From sip-admin@lists.bell-labs.com Fri Jun 1 02:43:36 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00090 for ; Fri, 1 Jun 2001 02:43:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 031B944350; Fri, 1 Jun 2001 02:43:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8AFEC44336 for ; Fri, 1 Jun 2001 02:42:32 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA20294; Fri, 1 Jun 2001 02:46:13 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 02:42:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Shan Lu'" , sip@lists.bell-labs.com Subject: RE: [SIP] comments on SDP section/bis-03 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 02:42:14 -0400 > -----Original Message----- > From: Shan Lu [mailto:slu@nextone.com] > Sent: Thursday, May 31, 2001 1:45 PM > To: sip@lists.bell-labs.com > Subject: [SIP] comments on SDP section/bis-03 > > > Hi, > > 1. From Section B.3.1 (3rd paragraph): > > "If the stream in the answer is marked as sendrecv, it MUST > contain at > least one codec the answerer is willing to both send and > receive with, > from amongst those listed in the offer. The stream MAY indicate > additional codes, not listed in the corresponding stream in > the offer, > that the answerer is willing to receive with." > > My comment is on the last sentence. It seems rather odd that somebody > can list a codec as recv only in a media stream that is send > and recv. > Is this a typo? The last sentence should read as: "The stream > ..., that > the answerer is willing to send and receive with." This is something we discussed at IETF 50. It is not a typo. The idea is that there are codecs (well, one in particular, rfc2833), which one would like to use in a bidirectional stream, but for which one side really only ever wants to send it, and the other side is willing to receive it. This is a common case when a user calls a media server, for example. So, the idea is that the caller would offer a stream with PCMU as the codec. The callee, the media server, would answer with PCMU and also rfc2833. This means that the callee can send/recv PCMU, as can the caller, but the caller can also send rfc2833 to the callee. Far more complex scenarios (in terms of send/recv capabilities for codecs within a stream) are possible, but this is the limit of the expressiveness of SDP, and fortunately, covers a really important case. SDP-ng will handle the more complex ones. > > 2. Immediately after the quoted sentences, I propose that we add the > following text: > > "If more than one codec are listed in the answer, the answerer and > offerer may choose different codecs to send media, leading to > asymmetric > codecs being used for send and receive. Furthermore, even > for the same > codec, the answerer and offerer may choose different > packetization sizes > because the indication of packetization time is not mandatory in SDP." Thats fine. > > I'd rather see that the SIP spec requires only one codec > listed in the > answer and mandates usage of ptime, for reasons that I > elaborated in my > earlier postings. If people out there think otherwise, at > least we need > to point out the consequences. And I have pointed out the reasons why multiple codecs in parallel have been part of the spec, and of the general IP conferencing model, for a long time. To address the concern that there are phones that cannot support more than one codec, we have the SDP-based caps exchange spec that is now in last call in mmusic. > > 3. From Section B.4 (4th paragraph): > > "..., the new SDP MUST have a matching media section for each media > section in the previous SDP. ... This matching is necessary > in order for > the answerer to determine which stream in the new SDP > corresponds to a > stream in the previous SDP." > > I think the idea of "matching media" is completely bogus as > described in > bis-03. This is not new. Matching of media lines by ordering has been part of SIP since rfc2543, and it is purely based on a weakness of SDP in that it has no explicit stream IDs. Its needed, for example, if I send an INVITE with: m=audio 2400 RTP/AVP 0 m=audio 2402 RTP/ACP 10 and then a re-INVITE with m=audio 2401 RTP/AVP 0 Since port numbers can change, what has happened here? Have we deleted the first stream, or the second? > Compare the 2nd and 3rd examples in Section B.5. Are > the first m > lines in these two SDPs supposed to match with each other? Oops, I screwed up big time. The new stream was added as the top m line, when it should have been the bottom. I will fix in -04. > What if the > media has changed? Consider the following two SDPs: > > SDP1: > m=audio 2400 RTP/AVP 0 > m=video 3600 RTP/AVP 31 > > SDP2: > m=video 3600 RTP/AVP 31 > m=audio 2402 RTP/AVP 0 > > The only thing that has changed is the audio port from 2400 > to 2402. But > since I am allowed to change media type, I can change the > order of the m > lines. Either the audio port has changed, or the two streams have changed media types and ports. In this example, one can tell realistically which is the case. But, without explicit numbering, how would you propose I know which streams in a re-INVITE correspond to which ones in the previous INVITE? -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 03:11:38 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01918 for ; Fri, 1 Jun 2001 03:11:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7EA29443D0; Fri, 1 Jun 2001 03:11:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 58178443CA for ; Fri, 1 Jun 2001 03:10:25 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA20396; Fri, 1 Jun 2001 03:14:14 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 03:10:19 -0400 Message-ID: From: Jonathan Rosenberg To: "'Shan Lu'" , sip@lists.bell-labs.com Subject: RE: [SIP] comments on SDP section/bis-03 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 03:10:12 -0400 > -----Original Message----- > From: Shan Lu [mailto:slu@nextone.com] > Sent: Thursday, May 31, 2001 1:45 PM > To: sip@lists.bell-labs.com > Subject: [SIP] comments on SDP section/bis-03 > > > Hi, > > 1. From Section B.3.1 (3rd paragraph): > > "If the stream in the answer is marked as sendrecv, it MUST > contain at > least one codec the answerer is willing to both send and > receive with, > from amongst those listed in the offer. The stream MAY indicate > additional codes, not listed in the corresponding stream in > the offer, > that the answerer is willing to receive with." Actually, the asymmetric case will not be that common based on the interpretation of ordering as implying preferences. If A INVITEs B with codecs 1,2 in that order, and B supports both, the answer has 1,2. Now, according to the spec, A SHOULD send with codec 1, and B SHOULD send with codec 1. The only trouble that would arise is if B returns, in the 200 OK, codecs 2,1 in that order. THis leads to asymmetric operation. So, I am more than willing to add the following piece of text instead: "Although the answerer MAY list the codecs in their desired order of preference, it is STRONGLY RECOMMENDED that unless there is a specific reason, the answer list codecs in the same relative order they were present in the offer. In other words, if a stream in the offer lists codecs 8, 22 and 48, in that order, and the answerer only supports codecs 8 and 48, it is STRONGLY RECOMMENDED that, if the answer has no reason to change it, the ordering of codecs in the answer be 8, 48, and not 48, 8. This helps ensure that the same codec is used in both directions." Now, this can't guarantee it, since one side may decide to change codecs based on adaptation. The bit about packetization delay needs to be in there; I had forgotten to mention it in -03 and will add it to -04. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 03:45:42 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02303 for ; Fri, 1 Jun 2001 03:45:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C434443AA; Fri, 1 Jun 2001 03:45:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B302A44336 for ; Fri, 1 Jun 2001 03:44:47 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA20656; Fri, 1 Jun 2001 03:48:27 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 03:44:30 -0400 Message-ID: From: Jonathan Rosenberg To: Robert Sparks , "'Christian Jansson'" Cc: kbinu@hss.hns.com, sip@lists.bell-labs.com Subject: RE: [SIP] Problems with multi-proxy authentication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 03:44:24 -0400 > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Thursday, May 31, 2001 2:29 PM > To: 'Christian Jansson'; Robert Sparks; 'jdrosen@dynamcisoft.com' > Cc: kbinu@hss.hns.com; sip@lists.bell-labs.com > Subject: RE: [SIP] Problems with multi-proxy authentication > > > > > > -----Original Message----- > > From: Christian Jansson [mailto:christian@hotsip.com] > > Sent: Thursday, May 31, 2001 2:24 PM > > To: "Robert Sparks" > > Cc: kbinu@hss.hns.com; sip@lists.bell-labs.com > > Subject: RE: [SIP] Problems with multi-proxy authentication > > > > > > > > > > Another question is about the description of > > > > Proxy-Authenticate.The last > > > > sentence states that: "The server responds with 401 > > > > (Unauthorized) if the > > > > client guessed wrong". And the description for WWW-Authenticate > > > > states > > > > that: "the WWW-Authenticate response-header MUST be included in > > > > 401". > > > > But the handling of WWW-Authenticate seems to be totally > > > > different as it is > > > > based on the To header while Proxy-Authenticate handling is > > > > based on the > > > > Request-Uri. So how is a UAC supposed to handle this? > > > > > > Where do you get the idea that WWW-Authenticate is based on a To: > > > header? > > > > I got it from 10.48 WWW-Authenticate (bis-03). The second > part states > > that: "A user agent SHOULD cache the authorization credentials for a > > given value of the destination (To header) and realm ...". > > I'm not sure why that's there. It implies that I (the user) > will have to > reenter my proxy credentials every time I call someone new. I > don't think > that's what was intended. Jonathan? No, it doesn't imply you will re-enter them. Remember, we are talking about UAS authentication of a UAC. It has nothing to do with proxies. So, if you call someone new, odds are that it will require new credentials. In fact, using the request URI here would be wrong, since it might be different between the initial INVITE and the ACK/re-INVITE/BYE because of Contact and Record-Routing. However, the URL portion of the To field doesn't change (I'll update the text to say URL portion, not just the whole To field). Christian also wrote: > Ok, it seems like we both agree on this. But take a look at 10.31 in > bis-03, last sentence. I think it trying to say that if I send the > wrong credentials to a 407/Proxy-Authentication I will get a 401 back! Yikes... that seems wrong to me also, and would explain your confusion. Henning? Christian wrote: > I also think that the description of Proxy-Authenticate is a > bit strange as > it > talks a lot about the UAC "contacting a specific proxy > server". Since when > did a SIP UAC actually know that it was going to contact a > proxy server > and not a UAS, or a redirect server? Yes, I agree this is confusing. We need a concise definition of how to cache credentials, if we want to provide support for that. I'm not really sure how to do it, since its hard to say whether a specific request will reach a specific proxy. The most important case, local outbound proxies, is easy, since the UAC knows that every request goes to that. I'm not sure any other proxy credential caching will be that useful. Maybe we should limit the discussion to just that case? -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 03:57:30 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02399 for ; Fri, 1 Jun 2001 03:57:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5EDC4440B; Fri, 1 Jun 2001 03:56:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id DD84844409 for ; Fri, 1 Jun 2001 03:55:54 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA20709; Fri, 1 Jun 2001 03:59:36 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 03:55:41 -0400 Message-ID: From: Jonathan Rosenberg To: Robert Sparks , "'Christian Jansson'" , "'David Simons'" Cc: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] RE: [Simple] Difference between a SUBSCRIBE and a re-SUBSCRIBE Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 03:55:33 -0400 > -----Original Message----- > From: Robert Sparks > Sent: Tuesday, May 29, 2001 10:11 AM > To: 'Christian Jansson'; David Simons; Jonathan Rosenberg > Cc: 'sip@lists.bell-labs.com' > Subject: RE: [Simple] Difference between a SUBSCRIBE and a > re-SUBSCRIBE > > > You are correct that a receiving agent can only expect > increasing CSeqs due to the opportunity for intervening > proxies to consume messages (with a 407 for example). > > The remaining motivation for increasing by 1 on the sending > side, as I understand it, is preserving CSeq space. Thats not a huge motivation, since the space is 2^31, which is pretty big for a single call leg. To be honest, the main motivation for contiguous increments was to provide contiguous increments at UAS, but this was before we (or, at least I) realized that an intermediate 407 fouled it all up. So, there is no real large motivation remaining, excepting that a UA can probably use it to detect a crash and restart condition on the remote side (a large gap in sequence numbers). -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 04:12:17 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02563 for ; Fri, 1 Jun 2001 04:12:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9026644403; Fri, 1 Jun 2001 04:09:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 364DB44403 for ; Fri, 1 Jun 2001 04:08:19 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA20842; Fri, 1 Jun 2001 04:12:07 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 04:08:12 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gonzalo Camarillo'" , Christer Holmberg Cc: sip@lists.bell-labs.com Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-isup-01.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 04:08:03 -0400 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Sunday, May 20, 2001 9:17 PM > To: Christer Holmberg > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-isup-01.txt > > > Hello, > > The purpose of INFO (before everybody began thinking that INFO can be > used for everything in the world) was to transport PSTN signalling. > However, since the INFO RFC was issued before we were ready with the > mapping draft, some minor changes will have to be added when INFO > advances to draft standard. > > About a general comment in the bis draft (about where to send requests > before the 200 OK), as I said, I think it is necessary. There are two things: 1. where to send pre-call-completion requests when you decide to send them, 2. when should a UAS include Contact/tags in a provisional Item (1) does belong in bis, I think, since it currently allows for provisionals with Contacts/tags (although I think it is still silent on sending requests before the call completes, and that needs to change). Item (2) depends on the extension. SIP-T needs to say that all SIP-T gateways have to send a provisional response with tags/Contacts in order to get pre-call-completion requests. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > Christer Holmberg wrote: > > > > Hi, > > > > I agree with what you say. > > > > So, one could argue that it should be said in the INFO RFC > instead of > > the ISUP-SIP draft. > > > > HOWEVER, the INFO RFC says (unfortunately, I think...) that > INFO is used > > for mid-session (ie AFTER the INVITE transaction is > finished) only, so > > one could say it is not an issue there. Then, since the > ISUP-SIP draft > > is the first (and currently only) SIP extension that may > also use INFO > > BEFORE the INVITE transaction is finished, one could argue that it > > should be said there. The third option is, like you > mentioned, to put it > > as a general rule in the bis draft, for ANY request that may be sent > > before the INVITE transaction is finished. > > > > My point is, that since it may cause problems for SIP-T, I want it > > mentioned SOMEWHERE :) > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Gonzalo Camarillo wrote: > > > > > > Hello, > > > > > > As I said in my previous mail, this is a general SIP > question. It has > > > nothing to do with the fact that you use SIP-T or that you are a > > > gateway. > > > > > > The general question you are after is: "Where do I send > requests if the > > > INVITE transaction is not complete yet?". > > > > > > I believe that bis should say that typically no requests > are sent before > > > the INVITE terminates, but that there are a few > exceptions, namely: > > > PRACK, COMET and INFO. > > > > > > Then, it can be explained in bis or in the RFCs defining > the extensions > > > where to send the requests (Route/Contact of provisional > responses). > > > > > > So, answering this question is up to bis and the > drafts/RFCs defining > > > the extensions themself, but never up to the isup-sip > mapping draft. We > > > do not explain how to locate a SIP server either, because > bis deals with > > > it already. Let's not try to make the scope of the > mapping draft wider. > > > Its scope is good as it is right now. > > > > > > Best regards, > > > > > > Gonzalo > > > > > > Christer Holmberg wrote: > > > > > > > > Hi, > > > > > > > > >I believe that this behavior is vanilla SIP, isn't it? > > > > > > > > I don't think it is mandatory (I appologise if I'm > wrong) to include a > > > > Contact header in a 18x provisional responses, and to > include a To-tag > > > > in a 18x provisional response. From a basic SIP > standard point of view > > > > it's optional, but different extension functionalities > (eg PRACK and > > > > SIP-T) can then make it mandatory. > > > > > > > > >We use the Contact/Route in provisional responses for > an INVITE to send > > > > >requests (typically PRACK, COMET and/or INFO) until we > get the 200 OK > > > > >for the INVITE with the definitive Route/Contact for > the session. Why > > > > >would you think we should add this in the ISUP-SIP draft? > > > > > > > > It is nowhere said that we use Contact/Route in > provisional responses > > > > for these kind of requests - no matter what request it > is. Yes, the > > > > 100rel draft says it for PRACK, and the manyfolks draft > may say it for > > > > COMET, but I haven't seen it anywhere for INFO. > > > > > > > > My point was that I wanted to make it a MUST, or at > least a SHOULD, for > > > > nodes supporting SIP-T, to make sure that any possible > INFO sent by the > > > > UAC before the 200 is received reaches the same UAS, > and that is why I > > > > wanted to add it to the ISUP-SIP draft. > > > > > > > > ...or, it should be added to the bis draft that this is > a MUST always > > > > when the UAC may send a new request (PRACK, COMET, > INFO, whatever...) > > > > before the final response is received. > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Gonzalo > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > I have a comment about the ISUP-SIP draft, related to SIP-T. > > > > > > > > > > > > When PRACK is used, the UAS MUST include a Contact > header and a To tag > > > > > > in the 18x provisional responses. > > > > > > > > > > > > I think it should also be a MUST for an UAS > supporting SIP-T, since the > > > > > > UAC may send an INFO before it has received a final > response for the > > > > > > INVITE. This would ensure that the INFO reaches the > same node from where > > > > > > the 18x provisional response came, if the INVITE was forked. > > > > > > > > > > > > Comments? > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer Holmberg > > > > > > Ericsson Finland > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +1 212 > 939 71 71 > > > > > Columbia University Mobile: +358 40 > 702 35 35 > > > > > 472 Computer Science Building Fax : +358 9 > 299 30 52 > > > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > > New York, NY 10027 > > > > USA Gonzalo.Camarillo@ericsson.com > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementor's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 04:24:52 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02776 for ; Fri, 1 Jun 2001 04:24:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5A6844489; Fri, 1 Jun 2001 04:17:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8AD8D44487 for ; Fri, 1 Jun 2001 04:16:27 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA20870; Fri, 1 Jun 2001 04:20:16 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 04:16:21 -0400 Message-ID: From: Jonathan Rosenberg To: "'Baniel Uri-CUB001'" , sip@lists.bell-labs.com Subject: RE: [SIP] Branch ID MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 04:16:18 -0400 > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Sunday, May 13, 2001 7:09 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Branch ID > > > 1. Is it true that with or without regard to branch IDs, a > forking proxy > needs to keep a list of network addresses of forked > destinations, so it > knows where to send consecutive requests such as Cancel or ACK to? Not necessarily. The only requirement is the ACK/CANCEL have the same R-URI as the original INVITE, and that SRV lookup randomization processes yield the same result for the same transaction ID. The implication is that the CANCEL/ACK will go to the same network address. You could, as an optimization, cache that, buy you might lose some SRV failover benefits if you do that. > 2. If the answer to (1) is YES, then is it true that the > Branch ID is just > an elegant (application layer) way to refer to the branches, > i.e., if it was > not there a forking proxy would have still known to tell one > branch from > another by their network addresses? No. The branch ID serves two purposes. One is to disambiguate *responses* to forked requests from each other, since the source IP of those responses won't necessarily be the same as the destination IP of where you sent them. The second purpose of the branch ID is to differentiate loops from spirals. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 04:36:31 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02886 for ; Fri, 1 Jun 2001 04:36:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2649E44496; Fri, 1 Jun 2001 04:24:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id AA495443E7 for ; Fri, 1 Jun 2001 04:23:27 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA20901; Fri, 1 Jun 2001 04:27:17 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 04:23:22 -0400 Message-ID: From: Jonathan Rosenberg To: "'seshashayi@hss.hns.com'" , sip@lists.bell-labs.com, Jonathan Rosenberg MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] RE: Encryption in bis-02 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 04:23:17 -0400 > -----Original Message----- > From: seshashayi@hss.hns.com [mailto:seshashayi@hss.hns.com] > Sent: Thursday, May 10, 2001 9:52 AM > To: sip@lists.bell-labs.com; Jonathan Rosenberg > Subject: Encryption in bis-02 > > > > > Hi, > In the draft-ietf-sip-rfc2543bis-02(Nov 2000), in the > section 13.1.1 > describing the End -to -End Encryption, > it refers to enc. column in Table 4,5 for the > specification of headers > which must not be encrypted. > But, the Table4 and Table 5 don't seem to have that column at all. > > The RFC 2543(March 1999) has this column. > Can I know,why was this removed in the bis-02? This was an error that has been fixed in -03. Section 10 says: The "proxy" column describes whether proxies can add comma-separated elements to headers ("c", for concatenate or comma), can modify the header ("m"), can add the header if not present ("a") or need to read the header ("r"). Headers that need to be read cannot be encrypted. And section 18.1.1 says: The "proxy" column describes whether proxies can add comma-separated elements to headers ("c", for concatenate or comma), can modify the header ("m"), can add the header if not present ("a") or need to read the header ("r"). Headers that need to be read cannot be encrypted. which is now consistent. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From extest-admin@lists.bell-labs.com Fri Jun 1 05:36:06 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03355 for ; Fri, 1 Jun 2001 05:36:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 291134501D for ; Fri, 1 Jun 2001 05:07:56 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: sip-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20010601090756.291134501D@lists.bell-labs.com> Date: Fri, 1 Jun 2001 05:07:56 -0400 (EDT) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, sip-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for sip-archive@lists.ietf.org: List Password // URL ---- -------- sip@lists.bell-labs.com TDGd http://lists.bell-labs.com/mailman/options/sip/sip-archive%40lists.ietf.org From sip-admin@lists.bell-labs.com Fri Jun 1 08:28:47 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06360 for ; Fri, 1 Jun 2001 08:28:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 489744433B; Fri, 1 Jun 2001 08:29:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from hs004.hotsip.com (unknown [212.28.214.197]) by lists.bell-labs.com (Postfix) with ESMTP id 94F1B44336 for ; Fri, 1 Jun 2001 08:28:41 -0400 (EDT) Received: from RYMDIS (dhcp013.hotsip.com [212.28.214.213]) by hs004.hotsip.com (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with SMTP id f51CSb604207; Fri, 1 Jun 2001 14:28:37 +0200 X-Authentication-Warning: hs004.hotsip.com: Host dhcp013.hotsip.com [212.28.214.213] claimed to be RYMDIS Message-ID: <028701c0ea96$9e97b3f0$d5d61cd4@RYMDIS> From: "Christian Jansson" To: "Jonathan Rosenberg" , "Robert Sparks" Cc: , References: Subject: Re: [SIP] Problems with multi-proxy authentication MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 14:30:19 +0200 Content-Transfer-Encoding: 7bit > > > > > Another question is about the description of > > > > > Proxy-Authenticate.The last > > > > > sentence states that: "The server responds with 401 > > > > > (Unauthorized) if the > > > > > client guessed wrong". And the description for WWW-Authenticate > > > > > states > > > > > that: "the WWW-Authenticate response-header MUST be included in > > > > > 401". > > > > > But the handling of WWW-Authenticate seems to be totally > > > > > different as it is > > > > > based on the To header while Proxy-Authenticate handling is > > > > > based on the > > > > > Request-Uri. So how is a UAC supposed to handle this? > > > > > > > > Where do you get the idea that WWW-Authenticate is based on a To: > > > > header? > > > > > > I got it from 10.48 WWW-Authenticate (bis-03). The second > > part states > > > that: "A user agent SHOULD cache the authorization credentials for a > > > given value of the destination (To header) and realm ...". > > > > I'm not sure why that's there. It implies that I (the user) > > will have to > > reenter my proxy credentials every time I call someone new. I > > don't think > > that's what was intended. Jonathan? > > No, it doesn't imply you will re-enter them. Remember, we are talking about > UAS authentication of a UAC. It has nothing to do with proxies. So, if you > call someone new, odds are that it will require new credentials. In fact, > using the request URI here would be wrong, since it might be different > between the initial INVITE and the ACK/re-INVITE/BYE because of Contact and > Record-Routing. However, the URL portion of the To field doesn't change > (I'll update the text to say URL portion, not just the whole To field). 10.48 in bis-03 also mentions the Request-URI three lines above the line talking about the To header. This can be a bit confusing. > > Christian also wrote: > > Ok, it seems like we both agree on this. But take a look at 10.31 in > > bis-03, last sentence. I think it trying to say that if I send the > > wrong credentials to a 407/Proxy-Authentication I will get a 401 back! > > Yikes... that seems wrong to me also, and would explain your confusion. > Henning? > > Christian wrote: > > I also think that the description of Proxy-Authenticate is a > > bit strange as it talks a lot about the UAC "contacting a specific > > proxy server". Since when did a SIP UAC actually know that it was > > going to contact a proxy server and not a UAS, or a redirect server? > > Yes, I agree this is confusing. We need a concise definition of how to cache > credentials, if we want to provide support for that. I'm not really sure how > to do it, since its hard to say whether a specific request will reach a > specific proxy. The most important case, local outbound proxies, is easy, > since the UAC knows that every request goes to that. I'm not sure any other > proxy credential caching will be that useful. Maybe we should limit the > discussion to just that case? Yes the UAC knows that every request goes to the outbound proxy, but if the UAC gets a 407, how can it detect that it is from the local outbound proxy and not from some other proxy in the chain? I think local outbound proxy is the special case as every request, independent of request-uri, will pass through it and could be challenged for proxy authentication. This could really mess up the credential cache with one entry per every request-uri, even though we know that we probably could have used already cached credentials. Could we make use of the "domain" parameter as defined in 3.2.1 RFC2617HttpAuth and instead cache credentials according to the domain provided in the challenge? Then if the address of the local outbound proxy matched one of the domains in the cache we could add the correct Proxy-Authorization header to every request without having the request-407 roundtrip. This would prevent the credentials cache from having an entry for each request-uri. Christian Jansson Hotsip www.hotsip.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 12:13:48 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11006 for ; Fri, 1 Jun 2001 12:13:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1670844341; Fri, 1 Jun 2001 12:14:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sheffield.cnchost.com (sheffield.concentric.net [207.155.252.12]) by lists.bell-labs.com (Postfix) with ESMTP id A54C844336 for ; Fri, 1 Jun 2001 12:13:09 -0400 (EDT) Received: from nextone.com ([207.113.13.1]) by sheffield.cnchost.com id MAA06021; Fri, 1 Jun 2001 12:13:04 -0400 (EDT) [ConcentricHost SMTP Relay 1.13] Message-ID: <3B17BDC8.2070503@nextone.com> From: Shan Lu User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12-20 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] comments on SDP section/bis-03 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Jun 2001 12:07:36 -0400 Content-Transfer-Encoding: 7bit The text looks good to me and will be helpful to eliminate some of the codec mismatch problems at Bakeoffs. Regards, Shan Lu NexTone Communications Jonathan Rosenberg wrote: > > > >> -----Original Message----- >> From: Shan Lu [mailto:slu@nextone.com] >> Sent: Thursday, May 31, 2001 1:45 PM >> To: sip@lists.bell-labs.com >> Subject: [SIP] comments on SDP section/bis-03 >> >> >> Hi, >> >> 1. From Section B.3.1 (3rd paragraph): >> >> "If the stream in the answer is marked as sendrecv, it MUST >> contain at >> least one codec the answerer is willing to both send and >> receive with, >> from amongst those listed in the offer. The stream MAY indicate >> additional codes, not listed in the corresponding stream in >> the offer, >> that the answerer is willing to receive with." > > > Actually, the asymmetric case will not be that common based on the > interpretation of ordering as implying preferences. If A INVITEs B with > codecs 1,2 in that order, and B supports both, the answer has 1,2. Now, > according to the spec, A SHOULD send with codec 1, and B SHOULD send with > codec 1. The only trouble that would arise is if B returns, in the 200 OK, > codecs 2,1 in that order. THis leads to asymmetric operation. So, I am more > than willing to add the following piece of text instead: > > "Although the answerer MAY list the codecs in their desired order of > preference, it is STRONGLY RECOMMENDED that unless there is a specific > reason, the answer list codecs in the same relative order they were present > in the offer. In other words, if a stream in the offer lists codecs 8, 22 > and 48, in that order, and the answerer only supports codecs 8 and 48, it is > STRONGLY RECOMMENDED that, if the answer has no reason to change it, the > ordering of codecs in the answer be 8, 48, and not 48, 8. This helps ensure > that the same codec is used in both directions." > > Now, this can't guarantee it, since one side may decide to change codecs > based on adaptation. > > The bit about packetization delay needs to be in there; I had forgotten to > mention it in -03 and will add it to -04. > > > -Jonathan R. > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 12:35:48 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11598 for ; Fri, 1 Jun 2001 12:35:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 46D46443F5; Fri, 1 Jun 2001 12:36:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wellington.cnchost.com (wellington.concentric.net [207.155.252.14]) by lists.bell-labs.com (Postfix) with ESMTP id 56CF7443E9 for ; Fri, 1 Jun 2001 12:35:12 -0400 (EDT) Received: from nextone.com ([207.113.13.1]) by wellington.cnchost.com id MAA24332; Fri, 1 Jun 2001 12:35:10 -0400 (EDT) [ConcentricHost SMTP Relay 1.13] Message-ID: <3B17C2F5.6010407@nextone.com> From: Shan Lu User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12-20 i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] comments on SDP section/bis-03 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Jun 2001 12:29:41 -0400 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > >> -----Original Message----- >> From: Shan Lu [mailto:slu@nextone.com] >> Sent: Thursday, May 31, 2001 1:45 PM >> To: sip@lists.bell-labs.com >> Subject: [SIP] comments on SDP section/bis-03 >> >> >> Hi, >> >> 1. From Section B.3.1 (3rd paragraph): >> >> "If the stream in the answer is marked as sendrecv, it MUST >> contain at >> least one codec the answerer is willing to both send and >> receive with, >> from amongst those listed in the offer. The stream MAY indicate >> additional codes, not listed in the corresponding stream in >> the offer, >> that the answerer is willing to receive with." >> >> My comment is on the last sentence. It seems rather odd that somebody >> can list a codec as recv only in a media stream that is send >> and recv. >> Is this a typo? The last sentence should read as: "The stream >> ..., that >> the answerer is willing to send and receive with." > > > This is something we discussed at IETF 50. It is not a typo. The idea is > that there are codecs (well, one in particular, rfc2833), which one would > like to use in a bidirectional stream, but for which one side really only > ever wants to send it, and the other side is willing to receive it. This is > a common case when a user calls a media server, for example. > > So, the idea is that the caller would offer a stream with PCMU as the codec. > The callee, the media server, would answer with PCMU and also rfc2833. This > means that the callee can send/recv PCMU, as can the caller, but the caller > can also send rfc2833 to the callee. > > Far more complex scenarios (in terms of send/recv capabilities for codecs > within a stream) are possible, but this is the limit of the expressiveness > of SDP, and fortunately, covers a really important case. SDP-ng will handle > the more complex ones. > I remember the discussion at IETF50. But still this looks like a hack. You actually list recv only codecs in a stream that is both send and recv. Another point is that what is wrong for the media server to list the DTMF codec as send and recv. Nobody can force you to use the codec to send. It seems that much of the discussion focuses on the DTMF codec. It'll help if some text can be added to explain the rationale and application. A year from now, somebody must have the same inquiry. >> 3. From Section B.4 (4th paragraph): >> >> "..., the new SDP MUST have a matching media section for each media >> section in the previous SDP. ... This matching is necessary >> in order for >> the answerer to determine which stream in the new SDP >> corresponds to a >> stream in the previous SDP." >> >> I think the idea of "matching media" is completely bogus as >> described in >> bis-03. > > > This is not new. Matching of media lines by ordering has been part of SIP > since rfc2543, and it is purely based on a weakness of SDP in that it has no > explicit stream IDs. Its needed, for example, if I send an INVITE with: > > m=audio 2400 RTP/AVP 0 > m=audio 2402 RTP/ACP 10 > > and then a re-INVITE with > > m=audio 2401 RTP/AVP 0 > > > Since port numbers can change, what has happened here? Have we deleted the > first stream, or the second? > >> Compare the 2nd and 3rd examples in Section B.5. Are >> the first m >> lines in these two SDPs supposed to match with each other? > > > Oops, I screwed up big time. The new stream was added as the top m line, > when it should have been the bottom. I will fix in -04. > >> What if the >> media has changed? Consider the following two SDPs: >> >> SDP1: >> m=audio 2400 RTP/AVP 0 >> m=video 3600 RTP/AVP 31 >> >> SDP2: >> m=video 3600 RTP/AVP 31 >> m=audio 2402 RTP/AVP 0 >> >> The only thing that has changed is the audio port from 2400 >> to 2402. But >> since I am allowed to change media type, I can change the >> order of the m >> lines. > > > Either the audio port has changed, or the two streams have changed media > types and ports. In this example, one can tell realistically which is the > case. But, without explicit numbering, how would you propose I know which > streams in a re-INVITE correspond to which ones in the previous INVITE? My problem is not with matching m lines, but with the possibility of change media type. In my opinion, allowing media type change defeats the very purpose of matching media. In my example, based on matching media, one would conclude that the audio stream has been replaced by a video stream and the video by an audio stream, which is incorrect. And the media services may be disrupted. Why would somebody change the media type for a m line while he can always set the port to 0 in the old m line and add a new m line with new media type? Regards, Shan Lu NexTone Communications _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 13:36:48 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14210 for ; Fri, 1 Jun 2001 13:36:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7CFF4433B; Fri, 1 Jun 2001 13:37:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 29B8544336 for ; Fri, 1 Jun 2001 13:36:33 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA06373; Fri, 1 Jun 2001 13:40:21 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 13:36:25 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A85A@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Jonathan Rosenberg , "'Christian Jansson'" Cc: "'kbinu@hss.hns.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Problems with multi-proxy authentication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 13:36:17 -0400 > -----Original Message----- > From: Jonathan Rosenberg > Sent: Friday, June 01, 2001 2:44 AM > To: Robert Sparks; 'Christian Jansson' > Cc: kbinu@hss.hns.com; sip@lists.bell-labs.com > Subject: RE: [SIP] Problems with multi-proxy authentication > > > > > > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Thursday, May 31, 2001 2:29 PM > > To: 'Christian Jansson'; Robert Sparks; 'jdrosen@dynamcisoft.com' > > Cc: kbinu@hss.hns.com; sip@lists.bell-labs.com > > Subject: RE: [SIP] Problems with multi-proxy authentication > > > > > > > > > > > -----Original Message----- > > > From: Christian Jansson [mailto:christian@hotsip.com] > > > Sent: Thursday, May 31, 2001 2:24 PM > > > To: "Robert Sparks" > > > Cc: kbinu@hss.hns.com; sip@lists.bell-labs.com > > > Subject: RE: [SIP] Problems with multi-proxy authentication > > > > > > > > > > > > > > Another question is about the description of > > > > > Proxy-Authenticate.The last > > > > > sentence states that: "The server responds with 401 > > > > > (Unauthorized) if the > > > > > client guessed wrong". And the description for > WWW-Authenticate > > > > > states > > > > > that: "the WWW-Authenticate response-header MUST be > included in > > > > > 401". > > > > > But the handling of WWW-Authenticate seems to be totally > > > > > different as it is > > > > > based on the To header while Proxy-Authenticate handling is > > > > > based on the > > > > > Request-Uri. So how is a UAC supposed to handle this? > > > > > > > > Where do you get the idea that WWW-Authenticate is > based on a To: > > > > header? > > > > > > I got it from 10.48 WWW-Authenticate (bis-03). The second > > part states > > > that: "A user agent SHOULD cache the authorization > credentials for a > > > given value of the destination (To header) and realm ...". > > > > I'm not sure why that's there. It implies that I (the user) > > will have to > > reenter my proxy credentials every time I call someone new. I > > don't think > > that's what was intended. Jonathan? > > No, it doesn't imply you will re-enter them. Remember, we are > talking about UAS authentication of a UAC. It has nothing to > do with proxies. So, if you call someone new, odds are that > it will require new credentials. In fact, using the request > URI here would be wrong, since it might be different between > the initial INVITE and the ACK/re-INVITE/BYE because of > Contact and Record-Routing. However, the URL portion of the > To field doesn't change (I'll update the text to say URL > portion, not just the whole To field). Ok, I was extending this to caching credentials used to respond to 407's. I'll go look for the text to make sure _that_ at least doesn't try to use the To:. I really disagree that the To: field should be involved in the key to the cache at all. It should _only_ be the realm. Consider the case where the UAS is a conference server on which I have an account and a set of credentials that go with that account. If I call in to use the conference server on sip:conf10031@confserver.com it 401s me (realm="Big Bucket Conference Services") and I provide credentials to my device, which caches them for future queries. I make the next call to sip:conf22994@confserver.com, it 401s me (realm="Big Bucket Conference Services"). With the above, the UAC is going to prompt me again! Have you discovered a problem with just using the realm as the key? > > Christian also wrote: > > Ok, it seems like we both agree on this. But take a look at 10.31 in > > bis-03, last sentence. I think it trying to say that if I send the > > wrong credentials to a 407/Proxy-Authentication I will get > a 401 back! > > Yikes... that seems wrong to me also, and would explain your > confusion. Henning? > > Christian wrote: > > I also think that the description of Proxy-Authenticate is a > > bit strange as > > it > > talks a lot about the UAC "contacting a specific proxy > > server". Since when > > did a SIP UAC actually know that it was going to contact a > > proxy server > > and not a UAS, or a redirect server? > > Yes, I agree this is confusing. We need a concise definition > of how to cache credentials, if we want to provide support > for that. I'm not really sure how to do it, since its hard to > say whether a specific request will reach a specific proxy. > The most important case, local outbound proxies, is easy, > since the UAC knows that every request goes to that. I'm not > sure any other proxy credential caching will be that useful. > Maybe we should limit the discussion to just that case? All you are doing is caching responses to a challenge. If you get a challenge from the same place, you try reusing what you have in your cache before you pester your user. For the case of multiple challenging proxies in the path, a device that doesn't cache my credentials will get put in the round file very quickly. You don't have to know ahead of time whether a specific request reaches a specific challenging proxy because if it does, it will challenge you. Or am I really missing the point? RjS _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 15:07:47 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16500 for ; Fri, 1 Jun 2001 15:07:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A1CA4433B; Fri, 1 Jun 2001 15:08:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from zrc2s03g.nortelnetworks.com (unknown [47.103.122.66]) by lists.bell-labs.com (Postfix) with ESMTP id A9B4E44336 for ; Fri, 1 Jun 2001 15:07:51 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id OAA00160 for ; Fri, 1 Jun 2001 14:09:00 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Fri, 1 Jun 2001 14:08:09 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Jun 2001 14:07:36 -0500 Message-ID: From: "Mary Barnes" To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EACE.1D0BA980" Subject: [SIP] Comments/nits on End-to-End encryption (section 18.1.1)/bis-03 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 14:07:33 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0EACE.1D0BA980 Content-Type: text/plain; charset="iso-8859-1" Hi all, Just a couple of minor comments on section 18.1.1 - In the bis-03 draft, it's specified the "Changes made in Version 03" section I that PGP has been removed (last bullet item). However, example messages on pages 124 and 125 (of the .txt version) indicate an Encryption header of "PGP version=5.0$". - (Even more minor), in section 18.1.1, the last sentence in the first paragraph specifies "three complementary forms of encryption", but only 2 are listed. I'm assuming this is another remnant of the PGP removal. Regards, Mary H. Barnes mbarnes@nortelnetworks.com IMS Solutions Standards Strategy 972-684-5432 Wireless 817-703-4806 ------_=_NextPart_001_01C0EACE.1D0BA980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments/nits on End-to-End encryption (section = 18.1.1)/bis-03

Hi all,

Just a couple of minor comments on section = 18.1.1

-  In the bis-03 draft, it's specified the = "Changes made in Version 03" section I that PGP has been = removed (last bullet item).  However, example messages on pages = 124 and 125 (of the .txt version) indicate an Encryption header of = "PGP version=3D5.0$".

- (Even more minor), in section 18.1.1, the last = sentence in the first paragraph specifies "three complementary = forms of encryption", but only 2 are listed.  I'm assuming = this is another remnant of the PGP removal.

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


------_=_NextPart_001_01C0EACE.1D0BA980-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 16:31:48 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17793 for ; Fri, 1 Jun 2001 16:31:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E0EB84433B; Fri, 1 Jun 2001 16:32:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mail2.intervoice-brite.com (mail2.intervoice-brite.com [204.62.8.15]) by lists.bell-labs.com (Postfix) with ESMTP id 11EB944336 for ; Fri, 1 Jun 2001 16:31:07 -0400 (EDT) Received: from 172.16.16.64 (gwsmtpsrv.intervoice.com [172.16.16.64]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with SMTP id PAA07012 for ; Fri, 01 Jun 2001 15:32:35 -0500 Received: from bculpepperpc ([151.214.151.180]) by 172.16.16.64; Fri, 01 Jun 2001 15:29:39 -0500 From: "Bert Culpepper" To: "'Jonathan Rosenberg'" , "'Shan Lu'" , Subject: RE: [SIP] comments on SDP section/bis-03 Message-ID: <005201c0ead9$90ad4050$b497d697@orlando.brite.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 16:29:30 -0400 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > Sent: Friday, June 01, 2001 2:42 AM > To: 'Shan Lu'; sip@lists.bell-labs.com > Subject: RE: [SIP] comments on SDP section/bis-03 > > > > > > > > -----Original Message----- > > From: Shan Lu [mailto:slu@nextone.com] > > Sent: Thursday, May 31, 2001 1:45 PM > > To: sip@lists.bell-labs.com > > Subject: [SIP] comments on SDP section/bis-03 > > > > > > Hi, > > > > 1. From Section B.3.1 (3rd paragraph): > > > > "If the stream in the answer is marked as sendrecv, it MUST > > contain at > > least one codec the answerer is willing to both send and > > receive with, > > from amongst those listed in the offer. The stream MAY indicate > > additional codes, not listed in the corresponding stream in > > the offer, > > that the answerer is willing to receive with." > > > > My comment is on the last sentence. It seems rather odd > that somebody > > can list a codec as recv only in a media stream that is send > > and recv. > > Is this a typo? The last sentence should read as: "The stream > > ..., that > > the answerer is willing to send and receive with." > > This is something we discussed at IETF 50. It is not a typo. > The idea is > that there are codecs (well, one in particular, rfc2833), > which one would > like to use in a bidirectional stream, but for which one side > really only > ever wants to send it, and the other side is willing to > receive it. This is > a common case when a user calls a media server, for example. > > So, the idea is that the caller would offer a stream with > PCMU as the codec. > The callee, the media server, would answer with PCMU and also > rfc2833. This > means that the callee can send/recv PCMU, as can the caller, > but the caller > can also send rfc2833 to the callee. > > Far more complex scenarios (in terms of send/recv > capabilities for codecs > within a stream) are possible, but this is the limit of the > expressiveness > of SDP, and fortunately, covers a really important case. > SDP-ng will handle > the more complex ones. > > > > > > 2. Immediately after the quoted sentences, I propose that > we add the > > following text: > > > > "If more than one codec are listed in the answer, the answerer and > > offerer may choose different codecs to send media, leading to > > asymmetric > > codecs being used for send and receive. Furthermore, even > > for the same > > codec, the answerer and offerer may choose different > > packetization sizes > > because the indication of packetization time is not > mandatory in SDP." > > Thats fine. > > > > > > I'd rather see that the SIP spec requires only one codec > > listed in the > > answer and mandates usage of ptime, for reasons that I > > elaborated in my > > earlier postings. If people out there think otherwise, at > > least we need > > to point out the consequences. > > And I have pointed out the reasons why multiple codecs in > parallel have been > part of the spec, and of the general IP conferencing model, > for a long time. > To address the concern that there are phones that cannot > support more than > one codec, we have the SDP-based caps exchange spec that is > now in last call > in mmusic. > > > > > 3. From Section B.4 (4th paragraph): > > > > "..., the new SDP MUST have a matching media section for each media > > section in the previous SDP. ... This matching is necessary > > in order for > > the answerer to determine which stream in the new SDP > > corresponds to a > > stream in the previous SDP." > > > > I think the idea of "matching media" is completely bogus as > > described in > > bis-03. > > This is not new. Matching of media lines by ordering has been > part of SIP > since rfc2543, and it is purely based on a weakness of SDP in > that it has no > explicit stream IDs. Its needed, for example, if I send an > INVITE with: > > m=audio 2400 RTP/AVP 0 > m=audio 2402 RTP/ACP 10 > > and then a re-INVITE with > > m=audio 2401 RTP/AVP 0 > > > Since port numbers can change, what has happened here? Have > we deleted the > first stream, or the second? > > > > Compare the 2nd and 3rd examples in Section B.5. Are > > the first m > > lines in these two SDPs supposed to match with each other? > > Oops, I screwed up big time. The new stream was added as the > top m line, > when it should have been the bottom. I will fix in -04. > If we consider the discussion at IETF 50 described above (and the text in B.3.1), wouldn't the events payload type be added to the original audio stream description? i.e., "m=audio 47920 RTP/AVP 0 1 110". But there are two things going on in this example at this point, changing the port for the audio and adding events media (at a different port). So a separate media description is needed in this case. It's also explicit that Bob will not send events, which is not known if a representation based on the discussion, and the text at the end of paragraph 3 in B.3.1, is used. Although since the media type is not present in the offer but is present in the answer, any media of that type should only flow one way. I write this because I also believe it's odd to be able to list a codec that's sendonly/recvonly in a stream that's sendrecv. I don't see the need for this practice. It may help in synchronizing tones with audio but that can be handled by using the same port in two media stream descriptions. (Or is this forbidden somewhere?) I like the example (when corrected) but don't like the text at the end of B.3.1 paragraph 3. The answerer gets no indication that the offerer will send the additional media type. However, separate media descriptions don't help with this aspect with SDP only in INVITE/200 and 200/ACK. Since it seems to me that somewhat special cases are being supported, can it be allowed/recommended to respond with SDP in an ACK (with previously offered contents unchanged) when the answerer has added a media stream not present in the offer? Another solution to the problem of both the offerer and answerer knowing the other's behavior with rfc2833 is defined in draft-mahy-sip-signaled-digits-00.txt. Or is the answer to use the SDP capabilities exchange stuff? Regards, Bert _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 16:33:17 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17814 for ; Fri, 1 Jun 2001 16:33:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 85CAF4440C; Fri, 1 Jun 2001 16:32:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lists.bell-labs.com (Postfix) with ESMTP id D4D1844336 for ; Fri, 1 Jun 2001 16:31:27 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA09142 for ; Fri, 1 Jun 2001 13:31:24 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA17094 for ; Fri, 1 Jun 2001 13:25:02 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Jun 2001 15:31:24 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E000@IL27EXM10.cig.mot.com> From: Baniel Uri-CUB001 To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [SIP] Invitation for a multicast session Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 15:31:23 -0500 My understanding is that a UAC can invite an individual or 'the first one to respond' from a group to a multicast session, but a UA can not invite the whole group by multicasting an Invite to the group. Is that true? ================================================================= Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; "Only by learning do we discover how ignorant we are" E.w.c ================================================================= _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 16:51:46 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18001 for ; Fri, 1 Jun 2001 16:51:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AC58D443AA; Fri, 1 Jun 2001 16:52:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lists.bell-labs.com (Postfix) with ESMTP id 3CC934433B for ; Fri, 1 Jun 2001 16:51:19 -0400 (EDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f51KpJU25073; Fri, 1 Jun 2001 13:51:19 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHG20918; Fri, 1 Jun 2001 13:51:16 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA08518; Fri, 1 Jun 2001 13:51:16 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15128.68.335584.688906@thomasm-u1.cisco.com> To: Robert Sparks Cc: Jonathan Rosenberg , "'Christian Jansson'" , "'kbinu@hss.hns.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Problems with multi-proxy authentication In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F314A85A@DYN-TX-EXCH-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F314A85A@DYN-TX-EXCH-001.dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 13:51:16 -0700 (PDT) Content-Transfer-Encoding: 7bit Robert Sparks writes: > All you are doing is caching responses to a challenge. If you > get a challenge from the same place, you try reusing what you > have in your cache before you pester your user. For the case > of multiple challenging proxies in the path, a device that doesn't > cache my credentials will get put in the round file very quickly. > > You don't have to know ahead of time whether a specific request > reaches a specific challenging proxy because if it does, it will > challenge you. > > Or am I really missing the point? Robert, I believe that http authentication is indeed stateless on the server as I think you are alluding to here, and with Basic authentication it is probably the least of your worries because you're just sending a uuencoded plaintext password each time. For more reasonable authentication schemes -- especially ones that prove freshness -- this may be problematic. If you're using public key signatures with anti-replay precautions, it implies that the UAC would have to resign each message; indeed, mutual would require all messages to be signed. This could lead to performance issues on low CPU performance UA's as well as high aggregation UA's. The second problem is that the two of the current popular means of asserting identity -- symmetric key signatures of kerberos tickets, and public key signatures over X.509 certs -- generate a large number of bytes on the wire. For Kerberos, that's typically between 300-500 bytes, and X.509 certs are typically bigger yet. This could become problematic where you are trying to keep the message count down for post dial delay considerations if it routinely runs over MTU, and could be a problem if the bit error rate on the access media favors smaller packets. In general, I agree that state sux(tm) and that if we can reasonably avoid storing state on proxies and UAS's, we should make that a priority. In this particular situation, however, I'm inclined to believe that creating shared state on the proxy/UAS for faster/smaller keyed integrity checksums may be the right tradeoff, despite not being especially enamored with the implications. Mike _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 17:35:46 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18415 for ; Fri, 1 Jun 2001 17:35:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C26A3443E9; Fri, 1 Jun 2001 17:36:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A98BB443E5 for ; Fri, 1 Jun 2001 17:35:45 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA10474; Fri, 1 Jun 2001 17:39:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Jun 2001 17:35:34 -0400 Message-ID: From: Jonathan Rosenberg To: "'Hrishikesh Saria'" , sip@lists.bell-labs.com Subject: RE: [SIP] drafts NAT ALG RSIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Jun 2001 17:35:32 -0400 Not sure if this was ever answered: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-01.txt http://search.ietf.org/internet-drafts/draft-martin-midcom-sip-natfw-callflo ws-00.txt http://search.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-00.txt Expired, http://www.jdrosen.net/papers/draft-rosenberg-sip-firewalls-00.txt http://www.ietf.org/internet-drafts/draft-huitema-sdp4nat-00.txt http://www.ietf.org/internet-drafts/draft-ietf-midcom-framework-01.txt http://www.ietf.org/internet-drafts/draft-ietf-midcom-requirements-00.txt http://www.ietf.org/internet-drafts/draft-ietf-midcom-scenarios-02.txt Its a big, ugly topic. -Jonathan R. -----Original Message----- From: Hrishikesh Saria [mailto:hrishikesh.saria@eximsoft.com] Sent: Friday, May 18, 2001 2:33 AM To: sip@lists.bell-labs.com Subject: [SIP] drafts NAT ALG RSIP Hi, Where can i find the current drafts about SIP with NAT or SIP with RSIP which are currently being discussed. Regards Thanks in advance Hrishikesh Saria --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 20:32:50 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19889 for ; Fri, 1 Jun 2001 20:32:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7BA754433B; Fri, 1 Jun 2001 20:33:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id F1F5944336 for ; Fri, 1 Jun 2001 20:32:37 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01008; Fri, 1 Jun 2001 17:31:09 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28377 for corey@hearme.com; Fri, 1 Jun 2001 17:30:20 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id BAA06396 for ; Thu, 31 May 2001 01:19:45 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id BAA09903 for ; Thu, 31 May 2001 01:19:43 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24950; Thu, 31 May 2001 04:19:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24918 for ; Thu, 31 May 2001 04:19:01 -0400 (EDT) Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18637; Thu, 31 May 2001 04:18:29 -0400 (EDT) Received: from KMAINWAR-W2K.cisco.com (ams-vpdn-client-485.cisco.com [144.254.47.233]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA10128; Thu, 31 May 2001 10:17:54 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010531095312.00b67270@nordic.cisco.com> X-Sender: kmainwar@nordic.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: gratta@lucent.com From: Keith Mainwaring Cc: sob@harvard.edu, mankin@isi.edu, new-work@ietf.org, sip@lists.bell-labs.com, sipping@ietf.org, Yukio Hiramatsu , steve.norreys@bt.com, tsg11q6@ties.itu.ch, tsg11q11@ties.itu.ch In-Reply-To: <200105302022.QAA03857@hotair.hobl.lucent.com> Mime-Version: 1.0 X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: multipart/alternative; boundary="=====================_7210898==_.ALT" Subject: [SIP] [Sipping] Re: Initiation of work on interworking of BICC and ISUP with SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 10:19:40 +0200 --=====================_7210898==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I should just like to clarify the background to this "message". It was generated in the final minutes of the SG 11 closing plenary after completion of working party reports and liaison statements when many delegates, myself included, had left for the airport and not during the discussions of Questions 6, 9 and 11. With regard to the final paragraph, there was no agreement during the joint question 6 and 9 activity on SIP interworking that SG 11 would work on identifying requirements for extensions to SIP. The second sentence of the first paragraph also presumes too much. Keith Mainwaring, Q6/11 Rapporteur. At 16:22 30/05/2001 -0400, Greg Ratta wrote: >This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May >2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of >ITU-T SG 11. For further technical clarification, contact the Rapporteur >for Q6/11 (Keith Mainwaring, Tel: + 46 70 605 9076, { HYPERLINK >mailto:rburke@lucent.com }kmainwar@cisco.com{ >HYPERLINK mailto:kmainwar@cisco.com }) or the >Rapporteur for Q11/11 (Steve Norreys, Tel: +44 207 843 5189, >steve.norreys@bt.com). > >ITU-T Study Group 11 has initiated a work program to define signalling >requirements for the interworking of SIP with BICC (Bearer Independent >Call Control) and with ISUP (ISDN User Part of Signalling System 7). It >is the understanding of SG11 that the IETF will continue to focus its >energy on SIP protocol development and would look to the ITU-T to develop >interworking signalling requirements and protocols. > >SG 11 has scheduled three meetings before February 2002 to advance its >efforts in this subject. A strong consensus exists among the participants >of this Study Group that a common approach should be taken for both BICC >and ISUP. > >SG 11 plans to keep the IETF informed of any requirements for extensions >to SIP that may develop from its studies and looks forward to further >communications as this study progresses. > > > >Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols > >Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, >gratta@lucent.com --=====================_7210898==_.ALT Content-Type: text/html; charset="us-ascii" I should just like to clarify the background to this "message". It was generated in the final minutes of the SG 11 closing plenary after completion of working party reports and liaison statements when many delegates, myself included, had left for the airport and not during the discussions of Questions 6, 9 and 11. With regard to the final paragraph, there was no agreement during the joint question 6 and 9 activity on SIP interworking that SG 11 would work on identifying requirements for extensions to SIP. The second sentence of the first paragraph also presumes too much.

Keith Mainwaring, Q6/11 Rapporteur.

At 16:22 30/05/2001 -0400, Greg Ratta wrote:
This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q6/11 (Keith Mainwaring, Tel: + 46 70 605 9076, { HYPERLINK mailto:rburke@lucent.com }kmainwar@cisco.com{ HYPERLINK mailto:kmainwar@cisco.com }) or the Rapporteur for Q11/11 (Steve Norreys, Tel: +44 207 843 5189, steve.norreys@bt.com).

ITU-T Study Group 11 has initiated a work program to define signalling requirements for the interworking of SIP with BICC (Bearer Independent Call Control) and with ISUP (ISDN User Part of Signalling System 7).  It is the understanding of SG11 that the IETF will continue to focus its energy on SIP protocol development and would look to the ITU-T to develop interworking signalling requirements and protocols.

SG 11 has scheduled three meetings before February 2002 to advance its efforts in this subject.  A strong consensus exists among the participants of this Study Group that a common approach should be taken for both BICC and ISUP.

SG 11 plans to keep the IETF informed of any requirements for extensions to SIP that may develop from its studies and looks forward to further communications as this study progresses. 



Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols 

Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com </blockquote></x-html>
--=====================_7210898==_.ALT-- _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Jun 1 20:52:49 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20160 for ; Fri, 1 Jun 2001 20:52:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B20BB44394; Fri, 1 Jun 2001 20:53:07 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 0FBE444336; Fri, 1 Jun 2001 20:52:11 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01580; Fri, 1 Jun 2001 17:51:37 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28771 for corey@hearme.com; Fri, 1 Jun 2001 17:51:36 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12836 for ; Thu, 31 May 2001 10:43:43 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA17308 for ; Thu, 31 May 2001 10:43:42 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C8C444400; Thu, 31 May 2001 13:43:04 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 0D860443A3; Thu, 31 May 2001 13:42:05 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07898; Thu, 31 May 2001 13:41:29 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14833; Thu, 31 May 2001 13:41:31 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 31 May 2001 13:41:30 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF044654D4@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: diffserv@ietf.org, iptel@lists.bell-labs.com, megaco@fore.com, sip@lists.bell-labs.com, tsvwg@ietf.org Cc: gratta@lucent.com, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] [IPTEL] RE: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL M ECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 13:41:29 -0400 Folks, this thread may or may not be the start of something good or evil, but it is going out to too many lists! Please, as of now, let's move it to one, and only one list. I nominate tsvwg. If you are replying to any message on this thread, PLEASE edit the to/cc to limit it to tsvwg@ietf.org Brian > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, May 31, 2001 1:09 PM > To: Roy, Radhika R, ALCTA > Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu; > diffserv@ietf.org; iptel@lists.bell-labs.com; > issll@mercury.lcs.mit.edu; > megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; > tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; > tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; > ITU-SG16@mailbag.cps.INTEL.COM > Subject: [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL > MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL > > > At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: > >All applications (e.g., H.323, SIP) uses signaling messages > >among its functional entities (e.g., terminal, agents, > >gatekeepers, proxies, gateways) for communications. > > I'm not sure we're on the same planet. Please help me out here. > > I can think of a few applications that have agents, > gatekeepers, proxies, > and gateways, mostly resulting from the imposition of firewalls or > authentication systems, or from legacy applications like > imitating the > telephone system in a data network. The only one that > *requires* any kind > of gateway, to my knowledge, is H.323 teleconferencing, which > represents a > paltry fraction of traffic according to most current > measurements. Anything > else (75% of Internet traffic is http or FTP, most of the > rest is mail, on > private LANs applications like NFS are pretty common, and > even SIP can be > done without a gateway between consenting systems) could be > hooked up in > separate systems on a LAN and made to work without any such > signalling at all. > > Could you be more specific on what QoS signalling is required > by the world > wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, > calendaring, and so on? If not, could you be more specific > about what "all" > applications you have in mind? > > And could you be more specific about what issues this proposal is > addressing that have not already been addressed in de facto > standards and > deployed in operational systems? It would be very nice to > understand what > you are preparing to ask vendors to do, and whether operators are > interested in deploying them. > > > > _______________________________________________ > Sipping mailing list > Sipping@ietf.org > http://www.ietf.org/mailman/listinfo/sipping > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sat Jun 2 09:14:48 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11387 for ; Sat, 2 Jun 2001 09:14:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E681B44338; Sat, 2 Jun 2001 09:15:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lists.bell-labs.com (Postfix) with ESMTP id 81BF244336 for ; Sat, 2 Jun 2001 09:14:17 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id GAA18791 for ; Sat, 2 Jun 2001 06:14:17 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id GAA25842 for ; Sat, 2 Jun 2001 06:14:17 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Sat, 2 Jun 2001 08:14:17 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E002@IL27EXM10.cig.mot.com> From: Baniel Uri-CUB001 To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Bis03 section 20.2 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 2 Jun 2001 08:14:17 -0500 In this example Bob is being invited to a multicast conference. As the mcast IP addresses show, the mcast addr (239...), which is being used to distribute the Invite is totally different than the one, which will be used for the conference itself (224...). As a matter of fact Bob could be invited to the conf call by unicast means, right?! So my question is: Is there any ratio to multicast an invitation to a multicast session rather than unicast it? or it just happened that the example had both mcast elements? _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sat Jun 2 11:26:46 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11925 for ; Sat, 2 Jun 2001 11:26:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B57A14433F; Sat, 2 Jun 2001 11:27:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 91D8F44336 for ; Sat, 2 Jun 2001 11:26:51 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Sat, 2 Jun 2001 08:26:30 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EB78.60565F50" Subject: [SIP] E.164 request-uri domain's. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 2 Jun 2001 08:26:21 -0700 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0EB78.60565F50 Content-Type: text/plain; charset="iso-8859-1" Hi, We have had this discussion quite a few times but I thought I would throw in a new idea. When building a request-uri containing an E.164 number which does not "belong" or is associated with a particular domain name then the most desirable action is to place a tel: URL in the outbound request-uri. However, if a tel URL cannot be generated or received for whatever reason, then a SIP url must be used instead and a domain name must selected for the url. The easiest option is to simply place the outbound proxy/destination's address or hostname in the host portion. Eg "sip:+12135551234@;user=phone". I remember that some people had some academic objections to this approach because the request-uri referred to an "intermediate destination" rather than the final destination. I personally believe that it is a) easy to ignore the domain name for the telephone subscriber case at a proxy (that is you simply treat a "user=phone" request-uri as a simple telephone number (ala tel URL) if the domain name is that of the proxy's). With the new loop detection rules I don't believe this creates any problems. This removes the objection due to the "intermediate destination" concept. b) A proxy worth the disk sectors it is written on should be able to route a call of this form. Firstly, do people who previously had objections to this approach still have their objections? Alternatively, for E.164 numbers what do people think about allowing "sip:+12135551234@e164;user=phone"? e164 is the domain stem used by ENUM for doing DNS lookups of E.164 numbers. In this case the host name of the sip URL correctly indicates that domain of the user portion. Cheers, Robert. ------_=_NextPart_001_01C0EB78.60565F50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable E.164 request-uri domain's.

Hi,

We have had this discussion quite a = few times but I thought I would throw in a new idea.

When building a request-uri containing = an E.164 number which does not "belong" or is associated with a = particular domain name then the most desirable action is to place a = tel: URL in the outbound request-uri. However, if a tel URL cannot be = generated or received for whatever reason, then a SIP url must = be used instead and a domain name must selected for the = url.

The easiest option is to simply place = the outbound proxy/destination's address or hostname in the host = portion. Eg "sip:+12135551234@<proxy hostname>;user=3Dphone". I = remember that some people had some academic objections to this approach = because the request-uri referred to an "intermediate destination" = rather than the final destination. I personally believe that it is =

  1. easy to ignore the = domain name for the telephone subscriber case at a proxy (that is you = simply treat a "user=3Dphone" request-uri as a simple telephone number = (ala tel URL) if the domain name is that of the proxy's). With the new = loop detection rules I don't believe this creates any problems. This = removes the objection  due to the "intermediate destination" = concept.
  2. A proxy worth the disk sectors it is = written on should be able to route a call of this form.

Firstly, do people who previously had = objections to this approach still have their objections?

Alternatively, for E.164 numbers what = do people think about allowing "sip:+12135551234@e164;user=3Dphone"? e164 is the = domain stem used by ENUM for doing DNS lookups of E.164 numbers. In = this case the host name of the sip URL correctly indicates that domain = of the user portion.

Cheers,

Robert.

------_=_NextPart_001_01C0EB78.60565F50-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 01:43:47 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19858 for ; Sun, 3 Jun 2001 01:43:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 630DF44337; Sun, 3 Jun 2001 01:44:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1A2D744336 for ; Sun, 3 Jun 2001 01:43:06 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14424; Sun, 3 Jun 2001 01:47:01 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Jun 2001 01:43:04 -0400 Message-ID: From: Jonathan Rosenberg To: "'Fairlie-Cuninghame, Robert'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] E.164 request-uri domain's. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Jun 2001 01:43:02 -0400 -----Original Message----- From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] Sent: Saturday, June 02, 2001 11:26 AM To: 'sip@lists.bell-labs.com' Subject: [SIP] E.164 request-uri domain's. >Hi, > >We have had this discussion quite a few times but I thought I would throw in a new idea. > >When building a request-uri containing an E.164 number which does not "belong" or is >associated with a particular domain name then the most desirable action is to place a tel: >URL in the outbound request-uri. However, if a tel URL cannot be generated or received for >whatever reason, then a SIP url must be used instead and a domain name must selected for >the url. > >The easiest option is to simply place the outbound proxy/destination's address or hostname >in the host portion. Eg "sip:+12135551234@;user=phone". I remember that >some people had some academic objections to this approach because the request-uri referred >to an "intermediate destination" rather than the final destination. That doesn't make sense to me. As long as a call traverses proxies, the request URI will always refer to intermediate destinations. I personally believe >that it is easy to ignore the domain name for the telephone subscriber case at a proxy >(that is you >simply treat a "user=phone" request-uri as a simple telephone number (ala tel URL) if the >domain name is that of the proxy's). With the new loop detection rules I don't believe >this creates any problems. This removes the objection due to the "intermediate >destination" concept. The interpretation of the LHS of the @ is entirely up to the administrator of the domain. A very common usage of that namespace is that any usernames that are purely numbers, and start with +, are E.164 formatted numbers, and should be handled in whatever way is appropraite for international phone numbers. So, the domain is not really ignored, nor should it be. It points to a server handling the domain which knows how to interpret the user portion of the URI in this way. Also, I believe this is a fairly common usage in real implementations. >Alternatively, for E.164 numbers what do people think about allowing "sip:+12135551234 >@e164;user=phone"? e164 is the domain stem used by ENUM for doing DNS lookups of E.164 >numbers. In this case the host name of the sip URL correctly indicates that domain of the >user portion. Now, this I object to. I should be able to take a SIP URL, and always be able to route it somewhere for further processing. Thats why the domain name is mandatory. By using e164 as the domain, you would require every host to know the semantics of that and have proper handling for it. Yuck. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 01:48:46 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20179 for ; Sun, 3 Jun 2001 01:48:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E60F84435E; Sun, 3 Jun 2001 01:49:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 142714435B for ; Sun, 3 Jun 2001 01:48:21 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14445; Sun, 3 Jun 2001 01:52:17 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Jun 2001 01:48:20 -0400 Message-ID: From: Jonathan Rosenberg To: "'Baniel Uri-CUB001'" , sip@lists.bell-labs.com Subject: RE: [SIP] Bis03 section 20.2 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Jun 2001 01:48:19 -0400 > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Saturday, June 02, 2001 9:14 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Bis03 section 20.2 > > > In this example Bob is being invited to a multicast > conference. As the mcast > IP addresses show, the mcast addr (239...), which is being used to > distribute the Invite is totally different than the one, > which will be used > for the conference itself (224...). That should almost always be the case. > > As a matter of fact Bob could be invited to the conf call by > unicast means, > right?! Indeed, this was the very purpose for which SIP was initially conceived. > So my question is: Is there any ratio to multicast an invitation to a > multicast session rather than unicast it? or it just happened that the > example had both mcast elements? I think you mean "reason" and not "ratio" above. If I want to INVITE some group of people to an Mbone conference, and those people are available via multicast, then the INVITE is sent to the multicast group that those people are available on. Of course, I can also send an INVITE using normal unicast, and this INVITE can describe an Mbone session as well. There is nothing that mandates that an invitation to a multicast session be itself multicast. It depends on who you are trying to INVITE. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 02:08:47 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28517 for ; Sun, 3 Jun 2001 02:08:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1BF9844355; Sun, 3 Jun 2001 02:09:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 719DF4433A for ; Sun, 3 Jun 2001 02:08:26 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA14531; Sun, 3 Jun 2001 02:12:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Jun 2001 02:08:18 -0400 Message-ID: From: Jonathan Rosenberg To: Robert Sparks , "'Christian Jansson'" Cc: "'kbinu@hss.hns.com'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Problems with multi-proxy authentication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Jun 2001 02:08:16 -0400 > -----Original Message----- > From: Robert Sparks > Sent: Friday, June 01, 2001 1:36 PM > To: Jonathan Rosenberg; 'Christian Jansson' > Cc: 'kbinu@hss.hns.com'; 'sip@lists.bell-labs.com' > Subject: RE: [SIP] Problems with multi-proxy authentication > > I really disagree that the To: field should be involved in > the key to the cache at all. It should _only_ be the realm. > Consider the case where the UAS is a conference server on > which I have an account and a set of credentials that go with > that account. If I call in to use the conference server on > sip:conf10031@confserver.com it 401s me (realm="Big Bucket > Conference Services") and I provide credentials to my device, > which caches them for future queries. I make the next call to > sip:conf22994@confserver.com, it 401s me (realm="Big Bucket > Conference Services"). With the above, the UAC is going to > prompt me again! Have you discovered a problem with just > using the realm as the key? Ah, now I see the confusion. There are two interpretations of caching: 1. Before sending a new request, a user checks to see if it has any credentials that might apply for that request, and inserts them right away. This avoids extra round-trips for challenges. 2. Send a new request, and then get a 407 or 401. Check to see if you have any credentials that apply to the challenges in the response, and use those instead of re-querying the user. Resend the request immediately with those cached credentials. I was talking about case 1, in which case the UAC doesn't know what the realm is before sending a request. Assuming you are talking about case 2, using the realm is indeed the right thing. I think Christian is also thinking about case 1. That said, Mike Thomas make some good points about cached credentials. Should those credentials contain any kind of signature information, they will effectively not be cacheable at all. Christian writes: > > 10.48 in bis-03 also mentions the Request-URI three lines > above the line > talking about the To header. This can be a bit confusing. Hmm. I'm honestly not even sure what those lines mean. "parameters applicable to the request-URI" is kind of vague. Henning? > > Yes, I agree this is confusing. We need a concise > definition of how to > cache > > credentials, if we want to provide support for that. I'm > not really sure > how > > to do it, since its hard to say whether a specific request > will reach a > > specific proxy. The most important case, local outbound > proxies, is easy, > > since the UAC knows that every request goes to that. I'm > not sure any > other > > proxy credential caching will be that useful. Maybe we > should limit the > > discussion to just that case? > > Yes the UAC knows that every request goes to the outbound > proxy, but if > the UAC gets a 407, how can it detect that it is from the > local outbound > proxy > and not from some other proxy in the chain? Right, I agree. This is what I'm saying about it being hard to know whether a specific request will reach a specific proxy. > > I think local outbound proxy is the special case as every request, > independent > of request-uri, will pass through it and could be challenged for proxy > authentication. > This could really mess up the credential cache with one entry > per every > request-uri, > even though we know that we probably could have used already cached > credentials. Right, so what I am saying is that we might want to only consider this case, in which case the spec says to attach credentials for the configured local outbound domain in every request, or something like that. > > Could we make use of the "domain" parameter as defined in 3.2.1 > RFC2617HttpAuth > and instead cache credentials according to the domain provided in the > challenge? Then > if the address of the local outbound proxy matched one of the > domains in the > cache we > could add the correct Proxy-Authorization header to every > request without > having > the request-407 roundtrip. This would prevent the credentials > cache from > having > an entry for each request-uri. The problem is that the address of the local outbound proxy is likely to be configured as an IP address in the UA, and the domain is not likely to be an IP address in the challenge. In any case, it just occurs to me that caching credentials for requests with differing request URIs and methods is fruitless anyway. For digest, the hash covers the request URI (albeit indirectly) and method. WIth rfc2617, it can even cover the body, which will be different in each request. So, this whole bit about caching credentials is not likely to ever be useful for local outbound proxies, or ever, in fact. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 02:15:45 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28964 for ; Sun, 3 Jun 2001 02:15:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BC91B4433A; Sun, 3 Jun 2001 02:16:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 95A4644336 for ; Sun, 3 Jun 2001 02:15:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA14563; Sun, 3 Jun 2001 02:19:31 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Jun 2001 02:15:34 -0400 Message-ID: From: Jonathan Rosenberg To: "'Baniel Uri-CUB001'" , sip@lists.bell-labs.com Subject: RE: [SIP] Invitation for a multicast session MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Jun 2001 02:15:33 -0400 > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Friday, June 01, 2001 4:31 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Invitation for a multicast session > > > My understanding is that a UAC can invite an individual or > 'the first one to > respond' from a group to a multicast session, but a UA can > not invite the > whole group by multicasting an Invite to the group. Is that true? Yes. I should have been clearer that when I talking about inviting a group, I meant that the invitation was destined for any member of the group, not all of them. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 08:59:45 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09424 for ; Sun, 3 Jun 2001 08:59:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8334344345; Sun, 3 Jun 2001 09:00:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lists.bell-labs.com (Postfix) with ESMTP id 45C6C44336 for ; Sun, 3 Jun 2001 08:59:37 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id FAA09937 for ; Sun, 3 Jun 2001 05:58:27 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id FAA24582 for ; Sun, 3 Jun 2001 05:58:27 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Sun, 3 Jun 2001 07:58:27 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E004@IL27EXM10.cig.mot.com> From: Baniel Uri-CUB001 To: "'Jonathan Rosenberg'" , sip@lists.bell-labs.com Subject: RE: [SIP] Invitation for a multicast session MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Jun 2001 07:58:26 -0500 So just to be 100% sure that I got this one right once and for all... say I like to invite A, B, C and D who belong to the same multicast group, to a conf call (mbone session). Say I like to invite them by multicast means. Do I have to multicast 4 Invites (each with a different request-URI and To fields(e.g. A@example.com, B@example.com, etc.,) or one multicast will do?? If one will do, what will be the request-URI? What will be the To? Based on your message below I think we need 4 invitations, but just to be on the safe side... ================================================================= Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; "Only by learning do we discover how ignorant we are" E.w.c ================================================================= > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, June 03, 2001 1:16 AM > To: 'Baniel Uri-CUB001'; sip@lists.bell-labs.com > Subject: RE: [SIP] Invitation for a multicast session > > > > > > > > -----Original Message----- > > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > > Sent: Friday, June 01, 2001 4:31 PM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Invitation for a multicast session > > > > > > My understanding is that a UAC can invite an individual or > > 'the first one to > > respond' from a group to a multicast session, but a UA can > > not invite the > > whole group by multicasting an Invite to the group. Is that true? > > Yes. I should have been clearer that when I talking about > inviting a group, > I meant that the invitation was destined for any member of > the group, not > all of them. > > -Jonathan R. > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 12:44:45 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10243 for ; Sun, 3 Jun 2001 12:44:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C91D44352; Sun, 3 Jun 2001 12:45:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id D47D744336 for ; Sun, 3 Jun 2001 12:44:19 -0400 (EDT) Received: from softarmor.com (localhost.localdomain [127.0.0.1]) by kevlar.softarmor.com (8.11.2/8.11.2) with ESMTP id f53GhGj01070; Sun, 3 Jun 2001 11:43:16 -0500 Message-ID: <3B1A6924.4050000@softarmor.com> From: Dean Willis User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4 i686; en-US; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: "Fairlie-Cuninghame, Robert" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] E.164 request-uri domain's. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 03 Jun 2001 11:43:16 -0500 Content-Transfer-Encoding: 7bit This is basically how the phone, proxy, and gateway connecting my desk to the PSTN work. -- Dean Fairlie-Cuninghame, Robert wrote: > Hi, > > We have had this discussion quite a few times but I thought I would > throw in a new idea. > > When building a request-uri containing an E.164 number which does not > "belong" or is associated with a particular domain name then the most > desirable action is to place a tel: URL in the outbound request-uri. > However, if a tel URL cannot be generated or received for whatever > reason, then a SIP url must be used instead and a domain name must > selected for the url. > > The easiest option is to simply place the outbound proxy/destination's > address or hostname in the host portion. Eg "sip:+12135551234@ hostname>;user=phone". I remember that some people had some academic > objections to this approach because the request-uri referred to an > "intermediate destination" rather than the final destination. I > personally believe that it is > > 1. easy to ignore the domain name for the telephone subscriber case > at a proxy (that is you simply treat a "user=phone" request-uri as > a simple telephone number (ala tel URL) if the domain name is that > of the proxy's). With the new loop detection rules I don't believe > this creates any problems. This removes the objection due to the > "intermediate destination" concept. > 2. A proxy worth the disk sectors it is written on should be able to > route a call of this form. > > Firstly, do people who previously had objections to this approach still > have their objections? > > Alternatively, for E.164 numbers what do people think about allowing > "sip:+12135551234@e164;user=phone"? e164 is the domain stem used by ENUM > for doing DNS lookups of E.164 numbers. In this case the host name of > the sip URL correctly indicates that domain of the user portion. > > Cheers, > > Robert. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 13:06:45 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10355 for ; Sun, 3 Jun 2001 13:06:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DCD64436A; Sun, 3 Jun 2001 13:07:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by lists.bell-labs.com (Postfix) with ESMTP id 6480144362 for ; Sun, 3 Jun 2001 13:06:16 -0400 (EDT) Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id NAA19821; Sun, 3 Jun 2001 13:03:15 -0400 (EDT) Subject: RE: [SIP] Invitation for a multicast session To: Baniel Uri-CUB001 Cc: "'Jonathan Rosenberg'" , sip@lists.bell-labs.com From: "Ashutosh Dutta" Message-ID: X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 06/03/2001 01:03:16 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Jun 2001 13:03:13 -0400 It would be helpful if we can use one multicast INVITE to invite the group members to an Mbone conference (which is of course can be a different multicast address), otherwise just four unicast INVITEs to join the mbone session should do the trick. Would multicasting 4 INVITEs be better than unicasting 4 INVITEs in any way? Thanks Ashutosh Baniel Uri-CUB001 on 06/03/2001 08:58:26 AM To: "'Jonathan Rosenberg'" , sip@lists.bell-labs.com cc: (bcc: Ashutosh Dutta/Telcordia) Subject: RE: [SIP] Invitation for a multicast session So just to be 100% sure that I got this one right once and for all... say I like to invite A, B, C and D who belong to the same multicast group, to a conf call (mbone session). Say I like to invite them by multicast means. Do I have to multicast 4 Invites (each with a different request-URI and To fields(e.g. A@example.com, B@example.com, etc.,) or one multicast will do?? If one will do, what will be the request-URI? What will be the To? Based on your message below I think we need 4 invitations, but just to be on the safe side... ================================================================= Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; "Only by learning do we discover how ignorant we are" E.w.c ================================================================= > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, June 03, 2001 1:16 AM > To: 'Baniel Uri-CUB001'; sip@lists.bell-labs.com > Subject: RE: [SIP] Invitation for a multicast session > > > > > > > > -----Original Message----- > > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > > Sent: Friday, June 01, 2001 4:31 PM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Invitation for a multicast session > > > > > > My understanding is that a UAC can invite an individual or > > 'the first one to > > respond' from a group to a multicast session, but a UA can > > not invite the > > whole group by multicasting an Invite to the group. Is that true? > > Yes. I should have been clearer that when I talking about > inviting a group, > I meant that the invitation was destined for any member of > the group, not > all of them. > > -Jonathan R. > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:03:47 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13413 for ; Sun, 3 Jun 2001 22:03:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E586744337; Sun, 3 Jun 2001 22:04:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 5EF1C44394; Fri, 1 Jun 2001 20:33:44 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01068; Fri, 1 Jun 2001 17:32:34 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28416 for corey@hearme.com; Fri, 1 Jun 2001 17:31:45 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09027 for ; Thu, 31 May 2001 06:17:31 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12911 for ; Thu, 31 May 2001 06:17:29 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06115; Thu, 31 May 2001 09:16:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00835 for ; Wed, 30 May 2001 19:39:29 -0400 (EDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27486; Wed, 30 May 2001 19:39:09 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4UNdHZ03453; Wed, 30 May 2001 16:39:17 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA13198; Wed, 30 May 2001 23:39:17 GMT Message-Id: <200105302339.XAA13198@gra.isi.edu> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU, rrroy@att.com Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM X-Sun-Charset: US-ASCII X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: text Subject: [SIP] [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 30 May 2001 23:39:17 GMT *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:05:19 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13425 for ; Sun, 3 Jun 2001 22:05:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5377044357; Sun, 3 Jun 2001 22:04:20 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 61FDD44336; Fri, 1 Jun 2001 20:35:23 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01087; Fri, 1 Jun 2001 17:33:23 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28433 for corey@hearme.com; Fri, 1 Jun 2001 17:32:34 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09029 for ; Thu, 31 May 2001 06:17:33 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12913 for ; Thu, 31 May 2001 06:17:30 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06184; Thu, 31 May 2001 09:17:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05686 for ; Thu, 31 May 2001 09:10:49 -0400 (EDT) Received: from ckmso1.proxy.att.com ([12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23528; Thu, 31 May 2001 09:10:29 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VD8wC16127; Thu, 31 May 2001 09:08:58 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id JAA04890; Thu, 31 May 2001 09:08:30 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 09:08:52 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 09:08:45 -0400 Hi, Bob: All applications (e.g., H.323, SIP) uses signaling messages among its functional entities (e.g., terminal, agents, gatekeepers, proxies, gateways) for communications. The signaling messages that carry QOS parameters are treated as QOS signaling messages. The applications like SIP and H.323 send signaling messages end-to-end. H.323 uses H.225.0 RAS, Q.931, Annex G, and H.245 signaling protocols. SIP also uses SDP as a part of the signaling messages. The signaling messages that carry QOS related information can be treated as "End-to-End QOS signaling" messages. Kindly see the ongoing works of Q.F/16 of SG16. This will provide more information related to your questions. Hope this helps. Best regards, Radhika R. Roy -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: Wednesday, May 30, 2001 7:39 PM To: gratta@lucent.com; sob@harvard.edu; mankin@ISI.EDU; Roy, Radhika R, ALCTA Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:07:20 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13436 for ; Sun, 3 Jun 2001 22:07:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 23C864436A; Sun, 3 Jun 2001 22:04:35 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id BBF5044336; Fri, 1 Jun 2001 20:36:34 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01110; Fri, 1 Jun 2001 17:34:44 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28443 for corey@hearme.com; Fri, 1 Jun 2001 17:33:23 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09035 for ; Thu, 31 May 2001 06:17:37 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA12919 for ; Thu, 31 May 2001 06:17:35 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06076; Thu, 31 May 2001 09:16:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28632 for ; Wed, 30 May 2001 18:31:19 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26407; Wed, 30 May 2001 18:30:53 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4UMUBU11655; Wed, 30 May 2001 15:30:11 -0700 (PDT) Message-Id: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: gratta@lucent.com From: Fred Baker Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <200105302022.QAA03855@hotair.hobl.lucent.com> Mime-Version: 1.0 X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] [Sipping] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 30 May 2001 15:30:00 -0700 Greg: The URLs in this note were all sent with what the ETSI machine considered to be 'malformed syntax'. Could you resend the correct URLs? Fred _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:09:21 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13453 for ; Sun, 3 Jun 2001 22:09:21 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E8C8B4437D; Sun, 3 Jun 2001 22:04:45 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 7E66744336 for ; Fri, 1 Jun 2001 20:37:09 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01124; Fri, 1 Jun 2001 17:35:23 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28459 for corey@hearme.com; Fri, 1 Jun 2001 17:34:44 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id GAA09461 for ; Thu, 31 May 2001 06:56:39 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id GAA13482 for ; Thu, 31 May 2001 06:56:38 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13753; Thu, 31 May 2001 09:53:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07127 for ; Thu, 31 May 2001 09:37:09 -0400 (EDT) Received: from cs.columbia.edu ([128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23499; Thu, 31 May 2001 09:09:56 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA08634; Thu, 31 May 2001 09:10:02 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id JAA05564; Thu, 31 May 2001 09:10:00 -0400 (EDT) Message-ID: <3B16426D.F7BADA0A@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Mainwaring Cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, new-work@ietf.org, sip@lists.bell-labs.com, sipping@ietf.org, Yukio Hiramatsu , steve.norreys@bt.com, tsg11q6@ties.itu.ch, tsg11q11@ties.itu.ch References: <4.3.2.7.2.20010531095312.00b67270@nordic.cisco.com> Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset=us-ascii Subject: [SIP] Re: [Sipping] Re: Initiation of work on interworking of BICC and ISUP withSIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 09:09:01 -0400 Content-Transfer-Encoding: 7bit Also, I assume that the relevant parties are aware of the IETF efforts in SIP-to-ISUP interworking (draft-ietf-sip-isup, et al.). The message below does not seem to indicate this ("would look to the ITU-T to develop interworking signalling requirements and protocols.") Keith Mainwaring wrote: > > I should just like to clarify the background to this "message". It was > generated in the final minutes of the SG 11 closing plenary after > completion of working party reports and liaison statements when many > delegates, myself included, had left for the airport and not during > the discussions of Questions 6, 9 and 11. With regard to the final > paragraph, there was no agreement during the joint question 6 and 9 > activity on SIP interworking that SG 11 would work on identifying > requirements for extensions to SIP. The second sentence of the first > paragraph also presumes too much. > > Keith Mainwaring, Q6/11 Rapporteur. > > At 16:22 30/05/2001 -0400, Greg Ratta wrote: > > > This message was agreed to at ITU-T Study Group 11 meeting (Geneva, > > May 2001) and is being transmitted on behalf of Yukio Hiramatsu, > > Chairman of ITU-T SG 11. For further technical clarification, > > contact the Rapporteur for Q6/11 (Keith Mainwaring, Tel: + 46 70 605 > > 9076, { HYPERLINK mailto:rburke@lucent.com }kmainwar@cisco.com{ > > HYPERLINK mailto:kmainwar@cisco.com }) or the Rapporteur for Q11/11 > > (Steve Norreys, Tel: +44 207 843 5189, steve.norreys@bt.com). > > > > ITU-T Study Group 11 has initiated a work program to define > > signalling requirements for the interworking of SIP with BICC > > (Bearer Independent Call Control) and with ISUP (ISDN User Part of > > Signalling System 7). It is the understanding of SG11 that the IETF > > will continue to focus its energy on SIP protocol development and > > would look to the ITU-T to develop interworking signalling > > requirements and protocols. > > > > SG 11 has scheduled three meetings before February 2002 to advance > > its efforts in this subject. A strong consensus exists among the > > participants of this Study Group that a common approach should be > > taken for both BICC and ISUP. > > > > SG 11 plans to keep the IETF informed of any requirements for > > extensions to SIP that may develop from its studies and looks > > forward to further communications as this study progresses. > > > > > > > > Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols > > > > Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com > > _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:11:26 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13527 for ; Sun, 3 Jun 2001 22:11:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5B1E84438B; Sun, 3 Jun 2001 22:04:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id B28A644336; Fri, 1 Jun 2001 20:38:10 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01176; Fri, 1 Jun 2001 17:37:00 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28488 for corey@hearme.com; Fri, 1 Jun 2001 17:36:01 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09651 for ; Thu, 31 May 2001 07:10:47 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13698 for ; Thu, 31 May 2001 07:10:45 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 262ED44358; Thu, 31 May 2001 10:07:12 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id 789E544336; Wed, 30 May 2001 17:23:12 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4ULLMD18676; Wed, 30 May 2001 17:21:22 -0400 (EDT) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id RAA19071; Wed, 30 May 2001 17:20:06 -0400 (EDT) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 May 2001 17:21:20 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 30 May 2001 17:21:14 -0400 Hi, Everyone: Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards for "End-to-End QOS for Multimedia Applications". Contributions are also being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 meeting. Applications like H.323, SIP, H.324, H.310, and others will also be able to use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be able to use this when specs are fully developed and, TIPHON's QOS mechanisms can also be used as one of the mechanisms for implementations. BICC and MEGCAO/H.248 are only used as the protocol between the gateways, NOT end-to-end (although SIP/H.323 or other protocols may be used between the gateways). The "End-to-End QOS for Multimedia Applications" of SG16 can also be termed as "Application Layer QOS." Q.F/16's end-to-end application layer QOS can also be implemented over the network layer QOS like RSVP, DiffServe, and/or MPLS after proper mapping. Similar is the case for the ATM network. Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS) may or may not have the end-to-end significance. For example, an IP network may implement different QOS schemes in different domains (e.g., RVSP in one domain, DiffServ in another domain). However, the application layer QOS is end-to-end that remains the same. For example, an H.323 or SIP call that can traverse several IP domains where each domain may implement its own network layer QOS schemes while the H.323/SIP call carry the signaling messages and QOS parameters end-to-end independent of the underlying network layer QOS mechanisms. Let us work together. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Greg Ratta [mailto:gratta@lucent.com] Sent: Wednesday, May 30, 2001 4:22 PM To: sob@harvard.edu; mankin@isi.edu Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; Yukio Hiramatsu; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch Subject: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES General Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. Proposals on end-to-end QoS service control It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. Proposals on IP QoS classes and IP Transfer Capabilities ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. The ETSI specifications referenced as base material are available at the following URLs: ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p Further information about the ETSI TIPHON project is available at the following URL: - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON __________________ BICC CS3 signalling requirements for end-to- end QoS service control EDITORS' NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups 1 Rationale The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. 2 Framework for end-to-end QoS service control and network QoS control. A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). 1) Call-control a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. 2) Vertical control a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. 3) Bearer control a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way. 4) Bearer a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. 3 QoS information flows applicable to BICC A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. 4 Q.BICC related QoS primitives and parameters The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. 4.1 Q.BICC related QoS primitives This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers. Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1. Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. 4.2 Q.BICC related QoS parameters Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control Qbicc.QoSreq QoS Service Class Optional Codec Type and Packetisation Mandatory Transport QoS Parameters Mandatory Traffic Descriptor Optional Transport Addresses Mandatory Application Data Transport Protocol Optional [Default RTP] Packet Transport Protocol Optional [Default UDP] QoS Mechanism Optional Qbicc.QoSconf QoS Service Class Optional Codec Type and Packetisation Mandatory Transport QoS Parameters Mandatory Transport Addresses Mandatory Application Data Transport Protocol Optional [Default RTP] Packet Transport Protocol Optional [Default UDP] Qbicc.QoSrej Reason [TBD] Mandatory 5 Q.CBC related QoS primitives and parameters The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. 5.1 Q.CBC related QoS primitives This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource. NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource. NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow. NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow. NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. 5.2 Q.CBC related QoS parameters Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control QT2.TRMQreq Transport QoS Parameters Mandatory Traffic Descriptor Mandatory Transport Addresses Mandatory Packet Transport Protocol Optional [Default UDP] QT2.TRMQconf Transport QoS Parameters Mandatory Transport Addresses Mandatory Packet Transport Protocol Optional [Default UDP] QoS Mechanism Optional QT2.TRMQrej Reason [TBD] Mandatory 6 Parameter contents Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. Table 3: Identification of parameter contents for end-to-end QoS service control QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium class of a beareror Best Effort Transport QoS Specifies the QoS characteristics Maximum Delay Parameters required of the transport flow carrying the media flow. Maximum Packet Delay Variation Maximum Packet Loss Traffic Descriptor Characterises the resource Peak Bit requirements of an application data flow (excludes transport flow Maximum Packet Size resource requirements). Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] Maximum bit rate (bit/s) of the media flow. Maximum size of the media packets 7 Information flows and signalling procedures for end-to-end QoS service control EDITORS' NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:13:32 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13541 for ; Sun, 3 Jun 2001 22:13:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 017724439B; Sun, 3 Jun 2001 22:05:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id C5D5244336; Fri, 1 Jun 2001 20:38:32 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01148; Fri, 1 Jun 2001 17:36:30 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28465 for corey@hearme.com; Fri, 1 Jun 2001 17:35:23 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09618 for ; Thu, 31 May 2001 07:07:47 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13655 for ; Thu, 31 May 2001 07:07:46 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1299A44340; Thu, 31 May 2001 10:07:05 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 194AD4433C for ; Wed, 30 May 2001 16:50:45 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed May 30 16:46:04 EDT 2001 Received: by lists.bell-labs.com (Postfix) id ED5254437D; Wed, 30 May 2001 16:22:27 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2]) by lists.bell-labs.com (Postfix) with SMTP id 0575844384; Wed, 30 May 2001 16:22:26 -0400 (EDT) Received: from 7460gratta.ho.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA03855; Wed, 30 May 2001 16:22:23 -0400 Message-Id: <200105302022.QAA03855@hotair.hobl.lucent.com> From: "Greg Ratta" To: sob@harvard.edu, mankin@isi.edu MIME-Version: 1.0 Content-transfer-encoding: Quoted-printable Reply-To: gratta@lucent.com Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch Priority: normal X-mailer: Pegasus Mail for Win32 (v3.01d) X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text/enriched; charset=ISO-8859-1 Subject: [SIP] [IPTEL] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 30 May 2001 16:22:23 -0400 Content-Transfer-Encoding: Quoted-printable This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) FULL TITLE: Times New RomanPROPOSED JOINT ACTI= VITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND 0100,0100,0100SIGNALLING PROTOCOL DEVELO= PMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES rightCourier NewGene= ral rightWithin ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. rightIt was noted that also QoS related work is= in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. rightProposals on end-to-end QoS service contro= l rightIt is proposed to start a joint activity w= ith IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: right- Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. right- The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. right- The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. right- The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. rightProposals on IP QoS classes and IP Transfe= r Capabilities rightITU-T SG11 would like to inform IETF that = it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. rightATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. rightThe ETSI specifications referenced as base= material are available at the following URLs: outETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc right- ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p rightFurther information about the ETSI TIPHON project is available at the following URL: right- http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=3D291&TB_NAME=3DTIPHON right__________________ rightBICC CS3 signalling requirements for end-t= o- end QoS service control rightEDITORS=92 NOTE: This requirements text fo= r end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups right1 Rationale rightThe rationale of the BICC CS3 requirements= for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine rightthe perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. right rightA second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. right rightTherefore end-to-end QoS service control a= t the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. right2 Framework for end-to-end QoS service control and network QoS control. rightA framework for QoS control may be conside= red at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). right1) Call-control righta) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. rightThe idea is that call control protocols ar= e enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). rightSuch a generic end-to-end QoS service cont= rol mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). rightb) BICC (Q.190x) is one of the call contro= l protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. right2) Vertical control righta) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. rightThese QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. rightb) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. right3) Bearer control righta) Network QoS is negotiated/communicated = at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. rightThe idea is that bearer control protocols = for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. rightb) IP BCP (Q.1970) is an IP bearer control= protocol that may be enhanced this way. right4) Bearer righta) Network QoS is negotiated/communicated = at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. rightb) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. right right3 QoS information flows applicable to BICC= rightA general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. right rightSection 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. right4 Q.BICC related QoS primitives and parame= ters rightThe Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. right4.1 Q.BICC related QoS primitives rightThis information flow (QC2 in ETSI TS 101 = 329 part 3) communicates the QoS related bearer information between the domains of different service providers. rightQ.BICC QoS request (Qbicc.QoSreq) requests= the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. rightNOTE Identical to QoSM request (QC2.QoSMre= q) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. rightNOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC QoS reject (Qbicc.QoSrej) rejects t= he creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. rightNOTE Identical to QoSM reject (QC2.QoSMrej= ) in ETSI TS 101 329 part 3 clause 8.1.1. rightQ.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. rightNOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. rightQoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. rightNOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. right4.2 Q.BICC related QoS parameters rightTable 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. rightNOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. rightTable 1: Identification of Q.BICC related parameters for end-to-end QoS service control rightQbicc.QoSreq QoS Service Class Optional right Codec Type and Packetisation Mandatory right Transport QoS Parameters Mandatory right Traffic Descriptor Optional right Transport Addresses Mandatory right Application Data Transport Protocol Optional [Default RTP] right Packet Transport Protocol Optional [Default UDP] right QoS Mechanism Optional rightQbicc.QoSconf QoS Service Class Optional right Codec Type and Packetisation Mandatory right Transport QoS Parameters Mandatory right Transport Addresses Mandatory right Application Data Transport Protocol Optional [Default RTP] right Packet Transport Protocol Optional [Default UDP] rightQbicc.QoSrej Reason [TBD] Mandatory right5 Q.CBC related QoS primitives and paramet= ers rightThe Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. right5.1 Q.CBC related QoS primitives rightThis information flow (QT2 in ETSI TS 101 = 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. rightQ.CBC QoS request (Qcbc.QoSreq) requests t= he establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS confirm (Qcbc.QoSconf) acknowled= ges the creation of a requested transport flow or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS reject (Qcbc.QoSrej) rejects the= creation of a requested transport flow or the reservation of Transport Domain resource. rightNOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. rightQ.CBC QoS release request (Qcbc.QoSrelreq)= requests the release of a transport flow. rightNOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. rightQ.CBC QoS release confirm (Qcbc.QoSrelconf= ) confirms the release of a transport flow. rightNOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. rightQ.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. rightNOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. right5.2 Q.CBC related QoS parameters rightTable 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. rightNOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. rightTable 2: Identification of Q.CBC related parameters for end-to-end QoS service control rightQT2.TRMQreq Transport QoS Parameters Mandatory right Traffic Descriptor Mandatory right Transport Addresses Mandatory right Packet Transport Protocol Optional [Default UDP] rightQT2.TRMQconf Transport QoS Parameters Mandatory right Transport Addresses Mandatory right Packet Transport Protocol Optional [Default UDP] right QoS Mechanism Optional rightQT2.TRMQrej Reason [TBD] Mandatory right6 Parameter contents rightTable 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. rightTable 3: Identification of parameter conte= nts for end-to-end QoS service control rightQoS Service Class Describes the end-to-end= ETSI TIPHON Best, High, Medium right class of a bearer or Best Effort rightTransport QoS Specifies the QoS characteristics Maximum Delay rightParameters required of the transport flow= right carrying the media flow. Maximum Packet Delay Variation right Maximum Packet Loss rightTraffic Descriptor Characterises the resource Peak Bit right requirements of an application data right flow (excludes transport flow Maximum Packet Size right resource requirements). rightParameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 rightThe maximum delay permitted (ms) over eith= er a segment of the transport flow or the remaining part of the transport flow. rightThe maximum packet delay variation permitt= ed (ms) over either a segment of the transport flow or the remaining part of the transport flow. rightThe maximum packet loss permitted (%) over= either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] rightMaximum bit rate (bit/s) of the media flow= . rightMaximum size of the media packets right7 Information flows and signalling procedu= res for end-to-end QoS service control rightEDITORS=92 NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protoc= ols Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:15:49 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13563 for ; Sun, 3 Jun 2001 22:15:49 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 02CC5443A5; Sun, 3 Jun 2001 22:05:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id BCA6444336; Fri, 1 Jun 2001 20:39:35 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01211; Fri, 1 Jun 2001 17:37:49 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28511 for corey@hearme.com; Fri, 1 Jun 2001 17:37:00 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09729 for ; Thu, 31 May 2001 07:19:04 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13804 for ; Thu, 31 May 2001 07:19:04 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0729444392; Thu, 31 May 2001 10:07:19 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 6CA7044336; Wed, 30 May 2001 18:31:17 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4UMUBU11655; Wed, 30 May 2001 15:30:11 -0700 (PDT) Message-Id: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: gratta@lucent.com From: Fred Baker Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <200105302022.QAA03855@hotair.hobl.lucent.com> Mime-Version: 1.0 X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] [IPTEL] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 30 May 2001 15:30:00 -0700 Greg: The URLs in this note were all sent with what the ETSI machine considered to be 'malformed syntax'. Could you resend the correct URLs? Fred _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:17:36 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13574 for ; Sun, 3 Jun 2001 22:17:35 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9B07A443CE; Sun, 3 Jun 2001 22:05:39 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 618B944336; Fri, 1 Jun 2001 20:41:23 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01242; Fri, 1 Jun 2001 17:39:53 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28538 for corey@hearme.com; Fri, 1 Jun 2001 17:38:42 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09857 for ; Thu, 31 May 2001 07:34:35 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13986 for ; Thu, 31 May 2001 07:34:34 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CBDDA443B7; Thu, 31 May 2001 10:07:29 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 6A90144336; Thu, 31 May 2001 09:10:54 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VD8wC16127; Thu, 31 May 2001 09:08:58 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id JAA04890; Thu, 31 May 2001 09:08:30 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 09:08:52 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 09:08:45 -0400 Hi, Bob: All applications (e.g., H.323, SIP) uses signaling messages among its functional entities (e.g., terminal, agents, gatekeepers, proxies, gateways) for communications. The signaling messages that carry QOS parameters are treated as QOS signaling messages. The applications like SIP and H.323 send signaling messages end-to-end. H.323 uses H.225.0 RAS, Q.931, Annex G, and H.245 signaling protocols. SIP also uses SDP as a part of the signaling messages. The signaling messages that carry QOS related information can be treated as "End-to-End QOS signaling" messages. Kindly see the ongoing works of Q.F/16 of SG16. This will provide more information related to your questions. Hope this helps. Best regards, Radhika R. Roy -----Original Message----- From: Bob Braden [mailto:braden@ISI.EDU] Sent: Wednesday, May 30, 2001 7:39 PM To: gratta@lucent.com; sob@harvard.edu; mankin@ISI.EDU; Roy, Radhika R, ALCTA Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:18:54 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13585 for ; Sun, 3 Jun 2001 22:18:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E3E5B4440D; Sun, 3 Jun 2001 22:06:09 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 288AF44336; Fri, 1 Jun 2001 20:50:24 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01477; Fri, 1 Jun 2001 17:49:04 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28692 for corey@hearme.com; Fri, 1 Jun 2001 17:48:05 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12283 for ; Thu, 31 May 2001 10:20:10 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16829 for ; Thu, 31 May 2001 10:20:09 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24344; Thu, 31 May 2001 13:19:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24030 for ; Thu, 31 May 2001 13:12:24 -0400 (EDT) Received: from sj-msg-core-4.cisco.com ([171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02436; Thu, 31 May 2001 13:12:02 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4VHBBU27133; Thu, 31 May 2001 10:11:12 -0700 (PDT) Message-Id: <5.1.0.14.2.20010531095817.04c50ea8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: "Roy, Radhika R, ALCTA" From: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM In-Reply-To: Mime-Version: 1.0 X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 10:09:10 -0700 At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:22:45 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13611 for ; Sun, 3 Jun 2001 22:22:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E61CC4442C; Sun, 3 Jun 2001 22:06:28 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id C3B3444336; Fri, 1 Jun 2001 20:51:59 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01527; Fri, 1 Jun 2001 17:50:42 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28732 for corey@hearme.com; Fri, 1 Jun 2001 17:50:03 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12742 for ; Thu, 31 May 2001 10:40:20 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16681 for ; Thu, 31 May 2001 10:12:15 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23823; Thu, 31 May 2001 13:08:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18138 for ; Thu, 31 May 2001 11:14:09 -0400 (EDT) Received: from prue.eim.surrey.ac.uk (IDENT:exim@prue.eim.surrey.ac.uk [131.227.76.5]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28182; Thu, 31 May 2001 11:13:46 -0400 (EDT) Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 155U91-00045U-00; Thu, 31 May 2001 16:13:51 +0100 From: Lloyd Wood X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Fred Baker Cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/ X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] [Sipping] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 16:13:43 +0100 (BST) On Wed, 30 May 2001, Fred Baker wrote: > Greg: > > The URLs in this note were all sent with what the ETSI machine considered > to be 'malformed syntax'. Could you resend the correct URLs? Just put all the parts together, removing unencoded spaces; the reason for the breaks after the hyphens seems obvious enough, but I'm at a loss to explain others. Here we go: http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt So http://docbox.etsi.org/ is passworded but docs can be retrieved by advertised public direct url? Bizarre. L. PGP _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:22:51 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13623 for ; Sun, 3 Jun 2001 22:22:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 49A50443F7; Sun, 3 Jun 2001 22:06:00 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 560FC44336; Fri, 1 Jun 2001 20:50:00 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01442; Fri, 1 Jun 2001 17:48:05 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28684 for corey@hearme.com; Fri, 1 Jun 2001 17:46:24 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12193 for ; Thu, 31 May 2001 10:16:21 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16755 for ; Thu, 31 May 2001 10:16:20 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0515B443E1; Thu, 31 May 2001 13:14:13 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id 55964443C5; Thu, 31 May 2001 12:12:00 -0400 (EDT) Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 May 2001 17:11:33 +0100 To: Lloyd Wood Cc: Fred Baker , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org, J.Crowcroft@cs.ucl.ac.uk In-reply-to: Your message of "Thu, 31 May 2001 16:13:43 BST." Message-ID: <922.991325489@cs.ucl.ac.uk> From: Jon Crowcroft X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text Subject: [SIP] [IPTEL] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 17:11:29 +0100 so the talk seems to be dated dec 2001, and makes me wonder if the tiphon folks have achieved a breakthru in QOS with e2e delays better than 0ms..... meanwhile, i stuck html versions of the files below at ftp://cs.ucl.ac.uk/darpa/tiphon/ (prob. doesnt help non windoze users since the html is generated by office 2000 apps so unless you have the unix internet explorer, too bad) In message , Lloyd Wood typed: >>On Wed, 30 May 2001, Fred Baker wrote: >> >>> Greg: >>> >>> The URLs in this note were all sent with what the ETSI machine considered >>> to be 'malformed syntax'. Could you resend the correct URLs? >> >>Just put all the parts together, removing unencoded >>spaces; the reason for the breaks after the hyphens seems >>obvious enough, but I'm at a loss to explain others. Here we go: >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip >> >>http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt >> >>So http://docbox.etsi.org/ is passworded but docs can be retrieved by >>advertised public direct url? Bizarre. >> >>L. >> >>PGP >> >> >> >> >> >> >> cheers jon _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:23:52 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13637 for ; Sun, 3 Jun 2001 22:23:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 83348443BA; Sun, 3 Jun 2001 22:05:29 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 5B91A44336; Fri, 1 Jun 2001 20:39:48 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01217; Fri, 1 Jun 2001 17:38:28 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28532 for corey@hearme.com; Fri, 1 Jun 2001 17:37:49 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id HAA09779 for ; Thu, 31 May 2001 07:25:19 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id HAA13879 for ; Thu, 31 May 2001 07:25:18 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B28F3443AB; Thu, 31 May 2001 10:07:24 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lists.bell-labs.com (Postfix) with ESMTP id B9C0B44336; Wed, 30 May 2001 19:39:31 -0400 (EDT) Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f4UNdHZ03453; Wed, 30 May 2001 16:39:17 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA13198; Wed, 30 May 2001 23:39:17 GMT Message-Id: <200105302339.XAA13198@gra.isi.edu> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU, rrroy@att.com Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM X-Sun-Charset: US-ASCII X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text Subject: [SIP] [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 30 May 2001 23:39:17 GMT *> From owner-issll@mercury.lcs.mit.edu Wed May 30 14:59:58 2001 *> From: "Roy, Radhika R, ALCTA" *> To: gratta@lucent.com, sob@harvard.edu, mankin@ISI.EDU *> Cc: diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, *> megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, *> Yukio Hiramatsu *> , rbuhrke@lucent.com, *> tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM *> Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E *> ND-TO-END QOS SERVICE CONTROL *> Date: Wed, 30 May 2001 17:21:14 -0400 *> MIME-Version: 1.0 *> *> Hi, Everyone: *> *> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards *> for "End-to-End QOS for Multimedia Applications". Contributions are also *> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001 *> meeting. This is very confusing. "End-to-End QOS for Multimedia Applications" is an really important topic, but this topic must be a superset of "End-to-End QOS signaling". There are much harder problems than signaling in providing E2E QoS. Can you explain how signaling relates to the title of this working party? Thanks, Bob Braden *> *> Applications like H.323, SIP, H.324, H.310, and others will also be able to *> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be *> able to use this when specs are fully developed and, TIPHON's QOS mechanisms *> can also be used as one of the mechanisms for implementations. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:25:47 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13652 for ; Sun, 3 Jun 2001 22:25:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 087C24441B; Sun, 3 Jun 2001 22:06:18 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 93BFB44336; Fri, 1 Jun 2001 20:51:30 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01500; Fri, 1 Jun 2001 17:50:03 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28712 for corey@hearme.com; Fri, 1 Jun 2001 17:49:04 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12310 for ; Thu, 31 May 2001 10:21:02 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16857 for ; Thu, 31 May 2001 10:21:01 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2574A443FC; Thu, 31 May 2001 13:14:18 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 21E354434B; Thu, 31 May 2001 13:12:28 -0400 (EDT) Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4VHBBU27133; Thu, 31 May 2001 10:11:12 -0700 (PDT) Message-Id: <5.1.0.14.2.20010531095817.04c50ea8@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: "Roy, Radhika R, ALCTA" From: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM In-Reply-To: Mime-Version: 1.0 X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 10:09:10 -0700 At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:29:31 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13674 for ; Sun, 3 Jun 2001 22:29:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 31F97443DE; Sun, 3 Jun 2001 22:05:50 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 34A3644336; Fri, 1 Jun 2001 20:47:41 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01431; Fri, 1 Jun 2001 17:46:24 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28669 for corey@hearme.com; Fri, 1 Jun 2001 17:45:13 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12157 for ; Thu, 31 May 2001 10:14:38 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16731 for ; Thu, 31 May 2001 10:14:37 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 35C504434B; Thu, 31 May 2001 13:14:05 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by lists.bell-labs.com (Postfix) with ESMTP id 47E5B443C5; Thu, 31 May 2001 12:06:44 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA34990; Thu, 31 May 2001 09:04:55 -0700 Received: from hursley.ibm.com ([9.29.3.174]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20120; Thu, 31 May 2001 09:04:54 -0700 Message-ID: <3B166AFC.9DF4CD05@hursley.ibm.com> From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: gratta@lucent.com Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch References: <200105302022.QAA03855@hotair.hobl.lucent.com> X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nodserv.hearme.com id KAA12157 Content-Type: text/plain; charset=iso-8859-1 Subject: [SIP] [IPTEL] Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 11:02:04 -0500 Content-Transfer-Encoding: 8bit Folks, This is *not* a discussion item for the diffserv WG mailing list. This WG is not chartered to discuss signalling issues. Whether the ITU should work on this and if so how it should collaborate with the IETF should be discussed at liaison level, not on a list with a few hundred people. So please everybody drop this discussion on the diffserv list and continue elswhere. Regards Brian Carpenter diffserv co-chair Greg Ratta wrote: > > This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) > > FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES > > General > > Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. > > It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. > > Proposals on end-to-end QoS service control > > It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: > > - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. > > - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. > > - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. > > - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. > > Proposals on IP QoS classes and IP Transfer Capabilities > > ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. > > ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. > > The ETSI specifications referenced as base material are available at the following URLs: > > ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc > > - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p > > Further information about the ETSI TIPHON project is available at the following URL: > > - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON > __________________ > > BICC CS3 signalling requirements for end-to- end QoS service control > > EDITORS’ NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups > > 1 Rationale > > The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine > the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. > > A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. > > Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. > > 2 Framework for end-to-end QoS service control and network QoS control. > > A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). > > 1) Call-control > > a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. > > The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). > > Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). > > b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. > > 2) Vertical control > > a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. > > These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. > > b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. > > 3) Bearer control > > a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. > > The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. > > b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way. > > 4) Bearer > > a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. > > b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. > > 3 QoS information flows applicable to BICC > > A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. > > Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. > > 4 Q.BICC related QoS primitives and parameters > > The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 4.1 Q.BICC related QoS primitives > > This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers. > > Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. > > NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. > > NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. > > NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > 4.2 Q.BICC related QoS parameters > > Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. > > NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. > > Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control > Qbicc.QoSreq QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Traffic Descriptor Optional > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > Qbicc.QoSconf QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > Qbicc.QoSrej Reason [TBD] Mandatory > > 5 Q.CBC related QoS primitives and parameters > > The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 5.1 Q.CBC related QoS primitives > > This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. > > Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow. > > NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow. > > NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. > > NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. > > 5.2 Q.CBC related QoS parameters > > Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. > > NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. > > Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control > > QT2.TRMQreq Transport QoS Parameters Mandatory > > Traffic Descriptor Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QT2.TRMQconf Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > QT2.TRMQrej Reason [TBD] Mandatory > > 6 Parameter contents > > Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. > > Table 3: Identification of parameter contents for end-to-end QoS service control > > QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium > class of a bearer or Best Effort > > Transport QoS Specifies the QoS characteristics Maximum Delay > Parameters required of the transport flow > carrying the media flow. Maximum Packet Delay Variation > > Maximum Packet Loss > > Traffic Descriptor Characterises the resource Peak Bit > requirements of an application data > flow (excludes transport flow Maximum Packet Size > resource requirements). > > Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 > > The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] > Maximum bit rate (bit/s) of the media flow. > > Maximum size of the media packets > > 7 Information flows and signalling procedures for end-to-end QoS service control > > EDITORS’ NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. > > Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols > Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:30:28 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13901 for ; Sun, 3 Jun 2001 22:30:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F0DC544435; Sun, 3 Jun 2001 22:06:37 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id D5FD34442C; Fri, 1 Jun 2001 20:53:21 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01578; Fri, 1 Jun 2001 17:51:36 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28745 for corey@hearme.com; Fri, 1 Jun 2001 17:50:42 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12744 for ; Thu, 31 May 2001 10:40:27 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16683 for ; Thu, 31 May 2001 10:12:15 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23907; Thu, 31 May 2001 13:08:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21446 for ; Thu, 31 May 2001 12:11:54 -0400 (EDT) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00447; Thu, 31 May 2001 12:11:31 -0400 (EDT) Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 31 May 2001 17:11:33 +0100 To: Lloyd Wood Cc: Fred Baker , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org, J.Crowcroft@cs.ucl.ac.uk In-reply-to: Your message of "Thu, 31 May 2001 16:13:43 BST." Message-ID: <922.991325489@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: text Subject: [SIP] [Sipping] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 17:11:29 +0100 so the talk seems to be dated dec 2001, and makes me wonder if the tiphon folks have achieved a breakthru in QOS with e2e delays better than 0ms..... meanwhile, i stuck html versions of the files below at ftp://cs.ucl.ac.uk/darpa/tiphon/ (prob. doesnt help non windoze users since the html is generated by office 2000 apps so unless you have the unix internet explorer, too bad) In message , Lloyd Wood typed: >>On Wed, 30 May 2001, Fred Baker wrote: >> >>> Greg: >>> >>> The URLs in this note were all sent with what the ETSI machine considered >>> to be 'malformed syntax'. Could you resend the correct URLs? >> >>Just put all the parts together, removing unencoded >>spaces; the reason for the breaks after the hyphens seems >>obvious enough, but I'm at a loss to explain others. Here we go: >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip >> >>http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON >> >>http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt >> >>So http://docbox.etsi.org/ is passworded but docs can be retrieved by >>advertised public direct url? Bizarre. >> >>L. >> >>PGP >> >> >> >> >> >> >> cheers jon _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:30:28 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13905 for ; Sun, 3 Jun 2001 22:30:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 45DC24443E; Sun, 3 Jun 2001 22:06:47 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 2C96544412; Fri, 1 Jun 2001 20:53:52 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01598; Fri, 1 Jun 2001 17:52:26 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28774 for corey@hearme.com; Fri, 1 Jun 2001 17:51:37 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id KAA12873 for ; Thu, 31 May 2001 10:44:35 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id KAA16691 for ; Thu, 31 May 2001 10:12:29 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23860; Thu, 31 May 2001 13:08:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21135 for ; Thu, 31 May 2001 12:06:43 -0400 (EDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00226; Thu, 31 May 2001 12:06:20 -0400 (EDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id JAA34990; Thu, 31 May 2001 09:04:55 -0700 Received: from hursley.ibm.com ([9.29.3.174]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA20120; Thu, 31 May 2001 09:04:54 -0700 Message-ID: <3B166AFC.9DF4CD05@hursley.ibm.com> From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: gratta@lucent.com Cc: sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch References: <200105302022.QAA03855@hotair.hobl.lucent.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA21136 X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset=iso-8859-1 Subject: [SIP] [Sipping] Re: [Diffserv] PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 11:02:04 -0500 Content-Transfer-Encoding: 8bit Folks, This is *not* a discussion item for the diffserv WG mailing list. This WG is not chartered to discuss signalling issues. Whether the ITU should work on this and if so how it should collaborate with the IETF should be discussed at liaison level, not on a list with a few hundred people. So please everybody drop this discussion on the diffserv list and continue elswhere. Regards Brian Carpenter diffserv co-chair Greg Ratta wrote: > > This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of ITU-T SG 11. For further technical clarification, contact the Rapporteur for Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK mailto:rburke@lucent.com }rbuhrke@lucent.com) > > FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON IP TRANSFER CAPABILITIES AND IP QOS CLASSES > > General > > Within ITU-T SG11 work has started on requirements for a generic protocol mechanism for end-to-end QoS service control. It was agreed within SG11 to proceed with this work utilising deliverables of ETSI TIPHON on end- to-end QoS service control as base material. It is the opinion of SG11 that this generic protocol mechanism for BICC intends to apply also to other protocols like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO protocol. > > It was noted that also QoS related work is in progress in IETF. Please find attached an initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. Please note the rationale for this activity and the framework for end-to-end QoS service control and network QoS control. The framework illustrates the field of application of the QoS handling at different levels and the different protocols involved. > > Proposals on end-to-end QoS service control > > It is proposed to start a joint activity with IETF on a generic protocol mechanism for end- to-end QoS service control. This refers to the potential work in IETF on the following topics: > > - Identification of the signalling requirements based on the ETSI TIPHON defined speech QoS service classes for VoIP and the signalling and control of end-to-end QoS for VoIP. The attachment provides the initial draft of the BICC CS3 signalling requirements for end-to-end QoS service control. > > - The definition of a generic call/bearer control mechanism in H.225/H.245, SIP/SDP and BICC CS3 for end-to-end QoS service control in the application plane. > > - The definition of generic extensions to H.248/MEGACO for end-to-end QoS service control between the application plane and the transport plane. > > - The translation between the generic protocol QoS information elements in H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms in IP, ATM, MPLS, etc. > > Proposals on IP QoS classes and IP Transfer Capabilities > > ITU-T SG11 would like to inform IETF that it is investigating signalling requirements for protocol development based on the IP Transfer Capabilities and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The plan is to build upon signalling approaches developed by IETF. We would like to stress that the work on IP QoS classes and IP Transfer Capabilities by ITU-T SG13 is co- ordinated with IETF. > > ATTACHMENT Initial draft text of the BICC CS3 signalling requirements for end-to-end QoS service control. > > The ETSI specifications referenced as base material are available at the following URLs: > > ETSI TS 301 329 part 2, http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10 1329-2v111p.doc > > - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05003/DTS05003v096.zi p > > Further information about the ETSI TIPHON project is available at the following URL: > > - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON > __________________ > > BICC CS3 signalling requirements for end-to- end QoS service control > > EDITORS’ NOTE: This requirements text for end-to-end QoS service control is a first draft text and requires extensive updating based on liaison activities with other groups > > 1 Rationale > > The rationale of the BICC CS3 requirements for end-to-end service control is based on the analysis made by ETSI TIPHON (see the presentation available at the URL: http://docbox.etsi.org/tech- org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012- Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the inter-relationship between the different QoS factors that finally determine > the perceived speech quality by the end- users. This perceived speech quality does not only depend on network quality of service (network packet loss, network jitter and network delay) but on the terminal implementation (jitter buffers and codec performance) as well. > > A second rationale is that end-to-end QoS requirements can be regarded as end-to-end quality budgets related to the media flows. To achieve the required end-to-end QoS these quality budgets must be allocated between the domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part 3). The Transport QoS Parameters specify the QoS budgets for each Transport Domain. It is assumed that the performance of each domain is statistically independent from any other. > > Therefore end-to-end QoS service control at the call control level (i.e. application plane) is required based on generic signalling procedures in protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS service control. > > 2 Framework for end-to-end QoS service control and network QoS control. > > A framework for QoS control may be considered at different levels: call control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP). > > 1) Call-control > > a) End-to-end QoS service control is negotiated/communicated end-to-end at the call control level. ETSI TIPHON has defined a set of speech QoS classes, and signalling requirements and flows for this purpose. > > The idea is that call control protocols are enhanced with a generic end-to-end QoS service control mechanism to negotiate these speech QoS classes and associated parameters (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size). > > Such a generic end-to-end QoS service control mechanism should be defined independent of the underlying technology (ATM or IP) and operate across network domains and including terminal characteristics to negotiate/communicate the requested listener speech quality that will be perceived by the end-users (i.e. "mouth-to-ear"). > > b) BICC (Q.190x) is one of the call control protocols that may be enhanced this way. Similar enhancements may be applicable to other call-control protocols like SIP/SDP and H.323. > > 2) Vertical control > > a) QoS service control is also negotiated/communicated at the vertical control level. The ETSI TIPHON defined signalling requirements and flows include the vertical interface. The idea is that vertical control protocols are enhanced to negotiate/communicate the QoS settings (Maximum delay, Maximum packet delay variation, Maximum packet loss, Peak bit rate and Maximum packet size) in the bearer core network based on generic H.248/MEGACO extensions. > > These QoS settings should be defined independent of the underlying technology (ATM or IP) of the bearer core network. > > b) CBC (Q.1950) is one of the vertical control protocols that may be enhanced this way. > > 3) Bearer control > > a) Network QoS is negotiated/communicated at the bearer control level. ATM signalling does already intrinsically support network QoS. SG13 has recently defined IP QoS classes and IP Transfer Capabilities. > > The idea is that bearer control protocols for IP are enhanced with a mechanism to negotiate the network QoS by using IP QoS classes and IP Transfer Capabilities. > > b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced this way. > > 4) Bearer > > a) Network QoS is negotiated/communicated at the bearer level, i.e. as part of the protocols associated with the bearers in the core network. The idea is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are used to differentiate between different types of IP traffic. > > b) IP QoS classes and IP Transfer Capabilities may be used to enhance existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP. > > 3 QoS information flows applicable to BICC > > A general model is considered for QoS information flows with BICC when making a translation of the relevant parts in Figure 8 in ETSI TS 301 329 part 3. > > Section 4 details the Q.BICC related QoS primitives and parameters based on the QoS primitives and parameters in the ETSI deliverable. Similarly, section 5 provides the Q.CBC related QoS primitives and parameters. > > 4 Q.BICC related QoS primitives and parameters > > The Q.BICC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 4.1 Q.BICC related QoS primitives > > This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS related bearer information between the domains of different service providers. > > Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer conforming to a particular ETSI TIPHON Class of Service or with defined QoS characteristics. > > NOTE Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming to a requested ETSI TIPHON QoS Class or with specified QoS characteristics. > > NOTE Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3 clause 8.1.1. > > Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer. > > NOTE Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer. > > NOTE Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101 329 part 3 clause 8.1.1 and the release of a transport flow is already covered by existing Q.BICC procedures in Q.1902 series. > > 4.2 Q.BICC related QoS parameters > > Table 1 lists the parameters used in the Q.BICC related QoS primitives not yet covered by the Q.BICC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in the Q.1902 series. > > NOTE The contents of Table 1 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.3. > > Table 1: Identification of Q.BICC related parameters for end-to-end QoS service control > Qbicc.QoSreq QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Traffic Descriptor Optional > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > Qbicc.QoSconf QoS Service Class Optional > > Codec Type and Packetisation Mandatory > > Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Application Data Transport Protocol Optional [Default RTP] > > Packet Transport Protocol Optional [Default UDP] > > Qbicc.QoSrej Reason [TBD] Mandatory > > 5 Q.CBC related QoS primitives and parameters > > The Q.CBC related QoS primitives and parameters are extracted from clause 8.1 and clause 8.2 of ETSI TS 101 329 part 3. > > 5.1 Q.CBC related QoS primitives > > This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS related transport flow information between a service domain and an associated transport domain. This information contains the QoS related characteristics required of the transport flows that will carry the media flow and the properties of the media flow. > > Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport flow with defined QoS characteristics across a Transport Domain or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport flow or the reservation of Transport Domain resource. > > NOTE Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3 clause 8.1.3. > > Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a transport flow. > > NOTE Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a transport flow. > > NOTE Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already covered by the existing Q.CBC procedures in Q.1950. > > Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service Domain of the performance of the Transport Domain in meeting the requested QoS levels. This may be a periodic event or an urgent alarm. Note: this primitive is a management primitive and its use is for further study. > > NOTE Identical to TRM QoS performance notification (QT2.TRM QoS perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study. > > 5.2 Q.CBC related QoS parameters > > Table 2 lists the parameters used in the Q.CBC related QoS primitives not yet covered by the Q.CBC protocol. The deleted items refer to the information elements already covered by the BICC CS2 protocol in Q.1950. > > NOTE The contents of Table 2 is an interpretation of the table in ETSI TS 101 329 part 3 clause 8.2.5. > > Table 2: Identification of Q.CBC related parameters for end-to-end QoS service control > > QT2.TRMQreq Transport QoS Parameters Mandatory > > Traffic Descriptor Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QT2.TRMQconf Transport QoS Parameters Mandatory > > Transport Addresses Mandatory > > Packet Transport Protocol Optional [Default UDP] > > QoS Mechanism Optional > > QT2.TRMQrej Reason [TBD] Mandatory > > 6 Parameter contents > > Table 3 specifies the information to be covered by the parameters listed in sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329 part 3 clause 8.2.1. > > Table 3: Identification of parameter contents for end-to-end QoS service control > > QoS Service Class Describes the end-to-end ETSI TIPHON Best, High, Medium > class of a bearer or Best Effort > > Transport QoS Specifies the QoS characteristics Maximum Delay > Parameters required of the transport flow > carrying the media flow. Maximum Packet Delay Variation > > Maximum Packet Loss > > Traffic Descriptor Characterises the resource Peak Bit > requirements of an application data > flow (excludes transport flow Maximum Packet Size > resource requirements). > > Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101 329 Part 2 > > The maximum delay permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet delay variation permitted (ms) over either a segment of the transport flow or the remaining part of the transport flow. > > The maximum packet loss permitted (%) over either a segment of the transport flow or the remaining part of the transport flow. [N.B. This measure assumes randomly distributed packet loss] > Maximum bit rate (bit/s) of the media flow. > > Maximum size of the media packets > > 7 Information flows and signalling procedures for end-to-end QoS service control > > EDITORS’ NOTE The information flows and signalling procedures for end-to-end QoS service control may be considered to follow the same principles as the already existing procedures for end-to-end codec negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for end-to-end QoS modification and mid-call QoS modification may be considered because the perceived QoS is highly related to the codec type employed end- to-end as part of the connection. The exact scope and properties of these procedures and protocol message flows needs further discussion. > > Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols > Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com > > _______________________________________________ diffserv mailing list diffserv@ietf.org http://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:32:47 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14640 for ; Sun, 3 Jun 2001 22:32:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F36A54444B; Sun, 3 Jun 2001 22:06:56 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id 26F2244418; Fri, 1 Jun 2001 20:55:21 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01628; Fri, 1 Jun 2001 17:53:43 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28792 for corey@hearme.com; Fri, 1 Jun 2001 17:52:27 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id LAA13287 for ; Thu, 31 May 2001 11:03:42 -0700 (PDT) Received: from optimus.ietf.org ([132.151.1.19]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id LAA17729 for ; Thu, 31 May 2001 11:03:40 -0700 (PDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26657; Thu, 31 May 2001 14:01:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25888 for ; Thu, 31 May 2001 13:53:44 -0400 (EDT) Received: from ckmso1.proxy.att.com ([12.20.58.69]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03801; Thu, 31 May 2001 13:53:19 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VHpPC24217; Thu, 31 May 2001 13:51:25 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id NAA00157; Thu, 31 May 2001 13:51:00 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 13:51:22 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Mailman-Version: 1.0 Precedence: bulk X-BeenThere: sipping@ietf.org Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] [Sipping] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 13:51:09 -0400 Hi, Baker: It appears that a good amount discussion can be started to answer your questions (what has being discussed for the last couple of years in the ITU-T and TIPHON in particular). I am not trying to do so. Let me answer your questions summarizing the key points as follows: 1. Broadly, all applications can be considered in two categories: a. Real-time (e.g., audio, video [of H.323/SIP]) and b. Non-Real-time (e.g., data applications like file transfer, WWW, Mail, etc. - can a part of H.323/SIP). The performance parameters of both real-time (audio, video) and non-real-time (data) traffic can be abstracted in an universal way that can be used by all applications (e.g., H.323, SIP, WWW, mail, etc). However, the signaling messages used by each application are application-specific although the QOS parameters used by all of them still remain same (e.g., H.323 might use RAS/Q.931/Annex-G/H.245 signaling messages, SIP might use SDP). The QOS signaling messages that use QOS parameters can be termed as the application layer QOS signaling messages and are sent on end-to-end basis and the values of those QOS parameters do not change no matter what may be the underlying transport networks (e.g., IP, ATM). 2. The network layer QOS signaling messages carried over the network may not be end-to-end significance. For example, an end-to-end path of an IP network may consist of RSVP, DiffServ, MPLS, and RSVP. So, the network layer QOS parameters may get translated between the source-destination path and may not remain the same what has been negotiated on end-to-end basis in the application layer (item 1). The problems that are being addressed are as follows: A. How to develop the end-to-end QOS signaling mechanisms in the application layer B. How to relate the application layer QOS signaling to the network layer QOS signaling (e.g., RSVP, DifServ, MPLS, etc.) so that one-to-one consistency remain between the application and network layer QOS parameters. Hope this may clarify some of your questions. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Thursday, May 31, 2001 1:09 PM To: Roy, Radhika R, ALCTA Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu; diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ Sipping mailing list Sipping@ietf.org http://www.ietf.org/mailman/listinfo/sipping _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:38:37 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14712 for ; Sun, 3 Jun 2001 22:38:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 93B6B44454; Sun, 3 Jun 2001 22:07:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id D03AA44481; Fri, 1 Jun 2001 20:56:06 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01644; Fri, 1 Jun 2001 17:54:49 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28810 for corey@hearme.com; Fri, 1 Jun 2001 17:53:44 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id LAA13663 for ; Thu, 31 May 2001 11:28:59 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id LAA18167 for ; Thu, 31 May 2001 11:28:54 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 12FC944472; Thu, 31 May 2001 14:11:10 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 9BDA5443A3; Thu, 31 May 2001 13:53:46 -0400 (EDT) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f4VHpPC24217; Thu, 31 May 2001 13:51:25 -0400 (EDT) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id NAA00157; Thu, 31 May 2001 13:51:00 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 13:51:22 -0400 Message-ID: From: "Roy, Radhika R, ALCTA" To: Fred Baker Cc: Bob Braden , gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 13:51:09 -0400 Hi, Baker: It appears that a good amount discussion can be started to answer your questions (what has being discussed for the last couple of years in the ITU-T and TIPHON in particular). I am not trying to do so. Let me answer your questions summarizing the key points as follows: 1. Broadly, all applications can be considered in two categories: a. Real-time (e.g., audio, video [of H.323/SIP]) and b. Non-Real-time (e.g., data applications like file transfer, WWW, Mail, etc. - can a part of H.323/SIP). The performance parameters of both real-time (audio, video) and non-real-time (data) traffic can be abstracted in an universal way that can be used by all applications (e.g., H.323, SIP, WWW, mail, etc). However, the signaling messages used by each application are application-specific although the QOS parameters used by all of them still remain same (e.g., H.323 might use RAS/Q.931/Annex-G/H.245 signaling messages, SIP might use SDP). The QOS signaling messages that use QOS parameters can be termed as the application layer QOS signaling messages and are sent on end-to-end basis and the values of those QOS parameters do not change no matter what may be the underlying transport networks (e.g., IP, ATM). 2. The network layer QOS signaling messages carried over the network may not be end-to-end significance. For example, an end-to-end path of an IP network may consist of RSVP, DiffServ, MPLS, and RSVP. So, the network layer QOS parameters may get translated between the source-destination path and may not remain the same what has been negotiated on end-to-end basis in the application layer (item 1). The problems that are being addressed are as follows: A. How to develop the end-to-end QOS signaling mechanisms in the application layer B. How to relate the application layer QOS signaling to the network layer QOS signaling (e.g., RSVP, DifServ, MPLS, etc.) so that one-to-one consistency remain between the application and network layer QOS parameters. Hope this may clarify some of your questions. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Fred Baker [mailto:fred@cisco.com] Sent: Thursday, May 31, 2001 1:09 PM To: Roy, Radhika R, ALCTA Cc: Bob Braden; gratta@lucent.com; sob@harvard.edu; mankin@isi.edu; diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu; megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org; hiramatsu.yukio@lab.ntt.co.jp; rbuhrke@lucent.com; tsg11q8@ties.itu.ch; tsg11q9@ties.itu.ch; ITU-SG16@mailbag.cps.INTEL.COM Subject: RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL At 06:08 AM 5/31/2001, Roy, Radhika R, ALCTA wrote: >All applications (e.g., H.323, SIP) uses signaling messages >among its functional entities (e.g., terminal, agents, >gatekeepers, proxies, gateways) for communications. I'm not sure we're on the same planet. Please help me out here. I can think of a few applications that have agents, gatekeepers, proxies, and gateways, mostly resulting from the imposition of firewalls or authentication systems, or from legacy applications like imitating the telephone system in a data network. The only one that *requires* any kind of gateway, to my knowledge, is H.323 teleconferencing, which represents a paltry fraction of traffic according to most current measurements. Anything else (75% of Internet traffic is http or FTP, most of the rest is mail, on private LANs applications like NFS are pretty common, and even SIP can be done without a gateway between consenting systems) could be hooked up in separate systems on a LAN and made to work without any such signalling at all. Could you be more specific on what QoS signalling is required by the world wide web, mail, FTP, common ERP applications like ERP and PeopleSoft, calendaring, and so on? If not, could you be more specific about what "all" applications you have in mind? And could you be more specific about what issues this proposal is addressing that have not already been addressed in de facto standards and deployed in operational systems? It would be very nice to understand what you are preparing to ask vendors to do, and whether operators are interested in deploying them. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:44:22 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14805 for ; Sun, 3 Jun 2001 22:44:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 26F994445F; Sun, 3 Jun 2001 22:07:16 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from gateway.hearme.com (gateway.hearme.com [204.242.182.129]) by lists.bell-labs.com (Postfix) with ESMTP id BD65544336; Fri, 1 Jun 2001 20:58:22 -0400 (EDT) Received: from nodserv.hearme.com (nodserv.hearme.com [206.233.214.16]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id RAA01690; Fri, 1 Jun 2001 17:56:55 -0700 (PDT) Received: (from corey@localhost) by nodserv.hearme.com (8.9.1/8.9.1) id RAA28836 for corey@hearme.com; Fri, 1 Jun 2001 17:55:50 -0700 (PDT) Received: from gateway.hearme.com (localhost [127.0.0.1]) by nodserv.hearme.com (8.9.1/8.9.1) with ESMTP id NAA15207 for ; Thu, 31 May 2001 13:36:17 -0700 (PDT) Received: from lists.bell-labs.com ([204.178.16.58]) by gateway.hearme.com (8.9.1/8.9.1) with ESMTP id NAA20219 for ; Thu, 31 May 2001 13:36:16 -0700 (PDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 308CF44374; Thu, 31 May 2001 11:31:05 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from prue.eim.surrey.ac.uk (prue.eim.surrey.ac.uk [131.227.76.5]) by lists.bell-labs.com (Postfix) with ESMTP id 16760443FA; Thu, 31 May 2001 11:14:11 -0400 (EDT) Received: from phaestos.ee.surrey.ac.uk ([131.227.88.14] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.16 #1) id 155U91-00045U-00; Thu, 31 May 2001 16:13:51 +0100 From: Lloyd Wood X-Sender: eep1lw@phaestos.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Fred Baker Cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org, iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, Yukio Hiramatsu , rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, John C Klensin , chair@ietf.org In-Reply-To: <5.1.0.14.2.20010530152432.043b8ec0@mira-sjcm-2.cisco.com> Message-ID: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 X-Scanner: exiscan *155U91-00045U-00*ZWgRfZ3Wo52* http://duncanthrax.net/exiscan/ X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] [IPTEL] Re: [Diffserv] Re: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR END-TO-END QOS SERVICE CONTROL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 31 May 2001 16:13:43 +0100 (BST) On Wed, 30 May 2001, Fred Baker wrote: > Greg: > > The URLs in this note were all sent with what the ETSI machine considered > to be 'malformed syntax'. Could you resend the correct URLs? Just put all the parts together, removing unencoded spaces; the reason for the breaks after the hyphens seems obvious enough, but I'm at a loss to explain others. Here we go: http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05009/V1.1.1/ts_101329-2v111p.doc http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/_Published/DTS05003/DTS05003v096.zip http://webapp.etsi.org/tbhomepage/TBDetails.asp?TB_ID=291&TB_NAME=TIPHON http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/ARCHIVES/2000/05-200012-Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt So http://docbox.etsi.org/ is passworded but docs can be retrieved by advertised public direct url? Bizarre. L. PGP _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 22:46:21 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14841 for ; Sun, 3 Jun 2001 22:46:20 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE52A44469; Sun, 3 Jun 2001 22:07:25 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lists.bell-labs.com (Postfix) with SMTP id 56A2944336; Sat, 2 Jun 2001 06:42:53 -0400 (EDT) Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 2 Jun 2001 11:42:33 +0100 To: rrroy@att.com Cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, iptel@lists.bell-labs.com, megaco@fore.com, sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org, hiramatsu.yukio@lab.ntt.co.jp, rbuhrke@lucent.com, tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch, ITU-SG16@mailbag.cps.INTEL.COM, J.Crowcroft@cs.ucl.ac.uk Subject: Re: [SIP] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR E ND-TO-END QOS SERVICE CONTROL In-reply-to: Your message of "Wed, 30 May 2001 23:39:17 GMT." <200105302339.XAA13198@gra.isi.edu> Message-ID: <1723.991478550@cs.ucl.ac.uk> From: Jon Crowcroft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 02 Jun 2001 11:42:30 +0100 1/ please stop copying all the lists. most of us are on all of them 2/ this is a layering question and is clearly indpenenant of mapping qos at lower layers (if it isnt its severely broken) - its clear that diffserve and issll sit several layeres BELOW what you want to do and that the signaling mechanisms for both are indpeennsdat and much lower - i notice for example you dont include 802.1p and q - similar layer type stuff... 3/ the docs cited are telpeony specific EXTREMELY and in fact dont relate to results that show that people have broader tolerances than yo umight expect when using different ways to get voice around - while its reasoanble to have a subset of QoS parameters signaled fro mapps that are application specific, a better way to do it is through a profiling mechanisms, which has a code point scheme, that then uses more general means to signal the actual QoS parameters 4/ the IETF has several appropriate signaling protocol efforts and paramerter specification schemes...although i believe its not well architectured across all the layers right now and its not clear we have a profile mechansism/language/syntax/semantics 5/ there's the siglite discussio ngoing on and there was the bof to talk about new signaling protocols at the last IETF _ this seems to be somewhat ignoring that activity - is that intentional? if so why? j. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Jun 3 23:44:34 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15645 for ; Sun, 3 Jun 2001 23:44:34 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E80D4439B; Sun, 3 Jun 2001 23:44:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 63D6A44398 for ; Sun, 3 Jun 2001 23:43:10 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02881; Sun, 3 Jun 2001 23:46:55 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Jun 2001 23:42:58 -0400 Message-ID: From: Jonathan Rosenberg To: "'Baniel Uri-CUB001'" , sip@lists.bell-labs.com Subject: RE: [SIP] Invitation for a multicast session MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Jun 2001 23:42:56 -0400 > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Sunday, June 03, 2001 8:58 AM > To: 'Jonathan Rosenberg'; sip@lists.bell-labs.com > Subject: RE: [SIP] Invitation for a multicast session > > > So just to be 100% sure that I got this one right once and > for all... say I like to invite A, B, C and D who belong to > the same multicast group, to a conf call (mbone session). Say > I like to invite them by multicast means. > Do I have to multicast 4 Invites (each with a different > request-URI and To fields(e.g. A@example.com, B@example.com, > etc.,) or one multicast will do?? Sending the same request four times would completely defeat the purpose of using multicast in the first place. The whole idea with multicast is that you don't know how many recipients there are. So, the answer is "one multicast will do". If one will do, what will > be the request-URI? What will be the To? > Based on your message below I think we need 4 invitations, > but just to be on the safe side... INVITE sip:mygroup@domain.com SIP/2.0 From: "Me" To: "The Gaggle" Via: SIP/2.0/UDP 1.2.3.4;maddr=224.2.3.4;ttl=2 Of course, each user in the group would need to be prepared to accept request sfor mygroup@domain.com. Once one decides to accept, they send a 200 OK. This triggers a CANCEL by the UAC. As a result, the caller is connected to one of the members of this group, whomever it might be. What SIP cannot do is help you generate a request so that a call is connected to ALL members of the group (this really requires reliable multicast to avoid response implosion). You'll only get the first to answer. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Jun 4 01:48:50 2001 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18409 for ; Mon, 4 Jun 2001 01:48:50 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 14A0344337; Mon, 4 Jun 2001 01:49:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from dns1.catt.ac.cn (unknown [202.106.106.98]) by lists.bell-labs.com (Postfix) with ESMTP id ACAB344336 for ; Mon, 4 Jun 2001 01:48:13 -0400 (EDT) Received: from suncz (202.106.106.126 [202.106.106.126]) by dns1.catt.ac.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LPMJYJ7W; Mon, 4 Jun 2001 13:42:33 +0800 Message-ID: <00e001c0ecb9$b50e6be0$7dce12ac@MCSD.local> From: "suncz" To: "Jonathan Rosenberg" , "'Baniel Uri-CUB001'" , References: Subject: Re: [SIP] Invitation for a multicast session MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Jun 2001 13:46:25 +0800 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id BAA18409 I have a question about the Call ID.If sending the same request four times to A,B,C and D respectively for the same conference,the reqest's Call ID is same? And how to write the To head field ? Thanks in advance. Best regards, Yours sincerely, Chengzhen Sun ------------------------------------------------- Standardization Department Mobile Communication R&D Center China Academy of Telecommunication Technology(CATT) No.40,Xueyuan Road Beijing,China 100083 Tel:+8610 62304422EXT227 Fax:+8610 62303127 Mailto:suncz@catt.ac.cn -------------------------------------------------- ----- Original Message ----- From: "Jonathan Rosenberg" To: "'Baniel Uri-CUB001'" ; Sent: Monday, June 04, 2001 11:42 AM Subject: RE: [SIP] Invitation for a multicast session > > > > > > -----Original Message----- > > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > > Sent: Sunday, June 03, 2001 8:58 AM > > To: 'Jonathan Rosenberg'; sip@lists.bell-labs.com > > Subject: RE: [SIP] Invitation for a multicast session > > > > > > So just to be 100% sure that I got this one right once and > > for all... say I like to invite A, B, C and D who belong to > > the same multicast group, to a conf call (mbone session). Say > > I like to invite them by multicast means. > > Do I have to multicast 4 Invites (each with a different > > request-URI and To fields(e.g. A@example.com, B@example.com, > > etc.,) or one multicast will do?? > > Sending the same request four times would completely defeat the purpose of > using multicast in the first place. The whole idea with multicast is that > you don't know how many recipients there are. So, the answer is "one > multicast will do". > > If one will do, what will > > be the request-URI? What will be the To? > > Based on your message below I think we need 4 invitations, > > but just to be on the safe side... > > INVITE sip:mygroup@domain.com SIP/2.0 > From: "Me" > To: "The Gaggle" > Via: SIP/2.0/UDP 1.2.3.4;maddr=224.2.3.4;ttl=2 > > Of course, each user in the group would need to be prepared to accept > request sfor mygroup@domain.com. Once one decides to accept, they send a 200 > OK. This triggers a CANCEL by the UAC. As a result, the caller is connected > to one of the members of this group, whomever it might be. What SIP cannot > do is help you generate a request so that a call is connected to ALL members > of the group (this really requires reliable multicast to avoid response > implosion). You'll only get the first to answer. > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÓ†+%ŠËb±ú+r‰íŠ{¢ž^½éh¦g§¶‡í…äˆ>šè¶‡(—ôázÈ©þ)©•éžžÚ+þÉb²Ø¬¶©•§¶‡b±Ë¬²)©•éžžÖ­Š‰ÿjwm¢·œz+ÞiÛâqê'ºw^®ËZاìb²Ø§‚È©ý:,¹»®&Þ¶ˆ­þǧvf¢–Ú,ŠŸâš™^™éí¢»ÿ­ê®zËÿrÏÜ¢[¦n&ÿyÛ°ŠØÿ²æìr¸›{ø§¶›¡Üÿ From sip-admin@lists.bell-labs.com Mon Jun 4 01:58:45 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19047 for ; Mon, 4 Jun 2001 01:58:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 990E04436A; Mon, 4 Jun 2001 01:59:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from cyclops.soft.net (relay1.soft.net [164.164.128.17]) by lists.bell-labs.com (Postfix) with ESMTP id 14F2244369 for ; Mon, 4 Jun 2001 01:58:12 -0400 (EDT) Received: from email.eximsoft.com ([164.164.87.130]) by cyclops.soft.net (Switch-2.0.1/Switch-2.0.1) with ESMTP id f54G2H615140 for ; Mon, 4 Jun 2001 11:02:18 -0500 (GMT) Received: from ewsuc110 (unknown [10.10.10.122]) by email.eximsoft.com (Postfix) with SMTP id 036A8690F9 for ; Mon, 4 Jun 2001 11:27:15 +0530 (IST) Message-ID: <000a01c0ed13$e06a0560$7a0a0a0a@exim.com> From: "Gautham A N" To: References: <00e001c0ecb9$b50e6be0$7dce12ac@MCSD.local> Subject: Re: [SIP] Invitation for a multicast session MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Jun 2001 11:31:58 -0500 Content-Transfer-Encoding: 8bit hi Chengzhen Sun, The Call ID is different for each of the requests. gautham ----- Original Message ----- From: suncz To: Jonathan Rosenberg ; 'Baniel Uri-CUB001' ; Sent: Monday, June 04, 2001 12:46 AM Subject: Re: [SIP] Invitation for a multicast session > I have a question about the Call ID.If sending the same request four times to A,B,C and D respectively for the same conference,the reqest's Call ID is same? > And how to write the To head field ? > Thanks in advance. > > > Best regards, > > Yours sincerely, > Chengzhen Sun > ------------------------------------------------- > > Standardization Department > Mobile Communication R&D Center > China Academy of Telecommunication Technology(CATT) > No.40,Xueyuan Road > Beijing,China > 100083 > Tel:+8610 62304422EXT227 > Fax:+8610 62303127 > Mailto:suncz@catt.ac.cn > -------------------------------------------------- > > ----- Original Message ----- > From: "Jonathan Rosenberg" > To: "'Baniel Uri-CUB001'" ; > Sent: Monday, June 04, 2001 11:42 AM > Subject: RE: [SIP] Invitation for a multicast session > > > > > > > > > > > > > -----Original Message----- > > > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > > > Sent: Sunday, June 03, 2001 8:58 AM > > > To: 'Jonathan Rosenberg'; sip@lists.bell-labs.com > > > Subject: RE: [SIP] Invitation for a multicast session > > > > > > > > > So just to be 100% sure that I got this one right once and > > > for all... say I like to invite A, B, C and D who belong to > > > the same multicast group, to a conf call (mbone session). Say > > > I like to invite them by multicast means. > > > Do I have to multicast 4 Invites (each with a different > > > request-URI and To fields(e.g. A@example.com, B@example.com, > > > etc.,) or one multicast will do?? > > > > Sending the same request four times would completely defeat the purpose of > > using multicast in the first place. The whole idea with multicast is that > > you don't know how many recipients there are. So, the answer is "one > > multicast will do". > > > > If one will do, what will > > > be the request-URI? What will be the To? > > > Based on your message below I think we need 4 invitations, > > > but just to be on the safe side... > > > > INVITE sip:mygroup@domain.com SIP/2.0 > > From: "Me" > > To: "The Gaggle" > > Via: SIP/2.0/UDP 1.2.3.4;maddr=224.2.3.4;ttl=2 > > > > Of course, each user in the group would need to be prepared to accept > > request sfor mygroup@domain.com. Once one decides to accept, they send a 200 > > OK. This triggers a CANCEL by the UAC. As a result, the caller is connected > > to one of the members of this group, whomever it might be. What SIP cannot > > do is help you generate a request so that a call is connected to ALL members > > of the group (this really requires reliable multicast to avoid response > > implosion). You'll only get the first to answer. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementor's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > N-+Sǭʶ)Sxz÷¢TzÚ¶ ú¢Ú¢TzÈSjzg¶S-+SËzTqëv+ºËsTTéjØ©¶Sqèy§?Çzéz»jwzSËz ¥:¹»®&¶^±éT¨¶<"¦)©.ézzÚ+²·ª¹ë-rÇ(-é>?§»­?Ë>±Êâm觶> _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Jun 4 03:23:43 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01212 for ; Mon, 4 Jun 2001 03:23:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 600394434C; Mon, 4 Jun 2001 03:24:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailweb25.rediffmail.com (unknown [203.199.83.29]) by lists.bell-labs.com (Postfix) with SMTP id B8D6F44336 for ; Mon, 4 Jun 2001 03:23:37 -0400 (EDT) Received: (qmail 15584 invoked by uid 510); 4 Jun 2001 07:28:07 -0000 Message-ID: <20010604072807.15583.qmail@mailweb25.rediffmail.com> Received: from unknown (210.214.217.58) by rediffmail.com via HTTP; 04 Jun 2001 07:28:07 -0000 MIME-Version: 1.0 To: "sip@lists.bell-labs.com" From: "Ashhar Farhan" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Subject: [SIP] Authentication and billing through proxy/re-direct server Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 4 Jun 2001 07:28:07 -0000 Content-Transfer-Encoding: 7bit in a typical next gen telco setup, the billing is centralised and their Point of presence are basically SIP servers that gateway to PSTN cloud. the INVITE gets redirected/proxied from the central server and the is resend to the gateway (a sip server). here, we have an issue of user authentication. the user has to be authenticated by the redirect/proxy server. the authentication (as per the SIP recommendations) should be md5 digest. the scheme would be that the redirect/proxy should generate a digest over the redirected INVITE request using the nonce and password of the intended server. billing systems are usually needed to be centralised (esp. in those next gen telcos where the servers are operated by franchises). this is a commercial requirement of SIP operations. the 2543.bis does not explicitly talk of the redirect/proxies authenticating requests for the gateways. the second issue: the call minutes are the accepted billing mechanism for atleast the next couple of years. to support billing, accurate times of call start and end are important. the call times maybe at variance between the client and the server due to a the RTT nature of messaging itself. In that case, it will be advisable, from a caller perspective to know when exactly did the call get disconnected (a second's delay can roll the call over to the next minute) and how long did the call last - as per server's record. Although MESSAGE can be used for this, i would rather believe that a more intrinsic method must be available to support this that can update the caller's own 'call meter'. - farhan@hotfoon.com _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Jun 4 06:45:46 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02619 for ; Mon, 4 Jun 2001 06:45:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB91C44355; Mon, 4 Jun 2001 06:46:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from mailweb16.rediffmail.com (unknown [203.199.83.28]) by lists.bell-labs.com (Postfix) with SMTP id 934EF44336 for ; Mon, 4 Jun 2001 06:45:38 -0400 (EDT) Received: (qmail 23667 invoked by uid 510); 4 Jun 2001 10:48:27 -0000 Message-ID: <20010604104827.23666.qmail@mailweb16.rediffmail.com> Received: from unknown (203.145.133.130) by rediffmail.com via HTTP; 04 Jun 2001 10:48:27 -0000 MIME-Version: 1.0 To: "sip@lists.bell-labs.com" From: "kumar s" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Subject: [SIP] doubt in HOLD & HOLD retrieve Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 4 Jun 2001 10:48:27 -0000 Content-Transfer-Encoding: 7bit Hello all, A and B are already have established a call. now A wants to put B on hold. That is INVITE B (with c=0.0.0.0 in SDP) A ---------------------------------------> B 200 OK <------------------------------------------- ACK -------------------------------------------> i want to know, What A has to do if B replies with 4xx response. Can A give CANCEL after giving INVITE and before A's response, if A could, how B will treat this. If A gives BYE before retrieving B from hold, will this terminates the entire session between A and B. Please could anyone explain me. Thanks S.Kumar _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Jun 4 10:36:43 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08794 for ; Mon, 4 Jun 2001 10:36:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D461544337; Mon, 4 Jun 2001 10:37:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by lists.bell-labs.com (Postfix) with ESMTP id B139444336 for ; Mon, 4 Jun 2001 10:36:28 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id HAA11540 for ; Mon, 4 Jun 2001 07:36:28 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA20488 for ; Mon, 4 Jun 2001 07:36:27 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 09:36:27 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E007@IL27EXM10.cig.mot.com> From: Baniel Uri-CUB001 To: "'Jonathan Rosenberg'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Invitation for a multicast session MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Jun 2001 09:36:26 -0500 OK now it is really clear! Thanks!! Anyways in case a "race" condition has happened and both stations (say B and C) responded with a 200 OK. (i.e. despite of the delay-response and Cancel mechanisms described in the spec), what is the correct behavior of the UAC? Say he wants to accept B and reject C, does it need to Ack C (in order to complete the 1st transaction) and then right away sends it a BYE? (I know I am actually asking here a generic and probably a naive/basic question regarding how a UAC should behave in case it does not want to accept the 200...) ================================================================= Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; "Only by learning do we discover how ignorant we are" E.w.c ================================================================= > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, June 03, 2001 10:43 PM > To: 'Baniel Uri-CUB001'; sip@lists.bell-labs.com > Subject: RE: [SIP] Invitation for a multicast session > > > > > > > > -----Original Message----- > > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > > Sent: Sunday, June 03, 2001 8:58 AM > > To: 'Jonathan Rosenberg'; sip@lists.bell-labs.com > > Subject: RE: [SIP] Invitation for a multicast session > > > > > > So just to be 100% sure that I got this one right once and > > for all... say I like to invite A, B, C and D who belong to > > the same multicast group, to a conf call (mbone session). Say > > I like to invite them by multicast means. > > Do I have to multicast 4 Invites (each with a different > > request-URI and To fields(e.g. A@example.com, B@example.com, > > etc.,) or one multicast will do?? > > Sending the same request four times would completely defeat > the purpose of > using multicast in the first place. The whole idea with > multicast is that > you don't know how many recipients there are. So, the answer is "one > multicast will do". > > If one will do, what will > > be the request-URI? What will be the To? > > Based on your message below I think we need 4 invitations, > > but just to be on the safe side... > > INVITE sip:mygroup@domain.com SIP/2.0 > From: "Me" > To: "The Gaggle" > Via: SIP/2.0/UDP 1.2.3.4;maddr=224.2.3.4;ttl=2 > > Of course, each user in the group would need to be prepared to accept > request sfor mygroup@domain.com. Once one decides to accept, > they send a 200 > OK. This triggers a CANCEL by the UAC. As a result, the > caller is connected > to one of the members of this group, whomever it might be. > What SIP cannot > do is help you generate a request so that a call is connected > to ALL members > of the group (this really requires reliable multicast to > avoid response > implosion). You'll only get the first to answer. > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Jun 4 10:38:26 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08809 for ; Mon, 4 Jun 2001 10:38:26 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2D2694436E; Mon, 4 Jun 2001 10:38:08 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by lists.bell-labs.com (Postfix) with ESMTP id A8C2544336 for ; Mon, 4 Jun 2001 10:37:34 -0400 (EDT) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id OAA15144; Mon, 4 Jun 2001 14:37:19 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 04 Jun 2001 14:37:19 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 07:37:16 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E89006E18B5B@orsmsx35.jf.intel.com> From: "Gross, Gerhard" To: "'Ashhar Farhan'" , sip@lists.bell-labs.com Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv er MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Jun 2001 07:36:58 -0700 Farhan, Your second issue can be addressed by having the SIP proxy server communicate with a AAA/policy server. An overview and msg interaction is discussed in: http://www.ietf.org/internet-drafts/draft-gross-cops-sip-01.txt http://www.ietf.org/internet-drafts/draft-gross-sipaq-01.txt Note that this model allows for selective billing of appropriate services. For example, part of the session may proceed using best effort transmission and another part may proceed using high priority (RSVP, diffserv). The AAA/policy svr is a PDP (or communicates with a PDP) for the network nodes providing high priority forwarding and therefore has knowledge of BW reserved, seconds the service was provided, etc. Gery > -----Original Message----- > From: Ashhar Farhan [mailto:afarhan@rediffmail.com] > Sent: Monday, June 04, 2001 12:28 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Authentication and billing through > proxy/re-direct server > > > in a typical next gen telco setup, the billing is centralised > and their Point of presence are basically SIP servers that > gateway to PSTN cloud. > > the INVITE gets redirected/proxied from the central server > and the is resend to the gateway (a sip server). > here, we have an issue of user authentication. the user has > to be authenticated by the redirect/proxy server. the > authentication (as per the SIP recommendations) should be md5 digest. > the scheme would be that the redirect/proxy should generate a > digest over the redirected INVITE request using the nonce and > password of the intended server. > > billing systems are usually needed to be centralised (esp. in > those next gen telcos where the servers are operated by > franchises). this is a commercial requirement of SIP operations. > > the 2543.bis does not explicitly talk of the redirect/proxies > authenticating requests for the gateways. > > the second issue: > the call minutes are the accepted billing mechanism for > atleast the next couple of years. to support billing, > accurate times of call start and end are important. > the call times maybe at variance between the client and the > server due to a the RTT nature of messaging itself. In that > case, it will be advisable, from a caller perspective to know > when exactly did the call get disconnected (a second's delay > can roll the call over to the next minute) and how long did > the call last - as per server's record. Although MESSAGE can > be used for this, i would rather believe that a more > intrinsic method must be available to support this that can > update the caller's own 'call meter'. > > - farhan@hotfoon.com > > > > _____________________________________________________ > Chat with your friends as soon as they come online. Get Rediff Bol at > http://bol.rediff.com > > > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Jun 4 10:52:44 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09161 for ; Mon, 4 Jun 2001 10:52:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 734E04437F; Mon, 4 Jun 2001 10:53:05 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by lists.bell-labs.com (Postfix) with ESMTP id B37604436B for ; Mon, 4 Jun 2001 10:52:55 -0400 (EDT) Received: from m2hub.mail.wipro.com (m2hub.wipro.com [164.164.27.50]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with ESMTP id f54KVTZ11685 for ; Mon, 4 Jun 2001 20:31:29 GMT Received: from m2vwall2.wipro.com ([164.164.27.52]) by m2hub.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GEEUF400.S1G for ; Mon, 4 Jun 2001 20:17:28 +0530 Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GEEUN800.L4B for ; Mon, 4 Jun 2001 20:22:21 +0530 Received: from wipro.com (mmcsview.wipsys.soft.net [164.164.8.211]) by wslexch.wipsys.soft.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LNNA3HW6; Mon, 4 Jun 2001 20:33:46 +0530 Message-ID: <3B1C5004.69DB525A@wipro.com> From: Varadarajan Srinivasan Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP Queries Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Jun 2001 08:51:36 +0531 Content-Transfer-Encoding: 7bit Hi All, I have some basic queries regarding RFC2543. I have used pdf version of the draft bis02, and the page nos are for the same. 1) Is it not the Route header and Via contains redudant information? Via is needed only to set route or just to send responses in the same path as that of the request.After route is set, I think proxies can take this info from route header and via contains redundant information. 2) Are Max_Forwards header and ttl parameter, mean similar things ? Can we take one out? 3) In chapter 16, RFC2543[100], in example, Why Via headers of the response 180 Ringing to the Invite request (in the previous page) are not the same?? 4) In chapter 16.5, [106](Page 106) of RFC2543, under the SIP message 487 Request Terminated, it is written as the response should terminate at Proxy. I think it is Client. 5) Why statefull proxies require TCP? 6) In Appendix A, in minimal implementation, [110] of RFC2543, for Clients, it is said Contact header is not a minimum requirement. Without that how do you register? Why BYE is not a part of minimum requirement?How will you terminate a call then? 7) In Appendix A, in minimal implementation, for Servers, OPTIONS is categorised as Minimal requirement. I dont think so as it is only a sophistication. 8) INVITE 11:02:32 UAC/UAS 1 ------------------------------ > UAC/UAS 2 180 RINGING 11:02:34 < ----------------------------- CANCEL 11:02:36 ----------------------------- > 200 OK for INVITE < ----------------------------- A user 1 invites another user 2. It gets the 180 ringing and later wants to cancel the invitation by sending cancel method. Before, the Cancel method reaches user 2, it picks up the call and hence sends a 200 OK. Now, at this situation, what to do next? 9) I have attempted certain clarrifications on RFC2543 for Appendix I. I just want the group to check whether mine is correct or open the problem to the group. i) In Appendix I, [127] of RFC2543, II paragraph, the author specify that the request URI for Register is just the domain name wihtout @ but a format of request line demands that it is a URL which requires @ in its syntax. The person who raised this query, is suggesting that To: header field can be processed instead of Request URI by REGISTRAR and Request URI can be omitted in the REGISTER method .. I think this is right. ii) In another clarrification in Appendix I, the last but one query before Appendix J, the person who raised the query is WRONG. Table 5 does contain www-Authenticate as a response as well as Request header. Mr. Varadarajan Srinivasan, Senior Systems Engineer, Wipro Technologies. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Jun 4 11:43:45 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10613 for ; Mon, 4 Jun 2001 11:43:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E661D4434C; Mon, 4 Jun 2001 11:44:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (unknown [207.67.232.131]) by lists.bell-labs.com (Postfix) with ESMTP id F16194434C for ; Mon, 4 Jun 2001 11:43:25 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Jun 2001 08:42:59 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] E.164 request-uri domain's. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ED0D.07CB5DE0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Jun 2001 08:42:58 -0700 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0ED0D.07CB5DE0 Content-Type: text/plain; charset="iso-8859-1" Thanks for the reply. Comments below. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Sunday, June 03, 2001 6:43 AM To: 'Fairlie-Cuninghame, Robert'; 'sip@lists.bell-labs.com' Subject: RE: [SIP] E.164 request-uri domain's. -----Original Message----- From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] Sent: Saturday, June 02, 2001 11:26 AM To: 'sip@lists.bell-labs.com' Subject: [SIP] E.164 request-uri domain's. >Hi, > >We have had this discussion quite a few times but I thought I would throw in a new idea. > >When building a request-uri containing an E.164 number which does not "belong" or is >associated with a particular domain name then the most desirable action is to place a tel: >URL in the outbound request-uri. However, if a tel URL cannot be generated or received for >whatever reason, then a SIP url must be used instead and a domain name must selected for >the url. > >The easiest option is to simply place the outbound proxy/destination's address or hostname >in the host portion. Eg "sip:+12135551234@;user=phone". I remember that >some people had some academic objections to this approach because the request-uri referred >to an "intermediate destination" rather than the final destination. That doesn't make sense to me. As long as a call traverses proxies, the request URI will always refer to intermediate destinations. I personally believe >that it is easy to ignore the domain name for the telephone subscriber case at a proxy >(that is you >simply treat a "user=phone" request-uri as a simple telephone number (ala tel URL) if the >domain name is that of the proxy's). With the new loop detection rules I don't believe >this creates any problems. This removes the objection due to the "intermediate >destination" concept. The interpretation of the LHS of the @ is entirely up to the administrator of the domain. A very common usage of that namespace is that any usernames that are purely numbers, and start with +, are E.164 formatted numbers, and should be handled in whatever way is appropraite for international phone numbers. So, the domain is not really ignored, nor should it be. It points to a server handling the domain which knows how to interpret the user portion of the URI in this way. [RFC] Sorry, "ignore" was a bad choice of words. Also, I believe this is a fairly common usage in real implementations. [RFC] Yes I also believe you are correct - this is what many people are doing currently. The purpose of my original email is try to correlate what should and what is being done. Also treating sip:+12135551234@proxyaddress (or UA address) and tel:+12135551234 synonymously is introducing some assumptions into the system - not necessarily bad but they do need to be considered (especially in multi-service-provider networks). Of course it's all a matter of local policy not protocol specification. >Alternatively, for E.164 numbers what do people think about allowing "sip:+12135551234 >@e164;user=phone"? e164 is the domain stem used by ENUM for doing DNS lookups of E.164 >numbers. In this case the host name of the sip URL correctly indicates that domain of the >user portion. Now, this I object to. I should be able to take a SIP URL, and always be able to route it somewhere for further processing. Thats why the domain name is mandatory. By using e164 as the domain, you would require every host to know the semantics of that and have proper handling for it. Yuck. [RFC] I agree. I only suggested it because of my perceived objections to this "intermediate destination" concept, which I also agree is an entirely valid concept! However, I think I slightly misinterpreted one of Henning's earlier statements about outbound proxies. Henning's answer to the question "When refering to [the Request-URI being the] current destination, does it mean the next hop destination or the current logical destination ?" is: "Current SIP destination. The outbound proxy is by definition not a SIP destination (with its own SIP URL). Thus, putting its address in the request URI makes no sense. I would prefer not to introduce yet another term ("logical destination"), as this increases complexity. The definition of the outbound proxy is that it differs from the Request-URI address, so I'm not sure how much confusion there can be. (If you stick the address of the proxy in the request-URI, it's no longer an outbound proxy.)" This is effectively the crux of what I am talking about. However, when I reread it, I think that the last bracketed sentence is allowing one to use the default outbound proxy address as the SIP URL domain name when requesting a proxy to route an "un-domained" telephone subscriber. However, in this case the default outbound proxy is no longer acting as an "outbound proxy" using Henning's definition of the term. To me, Henning's definition seems to be slightly at odds with the outbound proxy definition in http://search.ietf.org/internet-drafts/draft-ietf-sip-srv-02.txt : "Outbound proxy: A proxy that is located near the originator of requests. It receives all outgoing requests from a particular UAC, including those requests whose Request-URLs identify a host other than the outbound proxy. The outbound proxy sends these requests, after any local processing, to the address indicated in the Request-URI. (All other proxy servers are simply referred as proxies, not inbound proxies.)" Perhaps we need to describe this more clearly in a BCP somewhere, ie the interactions between the domain name, a telephone-subscriber and outbound proxies. That is, the difference between tel:+12135551234, sip:+12135551234@proxyaddress;user=phone (or UA address) and sip:+12135551234@calldomain;user=phone. Cheers, Robert. ------_=_NextPart_001_01C0ED0D.07CB5DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] E.164 request-uri domain's.

Thanks for the reply.

Comments below.

-----Original = Message-----
From:   Jonathan = Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent:   Sunday, June 03, 2001 6:43 AM
To:     'Fairlie-Cuninghame, Robert'; = 'sip@lists.bell-labs.com'
Subject:       = RE: [SIP] E.164 request-uri = domain's.



 
-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]=
Sent: Saturday, June 02, 2001 11:26 = AM
To: 'sip@lists.bell-labs.com'
Subject: [SIP] E.164 request-uri = domain's.


>Hi,
>
>We have had this discussion quite = a few times but I thought I would throw
in a new idea.
>
>When building a request-uri = containing an E.164 number which does not
"belong" or is
>associated with a particular = domain name then the most desirable action is
to place a tel:
>URL in the outbound request-uri. = However, if a tel URL cannot be generated
or received for
>whatever reason, then a SIP url = must be used instead and a domain name must
selected for
>the url.
>
>The easiest option is to simply = place the outbound proxy/destination's
address or hostname
>in the host portion. Eg = "sip:+12135551234@<proxy hostname>;user=3Dphone". = I
remember that
>some people had some academic = objections to this approach because the
request-uri referred
>to an "intermediate = destination" rather than the final destination.

That doesn't make sense to me. As long = as a call traverses proxies, the
request URI will always refer to = intermediate destinations.

I personally believe
>that it is easy to ignore the = domain name for the telephone subscriber case
at a proxy
>(that is you
>simply treat a = "user=3Dphone" request-uri as a simple telephone number = (ala
tel URL) if the
>domain name is that of the = proxy's). With the new loop detection rules I
don't believe
>this creates any problems. This = removes the objection  due to the
"intermediate
>destination" concept. =

The interpretation of the LHS of the @ = is entirely up to the administrator
of the domain. A very common usage of = that namespace is that any usernames
that are purely numbers, and start = with +, are E.164 formatted numbers, and
should be handled in whatever way is = appropraite for international phone
numbers. So, the domain is not really = ignored, nor should it be. It points
to a server handling the domain which = knows how to interpret the user
portion of the URI in this way. =

[RFC] Sorry, "ignore" was a bad choice = of words.


Also, I believe this is a fairly = common usage in real implementations.


[RFC] Yes I also believe you are correct - this is what many people are doing = currently. = The purpose of my original email is = try to = correlate what should = and what is being = done. =

Also treating sip:+12135551234@proxyaddress (or UA address) and = tel:+12135551234 synonymously is introducing some assumptions into the = system - not = necessarily bad but they do need to be considered (especially in multi-service-provider = networks). Of course = it's all a matter of local policy not protocol specification.


>Alternatively, for E.164 numbers = what do people think about allowing
"sip:+12135551234
>@e164;user=3Dphone"? e164 is = the domain stem used by ENUM for doing DNS
lookups of E.164
>numbers. In this case the host = name of the sip URL correctly indicates that
domain of the
>user portion.

Now, this I object to. I should be = able to take a SIP URL, and always be
able to route it somewhere for = further processing. Thats why the domain name
is mandatory. By using e164 as the = domain, you would require every host to
know the semantics of that and have = proper handling for it. Yuck.

[RFC] I agree. I only suggested it because of my perceived = objections to = this "intermediate destination" concept, which I also agree is an = entirely valid concept! However, I think I slightly misinterpreted one of Henning's earlier statements about outbound = proxies.

Henning's answer to the question "When refering to = [the Request-URI being the] current destination, does it mean the = next hop destination or the current logical destination ?" is:

      "Current SIP = destination. The outbound proxy is by definition not a SIP
      destination (with its own SIP URL). Thus, putting its address in = the
      request URI makes no sense. I would prefer not to introduce yet = another
      term ("logical destination"), as this increases complexity. = The
      definition of the outbound proxy is that it differs from the = Request-URI
      address, so I'm not sure how much confusion there can be. (If you = stick
      the address of the proxy in the request-URI, it's no longer an = outbound
      proxy.)"

This = is effectively the crux of what I am talking about. However, when I reread = it, I = think that the last bracketed sentence is allowing = one = to use = the default outbound proxy address as the = SIP URL = domain name = when requesting a proxy to route an "un-domained" telephone subscriber. However, in this case the = default outbound proxy is no longer acting as = an "outbound proxy" using Henning's definition of the = term.

To = me, Henning's definition seems to be slightly at odds = with the = outbound proxy definition in http://search.ietf.org/internet-drafts/draft-ietf-sip-srv= -02.txt :

"Outbound = proxy: A proxy that is located near the originator of requests. It = receives all outgoing requests from a particular UAC, including those = requests whose Request-URLs identify a host other than the outbound = proxy. The outbound proxy sends these requests, after any local = processing, to the address indicated in the Request-URI. (All other = proxy servers are simply referred as proxies, not inbound = proxies.)"

Perhaps we need = to describe this more clearly in a BCP somewhere, ie the = interactions between the domain name, a = telephone-subscriber and outbound proxies. That is, the difference between tel:+12135551234, = sip:+12135551234@proxyaddress;user=3Dphone (or UA address) and sip:+12135551234@calldomain;user=3Dphone.


Cheers,

Robert.

------_=_NextPart_001_01C0ED0D.07CB5DE0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Jun 4 12:01:42 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11216 for ; Mon, 4 Jun 2001 12:01:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9AA9944337; Mon, 4 Jun 2001 12:02:06 -0400 (EDT) Delivered-To: sip@lists.bell-labs.com Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by lists.bell-labs.com (Postfix) with ESMTP id 1DFCE44336 for ; Mon, 4 Jun 2001 12:01:28 -0400 (EDT) Received: from m2hub.mail.wipro.com (m2hub.wipro.com [164.164.27.50]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with ESMTP id f54LdvZ21786 for ; Mon, 4 Jun 2001 21:40:02 GMT Received: from m2vwall2.wipro.com ([164.164.27.52]) by m2hub.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GEEXLC00.P25 for ; Mon, 4 Jun 2001 21:26:00 +0530 Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GEEVAQ00.P4H; Mon, 4 Jun 2001 20:36:26 +0530 Received: from wipro.com (mmcsview.wipsys.soft.net [164.164.8.211]) by wslexch.wipsys.soft.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LNNA3H8W; Mon, 4 Jun 2001 20:47:51 +0530 Message-ID: <3B1C5351.92BED5B9@wipro.com> From: Varadarajan Srinivasan Organization: Wipro Technologies X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Baniel Uri-CUB001 Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Invitation for a multicast session References: <35DBB8B7AC89D4118E98009027B1009B0137E007@IL27EXM10.cig.mot.com> Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Jun 2001 09:05:41 +0531 --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="------------6AC0E9CB33D5D1090DC9C90A" --------------6AC0E9CB33D5D1090DC9C90A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi , I feel A's proxy will send ACK to B and CANCEL to C ( I read somewhere that CANCEL is of the same transaction as that of the INVITE). Regards, Varadarajan Baniel Uri-CUB001 wrote: > OK now it is really clear! Thanks!! > Anyways in case a "race" condition has happened and both stations (say B and > C) responded with a 200 OK. (i.e. despite of the delay-response and Cancel > mechanisms described in the spec), what is the correct behavior of the UAC? > Say he wants to accept B and reject C, does it need to Ack C (in order to > complete the 1st transaction) and then right away sends it a BYE? > (I know I am actually asking here a generic and probably a naive/basic > question regarding how a UAC should behave in case it does not want to > accept the 200...) > > ================================================================= > Uri.Baniel@motorola.com, > Tel: (847) 632 4616; Fax: (847) 632 3963; > "Only by learning do we discover how ignorant we are" E.w.c > ================================================================= > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Sunday, June 03, 2001 10:43 PM > > To: 'Baniel Uri-CUB001'; sip@lists.bell-labs.com > > Subject: RE: [SIP] Invitation for a multicast session > > > > > > > > > > > > > > > -----Original Message----- > > > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > > > Sent: Sunday, June 03, 2001 8:58 AM > > > To: 'Jonathan Rosenberg'; sip@lists.bell-labs.com > > > Subject: RE: [SIP] Invitation for a multicast session > > > > > > > > > So just to be 100% sure that I got this one right once and > > > for all... say I like to invite A, B, C and D who belong to > > > the same multicast group, to a conf call (mbone session). Say > > > I like to invite them by multicast means. > > > Do I have to multicast 4 Invites (each with a different > > > request-URI and To fields(e.g. A@example.com, B@example.com, > > > etc.,) or one multicast will do?? > > > > Sending the same request four times would completely defeat > > the purpose of > > using multicast in the first place. The whole idea with > > multicast is that > > you don't know how many recipients there are. So, the answer is "one > > multicast will do". > > > > If one will do, what will > > > be the request-URI? What will be the To? > > > Based on your message below I think we need 4 invitations, > > > but just to be on the safe side... > > > > INVITE sip:mygroup@domain.com SIP/2.0 > > From: "Me" > > To: "The Gaggle" > > Via: SIP/2.0/UDP 1.2.3.4;maddr=224.2.3.4;ttl=2 > > > > Of course, each user in the group would need to be prepared to accept > > request sfor mygroup@domain.com. Once one decides to accept, > > they send a 200 > > OK. This triggers a CANCEL by the UAC. As a result, the > > caller is connected > > to one of the members of this group, whomever it might be. > > What SIP cannot > > do is help you generate a request so that a call is connected > > to ALL members > > of the group (this really requires reliable multicast to > > avoid response > > implosion). You'll only get the first to answer. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. --------------6AC0E9CB33D5D1090DC9C90A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi ,

I feel A's proxy will send ACK to B and CANCEL to C ( I read somewhere that CANCEL
is of the same transaction as that of  the INVITE).

Regards,
Varadarajan
 

Baniel Uri-CUB001 wrote:

OK now it is really clear! Thanks!!
Anyways in case a "race" condition has happened and both stations (say B and
C) responded with a 200 OK. (i.e. despite of the delay-response and Cancel
mechanisms described in the spec), what is the correct behavior of the UAC?
Say he wants to accept B and reject C, does it need to Ack C (in order to
complete the 1st transaction) and then right away sends it a BYE?
(I know I am actually asking here a generic and probably a naive/basic
question regarding how a UAC should behave in case it does not want to
accept the 200...)

=================================================================
Uri.Baniel@motorola.com,
Tel: (847) 632 4616; Fax: (847) 632 3963;
"Only by learning do we discover how ignorant we are" E.w.c
=================================================================

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Sunday, June 03, 2001 10:43 PM
> To: 'Baniel Uri-CUB001'; sip@lists.bell-labs.com
> Subject: RE: [SIP] Invitation for a multicast session
>
>
>
>
>
>
> > -----Original Message-----
> > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com]
> > Sent: Sunday, June 03, 2001 8:58 AM
> > To: 'Jonathan Rosenberg'; sip@lists.bell-labs.com
> > Subject: RE: [SIP] Invitation for a multicast session
> >
> >
> > So just to be 100% sure that I got this one right once and
> > for all... say I like to invite A, B, C and D who belong to
> > the same multicast group, to a conf call (mbone session). Say
> > I like to invite them by multicast means.
> > Do I have to multicast 4 Invites (each with a different
> > request-URI and To fields(e.g. A@example.com, B@example.com,
> > etc.,) or one multicast will do??
>
> Sending the same request four times would completely defeat
> the purpose of
> using multicast in the first place. The whole idea with
> multicast is that
> you don't know how many recipients there are. So, the answer is "one
> multicast will do".
>
> If one will do, what will
> > be the request-URI? What will be the To?
> > Based on your message below I think we need 4 invitations,
> > but just to be on the safe side...
>
> INVITE sip:mygroup@domain.com SIP/2.0
> From: "Me" <sip:me@domain.com>
> To: "The Gaggle" <sip:mygroup@domain.com>
> Via: SIP/2.0/UDP 1.2.3.4;maddr=224.2.3.4;ttl=2
>
> Of course, each user in the group would need to be prepared to accept
> request sfor mygroup@domain.com. Once one decides to accept,
> they send a 200
> OK. This triggers a CANCEL by the UAC. As a result, the
> caller is connected
> to one of the members of this group, whomever it might be.
> What SIP cannot
> do is help you generate a request so that a call is connected
> to ALL members
> of the group (this really requires reliable multicast to
> avoid response
> implosion). You'll only get the first to answer.
>
> -Jonathan R.
>
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>

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


 

--------------6AC0E9CB33D5D1090DC9C90A--


--------------InterScan_NT_MIME_Boundary--


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


From sip-admin@lists.bell-labs.com  Mon Jun  4 12:05:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11322
	for ; Mon, 4 Jun 2001 12:05:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1D3C5443AD; Mon,  4 Jun 2001 12:06:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102])
	by lists.bell-labs.com (Postfix) with ESMTP id 2E1CF4438C
	for ; Mon,  4 Jun 2001 12:05:00 -0400 (EDT)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id JAA06937 for ; Mon, 4 Jun 2001 09:04:57 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA22101 for ; Mon, 4 Jun 2001 09:04:56 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 4 Jun 2001 11:04:56 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E00B@IL27EXM10.cig.mot.com>
From: Baniel Uri-CUB001 
To: "'Varadarajan Srinivasan'" ,
        Baniel Uri-CUB001 
Cc: "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Invitation for a multicast session
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 4 Jun 2001 11:04:53 -0500

According the spec after you get a 200 Ok you are not supposed to send an ACK but rather you should send a BYE...
 

================================================================= 
Uri.Baniel@motorola.com, 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
"Only by learning do we discover how ignorant we are" E.w.c 
================================================================= 

 

-----Original Message-----
From: Varadarajan Srinivasan [mailto:srinivasan.varada@wipro.com]
Sent: Monday, June 04, 2001 10:35 PM
To: Baniel Uri-CUB001
Cc: 'sip@lists.bell-labs.com'
Subject: Re: [SIP] Invitation for a multicast session


Hi , 

I feel A's proxy will send ACK to B and CANCEL to C ( I read somewhere that CANCEL 
is of the same transaction as that of  the INVITE). 


Regards, 
Varadarajan 
  


Baniel Uri-CUB001 wrote: 


OK now it is really clear! Thanks!! 
Anyways in case a "race" condition has happened and both stations (say B and 
C) responded with a 200 OK. (i.e. despite of the delay-response and Cancel 
mechanisms described in the spec), what is the correct behavior of the UAC? 
Say he wants to accept B and reject C, does it need to Ack C (in order to 
complete the 1st transaction) and then right away sends it a BYE? 
(I know I am actually asking here a generic and probably a naive/basic 
question regarding how a UAC should behave in case it does not want to 
accept the 200...) 

================================================================= 
Uri.Baniel@motorola.com, 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
"Only by learning do we discover how ignorant we are" E.w.c 
================================================================= 


> -----Original Message----- 
> From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com  ] 
> Sent: Sunday, June 03, 2001 10:43 PM 
> To: 'Baniel Uri-CUB001'; sip@lists.bell-labs.com 
> Subject: RE: [SIP] Invitation for a multicast session 
> 
> 
> 
> 
> 
> 
> > -----Original Message----- 
> > From: Baniel Uri-CUB001 [ mailto:Uri.Baniel@motorola.com  ] 
> > Sent: Sunday, June 03, 2001 8:58 AM 
> > To: 'Jonathan Rosenberg'; sip@lists.bell-labs.com 
> > Subject: RE: [SIP] Invitation for a multicast session 
> > 
> > 
> > So just to be 100% sure that I got this one right once and 
> > for all... say I like to invite A, B, C and D who belong to 
> > the same multicast group, to a conf call (mbone session). Say 
> > I like to invite them by multicast means. 
> > Do I have to multicast 4 Invites (each with a different 
> > request-URI and To fields(e.g. A@example.com, B@example.com, 
> > etc.,) or one multicast will do?? 
> 
> Sending the same request four times would completely defeat 
> the purpose of 
> using multicast in the first place. The whole idea with 
> multicast is that 
> you don't know how many recipients there are. So, the answer is "one 
> multicast will do". 
> 
> If one will do, what will 
> > be the request-URI? What will be the To? 
> > Based on your message below I think we need 4 invitations, 
> > but just to be on the safe side... 
> 
> INVITE sip:mygroup@domain.com SIP/2.0 
> From: "Me"  
> To: "The Gaggle"  
> Via: SIP/2.0/UDP 1.2.3.4;maddr=224.2.3.4;ttl=2 
> 
> Of course, each user in the group would need to be prepared to accept 
> request sfor mygroup@domain.com. Once one decides to accept, 
> they send a 200 
> OK. This triggers a CANCEL by the UAC. As a result, the 
> caller is connected 
> to one of the members of this group, whomever it might be. 
> What SIP cannot 
> do is help you generate a request so that a call is connected 
> to ALL members 
> of the group (this really requires reliable multicast to 
> avoid response 
> implosion). You'll only get the first to answer. 
> 
> -Jonathan R. 
> 
> --- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave. 
> Chief Scientist                             First Floor 
> dynamicsoft                                 East Hanover, NJ 07936 
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050 
> http://www.jdrosen.net                        PHONE: (973) 952-5000 
> http://www.dynamicsoft.com   
> 


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


  


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


From sip-admin@lists.bell-labs.com  Mon Jun  4 12:31:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12022
	for ; Mon, 4 Jun 2001 12:31:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 08EE34437C; Mon,  4 Jun 2001 12:32:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by lists.bell-labs.com (Postfix) with ESMTP id CF8B244336
	for ; Mon,  4 Jun 2001 12:31:22 -0400 (EDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA20881 for ; Mon, 4 Jun 2001 09:31:23 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA06965 for ; Mon, 4 Jun 2001 09:31:22 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 4 Jun 2001 11:31:22 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E00D@IL27EXM10.cig.mot.com>
From: Baniel Uri-CUB001 
To: "'Vijay Gurbani'" ,
        Baniel Uri-CUB001 
Cc: "'Varadarajan Srinivasan'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Invitation for a multicast session
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 4 Jun 2001 11:31:17 -0500

Yes, yes, sorry when I said ACK I meant Cancel...
Okay I think I have bombarded the list enough with this...

=================================================================
Uri.Baniel@motorola.com, 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
"Only by learning do we discover how ignorant we are" E.w.c
=================================================================



> -----Original Message-----
> From: Vijay Gurbani [mailto:vkg@lucent.com]
> Sent: Monday, June 04, 2001 11:27 AM
> To: Baniel Uri-CUB001
> Cc: 'Varadarajan Srinivasan'; 'sip@lists.bell-labs.com'
> Subject: Re: [SIP] Invitation for a multicast session
> 
> 
> Baniel Uri-CUB001 wrote:
> > 
> > According the spec after you get a 200 Ok you are not 
> supposed to send an 
> > ACK but rather you should send a BYE...
> 
> Nope; where in the spec does it say that?
> 
> If a UAC gets multiple 200 OK (INVITE), it should send an ACK 
> to all of them 
> to allow the INVITE transaction to complete.  It should then 
> send a BYE to 
> all call legs that it is not interested in, maintaining the 
> call legs it is 
> interested in.
> 
> This behavior is better specified in the latest (-03) bis.  
> See page 109 of
> the PDF version; notice the change bar towards the middle of the page.
> 
> Regards,
> 
> - vijay
> -- 
> Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
> Internet Software and eServices Group 
> Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
> Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: 
> +1 630 713 0184
> 

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


From sip-admin@lists.bell-labs.com  Mon Jun  4 12:42:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12258
	for ; Mon, 4 Jun 2001 12:42:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 962774437C; Mon,  4 Jun 2001 12:43:05 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id AD29444337
	for ; Mon,  4 Jun 2001 12:42:47 -0400 (EDT)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Jun  4 12:38:32 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id CC89744380; Mon,  4 Jun 2001 12:28:09 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ih2mail.ih.lucent.com (ih2mail.ih.lucent.com [135.1.241.39])
	by lists.bell-labs.com (Postfix) with ESMTP id 8C76F4437D
	for ; Mon,  4 Jun 2001 12:28:09 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA26681; Mon, 4 Jun 2001 11:28:06 -0500 (CDT)
Message-ID: <3B1BB6EE.A44168EE@lucent.com>
From: Vijay Gurbani 
Organization: Lucent Technologies/Bell Laboratories
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Baniel Uri-CUB001 
Cc: "'Varadarajan Srinivasan'" ,
        "'sip@lists.bell-labs.com'" 
Subject: Re: [SIP] Invitation for a multicast session
References: <35DBB8B7AC89D4118E98009027B1009B0137E00B@IL27EXM10.cig.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 04 Jun 2001 11:27:26 -0500
Content-Transfer-Encoding: 7bit

Baniel Uri-CUB001 wrote:
> 
> According the spec after you get a 200 Ok you are not supposed to send an 
> ACK but rather you should send a BYE...

Nope; where in the spec does it say that?

If a UAC gets multiple 200 OK (INVITE), it should send an ACK to all of them 
to allow the INVITE transaction to complete.  It should then send a BYE to 
all call legs that it is not interested in, maintaining the call legs it is 
interested in.

This behavior is better specified in the latest (-03) bis.  See page 109 of
the PDF version; notice the change bar towards the middle of the page.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

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


From sip-admin@lists.bell-labs.com  Mon Jun  4 14:20:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15105
	for ; Mon, 4 Jun 2001 14:20:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DC06E44337; Mon,  4 Jun 2001 14:21:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 2148644336
	for ; Mon,  4 Jun 2001 14:20:40 -0400 (EDT)
Received: from cowboys (localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f54IJmt10467;
	Mon, 4 Jun 2001 13:19:48 -0500
Message-ID: <006e01c0ed23$154efbf0$01000001@dynamicsoft.com>
From: "Dean Willis" 
To: "IETF SIPPING" , "IETF SIP" ,
        "IETF OLD SIP (E-mail)" 
Cc: "Scott Bradner (E-mail)" ,
        "Allison Mankin (E-mail)" 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [SIP] Warmed-over supplemental web site draft
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 4 Jun 2001 13:20:49 -0500
Content-Transfer-Encoding: 7bit

I've just spent the last couple of days in a major cleanup of the SIPWG
supplemental web site. The new version is much more automated, includes
SIPPING, and includes automated draft indexing and linking to subteams
(Henning beat me up many times here). I've also implemented the current
thinking on division of labor between SIP and SIPPING. Also, I've linked in
a "morgue" (it's a newspaper term) area for the expired drafts of each
working group -- those of you looking for the old call-control draft, it's
in the morgue.

I'm still trying to figure out indexing using htdig. Henry's beat me up many
times on this one . . .

The new stuff can be seen at http://bdsl.greycouncil.com/sipwg and
http://bdsl.greycouncil.com/sipping


I'll leave the old material in place at www.softarmor.com/sipwg for a while.
If all goes well, I'll replace the old stuff with the new stuff in a week or
so.

WHAT I NEED YOU TO DO:

1) Look through the new site and find the stuff you're interested in. Make
sure it's there.
2) Check your names and team memberships and the drafts for your teams.
3) Don't worry about the last-call calendars for a few more days. Rakesh is
working on them.

If confused or in error, please contact me.

Thanks.

--
Dean



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


From sip-admin@ietf.org  Mon Jun  4 14:25:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15205;
	Mon, 4 Jun 2001 14:25:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02587;
	Mon, 4 Jun 2001 14:20:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02528
	for ; Mon, 4 Jun 2001 14:20:40 -0400 (EDT)
Received: from kevlar.softarmor.com ([63.64.250.82])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15101;
	Mon, 4 Jun 2001 14:20:14 -0400 (EDT)
Received: from cowboys (localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f54IJmt10467;
	Mon, 4 Jun 2001 13:19:48 -0500
Message-ID: <006e01c0ed23$154efbf0$01000001@dynamicsoft.com>
From: "Dean Willis" 
To: "IETF SIPPING" , "IETF SIP" ,
        "IETF OLD SIP \(E-mail\)" 
Cc: "Scott Bradner \(E-mail\)" ,
        "Allison Mankin \(E-mail\)" 
Date: Mon, 4 Jun 2001 13:20:49 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [Sip] Warmed-over supplemental web site draft
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I've just spent the last couple of days in a major cleanup of the SIPWG
supplemental web site. The new version is much more automated, includes
SIPPING, and includes automated draft indexing and linking to subteams
(Henning beat me up many times here). I've also implemented the current
thinking on division of labor between SIP and SIPPING. Also, I've linked in
a "morgue" (it's a newspaper term) area for the expired drafts of each
working group -- those of you looking for the old call-control draft, it's
in the morgue.

I'm still trying to figure out indexing using htdig. Henry's beat me up many
times on this one . . .

The new stuff can be seen at http://bdsl.greycouncil.com/sipwg and
http://bdsl.greycouncil.com/sipping


I'll leave the old material in place at www.softarmor.com/sipwg for a while.
If all goes well, I'll replace the old stuff with the new stuff in a week or
so.

WHAT I NEED YOU TO DO:

1) Look through the new site and find the stuff you're interested in. Make
sure it's there.
2) Check your names and team memberships and the drafts for your teams.
3) Don't worry about the last-call calendars for a few more days. Rakesh is
working on them.

If confused or in error, please contact me.

Thanks.

--
Dean



_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jun  4 21:20:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22617
	for ; Mon, 4 Jun 2001 21:20:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D633844337; Mon,  4 Jun 2001 21:21:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214])
	by lists.bell-labs.com (Postfix) with ESMTP id 9189B44336
	for ; Mon,  4 Jun 2001 21:20:55 -0400 (EDT)
Received: from mailgate4.nec.co.jp ([10.7.69.195])
	by TYO201.gate.nec.co.jp (8.11.3/3.7W01041220) with ESMTP id f551KrQ16482
	for ; Tue, 5 Jun 2001 10:20:53 +0900 (JST)
Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.3/3.7W-MAILGATE-NEC) with ESMTP
	id f551KkN22584 for ; Tue, 5 Jun 2001 10:20:46 +0900 (JST)
Received: from mgw1.netlab.nec.co.jp (mgw1.netlab.nec.co.jp [133.201.4.10]) by mailsv.nec.co.jp (8.11.3/3.7W-MAILSV-NEC) with ESMTP
	id f551KeY13922 for ; Tue, 5 Jun 2001 10:20:42 +0900 (JST)
Received: from mail.netlab.nec.co.jp (mail.netlab.nec.co.jp [172.16.3.22])
	by mgw1.netlab.nec.co.jp (8.9.3/3.7W-MGW1_NETLAB) with ESMTP id KAA25094
	for ; Tue, 5 Jun 2001 10:20:39 +0900 (JST)
Received: from splpe792.netlab.nec.co.jp (splpe792.netlab.nec.co.jp [172.16.161.39])
	by mail.netlab.nec.co.jp (8.9.3/3.7W-MAIL.NETLAB) with ESMTP id KAA07320
	for ; Tue, 5 Jun 2001 10:20:39 +0900 (JST)
Received: from splwp25 (splwp25.netlab.nec.co.jp [172.16.4.31])
	by splpe792.netlab.nec.co.jp (8.9.3/3.7W06/29/00) with ESMTP id KAA42924
	for ; Tue, 5 Jun 2001 10:20:38 +0900 (JST)
From: Takuya Murakami 
To: sip@lists.bell-labs.com
Subject: [SIP] bis03 : IPv6 address?
Message-Id: <20010605100902.462E.MURAKAMI@da.jp.nec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.00
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 05 Jun 2001 10:20:24 +0900
Content-Transfer-Encoding: 7bit

Hello all,

I have comment on -bis-03 draft.

In the section 2, the IPv6reference and IPv6address were removed. Why?
I believe we need them.

And there is no description about this in section I.

-----
Takuya Murakami
  tmurakam@netlab.nec.co.jp


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


From sip-admin@lists.bell-labs.com  Tue Jun  5 03:33:44 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12597
	for ; Tue, 5 Jun 2001 03:33:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E305E44337; Tue,  5 Jun 2001 03:34:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from india.mercurykr.com (unknown [165.133.13.60])
	by lists.bell-labs.com (Postfix) with ESMTP id B224D44336
	for ; Tue,  5 Jun 2001 03:33:19 -0400 (EDT)
Received: from pushkar (Param [165.133.13.33])
	by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id MAA05150
	for ; Tue, 5 Jun 2001 12:56:49 -0600 (GMT)
Message-ID: <001901c0ed91$d1562b20$210d85a5@dti.daewoo.co.kr>
From: "Ashwani Kumar Kesharwani" 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0016_01C0EDBF.E845D140"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [SIP] (no subject)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 5 Jun 2001 13:03:25 +0530

This is a multi-part message in MIME format.

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

Hi

If a redirect server receives a REGISTER request what should it do?

If it redirects to UAC then what should be the contact address.


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









Hi


 


If a redirect server receives a =
REGISTER request=20
what should it do?


 


If it redirects to UAC then what should =
be the=20
contact address.


 


------=_NextPart_000_0016_01C0EDBF.E845D140--


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


From sip-admin@lists.bell-labs.com  Tue Jun  5 05:15:47 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13605
	for ; Tue, 5 Jun 2001 05:15:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 11F7D44337; Tue,  5 Jun 2001 05:16:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from india.mercurykr.com (unknown [165.133.13.60])
	by lists.bell-labs.com (Postfix) with ESMTP id 5299644336
	for ; Tue,  5 Jun 2001 05:14:49 -0400 (EDT)
Received: from pushkar (Param [165.133.13.33])
	by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id OAA07185;
	Tue, 5 Jun 2001 14:36:53 -0600 (GMT)
Message-ID: <002401c0ed9f$cd7bcec0$210d85a5@dti.daewoo.co.kr>
From: "Ashwani Kumar Kesharwani" 
To: "kanumuri sreeram" 
Cc: 
References: <20010605090251.92962.qmail@web14205.mail.yahoo.com>
Subject: Re: [SIP] (no subject)
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0021_01C0EDCD.E24AB7C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 5 Jun 2001 14:43:28 +0530

This is a multi-part message in MIME format.

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

I am asking that normally when a redirect server receives an INVITE =
request from a UAC it contacts the location service, and after getting =
current location of recipient of the message it return these addressess =
to UAC with contact headers.

Now instead of INVITE if UAC sends REGISTER request and redirect server =
receives it then what will be its processing .


My second question is , can a registrar also registers itself.



  ----- Original Message -----=20
  From: kanumuri sreeram=20
  To: Ashwani Kumar Kesharwani=20
  Sent: Tuesday, June 05, 2001 2:32 PM
  Subject: Re: [SIP] (no subject)


  hi ashwani,=20

  can u make me clear ur question again.=20

  Regards,=20

  sreeram=20

    Ashwani Kumar Kesharwani  wrote:=20

    Hi

    If a redirect server receives a REGISTER request what should it do?

    If it redirects to UAC then what should be the contact address.





-------------------------------------------------------------------------=
-----
  Do You Yahoo!?
  Yahoo! Mail Personal Address - Get email at your own domain with =
Yahoo! Mail.

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







I am asking that normally when a =
redirect server=20
receives an INVITE request from a UAC it contacts the location =
service, and=20
after getting current location of recipient of the message it return =
these=20
addressess to UAC with contact headers.


 


Now instead of INVITE if UAC sends =
REGISTER request=20
and redirect server receives it then what will be its processing =
.


 


 


My second question is , can a registrar =
also=20
registers itself.


 


 


 


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

  From:=20
  kanumuri=20
  sreeram 
  
  
Sent: Tuesday, June 05, 2001 =
2:32=20
PM

  
Subject: Re: [SIP] (no =
subject)

  


  
hi ashwani,=20
  
can u make me clear ur question again.=20
  
Regards,=20
  
sreeram=20
  
  Ashwani Kumar Kesharwani <ashwani@india.mercurykr.com>=20
  wrote:=20
  
    
    

    
Hi

    
 

    
If a redirect server receives a =
REGISTER=20
    request what should it do?

    
 

    
If it redirects to UAC then what =
should be the=20
    contact address.

    
 

  


  

  Do You Yahoo!?
Yahoo! =
Mail Personal=20
  Address - Get email at your own domain with Yahoo!=20
Mail.

------=_NextPart_000_0021_01C0EDCD.E24AB7C0--


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


From sip-admin@lists.bell-labs.com  Tue Jun  5 09:48:43 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20682
	for ; Tue, 5 Jun 2001 09:48:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E506544337; Tue,  5 Jun 2001 09:49:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.inetmail.att.net (mailhost2.inetmail.att.net [204.127.132.34])
	by lists.bell-labs.com (Postfix) with ESMTP id 022BF44336
	for ; Tue,  5 Jun 2001 09:48:24 -0400 (EDT)
Received: from ashok ([12.41.17.196])
          by mail.inetmail.att.net (mtiagic02) with SMTP
          id <20010605134824gi2031853he>; Tue, 5 Jun 2001 13:48:25 +0000
Message-ID: <003301c0edc7$5e02f1e0$c411290c@masconit.com>
Reply-To: "Ranjit Avasarala" 
From: "Ranjit Avasarala" 
To: "Ashwani Kumar Kesharwani" ,
        "kanumuri sreeram" 
Cc: 
References: <20010605090251.92962.qmail@web14205.mail.yahoo.com> <002401c0ed9f$cd7bcec0$210d85a5@dti.daewoo.co.kr>
Subject: Re: [SIP] (no subject)
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002F_01C0ED9D.74AE4400"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 5 Jun 2001 08:56:48 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_002F_01C0ED9D.74AE4400
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Ashwani, see my comments inline...

Regards
Ranjit
Mascon Communication Technologies
http://www.masconit.com






  ----- Original Message -----
  From: Ashwani Kumar Kesharwani
  To: kanumuri sreeram
  Cc: sip@lists.bell-labs.com
  Sent: Tuesday, June 05, 2001 4:13 AM
  Subject: Re: [SIP] (no subject)


  I am asking that normally when a redirect server receives an INVITE
request from a UAC it contacts the location service, and after getting
current location of recipient of the message it return these addressess to
UAC with contact headers.

  Now instead of INVITE if UAC sends REGISTER request and redirect server
receives it then what will be its processing .

  usually register requests are sent to registrar. So if ur redirect server
receives a register request, either it could forward the request
  to registrar or discard it.

  My second question is , can a registrar also registers itself.

  ya there will be a entry in the registrar specifying who the registrar is.

   HTH
    ----- Original Message -----
    From: kanumuri sreeram
    To: Ashwani Kumar Kesharwani
    Sent: Tuesday, June 05, 2001 2:32 PM
    Subject: Re: [SIP] (no subject)


    hi ashwani,

    can u make me clear ur question again.

    Regards,

    sreeram

      Ashwani Kumar Kesharwani  wrote:

      Hi

      If a redirect server receives a REGISTER request what should it do?

      If it redirects to UAC then what should be the contact address.





----------------------------------------------------------------------------
    Do You Yahoo!?
    Yahoo! Mail Personal Address - Get email at your own domain with Yahoo!
Mail.

------=_NextPart_000_002F_01C0ED9D.74AE4400
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Ashwani, see my =
comments=20
inline...


 


Regards
Ranjit
Mascon Communication Technologies
http://www.masconit.com


 


 


 


 


 


 


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

  From:=20
  Ashwani Kumar Kesharwani =

  
  
Cc: sip@lists.bell-labs.com 

  
Sent: Tuesday, June 05, 2001 =
4:13=20
AM

  
Subject: Re: [SIP] (no =
subject)

  


  
I am asking that normally when a =
redirect server=20
  receives an INVITE request from a UAC it contacts the location =
service,=20
  and after getting current location of recipient of the message it =
return these=20
  addressess to UAC with contact headers.

  
 

  
Now instead of INVITE if UAC sends =
REGISTER=20
  request and redirect server receives it then what will be its =
processing=20
  .

  
 

  
usually =
register requests=20
  are sent to registrar. So if ur redirect server receives a register =
request,=20
  either it could forward the request 

  
to registrar =
or discard=20
  it. 

  
 

  
My second question is , can a =
registrar also=20
  registers itself.

  
 

  
ya there will =
be a entry=20
  in the registrar specifying who the registrar is. =


  
 

  
 HTH

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

    From:=20
    kanumuri=20
    sreeram 
    
To: Ashwani Kumar Kesharwani =


    
Sent: Tuesday, June 05, 2001 =
2:32=20
    PM

    
Subject: Re: [SIP] (no =
subject)

    


    
hi ashwani,=20
    
can u make me clear ur question again.=20
    
Regards,=20
    
sreeram=20
    
  Ashwani Kumar Kesharwani <ashwani@india.mercurykr.com>=20
    wrote:=20
    
      
      

      
Hi

      
 

      
If a redirect server receives a =
REGISTER=20
      request what should it do?

      
 

      
If it redirects to UAC then what =
should be=20
      the contact address.

      
 

    


    

    Do You Yahoo!?
Yahoo! =
Mail=20
    Personal Address - Get email at your own domain with Yahoo!=20
  Mail.

------=_NextPart_000_002F_01C0ED9D.74AE4400--


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


From sip-admin@lists.bell-labs.com  Tue Jun  5 10:01:47 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21084
	for ; Tue, 5 Jun 2001 10:01:46 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E49FE44396; Tue,  5 Jun 2001 10:02:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 022A944336; Tue,  5 Jun 2001 01:29:28 -0400 (EDT)
Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92])
	by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id WAA09672;
	Mon, 4 Jun 2001 22:27:30 -0700
Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id WAA20780; Mon, 4 Jun 2001 22:27:29 -0700
Message-ID: <3B1C6DEA.477A8786@hursley.ibm.com>
From: Brian E Carpenter 
Organization: IBM
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en,fr
MIME-Version: 1.0
To: "Roy, Radhika R, ALCTA" 
Cc: gratta@lucent.com, sob@harvard.edu, mankin@isi.edu, diffserv@ietf.org,
        iptel@lists.bell-labs.com, issll@mercury.lcs.mit.edu, megaco@fore.com,
        sip@lists.bell-labs.com, sipping@ietf.org, tsvwg@ietf.org,
        Yukio Hiramatsu , rbuhrke@lucent.com,
        tsg11q8@ties.itu.ch, tsg11q9@ties.itu.ch,
        ITU-SG16@mailbag.cps.INTEL.COM
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: [Diffserv] [IPTEL] RE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL
 MECHANISM FOR END-TO-END QOS SERVICE CONTROL
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 05 Jun 2001 00:28:10 -0500
Content-Transfer-Encoding: 7bit

Hey! I asked people to STOP including diffserv@ietf.org on this thread.

Please take notice everybody. Diffserv doesn't want to know. It is not
our business. Talk about this somewhere else. Really.

Brian Carpenter
diffserv co-chair

"Roy, Radhika R, ALCTA" wrote:
> 
> Hi, Everyone:
> 
> Question Q.F/16 of ITU-T SG16 is fully dedicated for developing standards
> for "End-to-End QOS for Multimedia Applications". Contributions are also
> being under discussion in the ITU-T SG16 Brazil May 28 - June 8, 2001
> meeting.
> 
> Applications like H.323, SIP, H.324, H.310, and others will also be able to
> use this Q.F/16's QOS signaling protocol. MEGACO/H.248 and BICC will also be
> able to use this when specs are fully developed and, TIPHON's QOS mechanisms
> can also be used as one of the mechanisms for implementations.
> 
> BICC and MEGCAO/H.248 are only used as the protocol between the gateways,
> NOT end-to-end (although SIP/H.323 or other protocols may be used between
> the gateways).
> 
> The "End-to-End QOS for Multimedia Applications" of SG16 can also be termed
> as "Application Layer QOS."
> 
> Q.F/16's end-to-end application layer QOS can also be implemented over the
> network layer QOS like RSVP, DiffServe, and/or MPLS after proper mapping.
> Similar is the case for the ATM network.
> 
> Please note that the network layer QOS (e.g., RSVP, DiffServe, and/or MPLS)
> may or may not have the end-to-end significance. For example, an IP network
> may implement different QOS schemes in different domains (e.g., RVSP in one
> domain, DiffServ in another domain).
> 
> However, the application layer QOS is end-to-end that remains the same. For
> example, an H.323 or SIP call that can traverse several IP domains where
> each domain may implement its own network layer QOS schemes while the
> H.323/SIP call carry the signaling messages and QOS parameters end-to-end
> independent of the underlying network layer QOS mechanisms.
> 
> Let us work together.
> 
> Best regards,
> Radhika R. Roy
> AT&T
> 
> -----Original Message-----
> From: Greg Ratta [mailto:gratta@lucent.com]
> Sent: Wednesday, May 30, 2001 4:22 PM
> To: sob@harvard.edu; mankin@isi.edu
> Cc: diffserv@ietf.org; iptel@lists.bell-labs.com; issll@mercury.lcs.mit.edu;
> megaco@fore.com; sip@lists.bell-labs.com; sipping@ietf.org; tsvwg@ietf.org;
> Yukio Hiramatsu; rbuhrke@lucent.com; tsg11q8@ties.itu.ch;
> tsg11q9@ties.itu.ch
> Subject: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
> END-TO-END QOS SERVICE CONTROL
> 
> This message was agreed to at ITU-T Study Group 11 meeting (Geneva, May
> 2001) and is being transmitted on behalf of Yukio Hiramatsu, Chairman of
> ITU-T SG 11. For further technical clarification, contact the Rapporteur for
> Q9/11 (Rolfe Buhrke, Tel: + 1 630 713 7022, { HYPERLINK
> mailto:rburke@lucent.com }rbuhrke@lucent.com)
> 
> FULL TITLE: PROPOSED JOINT ACTIVITY ON A GENERIC PROTOCOL MECHANISM FOR
> END-TO-END QOS SERVICE CONTROL AND SIGNALLING PROTOCOL DEVELOPMENT BASED ON
> IP TRANSFER CAPABILITIES AND IP QOS CLASSES
> 
> General
> 
> Within ITU-T SG11 work has started on requirements for a generic protocol
> mechanism for end-to-end QoS service control. It was agreed within SG11 to
> proceed with this work utilising deliverables of ETSI TIPHON on end- to-end
> QoS service control as base material. It is the opinion of SG11 that this
> generic protocol mechanism for BICC intends to apply also to other protocols
> like SIP/SDP and H.323 next to generic extensions to the H.248/MEGACO
> protocol.
> 
> It was noted that also QoS related work is in progress in IETF. Please find
> attached an initial draft of the BICC CS3 signalling requirements for
> end-to-end QoS service control. Please note the rationale for this activity
> and the framework for end-to-end QoS service control and network QoS
> control. The framework illustrates the field of application of the QoS
> handling at different levels and the different protocols involved.
> 
> Proposals on end-to-end QoS service control
> 
> It is proposed to start a joint activity with IETF on a generic protocol
> mechanism for end- to-end QoS service control. This refers to the potential
> work in IETF on the following topics:
> 
> - Identification of the signalling requirements based on the ETSI TIPHON
> defined speech QoS service classes for VoIP and the signalling and control
> of end-to-end QoS for VoIP. The attachment provides the initial draft of the
> BICC CS3 signalling requirements for end-to-end QoS service control.
> 
> - The definition of a generic call/bearer control mechanism in H.225/H.245,
> SIP/SDP and BICC CS3 for end-to-end QoS service control in the application
> plane.
> 
> - The definition of generic extensions to H.248/MEGACO for end-to-end QoS
> service control between the application plane and the transport plane.
> 
> - The translation between the generic protocol QoS information elements in
> H.248/MEGACO and the technology specific QoS parameters and QoS mechanisms
> in IP, ATM, MPLS, etc.
> 
> Proposals on IP QoS classes and IP Transfer Capabilities
> 
> ITU-T SG11 would like to inform IETF that it is investigating signalling
> requirements for protocol development based on the IP Transfer Capabilities
> and IP QoS classes, as being defined by ITU-T SG13 in Y.1541 and Y.iptc. The
> plan is to build upon signalling approaches developed by IETF. We would like
> to stress that the work on IP QoS classes and IP Transfer Capabilities by
> ITU-T SG13 is co- ordinated with IETF.
> 
> ATTACHMENT      Initial draft text of the BICC CS3 signalling requirements
> for end-to-end QoS service control.
> 
> The ETSI specifications referenced as base material are available at the
> following URLs:
> 
> ETSI TS 301 329 part 2, http://docbox.etsi.org/tech-
> org/tiphon/Document/tiphon/07- drafts/wg5/_Published/DTS05009/V1.1.1/ts_10
> 1329-2v111p.doc
> 
> - ETSI TS 301 329 part 3 see http://docbox.etsi.org/tech-
> org/tiphon/Document/tiphon/07-
> drafts/wg5/_Published/DTS05003/DTS05003v096.zi p
> 
> Further information about the ETSI TIPHON project is available at the
> following URL:
> 
> - http://webapp.etsi.org/tbhomepage/TBDetails.as p?TB_ID=291&TB_NAME=TIPHON
> 
> __________________
> 
> BICC CS3 signalling requirements for end-to- end QoS service control
> 
> EDITORS' NOTE:  This requirements text for end-to-end QoS service control is
> a first draft text and requires extensive updating based on liaison
> activities with other groups
> 
> 1 Rationale
> 
> The rationale of the BICC CS3 requirements for end-to-end service control is
> based on the analysis made by ETSI TIPHON (see the presentation available at
> the URL: http://docbox.etsi.org/tech-
> org/tiphon/Document/tiphon/ARCHIVES/2000/05- 200012-
> Kyoto/WG5%20TIPHON21%20presentation%20Rev1.ppt ). It shows the
> inter-relationship between the different QoS factors that finally determine
> 
> the perceived speech quality by the end- users. This perceived speech
> quality does not only depend on network quality of service (network packet
> loss, network jitter and network delay) but on the terminal implementation
> (jitter buffers and codec performance) as well.
> 
> A second rationale is that end-to-end QoS requirements can be regarded as
> end-to-end quality budgets related to the media flows. To achieve the
> required end-to-end QoS these quality budgets must be allocated between the
> domains, including the user equipment (see Figure 7 in ETSI TS 301 329 part
> 3). The Transport QoS Parameters specify the QoS budgets for each Transport
> Domain. It is assumed that the performance of each domain is statistically
> independent from any other.
> 
> Therefore end-to-end QoS service control at the call control level (i.e.
> application plane) is required based on generic signalling procedures in
> protocols like BICC, SIP/SDP, H.323 and H.248/MEGACO for end-to- end QoS
> service control.
> 
> 2 Framework for end-to-end QoS service control and network QoS control.
> 
> A framework for QoS control may be considered at different levels: call
> control (BICC, SIP/SDP, H.323), vertical control (H.248/MEGACO, CBC), bearer
> control (IP BCP) and bearer (DiffServ, IntServ/RSVP or MPLS/LDP).
> 
> 1) Call-control
> 
> a) End-to-end QoS service control is negotiated/communicated end-to-end at
> the call control level. ETSI TIPHON has defined a set of speech QoS classes,
> and signalling requirements and flows for this purpose.
> 
> The idea is that call control protocols are enhanced with a generic
> end-to-end QoS service control mechanism to negotiate these speech QoS
> classes and associated parameters (Maximum delay, Maximum packet delay
> variation, Maximum packet loss, Peak bit rate and Maximum packet size).
> 
> Such a generic end-to-end QoS service control mechanism should be defined
> independent of the underlying technology (ATM or IP) and operate across
> network domains and including terminal characteristics to
> negotiate/communicate the requested listener speech quality that will be
> perceived by the end-users (i.e. "mouth-to-ear").
> 
> b) BICC (Q.190x) is one of the call control protocols that may be enhanced
> this way. Similar enhancements may be applicable to other call-control
> protocols like SIP/SDP and H.323.
> 
> 2) Vertical control
> 
> a) QoS service control is also negotiated/communicated at the vertical
> control level. The ETSI TIPHON defined signalling requirements and flows
> include the vertical interface. The idea is that vertical control protocols
> are enhanced to negotiate/communicate the QoS settings (Maximum delay,
> Maximum packet delay variation, Maximum packet loss, Peak bit rate and
> Maximum packet size) in the bearer core network based on generic
> H.248/MEGACO extensions.
> 
> These QoS settings should be defined independent of the underlying
> technology (ATM or IP) of the bearer core network.
> 
> b) CBC (Q.1950) is one of the vertical control protocols that may be
> enhanced this way.
> 
> 3) Bearer control
> 
> a) Network QoS is negotiated/communicated at the bearer control level. ATM
> signalling does already intrinsically support network QoS. SG13 has recently
> defined IP QoS classes and IP Transfer Capabilities.
> 
> The idea is that bearer control protocols for IP are enhanced with a
> mechanism to negotiate the network QoS by using IP QoS classes and IP
> Transfer Capabilities.
> 
> b) IP BCP (Q.1970) is an IP bearer control protocol that may be enhanced
> this way.
> 
> 4) Bearer
> 
> a) Network QoS is negotiated/communicated at the bearer level, i.e. as part
> of the protocols associated with the bearers in the core network. The idea
> is that IP QoS classes and IP Transfer Capabilties, as defined by SG13, are
> used to differentiate between different types of IP traffic.
> 
> b) IP QoS classes and IP Transfer Capabilities may be used to enhance
> existing IP mechanisms like DiffServ, IntServ/RSVP and MPLS/LDP.
> 
> 3 QoS information flows applicable to BICC
> 
> A general model is considered for QoS information flows with BICC when
> making a translation of the relevant parts in Figure 8 in ETSI TS 301 329
> part 3.
> 
> Section 4 details the Q.BICC related QoS primitives and parameters based on
> the QoS primitives and parameters in the ETSI deliverable. Similarly,
> section 5 provides the Q.CBC related QoS primitives and parameters.
> 
> 4 Q.BICC related QoS primitives and parameters
> 
> The Q.BICC related QoS primitives and parameters are extracted from clause
> 8.1 and clause 8.2 of ETSI TS 101 329 part 3.
> 
> 4.1 Q.BICC related QoS primitives
> 
> This information flow (QC2 in ETSI TS 101 329 part 3) communicates the QoS
> related bearer information between the domains of different service
> providers.
> 
> Q.BICC QoS request (Qbicc.QoSreq) requests the establishment of a bearer
> conforming to a particular ETSI TIPHON Class of Service or with defined QoS
> characteristics.
> 
> NOTE    Identical to QoSM request (QC2.QoSMreq) in ETSI TS 101 329 part 3
> clause 8.1.1.
> 
> Q.BICC QoS confirm (Qbicc.QoSconf) acknowledges the creation of a bearer
> conforming to a requested ETSI TIPHON QoS Class or with specified QoS
> characteristics.
> 
> NOTE    Identical to QoSM confirm (QC2.QoSMconf) in ETSI TS 101 329 part 3
> clause 8.1.1.
> 
> Q.BICC QoS reject (Qbicc.QoSrej) rejects the creation of a bearer conforming
> to a requested ETSI TIPHON QoS Class or with specified QoS characteristics.
> 
> NOTE    Identical to QoSM reject (QC2.QoSMrej) in ETSI TS 101 329 part 3
> clause 8.1.1.
> 
> Q.BICC release request (Qbicc.QoSrelreq) requests the release of a bearer.
> 
> NOTE    Identical to QoSM release request (QC2.QoSMrelreq) in ETSI TS 101
> 329 part 3 clause 8.1.1 and the release of a transport flow is already
> covered by existing Q.BICC procedures in Q.1902 series.
> 
> QoSM release confirm (Qbicc.QoSrelconf) confirms the release of a bearer.
> 
> NOTE    Identical to QoSM release confirm (QC2.QoSMrelconf) in ETSI TS 101
> 329 part 3 clause 8.1.1 and the release of a transport flow is already
> covered by existing Q.BICC procedures in Q.1902 series.
> 
> 4.2 Q.BICC related QoS parameters
> 
> Table 1 lists the parameters used in the Q.BICC related QoS primitives not
> yet covered by the Q.BICC protocol. The deleted items refer to the
> information elements already covered by the BICC CS2 protocol in the Q.1902
> series.
> 
> NOTE    The contents of Table 1 is an interpretation of the table in ETSI TS
> 101 329 part 3 clause 8.2.3.
> 
> Table 1: Identification of Q.BICC related parameters for end-to-end QoS
> service control
> 
> Qbicc.QoSreq      QoS Service Class                 Optional
> 
>                   Codec Type and Packetisation          Mandatory
> 
>                   Transport QoS Parameters          Mandatory
> 
>                   Traffic Descriptor                    Optional
> 
>                   Transport Addresses                 Mandatory
> 
>                   Application Data Transport Protocol       Optional
> [Default RTP]
> 
>                   Packet Transport Protocol Optional [Default UDP]
> 
>                   QoS Mechanism                   Optional
> 
> Qbicc.QoSconf         QoS Service Class             Optional
> 
>                   Codec Type and Packetisation          Mandatory
> 
>                   Transport QoS Parameters          Mandatory
> 
>                   Transport Addresses                 Mandatory
> 
>                   Application Data Transport Protocol       Optional
> [Default RTP]
> 
>                   Packet Transport Protocol Optional [Default UDP]
> 
> Qbicc.QoSrej      Reason [TBD]                    Mandatory
> 
> 5 Q.CBC related QoS primitives and parameters
> 
> The Q.CBC related QoS primitives and parameters are extracted from clause
> 8.1 and clause 8.2 of ETSI TS 101 329 part 3.
> 
> 5.1 Q.CBC related QoS primitives
> 
> This information flow (QT2 in ETSI TS 101 329 part 3) communicates the QoS
> related transport flow information between a service domain and an
> associated transport domain. This information contains the QoS related
> characteristics required of the transport flows that will carry the media
> flow and the properties of the media flow.
> 
> Q.CBC QoS request (Qcbc.QoSreq) requests the establishment of a transport
> flow with defined QoS characteristics across a Transport Domain or the
> reservation of Transport Domain resource.
> 
> NOTE    Identical to TRM QoS request (QT2.TRMQreq) in ETSI TS 101 329 part 3
> clause 8.1.3.
> 
> Q.CBC QoS confirm (Qcbc.QoSconf) acknowledges the creation of a requested
> transport flow or the reservation of Transport Domain resource.
> 
> NOTE    Identical to TRM QoS confirm (QT2.TRMQconf) in ETSI TS 101 329 part
> 3 clause 8.1.3.
> 
> Q.CBC QoS reject (Qcbc.QoSrej) rejects the creation of a requested transport
> flow or the reservation of Transport Domain resource.
> 
> NOTE    Identical to TRM QoS reject (QT2.TRMQrej) in ETSI TS 101 329 part 3
> clause 8.1.3.
> 
> Q.CBC QoS release request (Qcbc.QoSrelreq) requests the release of a
> transport flow.
> 
> NOTE    Identical to TRM QoS release request (QT2.TRM QoS relreq) in ETSI TS
> 101 329 part 3 clause 8.1.3. The release of a transport flow is already
> covered by the existing Q.CBC procedures in Q.1950.
> 
> Q.CBC QoS release confirm (Qcbc.QoSrelconf) confirms the release of a
> transport flow.
> 
> NOTE    Identical to TRM QoS release confirm (QT2.TRM QoS relconf) in ETSI
> TS 101 329 part 3 clause 8.1.3. The release of a transport flow is already
> covered by the existing Q.CBC procedures in Q.1950.
> 
> Q.CBC QoS performance notification (Qcbc.QoSperfnotif) notifies the Service
> Domain of the performance of the Transport Domain in meeting the requested
> QoS levels. This may be a periodic event or an urgent alarm. Note: this
> primitive is a management primitive and its use is for further study.
> 
> NOTE    Identical to TRM QoS performance notification (QT2.TRM QoS
> perfnotif) in ETSI TS 101 329 part 3 clause 8.1.3. For further study.
> 
> 5.2 Q.CBC related QoS parameters
> 
> Table 2 lists the parameters used in the Q.CBC related QoS primitives not
> yet covered by the Q.CBC protocol. The deleted items refer to the
> information elements already covered by the BICC CS2 protocol in Q.1950.
> 
> NOTE    The contents of Table 2 is an interpretation of the table in ETSI TS
> 101 329 part 3 clause 8.2.5.
> 
> Table 2: Identification of Q.CBC related parameters for end-to-end QoS
> service control
> 
> QT2.TRMQreq         Transport QoS Parameters          Mandatory
> 
>                   Traffic Descriptor                    Mandatory
> 
>                   Transport Addresses                 Mandatory
> 
>                   Packet Transport Protocol Optional [Default UDP]
> 
> QT2.TRMQconf      Transport QoS Parameters              Mandatory
> 
>                   Transport Addresses                 Mandatory
> 
>                   Packet Transport Protocol Optional [Default UDP]
> 
>                   QoS Mechanism                   Optional
> 
> QT2.TRMQrej         Reason [TBD]                    Mandatory
> 
> 6 Parameter contents
> 
> Table 3 specifies the information to be covered by the parameters listed in
> sections 4.2 and 5.2 based on the QoS parameter groups in ETSI TS 101 329
> part 3 clause 8.2.1.
> 
> Table 3: Identification of parameter contents for end-to-end QoS service
> control
> 
> QoS Service Class       Describes the end-to-end ETSI TIPHON       Best,
> High, Medium
> 
>                   class of a beareror Best Effort
> 
> Transport QoS           Specifies the QoS characteristics          Maximum
> Delay
> 
> Parameters          required of the transport flow
> 
>                   carrying the media flow.                Maximum Packet
> Delay Variation
> 
>                                         Maximum Packet Loss
> 
> Traffic Descriptor          Characterises the resource           Peak Bit
> 
>                   requirements of an application data
> 
>                   flow (excludes transport flow       Maximum Packet Size
> 
>                   resource requirements).
> 
> Parameters specifying the ETSI TIPHON QoS Class as defined in ETSI TS 101
> 329 Part 2
> 
> The maximum delay permitted (ms) over either a segment of the transport flow
> or the remaining part of the transport flow.
> 
> The maximum packet delay variation permitted (ms) over either a segment of
> the transport flow or the remaining part of the transport flow.
> 
> The maximum packet loss permitted (%) over either a segment of the transport
> flow or the remaining part of the transport flow. [N.B. This measure assumes
> randomly distributed packet loss]
> 
> Maximum bit rate (bit/s) of the media flow.
> 
> Maximum size of the media packets
> 
> 7 Information flows and signalling procedures for end-to-end QoS service
> control
> 
> EDITORS' NOTE   The information flows and signalling procedures for
> end-to-end QoS service control may be considered to follow the same
> principles as the already existing procedures for end-to-end codec
> negotiation in BICC CS1 and BICC CS2. Similarly mid-call procedures for
> end-to-end QoS modification and mid-call QoS modification may be considered
> because the perceived QoS is highly related to the codec type employed end-
> to-end as part of the connection. The exact scope and properties of these
> procedures and protocol message flows needs further discussion.
> 
> Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and
> protocols
> 
> Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196,
> gratta@lucent.com
> 
> _______________________________________________
> IPTEL mailing list
> IPTEL@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 
> _______________________________________________
> diffserv mailing list
> diffserv@ietf.org
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org

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


From sip-admin@lists.bell-labs.com  Tue Jun  5 16:09:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29388
	for ; Tue, 5 Jun 2001 16:09:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B4FE14433D; Tue,  5 Jun 2001 16:10:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from web4801.mail.yahoo.com (web4801.mail.yahoo.com [216.115.105.199])
	by lists.bell-labs.com (Postfix) with SMTP id EA48D44337
	for ; Tue,  5 Jun 2001 16:09:48 -0400 (EDT)
Message-ID: <20010605200948.23283.qmail@web4801.mail.yahoo.com>
Received: from [65.15.28.6] by web4801.mail.yahoo.com; Tue, 05 Jun 2001 13:09:48 PDT
From: Jose Martinez 
Subject: Re: [SIP] (no subject)
To: Ashwani Kumar Kesharwani ,
        sip@lists.bell-labs.com
In-Reply-To: <001901c0ed91$d1562b20$210d85a5@dti.daewoo.co.kr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 5 Jun 2001 13:09:48 -0700 (PDT)

it will reply with a 409 Conflict or 403 Forbiden i
think.

jose
--- Ashwani Kumar Kesharwani
 wrote:
> Hi
> 
> If a redirect server receives a REGISTER request
> what should it do?
> 
> If it redirects to UAC then what should be the
> contact address.
> 
> 


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

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


From sip-admin@lists.bell-labs.com  Tue Jun  5 19:00:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01142
	for ; Tue, 5 Jun 2001 19:00:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 84C994433D; Tue,  5 Jun 2001 19:01:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id DB5AF44337
	for ; Tue,  5 Jun 2001 19:00:46 -0400 (EDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f55N0iN21908;
	Wed, 6 Jun 2001 01:00:44 +0200 (MEST)
Received: from lmf.ericsson.se (racom107052.am.ericsson.se [147.117.107.52])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id BAA09699;
	Wed, 6 Jun 2001 01:01:05 +0200 (MET DST)
Message-ID: <3B1D660C.D9C3990@lmf.ericsson.se>
From: Gonzalo Camarillo 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip 
Cc: Jon Peterson , adam.roach@ericsson.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] SUS/RES encapsulation
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 06 Jun 2001 02:06:52 +0300
Content-Transfer-Encoding: 7bit

Hello,

I have received some feedback regarding the ISUP SUS/RES sequence. In
the ISUP-SIP mapping draft it is recommended to send them inside a
re-INVITE with media on hold.

While everybody agrees that this should be the recommended behavior,
some folks would like to be able to send SUS/RES in INFO as well. They
would do so when they were not interested in putting the media on hold
(in SIP bridging situations for example).

How do people feel about outlining this possible behavior in the draft?

Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

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


From sip-admin@lists.bell-labs.com  Wed Jun  6 00:53:48 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07358
	for ; Wed, 6 Jun 2001 00:53:47 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0FBF74433D; Wed,  6 Jun 2001 00:54:11 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from india.mercurykr.com (unknown [165.133.13.60])
	by lists.bell-labs.com (Postfix) with ESMTP id 475FE44337
	for ; Wed,  6 Jun 2001 00:53:09 -0400 (EDT)
Received: from pushkar (Param [165.133.13.33])
	by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id KAA18367
	for ; Wed, 6 Jun 2001 10:16:34 -0600 (GMT)
Message-ID: <002f01c0ee44$8d9c6e40$210d85a5@dti.daewoo.co.kr>
From: "Ashwani Kumar Kesharwani" 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002C_01C0EE72.A4A47E60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [SIP] (no subject)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 6 Jun 2001 10:22:52 +0530

This is a multi-part message in MIME format.

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

Hi

When a request goes through more than one proxy how does a proxy decides =
about the next proxy.


Thanks

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









Hi


 


When a request goes through more than =
one proxy how=20
does a proxy decides about the next proxy.


 


 


Thanks


------=_NextPart_000_002C_01C0EE72.A4A47E60--


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


From sip-admin@lists.bell-labs.com  Wed Jun  6 01:55:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10538
	for ; Wed, 6 Jun 2001 01:55:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0CE2D4433D; Wed,  6 Jun 2001 01:56:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from india.mercurykr.com (unknown [165.133.13.60])
	by lists.bell-labs.com (Postfix) with ESMTP id 301E244337
	for ; Wed,  6 Jun 2001 01:51:19 -0400 (EDT)
Received: from pushkar (Param [165.133.13.33])
	by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id LAA19340
	for ; Wed, 6 Jun 2001 11:14:38 -0600 (GMT)
Message-ID: <001001c0ee4c$a980f560$210d85a5@dti.daewoo.co.kr>
From: "Ashwani Kumar Kesharwani" 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000D_01C0EE7A.C03E40E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [SIP] Multicasting
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 6 Jun 2001 11:20:54 +0530

This is a multi-part message in MIME format.

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

Can somebody explain me that if somebody wants to initiate a multicast =
conference then where is he going to put the maddr parameter in request =
URI or in Via header.

Second question is at what hop multicasting will take place i.e. at =
outgoing proxy or at the recipient domain.

Please clarify with some example.

Thanks

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









Can somebody explain me that if =
somebody wants to=20
initiate a multicast conference then where is he going to put the maddr=20
parameter in request URI or in Via header.


 


Second question is at what hop =
multicasting will=20
take place i.e. at outgoing proxy or at the recipient =
domain.


 


Please clarify with some =
example.


 


Thanks


------=_NextPart_000_000D_01C0EE7A.C03E40E0--


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


From sip-admin@lists.bell-labs.com  Wed Jun  6 07:41:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26113
	for ; Wed, 6 Jun 2001 07:41:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EEED84437A; Wed,  6 Jun 2001 07:42:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41])
	by lists.bell-labs.com (Postfix) with ESMTP id 29D194433D
	for ; Wed,  6 Jun 2001 07:41:02 -0400 (EDT)
Received: from m2hub.mail.wipro.com (m2hub.wipro.com [164.164.27.50])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with ESMTP id f56HJXZ11246
	for ; Wed, 6 Jun 2001 17:19:34 GMT
Received: from m2vwall2.wipro.com ([164.164.27.52]) by
          m2hub.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP
          id GEIAVA00.8V3 for ; Wed, 6 Jun 2001
          17:05:34 +0530 
Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by
          kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GEIB3X00.JR3 for ; Wed, 6 Jun
          2001 17:10:45 +0530 
Received: from wipro.com (mmcsview.wipsys.soft.net [164.164.8.211]) by wslexch.wipsys.soft.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id LNNAPNW6; Wed, 6 Jun 2001 17:22:15 +0530
Message-ID: <3B1EC619.70C0E955@wipro.com>
From: Varadarajan Srinivasan 
Organization: Wipro Technologies
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Subject: [SIP] Proxy - A basic question
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 07 Jun 2001 05:39:58 +0531


--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
 boundary="------------402B848DD83DD9C4D3F60071"

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

Hi,

From RFC, We are asked to look upon proxy as DNS sort.

Can I assume that UA "MUST"  be tagged to a proxy?
That is all calls to UA outside its domain should come via proxy?



Mr. Varadarajan Srinivasan,
Senior Systems Engineer,
Wipro Technologies.



--------------402B848DD83DD9C4D3F60071
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi,

From RFC, We are asked to look upon proxy as DNS sort.

Can I assume that UA "MUST"  be tagged to a proxy?

That is all calls to UA outside its domain should come via proxy?

 

 

Mr. Varadarajan Srinivasan,
Senior Systems Engineer,
Wipro Technologies.

 

--------------402B848DD83DD9C4D3F60071--


--------------InterScan_NT_MIME_Boundary--


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


From sip-admin@lists.bell-labs.com  Wed Jun  6 09:07:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29233
	for ; Wed, 6 Jun 2001 09:07:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F096A4437A; Wed,  6 Jun 2001 09:08:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by lists.bell-labs.com (Postfix) with ESMTP id F2B054433D
	for ; Wed,  6 Jun 2001 09:07:10 -0400 (EDT)
Received: from hsssun01.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f56D8Ig17373;
	Wed, 6 Jun 2001 18:38:23 +0530 (IST)
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id f56CdLD26406;
	Wed, 6 Jun 2001 18:09:27 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256A63.00446FEE ; Wed, 6 Jun 2001 17:57:31 +0530
X-Lotus-FromDomain: HSSBLR
From: seshashayi@hss.hns.com
To: "Ashwani Kumar Kesharwani" 
Cc: sip@lists.bell-labs.com
Message-ID: <65256A63.00446F56.00@sampark.hss.hns.com>
Subject: Re: [SIP] Multicasting
Mime-Version: 1.0
Content-type: multipart/mixed;
	Boundary="0__=SasRPtNnrkOYdD6D1fsgTp2JhfaU19DojlmFcY1wXYWUvxR6wBdT6REY"
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 6 Jun 2001 18:03:57 +0530

--0__=SasRPtNnrkOYdD6D1fsgTp2JhfaU19DojlmFcY1wXYWUvxR6wBdT6REY
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline




>Can somebody explain me that if somebody wants to initiate a multicast
conference then where is he going to put the >maddr parameter in request
URI or in Via header.

Regarding maddr parameter,according to the bis "A client that sends a
request to a multicast address must add the maddr parameter
to its Via header field and should add the ttl field".The maddr parameter
in the request-uri can be used by outbound proxy to send the
message to the the multicast address specified.

>Second question is at what hop multicasting will take place i.e. at
outgoing proxy or at the recipient domain.
 Where the multicating happens depends on the IGMP protocol .I don't know
whether i got you right?

Regds
Seshu







"Ashwani Kumar Kesharwani"  on 06/06/2001
11:20:54 AM

To:   sip@lists.bell-labs.com
cc:    (bcc: Seshashayi T/HSSBLR)

Subject:  [SIP] Multicasting




Can somebody explain me that if somebody wants to initiate a multicast
conference then where is he going to put the maddr parameter in request URI
or in Via header.

Second question is at what hop multicasting will take place i.e. at
outgoing proxy or at the recipient domain.

Please clarify with some example.

Thanks

--0__=SasRPtNnrkOYdD6D1fsgTp2JhfaU19DojlmFcY1wXYWUvxR6wBdT6REY
Content-type: text/html;
	name="att-1.htm"
Content-Disposition: attachment; filename="att-1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M
IDUuNTAuNDEzNC42MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+
DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkNh
biBzb21lYm9keSBleHBsYWluIG1lIHRoYXQgaWYgc29tZWJvZHkgd2FudHMgdG8gDQppbml0aWF0
ZSBhIG11bHRpY2FzdCBjb25mZXJlbmNlIHRoZW4gd2hlcmUgaXMgaGUgZ29pbmcgdG8gcHV0IHRo
ZSBtYWRkciANCnBhcmFtZXRlciBpbiByZXF1ZXN0IFVSSSBvciBpbiBWaWEgaGVhZGVyLjwvRk9O
VD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW
Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5TZWNvbmQgcXVlc3Rpb24gaXMgYXQgd2hh
dCBob3AgbXVsdGljYXN0aW5nIHdpbGwgDQp0YWtlIHBsYWNlIGkuZS4gYXQgb3V0Z29pbmcgcHJv
eHkgb3IgYXQgdGhlIHJlY2lwaWVudCBkb21haW4uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBm
YWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp
YWwgc2l6ZT0yPlBsZWFzZSBjbGFyaWZ5IHdpdGggc29tZSBleGFtcGxlLjwvRk9OVD48L0RJVj4N
CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48
Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5UaGFua3M8L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4N
Cg==

--0__=SasRPtNnrkOYdD6D1fsgTp2JhfaU19DojlmFcY1wXYWUvxR6wBdT6REY--


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


From sip-admin@lists.bell-labs.com  Wed Jun  6 09:17:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29659
	for ; Wed, 6 Jun 2001 09:17:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7F03F4439A; Wed,  6 Jun 2001 09:18:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by lists.bell-labs.com (Postfix) with ESMTP id EAE5D4433D
	for ; Wed,  6 Jun 2001 09:17:26 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id ACF839AF0144; Wed, 06 Jun 2001 09:15:36 -0400
Message-ID: <003401c0ee8b$27c59960$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: "Varadarajan Srinivasan" ,
        
References: <3B1EC619.70C0E955@wipro.com>
Subject: Re: [SIP] Proxy - A basic question
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 6 Jun 2001 09:18:19 -0400
Content-Transfer-Encoding: 7bit



----- Original Message -----
From: "Varadarajan Srinivasan" 
To: 
Sent: Wednesday, June 06, 2001 8:08 PM
Subject: [SIP] Proxy - A basic question


> Hi,
>
> >From RFC, We are asked to look upon proxy as DNS sort.
>
> Can I assume that UA "MUST"  be tagged to a proxy?

The SIP spec does not require that UA to use a proxy.

> That is all calls to UA outside its domain should come via proxy?

If a UAC knows or can determine the IP address of the UAS and the UAC and
UAS are in the same "realm" (i.e. NAT and firewall are not an issue), it
does not have to go thru a proxy.

The presence of proxies in the network relieve UAs from having to figure out
the IP Address of the other end by providing location services. It can also
enable lots of other services.

>
>
>
> Mr. Varadarajan Srinivasan,
> Senior Systems Engineer,
> Wipro Technologies.
>
>
>


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


From sip-admin@lists.bell-labs.com  Wed Jun  6 09:37:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00405
	for ; Wed, 6 Jun 2001 09:37:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E59AF4439A; Wed,  6 Jun 2001 09:38:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41])
	by lists.bell-labs.com (Postfix) with ESMTP id 4A0124437A
	for ; Wed,  6 Jun 2001 09:37:19 -0400 (EDT)
Received: from m2hub.mail.wipro.com (m2hub.wipro.com [164.164.27.50])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with ESMTP id f56JFsZ16872
	for ; Wed, 6 Jun 2001 19:15:54 GMT
Received: from m2vwall2.wipro.com ([164.164.27.52]) by
          m2hub.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP
          id GEIG9600.4AD for ; Wed, 6 Jun 2001
          19:01:54 +0530 
Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by
          kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GEI6Q900.NOS; Wed, 6 Jun 2001 15:36:09 +0530 
Received: from wipro.com (mmcsview.wipsys.soft.net [164.164.8.211]) by wslexch.wipsys.soft.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id LNNAPLSP; Wed, 6 Jun 2001 15:47:39 +0530
Message-ID: <3B1EAFEC.ED0E679D@wipro.com>
From: Varadarajan Srinivasan 
Organization: Wipro Technologies
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Ashwani Kumar Kesharwani 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] (no subject)
References: <002f01c0ee44$8d9c6e40$210d85a5@dti.daewoo.co.kr>
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 07 Jun 2001 04:05:22 +0531


--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
 boundary="------------AA61AA7155EB41F08231711E"

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

Hi,

Proxy consults Location Server( Database) and finds the proxy URI which
can handle this request (
need not be the proxy in which UAS in there).

On issuing Request, it will put the new Request_URI in request line of
the INVITE message and sends out.

Anyways, routing is done at third layer. It it just the URI we can
mention in SIP.

Cheers,
Varadarajan



URI)Ashwani Kumar Kesharwani wrote:

> Hi When a request goes through more than one proxy how does a proxy
> decides about the next proxy.  Thanks

Mr. Varadarajan Srinivasan,
Senior Systems Engineer,
Wipro Technologies.



--------------AA61AA7155EB41F08231711E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




Hi,

Proxy consults Location Server( Database) and finds the proxy URI
which can handle this request (

need not be the proxy in which UAS in there).

On issuing Request, it will put the new Request_URI in request line
of the INVITE message and sends out.

Anyways, routing is done at third layer. It it just the URI we can mention
in SIP.

Cheers,

Varadarajan

 

 

URI)Ashwani Kumar Kesharwani wrote:


Hi
When a request goes through more than
one proxy how does a proxy decides about the next proxy. 
Thanks



Mr. Varadarajan Srinivasan,
Senior Systems Engineer,
Wipro Technologies.

 



--------------AA61AA7155EB41F08231711E--


--------------InterScan_NT_MIME_Boundary--


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


From sip-admin@lists.bell-labs.com  Wed Jun  6 09:39:25 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00448
	for ; Wed, 6 Jun 2001 09:39:25 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 848C6443C1; Wed,  6 Jun 2001 09:39:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from edgeconnect.com (unknown [207.171.0.7])
	by lists.bell-labs.com (Postfix) with ESMTP id 03917443BF
	for ; Wed,  6 Jun 2001 09:38:13 -0400 (EDT)
Received: from DDCW6701 [216.119.231.55] by edgeconnect.com with ESMTP
  (SMTPD32-6.06) id A1E1AE930092; Wed, 06 Jun 2001 06:36:33 -0700
From: "Victor A Paulsamy" 
To: "Varadarajan Srinivasan" 
Cc: "SIP" ,
        "Victor A Paulsamy" 
Subject: RE: [SIP] Proxy - A basic question
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001A_01C0EE6C.E0E9EF00"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <3B1EC619.70C0E955@wipro.com>
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 6 Jun 2001 09:41:36 -0400

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01C0EE6C.E0E9EF00
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

  Hi Varadarajan,

  Even if an UA is calling another UA within the same domain, proxy receives
the call, looks up in the registration database, extracts Contact address
and forwards the call. To reach the callee directly, caller needs to know
the IP address and port of the callee, which is very unlikely in real life.

  Warm regards,

  --victor

   -----Original Message-----
  From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Varadarajan Srinivasan
  Sent: Wednesday, June 06, 2001 8:09 PM
  To: sip@lists.bell-labs.com
  Subject: [SIP] Proxy - A basic question


  Hi,
  From RFC, We are asked to look upon proxy as DNS sort.

  Can I assume that UA "MUST"  be tagged to a proxy?
  That is all calls to UA outside its domain should come via proxy?



Mr. Varadarajan Srinivasan,
Senior Systems Engineer,
Wipro Technologies.


------=_NextPart_000_001A_01C0EE6C.E0E9EF00
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable








  
Hi=20
  Varadarajan,

  
 

  
Even if=20
  an UA is calling another UA within the same =
domain, proxy receives=20
  the call, looks up in the registration database, extracts Contact =
address=20
  and forwards the call. To reach the callee directly, caller =
needs to=20
  know the IP address and port of the callee, which is very =
unlikely in=20
  real life.

  
 

  
Warm=20
  regards,

  
 

  
--victor

  
 

  
 -----Original=20
  Message-----
From: sip-admin@lists.bell-labs.com=20
  [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Varadarajan=20
  Srinivasan
Sent: Wednesday, June 06, 2001 8:09 =
PM
To:=20
  sip@lists.bell-labs.com
Subject: [SIP] Proxy - A basic=20
  question

Hi,=20
  
From RFC, We are asked to look upon proxy as DNS sort.=20
  
Can I assume that UA "MUST"  be tagged to a proxy? =

That is=20
  all calls to UA outside its domain should come via proxy? 
 =20
  
  
Mr. Varadarajan Srinivasan,
Senior Systems Engineer,
Wipro Technologies.
  


------=_NextPart_000_001A_01C0EE6C.E0E9EF00--


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


From sip-admin@lists.bell-labs.com  Wed Jun  6 10:59:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02593
	for ; Wed, 6 Jun 2001 10:59:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2CB9A4437A; Wed,  6 Jun 2001 11:00:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.inetmail.att.net (mailhost1.inetmail.att.net [204.127.132.33])
	by lists.bell-labs.com (Postfix) with ESMTP id A9DD34433D
	for ; Wed,  6 Jun 2001 10:59:54 -0400 (EDT)
Received: from ashok ([12.41.17.196])
          by mail.inetmail.att.net (mtiagic01) with SMTP
          id <20010606145954gi128280lne>; Wed, 6 Jun 2001 14:59:54 +0000
Message-ID: <003d01c0ee9a$894441a0$c411290c@masconit.com>
Reply-To: "Ranjit Avasarala" 
From: "Ranjit Avasarala" 
To: "Ashwani Kumar Kesharwani" ,
        
References: <002f01c0ee44$8d9c6e40$210d85a5@dti.daewoo.co.kr>
Subject: Re: [SIP] (no subject)
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0039_01C0EE70.A001E340"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 6 Jun 2001 10:08:25 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_0039_01C0EE70.A001E340
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

see my comments inline.....
Regards
Ranjit
Mascon Communication Technologies
http://www.masconit.com






  ----- Original Message -----
  From: Ashwani Kumar Kesharwani
  To: sip@lists.bell-labs.com
  Sent: Tuesday, June 05, 2001 11:52 PM
  Subject: [SIP] (no subject)


  Hi

  When a request goes through more than one proxy how does a proxy decides
about the next proxy.

   usually every LAN could have an inbound and outbound proxy. so when u
send ur request to a proxy, proxy will know if the destination UA
  is within its network or another network. then it will fwd the request to
another proxy.
  Thanks

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









see my comments =

inline.....


Regards
Ranjit
Mascon Communication Technologies
http://www.masconit.com


 


 


 


 


 


 


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

  From:=20
  Ashwani Kumar Kesharwani =

  
To: sip@lists.bell-labs.com 

  
Sent: Tuesday, June 05, 2001 =
11:52=20
  PM

  
Subject: [SIP] (no =
subject)

  


  
Hi

  
 

  
When a request goes through more than =
one proxy=20
  how does a proxy decides about the next proxy.

  
 

  
 usually every LAN could have an inbound =
and=20
  outbound proxy. so when u send ur request to a proxy, proxy will know =
if the=20
  destination UA

  
is within its =
network or=20
  another network. then it will fwd the request to another=20
  proxy.

  
Thanks


------=_NextPart_000_0039_01C0EE70.A001E340--


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


From sip-admin@lists.bell-labs.com  Wed Jun  6 11:01:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02650
	for ; Wed, 6 Jun 2001 11:01:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4F055443BF; Wed,  6 Jun 2001 11:02:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41])
	by lists.bell-labs.com (Postfix) with ESMTP id B48E0443B7
	for ; Wed,  6 Jun 2001 11:01:26 -0400 (EDT)
Received: from m2hub.mail.wipro.com (m2hub.wipro.com [164.164.27.50])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with ESMTP id f56Ke1Z07021
	for ; Wed, 6 Jun 2001 20:40:01 GMT
Received: from m2vwall2.wipro.com ([164.164.27.52]) by
          m2hub.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP
          id GEIK5100.JMN for ; Wed, 6 Jun 2001
          20:25:49 +0530 
Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by
          kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GEIKBD00.AU5 for ; Wed, 6 Jun
          2001 20:29:37 +0530 
Received: from wipro.com (mmcsview.wipsys.soft.net [164.164.8.211]) by wslexch.wipsys.soft.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id LNNAPRMD; Wed, 6 Jun 2001 20:41:08 +0530
Message-ID: <3B1EF4B6.56B6CBA7@wipro.com>
From: Varadarajan Srinivasan 
Organization: Wipro Technologies
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Proxy - A simple question
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 07 Jun 2001 08:58:50 +0531
Content-Transfer-Encoding: 7bit

Hi,

Basically, I am concern about the statement

"Typically, only the first request within a call traverses all proxies,
while subsequent requests are exchanged directly between user agents"

Section 1.3, last but one statement in RFC2543bis03.

Rajan








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


From sip-admin@lists.bell-labs.com  Wed Jun  6 12:11:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04265
	for ; Wed, 6 Jun 2001 12:11:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 06B09443B6; Wed,  6 Jun 2001 12:12:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 9BEE2443A9
	for ; Wed,  6 Jun 2001 12:11:29 -0400 (EDT)
Received: from plate (localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f56GAlt15585;
	Wed, 6 Jun 2001 11:10:47 -0500
Message-ID: <005301c0eea3$1eae6740$55fa403f@directlink.net>
From: "Dean Willis" 
To: "Varadarajan Srinivasan" ,
        
References: <3B1EC619.70C0E955@wipro.com>
Subject: Re: [SIP] Proxy - A basic question
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0050_01C0EE79.350753A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 6 Jun 2001 11:09:50 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_0050_01C0EE79.350753A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Not really. For example, one of the SIP phones around my house is =
directly listed in dns. Incoming calls to its DNS name do not go through =
my proxy.

--
Dean

----- Original Message -----=20
  From: Varadarajan Srinivasan=20
  To: sip@lists.bell-labs.com=20
  Sent: Wednesday, June 06, 2001 7:08 PM
  Subject: [SIP] Proxy - A basic question


  Hi,=20
  From RFC, We are asked to look upon proxy as DNS sort.=20

  Can I assume that UA "MUST"  be tagged to a proxy?=20
  That is all calls to UA outside its domain should come via proxy?=20
   =20
   =20

Mr. Varadarajan Srinivasan,
Senior Systems Engineer,
Wipro Technologies.
   =20

------=_NextPart_000_0050_01C0EE79.350753A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









 


Not really. For example, one of the SIP =
phones=20
around my house is directly listed in dns. Incoming calls to its DNS =
name do not=20
go through my proxy.


 


--


Dean


 


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


  From:=20
  Varadarajan Srinivasan =

  
  
Sent: Wednesday, June 06, 2001 =
7:08=20
  PM

  
Subject: [SIP] Proxy - A basic=20
  question

  

Hi,=20
  
From RFC, We are asked to look upon proxy as DNS sort.=20
  
Can I assume that UA "MUST"  be tagged to a proxy? =

That is=20
  all calls to UA outside its domain should come via proxy? 
 =20
  
  
Mr. Varadarajan Srinivasan,
Senior Systems Engineer,
Wipro Technologies.
  

------=_NextPart_000_0050_01C0EE79.350753A0--


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


From sip-admin@lists.bell-labs.com  Wed Jun  6 14:00:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07054
	for ; Wed, 6 Jun 2001 14:00:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7324744341; Wed,  6 Jun 2001 14:01:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from web4805.mail.yahoo.com (web4805.mail.yahoo.com [216.115.105.247])
	by lists.bell-labs.com (Postfix) with SMTP id 840544433D
	for ; Wed,  6 Jun 2001 14:00:11 -0400 (EDT)
Message-ID: <20010606180009.26412.qmail@web4805.mail.yahoo.com>
Received: from [65.15.28.6] by web4805.mail.yahoo.com; Wed, 06 Jun 2001 11:00:09 PDT
From: Jose Martinez 
Subject: Re: [SIP] Proxy - A basic question
To: Bob Penfield ,
        Varadarajan Srinivasan ,
        sip@lists.bell-labs.com
In-Reply-To: <003401c0ee8b$27c59960$2300000a@acmepacket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 6 Jun 2001 11:00:09 -0700 (PDT)

Why do they have to be in the same realm?

--- Bob Penfield  wrote:
> 
> 
> ----- Original Message -----
> From: "Varadarajan Srinivasan"
> 
> To: 
> Sent: Wednesday, June 06, 2001 8:08 PM
> Subject: [SIP] Proxy - A basic question
> 
> 
> > Hi,
> >
> > >From RFC, We are asked to look upon proxy as DNS
> sort.
> >
> > Can I assume that UA "MUST"  be tagged to a proxy?
> 
> The SIP spec does not require that UA to use a
> proxy.
> 
> > That is all calls to UA outside its domain should
> come via proxy?
> 
> If a UAC knows or can determine the IP address of
> the UAS and the UAC and
> UAS are in the same "realm" (i.e. NAT and firewall
> are not an issue), it
> does not have to go thru a proxy.
> 
> The presence of proxies in the network relieve UAs
> from having to figure out
> the IP Address of the other end by providing
> location services. It can also
> enable lots of other services.
> 
> >
> >
> >
> > Mr. Varadarajan Srinivasan,
> > Senior Systems Engineer,
> > Wipro Technologies.
> >
> >
> >
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP
> protocol.
> The sip-implementor's list is the place to discuss
> implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> sip-implementors-request@cs.columbia.edu with
> "subscribe" in the body.


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

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


From sip-admin@lists.bell-labs.com  Wed Jun  6 14:13:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07317
	for ; Wed, 6 Jun 2001 14:13:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 10BD64435C; Wed,  6 Jun 2001 14:14:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from web4803.mail.yahoo.com (web4803.mail.yahoo.com [216.115.105.245])
	by lists.bell-labs.com (Postfix) with SMTP id 0FC134433D
	for ; Wed,  6 Jun 2001 14:13:40 -0400 (EDT)
Message-ID: <20010606181340.7511.qmail@web4803.mail.yahoo.com>
Received: from [65.15.28.6] by web4803.mail.yahoo.com; Wed, 06 Jun 2001 11:13:40 PDT
From: Jose Martinez 
Subject: Re: [SIP] (no subject)
To: Ashwani Kumar Kesharwani ,
        sip@lists.bell-labs.com
In-Reply-To: <002f01c0ee44$8d9c6e40$210d85a5@dti.daewoo.co.kr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 6 Jun 2001 11:13:40 -0700 (PDT)

To answer the your question 'HOW it dedides' that
depends on the proxy server.  There are different
conditions in which a proxy will contact a another
proxy.  It might not even know that it is contacting
another proxy.  You can put a perminent register, a
register that does not timeout, on a proxy for a
specific number.  Everytime that number is rung up the
proxy will forward the request to whoever is
registered.  Another way is to use some sort of phone
route that forwards the request to a specified IP
address.  You can also setup the proxyZ to redirect to
another proxyX, in this case the proxyZ does not
forward but instead tells the source of the request to
try proxyX.  Hope that helped somewhat.  
--- Ashwani Kumar Kesharwani
 wrote:
> Hi
> 
> When a request goes through more than one proxy how
> does a proxy decides about the next proxy.
> 
> 
> Thanks
> 


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

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


From sip-admin@lists.bell-labs.com  Thu Jun  7 01:02:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15648
	for ; Thu, 7 Jun 2001 01:02:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 416B044341; Thu,  7 Jun 2001 01:03:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id AD9FF4433D
	for ; Thu,  7 Jun 2001 01:02:22 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5752LN14380;
	Thu, 7 Jun 2001 07:02:21 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.51])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5752L521822;
	Thu, 7 Jun 2001 08:02:21 +0300 (EET DST)
Message-ID: <3B1F0ACB.1B950A40@lmf.ericsson.se>
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Varadarajan Srinivasan 
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Proxy - A simple question
References: <3B1EF4B6.56B6CBA7@wipro.com>
Content-Type: multipart/mixed;
 boundary="------------2DFF8FDB3B2059BEB497F901"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 07 Jun 2001 08:02:03 +0300

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


Hi,

The reason for this is that since the remote UA MUST insert a Contact
header in the 200 final response, subsequent requests are then sent
there. However, if a proxy does want to be in the path also for the
subsequent requests, it is possible by using the record route.

Regards,

Christer Holmberg
Ericsson Finland


Varadarajan Srinivasan wrote:
> 
> Hi,
> 
> Basically, I am concern about the statement
> 
> "Typically, only the first request within a call traverses all proxies,
> while subsequent requests are exchanged directly between user agents"
> 
> Section 1.3, last but one statement in RFC2543bis03.
> 
> Rajan
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
--------------2DFF8FDB3B2059BEB497F901
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------2DFF8FDB3B2059BEB497F901--


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


From sip-admin@lists.bell-labs.com  Thu Jun  7 01:30:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17197
	for ; Thu, 7 Jun 2001 01:30:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9D960443A8; Thu,  7 Jun 2001 01:31:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from india.mercurykr.com (unknown [165.133.13.60])
	by lists.bell-labs.com (Postfix) with ESMTP id 7CA7C4433D
	for ; Thu,  7 Jun 2001 01:30:07 -0400 (EDT)
Received: from ashwani (Param [165.133.13.33])
	by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id KAA01437;
	Thu, 7 Jun 2001 10:52:38 -0600 (GMT)
Message-ID: <003a01c0ef13$1ec94d60$210d85a5@dti.daewoo.co.kr>
From: "Ashwani Kumar Kesharwani" 
To: "Varadarajan Srinivasan" ,
        
References: <3B1EF4B6.56B6CBA7@wipro.com>
Subject: Re: [SIP] Proxy - A simple question
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 7 Jun 2001 11:01:29 +0530
Content-Transfer-Encoding: 7bit

Hi It is actually like this.
With in first request UAC provides its contact address so that UAS sends a
final response at the contact address mentioned rather than sending it
through all the proxies.
And with this final response it is a must for the UAS that it sends its own
contact address too. So that next time UAC will contact UAS without going
through proxies.

So after first request-response UAC and UAS could communicate without going
through proxies.
But if a proxy wants yo be in the path it adds a record route header while
first request is going through it.


>
> Basically, I am concern about the statement
>
> "Typically, only the first request within a call traverses all proxies,
> while subsequent requests are exchanged directly between user agents"
>
> Section 1.3, last but one statement in RFC2543bis03.
>
> Rajan
>
>
>
>
>
>
>
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
>


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


From sip-admin@lists.bell-labs.com  Thu Jun  7 01:50:41 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17917
	for ; Thu, 7 Jun 2001 01:50:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C262144341; Thu,  7 Jun 2001 01:51:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 9309C4433D
	for ; Thu,  7 Jun 2001 01:50:36 -0400 (EDT)
Received: from flash-18 (flash-18 [192.4.18.17])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f575m8u09944;
	Thu, 7 Jun 2001 01:48:08 -0400 (EDT)
From: Provin Gurung 
To: Ashwani Kumar Kesharwani 
Cc: Varadarajan Srinivasan ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Proxy - A simple question
In-Reply-To: <003a01c0ef13$1ec94d60$210d85a5@dti.daewoo.co.kr>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 7 Jun 2001 01:48:08 -0400 (EDT)

On Thu, 7 Jun 2001, Ashwani Kumar Kesharwani wrote:

> Hi It is actually like this.
> With in first request UAC provides its contact address so that UAS sends a
> final response at the contact address mentioned rather than sending it
> through all the proxies.

I think there is a slight misunderstanding here,
The contact is there so that future requests from the called
UA can be sent directly to the calling UA. All the responses *must*
traverse back the same path that the request followed, i.e responses are
forwarded to the top via field of the SIP message. The responses cannot
bypass the proxies. 

Proveen Gurung

Telcordia Technologies,
MCC-1H-209R,
445,South Street,
Morristown,NJ,USA-07960-6438
Tel (973)829-2323


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


From sip-admin@lists.bell-labs.com  Thu Jun  7 02:05:38 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25856
	for ; Thu, 7 Jun 2001 02:05:38 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6E3BB443B9; Thu,  7 Jun 2001 02:06:02 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from gateway.orientzone.com (unknown [202.54.109.83])
	by lists.bell-labs.com (Postfix) with ESMTP id 2FF0544341
	for ; Thu,  7 Jun 2001 02:05:12 -0400 (EDT)
Received: from coder24 (coder24.orientzone.com [192.168.1.59])
	by gateway.orientzone.com (8.9.3/8.9.3) with SMTP id LAA14334
	for ; Thu, 7 Jun 2001 11:29:42 +0530
Message-ID: <00ac01bea4e2$7e23eb80$3b01a8c0@orientzone.com>
From: "Ashutosh" 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00A9_01BEA510.97D48660"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: [SIP] sip application
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 23 May 1999 11:37:09 +0530

This is a multi-part message in MIME format.

------=_NextPart_000_00A9_01BEA510.97D48660
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I want to know for developing applications that support SIP what type of
knowlegde is required,If I am using SIP server,client and SDK from 3rd
party?Is it applecation dev like java,C++ or very hardcore experience in
protocol stacks, telecom and IP programming.. is required.
Regards
Ashutosh


------=_NextPart_000_00A9_01BEA510.97D48660
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









I want to know for developing =
applications that=20
support SIP what type of
knowlegde is required,If I am using SIP=20
server,client and SDK from 3rd
party?Is it applecation dev like =
java,C++ or=20
very hardcore experience in
protocol stacks, telecom and IP =
programming.. is=20
required.
Regards
Ashutosh


------=_NextPart_000_00A9_01BEA510.97D48660--


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


From sip-admin@lists.bell-labs.com  Thu Jun  7 02:19:41 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26870
	for ; Thu, 7 Jun 2001 02:19:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B6D1C443D6; Thu,  7 Jun 2001 02:20:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from india.mercurykr.com (unknown [165.133.13.60])
	by lists.bell-labs.com (Postfix) with ESMTP id E0A7F443B9
	for ; Thu,  7 Jun 2001 02:19:44 -0400 (EDT)
Received: from ashwani (Param [165.133.13.33])
	by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id LAA02269;
	Thu, 7 Jun 2001 11:39:59 -0600 (GMT)
Message-ID: <001a01c0ef19$bf5f7960$210d85a5@dti.daewoo.co.kr>
From: "Ashwani Kumar Kesharwani" 
To: "Provin Gurung" 
Cc: "Varadarajan Srinivasan" ,
        
References: 
Subject: Re: [SIP] Proxy - A simple question
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 7 Jun 2001 11:48:50 +0530
Content-Transfer-Encoding: 7bit

Yes Provin You are right.

A request and a final  response forms a transaction.
And both follow same set of proxies.

Contact address are used for further requests.


----- Original Message -----
From: "Provin Gurung" 
To: "Ashwani Kumar Kesharwani" 
Cc: "Varadarajan Srinivasan" ;

Sent: Thursday, June 07, 2001 11:18 AM
Subject: Re: [SIP] Proxy - A simple question


> On Thu, 7 Jun 2001, Ashwani Kumar Kesharwani wrote:
>
> > Hi It is actually like this.
> > With in first request UAC provides its contact address so that UAS sends
a
> > final response at the contact address mentioned rather than sending it
> > through all the proxies.
>
> I think there is a slight misunderstanding here,
> The contact is there so that future requests from the called
> UA can be sent directly to the calling UA. All the responses *must*
> traverse back the same path that the request followed, i.e responses are
> forwarded to the top via field of the SIP message. The responses cannot
> bypass the proxies.
>
> Proveen Gurung
>
> Telcordia Technologies,
> MCC-1H-209R,
> 445,South Street,
> Morristown,NJ,USA-07960-6438
> Tel (973)829-2323
>
>


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


From sip-admin@lists.bell-labs.com  Thu Jun  7 02:54:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28902
	for ; Thu, 7 Jun 2001 02:54:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B0B3C443A8; Thu,  7 Jun 2001 02:55:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41])
	by lists.bell-labs.com (Postfix) with ESMTP id 4345C4433D
	for ; Thu,  7 Jun 2001 02:54:48 -0400 (EDT)
Received: from m2hub.mail.wipro.com (m2hub.wipro.com [164.164.27.50])
	by wiprom2mx1.wipro.com (8.11.3/8.11.3) with ESMTP id f57CXKZ23662
	for ; Thu, 7 Jun 2001 12:33:20 GMT
Received: from m2vwall2.wipro.com ([164.164.27.52]) by
          m2hub.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP
          id GEJS9800.V65 for ; Thu, 7 Jun 2001
          12:18:44 +0530 
Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by
          kmglmail.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GEJS5K00.S28 for ; Thu, 7 Jun
          2001 12:16:32 +0530 
Received: from wipro.com (ntultra2.wipsys.soft.net [164.164.8.177]) by wslexch.wipsys.soft.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id LNNAP6L5; Thu, 7 Jun 2001 12:28:03 +0530
Message-ID: <3B1F236D.D59EFEA2@wipro.com>
From: Varadarajan Srinivasan 
Organization: Wipro Technologies
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] SIP Mailing lists
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 07 Jun 2001 12:18:09 +0531
Content-Transfer-Encoding: 7bit

Hi,

Sorry to dump mails.

I have been told by the mailing list maintenance that questions about
RFC, Implementations and basics should
be posted to SIP-Implementors list and not in this list.

Please refrain to mail here regarding the same.

Thanks,
Varadarajan






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


From sip-admin@lists.bell-labs.com  Thu Jun  7 03:14:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00131
	for ; Thu, 7 Jun 2001 03:14:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6FE0B443A8; Thu,  7 Jun 2001 03:15:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dcn.ssu.ac.kr (dcn.ssu.ac.kr [203.253.2.104])
	by lists.bell-labs.com (Postfix) with ESMTP id A940A4433D
	for ; Thu,  7 Jun 2001 03:14:28 -0400 (EDT)
Received: from softgear ([203.253.3.209])
	by dcn.ssu.ac.kr (8.10.1/8.10.1) with SMTP id f5775SR13481
	for ; Thu, 7 Jun 2001 16:05:28 +0900 (KST)
From: =?ks_c_5601-1987?B?sO28rrCp?= 
To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [SIP] callerprefs-03.txt  mistype
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 7 Jun 2001 16:17:15 +0900
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id DAA00131

Hello.
I found a misprint in 'draft-ietf-sip-callerprefs-03.txt' but it is minor.

At Page 5. Section 5. Table 5 specifies an extension of Table 5 in RFC 2543....
First 'Table 5' is a misprint, I think.

........softgearÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÓ†+%ŠËb±ú+r‰íŠ{¢ž^½éh¦g§¶‡í…äˆ>šè¶‡(—ôázÈ©þ)©•éžžÚ+þÉb²Ø¬¶©•§¶‡b±Ë¬²)©•éžžÖ­Š‰ÿjwm¢·œz+ÞiÛâqê'ºw^®ËZاìb²Ø§‚È©ý:,¹»®&Þ¶ˆ­þǧvf¢–Ú,ŠŸâš™^™éí¢»ÿ­ê®zËÿrÏÜ¢[¦n&ÿyÛ°ŠØÿ²æìr¸›{ø§¶›¡Üÿ


From sip-admin@lists.bell-labs.com  Thu Jun  7 04:00:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01572
	for ; Thu, 7 Jun 2001 04:00:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 15F57443A8; Thu,  7 Jun 2001 04:01:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb16.rediffmail.com (unknown [203.199.83.28])
	by lists.bell-labs.com (Postfix) with SMTP id 638754433D
	for ; Thu,  7 Jun 2001 04:00:54 -0400 (EDT)
Received: (qmail 16856 invoked by uid 510); 7 Jun 2001 08:03:18 -0000
Message-ID: <20010607080318.16855.qmail@mailweb16.rediffmail.com>
Received: from unknown (203.195.146.43) by rediffmail.com via HTTP; 07 Jun 2001 08:03:18 -0000
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" 
From: "Deepak  Mohan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [SIP] SIP URLs in Contact
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 7 Jun 2001 08:03:18 -0000
Content-Transfer-Encoding: 7bit

Hi,
2.2 of bis-03 says that Contact in OPTIONS should have only SIP URLs, but 10.14 says that "For OPTIONS, Contact provides a hint where future SIP requests can be sent or the user can be contacted via non-SIP means.

Clarifications?

Regards,
Deepak



_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





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


From sip-admin@lists.bell-labs.com  Thu Jun  7 09:43:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07117
	for ; Thu, 7 Jun 2001 09:43:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 632184433D; Thu,  7 Jun 2001 09:44:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 865244433B
	for ; Thu,  7 Jun 2001 09:43:11 -0400 (EDT)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0GEK00BE4BD3WS@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu,  7 Jun 2001 13:41:27 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0GEK00A01BCDJ0@dgismtp02.wcomnet.com>;
 Thu, 07 Jun 2001 13:41:26 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0GEK006PMBCAMO@dgismtp02.wcomnet.com>; Thu,
 07 Jun 2001 13:40:59 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 07 Jun 2001 13:40:58 +0000
Content-return: allowed
From: "Iliff, Tina" 
Subject: RE: [SIP] Proxy - A simple question
To: "'Provin Gurung'" ,
        Ashwani Kumar Kesharwani 
Cc: Varadarajan Srinivasan ,
        sip@lists.bell-labs.com
Message-id: <492EB4A3F68CD411ABE800508B69362E3F5932@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=iso-8859-1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 07 Jun 2001 13:40:57 +0000

What about the case of a Stateless proxy?
A stateful proxy would insert a Record-Route and this would cause the
responses to traverse via the proxy.  However, with a stateless proxy the
responses can go directly to the originating UAC.
Tina Iliff


 -----Original Message-----
From: 	Provin Gurung [mailto:pgurung@research.telcordia.com] 
Sent:	Thursday, June 07, 2001 12:48 AM
To:	Ashwani Kumar Kesharwani
Cc:	Varadarajan Srinivasan; sip@lists.bell-labs.com
Subject:	Re: [SIP] Proxy - A simple question

On Thu, 7 Jun 2001, Ashwani Kumar Kesharwani wrote:

> Hi It is actually like this.
> With in first request UAC provides its contact address so that UAS sends a
> final response at the contact address mentioned rather than sending it
> through all the proxies.

I think there is a slight misunderstanding here,
The contact is there so that future requests from the called
UA can be sent directly to the calling UA. All the responses *must*
traverse back the same path that the request followed, i.e responses are
forwarded to the top via field of the SIP message. The responses cannot
bypass the proxies. 

Proveen Gurung

Telcordia Technologies,
MCC-1H-209R,
445,South Street,
Morristown,NJ,USA-07960-6438
Tel (973)829-2323


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

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


From sip-admin@lists.bell-labs.com  Thu Jun  7 09:46:41 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07168
	for ; Thu, 7 Jun 2001 09:46:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0035B443DF; Thu,  7 Jun 2001 09:47:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by lists.bell-labs.com (Postfix) with ESMTP id ACAAF4433B
	for ; Thu,  7 Jun 2001 09:46:15 -0400 (EDT)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GEK005C0BKUTN@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu,  7 Jun 2001 13:46:06 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0GEK00D01BKKJ0@dgismtp02.wcomnet.com>;
 Thu, 07 Jun 2001 13:46:06 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0GEK00ABZBKIJO@dgismtp02.wcomnet.com>; Thu,
 07 Jun 2001 13:45:54 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 07 Jun 2001 13:45:54 +0000
Content-return: allowed
From: "Iliff, Tina" 
Subject: RE: [SIP] Proxy - A simple question
To: "'Provin Gurung'" ,
        "'Ashwani Kumar Kesharwani'" 
Cc: "'Varadarajan Srinivasan'" ,
        "'sip@lists.bell-labs.com'" 
Message-id: <492EB4A3F68CD411ABE800508B69362E3F5934@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=iso-8859-1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 07 Jun 2001 13:45:52 +0000

If a UAC knows the IP address of the UAS with which it wishes to
communicate, then the transaction can happen directly without the Request
going through a proxy.

Tina Iliff


 -----Original Message-----
From: 	Iliff, Tina  
Sent:	Thursday, June 07, 2001 8:41 AM
To:	'Provin Gurung'; Ashwani Kumar Kesharwani
Cc:	Varadarajan Srinivasan; sip@lists.bell-labs.com
Subject:	RE: [SIP] Proxy - A simple question

What about the case of a Stateless proxy?
A stateful proxy would insert a Record-Route and this would cause the
responses to traverse via the proxy.  However, with a stateless proxy the
responses can go directly to the originating UAC.
Tina Iliff


 -----Original Message-----
From: 	Provin Gurung [mailto:pgurung@research.telcordia.com] 
Sent:	Thursday, June 07, 2001 12:48 AM
To:	Ashwani Kumar Kesharwani
Cc:	Varadarajan Srinivasan; sip@lists.bell-labs.com
Subject:	Re: [SIP] Proxy - A simple question

On Thu, 7 Jun 2001, Ashwani Kumar Kesharwani wrote:

> Hi It is actually like this.
> With in first request UAC provides its contact address so that UAS sends a
> final response at the contact address mentioned rather than sending it
> through all the proxies.

I think there is a slight misunderstanding here,
The contact is there so that future requests from the called
UA can be sent directly to the calling UA. All the responses *must*
traverse back the same path that the request followed, i.e responses are
forwarded to the top via field of the SIP message. The responses cannot
bypass the proxies. 

Proveen Gurung

Telcordia Technologies,
MCC-1H-209R,
445,South Street,
Morristown,NJ,USA-07960-6438
Tel (973)829-2323


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

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


From sip-admin@lists.bell-labs.com  Thu Jun  7 09:51:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07312
	for ; Thu, 7 Jun 2001 09:51:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 14813443EF; Thu,  7 Jun 2001 09:52:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id D37F4443DF
	for ; Thu,  7 Jun 2001 09:51:03 -0400 (EDT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0GEK00GGVBSGPQ@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu,  7 Jun 2001 13:50:41 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GEK00I01BS4KP@pmismtp01.wcomnet.com>;
 Thu, 07 Jun 2001 13:50:40 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GEK00F8RBR6UI@pmismtp01.wcomnet.com>; Thu,
 07 Jun 2001 13:49:54 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 07 Jun 2001 13:49:54 +0000
Content-return: allowed
From: "Iliff, Tina" 
Subject: RE: [SIP] Proxy - A simple question
To: "'Provin Gurung'" ,
        Ashwani Kumar Kesharwani 
Cc: Varadarajan Srinivasan ,
        sip@lists.bell-labs.com
Message-id: <492EB4A3F68CD411ABE800508B69362E3F5935@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=ISO-8859-1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 07 Jun 2001 13:49:50 +0000

Let me get back on track with the original question:  Typically, subsequent
requests involve changes in SDP content.  Transaction Stateful proxies do
not need to be involved in these sorts of transactions.

Tina Iliff


 -----Original Message-----
From: 	Provin Gurung [mailto:pgurung@research.telcordia.com] 
Sent:	Thursday, June 07, 2001 12:48 AM
To:	Ashwani Kumar Kesharwani
Cc:	Varadarajan Srinivasan; sip@lists.bell-labs.com
Subject:	Re: [SIP] Proxy - A simple question

On Thu, 7 Jun 2001, Ashwani Kumar Kesharwani wrote:

> Hi It is actually like this.
> With in first request UAC provides its contact address so that UAS sends a
> final response at the contact address mentioned rather than sending it
> through all the proxies.

I think there is a slight misunderstanding here,
The contact is there so that future requests from the called
UA can be sent directly to the calling UA. All the responses *must*
traverse back the same path that the request followed, i.e responses are
forwarded to the top via field of the SIP message. The responses cannot
bypass the proxies. 

Proveen Gurung

Telcordia Technologies,
MCC-1H-209R,
445,South Street,
Morristown,NJ,USA-07960-6438
Tel (973)829-2323


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

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


From sip-admin@lists.bell-labs.com  Thu Jun  7 09:59:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07507
	for ; Thu, 7 Jun 2001 09:59:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 42DFF443F8; Thu,  7 Jun 2001 10:00:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from domino2.nc.tekelec.com (domino2.nc.tekelec.com [198.89.40.41])
	by lists.bell-labs.com (Postfix) with SMTP id 7DD04443D3
	for ; Thu,  7 Jun 2001 09:59:03 -0400 (EDT)
Received: by domino2.nc.tekelec.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 85256A64.004CA38F ; Thu, 7 Jun 2001 09:57:06 -0400
X-Lotus-FromDomain: TEKELEC
From: "MPJ Krishna" 
To: "Iliff, Tina" 
Cc: "'Provin Gurung'" ,
        Ashwani Kumar Kesharwani ,
        Varadarajan Srinivasan ,
        sip@lists.bell-labs.com
Message-ID: <85256A64.004CA1EE.00@domino2.nc.tekelec.com>
Subject: RE: [SIP] Proxy - A simple question
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 7 Jun 2001 09:53:23 -0400

Responses are routed using the Via header field not the Record-Route.

Krishna




"Iliff, Tina"  on 06/07/2001 09:40:57 AM

To:   "'Provin Gurung'" , Ashwani Kumar
      Kesharwani 
cc:   Varadarajan Srinivasan ,
      sip@lists.bell-labs.com (bcc: MPJ Krishna/Raleigh/TEKELEC)
Subject:  RE: [SIP] Proxy - A simple question




What about the case of a Stateless proxy?
A stateful proxy would insert a Record-Route and this would cause the
responses to traverse via the proxy.  However, with a stateless proxy the
responses can go directly to the originating UAC.
Tina Iliff


 -----Original Message-----
From:     Provin Gurung [mailto:pgurung@research.telcordia.com]
Sent:     Thursday, June 07, 2001 12:48 AM
To:  Ashwani Kumar Kesharwani
Cc:  Varadarajan Srinivasan; sip@lists.bell-labs.com
Subject:  Re: [SIP] Proxy - A simple question

On Thu, 7 Jun 2001, Ashwani Kumar Kesharwani wrote:

> Hi It is actually like this.
> With in first request UAC provides its contact address so that UAS sends a
> final response at the contact address mentioned rather than sending it
> through all the proxies.

I think there is a slight misunderstanding here,
The contact is there so that future requests from the called
UA can be sent directly to the calling UA. All the responses *must*
traverse back the same path that the request followed, i.e responses are
forwarded to the top via field of the SIP message. The responses cannot
bypass the proxies.

Proveen Gurung

Telcordia Technologies,
MCC-1H-209R,
445,South Street,
Morristown,NJ,USA-07960-6438
Tel (973)829-2323


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

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






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


From sip-admin@lists.bell-labs.com  Thu Jun  7 10:05:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07629
	for ; Thu, 7 Jun 2001 10:05:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8C50D44406; Thu,  7 Jun 2001 10:06:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 83F0A44404
	for ; Thu,  7 Jun 2001 10:05:35 -0400 (EDT)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-33 #47837)
 with ESMTP id <0GEK00ADCCFMU9@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu,  7 Jun 2001 14:04:34 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0GEK00201CF8Z2@dgismtp02.wcomnet.com>;
 Thu, 07 Jun 2001 14:04:33 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0GEK00INDCF79O@dgismtp02.wcomnet.com>; Thu,
 07 Jun 2001 14:04:19 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 07 Jun 2001 14:04:19 +0000
Content-return: allowed
From: "Iliff, Tina" 
Subject: RE: [SIP] Proxy - A simple question
To: "'MPJ Krishna'" 
Cc: "'Provin Gurung'" ,
        Ashwani Kumar Kesharwani ,
        Varadarajan Srinivasan ,
        sip@lists.bell-labs.com
Message-id: <492EB4A3F68CD411ABE800508B69362E3F5936@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=iso-8859-1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 07 Jun 2001 14:04:18 +0000

Thank you.  I just about to post another e-mail and apologize for my
incorrect statement.

Tina Iliff


 -----Original Message-----
From: 	MPJ Krishna [mailto:mpj.krishna@tekelec.com] 
Sent:	Thursday, June 07, 2001 8:53 AM
To:	Iliff, Tina
Cc:	'Provin Gurung'; Ashwani Kumar Kesharwani; Varadarajan Srinivasan;
sip@lists.bell-labs.com
Subject:	RE: [SIP] Proxy - A simple question

Responses are routed using the Via header field not the Record-Route.

Krishna




"Iliff, Tina"  on 06/07/2001 09:40:57 AM

To:   "'Provin Gurung'" , Ashwani Kumar
      Kesharwani 
cc:   Varadarajan Srinivasan ,
      sip@lists.bell-labs.com (bcc: MPJ Krishna/Raleigh/TEKELEC)
Subject:  RE: [SIP] Proxy - A simple question




What about the case of a Stateless proxy?
A stateful proxy would insert a Record-Route and this would cause the
responses to traverse via the proxy.  However, with a stateless proxy the
responses can go directly to the originating UAC.
Tina Iliff


 -----Original Message-----
From:     Provin Gurung [mailto:pgurung@research.telcordia.com]
Sent:     Thursday, June 07, 2001 12:48 AM
To:  Ashwani Kumar Kesharwani
Cc:  Varadarajan Srinivasan; sip@lists.bell-labs.com
Subject:  Re: [SIP] Proxy - A simple question

On Thu, 7 Jun 2001, Ashwani Kumar Kesharwani wrote:

> Hi It is actually like this.
> With in first request UAC provides its contact address so that UAS sends a
> final response at the contact address mentioned rather than sending it
> through all the proxies.

I think there is a slight misunderstanding here,
The contact is there so that future requests from the called
UA can be sent directly to the calling UA. All the responses *must*
traverse back the same path that the request followed, i.e responses are
forwarded to the top via field of the SIP message. The responses cannot
bypass the proxies.

Proveen Gurung

Telcordia Technologies,
MCC-1H-209R,
445,South Street,
Morristown,NJ,USA-07960-6438
Tel (973)829-2323


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

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





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


From sip-admin@lists.bell-labs.com  Thu Jun  7 10:17:40 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07836
	for ; Thu, 7 Jun 2001 10:17:40 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5E118443D0; Thu,  7 Jun 2001 10:18:05 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 56B0E443A9
	for ; Thu,  7 Jun 2001 10:17:27 -0400 (EDT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0GEK0071GD0VEA@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu,  7 Jun 2001 14:17:19 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GEK00C01D0MQC@pmismtp01.wcomnet.com>;
 Thu, 07 Jun 2001 14:17:18 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GEK009OND0HKS@pmismtp01.wcomnet.com>; Thu,
 07 Jun 2001 14:17:05 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 07 Jun 2001 14:17:04 +0000
Content-return: allowed
From: "Iliff, Tina" 
Subject: RE: [SIP] Proxy - A simple question
To: "'Provin Gurung'" ,
        Ashwani Kumar Kesharwani 
Cc: Varadarajan Srinivasan ,
        sip@lists.bell-labs.com
Message-id: <492EB4A3F68CD411ABE800508B69362E3F5937@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=ISO-8859-1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 07 Jun 2001 14:17:01 +0000

Let me correct myself here as well..I was only referring to INVITE Requests.
However, if a proxy has inserted a Record-Route Header in any initial
transaction responses from the UAS, then subsequent BYE, OPTIONS, etc
Requests must pass through the proxy.
Correct?

Tina Iliff


 -----Original Message-----
From: 	Iliff, Tina  
Sent:	Thursday, June 07, 2001 8:50 AM
To:	'Provin Gurung'; Ashwani Kumar Kesharwani
Cc:	Varadarajan Srinivasan; sip@lists.bell-labs.com
Subject:	RE: [SIP] Proxy - A simple question

Let me get back on track with the original question:  Typically, subsequent
requests involve changes in SDP content.  Transaction Stateful proxies do
not need to be involved in these sorts of transactions.

Tina Iliff


 -----Original Message-----
From: 	Provin Gurung [mailto:pgurung@research.telcordia.com] 
Sent:	Thursday, June 07, 2001 12:48 AM
To:	Ashwani Kumar Kesharwani
Cc:	Varadarajan Srinivasan; sip@lists.bell-labs.com
Subject:	Re: [SIP] Proxy - A simple question

On Thu, 7 Jun 2001, Ashwani Kumar Kesharwani wrote:

> Hi It is actually like this.
> With in first request UAC provides its contact address so that UAS sends a
> final response at the contact address mentioned rather than sending it
> through all the proxies.

I think there is a slight misunderstanding here,
The contact is there so that future requests from the called
UA can be sent directly to the calling UA. All the responses *must*
traverse back the same path that the request followed, i.e responses are
forwarded to the top via field of the SIP message. The responses cannot
bypass the proxies. 

Proveen Gurung

Telcordia Technologies,
MCC-1H-209R,
445,South Street,
Morristown,NJ,USA-07960-6438
Tel (973)829-2323


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

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

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


From sip-admin@lists.bell-labs.com  Thu Jun  7 13:06:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10716
	for ; Thu, 7 Jun 2001 13:06:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 954154433D; Thu,  7 Jun 2001 13:07:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 96E5F4433B
	for ; Thu,  7 Jun 2001 13:06:47 -0400 (EDT)
Received: from flash-18 (flash-18 [192.4.18.17])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f57H60u29058;
	Thu, 7 Jun 2001 13:06:01 -0400 (EDT)
From: Provin Gurung 
To: "Iliff, Tina" 
Cc: Ashwani Kumar Kesharwani ,
        Varadarajan Srinivasan ,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Proxy - A simple question
In-Reply-To: <492EB4A3F68CD411ABE800508B69362E3F5937@RIPEXCH002.wcomnet.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 7 Jun 2001 13:06:00 -0400 (EDT)


You are correct, if a Record Route header is present, all future
requests/responses travel through the proxies that inserted the
Record-Route header, irrespective of the
direction the request/response is travelling (from calling to called or
vice versa)
Also irrespective of the proxy being stateful or stateless, the responses
always travel the same path back. Btw there is no way for an UAS
downstream to determine if the proxy that forwarded the request is a
stateful or stateless. So without making any assumption the rule is to use
the via field to forward the message upstream. Also when a stateless
proxy receives a response it removes its Via field and forwards the
response upstream using the next via field.

-Provin.

 On Thu, 7 Jun 2001, Iliff, Tina wrote:

> Let me correct myself here as well..I was only referring to INVITE Requests.
> However, if a proxy has inserted a Record-Route Header in any initial
> transaction responses from the UAS, then subsequent BYE, OPTIONS, etc
> Requests must pass through the proxy.
> Correct?
> 
> Tina Iliff
> 
> 
>  -----Original Message-----
> From: 	Iliff, Tina  
> Sent:	Thursday, June 07, 2001 8:50 AM
> To:	'Provin Gurung'; Ashwani Kumar Kesharwani
> Cc:	Varadarajan Srinivasan; sip@lists.bell-labs.com
> Subject:	RE: [SIP] Proxy - A simple question
> 
> Let me get back on track with the original question:  Typically, subsequent
> requests involve changes in SDP content.  Transaction Stateful proxies do
> not need to be involved in these sorts of transactions.
> 
> Tina Iliff
> 
> 
>  -----Original Message-----
> From: 	Provin Gurung [mailto:pgurung@research.telcordia.com] 
> Sent:	Thursday, June 07, 2001 12:48 AM
> To:	Ashwani Kumar Kesharwani
> Cc:	Varadarajan Srinivasan; sip@lists.bell-labs.com
> Subject:	Re: [SIP] Proxy - A simple question
> 
> On Thu, 7 Jun 2001, Ashwani Kumar Kesharwani wrote:
> 
> > Hi It is actually like this.
> > With in first request UAC provides its contact address so that UAS sends a
> > final response at the contact address mentioned rather than sending it
> > through all the proxies.
> 
> I think there is a slight misunderstanding here,
> The contact is there so that future requests from the called
> UA can be sent directly to the calling UA. All the responses *must*
> traverse back the same path that the request followed, i.e responses are
> forwarded to the top via field of the SIP message. The responses cannot
> bypass the proxies. 
> 
> Proveen Gurung
> 
> Telcordia Technologies,
> MCC-1H-209R,
> 445,South Street,
> Morristown,NJ,USA-07960-6438
> Tel (973)829-2323
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> 

Telcordia Technologies,
MCC-1H-209R,
445,South Street,
Morristown,NJ-07960-6438
Tel (973)829-2323


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


From sip-admin@lists.bell-labs.com  Thu Jun  7 16:56:10 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14461
	for ; Thu, 7 Jun 2001 16:56:09 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4866C443C9; Thu,  7 Jun 2001 16:56:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail1.telefonica.com.ar (mail.telefonica.com.ar [168.226.49.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 4370B4433D
	for ; Thu,  7 Jun 2001 16:55:47 -0400 (EDT)
Received: by MAIL1 with Internet Mail Service (5.5.2448.0)
	id ; Thu, 7 Jun 2001 17:54:43 -0300
Message-ID: <19364262E259D51198BA0008C7E6528E091A04@MSTELEFONICA8>
From: De Leo Walter 
To: "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Proxy - A basic question
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 7 Jun 2001 17:54:34 -0300
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA14461

Hi
In initial deployments of sip bridging, with perhaps a couple of MGC talkin
SIP between each other is not uncommon that they 'know' each other's IP
address. I agree that for scalability issues and for advanced service
implementations it is desireble the existence of proxies, they could be
obviated in that kind of scenarios in an initial stage.

What do you think?

Best Regards,
Walter.
> -----Mensaje original-----
> De:	Victor A Paulsamy [SMTP:victor@voicecore.com]
> Enviado el:	Miércoles 6 de Junio de 2001 10:42
> Para:	Varadarajan Srinivasan
> CC:	SIP; Victor A Paulsamy
> Asunto:	RE: [SIP] Proxy - A basic question
> 
> 	Hi Varadarajan,
> 	 
> 	Even if an UA is calling another UA within the same domain, proxy
> receives the call, looks up in the registration database, extracts Contact
> address and forwards the call. To reach the callee directly, caller needs
> to know the IP address and port of the callee, which is very unlikely in
> real life.
> 	 
> 	Warm regards,
> 	 
> 	--victor
> 	 
> 	 -----Original Message-----
> 	From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Varadarajan Srinivasan
> 	Sent: Wednesday, June 06, 2001 8:09 PM
> 	To: sip@lists.bell-labs.com
> 	Subject: [SIP] Proxy - A basic question
> 	
> 	
> 	Hi, 
> 
> 	From RFC, We are asked to look upon proxy as DNS sort. 
> 
> 	Can I assume that UA "MUST"  be tagged to a proxy? 
> 	That is all calls to UA outside its domain should come via proxy? 
> 	  
> 	  
> 	Mr. Varadarajan Srinivasan,
> 	Senior Systems Engineer,
> 	Wipro Technologies.
> 	  
> 

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


From sip-admin@lists.bell-labs.com  Thu Jun  7 18:30:40 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15460
	for ; Thu, 7 Jun 2001 18:30:40 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C396B443A9; Thu,  7 Jun 2001 18:31:06 -0400 (EDT)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 1F21444356
	for ; Thu,  7 Jun 2001 18:30:51 -0400 (EDT)
To: sip@share.research.bell-labs.com
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jun  7 18:27:46 EDT 2001
Received: by lists.bell-labs.com (Postfix)
	id EF2DC44380; Thu,  7 Jun 2001 18:17:25 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from bz0017exch001p.wins.lucent.com (unknown [135.253.94.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 1770E4437D
	for ; Thu,  7 Jun 2001 18:17:24 -0400 (EDT)
Received: by BZ0017EXCH001P with Internet Mail Service (5.5.2650.21)
	id ; Thu, 7 Jun 2001 19:17:22 -0300
Message-ID: <0F103142B6F6D311A80E0008C71BAC295D2B83@BZ3002EXCH001U>
From: "Boaventura, Alberto Magno Silveira (Alberto)" 
Subject: [SIP] (no subject)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 7 Jun 2001 18:27:46 -0400

To: 
Subject: Handoff primitive
Date: Thu, 7 Jun 2001 19:17:21 -0300 
Return-Receipt-To: "Boaventura, Alberto Magno Silveira (Alberto)" 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-sip@lists.bell-labs.com

Greetings All,

What is current status of draft-dean-handoff-00.txt applied in January 19,
2001?

Thanks for any return,
Alberto.




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


From sip-admin@lists.bell-labs.com  Fri Jun  8 04:11:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07495
	for ; Fri, 8 Jun 2001 04:11:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3054B4433D; Fri,  8 Jun 2001 04:12:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb8.rediffmail.com (unknown [202.54.124.153])
	by lists.bell-labs.com (Postfix) with SMTP id 1A65344339
	for ; Fri,  8 Jun 2001 04:11:48 -0400 (EDT)
Received: (qmail 1653 invoked by uid 510); 8 Jun 2001 08:16:22 -0000
Message-ID: <20010608081622.1652.qmail@mailweb8.rediffmail.com>
Received: from unknown (203.195.146.106) by rediffmail.com via HTTP; 08 Jun 2001 08:16:22 -0000
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" 
From: "Deepak  Mohan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [SIP] Missing ACK in bis-03 Section 20.5?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 8 Jun 2001 08:16:22 -0000
Content-Transfer-Encoding: 7bit

In bis-03, section 20.5 Shouldn't there also be an ACK in the P->A direction after getting 487 for the INVITE?

Regards,
Deepak

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





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


From sip-admin@lists.bell-labs.com  Fri Jun  8 11:29:46 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14407
	for ; Fri, 8 Jun 2001 11:29:45 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7BFBE44341; Fri,  8 Jun 2001 11:30:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7])
	by lists.bell-labs.com (Postfix) with ESMTP id 58C5E4433D
	for ; Fri,  8 Jun 2001 11:29:42 -0400 (EDT)
Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id PAA18400
	for ; Fri, 8 Jun 2001 15:29:42 GMT
From: John.Hearty@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id PAA05870
	for ; Fri, 8 Jun 2001 15:29:35 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 8 Jun 2001 09:29:36 -0600
Message-ID: <5035FF399F22D51189820008C7E664CC22F4C0@n0215idc1.oss.level3.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Killing hung media streams
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 8 Jun 2001 09:28:34 -0600


 I have looked through the archives and could not find anything on this
topic, please excuse me if it has been discussed.  We have encountered a
couple of different UAs that are a MGC controlling MGs, and if the UA
crashes and comes back up, a media stream from the MG continues.  By the
time it comes back up, the UA on the other end has done all it's retransmits
trying to tear down the session, and has flushed the call.

 This hung media stream causes problems and consumes resources.  Obviously
some work needs to be done on the MGC - MG implementation to avoid this
problem and clean up after a crash.  However, has there been any discussion
regarding what the receiver of this media might do to inform the UA on the
other end to shut it down (once that UA has come back up)?  I suppose the
receiving UA would need to maintain a history of previous sessions to tie a
media stream back to a UA.  Thoughts?


John Hearty
Level 3 Communications, Inc.

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


From sip-admin@lists.bell-labs.com  Fri Jun  8 12:03:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15258
	for ; Fri, 8 Jun 2001 12:03:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F266A44391; Fri,  8 Jun 2001 12:04:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 8221D4434D
	for ; Fri,  8 Jun 2001 12:03:33 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA27048;
	Fri, 8 Jun 2001 12:07:07 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 8 Jun 2001 12:03:07 -0400
Message-ID: 
From: Igor Slepchin 
To: "'John.Hearty@Level3.com'" ,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Killing hung media streams
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 8 Jun 2001 12:03:03 -0400

> -----Original Message-----
> From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com]
>
> what the receiver of this media might do to inform 
> the UA on the
> other end to shut it down (once that UA has come back up)? 

Send back ICMP errors for what it considers to be stray RTP/RTCP packets?
The sending MG can interpret that as a sign that nobody is prepared to
receive the media and terminate the stream.

Thank you,
Igor Slepchin

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


From sip-admin@ietf.org  Fri Jun  8 12:28:17 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15788;
	Fri, 8 Jun 2001 12:28:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05797;
	Fri, 8 Jun 2001 12:23:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA05734
	for ; Fri, 8 Jun 2001 12:22:57 -0400 (EDT)
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15704;
	Fri, 8 Jun 2001 12:22:27 -0400 (EDT)
Received: from plate (localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f58GMlt20312;
	Fri, 8 Jun 2001 11:22:48 -0500
Message-ID: <000b01c0f037$14b13840$e0fb0cd8@dfwe.dal.wayport.net>
From: "Dean Willis" 
To: "IETF SIPPING" , "IETF SIP" 
Date: Fri, 8 Jun 2001 11:21:04 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Subject: [Sip] SIP and SIPPING Supplemental Web Site Replacement Completed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

http://www.softarmor.com/sipwg and http://www.softarmor.com/sipping now
point to the new web site.

There is a staging server at http://kevlar.softarmor.com/sipwg and
http://kevlar.softarmor.com/sipping/ that will also act as a backup -- not
quite a "mirror", as it actually gets the newer content first by a minute or
two. I'd suggest not using it unless the primary site is down (or you're one
of the people editing the web site).

Enjoy.

BTW -- I'll be working remotely with low bandwidth for the next two weeks,
attending VON Europe and 3GPP meetings in Stockholm. I should still be able
to respond to requests, but will be even slower than my traditional
slothlike pace.

--
Dean


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jun  8 13:29:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17649
	for ; Fri, 8 Jun 2001 13:29:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9A5F144341; Fri,  8 Jun 2001 13:30:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from gatekeeper.calltrol.com (unknown [65.105.250.35])
	by lists.bell-labs.com (Postfix) with ESMTP id D897A4433D
	for ; Fri,  8 Jun 2001 13:29:00 -0400 (EDT)
Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253])
	by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id NAA27657
	for ; Fri, 8 Jun 2001 13:30:50 -0400
Received: by NT-SERVER with Internet Mail Service (5.5.2448.0)
	id ; Fri, 8 Jun 2001 13:31:18 -0400
Message-ID: <60A9CA50081AD4118BD60040F60C1A9F0A3DA4@NT-SERVER>
From: Wai Wu 
To: "'sip@lists.bell-labs.com'" 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F040.D21DAD70"
Subject: [SIP] SIP Also header
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 8 Jun 2001 13:31:15 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F040.D21DAD70
Content-Type: text/plain;
	charset="iso-8859-1"

Hi All,
	Does any one has info for the Also header. I cannot find it in
RFC2543. I have been working with Cisco phones and see this header on Bye
messages when doing a call transfer. 

Regards
Wai Wu

------_=_NextPart_001_01C0F040.D21DAD70
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






SIP Also header




Hi All,

        Does any one has info for the Also header. I cannot find =
it in RFC2543. I have been working with Cisco phones and see this =
header on Bye messages when doing a call transfer. 



Regards

Wai Wu





------_=_NextPart_001_01C0F040.D21DAD70--

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


From sip-admin@lists.bell-labs.com  Fri Jun  8 13:51:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18106
	for ; Fri, 8 Jun 2001 13:51:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 19B8C44383; Fri,  8 Jun 2001 13:52:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.inetmail.att.net (mailhost1.inetmail.att.net [204.127.132.33])
	by lists.bell-labs.com (Postfix) with ESMTP id 6F62C4436D
	for ; Fri,  8 Jun 2001 13:51:01 -0400 (EDT)
Received: from ranjit ([12.41.17.196])
          by mail.inetmail.att.net (mtiagic01) with SMTP
          id <20010608175101gi128288m6e>; Fri, 8 Jun 2001 17:51:01 +0000
Message-ID: <010001c0f044$d3b6f880$c411290c@masconit.com>
Reply-To: "Ranjit Avasarala" 
From: "Ranjit Avasarala" 
To: "Wai Wu" , 
References: <60A9CA50081AD4118BD60040F60C1A9F0A3DA4@NT-SERVER>
Subject: Re: [SIP] SIP Also header
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00FC_01C0F01A.EA5AA980"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 8 Jun 2001 12:59:55 -0500

This is a multi-part message in MIME format.

------=_NextPart_000_00FC_01C0F01A.EA5AA980
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

SIP Also headerthere is some info on Also header in
draft-dcsgroup-sip-state-00.txt

Regards
Ranjit
Mascon Communication Technologies
http://www.masconit.com






  ----- Original Message -----
  From: Wai Wu
  To: 'sip@lists.bell-labs.com'
  Sent: Friday, June 08, 2001 12:31 PM
  Subject: [SIP] SIP Also header


  Hi All,
          Does any one has info for the Also header. I cannot find it in
RFC2543. I have been working with Cisco phones and see this header on Bye
messages when doing a call transfer.

  Regards
  Wai Wu


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


SIP Also header






there is some =
info on Also=20
header in draft-dcsgroup-sip-state-00.txt


 


Regards
Ranjit
Mascon Communication Technologies
http://www.masconit.com


 


 


 


 


 


 


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

  From:=20
  Wai =
Wu 
  
To: 'sip@lists.bell-labs.com' 

  
Sent: Friday, June 08, 2001 =
12:31=20
PM

  
Subject: [SIP] SIP Also =
header

  


  
Hi All,=20
  
        Does=20
  any one has info for the Also header. I cannot find it in RFC2543. I =
have been=20
  working with Cisco phones and see this header on Bye messages when =
doing a=20
  call transfer. 

  
Regards 
Wai=20
  Wu 


------=_NextPart_000_00FC_01C0F01A.EA5AA980--


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


From sip-admin@lists.bell-labs.com  Fri Jun  8 14:30:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18639
	for ; Fri, 8 Jun 2001 14:30:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 614214435D; Fri,  8 Jun 2001 14:31:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121])
	by lists.bell-labs.com (Postfix) with SMTP id 3D9AD44341
	for ; Fri,  8 Jun 2001 14:30:11 -0400 (EDT)
Received: from 157.54.9.100 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 08 Jun 2001 11:29:47 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Fri, 8 Jun 2001 11:28:42 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Fri, 8 Jun 2001 11:28:35 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Fri, 8 Jun 2001 11:27:27 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F048.ABC369CA"
Subject: RE: [SIP] SIP Also header
Message-ID: <2E33960095B58E40A4D3345AB9F65EC1A8414D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [SIP] SIP Also header
Thread-Index: AcDwQNCGu6dcXgWaRfiziXAhcN3aSAAB9PxQ
From: "Junhua Wang" 
To: "Wai Wu" , 
X-OriginalArrivalTime: 08 Jun 2001 18:27:27.0928 (UTC) FILETIME=[ABEF6B80:01C0F048]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 8 Jun 2001 11:27:27 -0700

This is a multi-part message in MIME format.

------_=_NextPart_001_01C0F048.ABC369CA
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

It is removed in bis03 (on page 135).

	-----Original Message-----
	From: Wai Wu [mailto:wwu@calltrol.com]=20
	Sent: Friday, June 08, 2001 10:31 AM
	To: 'sip@lists.bell-labs.com'
	Subject: [SIP] SIP Also header
=09
=09

	Hi All,=20
	        Does any one has info for the Also header. I cannot find
it in RFC2543. I have been working with Cisco phones and see this header
on Bye messages when doing a call transfer.=20

	Regards=20
	Wai Wu=20


------_=_NextPart_001_01C0F048.ABC369CA
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Message




It is =
removed in bis03=20
(on page 135).



  

  
-----Original Message-----
From: Wai =
Wu=20
  [mailto:wwu@calltrol.com] 
Sent: Friday, June 08, 2001 10:31 =

  AM
To: 'sip@lists.bell-labs.com'
Subject: [SIP] =
SIP Also=20
  header


  
Hi All,=20
  
        Does=20
  any one has info for the Also header. I cannot find it in RFC2543. I =
have been=20
  working with Cisco phones and see this header on Bye messages when =
doing a=20
  call transfer. 

  
Regards 
Wai=20
  Wu 

=00
------_=_NextPart_001_01C0F048.ABC369CA--

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


From sip-admin@lists.bell-labs.com  Fri Jun  8 21:19:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22723
	for ; Fri, 8 Jun 2001 21:19:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 11B824435D; Fri,  8 Jun 2001 21:20:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by lists.bell-labs.com (Postfix) with ESMTP id 8B2334434D
	for ; Fri,  8 Jun 2001 21:19:15 -0400 (EDT)
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f591J2E22651
	for ; Fri, 8 Jun 2001 21:19:03 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Fri, 8 Jun 2001 21:18:55 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Fri, 8 Jun 2001 21:19:05 -0400
Message-ID: <28560036253BD41191A10000F8BCBD110250CC87@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" 
To: "'Wai Wu'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] SIP Also header
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0F082.28162AD0"
X-Orig: 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 8 Jun 2001 21:18:57 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F082.28162AD0
Content-Type: text/plain;
	charset="ISO-8859-1"

The draft has expired and the header is deprecated.  Going forward call
transfers will use REFER and the Replaces header.

-----Original Message-----
From: Wai Wu [mailto:wwu@calltrol.com]
Sent: Friday, June 08, 2001 1:31 PM
To: 'sip@lists.bell-labs.com'
Subject: [SIP] SIP Also header


Hi All, 
        Does any one has info for the Also header. I cannot find it in
RFC2543. I have been working with Cisco phones and see this header on Bye
messages when doing a call transfer. 
Regards 
Wai Wu 

------_=_NextPart_001_01C0F082.28162AD0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] SIP Also header




The draft has expired and the header is =
deprecated.  Going forward call transfers will use REFER and the =
Replaces header.



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

From: Wai Wu [mailto:wwu@calltrol.com]

Sent: Friday, June 08, 2001 1:31 PM

To: 'sip@lists.bell-labs.com'

Subject: [SIP] SIP Also header






Hi All, 

        Does any =
one has info for the Also header. I cannot find it in RFC2543. I have =
been working with Cisco phones and see this header on Bye messages when =
doing a call transfer. 



Regards 

Wai Wu 





------_=_NextPart_001_01C0F082.28162AD0--

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


From sip-admin@lists.bell-labs.com  Sat Jun  9 00:41:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26607
	for ; Sat, 9 Jun 2001 00:41:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6A6F84433F; Sat,  9 Jun 2001 00:42:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from femail4.rdc1.on.home.com (femail4.rdc1.on.home.com [24.2.9.91])
	by lists.bell-labs.com (Postfix) with ESMTP id 286F544338
	for ; Sat,  9 Jun 2001 00:41:29 -0400 (EDT)
Received: from cybertron.div8.net ([24.114.8.64])
          by femail4.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP
          id <20010609044128.GTCP10025.femail4.rdc1.on.home.com@cybertron.div8.net>;
          Fri, 8 Jun 2001 21:41:28 -0700
Received: from vektor by cybertron.div8.net with local (Exim 3.12 #1 (Debian))
	id 158aeu-00004z-00; Sat, 09 Jun 2001 00:47:36 -0400
From: Billy Biggs 
To: Alan Johnston 
Cc: Dvir Oren ,
        SIP Implementors ,
        SIP List 
Message-ID: <20010609004736.A243@div8.net>
References: <15130.21550.973473.551003@jodie.lucid> <20010604093456.A7248@div8.net> <3B21336E.4C1FF35C@wcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B21336E.4C1FF35C@wcom.com>; from alan.johnston@wcom.com on Fri, Jun 08, 2001 at 03:19:58PM -0500
Subject: [SIP] Replaces leg matching (was Re: [Sip-implementors] replaces)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 9 Jun 2001 00:47:36 -0400

  Alan,

  I'm posting this to the SIP WG list as well to solicit more opinions.

> I know others have been thinking about whether we need the full To and
> From URLs (or a MD5 hash of them) in the Replaces header.  I'm not
> convinced myself, but there is one possible scenario that could cause
> trouble.  A RFC2543 UAC which is redirected directly to another
> RFC2543 UAS (no proxies in between) could result in a call without any
> tags (To tags are not mandatory in RFC2543 unless there are more than
> one Via headers, ie a proxy in the path).  Now, we are down to relying
> only on the uniqueness of the Call-ID.  Of course, any bis UA will use
> From and To tags.

  Since the Call-ID is unique, I don't see a matching problem.  We can
also recommend that any UA which supports Replaces must also support
bis (at least use tags).

> The only other argument that I've heard that could sway me is that if
> this actual situation was encountered in the real world, the result
> would be disaster.  If a Gateway replaces the wrong session, then the
> wrong session will be dropped and two parties that had no intention of
> talking will suddenly be connected - a very hard thing to explain to
> your customers!

  I see this as the best argument for including the full call leg
identification.

> Wouldn't a MD5 hash of specific parts of the To and From headers
> (user, host, port, and tags, with rules for default handling) answer
> your concerns about URL escaping and header size and eliminate the
> possibility of the wrong session being replaced?

  If only a subset of the information in the To and From is required for
the hash, is this any better than just the tags?  A call-leg matches
when the full URI including parameters and all header parameters match.
So, to _always_ match correctly, we must be complete.

  The problem then becomes one of debugging.  We need to decide on a
canonical form of a URI for conversions (remove all spaces and line
folding, lower case everything you can, make sure you watch for quotes,
careful for invalid URIs, etc etc), and then hope nobody messes up.  If
someone's phone is sending Replaces headers which don't work and a
customer complains, it's difficult to figure who's phone is broken,
since all you have is the hash.

  This may be an acceptable loss, since Replaces has the nice property
that if things do go wrong and everyone has multi-line phones, the
transfer will work fine, but somebody's phone may ring unexpectedly.

  I'd rather just stick with the tags.

> My main concern is that we finish this discussion now so that we can
> finalize the attended transfer call flows now that REFER seems to be
> stable.

  I'd definitely like to see this issue closed.  More thoughts
appreciated.

> Billy Biggs wrote:
> 
> > Dvir Oren (dvir@lucidvon.com):
> >
> > > Are the tags in 'to' and 'from' plus the call-id sufficient to
> > > find a call-leg?  It appears from the replaces draft that this is
> > > all is needed.  However, at least in my implementation, I also
> > > need the 'to' and 'from' themselves, and not only the tags.
> >
> >   It's unclear to my why you feel so strongly about needing the full
> > to and from headers.
> >
> >   In almost all cases, the call-id alone should be sufficient to
> > identify an active call.  For Replaces, the only cases I can think
> > of where the call-id might be insufficient are:
> >
> >   a) Two UAs answer the same call and both are accepted.  When an
> >      INVITE arrives with a replaces, there is a possibility that
> >      both UAs receive the INVITE (some transparent proxy may have
> >      decided to fork it).  In this case, the UAs each check to see
> >      who's tags are listed to determine if they should honour the
> >      Replaces.
> >
> >   b) Some broken UA makes many calls under the same call-id.  In
> >      this case, checking the tags is a cheap way of identifying
> >      which call was intended.
> >
> >   Clearly in these cases, having the tags is useful, and having the
> > full to and from would be more 'correct' (but AFAICT not, as you
> > claim, required).  My reason for just using the tags is a
> > practical one:  if the full to and from are used, the escaping and
> > unescaping gets much worse for very little gain, and we've also
> > greatly increased the length of the header.
> >
> >   I worry about:
> >   Replaces: 8c43a98f-ff8f@dumbterm.net;to=billy@billybiggs.com%3bmobileid%3d9775
> >                                       ;to-tag=88f787f
> >
> >   from:
> >   Refer-To: sip:dvir@lucidvon.com?
> >             Replaces=8c43a98f-ff8f@dumbterm.net%3bto%3dbilly@billybiggs.com
> >                      %253bmobileid%253d9775%3dto-tag%3d88f787f
> >
> >   Where double-escape code decoding is required.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

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


From sip-admin@lists.bell-labs.com  Sat Jun  9 09:50:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14690
	for ; Sat, 9 Jun 2001 09:50:42 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AAAAB4433A; Sat,  9 Jun 2001 09:51:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 0AA7C44338
	for ; Sat,  9 Jun 2001 09:50:03 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f59DncU03275;
	Sat, 9 Jun 2001 06:49:38 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AHV20871;
	Sat, 9 Jun 2001 06:49:29 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA10878; Sat, 9 Jun 2001 06:49:29 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15138.10601.449148.348115@thomasm-u1.cisco.com>
To: John.Hearty@Level3.com
Cc: sip@lists.bell-labs.com
Subject: [SIP] Killing hung media streams
In-Reply-To: <5035FF399F22D51189820008C7E664CC22F4C0@n0215idc1.oss.level3.com>
References: <5035FF399F22D51189820008C7E664CC22F4C0@n0215idc1.oss.level3.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 9 Jun 2001 06:49:29 -0700 (PDT)
Content-Transfer-Encoding: 7bit




John.Hearty@Level3.com writes:
 > 
 >  I have looked through the archives and could not find anything on this
 > topic, please excuse me if it has been discussed.  We have encountered a
 > couple of different UAs that are a MGC controlling MGs, and if the UA
 > crashes and comes back up, a media stream from the MG continues.  By the
 > time it comes back up, the UA on the other end has done all it's retransmits
 > trying to tear down the session, and has flushed the call.
 > 
 >  This hung media stream causes problems and consumes resources.  Obviously
 > some work needs to be done on the MGC - MG implementation to avoid this
 > problem and clean up after a crash.  However, has there been any discussion
 > regarding what the receiver of this media might do to inform the UA on the
 > other end to shut it down (once that UA has come back up)?  I suppose the
 > receiving UA would need to maintain a history of previous sessions to tie a
 > media stream back to a UA.  Thoughts?

   It ought to send an ICMP port unavailable. Also: it would
   probably be a good overall thing to use RTCP for liveliness
   heuristics since it's possible that the partition affected
   the MGC as well, in which case you might not be able to
   get the tear down command even with a well implemented MGC.

	   Mike

 

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


From sip-admin@lists.bell-labs.com  Sat Jun  9 12:14:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15551
	for ; Sat, 9 Jun 2001 12:14:43 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B081B4434D; Sat,  9 Jun 2001 12:15:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from symsj01.sj.symbol.com (symsj01.sj.symbol.com [206.61.138.2])
	by lists.bell-labs.com (Postfix) with SMTP id C807E4434D
	for ; Sat,  9 Jun 2001 12:14:31 -0400 (EDT)
Received: from iserver.sj.symbol.com ([206.61.138.130]) by symsj01.sj.symbol.com
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 9 Jun 2001 16:14:32 UT
Received: from symsj01-qfe0.sj.symbol.com (gwianameserver [157.235.95.252])
	by iserver.sj.symbol.com (8.11.4/8.11.4) with SMTP id f59GCjh17364
	for ; Sat, 9 Jun 2001 09:12:45 -0700 (PDT)
Received: from [157.235.95.252] by symsj01-qfe0.sj.symbol.com
          via smtpd (for iserver.sj.symbol.com [206.61.138.130]) with SMTP; 9 Jun 2001 16:14:31 UT
Received: from SJ-DOM-Message_Server by gwianameserver.sj.symbol.com
	with Novell_GroupWise; Sat, 09 Jun 2001 09:13:36 -0700
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
From: "Richard Watson" 
To: , 
Cc: 
Subject: Re: [SIP] Killing hung media streams
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_1A400E20.EF8EEF7C"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 09 Jun 2001 09:13:23 -0700

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_1A400E20.EF8EEF7C
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

This problem (disappearing media streams), is an real issue with implementa=
tion of a wireless SIP deployment.  There needs to be some intrinsic =
protocol mechanism for bi-directional determination of active states of =
the call participants.

Suggestions on addressing this issue?



Richard Watson
Director of Telephony Product Marketing
Wireless LAN Division
Symbol Technologies, Inc.
6480 Via Del Oro
San Jose, CA 95119-1208
(408) 528-2820

>>> Michael Thomas  06/09/01 06:49AM >>>



John.Hearty@Level3.com writes:
>=20
>  I have looked through the archives and could not find anything on this
> topic, please excuse me if it has been discussed.  We have encountered a
> couple of different UAs that are a MGC controlling MGs, and if the UA
> crashes and comes back up, a media stream from the MG continues.  By the
> time it comes back up, the UA on the other end has done all it's =
retransmits
> trying to tear down the session, and has flushed the call.
>=20
>  This hung media stream causes problems and consumes resources.  =
Obviously
> some work needs to be done on the MGC - MG implementation to avoid this
> problem and clean up after a crash.  However, has there been any =
discussion
> regarding what the receiver of this media might do to inform the UA on =
the
> other end to shut it down (once that UA has come back up)?  I suppose =
the
> receiving UA would need to maintain a history of previous sessions to =
tie a
> media stream back to a UA.  Thoughts?

   It ought to send an ICMP port unavailable. Also: it would
   probably be a good overall thing to use RTCP for liveliness
   heuristics since it's possible that the partition affected
   the MGC as well, in which case you might not be able to
   get the tear down command even with a well implemented MGC.

       Mike



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

--=_1A400E20.EF8EEF7C
Content-Type: text/html; charset=ISO-8859-1
Content-Description: HTML
Content-Transfer-Encoding: quoted-printable







This problem (disappearing media streams), is an real =
issue=20
with implementation of a wireless SIP deployment.  There needs to be =
some=20
intrinsic protocol mechanism for bi-directional determination of=20
active states of the call participants.


 


Suggestions on addressing this issue?


 


 


 


Richard Watson
Director of Telephony Product Marketing
Wireless =
LAN=20
Division
Symbol Technologies, Inc.
6480 Via Del Oro
San Jose, =
CA=20
95119-1208
(408) 528-2820

>>> Michael Thomas=20
<mat@cisco.com> 06/09/01 06:49AM=20
>>>



John.Hearty@Level3.com writes:
>=20

>  I have looked through the archives and could not find =
anything on=20
this
> topic, please excuse me if it has been discussed.  We =
have=20
encountered a
> couple of different UAs that are a MGC controlling =
MGs,=20
and if the UA
> crashes and comes back up, a media stream from the =
MG=20
continues.  By the
> time it comes back up, the UA on the other =
end=20
has done all it's retransmits
> trying to tear down the session, and =
has=20
flushed the call.
> 
>  This hung media stream causes =
problems=20
and consumes resources.  Obviously
> some work needs to be done =
on=20
the MGC - MG implementation to avoid this
> problem and clean up =
after a=20
crash.  However, has there been any discussion
> regarding what =
the=20
receiver of this media might do to inform the UA on the
> other end =
to=20
shut it down (once that UA has come back up)?  I suppose the
>=
=20
receiving UA would need to maintain a history of previous sessions to =
tie=20
a
> media stream back to a UA.  Thoughts?

   =
It=20
ought to send an ICMP port unavailable. Also: it would
   =
probably=20
be a good overall thing to use RTCP for liveliness
   =
heuristics=20
since it's possible that the partition affected
   the MGC as =
well,=20
in which case you might not be able to
   get the tear down =
command=20
even with a well implemented MGC.

      =20=

Mike



_______________________________________________
This=
 list=20
is for continuing development of the SIP protocol.
The sip-implementor's=
 list=20
is the place to discuss implementation,
and to receive advice on=20
understanding existing sip.
To subscribe to it, send mail to=20

sip-implementors-request@cs.columbia.edu with "subscribe" in the=20
body.


--=_1A400E20.EF8EEF7C--

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


From sip-admin@lists.bell-labs.com  Sat Jun  9 15:09:45 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17139
	for ; Sat, 9 Jun 2001 15:09:44 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4306144342; Sat,  9 Jun 2001 15:10:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 591CB44338
	for ; Sat,  9 Jun 2001 15:09:07 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f59J93U12405;
	Sat, 9 Jun 2001 12:09:10 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AHV21633;
	Sat, 9 Jun 2001 12:08:58 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA10917; Sat, 9 Jun 2001 12:08:58 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15138.29769.972047.117131@thomasm-u1.cisco.com>
To: "Richard Watson" 
Cc: , , 
Subject: Re: [SIP] Killing hung media streams
In-Reply-To: 
References: 
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 9 Jun 2001 12:08:57 -0700 (PDT)
Content-Transfer-Encoding: 7bit

Richard Watson writes:
 > This problem (disappearing media streams), is an real issue with implementation of a wireless SIP deployment.  There needs to be some intrinsic protocol mechanism for bi-directional determination of active states of the call participants.
 > 
 > Suggestions on addressing this issue?

   Just like TCP, there can be no algorithmic way to determine the
   difference between a transient network partition, the other
   side croaking, congestion, or VAD. That isn't to say that you
   can't do an adequate job of determining that you're hosed with
   RTCP, it's just that every once in a while an innocent stream
   is going to be sentenced to death. C'est la guerre.

	    Mike


 > 
 > 
 > Richard Watson
 > Director of Telephony Product Marketing
 > Wireless LAN Division
 > Symbol Technologies, Inc.
 > 6480 Via Del Oro
 > San Jose, CA 95119-1208
 > (408) 528-2820
 > 
 > >>> Michael Thomas  06/09/01 06:49AM >>>
 > 
 > 
 > 
 > John.Hearty@Level3.com writes:
 > > 
 > >  I have looked through the archives and could not find anything on this
 > > topic, please excuse me if it has been discussed.  We have encountered a
 > > couple of different UAs that are a MGC controlling MGs, and if the UA
 > > crashes and comes back up, a media stream from the MG continues.  By the
 > > time it comes back up, the UA on the other end has done all it's retransmits
 > > trying to tear down the session, and has flushed the call.
 > > 
 > >  This hung media stream causes problems and consumes resources.  Obviously
 > > some work needs to be done on the MGC - MG implementation to avoid this
 > > problem and clean up after a crash.  However, has there been any discussion
 > > regarding what the receiver of this media might do to inform the UA on the
 > > other end to shut it down (once that UA has come back up)?  I suppose the
 > > receiving UA would need to maintain a history of previous sessions to tie a
 > > media stream back to a UA.  Thoughts?
 > 
 >    It ought to send an ICMP port unavailable. Also: it would
 >    probably be a good overall thing to use RTCP for liveliness
 >    heuristics since it's possible that the partition affected
 >    the MGC as well, in which case you might not be able to
 >    get the tear down command even with a well implemented MGC.
 > 
 >        Mike
 > 
 > 
 > 
 > _______________________________________________
 > This list is for continuing development of the SIP protocol.
 > The sip-implementor's list is the place to discuss implementation,
 > and to receive advice on understanding existing sip.
 > To subscribe to it, send mail to 
 > sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
 > 
 > 
 > 
 > 
 > 
 > 
This problem (disappearing media streams), is an real issue 
 > with implementation of a wireless SIP deployment.  There needs to be some 
 > intrinsic protocol mechanism for bi-directional determination of 
 > active states of the call participants.

 > 
 

 > 
Suggestions on addressing this issue?

 > 
 

 > 
 

 > 
 

 > 
Richard Watson
Director of Telephony Product Marketing
Wireless LAN 
 > Division
Symbol Technologies, Inc.
6480 Via Del Oro
San Jose, CA 
 > 95119-1208
(408) 528-2820

>>> Michael Thomas 
 > <mat@cisco.com> 06/09/01 06:49AM 
 > >>>



John.Hearty@Level3.com writes:
> 
 > 
>  I have looked through the archives and could not find anything on 
 > this
> topic, please excuse me if it has been discussed.  We have 
 > encountered a
> couple of different UAs that are a MGC controlling MGs, 
 > and if the UA
> crashes and comes back up, a media stream from the MG 
 > continues.  By the
> time it comes back up, the UA on the other end 
 > has done all it's retransmits
> trying to tear down the session, and has 
 > flushed the call.
> 
>  This hung media stream causes problems 
 > and consumes resources.  Obviously
> some work needs to be done on 
 > the MGC - MG implementation to avoid this
> problem and clean up after a 
 > crash.  However, has there been any discussion
> regarding what the 
 > receiver of this media might do to inform the UA on the
> other end to 
 > shut it down (once that UA has come back up)?  I suppose the
> 
 > receiving UA would need to maintain a history of previous sessions to tie 
 > a
> media stream back to a UA.  Thoughts?

   It 
 > ought to send an ICMP port unavailable. Also: it would
   probably 
 > be a good overall thing to use RTCP for liveliness
   heuristics 
 > since it's possible that the partition affected
   the MGC as well, 
 > in which case you might not be able to
   get the tear down command 
 > even with a well implemented MGC.

       
 > Mike



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


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


From sip-admin@lists.bell-labs.com  Sat Jun  9 15:27:41 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17499
	for ; Sat, 9 Jun 2001 15:27:40 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3888E4434D; Sat,  9 Jun 2001 15:28:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 4813C44342
	for ; Sat,  9 Jun 2001 15:27:44 -0400 (EDT)
Received: from plate (localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f59JRIt21539;
	Sat, 9 Jun 2001 14:27:18 -0500
Message-ID: <002101c0f119$ff534ea0$b4ec74d5@plate>
From: "Dean Willis" 
To: "Michael Thomas" , "Richard Watson" 
Cc: , , 
References:  <15138.29769.972047.117131@thomasm-u1.cisco.com>
Subject: Re: [SIP] Killing hung media streams
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 9 Jun 2001 14:25:47 -0500
Content-Transfer-Encoding: 7bit


I believe that if one were to use RTCP at 5-second granularity for media
liveness determination of a voice session, one might safely assume at 3
misses that either the far end has dropped or that the network in between
has gone byby and hang up the call.  Do you really want call a with
15-seconf hoels in it to stay "up"? We're not talking
voice-activiity-detection here, either . . .

As Michael  points out, media streaming to a UA that has rebooted is likely
to result in an ICMP port unreachable message UNLESS that UA has recycled
the port. If the port has been recycled, we hopefully get an SSRC mismatch
(what happens then? This seems like a likely case.) In the very unlikely
case of a birthday paradox on SSRC at the same port, one could have an
interesting condition develop (maybe very likely with bad implementations of
SSRC and weak port randomization) with two senders and no way to identify or
tear down the "ghost" leg.
.
I also suspect that John's original post begs the question of "something
like session timer" for MGCP. That is, he's asking the legitmate MGCP
question of "what happens if the MGC loses synch with the MG". Great
question. Wrong working group.

--
Dean



----- Original Message -----
From: "Michael Thomas" 
To: "Richard Watson" 
Cc: ; ; 
Sent: Saturday, June 09, 2001 2:08 PM
Subject: Re: [SIP] Killing hung media streams


> Richard Watson writes:
>  > This problem (disappearing media streams), is an real issue with
implementation of a wireless SIP deployment.  There needs to be some
intrinsic protocol mechanism for bi-directional determination of active
states of the call participants.
>  >
>  > Suggestions on addressing this issue?
>
>    Just like TCP, there can be no algorithmic way to determine the
>    difference between a transient network partition, the other
>    side croaking, congestion, or VAD. That isn't to say that you
>    can't do an adequate job of determining that you're hosed with
>    RTCP, it's just that every once in a while an innocent stream
>    is going to be sentenced to death. C'est la guerre.
>
>     Mike
>
>
>  >
>  >
>  > Richard Watson
>  > Director of Telephony Product Marketing
>  > Wireless LAN Division
>  > Symbol Technologies, Inc.
>  > 6480 Via Del Oro
>  > San Jose, CA 95119-1208
>  > (408) 528-2820
>  >
>  > >>> Michael Thomas  06/09/01 06:49AM >>>
>  >
>  >
>  >
>  > John.Hearty@Level3.com writes:
>  > >
>  > >  I have looked through the archives and could not find anything on
this
>  > > topic, please excuse me if it has been discussed.  We have
encountered a
>  > > couple of different UAs that are a MGC controlling MGs, and if the UA
>  > > crashes and comes back up, a media stream from the MG continues.  By
the
>  > > time it comes back up, the UA on the other end has done all it's
retransmits
>  > > trying to tear down the session, and has flushed the call.
>  > >
>  > >  This hung media stream causes problems and consumes resources.
Obviously
>  > > some work needs to be done on the MGC - MG implementation to avoid
this
>  > > problem and clean up after a crash.  However, has there been any
discussion
>  > > regarding what the receiver of this media might do to inform the UA
on the
>  > > other end to shut it down (once that UA has come back up)?  I suppose
the
>  > > receiving UA would need to maintain a history of previous sessions to
tie a
>  > > media stream back to a UA.  Thoughts?
>  >
>  >    It ought to send an ICMP port unavailable. Also: it would
>  >    probably be a good overall thing to use RTCP for liveliness
>  >    heuristics since it's possible that the partition affected
>  >    the MGC as well, in which case you might not be able to
>  >    get the tear down command even with a well implemented MGC.
>  >
>  >        Mike
>  >
>  >
>  >
>  > _______________________________________________
>  > This list is for continuing development of the SIP protocol.
>  > The sip-implementor's list is the place to discuss implementation,
>  > and to receive advice on understanding existing sip.
>  > To subscribe to it, send mail to
>  > sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
This problem (disappearing media streams), is an real
issue
>  > with implementation of a wireless SIP deployment.  There needs to
be some
>  > intrinsic protocol mechanism for bi-directional determination of
>  > active states of the call participants.

>  > 
 

>  > 
Suggestions on addressing this issue?

>  > 
 

>  > 
 

>  > 
 

>  > 
Richard Watson
Director of Telephony Product
Marketing
Wireless LAN
>  > Division
Symbol Technologies, Inc.
6480 Via Del Oro
San Jose,
CA
>  > 95119-1208
(408) 528-2820

>>> Michael Thomas
>  > <mat@cisco.com> 06/09/01 06:49AM
>  > >>>



John.Hearty@Level3.com writes:
>
>  > 
>  I have looked through the archives and could not find
anything on
>  > this
> topic, please excuse me if it has been discussed.  We
have
>  > encountered a
> couple of different UAs that are a MGC
controlling MGs,
>  > and if the UA
> crashes and comes back up, a media stream from
the MG
>  > continues.  By the
> time it comes back up, the UA on the
other end
>  > has done all it's retransmits
> trying to tear down the session,
and has
>  > flushed the call.
> 
>  This hung media stream causes
problems
>  > and consumes resources.  Obviously
> some work needs to be
done on
>  > the MGC - MG implementation to avoid this
> problem and clean up
after a
>  > crash.  However, has there been any discussion
> regarding
what the
>  > receiver of this media might do to inform the UA on the
> other
end to
>  > shut it down (once that UA has come back up)?  I suppose
the
>
>  > receiving UA would need to maintain a history of previous sessions to
tie
>  > a
> media stream back to a UA. 
Thoughts?

   It
>  > ought to send an ICMP port unavailable. Also: it would
  
probably
>  > be a good overall thing to use RTCP for liveliness
  
heuristics
>  > since it's possible that the partition affected
   the MGC
as well,
>  > in which case you might not be able to
   get the tear
down command
>  > even with a well implemented MGC.

   
  
>  >
Mike



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

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


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


From sip-admin@lists.bell-labs.com  Sat Jun  9 18:28:40 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19709
	for ; Sat, 9 Jun 2001 18:28:40 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3DBCC44355; Sat,  9 Jun 2001 18:29:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from symsj01.sj.symbol.com (symsj01.sj.symbol.com [206.61.138.2])
	by lists.bell-labs.com (Postfix) with SMTP id 7107C4434D
	for ; Sat,  9 Jun 2001 18:28:32 -0400 (EDT)
Received: from iserver.sj.symbol.com ([206.61.138.130]) by symsj01.sj.symbol.com
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 9 Jun 2001 22:28:33 UT
Received: from symsj01-qfe0.sj.symbol.com (gwianameserver [157.235.95.252])
	by iserver.sj.symbol.com (8.11.4/8.11.4) with SMTP id f59MQjh18233
	for ; Sat, 9 Jun 2001 15:26:45 -0700 (PDT)
Received: from [157.235.95.252] by symsj01-qfe0.sj.symbol.com
          via smtpd (for iserver.sj.symbol.com [206.61.138.130]) with SMTP; 9 Jun 2001 22:28:32 UT
Received: from SJ-DOM-Message_Server by gwianameserver.sj.symbol.com
	with Novell_GroupWise; Sat, 09 Jun 2001 15:27:39 -0700
Message-Id: 
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
From: "Richard Watson" 
To: 
Cc: , , 
Subject: Re: [SIP] Killing hung media streams
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_18420CCB.D5B4D547"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 09 Jun 2001 15:27:31 -0700

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_18420CCB.D5B4D547
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Thanks for the input.  One of the behaviors that Symbol has found that is =
broadly accepted by our wireless H.323 implementations is the ability to =
be in a call; step out-of-coverage; be notified by audio "beep"; and back =
into coverage within 15 seconds to sustain the call.  This "robustness" of =
call management has been a real plus with our NetVision H.323 implementatio=
n.  Any longer than a 15 second window, the call needs to be torn down on =
both sides in an automated fashion.

let's keep the discussion goin....

richWatson/Symbol

>>> "Dean Willis"  06/09/01 12:25PM >>>

I believe that if one were to use RTCP at 5-second granularity for media
liveness determination of a voice session, one might safely assume at 3
misses that either the far end has dropped or that the network in between
has gone byby and hang up the call.  Do you really want call a with
15-seconf hoels in it to stay "up"? We're not talking
voice-activiity-detection here, either . . .

As Michael  points out, media streaming to a UA that has rebooted is =
likely
to result in an ICMP port unreachable message UNLESS that UA has recycled
the port. If the port has been recycled, we hopefully get an SSRC mismatch
(what happens then? This seems like a likely case.) In the very unlikely
case of a birthday paradox on SSRC at the same port, one could have an
interesting condition develop (maybe very likely with bad implementations =
of
SSRC and weak port randomization) with two senders and no way to identify =
or
tear down the "ghost" leg.
.
I also suspect that John's original post begs the question of "something
like session timer" for MGCP. That is, he's asking the legitmate MGCP
question of "what happens if the MGC loses synch with the MG". Great
question. Wrong working group.

--
Dean



----- Original Message -----
From: "Michael Thomas" 
To: "Richard Watson" 
Cc: ; ; 
Sent: Saturday, June 09, 2001 2:08 PM
Subject: Re: [SIP] Killing hung media streams


> Richard Watson writes:
>  > This problem (disappearing media streams), is an real issue with
implementation of a wireless SIP deployment.  There needs to be some
intrinsic protocol mechanism for bi-directional determination of active
states of the call participants.
>  >
>  > Suggestions on addressing this issue?
>
>    Just like TCP, there can be no algorithmic way to determine the
>    difference between a transient network partition, the other
>    side croaking, congestion, or VAD. That isn't to say that you
>    can't do an adequate job of determining that you're hosed with
>    RTCP, it's just that every once in a while an innocent stream
>    is going to be sentenced to death. C'est la guerre.
>
>     Mike
>
>
>  >
>  >
>  > Richard Watson
>  > Director of Telephony Product Marketing
>  > Wireless LAN Division
>  > Symbol Technologies, Inc.
>  > 6480 Via Del Oro
>  > San Jose, CA 95119-1208
>  > (408) 528-2820
>  >
>  > >>> Michael Thomas  06/09/01 06:49AM >>>
>  >
>  >
>  >
>  > John.Hearty@Level3.com writes:
>  > >
>  > >  I have looked through the archives and could not find anything on
this
>  > > topic, please excuse me if it has been discussed.  We have
encountered a
>  > > couple of different UAs that are a MGC controlling MGs, and if the =
UA
>  > > crashes and comes back up, a media stream from the MG continues.  =
By
the
>  > > time it comes back up, the UA on the other end has done all it's
retransmits
>  > > trying to tear down the session, and has flushed the call.
>  > >
>  > >  This hung media stream causes problems and consumes resources.
Obviously
>  > > some work needs to be done on the MGC - MG implementation to avoid
this
>  > > problem and clean up after a crash.  However, has there been any
discussion
>  > > regarding what the receiver of this media might do to inform the UA
on the
>  > > other end to shut it down (once that UA has come back up)?  I =
suppose
the
>  > > receiving UA would need to maintain a history of previous sessions =
to
tie a
>  > > media stream back to a UA.  Thoughts?
>  >
>  >    It ought to send an ICMP port unavailable. Also: it would
>  >    probably be a good overall thing to use RTCP for liveliness
>  >    heuristics since it's possible that the partition affected
>  >    the MGC as well, in which case you might not be able to
>  >    get the tear down command even with a well implemented MGC.
>  >
>  >        Mike
>  >
>  >
>  >
>  > _______________________________________________
>  > This list is for continuing development of the SIP protocol.
>  > The sip-implementor's list is the place to discuss implementation,
>  > and to receive advice on understanding existing sip.
>  > To subscribe to it, send mail to
>  > sip-implementors-request@cs.columbia.edu with "subscribe" in the =
body.
>  > 
>  > 
>  > 
>  > 
>  > 
>  > 
This problem (disappearing media streams), is an =
real
issue
>  > with implementation of a wireless SIP deployment.  There needs =
to
be some
>  > intrinsic protocol mechanism for bi-directional determination of
>  > active states of the call participants.

>  > 
 

>  > 
Suggestions on addressing this issue?
=

>  > 
 

>  > 
 

>  > 
 

>  > 
Richard Watson
Director of Telephony Product
Marketing
Wireless LAN
>  > Division
Symbol Technologies, Inc.
6480 Via Del Oro
San =
Jose,
CA
>  > 95119-1208
(408) 528-2820

>>> Michael Thomas
>  > <mat@cisco.com> 06/09/01 06:49AM
>  > >>>



John.Hearty@Level3.com writes:
>
>  > 
>  I have looked through the archives and could not find
anything on
>  > this
> topic, please excuse me if it has been discussed.  =
We
have
>  > encountered a
> couple of different UAs that are a MGC
controlling MGs,
>  > and if the UA
> crashes and comes back up, a media stream from
the MG
>  > continues.  By the
> time it comes back up, the UA on the
other end
>  > has done all it's retransmits
> trying to tear down the =
session,
and has
>  > flushed the call.
> 
>  This hung media stream =
causes
problems
>  > and consumes resources.  Obviously
> some work needs to be
done on
>  > the MGC - MG implementation to avoid this
> problem and clean =
up
after a
>  > crash.  However, has there been any discussion
> regarding
what the
>  > receiver of this media might do to inform the UA on the
> other
end to
>  > shut it down (once that UA has come back up)?  I suppose
the
>
>  > receiving UA would need to maintain a history of previous sessions to
tie
>  > a
> media stream back to a UA. 
Thoughts?

   It
>  > ought to send an ICMP port unavailable. Also: it would
  =

probably
>  > be a good overall thing to use RTCP for liveliness
  
heuristics
>  > since it's possible that the partition affected
   the =
MGC
as well,
>  > in which case you might not be able to
   get the tear
down command
>  > even with a well implemented MGC.

   
  
>  >
Mike



_______________________________________________
This=

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

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


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

--=_18420CCB.D5B4D547
Content-Type: text/html; charset=ISO-8859-1
Content-Description: HTML
Content-Transfer-Encoding: quoted-printable







Thanks for the input.  One of the behaviors that =
Symbol=20
has found that is broadly accepted by our wireless H.323 implementations =
is the=20
ability to be in a call; step out-of-coverage; be notified by audio =
"beep"; and=20
back into coverage within 15 seconds to sustain the call.  This=20
"robustness" of call management has been a real plus with our NetVision =
H.323=20
implementation.  Any longer than a 15 second window, the call needs =
to be=20
torn down on both sides in an automated fashion.


 


let's keep the discussion goin....


 


richWatson/Symbol

>>> "Dean =
Willis"=20
<dean.willis@softarmor.com> 06/09/01 12:25PM >>>

I =
believe=20
that if one were to use RTCP at 5-second granularity for media
liveness=
=20
determination of a voice session, one might safely assume at 3
misses =
that=20
either the far end has dropped or that the network in between
has gone =
byby=20
and hang up the call.  Do you really want call a with
15-seconf =
hoels in=20
it to stay "up"? We're not talking
voice-activiity-detection here, =
either . .=20
.

As Michael  points out, media streaming to a UA that has =
rebooted=20
is likely
to result in an ICMP port unreachable message UNLESS that UA =
has=20
recycled
the port. If the port has been recycled, we hopefully get an =
SSRC=20
mismatch
(what happens then? This seems like a likely case.) In the =
very=20
unlikely
case of a birthday paradox on SSRC at the same port, one could =
have=20
an
interesting condition develop (maybe very likely with bad implementat=
ions=20
of
SSRC and weak port randomization) with two senders and no way to =
identify=20
or
tear down the "ghost" leg.
.
I also suspect that John's =
original=20
post begs the question of "something
like session timer" for MGCP. That =
is,=20
he's asking the legitmate MGCP
question of "what happens if the MGC =
loses=20
synch with the MG". Great
question. Wrong working=20
group.

--
Dean



----- Original Message -----
Fro=
m:=20
"Michael Thomas" <mat@cisco.com>
To: "Richard Watson"=20
<rwatson@sj.symbol.com>
Cc: <mat@cisco.com>;=20
<John.Hearty@Level3.com>; <sip@lists.bell-labs.com>
Sent:=20=

Saturday, June 09, 2001 2:08 PM
Subject: Re: [SIP] Killing hung =
media=20
streams


> Richard Watson writes:
>  > This =
problem=20
(disappearing media streams), is an real issue with
implementation of =
a=20
wireless SIP deployment.  There needs to be some
intrinsic =
protocol=20
mechanism for bi-directional determination of active
states of the =
call=20
participants.
>  >
>  > Suggestions on =
addressing=20
this issue?
>
>    Just like TCP, there can be =
no=20
algorithmic way to determine the
>    difference =
between a=20
transient network partition, the other
>    side =
croaking,=20
congestion, or VAD. That isn't to say that you
>    =
can't=20
do an adequate job of determining that you're hosed=20
with
>    RTCP, it's just that every once in a while =
an=20
innocent stream
>    is going to be sentenced to =
death.=20
C'est la guerre.
>
>    =20
Mike
>
>
>  >
>  >
>  =
>=20
Richard Watson
>  > Director of Telephony Product=20
Marketing
>  > Wireless LAN Division
>  > =
Symbol=20
Technologies, Inc.
>  > 6480 Via Del Oro
>  > =
San=20
Jose, CA 95119-1208
>  > (408) 528-2820
> =20
>
>  > >>> Michael Thomas <mat@cisco.com>=
=20
06/09/01 06:49AM >>>
>  >
> =20
>
>  >
>  > John.Hearty@Level3.com=20
writes:
>  > >
>  > >  I have =
looked=20
through the archives and could not find anything on
this
>  =
>=20
> topic, please excuse me if it has been discussed.  We=20
have
encountered a
>  > > couple of different UAs that =
are a=20
MGC controlling MGs, and if the UA
>  > > crashes and =
comes=20
back up, a media stream from the MG continues.  By
the
> =
;=20
> > time it comes back up, the UA on the other end has done all=20
it's
retransmits
>  > > trying to tear down the =
session, and=20
has flushed the call.
>  > >
>  > > =
 This=20
hung media stream causes problems and consumes=20
resources.
Obviously
>  > > some work needs to be done =
on=20
the MGC - MG implementation to avoid
this
>  > > =
problem and=20
clean up after a crash.  However, has there been=20
any
discussion
>  > > regarding what the receiver of =
this=20
media might do to inform the UA
on the
>  > > other =
end to=20
shut it down (once that UA has come back up)?  I=20
suppose
the
>  > > receiving UA would need to maintain =
a=20
history of previous sessions to
tie a
>  > > media =
stream=20
back to a UA.  Thoughts?
>  >
> =20
>    It ought to send an ICMP port unavailable. Also: =
it=20
would
>  >    probably be a good overall =
thing to=20
use RTCP for liveliness
>  >    heuristics =
since=20
it's possible that the partition affected
>  >  &nb=
sp;=20
the MGC as well, in which case you might not be able to
> =20
>    get the tear down command even with a well =
implemented=20
MGC.
>  >
> =20
>        Mike
> =20
>
>  >
>  >
>  >=20
_______________________________________________
>  > This =
list is=20
for continuing development of the SIP protocol.
>  > The=20
sip-implementor's list is the place to discuss implementation,
> =
;=20
> and to receive advice on understanding existing sip.
>  =
> To=20
subscribe to it, send mail to
>  >=20
sip-implementors-request@cs.columbia.edu with "subscribe" in the=20
body.
>  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0=20
Transitional//EN">
>  > <HTML><HEAD>
>&n=
bsp;=20
> <META content=3D"text/html; charset=3Diso-8859-1"=20
http-equiv=3DContent-Type>
>  > <META content=3D"MSHTML=
=20
5.00.2614.3500" name=3DGENERATOR></HEAD>
>  > =
<BODY=20
style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px;=20
MARGIN-TOP:
2px">
>  > <DIV><FONT size=3D1>=
This=20
problem (disappearing media streams), is an real
issue
>  =
>=20
with implementation of a wireless SIP deployment.&nbsp; There needs =
to
be=20
some
>  > intrinsic protocol mechanism for bi-directional=20
determination of
>  > active&nbsp;states of the call=20
participants.</FONT></DIV>
>  >=20
<DIV>&nbsp;</DIV>
>  > <DIV><FONT=20=

size=3D1>Suggestions on addressing this=20
issue?</FONT></DIV>
>  >=20
<DIV>&nbsp;</DIV>
>  >=20
<DIV>&nbsp;</DIV>
>  >=20
<DIV>&nbsp;</DIV>
>  > <DIV>Richard=20
Watson<BR>Director of Telephony Product
Marketing<BR>Wireles=
s=20
LAN
>  > Division<BR>Symbol Technologies, Inc.<BR>=
;6480=20
Via Del Oro<BR>San Jose,
CA
>  >=20
95119-1208<BR>(408) 528-2820<BR><BR>&gt;&gt;&=
gt;=20
Michael Thomas
>  > &lt;mat@cisco.com&gt; 06/09/01=20=

06:49AM
>  >=20
&gt;&gt;&gt;<BR><BR><BR><BR>John.Hearty=
@Level3.com=20
writes:<BR>&gt;
>  > <BR>&gt;&nbsp; =
I have=20
looked through the archives and could not find
anything on
> =
 >=20
this<BR>&gt; topic, please excuse me if it has been=20
discussed.&nbsp; We
have
>  > encountered=20
a<BR>&gt; couple of different UAs that are a MGC
controlling=
=20
MGs,
>  > and if the UA<BR>&gt; crashes and comes =
back=20
up, a media stream from
the MG
>  > continues.&nbsp; =
By=20
the<BR>&gt; time it comes back up, the UA on the
other=20
end
>  > has done all it's retransmits<BR>&gt; =
trying to=20
tear down the session,
and has
>  > flushed the=20
call.<BR>&gt; <BR>&gt;&nbsp; This hung media =
stream=20
causes
problems
>  > and consumes resources.&nbsp;=20
Obviously<BR>&gt; some work needs to be
done on
>  =
>=20
the MGC - MG implementation to avoid this<BR>&gt; problem and =
clean=20
up
after a
>  > crash.&nbsp; However, has there been =
any=20
discussion<BR>&gt; regarding
what the
>  > =
receiver=20
of this media might do to inform the UA on the<BR>&gt; other
e=
nd=20
to
>  > shut it down (once that UA has come back up)?&nbs=
p; I=20
suppose
the<BR>&gt;
>  > receiving UA would =
need to=20
maintain a history of previous sessions to
tie
>  >=20
a<BR>&gt; media stream back to a=20
UA.&nbsp;
Thoughts?<BR><BR>&nbsp;&nbsp;=20
It
>  > ought to send an ICMP port unavailable. Also: it=20
would<BR>&nbsp;&nbsp;
probably
>  > be a =
good=20
overall thing to use RTCP for=20
liveliness<BR>&nbsp;&nbsp;
heuristics
>  > =
since=20
it's possible that the partition affected<BR>&nbsp;&nbsp; =
the=20
MGC
as well,
>  > in which case you might not be able=20
to<BR>&nbsp;&nbsp; get the tear
down command
> =
 >=20
even with a well implemented=20
MGC.<BR><BR>&nbsp;&nbsp;&nbsp;
&nbsp;&nb=
sp;
> =20
>
Mike<BR><BR><BR><BR>_______________________=
________________________<BR>This
list
> =20
> is for continuing development of the SIP=20
protocol.<BR>The
sip-implementor's list
>  > is the =
place=20
to discuss implementation,<BR>and to receive advice on
>  =
>=20
understanding existing sip.<BR>To subscribe to it, send mail=20
to
>  > <BR>sip-implementors-request@cs.columbia.edu =
with=20
"subscribe" in the
>  >=20
body.<BR></DIV></BODY></HTML>
>
>=20
_______________________________________________
> This list is =
for=20
continuing development of the SIP protocol.
> The sip-implementor's =
list=20
is the place to discuss implementation,
> and to receive advice =
on=20
understanding existing sip.
> To subscribe to it, send mail =
to
>=20
sip-implementors-request@cs.columbia.edu with "subscribe" in the=20
body.
>


_______________________________________________This=20
list is for continuing development of the SIP protocol.
The sip-implemen=
tor's=20
list is the place to discuss implementation,
and to receive advice =
on=20
understanding existing sip.
To subscribe to it, send mail to=20

sip-implementors-request@cs.columbia.edu with "subscribe" in the=20
body.


--=_18420CCB.D5B4D547--

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


From sip-admin@lists.bell-labs.com  Sat Jun  9 22:16:41 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22747
	for ; Sat, 9 Jun 2001 22:16:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6AA8044355; Sat,  9 Jun 2001 22:17:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id 1302F4433C
	for ; Sat,  9 Jun 2001 22:16:39 -0400 (EDT)
Received: from pmismtp03.wcomnet.com ([166.38.62.38])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0GEO00AGIZNQ4K@firewall.mcit.com> for sip@lists.bell-labs.com;
 Sun, 10 Jun 2001 02:16:38 +0000 (GMT)
Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GEO00E01ZNPK4@pmismtp03.wcomnet.com>;
 Sun, 10 Jun 2001 02:16:38 +0000 (GMT)
Received: from hsinnreich ([166.44.138.13])
 by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 with SMTP id <0GEO003O4ZMY48@pmismtp03.wcomnet.com>; Sun,
 10 Jun 2001 02:16:24 +0000 (GMT)
From: Henry Sinnreich 
Subject: RE: [SIP] Killing hung media streams
In-reply-to: 
To: Richard Watson , dean.willis@softarmor.com
Cc: mat@cisco.com, John.Hearty@Level3.com, sip@lists.bell-labs.com
Message-id: 
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_g0hzCTngUC+MGjDcIE7NVw)"
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 09 Jun 2001 21:16:11 -0500

This is a multi-part message in MIME format.

--Boundary_(ID_g0hzCTngUC+MGjDcIE7NVw)
Content-type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

>let's keep the discussion goin....
wrong group, not here.
Henry
  -----Original Message-----
  From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Richard Watson
  Sent: Saturday, June 09, 2001 5:28 PM
  To: dean.willis@softarmor.com
  Cc: mat@cisco.com; John.Hearty@Level3.com; sip@lists.bell-labs.com
  Subject: Re: [SIP] Killing hung media streams


  Thanks for the input.  One of the behaviors that Symbol has found that is
broadly accepted by our wireless H.323 implementations is the ability to be
in a call; step out-of-coverage; be notified by audio "beep"; and back into
coverage within 15 seconds to sustain the call.  This "robustness" of call
management has been a real plus with our NetVision H.323 implementation.
Any longer than a 15 second window, the call needs to be torn down on both
sides in an automated fashion.

  let's keep the discussion goin....

  richWatson/Symbol

  >>> "Dean Willis"  06/09/01 12:25PM >>>

  I believe that if one were to use RTCP at 5-second granularity for media
  liveness determination of a voice session, one might safely assume at 3
  misses that either the far end has dropped or that the network in between
  has gone byby and hang up the call.  Do you really want call a with
  15-seconf hoels in it to stay "up"? We're not talking
  voice-activiity-detection here, either . . .

  As Michael  points out, media streaming to a UA that has rebooted is
likely
  to result in an ICMP port unreachable message UNLESS that UA has recycled
  the port. If the port has been recycled, we hopefully get an SSRC mismatch
  (what happens then? This seems like a likely case.) In the very unlikely
  case of a birthday paradox on SSRC at the same port, one could have an
  interesting condition develop (maybe very likely with bad implementations
of
  SSRC and weak port randomization) with two senders and no way to identify
or
  tear down the "ghost" leg.
  .
  I also suspect that John's original post begs the question of "something
  like session timer" for MGCP. That is, he's asking the legitmate MGCP
  question of "what happens if the MGC loses synch with the MG". Great
  question. Wrong working group.

  --
  Dean



  ----- Original Message -----
  From: "Michael Thomas" 
  To: "Richard Watson" 
  Cc: ; ; 
  Sent: Saturday, June 09, 2001 2:08 PM
  Subject: Re: [SIP] Killing hung media streams


  > Richard Watson writes:
  >  > This problem (disappearing media streams), is an real issue with
  implementation of a wireless SIP deployment.  There needs to be some
  intrinsic protocol mechanism for bi-directional determination of active
  states of the call participants.
  >  >
  >  > Suggestions on addressing this issue?
  >
  >    Just like TCP, there can be no algorithmic way to determine the
  >    difference between a transient network partition, the other
  >    side croaking, congestion, or VAD. That isn't to say that you
  >    can't do an adequate job of determining that you're hosed with
  >    RTCP, it's just that every once in a while an innocent stream
  >    is going to be sentenced to death. C'est la guerre.
  >
  >     Mike
  >
  >
  >  >
  >  >
  >  > Richard Watson
  >  > Director of Telephony Product Marketing
  >  > Wireless LAN Division
  >  > Symbol Technologies, Inc.
  >  > 6480 Via Del Oro
  >  > San Jose, CA 95119-1208
  >  > (408) 528-2820
  >  >
  >  > >>> Michael Thomas  06/09/01 06:49AM >>>
  >  >
  >  >
  >  >
  >  > John.Hearty@Level3.com writes:
  >  > >
  >  > >  I have looked through the archives and could not find anything on
  this
  >  > > topic, please excuse me if it has been discussed.  We have
  encountered a
  >  > > couple of different UAs that are a MGC controlling MGs, and if the
UA
  >  > > crashes and comes back up, a media stream from the MG continues.
By
  the
  >  > > time it comes back up, the UA on the other end has done all it's
  retransmits
  >  > > trying to tear down the session, and has flushed the call.
  >  > >
  >  > >  This hung media stream causes problems and consumes resources.
  Obviously
  >  > > some work needs to be done on the MGC - MG implementation to avoid
  this
  >  > > problem and clean up after a crash.  However, has there been any
  discussion
  >  > > regarding what the receiver of this media might do to inform the UA
  on the
  >  > > other end to shut it down (once that UA has come back up)?  I
suppose
  the
  >  > > receiving UA would need to maintain a history of previous sessions
to
  tie a
  >  > > media stream back to a UA.  Thoughts?
  >  >
  >  >    It ought to send an ICMP port unavailable. Also: it would
  >  >    probably be a good overall thing to use RTCP for liveliness
  >  >    heuristics since it's possible that the partition affected
  >  >    the MGC as well, in which case you might not be able to
  >  >    get the tear down command even with a well implemented MGC.
  >  >
  >  >        Mike
  >  >
  >  >
  >  >
  >  > _______________________________________________
  >  > This list is for continuing development of the SIP protocol.
  >  > The sip-implementor's list is the place to discuss implementation,
  >  > and to receive advice on understanding existing sip.
  >  > To subscribe to it, send mail to
  >  > sip-implementors-request@cs.columbia.edu with "subscribe" in the
body.
  >  > 
  >  > 
  >  > 
  >  > 
  >  > 
  >  > 
This problem (disappearing media streams), is an
real
  issue
  >  > with implementation of a wireless SIP deployment.  There needs
to
  be some
  >  > intrinsic protocol mechanism for bi-directional determination of
  >  > active states of the call participants.

  >  > 
 

  >  > 
Suggestions on addressing this issue?

  >  > 
 

  >  > 
 

  >  > 
 

  >  > 
Richard Watson
Director of Telephony Product
  Marketing
Wireless LAN
  >  > Division
Symbol Technologies, Inc.
6480 Via Del Oro
San
Jose,
  CA
  >  > 95119-1208
(408) 528-2820

>>> Michael Thomas
  >  > <mat@cisco.com> 06/09/01 06:49AM
  >  > >>>



John.Hearty@Level3.com writes:
>
  >  > 
>  I have looked through the archives and could not find
  anything on
  >  > this
> topic, please excuse me if it has been discussed. 
We
  have
  >  > encountered a
> couple of different UAs that are a MGC
  controlling MGs,
  >  > and if the UA
> crashes and comes back up, a media stream from
  the MG
  >  > continues.  By the
> time it comes back up, the UA on the
  other end
  >  > has done all it's retransmits
> trying to tear down the
session,
  and has
  >  > flushed the call.
> 
>  This hung media stream
causes
  problems
  >  > and consumes resources.  Obviously
> some work needs to be
  done on
  >  > the MGC - MG implementation to avoid this
> problem and clean
up
  after a
  >  > crash.  However, has there been any discussion
> regarding
  what the
  >  > receiver of this media might do to inform the UA on the
> other
  end to
  >  > shut it down (once that UA has come back up)?  I suppose
  the
>
  >  > receiving UA would need to maintain a history of previous sessions to
  tie
  >  > a
> media stream back to a UA. 
  Thoughts?

   It
  >  > ought to send an ICMP port unavailable. Also: it
would
  
  probably
  >  > be a good overall thing to use RTCP for liveliness
  
  heuristics
  >  > since it's possible that the partition affected
   the
MGC
  as well,
  >  > in which case you might not be able to
   get the tear
  down command
  >  > even with a well implemented MGC.

   
    
  >  >

Mike



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

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


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


--Boundary_(ID_g0hzCTngUC+MGjDcIE7NVw)
Content-type: text/html; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable







>let's keep the =
discussion=20
goin....


wrong group, not=20
here.


Henry



  
-----Original Message-----
From:=20
  sip-admin@lists.bell-labs.com =
[mailto:sip-admin@lists.bell-labs.com]On=20
  Behalf Of Richard Watson
Sent: Saturday, June 09, 2001 =
5:28=20
  PM
To: dean.willis@softarmor.com
Cc: =
mat@cisco.com;=20
  John.Hearty@Level3.com; sip@lists.bell-labs.com
Subject: Re: =
[SIP]=20
  Killing hung media streams


  
Thanks for the input.  One of the behaviors =
that Symbol=20
  has found that is broadly accepted by our wireless H.323 =
implementations is=20
  the ability to be in a call; step out-of-coverage; be notified by =
audio=20
  "beep"; and back into coverage within 15 seconds to sustain the =
call. =20
  This "robustness" of call management has been a real plus with our =
NetVision=20
  H.323 implementation.  Any longer than a 15 second window, the =
call needs=20
  to be torn down on both sides in an automated fashion.

  
 

  
let's keep the discussion goin....

  
 

  
richWatson/Symbol

>>> "Dean =
Willis"=20
  <dean.willis@softarmor.com> 06/09/01 12:25PM =
>>>

I=20
  believe that if one were to use RTCP at 5-second granularity for=20
  media
liveness determination of a voice session, one might safely =
assume at=20
  3
misses that either the far end has dropped or that the network in =

  between
has gone byby and hang up the call.  Do you really =
want call a=20
  with
15-seconf hoels in it to stay "up"? We're not=20
  talking
voice-activiity-detection here, either . . .

As=20
  Michael  points out, media streaming to a UA that has rebooted is =

  likely
to result in an ICMP port unreachable message UNLESS that UA =
has=20
  recycled
the port. If the port has been recycled, we hopefully get =
an SSRC=20
  mismatch
(what happens then? This seems like a likely case.) In the =
very=20
  unlikely
case of a birthday paradox on SSRC at the same port, one =
could=20
  have an
interesting condition develop (maybe very likely with bad=20
  implementations of
SSRC and weak port randomization) with two =
senders and=20
  no way to identify or
tear down the "ghost" leg.
.
I also =
suspect=20
  that John's original post begs the question of "something
like =
session=20
  timer" for MGCP. That is, he's asking the legitmate MGCP
question =
of "what=20
  happens if the MGC loses synch with the MG". Great
question. Wrong =
working=20
  group.

--
Dean



----- Original Message =
-----
From:=20
  "Michael Thomas" <mat@cisco.com>
To: "Richard Watson"=20
  <rwatson@sj.symbol.com>
Cc: <mat@cisco.com>;=20
  <John.Hearty@Level3.com>; =
<sip@lists.bell-labs.com>
Sent:=20
  Saturday, June 09, 2001 2:08 PM
Subject: Re: [SIP] Killing hung =
media=20
  streams


> Richard Watson writes:
>  > This =
problem=20
  (disappearing media streams), is an real issue with
implementation =
of a=20
  wireless SIP deployment.  There needs to be some
intrinsic =
protocol=20
  mechanism for bi-directional determination of active
states of the =
call=20
  participants.
>  >
>  > Suggestions on =
addressing=20
  this issue?
>
>    Just like TCP, there can =
be no=20
  algorithmic way to determine the
>    difference =
between=20
  a transient network partition, the other
>    =
side=20
  croaking, congestion, or VAD. That isn't to say that=20
  you
>    can't do an adequate job of determining =
that=20
  you're hosed with
>    RTCP, it's just that every =
once in=20
  a while an innocent stream
>    is going to be =
sentenced=20
  to death. C'est la guerre.
>
>    =20
  Mike
>
>
>  >
>  =
>
>  >=20
  Richard Watson
>  > Director of Telephony Product=20
  Marketing
>  > Wireless LAN Division
>  > =
Symbol=20
  Technologies, Inc.
>  > 6480 Via Del Oro
>  =
> San=20
  Jose, CA 95119-1208
>  > (408) 528-2820
> =20
  >
>  > >>> Michael Thomas =
<mat@cisco.com>=20
  06/09/01 06:49AM >>>
>  >
> =20
  >
>  >
>  > John.Hearty@Level3.com=20
  writes:
>  > >
>  > >  I have =
looked=20
  through the archives and could not find anything =
on
this
>  >=20
  > topic, please excuse me if it has been discussed.  We=20
  have
encountered a
>  > > couple of different UAs =
that are=20
  a MGC controlling MGs, and if the UA
>  > > crashes =
and comes=20
  back up, a media stream from the MG continues.  =
By
the
> =20
  > > time it comes back up, the UA on the other end has done all=20
  it's
retransmits
>  > > trying to tear down the =
session,=20
  and has flushed the call.
>  > >
>  >=20
  >  This hung media stream causes problems and consumes=20
  resources.
Obviously
>  > > some work needs to be =
done on=20
  the MGC - MG implementation to avoid
this
>  > > =
problem=20
  and clean up after a crash.  However, has there been=20
  any
discussion
>  > > regarding what the receiver =
of this=20
  media might do to inform the UA
on the
>  > > =
other end to=20
  shut it down (once that UA has come back up)?  I=20
  suppose
the
>  > > receiving UA would need to =
maintain a=20
  history of previous sessions to
tie a
>  > > media =
stream=20
  back to a UA.  Thoughts?
>  >
> =20
  >    It ought to send an ICMP port unavailable. =
Also: it=20
  would
>  >    probably be a good overall =
thing to=20
  use RTCP for liveliness
>  >    =
heuristics since=20
  it's possible that the partition affected
>  =
>   =20
  the MGC as well, in which case you might not be able to
> =20
  >    get the tear down command even with a well =
implemented=20
  MGC.
>  >
> =20
  >        Mike
> =20
  >
>  >
>  >
>  >=20
  _______________________________________________
>  > =
This list=20
  is for continuing development of the SIP protocol.
>  > =
The=20
  sip-implementor's list is the place to discuss =
implementation,
> =20
  > and to receive advice on understanding existing =
sip.
>  >=20
  To subscribe to it, send mail to
>  >=20
  sip-implementors-request@cs.columbia.edu with "subscribe" in the=20
  body.
>  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML =
4.0=20
  Transitional//EN">
>  >=20
  <HTML><HEAD>
>  > <META =
content=3D"text/html;=20
  charset=3Diso-8859-1" http-equiv=3DContent-Type>
>  > =
<META=20
  content=3D"MSHTML 5.00.2614.3500" =
name=3DGENERATOR></HEAD>
> =20
  > <BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px;=20
  MARGIN-TOP:
2px">
>  > <DIV><FONT =
size=3D1>This=20
  problem (disappearing media streams), is an =
real
issue
>  >=20
  with implementation of a wireless SIP deployment.&nbsp; There =
needs=20
  to
be some
>  > intrinsic protocol mechanism for=20
  bi-directional determination of
>  > =
active&nbsp;states of=20
  the call participants.</FONT></DIV>
>  >=20
  <DIV>&nbsp;</DIV>
>  > =
<DIV><FONT=20
  size=3D1>Suggestions on addressing this=20
  issue?</FONT></DIV>
>  >=20
  <DIV>&nbsp;</DIV>
>  >=20
  <DIV>&nbsp;</DIV>
>  >=20
  <DIV>&nbsp;</DIV>
>  > =
<DIV>Richard=20
  Watson<BR>Director of Telephony =
Product
Marketing<BR>Wireless=20
  LAN
>  > Division<BR>Symbol Technologies,=20
  Inc.<BR>6480 Via Del Oro<BR>San Jose,
CA
>  =
>=20
  95119-1208<BR>(408) =
528-2820<BR><BR>&gt;&gt;&gt;=20
  Michael Thomas
>  > &lt;mat@cisco.com&gt; =
06/09/01=20
  06:49AM
>  >=20
  =
&gt;&gt;&gt;<BR><BR><BR><BR>John.Hear=
ty@Level3.com=20
  writes:<BR>&gt;
>  > =
<BR>&gt;&nbsp; I=20
  have looked through the archives and could not find
anything=20
  on
>  > this<BR>&gt; topic, please excuse me =
if it has=20
  been discussed.&nbsp; We
have
>  > encountered=20
  a<BR>&gt; couple of different UAs that are a =
MGC
controlling=20
  MGs,
>  > and if the UA<BR>&gt; crashes and =
comes back=20
  up, a media stream from
the MG
>  > =
continues.&nbsp; By=20
  the<BR>&gt; time it comes back up, the UA on the
other=20
  end
>  > has done all it's retransmits<BR>&gt; =
trying=20
  to tear down the session,
and has
>  > flushed the=20
  call.<BR>&gt; <BR>&gt;&nbsp; This hung media =
stream=20
  causes
problems
>  > and consumes =
resources.&nbsp;=20
  Obviously<BR>&gt; some work needs to be
done =
on
> =20
  > the MGC - MG implementation to avoid this<BR>&gt; =
problem and=20
  clean up
after a
>  > crash.&nbsp; However, has =
there=20
  been any discussion<BR>&gt; regarding
what =
the
>  >=20
  receiver of this media might do to inform the UA on =
the<BR>&gt;=20
  other
end to
>  > shut it down (once that UA has come =
back=20
  up)?&nbsp; I suppose
the<BR>&gt;
>  > =
receiving=20
  UA would need to maintain a history of previous sessions=20
  to
tie
>  > a<BR>&gt; media stream back to =
a=20
  UA.&nbsp;
Thoughts?<BR><BR>&nbsp;&nbsp;=20
  It
>  > ought to send an ICMP port unavailable. Also: it =

  would<BR>&nbsp;&nbsp;
probably
>  > be =
a good=20
  overall thing to use RTCP for=20
  liveliness<BR>&nbsp;&nbsp;
heuristics
>  =
>=20
  since it's possible that the partition =
affected<BR>&nbsp;&nbsp;=20
  the MGC
as well,
>  > in which case you might not be =
able=20
  to<BR>&nbsp;&nbsp; get the tear
down =
command
> =20
  > even with a well implemented=20
  =
MGC.<BR><BR>&nbsp;&nbsp;&nbsp;
&nbsp;&=
nbsp;
> =20
  =
>
Mike<BR><BR><BR><BR>_____________________=
__________________________<BR>This
list
> =20
  > is for continuing development of the SIP=20
  protocol.<BR>The
sip-implementor's list
>  > is =
the=20
  place to discuss implementation,<BR>and to receive advice=20
  on
>  > understanding existing sip.<BR>To =
subscribe to it,=20
  send mail to
>  >=20
  <BR>sip-implementors-request@cs.columbia.edu with "subscribe" in =

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


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


--Boundary_(ID_g0hzCTngUC+MGjDcIE7NVw)--

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


From sip-admin@lists.bell-labs.com  Sun Jun 10 10:25:41 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11150
	for ; Sun, 10 Jun 2001 10:25:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 50ECD4433A; Sun, 10 Jun 2001 10:26:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by lists.bell-labs.com (Postfix) with ESMTP id 191CF44338
	for ; Sun, 10 Jun 2001 10:25:28 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5AENmF08054;
	Sun, 10 Jun 2001 07:23:48 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AHV23753;
	Sun, 10 Jun 2001 07:25:22 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA11201; Sun, 10 Jun 2001 07:25:21 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15139.33617.711457.490377@thomasm-u1.cisco.com>
To: "Richard Watson" 
Cc: , , ,
        
Subject: Re: [SIP] Killing hung media streams
In-Reply-To: 
References: 
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 10 Jun 2001 07:25:21 -0700 (PDT)
Content-Transfer-Encoding: 7bit

Richard Watson writes:
 > Thanks for the input.  One of the behaviors that Symbol has found that is broadly accepted by our wireless H.323 implementations is the ability to be in a call; step out-of-coverage; be notified by audio "beep"; and back into coverage within 15 seconds to sustain the call.  This "robustness" of call management has been a real plus with our NetVision H.323 implementation.  Any longer than a 15 second window, the call needs to be torn down on both sides in an automated fashion.
 > 
 > let's keep the discussion goin....

  In this case, the RTCP check (assuming that the other side
  isn't a broken implementation and doesn't send RTCP) is
  probably adequate for reaping long term failures. Note 
  that people are generally a lot less patient, so this is
  usually only a problem when a person isn't attending to
  the call. 

  As for Dean's port-reuse scenario, sounds like a good
  reason to use keyed hashes on the media ala SRTP :-)

	    Mike

 > 
 > richWatson/Symbol
 > 
 > >>> "Dean Willis"  06/09/01 12:25PM >>>
 > 
 > I believe that if one were to use RTCP at 5-second granularity for media
 > liveness determination of a voice session, one might safely assume at 3
 > misses that either the far end has dropped or that the network in between
 > has gone byby and hang up the call.  Do you really want call a with
 > 15-seconf hoels in it to stay "up"? We're not talking
 > voice-activiity-detection here, either . . .
 > 
 > As Michael  points out, media streaming to a UA that has rebooted is likely
 > to result in an ICMP port unreachable message UNLESS that UA has recycled
 > the port. If the port has been recycled, we hopefully get an SSRC mismatch
 > (what happens then? This seems like a likely case.) In the very unlikely
 > case of a birthday paradox on SSRC at the same port, one could have an
 > interesting condition develop (maybe very likely with bad implementations of
 > SSRC and weak port randomization) with two senders and no way to identify or
 > tear down the "ghost" leg.
 > .
 > I also suspect that John's original post begs the question of "something
 > like session timer" for MGCP. That is, he's asking the legitmate MGCP
 > question of "what happens if the MGC loses synch with the MG". Great
 > question. Wrong working group.
 > 
 > --
 > Dean
 > 
 > 
 > 
 > ----- Original Message -----
 > From: "Michael Thomas" 
 > To: "Richard Watson" 
 > Cc: ; ; 
 > Sent: Saturday, June 09, 2001 2:08 PM
 > Subject: Re: [SIP] Killing hung media streams
 > 
 > 
 > > Richard Watson writes:
 > >  > This problem (disappearing media streams), is an real issue with
 > implementation of a wireless SIP deployment.  There needs to be some
 > intrinsic protocol mechanism for bi-directional determination of active
 > states of the call participants.
 > >  >
 > >  > Suggestions on addressing this issue?
 > >
 > >    Just like TCP, there can be no algorithmic way to determine the
 > >    difference between a transient network partition, the other
 > >    side croaking, congestion, or VAD. That isn't to say that you
 > >    can't do an adequate job of determining that you're hosed with
 > >    RTCP, it's just that every once in a while an innocent stream
 > >    is going to be sentenced to death. C'est la guerre.
 > >
 > >     Mike
 > >
 > >
 > >  >
 > >  >
 > >  > Richard Watson
 > >  > Director of Telephony Product Marketing
 > >  > Wireless LAN Division
 > >  > Symbol Technologies, Inc.
 > >  > 6480 Via Del Oro
 > >  > San Jose, CA 95119-1208
 > >  > (408) 528-2820
 > >  >
 > >  > >>> Michael Thomas  06/09/01 06:49AM >>>
 > >  >
 > >  >
 > >  >
 > >  > John.Hearty@Level3.com writes:
 > >  > >
 > >  > >  I have looked through the archives and could not find anything on
 > this
 > >  > > topic, please excuse me if it has been discussed.  We have
 > encountered a
 > >  > > couple of different UAs that are a MGC controlling MGs, and if the UA
 > >  > > crashes and comes back up, a media stream from the MG continues.  By
 > the
 > >  > > time it comes back up, the UA on the other end has done all it's
 > retransmits
 > >  > > trying to tear down the session, and has flushed the call.
 > >  > >
 > >  > >  This hung media stream causes problems and consumes resources.
 > Obviously
 > >  > > some work needs to be done on the MGC - MG implementation to avoid
 > this
 > >  > > problem and clean up after a crash.  However, has there been any
 > discussion
 > >  > > regarding what the receiver of this media might do to inform the UA
 > on the
 > >  > > other end to shut it down (once that UA has come back up)?  I suppose
 > the
 > >  > > receiving UA would need to maintain a history of previous sessions to
 > tie a
 > >  > > media stream back to a UA.  Thoughts?
 > >  >
 > >  >    It ought to send an ICMP port unavailable. Also: it would
 > >  >    probably be a good overall thing to use RTCP for liveliness
 > >  >    heuristics since it's possible that the partition affected
 > >  >    the MGC as well, in which case you might not be able to
 > >  >    get the tear down command even with a well implemented MGC.
 > >  >
 > >  >        Mike
 > >  >
 > >  >
 > >  >
 > >  > _______________________________________________
 > >  > This list is for continuing development of the SIP protocol.
 > >  > The sip-implementor's list is the place to discuss implementation,
 > >  > and to receive advice on understanding existing sip.
 > >  > To subscribe to it, send mail to
 > >  > sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
This problem (disappearing media streams), is an real
 > issue
 > >  > with implementation of a wireless SIP deployment.  There needs to
 > be some
 > >  > intrinsic protocol mechanism for bi-directional determination of
 > >  > active states of the call participants.

 > >  > 
 

 > >  > 
Suggestions on addressing this issue?

 > >  > 
 

 > >  > 
 

 > >  > 
 

 > >  > 
Richard Watson
Director of Telephony Product
 > Marketing
Wireless LAN
 > >  > Division
Symbol Technologies, Inc.
6480 Via Del Oro
San Jose,
 > CA
 > >  > 95119-1208
(408) 528-2820

>>> Michael Thomas
 > >  > <mat@cisco.com> 06/09/01 06:49AM
 > >  > >>>



John.Hearty@Level3.com writes:
>
 > >  > 
>  I have looked through the archives and could not find
 > anything on
 > >  > this
> topic, please excuse me if it has been discussed.  We
 > have
 > >  > encountered a
> couple of different UAs that are a MGC
 > controlling MGs,
 > >  > and if the UA
> crashes and comes back up, a media stream from
 > the MG
 > >  > continues.  By the
> time it comes back up, the UA on the
 > other end
 > >  > has done all it's retransmits
> trying to tear down the session,
 > and has
 > >  > flushed the call.
> 
>  This hung media stream causes
 > problems
 > >  > and consumes resources.  Obviously
> some work needs to be
 > done on
 > >  > the MGC - MG implementation to avoid this
> problem and clean up
 > after a
 > >  > crash.  However, has there been any discussion
> regarding
 > what the
 > >  > receiver of this media might do to inform the UA on the
> other
 > end to
 > >  > shut it down (once that UA has come back up)?  I suppose
 > the
>
 > >  > receiving UA would need to maintain a history of previous sessions to
 > tie
 > >  > a
> media stream back to a UA. 
 > Thoughts?

   It
 > >  > ought to send an ICMP port unavailable. Also: it would
  
 > probably
 > >  > be a good overall thing to use RTCP for liveliness
  
 > heuristics
 > >  > since it's possible that the partition affected
   the MGC
 > as well,
 > >  > in which case you might not be able to
   get the tear
 > down command
 > >  > even with a well implemented MGC.

   
 >   
 > >  >
 > Mike



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

 > >
 > > _______________________________________________
 > > This list is for continuing development of the SIP protocol.
 > > The sip-implementor's list is the place to discuss implementation,
 > > and to receive advice on understanding existing sip.
 > > To subscribe to it, send mail to
 > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
 > >
 > 
 > 
 > _______________________________________________
 > This list is for continuing development of the SIP protocol.
 > The sip-implementor's list is the place to discuss implementation,
 > and to receive advice on understanding existing sip.
 > To subscribe to it, send mail to 
 > sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
 > 
 > 
 > 
 > 
 > 
 > 
Thanks for the input.  One of the behaviors that Symbol 
 > has found that is broadly accepted by our wireless H.323 implementations is the 
 > ability to be in a call; step out-of-coverage; be notified by audio "beep"; and 
 > back into coverage within 15 seconds to sustain the call.  This 
 > "robustness" of call management has been a real plus with our NetVision H.323 
 > implementation.  Any longer than a 15 second window, the call needs to be 
 > torn down on both sides in an automated fashion.

 > 
 

 > 
let's keep the discussion goin....

 > 
 

 > 
richWatson/Symbol

>>> "Dean Willis" 
 > <dean.willis@softarmor.com> 06/09/01 12:25PM >>>

I believe 
 > that if one were to use RTCP at 5-second granularity for media
liveness 
 > determination of a voice session, one might safely assume at 3
misses that 
 > either the far end has dropped or that the network in between
has gone byby 
 > and hang up the call.  Do you really want call a with
15-seconf hoels in 
 > it to stay "up"? We're not talking
voice-activiity-detection here, either . . 
 > .

As Michael  points out, media streaming to a UA that has rebooted 
 > is likely
to result in an ICMP port unreachable message UNLESS that UA has 
 > recycled
the port. If the port has been recycled, we hopefully get an SSRC 
 > mismatch
(what happens then? This seems like a likely case.) In the very 
 > unlikely
case of a birthday paradox on SSRC at the same port, one could have 
 > an
interesting condition develop (maybe very likely with bad implementations 
 > of
SSRC and weak port randomization) with two senders and no way to identify 
 > or
tear down the "ghost" leg.
.
I also suspect that John's original 
 > post begs the question of "something
like session timer" for MGCP. That is, 
 > he's asking the legitmate MGCP
question of "what happens if the MGC loses 
 > synch with the MG". Great
question. Wrong working 
 > group.

--
Dean



----- Original Message -----
From: 
 > "Michael Thomas" <mat@cisco.com>
To: "Richard Watson" 
 > <rwatson@sj.symbol.com>
Cc: <mat@cisco.com>; 
 > <John.Hearty@Level3.com>; <sip@lists.bell-labs.com>
Sent: 
 > Saturday, June 09, 2001 2:08 PM
Subject: Re: [SIP] Killing hung media 
 > streams


> Richard Watson writes:
>  > This problem 
 > (disappearing media streams), is an real issue with
implementation of a 
 > wireless SIP deployment.  There needs to be some
intrinsic protocol 
 > mechanism for bi-directional determination of active
states of the call 
 > participants.
>  >
>  > Suggestions on addressing 
 > this issue?
>
>    Just like TCP, there can be no 
 > algorithmic way to determine the
>    difference between a 
 > transient network partition, the other
>    side croaking, 
 > congestion, or VAD. That isn't to say that you
>    can't 
 > do an adequate job of determining that you're hosed 
 > with
>    RTCP, it's just that every once in a while an 
 > innocent stream
>    is going to be sentenced to death. 
 > C'est la guerre.
>
>     
 > Mike
>
>
>  >
>  >
>  > 
 > Richard Watson
>  > Director of Telephony Product 
 > Marketing
>  > Wireless LAN Division
>  > Symbol 
 > Technologies, Inc.
>  > 6480 Via Del Oro
>  > San 
 > Jose, CA 95119-1208
>  > (408) 528-2820
>  
 > >
>  > >>> Michael Thomas <mat@cisco.com> 
 > 06/09/01 06:49AM >>>
>  >
>  
 > >
>  >
>  > John.Hearty@Level3.com 
 > writes:
>  > >
>  > >  I have looked 
 > through the archives and could not find anything on
this
>  > 
 > > topic, please excuse me if it has been discussed.  We 
 > have
encountered a
>  > > couple of different UAs that are a 
 > MGC controlling MGs, and if the UA
>  > > crashes and comes 
 > back up, a media stream from the MG continues.  By
the
>  
 > > > time it comes back up, the UA on the other end has done all 
 > it's
retransmits
>  > > trying to tear down the session, and 
 > has flushed the call.
>  > >
>  > >  This 
 > hung media stream causes problems and consumes 
 > resources.
Obviously
>  > > some work needs to be done on 
 > the MGC - MG implementation to avoid
this
>  > > problem and 
 > clean up after a crash.  However, has there been 
 > any
discussion
>  > > regarding what the receiver of this 
 > media might do to inform the UA
on the
>  > > other end to 
 > shut it down (once that UA has come back up)?  I 
 > suppose
the
>  > > receiving UA would need to maintain a 
 > history of previous sessions to
tie a
>  > > media stream 
 > back to a UA.  Thoughts?
>  >
>  
 > >    It ought to send an ICMP port unavailable. Also: it 
 > would
>  >    probably be a good overall thing to 
 > use RTCP for liveliness
>  >    heuristics since 
 > it's possible that the partition affected
>  >    
 > the MGC as well, in which case you might not be able to
>  
 > >    get the tear down command even with a well implemented 
 > MGC.
>  >
>  
 > >        Mike
>  
 > >
>  >
>  >
>  > 
 > _______________________________________________
>  > This list is 
 > for continuing development of the SIP protocol.
>  > The 
 > sip-implementor's list is the place to discuss implementation,
>  
 > > and to receive advice on understanding existing sip.
>  > To 
 > subscribe to it, send mail to
>  > 
 > sip-implementors-request@cs.columbia.edu with "subscribe" in the 
 > body.
>  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 
 > Transitional//EN">
>  > <HTML><HEAD>
>  
 > > <META content="text/html; charset=iso-8859-1" 
 > http-equiv=Content-Type>
>  > <META content="MSHTML 
 > 5.00.2614.3500" name=GENERATOR></HEAD>
>  > <BODY 
 > style="FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; 
 > MARGIN-TOP:
2px">
>  > <DIV><FONT size=1>This 
 > problem (disappearing media streams), is an real
issue
>  > 
 > with implementation of a wireless SIP deployment.&nbsp; There needs to
be 
 > some
>  > intrinsic protocol mechanism for bi-directional 
 > determination of
>  > active&nbsp;states of the call 
 > participants.</FONT></DIV>
>  > 
 > <DIV>&nbsp;</DIV>
>  > <DIV><FONT 
 > size=1>Suggestions on addressing this 
 > issue?</FONT></DIV>
>  > 
 > <DIV>&nbsp;</DIV>
>  > 
 > <DIV>&nbsp;</DIV>
>  > 
 > <DIV>&nbsp;</DIV>
>  > <DIV>Richard 
 > Watson<BR>Director of Telephony Product
Marketing<BR>Wireless 
 > LAN
>  > Division<BR>Symbol Technologies, Inc.<BR>6480 
 > Via Del Oro<BR>San Jose,
CA
>  > 
 > 95119-1208<BR>(408) 528-2820<BR><BR>&gt;&gt;&gt; 
 > Michael Thomas
>  > &lt;mat@cisco.com&gt; 06/09/01 
 > 06:49AM
>  > 
 > &gt;&gt;&gt;<BR><BR><BR><BR>John.Hearty@Level3.com 
 > writes:<BR>&gt;
>  > <BR>&gt;&nbsp; I have 
 > looked through the archives and could not find
anything on
>  > 
 > this<BR>&gt; topic, please excuse me if it has been 
 > discussed.&nbsp; We
have
>  > encountered 
 > a<BR>&gt; couple of different UAs that are a MGC
controlling 
 > MGs,
>  > and if the UA<BR>&gt; crashes and comes back 
 > up, a media stream from
the MG
>  > continues.&nbsp; By 
 > the<BR>&gt; time it comes back up, the UA on the
other 
 > end
>  > has done all it's retransmits<BR>&gt; trying to 
 > tear down the session,
and has
>  > flushed the 
 > call.<BR>&gt; <BR>&gt;&nbsp; This hung media stream 
 > causes
problems
>  > and consumes resources.&nbsp; 
 > Obviously<BR>&gt; some work needs to be
done on
>  > 
 > the MGC - MG implementation to avoid this<BR>&gt; problem and clean 
 > up
after a
>  > crash.&nbsp; However, has there been any 
 > discussion<BR>&gt; regarding
what the
>  > receiver 
 > of this media might do to inform the UA on the<BR>&gt; other
end 
 > to
>  > shut it down (once that UA has come back up)?&nbsp; I 
 > suppose
the<BR>&gt;
>  > receiving UA would need to 
 > maintain a history of previous sessions to
tie
>  > 
 > a<BR>&gt; media stream back to a 
 > UA.&nbsp;
Thoughts?<BR><BR>&nbsp;&nbsp; 
 > It
>  > ought to send an ICMP port unavailable. Also: it 
 > would<BR>&nbsp;&nbsp;
probably
>  > be a good 
 > overall thing to use RTCP for 
 > liveliness<BR>&nbsp;&nbsp;
heuristics
>  > since 
 > it's possible that the partition affected<BR>&nbsp;&nbsp; the 
 > MGC
as well,
>  > in which case you might not be able 
 > to<BR>&nbsp;&nbsp; get the tear
down command
>  > 
 > even with a well implemented 
 > MGC.<BR><BR>&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;
>  
 > >
Mike<BR><BR><BR><BR>_______________________________________________<BR>This
list
>  
 > > is for continuing development of the SIP 
 > protocol.<BR>The
sip-implementor's list
>  > is the place 
 > to discuss implementation,<BR>and to receive advice on
>  > 
 > understanding existing sip.<BR>To subscribe to it, send mail 
 > to
>  > <BR>sip-implementors-request@cs.columbia.edu with 
 > "subscribe" in the
>  > 
 > body.<BR></DIV></BODY></HTML>
>
> 
 > _______________________________________________
> This list is for 
 > continuing development of the SIP protocol.
> The sip-implementor's list 
 > is the place to discuss implementation,
> and to receive advice on 
 > understanding existing sip.
> To subscribe to it, send mail to
> 
 > sip-implementors-request@cs.columbia.edu with "subscribe" in the 
 > body.
>


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


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


From sip-admin@lists.bell-labs.com  Mon Jun 11 00:41:41 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18661
	for ; Mon, 11 Jun 2001 00:41:41 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4F3B84433C; Mon, 11 Jun 2001 00:42:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 0B6EF44338
	for ; Mon, 11 Jun 2001 00:41:04 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA02628;
	Mon, 11 Jun 2001 00:45:01 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 11 Jun 2001 00:41:00 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Michael Thomas'" , John.Hearty@Level3.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Killing hung media streams
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 00:40:54 -0400



 

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Saturday, June 09, 2001 9:49 AM
> To: John.Hearty@Level3.com
> Cc: sip@lists.bell-labs.com
> Subject: [SIP] Killing hung media streams
> 
> 
> 
> 
> 
> John.Hearty@Level3.com writes:
>  > 
>  >  I have looked through the archives and could not find 
> anything on this
>  > topic, please excuse me if it has been discussed.  We have 
> encountered a
>  > couple of different UAs that are a MGC controlling MGs, 
> and if the UA
>  > crashes and comes back up, a media stream from the MG 
> continues.  By the
>  > time it comes back up, the UA on the other end has done 
> all it's retransmits
>  > trying to tear down the session, and has flushed the call.
>  > 
>  >  This hung media stream causes problems and consumes 
> resources.  Obviously
>  > some work needs to be done on the MGC - MG implementation 
> to avoid this
>  > problem and clean up after a crash.  However, has there 
> been any discussion
>  > regarding what the receiver of this media might do to 
> inform the UA on the
>  > other end to shut it down (once that UA has come back up)? 
>  I suppose the
>  > receiving UA would need to maintain a history of previous 
> sessions to tie a
>  > media stream back to a UA.  Thoughts?
> 
>    It ought to send an ICMP port unavailable. Also: it would
>    probably be a good overall thing to use RTCP for liveliness
>    heuristics since it's possible that the partition affected
>    the MGC as well, in which case you might not be able to
>    get the tear down command even with a well implemented MGC.


I agree with the others that have suggested ICMP port unreachables. A few
additional comments to that.

First, for those of you for whom 5 second RTCP intervals is too long (since
that would require perhaps 15 seconds to detect a failure through timeout),
there is a draft on an SDP extension for indicating the RTCP bandwidth
allocation:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-bw-03.txt

which can allow you to up the frequency.

A more interesting question is this: what is the right behavior for a UA
that starts to get ICMP port unreachable errors on the RTP stream? I have
encountered two very different scenarios for this. In one case, the right
behavior is to consider the call terminated. Another, more interesting case,
is to immediately send a re-INVITE in order to re-establish the call at a
backup of the remote peer. This turns out to be very useful for high
availability conferencing and media systems. Thus, there may be a need for
some kind of flag somewhere to indicate which behavior a UA desires when its
peer starts to receive ICMP errors from it. I'm working on an I-D on this
topic. Stay tuned...

-Jonathan R.

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

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 00:54:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18732
	for ; Mon, 11 Jun 2001 00:54:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E608744348; Mon, 11 Jun 2001 00:55:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 6775F4433C
	for ; Mon, 11 Jun 2001 00:54:54 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA02665;
	Mon, 11 Jun 2001 00:58:51 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 11 Jun 2001 00:54:50 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Deepak  Mohan'" , sip@lists.bell-labs.com
Subject: RE: [SIP] SIP URLs in Contact
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 00:54:48 -0400



 

> -----Original Message-----
> From: Deepak Mohan [mailto:deepakwarrier@rediffmail.com]
> Sent: Thursday, June 07, 2001 4:03 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] SIP URLs in Contact
> 
> 
> Hi,
> 2.2 of bis-03 says that Contact in OPTIONS should have only 
> SIP URLs, but 10.14 says that "For OPTIONS, Contact provides 
> a hint where future SIP requests can be sent or the user can 
> be contacted via non-SIP means.
> 
> Clarifications?

The right answer depends on the interpretation of the Contact in the OPTIONS
response. Really, Contact has two separate meanings. The one in INVITE and
INVITE-200 are signaling addresses, which always need to be one single SIP
URL. The Contact in 3xx, REGISTER, and REGISTER-200 are alternate names for
a user, which can be non-SIP URLs, and there can be more than one. The
distinction is subtle (and this is why its one header), but I have become
convinced that they are distinct.

Now, which of these two do we want in OPTIONS? If we are trying to obtain a
direct address for signaling for INVITE, then we want the first
interpretation, in which case it needs to be a single SIP URL. If its a set
of alternate names for a user, then it can be multiple non-SIP URLs. I'm
inclined to think its the latter.

-Jonathan R.


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


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


From sip-admin@lists.bell-labs.com  Mon Jun 11 01:01:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18793
	for ; Mon, 11 Jun 2001 01:01:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3968144362; Mon, 11 Jun 2001 01:02:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 6C6C444348
	for ; Mon, 11 Jun 2001 01:01:15 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA02718;
	Mon, 11 Jun 2001 01:05:11 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 11 Jun 2001 01:01:11 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Deepak  Mohan'" , sip@lists.bell-labs.com
Subject: RE: [SIP] Missing ACK in bis-03 Section 20.5?
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 01:01:00 -0400



 

> -----Original Message-----
> From: Deepak Mohan [mailto:deepakwarrier@rediffmail.com]
> Sent: Friday, June 08, 2001 4:16 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Missing ACK in bis-03 Section 20.5?
> 
> 
> In bis-03, section 20.5 Shouldn't there also be an ACK in the 
> P->A direction after getting 487 for the INVITE?

Yup. Will add. Thanks.

-Jonathan R.

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

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 01:25:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20172
	for ; Mon, 11 Jun 2001 01:25:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BA42D4434D; Mon, 11 Jun 2001 01:26:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 72D2344338
	for ; Mon, 11 Jun 2001 01:25:02 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA02819;
	Mon, 11 Jun 2001 01:28:22 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 11 Jun 2001 01:24:21 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Jose Martinez'" ,
        Ashwani Kumar Kesharwani ,
        sip@lists.bell-labs.com
Subject: RE: [SIP] (no subject)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 01:24:16 -0400



 

> -----Original Message-----
> From: Jose Martinez [mailto:jmartine_1026@yahoo.com]
> Sent: Tuesday, June 05, 2001 4:10 PM
> To: Ashwani Kumar Kesharwani; sip@lists.bell-labs.com
> Subject: Re: [SIP] (no subject)
> 
> 
> it will reply with a 409 Conflict or 403 Forbiden i
> think.

No, that is not correct. It does what a redirect server does, which is
redirect the request. To do that, it does what it normally does. It looks up
the request URI in its location service (here, its a URI without a
username), and if it knows how to redirect that, it does so. If not, it can
generate a 404, as a redirect server would for any other URI it doesn't know
about.

-Jonathan R.

> --- Ashwani Kumar Kesharwani
>  wrote:
> > Hi
> > 
> > If a redirect server receives a REGISTER request
> > what should it do?
> > 
> > If it redirects to UAC then what should be the
> > contact address.
> > 
> > 
> 

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

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 01:28:40 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20413
	for ; Mon, 11 Jun 2001 01:28:40 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9D7604434D; Mon, 11 Jun 2001 01:29:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 09DC14434D
	for ; Mon, 11 Jun 2001 01:28:28 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA02839;
	Mon, 11 Jun 2001 01:32:22 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 11 Jun 2001 01:28:21 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Baniel Uri-CUB001'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Invitation for a multicast session
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 01:28:13 -0400



 

> -----Original Message-----
> From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com]
> Sent: Monday, June 04, 2001 10:36 AM
> To: 'Jonathan Rosenberg'; 'sip@lists.bell-labs.com'
> Subject: RE: [SIP] Invitation for a multicast session
> 
> 
> OK now it is really clear! Thanks!!
> Anyways in case a "race" condition has happened and both 
> stations (say B and
> C) responded with a 200 OK. (i.e. despite of the 
> delay-response and Cancel
> mechanisms described in the spec), what is the correct 
> behavior of the UAC?
> Say he wants to accept B and reject C, does it need to Ack C 
> (in order to
> complete the 1st transaction) and then right away sends it a BYE?
> (I know I am actually asking here a generic and probably a naive/basic
> question regarding how a UAC should behave in case it does not want to
> accept the 200...)

Sounds like its time to repeat the mantra:

All transactions complete independently.
All transactions complete independently.
All transactions complete independently.

Applying our beloved mantra here, the UAC will ACK both, and then send BYE
to the ones it doesn't want. As Vijay has pointed out, this is much clearer
in the current spec.

-Jonathan R.


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

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 01:33:40 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20718
	for ; Mon, 11 Jun 2001 01:33:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8BE194436B; Mon, 11 Jun 2001 01:34:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 73E0E4434A
	for ; Mon, 11 Jun 2001 01:33:33 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA02864;
	Mon, 11 Jun 2001 01:37:32 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 11 Jun 2001 01:33:32 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Gonzalo Camarillo'" ,
        sip 
Cc: Jon Peterson , adam.roach@ericsson.com
Subject: RE: [SIP] SUS/RES encapsulation
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 01:33:24 -0400



 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Tuesday, June 05, 2001 7:07 PM
> To: sip
> Cc: Jon Peterson; adam.roach@ericsson.com
> Subject: [SIP] SUS/RES encapsulation
> 
> 
> Hello,
> 
> I have received some feedback regarding the ISUP SUS/RES sequence. In
> the ISUP-SIP mapping draft it is recommended to send them inside a
> re-INVITE with media on hold.
> 
> While everybody agrees that this should be the recommended behavior,
> some folks would like to be able to send SUS/RES in INFO as well. They
> would do so when they were not interested in putting the media on hold
> (in SIP bridging situations for example).
> 
> How do people feel about outlining this possible behavior in 
> the draft?

I don't like it, for two reasons:

1. Its a bad thing to have too many ways to do the same thing.

2. The whole idea with SIP-T is to continue to use SIP to drive call
control, with the ISUP bodies merely providing additional information that
an ISUP gateway might want. Therefore, whenever possible, ISUP functionality
should be mapped to its SIP equivalent. I may be mistaken, but I thought
that SUS really was an end-to-end hold of media, and therefore, should be
mapped to the equivalent function in SIP - a re-INVITE with 0.0.0.0 SDP. 


The point of SIP-T is *not* to simply tunnel all messages in INFO.

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

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 02:03:40 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27130
	for ; Mon, 11 Jun 2001 02:03:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BB7274433C; Mon, 11 Jun 2001 02:04:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 0539344338
	for ; Mon, 11 Jun 2001 02:03:27 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA03035;
	Mon, 11 Jun 2001 02:07:23 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 11 Jun 2001 02:03:23 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Ashhar Farhan'" , sip@lists.bell-labs.com
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	er
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 02:03:20 -0400



 

> -----Original Message-----
> From: Ashhar Farhan [mailto:afarhan@rediffmail.com]
> Sent: Monday, June 04, 2001 3:28 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Authentication and billing through 
> proxy/re-direct server
> 
> 
> in a typical next gen telco setup, the billing is centralised 
> and their Point of presence are basically SIP servers that 
> gateway to PSTN cloud.
> 
> the INVITE gets redirected/proxied from the central server 
> and the is resend to the gateway (a sip server).
> here, we have an issue of user authentication. the user has 
> to be authenticated by the redirect/proxy server. the 
> authentication (as per the SIP recommendations) should be md5 digest. 
> the scheme would be that the redirect/proxy should generate a 
> digest over the redirected INVITE request using the nonce and 
> password of the intended server.
> 
> billing systems are usually needed to be centralised (esp. in 
> those next gen telcos where the servers are operated by 
> franchises). this is a commercial requirement of SIP operations.
> 
> the 2543.bis does not explicitly talk of the redirect/proxies 
> authenticating requests for the gateways.

I'm uncertain if there is a question here somewhere. Perhaps you are asking
whether the spec should say something about proxies authenticating users on
the behalf of gateways? THis is a network design issue, outside the scope of
a specification.


> 
> the second issue:
> the call minutes are the accepted billing mechanism for 
> atleast the next couple of years. to support billing, 
> accurate times of call start and end are important.
> the call times maybe at variance between the client and the 
> server due to a the RTT nature of messaging itself. In that 
> case, it will be advisable, from a caller perspective to know 
> when exactly did the call get disconnected (a second's delay 
> can roll the call over to the next minute) and how long did 
> the call last - as per server's record. Although MESSAGE can 
> be used for this, i would rather believe that a more 
> intrinsic method must be available to support this that can 
> update the caller's own 'call meter'.

Many billing systems today allow users to go to a web page to see how long
the call lasted. I see no reason to include such information in SIP
messages.

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

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 02:13:40 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00453
	for ; Mon, 11 Jun 2001 02:13:40 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1AD7744355; Mon, 11 Jun 2001 02:14:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id C5B4544338
	for ; Mon, 11 Jun 2001 02:13:14 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA03119;
	Mon, 11 Jun 2001 02:17:13 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 11 Jun 2001 02:13:13 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Mary Barnes'" , sip@lists.bell-labs.com
Subject: RE: [SIP] Comments/nits on End-to-End encryption (section 18.1.1)
	/bis-03
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 02:13:07 -0400



  
-----Original Message-----
From: Mary Barnes [mailto:mbarnes@nortelnetworks.com]
Sent: Friday, June 01, 2001 3:08 PM
To: sip@lists.bell-labs.com
Subject: [SIP] Comments/nits on End-to-End encryption (section
18.1.1)/bis-03


>Hi all, 
>Just a couple of minor comments on section 18.1.1 
>-  In the bis-03 draft, it's specified the "Changes made in Version 03"
section 
>I that PGP has been removed (last bullet item).  However, example messages
on 
>pages 124 and 125 (of the .txt version) indicate an Encryption header of
"PGP 
>version=5.0$". 

I kept these on purpose. The spec right now is in an odd intermediate state
regarding encryption. It defines a general framework, but has no concrete
mechanisms that use the framework. Since I haven't removed the framework,
the examples section needs to mention some "theoretical" approach, and so I
figured we may as well stick with PGP, which is effectively the same as
"foo" here.


>- (Even more minor), in section 18.1.1, the last sentence in the first 
>paragraph specifies "three complementary forms of encryption", but only 2
are 
>listed.  I'm assuming this is another remnant of the PGP removal. 

Yup, fixed.

Thanks,
Jonathan R.

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

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 02:18:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00831
	for ; Mon, 11 Jun 2001 02:18:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6E2B64438F; Mon, 11 Jun 2001 02:19:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 48D054438B
	for ; Mon, 11 Jun 2001 02:18:08 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA03170;
	Mon, 11 Jun 2001 02:22:03 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 11 Jun 2001 02:18:02 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Billy Biggs'" ,
        Alan Johnston 
Cc: Dvir Oren , SIP List 
Subject: RE: [SIP] Replaces leg matching (was Re: [Sip-implementors] repla
	ces)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 02:18:01 -0400



 

> -----Original Message-----
> From: Billy Biggs [mailto:billy@billybiggs.com]
> Sent: Saturday, June 09, 2001 12:48 AM
> To: Alan Johnston
> Cc: Dvir Oren; SIP Implementors; SIP List
> Subject: [SIP] Replaces leg matching (was Re: [Sip-implementors]
> replaces)
> 
> 
>   Alan,
> 
>   I'm posting this to the SIP WG list as well to solicit more 
> opinions.
> 
> > I know others have been thinking about whether we need the 
> full To and
> > From URLs (or a MD5 hash of them) in the Replaces header.  I'm not
> > convinced myself, but there is one possible scenario that 
> could cause
> > trouble.  A RFC2543 UAC which is redirected directly to another
> > RFC2543 UAS (no proxies in between) could result in a call 
> without any
> > tags (To tags are not mandatory in RFC2543 unless there are 
> more than
> > one Via headers, ie a proxy in the path).  Now, we are down 
> to relying
> > only on the uniqueness of the Call-ID.  Of course, any bis 
> UA will use
> > From and To tags.
> 
>   Since the Call-ID is unique, I don't see a matching problem.  We can
> also recommend that any UA which supports Replaces must also support
> bis (at least use tags).

Another practical issue worth considering is that many implementations in
gateways store call leg objects indexed by the hash of the call leg ID.
There is no direct index of calls based on call-id, since its really not
needed. Therefore, it becomes a practical problem to find the matching call
leg with just the call-id.

-Jonathan R.


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

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 02:22:21 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01082
	for ; Mon, 11 Jun 2001 02:22:21 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AF43744398; Mon, 11 Jun 2001 02:21:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 4CB4344395
	for ; Mon, 11 Jun 2001 02:20:11 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA03192;
	Mon, 11 Jun 2001 02:23:54 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 11 Jun 2001 02:19:53 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'???'" , sip@lists.bell-labs.com
Subject: RE: [SIP] callerprefs-03.txt  mistype
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 02:19:48 -0400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA01082

No, table 5 is correct.

-Jonathan R.

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

> -----Original Message-----
> From: softgear@dcn.ssu.ac.kr [mailto:softgear@dcn.ssu.ac.kr]
> Sent: Thursday, June 07, 2001 3:17 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] callerprefs-03.txt mistype
> 
> 
> Hello.
> I found a misprint in 'draft-ietf-sip-callerprefs-03.txt' but 
> it is minor.
> 
> At Page 5. Section 5. Table 5 specifies an extension of Table 
> 5 in RFC 2543....
> First 'Table 5' is a misprint, I think.
> 
> ........softgearN¬–+-ŠÇè­?'?)?xz÷¥¢™žž??? ?¢Ú¢T?È©Šjezg§¶Šì?+-ŠËaz™Z
> q?v+ºË"š™^™é?ب©Ý¶ŠÞqè¯y§o‰Ç¨žéÝz?-jwb?±Š??
> "?:,¹»?&Þ¶ˆ­±é??¶‹"?)©•?žÚ+²·ª¹?-r?(–雉§?­†?±Ê?è§?
> 

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 06:01:40 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05508
	for ; Mon, 11 Jun 2001 06:01:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A2F6944338; Mon, 11 Jun 2001 06:02:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mctbdc.mctchn (unknown [202.9.161.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 1ED9F44337
	for ; Mon, 11 Jun 2001 06:01:08 -0400 (EDT)
Received: by MCTBDC with Internet Mail Service (5.5.2653.19)
	id ; Mon, 11 Jun 2001 15:33:30 +0530
Message-ID: 
From: Deepika Giri 
To: jdrosen@dynamicsoft.com
Cc: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Re-invites in a multi-party call
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 15:33:29 +0530

Hi,

I am trying to implement a multi-party conference control application in SIP
using 3pcc.
My problem is this:

Usr A is currently in a conference call with User B and C, now it wishes to
put the current conference call on hold, by sending a re-INVITE, but what
will be the sip request url for this re-invite, does it send hold messages
to B and C individually?  If it has to do this, it has to maintain the users
currently in the conference call, but does a standard SIP-phone maintain
this information?   The number of users in a conference is not always known
to each client in a conference, there has to be a mechanism by which the
users get a fresh list of participants every time one leaves the call or
joins in. Can someone explains how such a feature would be implemented in a
SIP phone?


I need to know how a sip phone behaves in this scenario, b'cos my 3rd party
application has to handle this "hold " invocation by any of the users in a
call.

Can you please clarify?

Thanks
Deepika

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 08:46:40 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08702
	for ; Mon, 11 Jun 2001 08:46:40 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0FEA24434F; Mon, 11 Jun 2001 08:47:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id 5397D4434B
	for ; Mon, 11 Jun 2001 08:46:04 -0400 (EDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5BCk2N07377;
	Mon, 11 Jun 2001 14:46:02 +0200 (MEST)
Received: from lmf.ericsson.se (racom107016.am.ericsson.se [147.117.107.16])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id OAA10080;
	Mon, 11 Jun 2001 14:46:26 +0200 (MET DST)
Message-ID: <3B24BF1F.2EC6C9EA@lmf.ericsson.se>
From: Gonzalo Camarillo 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: sip , Jon Peterson ,
        adam.roach@ericsson.com
Subject: Re: [SIP] SUS/RES encapsulation
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 15:52:47 +0300
Content-Transfer-Encoding: 7bit

Hello,

Jonathan Rosenberg wrote:
> I may be mistaken, but I thought
> that SUS really was an end-to-end hold of media, and therefore, should be
> mapped to the equivalent function in SIP - a re-INVITE with 0.0.0.0 SDP.

SUS is used when an ISDN subscriber unplugs his phone from the socket
and plugs it in another socket in the middle of the call. When the call
is SUSpended, the local exchange of the user unplugging the phone cuts
the media, but the rest of the switches do not do anything.

SUS is also sent by the an analog callee when he hangs up, but for our
purposes it does not matter which one of the scenarios we are dealing
with.


I agree with you that SDP 0.0.0.0 is the proper way to go, and that's
why it was included in the draft in the first place. However, I have
been receiving comments about this proposing a differeent mapping.
That's why I wanted to get the opinion of the mailing list. My personal
opinion was written in the draft already.

The proposal that I have received is that, since in the PSTN all the
switches but the local exchange do not do anything, the SUS message can
be mapped to an INFO message, since it does not affect the state of the
session.

Opinions?

Best regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 09:09:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09469
	for ; Mon, 11 Jun 2001 09:09:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6418A44371; Mon, 11 Jun 2001 09:10:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by lists.bell-labs.com (Postfix) with ESMTP id EC3C54436C
	for ; Mon, 11 Jun 2001 09:09:40 -0400 (EDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5BD8HX00681;
	Mon, 11 Jun 2001 09:08:17 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-145.cisco.com [161.44.241.145])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAR01305 (AUTH pkyzivat);
	Mon, 11 Jun 2001 09:09:40 -0400 (EDT)
Message-ID: <3B24C236.16703DAD@cisco.com>
From: Paul Kyzivat 
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
Cc: "'Michael Thomas'" , John.Hearty@Level3.com,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Killing hung media streams
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 09:05:58 -0400
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:
>
> A more interesting question is this: what is the right behavior for a UA
> that starts to get ICMP port unreachable errors on the RTP stream? I have
> encountered two very different scenarios for this. In one case, the right
> behavior is to consider the call terminated. Another, more interesting case,
> is to immediately send a re-INVITE in order to re-establish the call at a
> backup of the remote peer. This turns out to be very useful for high
> availability conferencing and media systems. Thus, there may be a need for
> some kind of flag somewhere to indicate which behavior a UA desires when its
> peer starts to receive ICMP errors from it.

The relevant cases certainly extend beyond this specific error.
For one, this particular error is only relevant for media over RTP.

There is need for a way to do a reinvite that says in effect:
I'm ok but you are not - please offer me some alternate resources to
use.

The errors that would lead to this are probably all media specific.
In the case of calls involving multiple media, expressing the problem
clearly gets into the area of overlap between SIP and SDP - which media
stream is having difficulty.

> I'm working on an I-D on this topic. Stay tuned...

ok.

	Paul Kyzivat
	Cisco Systems

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 09:45:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10527
	for ; Mon, 11 Jun 2001 09:45:38 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6C9FD4434F; Mon, 11 Jun 2001 09:46:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb24.rediffmail.com (unknown [203.199.83.148])
	by lists.bell-labs.com (Postfix) with SMTP id F120744338
	for ; Mon, 11 Jun 2001 09:45:28 -0400 (EDT)
Received: (qmail 16847 invoked by uid 510); 11 Jun 2001 13:50:05 -0000
Message-ID: <20010611135005.16846.qmail@mailweb24.rediffmail.com>
Received: from unknown (203.197.251.9) by rediffmail.com via HTTP; 11 Jun 2001 13:50:05 -0000
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" 
Subject:  RE: [SIP] Authentication and billing through proxy/re-direct server
From: "Ashhar Farhan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 11 Jun 2001 13:50:05 -0000
Content-Transfer-Encoding: 7bit


>I'm uncertain if there is a question here somewhere. >Perhaps you are asking whether the spec should say
>something about proxies authenticating users on
>the behalf of gateways? 
>THis is a network design issue, outside the scope of
a specification.

it is not clear that this is issue entirely within the network design. if a proxy authenticates an INVITE from a caller to a gateway, the following arise:
1. the caller does not have the password for the gateway.
2. the gateway does not have the password for the caller.
3. the caller sends the INVITE to the proxy, the proxy issues a challenge.
4. the caller resends the INVITE with an incremented C Seq and this time includes a response to generated over the INVITE message using the caller's own userid, password, nonce and the INVITE message.
5. the proxy checks that INVITE contains correct respones to its previous challenge and the proxy has to forward the INVITE to the gateway.
6. the INVITE to the gateway will be challenged and responded to by the proxy using gateway's own userid, password and message content.

This behaviour is only possible in the proxy mode and it is not possible in redirect mode where the INVITE travels directly to the gateway server. That is because, the client will not be able to generate the correct response to the gateway's challenge. It can be accomodated if there is a mechanism to return a authentication response to the client from the redirect server such that this authentication response is forwarded to the gateway server.


>Many billing systems today allow users to go to a web page to see how longthe call lasted. 
> I see no reason to include such information in SIP
messages.

while the billing accounting system will take care of many more things, it is important that the client and the server, both agree about the call duration. if the client issues a BYE but the gateway can, inspite of having dropped the call, mis-report the call time and overcharge the caller. 

this can be ascertained if BYE and ACK are both routed through the proxy to record the definite start and end times of a call. 

in a sense, i am suggesting that proxy behaviour maybe the only possible architecture for commericial deployments.

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





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


From sip-admin@lists.bell-labs.com  Mon Jun 11 10:24:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11328
	for ; Mon, 11 Jun 2001 10:24:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 30EB14434B; Mon, 11 Jun 2001 10:25:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id 6C40644338
	for ; Mon, 11 Jun 2001 10:24:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23033
	for ; Mon, 11 Jun 2001 10:24:41 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08402
	for ; Mon, 11 Jun 2001 10:24:40 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 11 Jun 2001 10:24:41 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF04465539@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'sip@lists.bell-labs.com'" 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F282.3F205E10"
Subject: [SIP] Please discontinue use of this list
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 10:24:38 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F282.3F205E10
Content-Type: text/plain;
	charset="iso-8859-1"

Please do NOT send any more messages to sip@lists.bell-labs.com
 .
This list is being split and moved to two lists maintained at ietf.org.
 
If you have contributions on extensions to the core sip protocol, please
direct them to   sip@ietf.org
 
If you have contributions on the uses of sip, including interwork issues,
please
direct them to   sipping@ietf.org
 
If you have not subscribed to one or both of these lists:
    send a message to sip-request@ietf.org  ,
specify "subscribe" as the BODY
    of your message
 
and/or
    send a message to sipping-request@ietf.org
 , specify "subscribe" as the BODY
    of your message
 
Please remember that both of these new lists are for discussions of new
developments in sip and it's use only.  Questions and discussions on current
sip
are held on sip-implementors@cs.columbia.edu
 .
 
PLEASE do NOT send any message to more than one list.
 
Thanks
Brian

------_=_NextPart_001_01C0F282.3F205E10
Content-Type: text/html;
	charset="iso-8859-1"









Please do NOT send any more 
messages to sip@lists.bell-labs.com.


This list is being split 
and moved to two lists maintained at ietf.org.


 






If you have contributions 
on extensions to the core sip 
protocol, please


direct them to sip@ietf.org


 
If you have contributions 
on the uses of sip, including interwork issues, please


direct them to sipping@ietf.org


 


If you have not subscribed to one or both of these 
lists:


    send a message to sip-request@ietf.org, specify "subscribe" 
as the BODY


    of your message


 


and/or




    send a message to sipping-request@ietf.org, specify 
"subscribe" as the BODY


    of your message


 


Please 
remember that both of these new lists are for discussions of 
new


developments 
in sip and it's use only.  Questions and discussions on current 
sip



 


PLEASE do NOT 
send any message to more than one list.


 


Thanks


Brian


------_=_NextPart_001_01C0F282.3F205E10--

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


From sip-admin@ietf.org  Mon Jun 11 10:26:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11443;
	Mon, 11 Jun 2001 10:26:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20853;
	Mon, 11 Jun 2001 10:12:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20822
	for ; Mon, 11 Jun 2001 10:12:07 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11140
	for ; Mon, 11 Jun 2001 10:11:38 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21333
	for ; Mon, 11 Jun 2001 10:11:36 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03944
	for ; Mon, 11 Jun 2001 10:11:35 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 11 Jun 2001 10:11:35 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF04465537@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'sip@ietf.org'" 
Date: Mon, 11 Jun 2001 10:11:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F280.6791D4C0"
Subject: [Sip] Please start using SIP
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F280.6791D4C0
Content-Type: text/plain;
	charset="iso-8859-1"

It is now time to start using the sip@ietf.org   list. 
If you have contributions on extensions to core sip, direct them to
sip@ietf.org  
 
If you have contributions on the uses of sip, including interwork issues,
please
direct them to sipping@ietf.org  
 
If you have questions on current sip, please continue to direct them to
sip-implementors@cs.columbia.edu   
 
This will result in discontinuing the use of sip@lists.bel-labs.com
 , and splitting
discussion of core sip and other sip issues between sip@ietf.org
  and
sipping@ietf.org  
 
The is NO reason to direct any response to more than one of these lists!!!
If someone does that, would responders please edit the response to the
appropriate list.
 
We recommend that you stay subscribed to sip@lists.bell-labs.com
  for another
week or so, as it will take a while for everyone to catch on.
 
Thanks
 
Brian

------_=_NextPart_001_01C0F280.6791D4C0
Content-Type: text/html;
	charset="iso-8859-1"









It is now time to start 
using the sip@ietf.org list. 



If you 
have contributions on extensions to core sip, direct them to sip@ietf.org


 


If you have contributions 
on the uses of sip, including interwork issues, please


direct them to sipping@ietf.org


 


If you have questions on 
current sip, please continue to direct them to



 


This will result in 
discontinuing the use of sip@lists.bel-labs.com, and 
splitting


discussion of core sip and 
other sip issues between sip@ietf.org 
and



 


The is NO reason to direct 
any response to more than one of these lists!!!


If someone does that, would 
responders please edit the response to the


appropriate 
list.


 


We recommend that you stay 
subscribed to sip@lists.bell-labs.com for 
another


week or so, as it will take 
a while for everyone to catch on.


 


Thanks


 


Brian


------_=_NextPart_001_01C0F280.6791D4C0--

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jun 11 10:36:38 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11825
	for ; Mon, 11 Jun 2001 10:36:38 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2847244379; Mon, 11 Jun 2001 10:37:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lists.bell-labs.com (Postfix) with ESMTP id C486A44338
	for ; Mon, 11 Jun 2001 10:36:14 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5BEaIU27716;
	Mon, 11 Jun 2001 07:36:19 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AHV28999;
	Mon, 11 Jun 2001 07:36:09 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA11469; Mon, 11 Jun 2001 07:36:09 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15140.55129.363391.244967@thomasm-u1.cisco.com>
To: Jonathan Rosenberg 
Cc: "'Michael Thomas'" , John.Hearty@Level3.com,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Killing hung media streams
In-Reply-To: 
References: 
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 07:36:09 -0700 (PDT)
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg writes:
 > A more interesting question is this: what is the right behavior for a UA
 > that starts to get ICMP port unreachable errors on the RTP stream? I have
 > encountered two very different scenarios for this. In one case, the right
 > behavior is to consider the call terminated. Another, more interesting case,
 > is to immediately send a re-INVITE in order to re-establish the call at a
 > backup of the remote peer. This turns out to be very useful for high
 > availability conferencing and media systems. Thus, there may be a need for
 > some kind of flag somewhere to indicate which behavior a UA desires when its
 > peer starts to receive ICMP errors from it. I'm working on an I-D on this
 > topic. Stay tuned...

   This sounds quite sensible, but I don't understand why there
   needs to be signaling involved. Isn't this just a local decision?
   Why would those preferences need to be signaled?

	     Mike

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 15:15:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17171
	for ; Mon, 11 Jun 2001 15:15:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F008F44342; Mon, 11 Jun 2001 15:16:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.inetmail.att.net (mailhost1.inetmail.att.net [204.127.132.33])
	by lists.bell-labs.com (Postfix) with ESMTP id 9DCD64433C
	for ; Mon, 11 Jun 2001 15:15:44 -0400 (EDT)
Received: from ranjit ([12.41.17.196])
          by mail.inetmail.att.net (mtiagic01) with SMTP
          id <20010611191544gi128280rke>; Mon, 11 Jun 2001 19:15:44 +0000
Message-ID: <00dd01c0f2a8$b7f3a740$c411290c@masconit.com>
Reply-To: "Ranjit Avasarala" 
From: "Ranjit Avasarala" 
To: "Deepika Giri" 
Cc: 
References: 
Subject: Re: [SIP] Re-invites in a multi-party call
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 14:00:01 -0500
Content-Transfer-Encoding: 7bit

Hi  Deepika,

      to put usr B on HOLD usr A sends a Re INVITE (HOLD) message with a
session description containing a null (0.0.0.0) address.
when used with SDP the 'c' address field of media types is set to 0.


Regards
Ranjit
Mascon Communication Technologies
http://www.masconit.com



----- Original Message -----
From: Deepika Giri 
To: 
Cc: 
Sent: Monday, June 11, 2001 5:03 AM
Subject: [SIP] Re-invites in a multi-party call


Hi,

I am trying to implement a multi-party conference control application in SIP
using 3pcc.
My problem is this:

Usr A is currently in a conference call with User B and C, now it wishes to
put the current conference call on hold, by sending a re-INVITE, but what
will be the sip request url for this re-invite, does it send hold messages
to B and C individually?  If it has to do this, it has to maintain the users
currently in the conference call, but does a standard SIP-phone maintain
this information?   The number of users in a conference is not always known
to each client in a conference, there has to be a mechanism by which the
users get a fresh list of participants every time one leaves the call or
joins in. Can someone explains how such a feature would be implemented in a
SIP phone?

I need to know how a sip phone behaves in this scenario, b'cos my 3rd party
application has to handle this "hold " invocation by any of the users in a
call.

Can you please clarify?

Thanks
Deepika

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


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


From sip-admin@ietf.org  Mon Jun 11 15:21:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17302;
	Mon, 11 Jun 2001 15:21:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05758;
	Mon, 11 Jun 2001 15:13:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05728
	for ; Mon, 11 Jun 2001 15:13:02 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17072
	for ; Mon, 11 Jun 2001 15:12:34 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5BJCc907067
	for ; Mon, 11 Jun 2001 12:12:38 -0700 (PDT)
Received: from fluffyw2k (dhcp-128-107-142-120.cisco.com [128.107.142.120])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id AAJ18842;
	Mon, 11 Jun 2001 12:12:33 -0700 (PDT)
From: "Cullen Jennings" 
To: 
Date: Mon, 11 Jun 2001 12:15:02 -0700
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [Sip] Few tiny issues with SDP section of bis3
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Examples in section B don't have an e or P line in the SDP even though one
them must be present.

When adding a media steam it must be below existing media streams but the
example in (3rd SDP in section B.5 - top of page 122) seems to have it at
the top.

Would be nice to have an example that sent video and audio to a different
IPs to illustrate this case.

A clear example of the SDP for a call that was doing some voice codec, say
G.711, and was also doing RFC 2833 events would be nice.


Cullen








_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jun 11 16:57:38 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18885
	for ; Mon, 11 Jun 2001 16:57:38 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A7BA444342; Mon, 11 Jun 2001 16:58:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7])
	by lists.bell-labs.com (Postfix) with ESMTP id B6AEC4433C
	for ; Mon, 11 Jun 2001 16:57:47 -0400 (EDT)
Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id UAA23863;
	Mon, 11 Jun 2001 20:57:38 GMT
From: Jon.Peterson@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id UAA00980;
	Mon, 11 Jun 2001 20:57:31 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 11 Jun 2001 14:57:33 -0600
Message-ID: <6384220893BCD411BDFE0008C791B79CA3E621@N0228IDC1.oss.level3.com>
To: Gonzalo.Camarillo@lmf.ericsson.se, jdrosen@dynamicsoft.com
Cc: sip@lists.bell-labs.com, adam.roach@ericsson.com, sipping@ietf.org
Subject: RE: [SIP] SUS/RES encapsulation
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 14:57:23 -0600

I think this case is interesting in so far as the originating PSTN gateway
(which has received the SUS and which will subsequently send a re-INVITE or
INFO) is making a decision about how the terminating SIP endpoint should
react to the suspension of the PSTN leg of the call. In some networks it
might not matter if the terminating SIP endpoint continues to transmit media
to the PSTN gateway while the call is suspended. If however the terminating
SIP endpoint is using a dialup link for connectivity or has some similar
bandwidth constraint, the endpoint might want to stop transmitting media.

So, should a SIP endpoint (which could be a native SIP phone with no
understanding of ISUP) have to understand a SUS in INFO in order to know
that it should stop transmitting media, if its local policies suggest that
it should do just that? Should the PSTN gateway decide this for SIP
endpoints (perhaps it makes a difference if they are in the same
administrative domain or not)? On the converse side, is there any harm in
the PSTN gateway sending a re-INVITE on receipt of SUS? I don't see why it
would be undesirable to cease the flow of media for the duration of the
suspension of the call, especially considering that suspensions most often
lead to the termination of the call.

I am certainly wary of defining two mechanisms for this (i.e. allowing both
INFO and re-INVITE for SUS), since I'm not sure why a gateway vendor would
implement one rather than the other. Perhaps if there needs to be a
mechanism by which the gateway can handle a SUS without forcing a change in
the media characteristics of a call, it could send a re-INVITE without SDP,
or something. Personally I'd rather see one defined way of handling this
case.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
Sent: Monday, June 11, 2001 6:53 AM
To: Jonathan Rosenberg
Cc: sip; Peterson, Jon; adam.roach@ericsson.com
Subject: Re: [SIP] SUS/RES encapsulation


Hello,

Jonathan Rosenberg wrote:
> I may be mistaken, but I thought
> that SUS really was an end-to-end hold of media, and therefore, should be
> mapped to the equivalent function in SIP - a re-INVITE with 0.0.0.0 SDP.

SUS is used when an ISDN subscriber unplugs his phone from the socket
and plugs it in another socket in the middle of the call. When the call
is SUSpended, the local exchange of the user unplugging the phone cuts
the media, but the rest of the switches do not do anything.

SUS is also sent by the an analog callee when he hangs up, but for our
purposes it does not matter which one of the scenarios we are dealing
with.


I agree with you that SDP 0.0.0.0 is the proper way to go, and that's
why it was included in the draft in the first place. However, I have
been receiving comments about this proposing a differeent mapping.
That's why I wanted to get the opinion of the mailing list. My personal
opinion was written in the draft already.

The proposal that I have received is that, since in the PSTN all the
switches but the local exchange do not do anything, the SUS message can
be mapped to an INFO message, since it does not affect the state of the
session.

Opinions?

Best regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

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


From sip-admin@ietf.org  Mon Jun 11 17:06:45 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19053;
	Mon, 11 Jun 2001 17:06:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09782;
	Mon, 11 Jun 2001 16:59:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09748
	for ; Mon, 11 Jun 2001 16:59:31 -0400 (EDT)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18908
	for ; Mon, 11 Jun 2001 16:59:02 -0400 (EDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP id EEAC04DA44
	for ; Mon, 11 Jun 2001 16:59:32 -0400 (EDT)
Received: from fish.research.att.com (fish.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA20960
	for ; Mon, 11 Jun 2001 16:59:28 -0400 (EDT)
From: William Marshall 
Received: (from wtm@localhost)
	by fish.research.att.com (SGI-8.9.3/8.8.5) id QAA45232
	for sip@ietf.org; Mon, 11 Jun 2001 16:57:01 -0400 (EDT)
Date: Mon, 11 Jun 2001 16:57:01 -0400 (EDT)
Message-Id: <200106112057.QAA45232@fish.research.att.com>
To: sip@ietf.org
Subject: Re: [SIP] SIP Also header
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

While draft-dcsgroup-sip-state-00 did mention the Also header, it
has long ago expired.  The latest version, draft-ietf-sip-state-01,
does not.  This is consistent with the removal of the Also header
from other drafts.

Bill Marshall
wtm@research.att.com

-----original message-----
From: "Ranjit Avasarala" 
To: "Wai Wu" , 
Subject: Re: [SIP] SIP Also header
Date: Fri, 8 Jun 2001 12:59:55 -0500

SIP Also headerthere is some info on Also header in
draft-dcsgroup-sip-state-00.txt

Regards
Ranjit
Mascon Communication Technologies
http://www.masconit.com

  ----- Original Message -----
  From: Wai Wu
  To: 'sip@lists.bell-labs.com'
  Sent: Friday, June 08, 2001 12:31 PM
  Subject: [SIP] SIP Also header


  Hi All,
          Does any one has info for the Also header. I cannot find it in
RFC2543. I have been working with Cisco phones and see this header on Bye
messages when doing a call transfer.

  Regards
  Wai Wu


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Mon Jun 11 18:14:35 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19998;
	Mon, 11 Jun 2001 18:14:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12328;
	Mon, 11 Jun 2001 18:01:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12294
	for ; Mon, 11 Jun 2001 18:01:00 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19786
	for ; Mon, 11 Jun 2001 18:00:30 -0400 (EDT)
From: adam.roach@ericsson.com
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f5BM10a27882;
	Mon, 11 Jun 2001 17:01:00 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f5BM0xA27935;
	Mon, 11 Jun 2001 17:00:59 -0500 (CDT)
Received: from pc050163 (pc050178.exu.ericsson.se [138.85.50.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id RAA09345; Mon, 11 Jun 2001 17:00:59 -0500 (CDT)
Reply-To: 
To: "'Boaventura, Alberto Magno Silveira (Alberto)'" ,
        
Subject: RE: [SIP] (no subject)
Date: Mon, 11 Jun 2001 17:00:57 -0500
Message-ID: <61D824C63B99D311975E00508B0CC98502251828@eamrcnt717.exu.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <0F103142B6F6D311A80E0008C71BAC295D2B83@BZ3002EXCH001U>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

(Sorry if I missed responses to this message; I was away for a
while, and missed about a week of SIP WG mail due to the
switch-over of mailing lists)

At the interrum meeting in Plano (between IETFs 49 and 50), we
decided that this type of shortcut handling for something that
can be accomplished just fine with REFER wasn't worth the extra
standardization effort. This decision was largely based on the
long-running principle of generality over efficiency which we
have pursued for SIP.

In short: this effort has been discontinued.

/a

> -----Original Message-----
> From: Boaventura, Alberto Magno Silveira (Alberto)
> [mailto:aboaventura@lucent.com]
> Sent: Thursday, June 07, 2001 5:28 PM
> To: sip@share.research.bell-labs.com
> Subject: [SIP] (no subject)
> 
> 
> To: 
> Subject: Handoff primitive
> Date: Thu, 7 Jun 2001 19:17:21 -0300 
> Return-Receipt-To: "Boaventura, Alberto Magno Silveira 
> (Alberto)" 
> MIME-Version: 1.0
> X-Mailer: Internet Mail Service (5.5.2650.21)
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> Sender: owner-sip@lists.bell-labs.com
> 
> Greetings All,
> 
> What is current status of draft-dean-handoff-00.txt applied 
> in January 19,
> 2001?
> 
> Thanks for any return,
> Alberto.
> 
> 
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> 


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jun 11 20:21:47 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21194
	for ; Mon, 11 Jun 2001 20:21:47 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F202D4433D; Mon, 11 Jun 2001 20:22:13 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by lists.bell-labs.com (Postfix) with SMTP id 0F39D44336
	for ; Mon, 11 Jun 2001 20:21:35 -0400 (EDT)
Received: from 157.54.1.52 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Jun 2001 17:19:09 -0700 (Pacific Daylight Time)
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Mon, 11 Jun 2001 17:21:18 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Mon, 11 Jun 2001 17:21:14 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 11 Jun 2001 17:19:59 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F2D5.6A1162C4"
Message-ID: <2E33960095B58E40A4D3345AB9F65EC1463688@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Registrar cancelation of registers
Thread-Index: AcDy1ZbkvH//lngmQm2GE2VhEKCz4Q==
From: "David Simons" 
To: 
Cc: "David Simons" ,
        "Robert Brown" 
X-OriginalArrivalTime: 12 Jun 2001 00:19:59.0088 (UTC) FILETIME=[6A3F8F00:01C0F2D5]
Subject: [SIP] Registrar cancelation of registers
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 17:19:58 -0700

This is a multi-part message in MIME format.

------_=_NextPart_001_01C0F2D5.6A1162C4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

One of the limitation I see in SIP is that a registrar has no way of
indicating to a UAC that it's registration is no longer valid.  There
doesn't seem to be a mechanism to cancel registrations.  I can think of
two scenarios were this could be very useful.  First, a registrar needs
to shutdown but it has recently accepted one hour registrations.  It
would be nice if the registrar could indicate to the UAC that its
registration is no longer valid and should re-register after a while.
In the second scenario a service wants to minimize the amount of
resources that a users consumes on the Registrar.  This could be done by
deigning new registration but the new registrations are the ones most
likely to be called successfully.  Or you could say you want to remove
registration for the lowest q-values.  I'd be interesting in the
thoughts of others on this group.

One solution I've considered is to send a CANCEL with the same FROM, TO,
and Call-ID as the REGISTER to the UAC, In effect canceling the
registration.  This doesn't seem to conform to RFC2543bis03.  This
solution would be canceling a request that had a final reply.   Also the
CANCEL wouldn't be sent by the requester.  Then there is the use of BYE
that could be an option but BYE only seems to address INVITE.

Comments?

Regards,=20

David J. Simons
Development Lead
Microsoft Windows RTC



------_=_NextPart_001_01C0F2D5.6A1162C4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






Registrar cancelation of registers





One =
of the limitation I see in SIP is that a registrar has no way of =
indicating to a UAC that it’s registration is no longer =
valid.  There =
doesn’t seem to be a mechanism to cancel registrations.  I =
can think of two scenarios were this could be very =
useful.  First, a registrar needs to shutdown but it has recently accepted one hour registrations.  It would be nice if the registrar =
could =
indicate to the UAC that its =
registration is no longer valid and should re-register after a =
while.  In the second scenario a service wants to minimize the amount =
of resources that a users consumes on the Registrar.  This could =
be done by deigning new registration =
but the new registrations =
are the ones most likely to be called successfully.  Or you could say you want to remove registration =
for the lowest q-values.  I’d be interesting in the =
thoughts of others on this group.



One =
solution I’ve considered is to send a CANCEL with =
the same FROM, TO, and Call-ID as the REGISTER to the UAC, In =
effect =
canceling the registration.  This doesn’t seem to conform to =
RFC2543bis03.  This solution would be canceling a request that had a final =
reply. =
  Also the CANCEL =
wouldn’t be sent by the requester.  Then there is the use =
of BYE that could be an option but BYE only seems to address =
INVITE.



Comments?



Regards, 



David J. =
Simons



Development Lead



Microsoft Windows RTC







------_=_NextPart_001_01C0F2D5.6A1162C4--

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


From sip-admin@lists.bell-labs.com  Mon Jun 11 20:27:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21210
	for ; Mon, 11 Jun 2001 20:27:49 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D909D44385; Mon, 11 Jun 2001 20:28:14 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by lists.bell-labs.com (Postfix) with ESMTP id 49A5A44365
	for ; Mon, 11 Jun 2001 20:27:02 -0400 (EDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id RAA29788 for ; Mon, 11 Jun 2001 17:27:02 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id RAA02974 for ; Mon, 11 Jun 2001 17:27:02 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 11 Jun 2001 19:27:01 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E080@IL27EXM10.cig.mot.com>
From: Baniel Uri-CUB001 
To: "'David Simons'" , sip@lists.bell-labs.com
Cc: Robert Brown 
Subject: RE: [SIP] Registrar cancelation of registers
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 19:26:57 -0500

David
 
We have discussed the issue back a few months ago. One of the recommendations was to use the 'subscribe and notify' mechanism, when registration may serve as an implicit subscription to being notified for de-registration event. You may also want to take a look at the R5 3GPP relevant spec (23.228)
 
Uri
 

================================================================= 
Uri.Baniel@motorola.com, 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
"Only by learning do we discover how ignorant we are" E.w.c 
================================================================= 

 

-----Original Message-----
From: David Simons [mailto:dsimons@windows.microsoft.com]
Sent: Monday, June 11, 2001 7:20 PM
To: sip@lists.bell-labs.com
Cc: David Simons; Robert Brown
Subject: [SIP] Registrar cancelation of registers



One of the limitation I see in SIP is that a registrar has no way of indicating to a UAC that it's registration is no longer valid.  There doesn't seem to be a mechanism to cancel registrations.  I can think of two scenarios were this could be very useful.  First, a registrar needs to shutdown but it has recently accepted one hour registrations.  It would be nice if the registrar could indicate to the UAC that its registration is no longer valid and should re-register after a while.  In the second scenario a service wants to minimize the amount of resources that a users consumes on the Registrar.  This could be done by deigning new registration but the new registrations are the ones most likely to be called successfully.  Or you could say you want to remove registration for the lowest q-values.  I'd be interesting in the thoughts of others on this group.

One solution I've considered is to send a CANCEL with the same FROM, TO, and Call-ID as the REGISTER to the UAC, In effect canceling the registration.  This doesn't seem to conform to RFC2543bis03.  This solution would be canceling a request that had a final reply.   Also the CANCEL wouldn't be sent by the requester.  Then there is the use of BYE that could be an option but BYE only seems to address INVITE.

Comments?

Regards, 

David J. Simons

Development Lead

Microsoft Windows RTC




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


From sip-admin@lists.bell-labs.com  Mon Jun 11 20:48:40 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21392
	for ; Mon, 11 Jun 2001 20:48:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9DA2B4435C; Mon, 11 Jun 2001 20:49:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 5ED204433D
	for ; Mon, 11 Jun 2001 20:48:42 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5C0mk916585;
	Mon, 11 Jun 2001 17:48:46 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AHX03313;
	Mon, 11 Jun 2001 17:48:40 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA11555; Mon, 11 Jun 2001 17:48:40 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <15141.26343.698849.988865@thomasm-u1.cisco.com>
To: "David Simons" 
Cc: , "Robert Brown" 
Subject: [SIP] Registrar cancelation of registers
In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1463688@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
References: <2E33960095B58E40A4D3345AB9F65EC1463688@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 11 Jun 2001 17:48:39 -0700 (PDT)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id UAA21392


Funny, DNS has the exact same problem and nobody
to my knowledge is trying to back annotate changes
in status into DNS records. Either DNS servers
never go down, or I expect that similar methods of
dealing with highly available do-dads might be
appropriate for SIP registrars.

	      Mike

David Simons writes:
 > One of the limitation I see in SIP is that a registrar has no way of
 > indicating to a UAC that it's registration is no longer valid.  There
 > doesn't seem to be a mechanism to cancel registrations.  I can think of
 > two scenarios were this could be very useful.  First, a registrar needs
 > to shutdown but it has recently accepted one hour registrations.  It
 > would be nice if the registrar could indicate to the UAC that its
 > registration is no longer valid and should re-register after a while.
 > In the second scenario a service wants to minimize the amount of
 > resources that a users consumes on the Registrar.  This could be done by
 > deigning new registration but the new registrations are the ones most
 > likely to be called successfully.  Or you could say you want to remove
 > registration for the lowest q-values.  I'd be interesting in the
 > thoughts of others on this group.
 > 
 > One solution I've considered is to send a CANCEL with the same FROM, TO,
 > and Call-ID as the REGISTER to the UAC, In effect canceling the
 > registration.  This doesn't seem to conform to RFC2543bis03.  This
 > solution would be canceling a request that had a final reply.   Also the
 > CANCEL wouldn't be sent by the requester.  Then there is the use of BYE
 > that could be an option but BYE only seems to address INVITE.
 > 
 > Comments?
 > 
 > Regards, 
 > 
 > David J. Simons
 > Development Lead
 > Microsoft Windows RTC
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > Registrar cancelation of registers
 > 
 > 
 > 
 > 
 > 
One of the limitation I see in SIP is that a registrar has no way of indicating to a UAC that it’s registration is no longer valid.  There doesn’t seem to be a mechanism to cancel registrations.  I can think of two scenarios were this could be very useful.  First, a registrar needs to shutdown but it has recently accepted one hour registrations.  It would be nice if the registrar could indicate to the UAC that its registration is no longer valid and should re-register after a while.  In the second scenario a service wants to minimize the amount of resources that a users consumes on the Registrar.  This could be done by deigning new registration but the new registrations are the ones most likely to be called successfully.  Or you could say you want to remove registration for the lowest q-values.  I’d be interesting in the thoughts of others on this group.

 > 
 > 
One solution I’ve considered is to send a CANCEL with the same FROM, TO, and Call-ID as the REGISTER to the UAC, In effect canceling the registration.  This doesn’t seem to conform to RFC2543bis03.  This solution would be canceling a request that had a final reply.   Also the CANCEL wouldn’t be sent by the requester.  Then there is the use of BYE that could be an option but BYE only seems to address INVITE.

 > 
 > 
Comments?

 > 
 > 
Regards, 

 > 
 > 
David J. Simons

 > 
 > 
Development Lead

 > 
 > 
Microsoft Windows RTC

 > 
 > 

 > 
 > 
 > ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÓ†+%ŠËb±ú+r‰íŠ{¢ž^½éh¦g§¶‡í…äˆ>šè¶‡(—ôázÈ©þ)©•éžžÚ+þÉb²Ø¬¶©•§¶‡b±Ë¬²)©•éžžÖ­Š‰ÿjwm¢·œz+ÞiÛâqê'ºw^®ËZاìb²Ø§‚È©ý:,¹»®&Þ¶ˆ­þǧvf¢–Ú,ŠŸâš™^™éí¢»ÿ­ê®zËÿrÏÜ¢[¦n&ÿyÛ°ŠØÿ²æìr¸›{ø§¶›¡Üÿ


From sip-admin@lists.bell-labs.com  Tue Jun 12 01:24:40 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26453
	for ; Tue, 12 Jun 2001 01:24:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DE96544337; Tue, 12 Jun 2001 01:25:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mctbdc.mctchn (unknown [202.9.161.82])
	by lists.bell-labs.com (Postfix) with ESMTP id F3F8D44336
	for ; Tue, 12 Jun 2001 01:24:35 -0400 (EDT)
Received: by MCTBDC with Internet Mail Service (5.5.2653.19)
	id ; Tue, 12 Jun 2001 10:57:18 +0530
Message-ID: 
From: Deepika Giri 
To: sip@lists.bell-labs.com
Subject: RE: [SIP] Re-invites in a multi-party call
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 12 Jun 2001 10:57:16 +0530

That was not my question, not to put a single user on hold, I need to put
all "conference participants on hold".

Anyway, I think multi-cast should work as suggested by Iliff TIna.

Deepika

-----Original Message-----
From: Ranjit Avasarala [mailto:ranjitka@email.masconit.com]
Sent: Tuesday, June 12, 2001 3:00 AM
To: Deepika Giri
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Re-invites in a multi-party call


Hi  Deepika,

      to put usr B on HOLD usr A sends a Re INVITE (HOLD) message with a
session description containing a null (0.0.0.0) address.
when used with SDP the 'c' address field of media types is set to 0.


Regards
Ranjit
Mascon Communication Technologies
http://www.masconit.com



----- Original Message -----
From: Deepika Giri 
To: 
Cc: 
Sent: Monday, June 11, 2001 5:03 AM
Subject: [SIP] Re-invites in a multi-party call


Hi,

I am trying to implement a multi-party conference control application in SIP
using 3pcc.
My problem is this:

Usr A is currently in a conference call with User B and C, now it wishes to
put the current conference call on hold, by sending a re-INVITE, but what
will be the sip request url for this re-invite, does it send hold messages
to B and C individually?  If it has to do this, it has to maintain the users
currently in the conference call, but does a standard SIP-phone maintain
this information?   The number of users in a conference is not always known
to each client in a conference, there has to be a mechanism by which the
users get a fresh list of participants every time one leaves the call or
joins in. Can someone explains how such a feature would be implemented in a
SIP phone?

I need to know how a sip phone behaves in this scenario, b'cos my 3rd party
application has to handle this "hold " invocation by any of the users in a
call.

Can you please clarify?

Thanks
Deepika

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

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


From sip-admin@lists.bell-labs.com  Tue Jun 12 05:29:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11168
	for ; Tue, 12 Jun 2001 05:29:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6BAF744337; Tue, 12 Jun 2001 05:30:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 42F0744336
	for ; Tue, 12 Jun 2001 05:29:46 -0400 (EDT)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f5C9TkO26198
	for ; Tue, 12 Jun 2001 11:29:46 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jun 12 11:29:43 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 12 Jun 2001 11:29:43 +0200
Message-ID: <1367DA832A24D311A95C0008C791C77008AB3D09@eitrmnt100.tei.ericsson.se>
From: "Giuseppe De Marco (TEI)" 
To: "'sip@lists.bell-labs.com'" 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [SIP] (no subject)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 12 Jun 2001 11:32:22 +0200

gdemarco@unisa.it

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


From sip-admin@lists.bell-labs.com  Tue Jun 12 09:56:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15172
	for ; Tue, 12 Jun 2001 09:56:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 089A544337; Tue, 12 Jun 2001 09:57:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from gatekeeper.calltrol.com (unknown [65.105.250.35])
	by lists.bell-labs.com (Postfix) with ESMTP id 2927C44336
	for ; Tue, 12 Jun 2001 09:56:25 -0400 (EDT)
Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253])
	by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id JAA28381;
	Tue, 12 Jun 2001 09:58:10 -0400
Received: by NT-SERVER with Internet Mail Service (5.5.2448.0)
	id ; Tue, 12 Jun 2001 09:58:34 -0400
Message-ID: <60A9CA50081AD4118BD60040F60C1A9F0A3DB1@NT-SERVER>
From: Wai Wu 
To: "'Ranjit Avasarala'" ,
        Deepika Giri 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Re-invites in a multi-party call
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F347.C4930920"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 12 Jun 2001 09:58:33 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F347.C4930920
Content-Type: text/plain;
	charset="iso-8859-1"

I have been working with several so call standard SIP phones. All of them
assume that a conference bridge exists in the lan. When an UAC puts the
conference on hold, it sends a re INVITE to the conference bridge.

-----Original Message-----
From: Ranjit Avasarala [mailto:ranjitka@email.masconit.com]
Sent: Monday, June 11, 2001 3:00 PM
To: Deepika Giri
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Re-invites in a multi-party call


Hi  Deepika,

      to put usr B on HOLD usr A sends a Re INVITE (HOLD) message with a
session description containing a null (0.0.0.0) address.
when used with SDP the 'c' address field of media types is set to 0.


Regards
Ranjit
Mascon Communication Technologies
http://www.masconit.com



----- Original Message -----
From: Deepika Giri 
To: 
Cc: 
Sent: Monday, June 11, 2001 5:03 AM
Subject: [SIP] Re-invites in a multi-party call


Hi,

I am trying to implement a multi-party conference control application in SIP
using 3pcc.
My problem is this:

Usr A is currently in a conference call with User B and C, now it wishes to
put the current conference call on hold, by sending a re-INVITE, but what
will be the sip request url for this re-invite, does it send hold messages
to B and C individually?  If it has to do this, it has to maintain the users
currently in the conference call, but does a standard SIP-phone maintain
this information?   The number of users in a conference is not always known
to each client in a conference, there has to be a mechanism by which the
users get a fresh list of participants every time one leaves the call or
joins in. Can someone explains how such a feature would be implemented in a
SIP phone?

I need to know how a sip phone behaves in this scenario, b'cos my 3rd party
application has to handle this "hold " invocation by any of the users in a
call.

Can you please clarify?

Thanks
Deepika

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



------_=_NextPart_001_01C0F347.C4930920
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Re-invites in a multi-party call




I have been working with several so call standard SIP =
phones. All of them assume that a conference bridge exists in the lan. =
When an UAC puts the conference on hold, it sends a re INVITE to the =
conference bridge.



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

From: Ranjit Avasarala [mailto:ranjitka@email.mascon=
it.com]

Sent: Monday, June 11, 2001 3:00 PM

To: Deepika Giri

Cc: sip@lists.bell-labs.com

Subject: Re: [SIP] Re-invites in a multi-party =
call






Hi  Deepika,




      to put usr B on HOLD =
usr A sends a Re INVITE (HOLD) message with a

session description containing a null (0.0.0.0) =
address.

when used with SDP the 'c' address field of media =
types is set to 0.






Regards

Ranjit

Mascon Communication Technologies

http://www.masconit.com








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

From: Deepika Giri =
<deepika@mascon.co.in>

To: <jdrosen@dynamicsoft.com>

Cc: <sip@lists.bell-labs.com>

Sent: Monday, June 11, 2001 5:03 AM

Subject: [SIP] Re-invites in a multi-party =
call






Hi,




I am trying to implement a multi-party conference =
control application in SIP

using 3pcc.

My problem is this:




Usr A is currently in a conference call with User B =
and C, now it wishes to

put the current conference call on hold, by sending =
a re-INVITE, but what

will be the sip request url for this re-invite, does =
it send hold messages

to B and C individually?  If it has to do this, =
it has to maintain the users

currently in the conference call, but does a =
standard SIP-phone maintain

this information?   The number of users in =
a conference is not always known

to each client in a conference, there has to be a =
mechanism by which the

users get a fresh list of participants every time =
one leaves the call or

joins in. Can someone explains how such a feature =
would be implemented in a

SIP phone?




I need to know how a sip phone behaves in this =
scenario, b'cos my 3rd party

application has to handle this "hold " =
invocation by any of the users in a

call.




Can you please clarify?




Thanks

Deepika




_______________________________________________

This list is for continuing development of the SIP =
protocol.

The sip-implementor's list is the place to discuss =
implementation,

and to receive advice on understanding existing sip.<=
/FONT>

To subscribe to it, send mail to

sip-implementors-request@cs.columbia.edu with =
"subscribe" in the body.







------_=_NextPart_001_01C0F347.C4930920--

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


From sip-admin@lists.bell-labs.com  Tue Jun 12 09:59:38 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15284
	for ; Tue, 12 Jun 2001 09:59:38 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 383C844373; Tue, 12 Jun 2001 10:00:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from zrc2s03g.nortelnetworks.com (unknown [47.103.122.66])
	by lists.bell-labs.com (Postfix) with ESMTP id 6AAB844336
	for ; Tue, 12 Jun 2001 09:59:10 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.nortelnetworks.com (8.9.3+Sun/8.9.1) with ESMTP id JAA13903
	for ; Tue, 12 Jun 2001 09:00:32 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Tue, 12 Jun 2001 08:53:08 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Tue, 12 Jun 2001 08:58:48 -0500
Message-ID: <9A9367D1556AD21182C40000F80930AB04411C19@crchy28b.us.nortel.com>
From: "Sriram Parameswar" 
To: "'David Simons'" ,
        "'sip@lists.bell-labs.com'" 
Cc: "'Robert Brown'" 
Subject: RE: [SIP] Registrar cancelation of registers
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0F347.C5E746F0"
X-Orig: 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 12 Jun 2001 08:58:35 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F347.C5E746F0
Content-Type: text/plain;
	charset="iso-8859-1"

David,
 
There was a long discussion thread on this very topic - when 3GPP introduced
it. In short - the 3GPP approach is to 'NOTIFY' the subscriber when there
has been a network initiated de-registration. 
 
Regards,

Sriram
 

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

-----Original Message-----
From: David Simons [mailto:dsimons@windows.microsoft.com]
Sent: Monday, June 11, 2001 7:20 PM
To: sip@lists.bell-labs.com
Cc: David Simons; Robert Brown
Subject: [SIP] Registrar cancelation of registers



One of the limitation I see in SIP is that a registrar has no way of
indicating to a UAC that it's registration is no longer valid.  There
doesn't seem to be a mechanism to cancel registrations.  I can think of two
scenarios were this could be very useful.  First, a registrar needs to
shutdown but it has recently accepted one hour registrations.  It would be
nice if the registrar could indicate to the UAC that its registration is no
longer valid and should re-register after a while.  In the second scenario a
service wants to minimize the amount of resources that a users consumes on
the Registrar.  This could be done by deigning new registration but the new
registrations are the ones most likely to be called successfully.  Or you
could say you want to remove registration for the lowest q-values.  I'd be
interesting in the thoughts of others on this group.

One solution I've considered is to send a CANCEL with the same FROM, TO, and
Call-ID as the REGISTER to the UAC, In effect canceling the registration.
This doesn't seem to conform to RFC2543bis03.  This solution would be
canceling a request that had a final reply.   Also the CANCEL wouldn't be
sent by the requester.  Then there is the use of BYE that could be an option
but BYE only seems to address INVITE.

Comments?

Regards, 

David J. Simons

Development Lead

Microsoft Windows RTC




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




Registrar cancelation of registers




David,


 


There 
was a long discussion thread on this very topic - when 3GPP introduced it. In 
short - the 3GPP approach is to 'NOTIFY' the subscriber when there has been a 
network initiated de-registration. 


 


Regards,



Sriram


 


__________________________________________ 
Sriram 
Parameswar              
Phone: 972-685-8540 
Wireless IP MultiMedia (WIPMM)   Fax: 972-685-3563 

Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com 



  
-----Original Message-----
From: David Simons 
  [mailto:dsimons@windows.microsoft.com]
Sent: Monday, June 11, 2001 
  7:20 PM
To: sip@lists.bell-labs.com
Cc: David Simons; 
  Robert Brown
Subject: [SIP] Registrar cancelation of 
  registers


  
One of the limitation I 
  see in SIP is that a registrar has no way of indicating to a UAC that 
  it’s registration is no longer valid.  There 
  doesn’t seem to be a mechanism to cancel registrations.  I 
  can think of two scenarios were this could be very useful.  
  First, a registrar needs to shutdown but it has 
  recently accepted one hour registrations.  It would be 
  nice if the registrar could indicate to the UAC that 
  its registration is no longer valid and should re-register after a 
  while.  In the second scenario a service wants to minimize the amount 
  of resources that a users consumes on the Registrar.  This could be 
  done by deigning new registration but the new registrations 
  are the ones most likely to be called successfully.  Or you could say you want to remove 
  registration for the lowest q-values.  I’d be interesting in 
  the thoughts of others on this group.

  
One solution 
  I’ve 
  considered is to send a CANCEL with the same FROM, 
  TO, and Call-ID as the REGISTER to the UAC, In effect canceling the 
  registration.  This doesn’t seem to conform 
  to RFC2543bis03.  This solution would be canceling a request that had a final reply.   Also the 
  CANCEL wouldn’t be sent by the requester.  Then 
  there is the use of BYE that could be an option but BYE only seems to address 
  INVITE.

  
Comments?

  
Regards, 
  

  
David J. Simons

  
Development Lead

  
Microsoft Windows RTC

  


------_=_NextPart_001_01C0F347.C5E746F0--

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


From sip-admin@ietf.org  Tue Jun 12 10:27:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16265;
	Tue, 12 Jun 2001 10:27:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22219;
	Tue, 12 Jun 2001 10:08:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22186
	for ; Tue, 12 Jun 2001 10:08:15 -0400 (EDT)
Received: from gatekeeper.calltrol.com (root@[65.105.250.35])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15587
	for ; Tue, 12 Jun 2001 10:07:43 -0400 (EDT)
Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253])
	by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id KAA28390
	for ; Tue, 12 Jun 2001 10:10:07 -0400
Received: by NT-SERVER with Internet Mail Service (5.5.2448.0)
	id ; Tue, 12 Jun 2001 10:10:31 -0400
Message-ID: <60A9CA50081AD4118BD60040F60C1A9F0A3DB3@NT-SERVER>
From: Wai Wu 
To: "'sip@ietf.org'" 
Date: Tue, 12 Jun 2001 10:10:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F349.70357800"
Subject: [Sip] REFER method
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F349.70357800
Content-Type: text/plain;
	charset="iso-8859-1"


Does any one have any info on the REFER method. I know it is not going to be
released until fall.

Thanks

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






REFER method






Does any one have any info on the REFER method. I know it is not going to be released until fall.




Thanks





------_=_NextPart_001_01C0F349.70357800--

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Tue Jun 12 11:14:52 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17455;
	Tue, 12 Jun 2001 11:14:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22734;
	Tue, 12 Jun 2001 10:24:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22700
	for ; Tue, 12 Jun 2001 10:24:29 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16134
	for ; Tue, 12 Jun 2001 10:23:32 -0400 (EDT)
From: adam.roach@ericsson.com
Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f5CENka13980;
	Tue, 12 Jun 2001 09:23:46 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f5CENjV26968;
	Tue, 12 Jun 2001 09:23:45 -0500 (CDT)
Received: from pc050163 (pc050178.exu.ericsson.se [138.85.50.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id JAA12680; Tue, 12 Jun 2001 09:23:45 -0500 (CDT)
Reply-To: 
To: "'David Simons'" , 
Cc: "Robert Brown" 
Subject: RE: [SIP] Registrar cancelation of registers
Date: Tue, 12 Jun 2001 09:23:42 -0500
Message-ID: <61D824C63B99D311975E00508B0CC9850225182D@eamrcnt717.exu.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1463688@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Content-Transfer-Encoding: 8bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit


If the clients don't care, this is correct -- there is no way for
registrars to indicate this information. This issue has been raised
uncountable times over the past couple of years on the list; the
group consensus is that we will not add a mandatory mechanism for
this sort of thing.

On the other hand, the presence work going on in the SIMPLE working
group *does* provide an interesting mechanism to provide the same
functionality -- assuming, that is, that the client cares.

If a client *wants* to be notified when his registration is no longer
valid, he may send a SUBSCRIBE message for his own presence to his
registrar. In this way, just like anyone else subscribed to his
presence, he will receive a NOTIFY message when his registration
disappears.

See http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-00.txt
for further details on presence and SIP.

/a

-----Original Message-----
From: David Simons [mailto:dsimons@windows.microsoft.com]
Sent: Monday, June 11, 2001 7:20 PM
To: sip@lists.bell-labs.com
Cc: David Simons; Robert Brown
Subject: [SIP] Registrar cancelation of registers


One of the limitation I see in SIP is that a registrar has no way of indicating
to a UAC that it’s registration is no longer valid.  There doesn’t seem to be a
mechanism to cancel registrations.  I can think of two scenarios were this
could be very useful.  First, a registrar needs to shutdown but it has recently
accepted one hour registrations.  It would be nice if the registrar could
indicate to the UAC that its registration is no longer valid and should
re-register after a while.  In the second scenario a service wants to minimize
the amount of resources that a users consumes on the Registrar.  This could be
done by deigning new registration but the new registrations are the ones most
likely to be called successfully.  Or you could say you want to remove
registration for the lowest q-values.  I’d be interesting in the thoughts of
others on this group.
One solution I’ve considered is to send a CANCEL with the same FROM, TO, and
Call-ID as the REGISTER to the UAC, In effect canceling the registration.  This
doesn’t seem to conform to RFC2543bis03.  This solution would be canceling a
request that had a final reply.   Also the CANCEL wouldn’t be sent by the
requester.  Then there is the use of BYE that could be an option but BYE only
seems to address INVITE.
Comments?
Regards,
David J. Simons
Development Lead
Microsoft Windows RTC


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Tue Jun 12 12:15:54 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18510;
	Tue, 12 Jun 2001 12:15:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27529;
	Tue, 12 Jun 2001 12:09:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27498
	for ; Tue, 12 Jun 2001 12:09:35 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18366
	for ; Tue, 12 Jun 2001 12:09:04 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1])
	by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5CG9WP26670
	for ; Tue, 12 Jun 2001 12:09:32 -0400 (EDT)
Received: from hvssa01.nl.lucent.com (h135-85-68-2.lucent.com [135.85.68.2])
	by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5CG9W426657
	for ; Tue, 12 Jun 2001 12:09:32 -0400 (EDT)
Received: by hvssa01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id SAA13444; Tue, 12 Jun 2001 18:09:30 +0200 (MET DST)
Received: from lucent.com by hvssa01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id SAA13438; Tue, 12 Jun 2001 18:09:29 +0200 (MET DST)
Message-ID: <3B263E14.D9E752C9@lucent.com>
Date: Tue, 12 Jun 2001 18:06:44 +0200
From: Michel de Boer 
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] bis03 ps version differs from txt version
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

By accident I noticed that there is a difference in the postscript
version and the text version of the rfc2543bis-03 draft.

The SIP-URL definition on page 20 of the postscript version says:

userinfo          = [ user|telephone-subscriber [":" password ]]
user              = *( unreserved | escaped | user-unreserved )
user-unreserved   = "&" | "=" | "+" | "$" | "," |";"|"?"|"/"

transport-param = "transport=" ( "udp" | "tcp" | "sctp" | "tls" | other-transport )

The SIP-URL definition on page 19 of the text version says:

  userinfo        = user [ ":" password ]
  user            = *( unreserved | escaped
                  | "&" | "=" | "+" | "$" | "," )

  transport-param = "transport=" ( "udp" | "tcp" )

And there are more differences in this syntax definition that I don't want 
to put here. Note that 'telephone-subscriber' is not defined. I don't know
if there are other diffs in other parts of the document.

It seems that the postscript version is the latest version. Please publish
the correct version of the documents.


Regards,
Michel

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Tue Jun 12 13:35:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20533;
	Tue, 12 Jun 2001 13:35:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00600;
	Tue, 12 Jun 2001 13:22:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00571
	for ; Tue, 12 Jun 2001 13:22:21 -0400 (EDT)
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20032
	for ; Tue, 12 Jun 2001 13:21:51 -0400 (EDT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #47837)
 with ESMTP id <0GET000LIUV2S5@firewall.mcit.com> for sip@ietf.org; Tue,
 12 Jun 2001 17:21:02 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GET00901UUK6D@pmismtp01.wcomnet.com>;
 Tue, 12 Jun 2001 17:21:02 +0000 (GMT)
Received: from wcom.com ([166.44.58.121])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GET0085GUUAFL@pmismtp01.wcomnet.com>; Tue,
 12 Jun 2001 17:20:36 +0000 (GMT)
Date: Tue, 12 Jun 2001 12:12:16 -0500
From: Alan Johnston 
Subject: Re: [SIP] Replaces leg matching (was Re: [Sip-implementors] repla	ces)
To: Jonathan Rosenberg 
Cc: "'Billy Biggs'" , Dvir Oren ,
        SIP List 
Message-id: <3B264D70.27FE91E1@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en] (Win98; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: 
 
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

(Moved to the new SIP List)

Jonathan & Billy,

See my comments below.

Alan.

Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: Billy Biggs [mailto:billy@billybiggs.com]
> > Sent: Saturday, June 09, 2001 12:48 AM
> > To: Alan Johnston
> > Cc: Dvir Oren; SIP Implementors; SIP List
> > Subject: [SIP] Replaces leg matching (was Re: [Sip-implementors]
> > replaces)
> >
> >
> >   Alan,
> >
> >   I'm posting this to the SIP WG list as well to solicit more
> > opinions.
> >
> > > I know others have been thinking about whether we need the
> > full To and
> > > From URLs (or a MD5 hash of them) in the Replaces header.  I'm not
> > > convinced myself, but there is one possible scenario that
> > could cause
> > > trouble.  A RFC2543 UAC which is redirected directly to another
> > > RFC2543 UAS (no proxies in between) could result in a call
> > without any
> > > tags (To tags are not mandatory in RFC2543 unless there are
> > more than
> > > one Via headers, ie a proxy in the path).  Now, we are down
> > to relying
> > > only on the uniqueness of the Call-ID.  Of course, any bis
> > UA will use
> > > From and To tags.
> >
> >   Since the Call-ID is unique, I don't see a matching problem.  We can
> > also recommend that any UA which supports Replaces must also support
> > bis (at least use tags).

Sounds like a reasonable solution.

>
>
> Another practical issue worth considering is that many implementations in
> gateways store call leg objects indexed by the hash of the call leg ID.
> There is no direct index of calls based on call-id, since its really not
> needed. Therefore, it becomes a practical problem to find the matching call
> leg with just the call-id.
>
> -Jonathan R.
>

This practical issue is an important one.

I was actually leaning the other way, thinking that the Call-ID would make it
easier to index than the hash of the call leg information, but perhaps you are
right - if the hash function was identical to the one already used by the
Gateway to identify calls, this would seem to make the most sense.

I'd be interested in hearing from Gateway vendors, Conference Bridge vendors,
or anyone else who implements large shared UAs on this issue.


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Tue Jun 12 15:39:49 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23217;
	Tue, 12 Jun 2001 15:39:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05808;
	Tue, 12 Jun 2001 15:33:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05777
	for ; Tue, 12 Jun 2001 15:33:13 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23106;
	Tue, 12 Jun 2001 15:32:41 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA09719;
	Tue, 12 Jun 2001 15:37:07 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 12 Jun 2001 15:33:06 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Michel de Boer'" , sip@ietf.org
Cc: "'sip-implementors@ietf.org'" 
Subject: PLEASE READ!!!!!!: RE: [Sip] bis03 ps version differs from txt ve
	rsion
Date: Tue, 12 Jun 2001 15:33:05 -0400
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Michel de Boer [mailto:michelboer@lucent.com]
> Sent: Tuesday, June 12, 2001 12:07 PM
> To: sip@ietf.org
> Subject: [Sip] bis03 ps version differs from txt version
> 
> 
> By accident I noticed that there is a difference in the postscript
> version and the text version of the rfc2543bis-03 draft.
> 
> The SIP-URL definition on page 20 of the postscript version says:
> 
> userinfo          = [ user|telephone-subscriber [":" password ]]
> user              = *( unreserved | escaped | user-unreserved )
> user-unreserved   = "&" | "=" | "+" | "$" | "," |";"|"?"|"/"
> 
> transport-param = "transport=" ( "udp" | "tcp" | "sctp" | 
> "tls" | other-transport )
> 
> The SIP-URL definition on page 19 of the text version says:
> 
>   userinfo        = user [ ":" password ]
>   user            = *( unreserved | escaped
>                   | "&" | "=" | "+" | "$" | "," )
> 
>   transport-param = "transport=" ( "udp" | "tcp" )

This is a terrible error, and I apologize. There are three files that are
different between the text and ps/pdf versions of the document, and these
three are the syntax for the URL, contact and via headers. Somehow the text
versions have reverted to an older version; I am going to look into how this
happened (I suspect the CVS repositories we use for the spec did not contain
the latest version that was in use). I have gone through and have brought
them into sync, and this will be reflected in the -04 version. I will likely
issue this shortly so that people have a consistent version asap.


> 
> And there are more differences in this syntax definition that 
> I don't want 
> to put here. Note that 'telephone-subscriber' is not defined. 

This is defined in the tel URL specification, rfc2806. This is referenced by
section 2.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Tue Jun 12 16:38:48 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24295;
	Tue, 12 Jun 2001 16:38:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08294;
	Tue, 12 Jun 2001 16:33:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08265
	for ; Tue, 12 Jun 2001 16:33:23 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24142
	for ; Tue, 12 Jun 2001 16:32:50 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA10515;
	Tue, 12 Jun 2001 16:37:14 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 12 Jun 2001 16:33:14 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'adam.roach@ericsson.com'" ,
        "'David Simons'"
	 , sip@ietf.org
Cc: Robert Brown 
Subject: RE: [SIP] Registrar cancelation of registers
Date: Tue, 12 Jun 2001 16:33:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
> Sent: Tuesday, June 12, 2001 10:24 AM
> To: 'David Simons'; sip@ietf.org
> Cc: Robert Brown
> Subject: RE: [SIP] Registrar cancelation of registers
> 
> 
> 
> If the clients don't care, this is correct -- there is no way for
> registrars to indicate this information. This issue has been raised
> uncountable times over the past couple of years on the list; the
> group consensus is that we will not add a mandatory mechanism for
> this sort of thing.
> 
> On the other hand, the presence work going on in the SIMPLE working
> group *does* provide an interesting mechanism to provide the same
> functionality -- assuming, that is, that the client cares.
> 
> If a client *wants* to be notified when his registration is no longer
> valid, he may send a SUBSCRIBE message for his own presence to his
> registrar. In this way, just like anyone else subscribed to his
> presence, he will receive a NOTIFY message when his registration
> disappears.

To add to that, there are two uses for the network deregistration. One is to
simply notify clients as an FYI, and another is to cause them to re-register
at another server in order to replicate registration state at the backup
server. The former is covered by presence, as has been noted. The latter is
best served, as Mike Thomas pointed out, by having a back end data
replication. In fact, asking clients to re-register to reconstruct state at
another server has a whole bunch of problems, all of which were discussed
previously on the list. They include:

1. it results in a flood of registrations, which can cause packet loss and
processing overloads. 

2. it won't work for clients that are users of the system, but haven't yet
registered (they won't know about the change to another registrar)

3. It results in a trasitory period where the contact list in the new server
is not up to date; that can result in failed calls during the transition.

So, the proposed approach is that the registrar is accessed via DNS SRV, and
when one fails or is shut down, clients gradually re-register with a backup.
The data is transferred to the backup using some implementation specific
means. 

SIP does allow for existing registrations to be removed by clients, by the
way. A re-REGISTER is sent, with an expires=0 for the contact that is to be
removed.

-Jonathan R.

-----Original Message-----
From: David Simons [mailto:dsimons@windows.microsoft.com]
Sent: Monday, June 11, 2001 7:20 PM
To: sip@lists.bell-labs.com
Cc: David Simons; Robert Brown
Subject: [SIP] Registrar cancelation of registers


One of the limitation I see in SIP is that a registrar has no way of
indicating
to a UAC that it's registration is no longer valid.  There doesn't seem to
be a
mechanism to cancel registrations.  I can think of two scenarios were this
could be very useful.  First, a registrar needs to shutdown but it has
recently
accepted one hour registrations.  It would be nice if the registrar could
indicate to the UAC that its registration is no longer valid and should
re-register after a while.  In the second scenario a service wants to
minimize
the amount of resources that a users consumes on the Registrar.  This could
be
done by deigning new registration but the new registrations are the ones
most
likely to be called successfully.  Or you could say you want to remove
registration for the lowest q-values.  I'd be interesting in the thoughts of
others on this group.
One solution I've considered is to send a CANCEL with the same FROM, TO, and
Call-ID as the REGISTER to the UAC, In effect canceling the registration.
This
doesn't seem to conform to RFC2543bis03.  This solution would be canceling a
request that had a final reply.   Also the CANCEL wouldn't be sent by the
requester.  Then there is the use of BYE that could be an option but BYE
only
seems to address INVITE.
Comments?
Regards,
David J. Simons
Development Lead
Microsoft Windows RTC


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jun 12 16:40:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24338
	for ; Tue, 12 Jun 2001 16:40:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6F8D444337; Tue, 12 Jun 2001 16:41:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id C6E4744336
	for ; Tue, 12 Jun 2001 16:40:12 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA10656;
	Tue, 12 Jun 2001 16:44:09 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 12 Jun 2001 16:40:08 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Deepika Giri'" ,
        Jonathan Rosenberg 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Re-invites in a multi-party call
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 12 Jun 2001 16:40:05 -0400



 

> -----Original Message-----
> From: Deepika Giri [mailto:deepika@mascon.co.in]
> Sent: Monday, June 11, 2001 6:03 AM
> To: jdrosen@dynamicsoft.com
> Cc: sip@lists.bell-labs.com
> Subject: [SIP] Re-invites in a multi-party call
> 
> 
> Hi,
> 
> I am trying to implement a multi-party conference control 
> application in SIP
> using 3pcc.
> My problem is this:
> 
> Usr A is currently in a conference call with User B and C, 
> now it wishes to
> put the current conference call on hold, by sending a 
> re-INVITE, but what
> will be the sip request url for this re-invite, does it send 
> hold messages
> to B and C individually? 

This question cannot be answered without knowing what conferencing model is
being used. Conferencing models for SIP are discussed at length in:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-conferencing-mode
ls-00.txt

In the case of a dial-in conference server, you would hold the other
participants by sending a re-INVITE to the server itself, with a 0.0.0.0
SDP.

In the case of end system mixing, described in section 2 of the above
document, you would send a hold individually to all the other participants
being mixed.

You later write:
> That was not my question, not to put a single user on hold, I 
> need to put
> all "conference participants on hold".
> 
> Anyway, I think multi-cast should work as suggested by Iliff TIna.
> 

Multicast? The phrases "multicast" and "should work" are contradictory and
usually don't belong in the same sentence. In any case, multicast won't help
you in any way for anything but multicast conferences. In the case of a
multicast conference (where the media is distributed via multicast), there
is no possibility for a hold. You would simply stop listening for media.

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

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


From sip-admin@ietf.org  Tue Jun 12 16:55:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24481;
	Tue, 12 Jun 2001 16:55:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08920;
	Tue, 12 Jun 2001 16:51:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA08895
	for ; Tue, 12 Jun 2001 16:51:05 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24426
	for ; Tue, 12 Jun 2001 16:50:33 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA10877;
	Tue, 12 Jun 2001 16:55:01 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 12 Jun 2001 16:51:01 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Cullen Jennings'" , sip@ietf.org
Subject: RE: [Sip] Few tiny issues with SDP section of bis3
Date: Tue, 12 Jun 2001 16:51:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Monday, June 11, 2001 3:15 PM
> To: sip@ietf.org
> Subject: [Sip] Few tiny issues with SDP section of bis3
> 
> 
> 
> Examples in section B don't have an e or P line in the SDP 
> even though one
> them must be present.

OK, I fixed that.

> 
> When adding a media steam it must be below existing media 
> streams but the
> example in (3rd SDP in section B.5 - top of page 122) seems 
> to have it at
> the top.

Yeah, that was a big oops. I fixed that one already.

> 
> Would be nice to have an example that sent video and audio to 
> a different
> IPs to illustrate this case.

The spec is not the place to deal with tons of examples. We could add such
things to the call flows example doc.


> 
> A clear example of the SDP for a call that was doing some 
> voice codec, say
> G.711, and was also doing RFC 2833 events would be nice.

There is such an example in the new SDP section in bis-03.

Thanks for your comments,

Jonathan R.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Tue Jun 12 17:03:01 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24588;
	Tue, 12 Jun 2001 17:03:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09167;
	Tue, 12 Jun 2001 16:56:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09139
	for ; Tue, 12 Jun 2001 16:56:13 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24492
	for ; Tue, 12 Jun 2001 16:55:41 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA10933;
	Tue, 12 Jun 2001 17:00:02 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 12 Jun 2001 16:56:01 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Michael Thomas'" ,
        Jonathan Rosenberg
	 
Cc: John.Hearty@level3.com, "'sip@ietf.org'" 
Subject: RE: [SIP] Killing hung media streams
Date: Tue, 12 Jun 2001 16:56:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

(moving the thread to the new list)

 

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Monday, June 11, 2001 10:36 AM
> To: Jonathan Rosenberg
> Cc: 'Michael Thomas'; John.Hearty@Level3.com; sip@lists.bell-labs.com
> Subject: RE: [SIP] Killing hung media streams
> 
> 
> Jonathan Rosenberg writes:
>  > A more interesting question is this: what is the right 
> behavior for a UA
>  > that starts to get ICMP port unreachable errors on the RTP 
> stream? I have
>  > encountered two very different scenarios for this. In one 
> case, the right
>  > behavior is to consider the call terminated. Another, more 
> interesting case,
>  > is to immediately send a re-INVITE in order to 
> re-establish the call at a
>  > backup of the remote peer. This turns out to be very 
> useful for high
>  > availability conferencing and media systems. Thus, there 
> may be a need for
>  > some kind of flag somewhere to indicate which behavior a 
> UA desires when its
>  > peer starts to receive ICMP errors from it. I'm working on 
> an I-D on this
>  > topic. Stay tuned...
> 
>    This sounds quite sensible, but I don't understand why there
>    needs to be signaling involved. Isn't this just a local decision?
>    Why would those preferences need to be signaled?

Lets say A and B are in a call, and B is a type of device that if it fails,
the call is over. When A detects this, through ICMP errors, it should not
bother with a re-INVITE, but rather, consider the call over. On the other
hand, if B is a type of device that, if it fails, a simple re-INVITE will
allow the call to be recovered at an alternate device (the alternate would
be figured out through downstream SRV or other routing approaches), then A
should send that re-INVITE immediately.

So, how does A know which to do?

I suppose we could mandate that a re-INVITE is always done, and then, if a
481 is generated, the call is considered terminated. That would generally
work, I think, but would often be a waste. I suppose for simplicities sake
we could just specify that, although I could have sworn I had come up with a
reason you really needed to know....

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jun 12 17:04:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24616
	for ; Tue, 12 Jun 2001 17:04:38 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1642144382; Tue, 12 Jun 2001 17:05:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id CD78944371
	for ; Tue, 12 Jun 2001 17:04:19 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA11027;
	Tue, 12 Jun 2001 17:08:18 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 12 Jun 2001 17:04:17 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Ashhar Farhan'" , sip@lists.bell-labs.com
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	er
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 12 Jun 2001 17:04:16 -0400



 

> -----Original Message-----
> From: Ashhar Farhan [mailto:afarhan@rediffmail.com]
> Sent: Monday, June 11, 2001 9:50 AM
> To: sip@lists.bell-labs.com
> Subject: RE: [SIP] Authentication and billing through proxy/re-direct
> server
> 
> 
> 
> >I'm uncertain if there is a question here somewhere. 
> >Perhaps you are asking whether the spec should say
> >something about proxies authenticating users on
> >the behalf of gateways? 
> >THis is a network design issue, outside the scope of
> a specification.
> 
> it is not clear that this is issue entirely within the 
> network design. if a proxy authenticates an INVITE from a 
> caller to a gateway, the following arise:
> 1. the caller does not have the password for the gateway.
> 2. the gateway does not have the password for the caller.
> 3. the caller sends the INVITE to the proxy, the proxy issues 
> a challenge.
> 4. the caller resends the INVITE with an incremented C Seq 
> and this time includes a response to generated over the 
> INVITE message using the caller's own userid, password, nonce 
> and the INVITE message.
> 5. the proxy checks that INVITE contains correct respones to 
> its previous challenge and the proxy has to forward the 
> INVITE to the gateway.
> 6. the INVITE to the gateway will be challenged and responded 
> to by the proxy using gateway's own userid, password and 
> message content.

The last step is where you have gone wrong. What you are interested in, I
think, is a system where the user has credentials for service at a proxy.
That proxy sits as the entry point to the domain. Once the user has
authenticated itself to the proxy, it should be able to also connect to a
gateway (or some other element), within the domain, but only if it
successfully authenticated itself to the proxy.

Doing that is easy. Its a matter of transitive trust. The user authenticates
itself to the proxy. The proxy maintaints persistent TLS connections to the
gateways or other servers within the domain. The proxy only allows
authenticated requests in, and the gateway only accepts requests over the
TLS connection with the proxy. The proxy and gateway both have policies that
only accept TLS connections from entities that authenticate themselves with
a specific name. 

In this way, you only bother with the user authentication once, and then the
rest is based on secure associations.


> 
> This behaviour is only possible in the proxy mode and it is 
> not possible in redirect mode where the INVITE travels 
> directly to the gateway server.

Well, you wouldn't use a redirect server in this network, then. Thats why I
am saying its a matter of network design.

> >Many billing systems today allow users to go to a web page 
> to see how longthe call lasted. 
> > I see no reason to include such information in SIP
> messages.
> 
> while the billing accounting system will take care of many 
> more things, it is important that the client and the server, 
> both agree about the call duration. if the client issues a 
> BYE but the gateway can, inspite of having dropped the call, 
> mis-report the call time and overcharge the caller. 

It can do that no matter what. Even if there exists a way to report call
times in SIP messages, this says nothing about what the user might get
charged for.

> 
> this can be ascertained if BYE and ACK are both routed 
> through the proxy to record the definite start and end times 
> of a call. 

Recording call start and stop times through a proxy has its challenges.
There are many fraud and failure cases where it doesn't work particularly
well. But, thats a separate issue.

> 
> in a sense, i am suggesting that proxy behaviour maybe the 
> only possible architecture for commericial deployments.

All the commercial deployments I am aware of have quite a few proxies, for
many reasons, of which billing is just one.

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

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


From sip-admin@ietf.org  Tue Jun 12 17:12:11 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24685;
	Tue, 12 Jun 2001 17:12:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09802;
	Tue, 12 Jun 2001 17:05:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09771
	for ; Tue, 12 Jun 2001 17:05:50 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24627
	for ; Tue, 12 Jun 2001 17:05:18 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA11060;
	Tue, 12 Jun 2001 17:09:43 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 12 Jun 2001 17:05:43 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Takuya Murakami'" ,
        "'sip@ietf.org'"
	 
Subject: RE: [SIP] bis03 : IPv6 address?
Date: Tue, 12 Jun 2001 17:05:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Moving to ietf list.

 

> -----Original Message-----
> From: Takuya Murakami [mailto:murakami@da.jp.nec.com]
> Sent: Monday, June 04, 2001 9:20 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] bis03 : IPv6 address?
> 
> 
> Hello all,
> 
> I have comment on -bis-03 draft.
> 
> In the section 2, the IPv6reference and IPv6address were removed. Why?
> I believe we need them.
> 
> And there is no description about this in section I.

This is my bad. It is correct in the ps and pdf. There is an inconsistency
that has been pointed out. It will be corrected in -04.

-Jonathan R.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Tue Jun 12 17:26:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24953;
	Tue, 12 Jun 2001 17:26:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAB10536;
	Tue, 12 Jun 2001 17:23:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10508
	for ; Tue, 12 Jun 2001 17:23:30 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24883
	for ; Tue, 12 Jun 2001 17:22:58 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA11367;
	Tue, 12 Jun 2001 17:27:27 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 12 Jun 2001 17:23:26 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Sudipto Mukherjee'" ,
        "'sip@ietf.org'"
	 
Subject: RE: [SIP] ReTransmission interval Question - Reliable Provisonal 
	Responses
Date: Tue, 12 Jun 2001 17:23:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org


(moved to new sip list)
 

> -----Original Message-----
> From: Sudipto Mukherjee [mailto:sudiptom@cisco.com]
> Sent: Friday, May 25, 2001 5:19 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] ReTransmission interval Question - Reliable Provisonal
> Responses
> 
> 
> Hi,
> 
> In section 7, Retransmit Interval Computation of Reliability 
> of Provisional  Responses in SIP draft ( 
> http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-03.txt),
> 
> It is described that non-100 provisionals be retransmitted with
> exponential backoff with a max retransmit interval of 32 secs. 
> There is reference to behaviour of INVITE responses as described
> in RFC2543.
> 
> While the BIS-02 draft for SIP describes that retransmit intervals
> for INVITE final responses starts at T1 (500msecs) and 
> caps at T2 (4 secs) interval.
> 
> Reliable Provisional Responses draft contradicts the
> BIS-02 requirements.
> 
> Will the Reliability of Provisional Responses draft be updated
> to match up with requirements of the BIS-02 or BIS-03 drafts ?

I believe I have answered this question previously on this list or
sip-implementors. The answer is no, it is actually not needed for the
reliable provisional response to copy the non-INVITE and INVITE-response
behavior. As I explained, thats because this message is effectively part of
a three way handshake, which is 1xx/PRACK/200-PRACK. Thus, it is more like
INVITE, which is also the first request in a three-way handshake. So, its
relaibility rules follow INVITE.

-Jonathan R.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Tue Jun 12 17:39:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25172;
	Tue, 12 Jun 2001 17:38:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11257;
	Tue, 12 Jun 2001 17:35:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11225
	for ; Tue, 12 Jun 2001 17:35:35 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25092
	for ; Tue, 12 Jun 2001 17:35:02 -0400 (EDT)
From: adam.roach@ericsson.com
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f5CLZLa02738;
	Tue, 12 Jun 2001 16:35:21 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f5CLZLr09268;
	Tue, 12 Jun 2001 16:35:21 -0500 (CDT)
Received: from pc050163 (pc050178.exu.ericsson.se [138.85.50.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id QAA06591; Tue, 12 Jun 2001 16:35:20 -0500 (CDT)
Reply-To: 
To: "'Jonathan Rosenberg'" ,
        "'Michael Thomas'" 
Cc: , 
Subject: RE: [SIP] Killing hung media streams
Date: Tue, 12 Jun 2001 16:35:16 -0500
Message-ID: <61D824C63B99D311975E00508B0CC98502251835@eamrcnt717.exu.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> 
> I suppose we could mandate that a re-INVITE is always done, 
> and then, if a
> 481 is generated, the call is considered terminated. That 
> would generally
> work, I think, but would often be a waste.

Some might even go so far as to phrase that as 
choosing "generality over efficiency."

;)

/a

P.S. I don't like the word "mandate" in this context. I
     kind of prefer "suggest."


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 13 06:44:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18146;
	Wed, 13 Jun 2001 06:44:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10730;
	Wed, 13 Jun 2001 06:31:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA10699
	for ; Wed, 13 Jun 2001 06:31:41 -0400 (EDT)
Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18100
	for ; Wed, 13 Jun 2001 06:31:10 -0400 (EDT)
Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca
          via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 13 Jun 2001 11:31:30 UT
Received: (private information removed)
Message-ID: <3B273ED0.364319DE@ubiquity.net>
From: James Undery 
To: "'sip@ietf.org'" 
Date: Wed, 13 Jun 2001 06:22:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Inconsistency in bis draft
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Hi,
Section 1.5.2 states in the last paragraph

    "User agents SHOULD implement both UDP and TCP transport. Proxy,
registrar, (sic) and redirect servers MUST implement both UDP and TCP
transport."

Section A1 says

    "User agents and stateless proxies MUST support UDP and MAY support
TCP or other transport protocols, stateful proxies MUST support both UDP
and TCP."

Also I'd note stateless proxies shouldn't use TCP as a server SHOULD NOT
close a TCP connection until it has sent its final response (Section
14.2). Although the removal of the CANCEL semantics of closing a
connection would allow this I guess, provided a UA can handle a response
on a new TCP connection. (Although the FAQ says a proxy must be stateful
if it uses TCP I guess this might have changed see
http://www.cs.columbia.edu/~hgs/sip/faq/cache/36.html)

James Undery



_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jun 13 08:23:40 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20325
	for ; Wed, 13 Jun 2001 08:23:39 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DC7F744337; Wed, 13 Jun 2001 08:24:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mctbdc.mctchn (unknown [202.9.161.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 2097B44336
	for ; Wed, 13 Jun 2001 08:23:54 -0400 (EDT)
Received: by MCTBDC with Internet Mail Service (5.5.2653.19)
	id ; Wed, 13 Jun 2001 17:56:35 +0530
Message-ID: 
From: Deepika Giri 
To: Jonathan Rosenberg 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Re-invites in a multi-party call
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 13 Jun 2001 17:56:33 +0530

My conferencing model centralized in nature, where the conference
server/bridge does the mixing.  The usr A is not aware that he's connected
to the bridge, only the Conference Control application does the bridging of
all the users to the CB, this is using 3pcc.

As far as A is concerned, he knows that he is in conference with B and C,
so, he can put them on hold by sending them messages individually. right? or
can he send a single hold message that will put both of the users on hold?
how does a standard SIP phone do this?

what if there is a situation where there is one more user D in the
conference(brought in by C, whose presence A is not aware of?  He cannot
send a hold message to D, he doesn't even know he exists, unless the list of
participants in the conference is constantly given to each of the users.

THanks
Deepika
-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, June 13, 2001 4:40 AM
To: 'Deepika Giri'; Jonathan Rosenberg
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Re-invites in a multi-party call




 

> -----Original Message-----
> From: Deepika Giri [mailto:deepika@mascon.co.in]
> Sent: Monday, June 11, 2001 6:03 AM
> To: jdrosen@dynamicsoft.com
> Cc: sip@lists.bell-labs.com
> Subject: [SIP] Re-invites in a multi-party call
> 
> 
> Hi,
> 
> I am trying to implement a multi-party conference control 
> application in SIP
> using 3pcc.
> My problem is this:
> 
> Usr A is currently in a conference call with User B and C, 
> now it wishes to
> put the current conference call on hold, by sending a 
> re-INVITE, but what
> will be the sip request url for this re-invite, does it send 
> hold messages
> to B and C individually? 

This question cannot be answered without knowing what conferencing model is
being used. Conferencing models for SIP are discussed at length in:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-conferencing-mode
ls-00.txt

In the case of a dial-in conference server, you would hold the other
participants by sending a re-INVITE to the server itself, with a 0.0.0.0
SDP.

In the case of end system mixing, described in section 2 of the above
document, you would send a hold individually to all the other participants
being mixed.

You later write:
> That was not my question, not to put a single user on hold, I 
> need to put
> all "conference participants on hold".
> 
> Anyway, I think multi-cast should work as suggested by Iliff TIna.
> 

Multicast? The phrases "multicast" and "should work" are contradictory and
usually don't belong in the same sentence. In any case, multicast won't help
you in any way for anything but multicast conferences. In the case of a
multicast conference (where the media is distributed via multicast), there
is no possibility for a hold. You would simply stop listening for media.

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

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


From sip-admin@ietf.org  Wed Jun 13 08:27:29 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20462;
	Wed, 13 Jun 2001 08:27:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13863;
	Wed, 13 Jun 2001 08:22:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13834
	for ; Wed, 13 Jun 2001 08:22:43 -0400 (EDT)
Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20271
	for ; Wed, 13 Jun 2001 08:22:08 -0400 (EDT)
Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345)
	id A7F1C64C; Wed, 13 Jun 2001 05:21:58 -0700 (PDT)
Received: from excmun-gh01.eur.compaq.com (excmun-gh01.dem.cpqcorp.net [16.41.92.160])
	by zcamail03.zca.compaq.com (Postfix) with ESMTP id 9BC8F446
	for ; Wed, 13 Jun 2001 05:21:57 -0700 (PDT)
Received: by excmun-gh01.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21)
	id ; Wed, 13 Jun 2001 14:22:06 +0200
Message-ID: 
From: "Gayraud, Richard" 
To: "'sip@ietf.org'" 
Date: Wed, 13 Jun 2001 14:24:17 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] SIP-URL params parsing issue
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Hi,

In reading the Contact header ABNF, I noticed that a SIP-URL
can be immediately followed by generic-params.

I also noticed that SIP-URL can be ended by similar parameters 
(almost the same syntax, separated by ';'). 

Therefore I wonder how a general purpose SIP parser could 
determine whether a given parameter is part of the SIP-URL 
or is a generic-param of the Contact header field.

Here is an example of such an ambiguous header:

  Contact: me@compaq.com;my_param=my_value

Note that adding an extra LWS after the URI may solve the 
issue, but the spec does not require it.

I noticed the same problem for the From and To headers. Some 
other headers, like Alert-Info are safe, as they force the URI to 
be enclosed between '<' and  '>'.

Thanks in advance for your help,

Richard Gayraud.


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 13 08:47:46 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21214;
	Wed, 13 Jun 2001 08:47:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14831;
	Wed, 13 Jun 2001 08:43:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14801
	for ; Wed, 13 Jun 2001 08:43:45 -0400 (EDT)
Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20976
	for ; Wed, 13 Jun 2001 08:43:11 -0400 (EDT)
Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 13 Jun 2001 08:38:02 -0400
Message-ID: 
From: Alexandre Charest 
To: "'Gayraud, Richard'" ,
        "'sip@ietf.org'"
	 
Subject: RE: [Sip] SIP-URL params parsing issue
Date: Wed, 13 Jun 2001 08:38:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Look just behind the ABNF for the contact at page 46 of the ps. It is
written:
"Event if the "display-name" is empty, the "name-addr" form MUST be used if
the "addr-spec" contains a comma, semicolon or question mark."

So Contact is safe too. You can find the same sentence in the From and To
headers description.

-----Original Message-----
From: Gayraud, Richard [mailto:Richard.Gayraud@compaq.com]
Sent: Wednesday, June 13, 2001 8:24 AM
To: 'sip@ietf.org'
Subject: [Sip] SIP-URL params parsing issue


Hi,

In reading the Contact header ABNF, I noticed that a SIP-URL
can be immediately followed by generic-params.

I also noticed that SIP-URL can be ended by similar parameters 
(almost the same syntax, separated by ';'). 

Therefore I wonder how a general purpose SIP parser could 
determine whether a given parameter is part of the SIP-URL 
or is a generic-param of the Contact header field.

Here is an example of such an ambiguous header:

  Contact: me@compaq.com;my_param=my_value

Note that adding an extra LWS after the URI may solve the 
issue, but the spec does not require it.

I noticed the same problem for the From and To headers. Some 
other headers, like Alert-Info are safe, as they force the URI to 
be enclosed between '<' and  '>'.

Thanks in advance for your help,

Richard Gayraud.


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 13 10:38:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24124;
	Wed, 13 Jun 2001 10:38:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17435;
	Wed, 13 Jun 2001 09:51:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17404
	for ; Wed, 13 Jun 2001 09:51:23 -0400 (EDT)
Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23115
	for ; Wed, 13 Jun 2001 09:50:49 -0400 (EDT)
From: adam.roach@ericsson.com
Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f5DDoK809642;
	Wed, 13 Jun 2001 08:50:27 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f5DDoIb19782;
	Wed, 13 Jun 2001 08:50:18 -0500 (CDT)
Received: from pc050163 (pc050111.exu.ericsson.se [138.85.50.111]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id IAA08987; Wed, 13 Jun 2001 08:50:17 -0500 (CDT)
Reply-To: 
To: "'Deepika Giri'" ,
        "Jonathan Rosenberg" 
Cc: 
Subject: RE: [SIP] Re-invites in a multi-party call
Date: Wed, 13 Jun 2001 08:50:15 -0500
Message-ID: <61D824C63B99D311975E00508B0CC9850225183C@eamrcnt717.exu.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

[Moving to IETF list]

> -----Original Message-----
> From: Deepika Giri [mailto:deepika@mascon.co.in]
> 
> My conferencing model centralized in nature, where the conference
> server/bridge does the mixing.  The usr A is not aware that 
> he's connected
> to the bridge, only the Conference Control application does 
> the bridging of
> all the users to the CB, this is using 3pcc.
> 
> As far as A is concerned, he knows that he is in conference 
> with B and C,
> so, he can put them on hold by sending them messages 
> individually. right?

Not with the architecture you just described. As far as user A's
equipment is concerned, he is communicating with exactly one
party: the conference bridge. He will hold the conference bridge.

/a


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 13 13:58:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28346;
	Wed, 13 Jun 2001 13:58:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26212;
	Wed, 13 Jun 2001 13:48:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26183
	for ; Wed, 13 Jun 2001 13:48:11 -0400 (EDT)
Received: from web13902.mail.yahoo.com (web13902.mail.yahoo.com [216.136.175.28])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28228
	for ; Wed, 13 Jun 2001 13:47:39 -0400 (EDT)
Message-ID: <20010613174809.89424.qmail@web13902.mail.yahoo.com>
Received: from [63.84.167.14] by web13902.mail.yahoo.com; Wed, 13 Jun 2001 10:48:09 PDT
Date: Wed, 13 Jun 2001 10:48:09 -0700 (PDT)
From: Gustaf Lawson 
Subject: Re: [Sip] REFER method
To: Wai Wu , "'sip@ietf.org'" 
In-Reply-To: <60A9CA50081AD4118BD60040F60C1A9F0A3DB3@NT-SERVER>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1189641421-992454489=:83838"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

--0-1189641421-992454489=:83838
Content-Type: text/plain; charset=us-ascii


ftp://ietf.org/internet-drafts/draft-ietf-sip-cc-transfer-04.txt

  Wai Wu  wrote: 

Does any one have any info on the REFER method. I know it is not going to be released until fall. 

Thanks 



---------------------------------
Do You Yahoo!?
Yahoo! Mail Personal Address - Get email at your own domain with Yahoo! Mail.
--0-1189641421-992454489=:83838
Content-Type: text/html; charset=us-ascii


ftp://ietf.org/internet-drafts/draft-ietf-sip-cc-transfer-04.txt


  Wai Wu <wwu@calltrol.com> wrote: 





Does any one have any info on the REFER method. I know it is not going to be released until fall. 


Thanks 

Do You Yahoo!?

Yahoo! Mail Personal Address - 
Get email at your own domain with Yahoo! Mail.
--0-1189641421-992454489=:83838--

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 13 14:11:45 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28612;
	Wed, 13 Jun 2001 14:11:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27042;
	Wed, 13 Jun 2001 14:08:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27015
	for ; Wed, 13 Jun 2001 14:08:12 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28501
	for ; Wed, 13 Jun 2001 14:07:39 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5DI7h923351;
	Wed, 13 Jun 2001 11:07:43 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f5DI7e601533;
	Wed, 13 Jun 2001 11:07:40 -0700 (PDT)
Received: from cisco.com (dhcp-edison-119.cisco.com [171.68.78.119]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id LAA22215; Wed, 13 Jun 2001 11:07:35 -0700 (PDT)
Message-ID: <3B27AC3D.963C3B4E@cisco.com>
Date: Wed, 13 Jun 2001 14:09:01 -0400
From: Flemming Andreasen 
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Cullen Jennings'" , sip@ietf.org
Subject: Re: [Sip] Few tiny issues with SDP section of bis3
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > Sent: Monday, June 11, 2001 3:15 PM
> > To: sip@ietf.org
> > Subject: [Sip] Few tiny issues with SDP section of bis3
> >
> >
> >
> > Examples in section B don't have an e or P line in the SDP
> > even though one
> > them must be present.
>
> OK, I fixed that.

Speaking of that: Why is there now a requirement in the SDP section stating
that "Either an e line or p line MUST be present." ?

-- Flemming


--
Flemming Andreasen
Cisco Systems



_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 13 14:18:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28746;
	Wed, 13 Jun 2001 14:18:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27381;
	Wed, 13 Jun 2001 14:15:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27352
	for ; Wed, 13 Jun 2001 14:15:07 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28681
	for ; Wed, 13 Jun 2001 14:14:35 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA21684;
	Wed, 13 Jun 2001 14:19:04 -0400 (EDT)
Message-ID: <3B27ADA6.154CDECA@dynamicsoft.com>
Date: Wed, 13 Jun 2001 14:15:02 -0400
From: Anders Kristensen 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Flemming Andreasen 
CC: Jonathan Rosenberg ,
        "'Cullen Jennings'" , sip@ietf.org
Subject: Re: [Sip] Few tiny issues with SDP section of bis3
References:  <3B27AC3D.963C3B4E@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

It's required by RFC 2327 (no idea why, though:

   o Either an email field or a phone field must be specified.
     Additional email and phone fields are allowed.

Thanks,
Anders


Flemming Andreasen wrote:
> 
> Jonathan Rosenberg wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > > Sent: Monday, June 11, 2001 3:15 PM
> > > To: sip@ietf.org
> > > Subject: [Sip] Few tiny issues with SDP section of bis3
> > >
> > >
> > >
> > > Examples in section B don't have an e or P line in the SDP
> > > even though one
> > > them must be present.
> >
> > OK, I fixed that.
> 
> Speaking of that: Why is there now a requirement in the SDP section stating
> that "Either an e line or p line MUST be present." ?
> 
> -- Flemming
> 
> --
> Flemming Andreasen
> Cisco Systems
> 
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 13 14:26:44 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28914;
	Wed, 13 Jun 2001 14:26:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27637;
	Wed, 13 Jun 2001 14:20:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27610
	for ; Wed, 13 Jun 2001 14:20:43 -0400 (EDT)
Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28776
	for ; Wed, 13 Jun 2001 14:20:10 -0400 (EDT)
From: adam.roach@ericsson.com
Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f5DIK4821228;
	Wed, 13 Jun 2001 13:20:04 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f5DIK3104762;
	Wed, 13 Jun 2001 13:20:03 -0500 (CDT)
Received: from pc050163 (pc050178.exu.ericsson.se [138.85.50.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id NAA23786; Wed, 13 Jun 2001 13:20:02 -0500 (CDT)
Reply-To: 
To: "'Flemming Andreasen'" ,
        "Jonathan Rosenberg" 
Cc: "'Cullen Jennings'" , 
Subject: RE: [Sip] Few tiny issues with SDP section of bis3
Date: Wed, 13 Jun 2001 13:20:00 -0500
Message-ID: <61D824C63B99D311975E00508B0CC98502251844@eamrcnt717.exu.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <3B27AC3D.963C3B4E@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
>
> Speaking of that: Why is there now a requirement in the SDP 
> section stating
> that "Either an e line or p line MUST be present." ?

This is actually a requirement straight from SDP; it's just so
often overlooked that (I guess) it seems to make sense to
reiterate it in SIP.

From RFC2327:

    "Either an email field or a phone field must be specified.
     Additional email and phone fields are allowed."

/a


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 13 15:26:01 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29907;
	Wed, 13 Jun 2001 15:26:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29427;
	Wed, 13 Jun 2001 15:18:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29403
	for ; Wed, 13 Jun 2001 15:18:03 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29770
	for ; Wed, 13 Jun 2001 15:17:30 -0400 (EDT)
Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5DJDeF07546;
	Wed, 13 Jun 2001 12:13:40 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f5DJFCa09731;
	Wed, 13 Jun 2001 12:15:12 -0700 (PDT)
Received: from cisco.com (dhcp-edison-119.cisco.com [171.68.78.119]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id MAA24200; Wed, 13 Jun 2001 12:15:10 -0700 (PDT)
Message-ID: <3B27BC14.7E81C829@cisco.com>
Date: Wed, 13 Jun 2001 15:16:36 -0400
From: Flemming Andreasen 
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen 
CC: Jonathan Rosenberg ,
        "'Cullen Jennings'" , sip@ietf.org
Subject: Re: [Sip] Few tiny issues with SDP section of bis3
References:  <3B27AC3D.963C3B4E@cisco.com> <3B27ADA6.154CDECA@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

That's far from clear if you read it in the context it was provided in. Also, do
note that both of these fields are in fact listed as optional earlier in the
spec.

-- Flemming

Anders Kristensen wrote:

> It's required by RFC 2327 (no idea why, though:
>
>    o Either an email field or a phone field must be specified.
>      Additional email and phone fields are allowed.
>
> Thanks,
> Anders
>
> Flemming Andreasen wrote:
> >
> > Jonathan Rosenberg wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > > > Sent: Monday, June 11, 2001 3:15 PM
> > > > To: sip@ietf.org
> > > > Subject: [Sip] Few tiny issues with SDP section of bis3
> > > >
> > > >
> > > >
> > > > Examples in section B don't have an e or P line in the SDP
> > > > even though one
> > > > them must be present.
> > >
> > > OK, I fixed that.
> >
> > Speaking of that: Why is there now a requirement in the SDP section stating
> > that "Either an e line or p line MUST be present." ?
> >
> > -- Flemming
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> > _______________________________________________
> > Sip mailing list
> > Sip@ietf.org
> > http://www.ietf.org/mailman/listinfo/sip

--
Flemming Andreasen
Cisco Systems



_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 13 15:33:30 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00037;
	Wed, 13 Jun 2001 15:33:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29857;
	Wed, 13 Jun 2001 15:30:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29822
	for ; Wed, 13 Jun 2001 15:30:20 -0400 (EDT)
Received: from mailserver.sylantro.com ([65.200.90.207])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29997
	for ; Wed, 13 Jun 2001 15:29:46 -0400 (EDT)
Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 13 Jun 2001 12:27:39 -0700
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Received: by mailserver.sylantro.com with Internet Mail Service (
 5.5.2653.19) id ; Wed, 13 Jun 2001 12:27:39 -0700
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD84E7D5@mailserver.sylantro.com>
From: "Mohsen Soroush-nejad" 
To: "Flemming Andreasen" ,
        "Anders Kristensen" 
cc: "Jonathan Rosenberg" ,
        "'Cullen Jennings'" , sip@ietf.org
Subject: RE: [Sip] Few tiny issues with SDP section of bis3
Date: Wed, 13 Jun 2001 12:27:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 1739612114317-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Section 6 of RFC 2327 lists all the SDP fields. The optional
fields are identified by "*". "e" & "p" are identified as optional....

Mohsen
-----Original Message-----
From: Flemming Andreasen [mailto:fandreas@cisco.com]
Sent: Wednesday, June 13, 2001 12:17 PM
To: Anders Kristensen
Cc: Jonathan Rosenberg; 'Cullen Jennings'; sip@ietf.org
Subject: Re: [Sip] Few tiny issues with SDP section of bis3


That's far from clear if you read it in the context it was provided in.
Also, do
note that both of these fields are in fact listed as optional earlier in the
spec.

-- Flemming

Anders Kristensen wrote:

> It's required by RFC 2327 (no idea why, though:
>
>    o Either an email field or a phone field must be specified.
>      Additional email and phone fields are allowed.
>
> Thanks,
> Anders
>
> Flemming Andreasen wrote:
> >
> > Jonathan Rosenberg wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > > > Sent: Monday, June 11, 2001 3:15 PM
> > > > To: sip@ietf.org
> > > > Subject: [Sip] Few tiny issues with SDP section of bis3
> > > >
> > > >
> > > >
> > > > Examples in section B don't have an e or P line in the SDP
> > > > even though one
> > > > them must be present.
> > >
> > > OK, I fixed that.
> >
> > Speaking of that: Why is there now a requirement in the SDP section
stating
> > that "Either an e line or p line MUST be present." ?
> >
> > -- Flemming
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> > _______________________________________________
> > Sip mailing list
> > Sip@ietf.org
> > http://www.ietf.org/mailman/listinfo/sip

--
Flemming Andreasen
Cisco Systems



_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 13 15:42:08 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00129;
	Wed, 13 Jun 2001 15:42:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00085;
	Wed, 13 Jun 2001 15:36:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00052
	for ; Wed, 13 Jun 2001 15:36:24 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00082
	for ; Wed, 13 Jun 2001 15:35:51 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA22918;
	Wed, 13 Jun 2001 15:40:16 -0400 (EDT)
Message-ID: <3B27C0AE.95EFF5E@dynamicsoft.com>
Date: Wed, 13 Jun 2001 15:36:14 -0400
From: Anders Kristensen 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mohsen Soroush-nejad 
CC: Flemming Andreasen ,
        Jonathan Rosenberg ,
        "'Cullen Jennings'" , sip@ietf.org
Subject: Re: [Sip] Few tiny issues with SDP section of bis3
References: <79FEAA5FABA7D411BF580001023D1BBD84E7D5@mailserver.sylantro.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

They're optional in the grammar, but the accompanying text seems
perfectly clear that one or the other must be present. Sometimes it's
more convenient to state requirements in english than BNF - doesn't mean
it's not part of the spec. I'm pretty sure that the quoted sentence is
the only reason it's required for SIP.

Anders


Mohsen Soroush-nejad wrote:
> 
> Section 6 of RFC 2327 lists all the SDP fields. The optional
> fields are identified by "*". "e" & "p" are identified as optional....
> 
> Mohsen
> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Wednesday, June 13, 2001 12:17 PM
> To: Anders Kristensen
> Cc: Jonathan Rosenberg; 'Cullen Jennings'; sip@ietf.org
> Subject: Re: [Sip] Few tiny issues with SDP section of bis3
> 
> That's far from clear if you read it in the context it was provided in.
> Also, do
> note that both of these fields are in fact listed as optional earlier in the
> spec.
> 
> -- Flemming
> 
> Anders Kristensen wrote:
> 
> > It's required by RFC 2327 (no idea why, though:
> >
> >    o Either an email field or a phone field must be specified.
> >      Additional email and phone fields are allowed.
> >
> > Thanks,
> > Anders
> >
> > Flemming Andreasen wrote:
> > >
> > > Jonathan Rosenberg wrote:
> > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > > > > Sent: Monday, June 11, 2001 3:15 PM
> > > > > To: sip@ietf.org
> > > > > Subject: [Sip] Few tiny issues with SDP section of bis3
> > > > >
> > > > >
> > > > >
> > > > > Examples in section B don't have an e or P line in the SDP
> > > > > even though one
> > > > > them must be present.
> > > >
> > > > OK, I fixed that.
> > >
> > > Speaking of that: Why is there now a requirement in the SDP section
> stating
> > > that "Either an e line or p line MUST be present." ?
> > >
> > > -- Flemming
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> > >
> > > _______________________________________________
> > > Sip mailing list
> > > Sip@ietf.org
> > > http://www.ietf.org/mailman/listinfo/sip
> 
> --
> Flemming Andreasen
> Cisco Systems
> 
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jun 13 16:05:38 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00732
	for ; Wed, 13 Jun 2001 16:05:37 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E114844337; Wed, 13 Jun 2001 16:06:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.pingtel.com (mail.pingtel.com [216.91.1.131])
	by lists.bell-labs.com (Postfix) with ESMTP id E33CA44336
	for ; Wed, 13 Jun 2001 16:05:30 -0400 (EDT)
Received: from pingtel.com (cdhcp106.pingtel.com [10.1.1.106])
	by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id f5DK4ud14845;
	Wed, 13 Jun 2001 16:04:56 -0400
Message-ID: <3B27C8A6.27D85C26@pingtel.com>
From: Rich Schaaf 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] DNS SRV and authentication challenges
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 13 Jun 2001 16:10:14 -0400
Content-Transfer-Encoding: 7bit

Hi all,

I'm having trouble figuring out the correct behavior for the following
situation involving DNS SRV and proxy authentication.  The scenario is:

   For a given domain name, DNS is configured with two SIP SRV
   records.  The SRV records for the two hosts (let's refer to
   them as HostA and HostB) have the same priority and weight
   (i.e., round robin behavior).

   Transaction #1:
     A SIP client sends an INVITE request.  A DNS SRV lookup is
     performed by the SIP client (which returns HostA) and the
     request is sent to the SIP proxy at HostA.

     The SIP proxy sends back a "407 Proxy Authentication Required"
     response.

     The SIP client sends an ACK to HostA.

   Transaction #2:
     The SIP client sends a new INVITE request that includes
     proxy authorization information.  Since this is a new
     transaction, a DNS SRV lookup is performed by the SIP client
     (which returns HostB) and the request is sent to the SIP
     proxy at HostB.

     The SIP proxy at HostB is not the proxy that issued the challenge
     to the SIP client so it sends back a "403 Non-Trusted Caller"
     response and the call fails.

Based on my reading of draft-ietf-sip-rfc2543bis-03.txt, I think the SIP
client is adhering to the spec.  The draft states:
  "Clients MUST determine the destination address once per
   transaction rather than for each request, i.e., requests
   within the same transaction MUST be sent to the same network
   address."

The draft also defines a transaction as follows:
  "(SIP) transaction: A SIP transaction occurs between a client
   and a server and comprises all messages from the first request
   sent from the client to the server up to a final (non-1xx)
   response sent from the server to the client.  A transaction is
   identified by the CSeq sequence number (Section 10.20) within a
   single call leg. The ACK request has the same CSeq number as
   the corresponding INVITE request, but comprises a transaction
   of its own."

So, if my reading of the spec is correct, the SIP client is behaving
correctly.  The SIP proxy behavior and DNS configuration also seem
reasonable.  However, the end result is that the call fails to get set
up.

Please let me know if my reasoning is correct and I welcome any
suggestions on what _should_ happen in this situation.

Cheers,
Rich Schaaf

======================================================================
Rich Schaaf                               Pingtel Corporation
Email: rschaaf@pingtel.com                Suite 2200
Voice: +1 (781) 938-5306 x112             400 West Cummings Park
Fax:   +1 (781) 938-9650                  Woburn, MA  01801
======================================================================

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


From sip-admin@ietf.org  Wed Jun 13 16:23:25 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01026;
	Wed, 13 Jun 2001 16:23:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01229;
	Wed, 13 Jun 2001 16:15:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01196
	for ; Wed, 13 Jun 2001 16:15:54 -0400 (EDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00909
	for ; Wed, 13 Jun 2001 16:15:20 -0400 (EDT)
Received: from 157.54.9.101 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 13 Jun 2001 11:52:27 -0700 (Pacific Daylight Time)
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 13 Jun 2001 11:52:27 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Wed, 13 Jun 2001 11:52:25 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 13 Jun 2001 11:51:05 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Sip] Few tiny issues with SDP section of bis3
Date: Wed, 13 Jun 2001 11:51:05 -0700
Message-ID: 
Thread-Topic: [Sip] Few tiny issues with SDP section of bis3
Thread-Index: AcD0NXEDfVRJxKp1SVKahuBUEdxdcQABDORg
From: "Christian Huitema" 
To: , "Flemming Andreasen" ,
        "Jonathan Rosenberg" 
Cc: "Cullen Jennings" , 
X-OriginalArrivalTime: 13 Jun 2001 18:51:06.0017 (UTC) FILETIME=[CD3F6110:01C0F439]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA01197
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

> From RFC2327:
> 
>     "Either an email field or a phone field must be specified.
>      Additional email and phone fields are allowed."

Yes, this is present in RFC 2327, but the rationale is in SAP, not SIP.
Arguably, these fields are never used in SIP. I would argue that we
should have a "liberal with what you receive" warning that states that,
in deviance with 2327, email and phone field are not mandatory in our
application, and will often be both absent.

-- Christian Huitema

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 13 16:41:13 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01279;
	Wed, 13 Jun 2001 16:41:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01894;
	Wed, 13 Jun 2001 16:35:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01865
	for ; Wed, 13 Jun 2001 16:35:25 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01222
	for ; Wed, 13 Jun 2001 16:34:52 -0400 (EDT)
From: adam.roach@ericsson.com
Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f5DKZOa15193;
	Wed, 13 Jun 2001 15:35:24 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f5DKZNZ29681;
	Wed, 13 Jun 2001 15:35:23 -0500 (CDT)
Received: from pc050163 (pc050178.exu.ericsson.se [138.85.50.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id PAA01150; Wed, 13 Jun 2001 15:35:23 -0500 (CDT)
Reply-To: 
To: "'Rich Schaaf'" , 
Subject: RE: [SIP] DNS SRV and authentication challenges
Date: Wed, 13 Jun 2001 15:35:22 -0500
Message-ID: <61D824C63B99D311975E00508B0CC98502251846@eamrcnt717.exu.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <3B27C8A6.27D85C26@pingtel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: Rich Schaaf [mailto:rschaaf@pingtel.com]

  [Description of problem deleted. Synopsis: DNS points to
   two servers with the same q-values; one issues a challenge
   and the other receives the response]
 
> So, if my reading of the spec is correct, the SIP client is behaving
> correctly.  The SIP proxy behavior and DNS configuration also seem
> reasonable.  However, the end result is that the call fails to get set
> up.
> 
> Please let me know if my reasoning is correct and I welcome any
> suggestions on what _should_ happen in this situation.

I would contend that, in these cirucumstances, you would
need to have some sort of coordination between these
"equivalent" nodes. They can share a back-end database
or a deterministic algorithm for generating challenges
based on, say, a synchronized clock.

(I'm not a security expert, so you might want to run
the second idea past someone who has a better idea of
what the implications of a deterministic challenge
algorithm might be if you intend to use it).

/a


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 13 16:47:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01326;
	Wed, 13 Jun 2001 16:47:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02024;
	Wed, 13 Jun 2001 16:40:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01995
	for ; Wed, 13 Jun 2001 16:40:44 -0400 (EDT)
Received: from gatekeeper.calltrol.com (root@[65.105.250.35])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01269
	for ; Wed, 13 Jun 2001 16:40:10 -0400 (EDT)
Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253])
	by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id QAA28746;
	Wed, 13 Jun 2001 16:42:40 -0400
Received: by NT-SERVER with Internet Mail Service (5.5.2448.0)
	id ; Wed, 13 Jun 2001 16:43:02 -0400
Message-ID: <60A9CA50081AD4118BD60040F60C1A9F0A3DBA@NT-SERVER>
From: Wai Wu 
To: "'Gustaf Lawson'" , Wai Wu ,
        "'sip@ietf.org'" 
Subject: RE: [Sip] REFER method
Date: Wed, 13 Jun 2001 16:43:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F449.70727960"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F449.70727960
Content-Type: text/plain;
	charset="iso-8859-1"

I am sorry, that is a broken link

-----Original Message-----
From: Gustaf Lawson [mailto:guslawson@yahoo.com]
Sent: Wednesday, June 13, 2001 1:48 PM
To: Wai Wu; 'sip@ietf.org'
Subject: Re: [Sip] REFER method



ftp://ietf.org/internet-drafts/draft-ietf-sip-cc-transfer-04.txt
 



  Wai Wu  wrote: 



Does any one have any info on the REFER method. I know it is not going to be
released until fall. 

Thanks 




  _____  

Do You Yahoo!?
Yahoo! Mail Personal  
Address - Get email at your own domain with Yahoo! Mail.


------_=_NextPart_001_01C0F449.70727960
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









I am=20
sorry, that is a broken link



  
-----Original Message-----
From: Gustaf Lawson=20
  [mailto:guslawson@yahoo.com]
Sent: Wednesday, June 13, 2001 =
1:48=20
  PM
To: Wai Wu; 'sip@ietf.org'
Subject: Re: [Sip] =
REFER=20
  method


  
ftp://ietf.org/internet-drafts/draft-ietf-sip-cc-transfer-04.txt
  
  Wai Wu <wwu@calltrol.com> wrote:=20
  
    

    
Does any one have any info on the =
REFER method. I=20
    know it is not going to be released until fall. 

    
Thanks 

  


  

  Do You Yahoo!?
Yahoo! =
Mail Personal=20
  Address - Get email at your own domain with Yahoo!=20
Mail.

------_=_NextPart_001_01C0F449.70727960--

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 13 16:48:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01351;
	Wed, 13 Jun 2001 16:48:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02114;
	Wed, 13 Jun 2001 16:42:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02087
	for ; Wed, 13 Jun 2001 16:42:57 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01299
	for ; Wed, 13 Jun 2001 16:42:22 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA23956
	for ; Wed, 13 Jun 2001 16:46:43 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 13 Jun 2001 16:42:42 -0400
Message-ID: 
From: Rakesh Shah 
To: "'sip@ietf.org'" 
Subject: RE: [Sip] REFER method
Date: Wed, 13 Jun 2001 16:42:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F449.641A9D9A"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F449.641A9D9A
Content-Type: text/plain;
	charset="iso-8859-1"

It works for me.
 
Regards,
 
Rakesh

-----Original Message-----
From: Wai Wu [mailto:wwu@calltrol.com]
Sent: Wednesday, June 13, 2001 4:43 PM
To: 'Gustaf Lawson'; Wai Wu; 'sip@ietf.org'
Subject: RE: [Sip] REFER method


I am sorry, that is a broken link

-----Original Message-----
From: Gustaf Lawson [mailto:guslawson@yahoo.com]
Sent: Wednesday, June 13, 2001 1:48 PM
To: Wai Wu; 'sip@ietf.org'
Subject: Re: [Sip] REFER method



ftp://ietf.org/internet-drafts/draft-ietf-sip-cc-transfer-04.txt
 



  Wai Wu  wrote: 



Does any one have any info on the REFER method. I know it is not going to be
released until fall. 

Thanks 




  _____  

Do You Yahoo!?
Yahoo! Mail   Personal
Address - Get email at your own domain with Yahoo! Mail.


------_=_NextPart_001_01C0F449.641A9D9A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









It=20
works for me.


 


Regards,


 


Rakesh



  
-----Original Message-----
From: Wai Wu=20
  [mailto:wwu@calltrol.com]
Sent: Wednesday, June 13, 2001 =
4:43=20
  PM
To: 'Gustaf Lawson'; Wai Wu; =
'sip@ietf.org'
Subject:=20
  RE: [Sip] REFER method


  
I am=20
  sorry, that is a broken link

  

    
-----Original Message-----
From: Gustaf Lawson=20
    [mailto:guslawson@yahoo.com]
Sent: Wednesday, June 13, =
2001 1:48=20
    PM
To: Wai Wu; 'sip@ietf.org'
Subject: Re: =
[Sip] REFER=20
    method


    
ftp://ietf.org/internet-drafts/draft-ietf-sip-cc-transfer-04.txt
    
  Wai Wu <wwu@calltrol.com> wrote:=20
    
      

      
Does any one have any info on the =
REFER method.=20
      I know it is not going to be released until fall. 

      
Thanks 

    


    

    Do You Yahoo!?
Yahoo! =
Mail=20
    Personal Address - Get email at your own domain with Yahoo!=20
  Mail.


------_=_NextPart_001_01C0F449.641A9D9A--

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 14 08:22:42 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26117;
	Thu, 14 Jun 2001 08:22:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06985;
	Thu, 14 Jun 2001 08:11:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06954
	for ; Thu, 14 Jun 2001 08:11:11 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25870
	for ; Thu, 14 Jun 2001 08:10:39 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5ECAe927130;
	Thu, 14 Jun 2001 05:10:40 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f5ECAgU01697;
	Thu, 14 Jun 2001 05:10:42 -0700 (PDT)
Received: from cisco.com (dhcp-edison-119.cisco.com [171.68.78.119]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id FAA02618; Thu, 14 Jun 2001 05:10:38 -0700 (PDT)
Message-ID: <3B28AA15.DB8F10C1@cisco.com>
Date: Thu, 14 Jun 2001 08:12:05 -0400
From: Flemming Andreasen 
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "'sip@ietf.org'" ,
        Jonathan Rosenberg 
Subject: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of bis3]]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Based on this, can we agree, that the sentence "Either an e line or p line MUST be
present." in Section B.2 should be removed, and hence there's no need to mention
"e" and "p" in the next sentence ?

-- Flemming



Colin Perkins wrote:

> It seems that any mandatory use of p= or e= is a hang over from the
> original use of SDP with SAP. I don't see that it necessarily makes
> sense with many current uses of SDP.
>
> We should clarify this in the revision of SDP, does someone want to
> suggest wording changes to the draft?
> Colin
>
> --> Rajesh Kumar writes:
> >rfc2327  annotates them with a "*" and further says: Optional items are
> >marked with a "*".
> >
> >I take this to mean that these are optional. When using it in the context
> >of SIP, this convention should be followed. Further, I believe this
> >convention has been retained in the on-going SDP work, right?
> >
> >Rajesh
> >
> >At 04:25 PM 6/13/2001 -0400, Flemming Andreasen wrote:
> >>Can somebody clarify if either an email address ("e=") or phone number
> >>("p=") MUST
> >>be present in SDP. The spec doesn't seem entirely clear on this.
> >>
> >>
> >>Thanks
> >>
> >>         Flemming
> >>
> >>
> >>Anders Kristensen wrote:
> >>
> >> > They're optional in the grammar, but the accompanying text seems
> >> > perfectly clear that one or the other must be present. Sometimes it's
> >> > more convenient to state requirements in english than BNF - doesn't mean
> >> > it's not part of the spec. I'm pretty sure that the quoted sentence is
> >> > the only reason it's required for SIP.
> >> >
> >> > Anders
> >> >
> >> > Mohsen Soroush-nejad wrote:
> >> > >
> >> > > Section 6 of RFC 2327 lists all the SDP fields. The optional
> >> > > fields are identified by "*". "e" & "p" are identified as optional....
> >> > >
> >> > > Mohsen
> >> > > -----Original Message-----
> >> > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> >> > > Sent: Wednesday, June 13, 2001 12:17 PM
> >> > > To: Anders Kristensen
> >> > > Cc: Jonathan Rosenberg; 'Cullen Jennings'; sip@ietf.org
> >> > > Subject: Re: [Sip] Few tiny issues with SDP section of bis3
> >> > >
> >> > > That's far from clear if you read it in the context it was provided in.
> >> > > Also, do
> >> > > note that both of these fields are in fact listed as optional earlier
> >> in the
> >> > > spec.
> >> > >
> >> > > -- Flemming
> >> > >
> >> > > Anders Kristensen wrote:
> >> > >
> >> > > > It's required by RFC 2327 (no idea why, though:
> >> > > >
> >> > > >    o Either an email field or a phone field must be specified.
> >> > > >      Additional email and phone fields are allowed.
> >> > > >
> >> > > > Thanks,
> >> > > > Anders
> >> > > >
> >> > > > Flemming Andreasen wrote:
> >> > > > >
> >> > > > > Jonathan Rosenberg wrote:
> >> > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > > -----Original Message-----
> >> > > > > > > From: Cullen Jennings [mailto:fluffy@cisco.com]
> >> > > > > > > Sent: Monday, June 11, 2001 3:15 PM
> >> > > > > > > To: sip@ietf.org
> >> > > > > > > Subject: [Sip] Few tiny issues with SDP section of bis3
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > Examples in section B don't have an e or P line in the SDP
> >> > > > > > > even though one
> >> > > > > > > them must be present.
> >> > > > > >
> >> > > > > > OK, I fixed that.
> >> > > > >
> >> > > > > Speaking of that: Why is there now a requirement in the SDP section
> >> > > stating
> >> > > > > that "Either an e line or p line MUST be present." ?
> >> > > > >
> >> > > > > -- Flemming
> >> > > > >
> >> > > > > --
> >> > > > > Flemming Andreasen
> >> > > > > Cisco Systems
> >> > > > >
> >> > > > > _______________________________________________
> >> > > > > Sip mailing list
> >> > > > > Sip@ietf.org
> >> > > > > http://www.ietf.org/mailman/listinfo/sip
> >> > >
> >> > > --
> >> > > Flemming Andreasen
> >> > > Cisco Systems
> >> > >
> >> > > _______________________________________________
> >> > > Sip mailing list
> >> > > Sip@ietf.org
> >> > > http://www.ietf.org/mailman/listinfo/sip
> >>
> >>--
> >>Flemming Andreasen
> >>Cisco Systems
> >
> >  Rajesh
> >--------------------------------------------------------
> >Rajesh Kumar
> >Cisco Voice Technology Center
> >Tel: 408-527-0811, Fax: 408-853-1101
> >Epage: mailto:rkumar@epage.cisco.com
> >------------------------------------------------ --------
> >
> >

--
Flemming Andreasen
Cisco Systems



_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 14 11:06:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01747;
	Thu, 14 Jun 2001 11:06:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12911;
	Thu, 14 Jun 2001 10:58:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12829
	for ; Thu, 14 Jun 2001 10:58:11 -0400 (EDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01556
	for ; Thu, 14 Jun 2001 10:57:35 -0400 (EDT)
Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Jun 2001 07:55:04 -0700 (Pacific Daylight Time)
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Thu, 14 Jun 2001 07:53:59 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Thu, 14 Jun 2001 07:53:52 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Thu, 14 Jun 2001 07:52:31 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of bis3]]
Date: Thu, 14 Jun 2001 07:52:31 -0700
Message-ID: 
Thread-Topic: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of bis3]]
Thread-Index: AcD0y016uk9cicOmTwCmgjLhYGyg1wAFkJIg
From: "Christian Huitema" 
To: "Flemming Andreasen" , ,
        "Jonathan Rosenberg" 
X-OriginalArrivalTime: 14 Jun 2001 14:52:31.0939 (UTC) FILETIME=[A3CE2930:01C0F4E1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA12830
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Yes. In fact, I would be stronger. I would place a sentence saying
explicitly that and SDP text that does not include an "e=" or "p=" line
MUST NOT be rejected by SIP implementations.

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Thursday, June 14, 2001 5:12 AM
> To: 'sip@ietf.org'; Jonathan Rosenberg
> Subject: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of bis3]]
> 
> Based on this, can we agree, that the sentence "Either an e line or p
line
> MUST be
> present." in Section B.2 should be removed, and hence there's no need
to
> mention
> "e" and "p" in the next sentence ?
> 
> -- Flemming
> 
> 
> 
> Colin Perkins wrote:
> 
> > It seems that any mandatory use of p= or e= is a hang over from the
> > original use of SDP with SAP. I don't see that it necessarily makes
> > sense with many current uses of SDP.
> >
> > We should clarify this in the revision of SDP, does someone want to
> > suggest wording changes to the draft?
> > Colin
> >
> > --> Rajesh Kumar writes:
> > >rfc2327  annotates them with a "*" and further says: Optional items
are
> > >marked with a "*".
> > >
> > >I take this to mean that these are optional. When using it in the
> context
> > >of SIP, this convention should be followed. Further, I believe this
> > >convention has been retained in the on-going SDP work, right?
> > >
> > >Rajesh
> > >
> > >At 04:25 PM 6/13/2001 -0400, Flemming Andreasen wrote:
> > >>Can somebody clarify if either an email address ("e=") or phone
number
> > >>("p=") MUST
> > >>be present in SDP. The spec doesn't seem entirely clear on this.
> > >>
> > >>
> > >>Thanks
> > >>
> > >>         Flemming
> > >>
> > >>
> > >>Anders Kristensen wrote:
> > >>
> > >> > They're optional in the grammar, but the accompanying text
seems
> > >> > perfectly clear that one or the other must be present.
Sometimes
> it's
> > >> > more convenient to state requirements in english than BNF -
doesn't
> mean
> > >> > it's not part of the spec. I'm pretty sure that the quoted
sentence
> is
> > >> > the only reason it's required for SIP.
> > >> >
> > >> > Anders
> > >> >
> > >> > Mohsen Soroush-nejad wrote:
> > >> > >
> > >> > > Section 6 of RFC 2327 lists all the SDP fields. The optional
> > >> > > fields are identified by "*". "e" & "p" are identified as
> optional....
> > >> > >
> > >> > > Mohsen
> > >> > > -----Original Message-----
> > >> > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > >> > > Sent: Wednesday, June 13, 2001 12:17 PM
> > >> > > To: Anders Kristensen
> > >> > > Cc: Jonathan Rosenberg; 'Cullen Jennings'; sip@ietf.org
> > >> > > Subject: Re: [Sip] Few tiny issues with SDP section of bis3
> > >> > >
> > >> > > That's far from clear if you read it in the context it was
> provided in.
> > >> > > Also, do
> > >> > > note that both of these fields are in fact listed as optional
> earlier
> > >> in the
> > >> > > spec.
> > >> > >
> > >> > > -- Flemming
> > >> > >
> > >> > > Anders Kristensen wrote:
> > >> > >
> > >> > > > It's required by RFC 2327 (no idea why, though:
> > >> > > >
> > >> > > >    o Either an email field or a phone field must be
specified.
> > >> > > >      Additional email and phone fields are allowed.
> > >> > > >
> > >> > > > Thanks,
> > >> > > > Anders
> > >> > > >
> > >> > > > Flemming Andreasen wrote:
> > >> > > > >
> > >> > > > > Jonathan Rosenberg wrote:
> > >> > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > > -----Original Message-----
> > >> > > > > > > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > >> > > > > > > Sent: Monday, June 11, 2001 3:15 PM
> > >> > > > > > > To: sip@ietf.org
> > >> > > > > > > Subject: [Sip] Few tiny issues with SDP section of
bis3
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > > Examples in section B don't have an e or P line in
the
> SDP
> > >> > > > > > > even though one
> > >> > > > > > > them must be present.
> > >> > > > > >
> > >> > > > > > OK, I fixed that.
> > >> > > > >
> > >> > > > > Speaking of that: Why is there now a requirement in the
SDP
> section
> > >> > > stating
> > >> > > > > that "Either an e line or p line MUST be present." ?
> > >> > > > >
> > >> > > > > -- Flemming
> > >> > > > >
> > >> > > > > --
> > >> > > > > Flemming Andreasen
> > >> > > > > Cisco Systems
> > >> > > > >
> > >> > > > > _______________________________________________
> > >> > > > > Sip mailing list
> > >> > > > > Sip@ietf.org
> > >> > > > > http://www.ietf.org/mailman/listinfo/sip
> > >> > >
> > >> > > --
> > >> > > Flemming Andreasen
> > >> > > Cisco Systems
> > >> > >
> > >> > > _______________________________________________
> > >> > > Sip mailing list
> > >> > > Sip@ietf.org
> > >> > > http://www.ietf.org/mailman/listinfo/sip
> > >>
> > >>--
> > >>Flemming Andreasen
> > >>Cisco Systems
> > >
> > >  Rajesh
> > >--------------------------------------------------------
> > >Rajesh Kumar
> > >Cisco Voice Technology Center
> > >Tel: 408-527-0811, Fax: 408-853-1101
> > >Epage: mailto:rkumar@epage.cisco.com
> > >------------------------------------------------ --------
> > >
> > >
> 
> --
> Flemming Andreasen
> Cisco Systems
> 
> 
> 
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 14 11:06:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01758;
	Thu, 14 Jun 2001 11:06:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13047;
	Thu, 14 Jun 2001 11:00:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13016
	for ; Thu, 14 Jun 2001 11:00:07 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01597
	for ; Thu, 14 Jun 2001 10:59:35 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA00408
	for ; Thu, 14 Jun 2001 11:04:07 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 14 Jun 2001 11:00:06 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'sip@ietf.org'" 
Date: Thu, 14 Jun 2001 11:00:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Open Issue ID#100 - case sensitivity of URL parameter values
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Folks,

The following is an open issue in bis that I would like to discuss. THe
never ending saga of case sensitivity... Here's the problem:

The rules for BNF state:

"literal"
Quotation marks surround literal text. Unless stated otherwise, the text is 
case-insensitive.

And then looking at the SIP URL:

transport-param = "transport="
( "udp" | "tcp" | "sctp" | "tls" | other-transport)

Note how udp, tcp are in quotation marks. This makes them literal text, so
that 
its case insensitive. But, the matching rules say:

Comparisons of scheme name ("sip"), domain names, parameter names and header

names are case-insensitive,
all other comparisons are case-sensitive.


Here, we are talking about a parameter value. This says its case sensitive. 

So, which is it?

Interpretations appear to be mixed. Technically, the correct answer as
written is that they are CS. The reason is that the BNF says that quoted
values are CI *unless stated otherwise*. Well, we did state otherwise.
However, this is a subtletly that is easily missed.

So, we can either stick with whats written, but clarify by explicitly
pointing to the contradiction with the BNF, or be consistent with the BNF
rules, and make it CI. CS is more efficient, CI is more interoperable. I
suspect most people are doing CI for this.

Input?

-Jonathan R.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 14 11:37:27 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02346;
	Thu, 14 Jun 2001 11:37:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14216;
	Thu, 14 Jun 2001 11:29:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14193
	for ; Thu, 14 Jun 2001 11:29:13 -0400 (EDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02077
	for ; Thu, 14 Jun 2001 11:28:41 -0400 (EDT)
Received: from 157.54.9.104 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 14 Jun 2001 08:16:15 -0700 (Pacific Daylight Time)
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Thu, 14 Jun 2001 08:18:28 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Thu, 14 Jun 2001 08:18:22 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Thu, 14 Jun 2001 08:17:01 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of bis3]]
Date: Thu, 14 Jun 2001 08:17:01 -0700
Message-ID: 
Thread-Topic: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of bis3]]
Thread-Index: AcD05IS3k/yLf2LrTrCBjD2ImiH5GgAAGprA
From: "Christian Huitema" 
To: "Anders Kristensen" 
Cc: "Flemming Andreasen" , ,
        "Jonathan Rosenberg" 
X-OriginalArrivalTime: 14 Jun 2001 15:17:01.0863 (UTC) FILETIME=[0FF2C370:01C0F4E5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA14194
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Yes. In fact, we could make a session explaining that SDP was originally
defined for an entirely different purpose, that it is currently being
revised, and that a bunch of fields defined in SDP shall be considered
optional when used with SIP. I bet that this includes essentially all
the fields that are not directly related to specifying addresses, ports
and coding parameters, plus the version field that we use in
"re-invite."

> -----Original Message-----
> From: Anders Kristensen [mailto:akristensen@dynamicsoft.com]
> Sent: Thursday, June 14, 2001 8:14 AM
> To: Christian Huitema
> Cc: Flemming Andreasen; sip@ietf.org; Jonathan Rosenberg
> Subject: Re: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of
bis3]]
> 
> As long as we're sanitizing SDP we might as well make t= optional
also,
> as this doesn't always have a meaning (as phone calls are usually
> synchronous). Also, s= line is now usually given some dummy value and
> should be made optional.
> 
> Anders
> 
> 
> Christian Huitema wrote:
> >
> > Yes. In fact, I would be stronger. I would place a sentence saying
> > explicitly that and SDP text that does not include an "e=" or "p="
line
> > MUST NOT be rejected by SIP implementations.
> >
> > > -----Original Message-----
> > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > Sent: Thursday, June 14, 2001 5:12 AM
> > > To: 'sip@ietf.org'; Jonathan Rosenberg
> > > Subject: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of
bis3]]
> > >
> > > Based on this, can we agree, that the sentence "Either an e line
or p
> > line
> > > MUST be
> > > present." in Section B.2 should be removed, and hence there's no
need
> > to
> > > mention
> > > "e" and "p" in the next sentence ?
> > >
> > > -- Flemming
> > >
> > >
> > >
> > > Colin Perkins wrote:
> > >
> > > > It seems that any mandatory use of p= or e= is a hang over from
the
> > > > original use of SDP with SAP. I don't see that it necessarily
makes
> > > > sense with many current uses of SDP.
> > > >
> > > > We should clarify this in the revision of SDP, does someone want
to
> > > > suggest wording changes to the draft?
> > > > Colin
> > > >
> > > > --> Rajesh Kumar writes:
> > > > >rfc2327  annotates them with a "*" and further says: Optional
items
> > are
> > > > >marked with a "*".
> > > > >
> > > > >I take this to mean that these are optional. When using it in
the
> > > context
> > > > >of SIP, this convention should be followed. Further, I believe
this
> > > > >convention has been retained in the on-going SDP work, right?
> > > > >
> > > > >Rajesh
> > > > >
> > > > >At 04:25 PM 6/13/2001 -0400, Flemming Andreasen wrote:
> > > > >>Can somebody clarify if either an email address ("e=") or
phone
> > number
> > > > >>("p=") MUST
> > > > >>be present in SDP. The spec doesn't seem entirely clear on
this.
> > > > >>
> > > > >>
> > > > >>Thanks
> > > > >>
> > > > >>         Flemming
> > > > >>
> > > > >>
> > > > >>Anders Kristensen wrote:
> > > > >>
> > > > >> > They're optional in the grammar, but the accompanying text
> > seems
> > > > >> > perfectly clear that one or the other must be present.
> > Sometimes
> > > it's
> > > > >> > more convenient to state requirements in english than BNF -
> > doesn't
> > > mean
> > > > >> > it's not part of the spec. I'm pretty sure that the quoted
> > sentence
> > > is
> > > > >> > the only reason it's required for SIP.
> > > > >> >
> > > > >> > Anders
> > > > >> >
> > > > >> > Mohsen Soroush-nejad wrote:
> > > > >> > >
> > > > >> > > Section 6 of RFC 2327 lists all the SDP fields. The
optional
> > > > >> > > fields are identified by "*". "e" & "p" are identified as
> > > optional....
> > > > >> > >
> > > > >> > > Mohsen
> > > > >> > > -----Original Message-----
> > > > >> > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > > >> > > Sent: Wednesday, June 13, 2001 12:17 PM
> > > > >> > > To: Anders Kristensen
> > > > >> > > Cc: Jonathan Rosenberg; 'Cullen Jennings'; sip@ietf.org
> > > > >> > > Subject: Re: [Sip] Few tiny issues with SDP section of
bis3
> > > > >> > >
> > > > >> > > That's far from clear if you read it in the context it
was
> > > provided in.
> > > > >> > > Also, do
> > > > >> > > note that both of these fields are in fact listed as
optional
> > > earlier
> > > > >> in the
> > > > >> > > spec.
> > > > >> > >
> > > > >> > > -- Flemming
> > > > >> > >
> > > > >> > > Anders Kristensen wrote:
> > > > >> > >
> > > > >> > > > It's required by RFC 2327 (no idea why, though:
> > > > >> > > >
> > > > >> > > >    o Either an email field or a phone field must be
> > specified.
> > > > >> > > >      Additional email and phone fields are allowed.
> > > > >> > > >
> > > > >> > > > Thanks,
> > > > >> > > > Anders
> > > > >> > > >
> > > > >> > > > Flemming Andreasen wrote:
> > > > >> > > > >
> > > > >> > > > > Jonathan Rosenberg wrote:
> > > > >> > > > >
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > > -----Original Message-----
> > > > >> > > > > > > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > > > >> > > > > > > Sent: Monday, June 11, 2001 3:15 PM
> > > > >> > > > > > > To: sip@ietf.org
> > > > >> > > > > > > Subject: [Sip] Few tiny issues with SDP section
of
> > bis3
> > > > >> > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > > > Examples in section B don't have an e or P line
in
> > the
> > > SDP
> > > > >> > > > > > > even though one
> > > > >> > > > > > > them must be present.
> > > > >> > > > > >
> > > > >> > > > > > OK, I fixed that.
> > > > >> > > > >
> > > > >> > > > > Speaking of that: Why is there now a requirement in
the
> > SDP
> > > section
> > > > >> > > stating
> > > > >> > > > > that "Either an e line or p line MUST be present." ?
> > > > >> > > > >
> > > > >> > > > > -- Flemming
> > > > >> > > > >
> > > > >> > > > > --
> > > > >> > > > > Flemming Andreasen
> > > > >> > > > > Cisco Systems
> > > > >> > > > >
> > > > >> > > > > _______________________________________________
> > > > >> > > > > Sip mailing list
> > > > >> > > > > Sip@ietf.org
> > > > >> > > > > http://www.ietf.org/mailman/listinfo/sip
> > > > >> > >
> > > > >> > > --
> > > > >> > > Flemming Andreasen
> > > > >> > > Cisco Systems
> > > > >> > >
> > > > >> > > _______________________________________________
> > > > >> > > Sip mailing list
> > > > >> > > Sip@ietf.org
> > > > >> > > http://www.ietf.org/mailman/listinfo/sip
> > > > >>
> > > > >>--
> > > > >>Flemming Andreasen
> > > > >>Cisco Systems
> > > > >
> > > > >  Rajesh
> > > > >--------------------------------------------------------
> > > > >Rajesh Kumar
> > > > >Cisco Voice Technology Center
> > > > >Tel: 408-527-0811, Fax: 408-853-1101
> > > > >Epage: mailto:rkumar@epage.cisco.com
> > > > >------------------------------------------------ --------
> > > > >
> > > > >
> > >
> > > --
> > > Flemming Andreasen
> > > Cisco Systems
> > >
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list
> > > Sip@ietf.org
> > > http://www.ietf.org/mailman/listinfo/sip
> >
> > _______________________________________________
> > Sip mailing list
> > Sip@ietf.org
> > http://www.ietf.org/mailman/listinfo/sip

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 14 11:45:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02628;
	Thu, 14 Jun 2001 11:45:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14852;
	Thu, 14 Jun 2001 11:37:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14821
	for ; Thu, 14 Jun 2001 11:37:14 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02298
	for ; Thu, 14 Jun 2001 11:36:38 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5EFaj916691
	for ; Thu, 14 Jun 2001 08:36:45 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f5EFadl18831
	for ; Thu, 14 Jun 2001 08:36:39 -0700 (PDT)
Received: from cisco.com (dhcp-edison-119.cisco.com [171.68.78.119]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id IAA21138 for ; Thu, 14 Jun 2001 08:36:28 -0700 (PDT)
Message-ID: <3B28DA53.D016C60F@cisco.com>
Date: Thu, 14 Jun 2001 11:37:55 -0400
From: Flemming Andreasen 
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "'sip@ietf.org'" 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Allow in provisional responses ?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

2543bis-03 is silent on whether an Allow header can be used in a
provisional response. Can I assume that it means that it can (would e.g.
be good for knowing I can send INFO during call setup), and if not, why
not ?

-- Flemming



--
Flemming Andreasen
Cisco Systems



_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 14 12:00:00 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02967;
	Thu, 14 Jun 2001 11:59:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13719;
	Thu, 14 Jun 2001 11:14:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13690
	for ; Thu, 14 Jun 2001 11:14:26 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01865
	for ; Thu, 14 Jun 2001 11:13:53 -0400 (EDT)
Received: from dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA00653;
	Thu, 14 Jun 2001 11:18:21 -0400 (EDT)
Message-ID: <3B28D4CC.3F0B53D4@dynamicsoft.com>
Date: Thu, 14 Jun 2001 11:14:20 -0400
From: Anders Kristensen 
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema 
CC: Flemming Andreasen , sip@ietf.org,
        Jonathan Rosenberg 
Subject: Re: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of bis3]]
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

As long as we're sanitizing SDP we might as well make t= optional also,
as this doesn't always have a meaning (as phone calls are usually
synchronous). Also, s= line is now usually given some dummy value and
should be made optional.

Anders


Christian Huitema wrote:
> 
> Yes. In fact, I would be stronger. I would place a sentence saying
> explicitly that and SDP text that does not include an "e=" or "p=" line
> MUST NOT be rejected by SIP implementations.
> 
> > -----Original Message-----
> > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > Sent: Thursday, June 14, 2001 5:12 AM
> > To: 'sip@ietf.org'; Jonathan Rosenberg
> > Subject: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of bis3]]
> >
> > Based on this, can we agree, that the sentence "Either an e line or p
> line
> > MUST be
> > present." in Section B.2 should be removed, and hence there's no need
> to
> > mention
> > "e" and "p" in the next sentence ?
> >
> > -- Flemming
> >
> >
> >
> > Colin Perkins wrote:
> >
> > > It seems that any mandatory use of p= or e= is a hang over from the
> > > original use of SDP with SAP. I don't see that it necessarily makes
> > > sense with many current uses of SDP.
> > >
> > > We should clarify this in the revision of SDP, does someone want to
> > > suggest wording changes to the draft?
> > > Colin
> > >
> > > --> Rajesh Kumar writes:
> > > >rfc2327  annotates them with a "*" and further says: Optional items
> are
> > > >marked with a "*".
> > > >
> > > >I take this to mean that these are optional. When using it in the
> > context
> > > >of SIP, this convention should be followed. Further, I believe this
> > > >convention has been retained in the on-going SDP work, right?
> > > >
> > > >Rajesh
> > > >
> > > >At 04:25 PM 6/13/2001 -0400, Flemming Andreasen wrote:
> > > >>Can somebody clarify if either an email address ("e=") or phone
> number
> > > >>("p=") MUST
> > > >>be present in SDP. The spec doesn't seem entirely clear on this.
> > > >>
> > > >>
> > > >>Thanks
> > > >>
> > > >>         Flemming
> > > >>
> > > >>
> > > >>Anders Kristensen wrote:
> > > >>
> > > >> > They're optional in the grammar, but the accompanying text
> seems
> > > >> > perfectly clear that one or the other must be present.
> Sometimes
> > it's
> > > >> > more convenient to state requirements in english than BNF -
> doesn't
> > mean
> > > >> > it's not part of the spec. I'm pretty sure that the quoted
> sentence
> > is
> > > >> > the only reason it's required for SIP.
> > > >> >
> > > >> > Anders
> > > >> >
> > > >> > Mohsen Soroush-nejad wrote:
> > > >> > >
> > > >> > > Section 6 of RFC 2327 lists all the SDP fields. The optional
> > > >> > > fields are identified by "*". "e" & "p" are identified as
> > optional....
> > > >> > >
> > > >> > > Mohsen
> > > >> > > -----Original Message-----
> > > >> > > From: Flemming Andreasen [mailto:fandreas@cisco.com]
> > > >> > > Sent: Wednesday, June 13, 2001 12:17 PM
> > > >> > > To: Anders Kristensen
> > > >> > > Cc: Jonathan Rosenberg; 'Cullen Jennings'; sip@ietf.org
> > > >> > > Subject: Re: [Sip] Few tiny issues with SDP section of bis3
> > > >> > >
> > > >> > > That's far from clear if you read it in the context it was
> > provided in.
> > > >> > > Also, do
> > > >> > > note that both of these fields are in fact listed as optional
> > earlier
> > > >> in the
> > > >> > > spec.
> > > >> > >
> > > >> > > -- Flemming
> > > >> > >
> > > >> > > Anders Kristensen wrote:
> > > >> > >
> > > >> > > > It's required by RFC 2327 (no idea why, though:
> > > >> > > >
> > > >> > > >    o Either an email field or a phone field must be
> specified.
> > > >> > > >      Additional email and phone fields are allowed.
> > > >> > > >
> > > >> > > > Thanks,
> > > >> > > > Anders
> > > >> > > >
> > > >> > > > Flemming Andreasen wrote:
> > > >> > > > >
> > > >> > > > > Jonathan Rosenberg wrote:
> > > >> > > > >
> > > >> > > > > >
> > > >> > > > > >
> > > >> > > > > > > -----Original Message-----
> > > >> > > > > > > From: Cullen Jennings [mailto:fluffy@cisco.com]
> > > >> > > > > > > Sent: Monday, June 11, 2001 3:15 PM
> > > >> > > > > > > To: sip@ietf.org
> > > >> > > > > > > Subject: [Sip] Few tiny issues with SDP section of
> bis3
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > >
> > > >> > > > > > > Examples in section B don't have an e or P line in
> the
> > SDP
> > > >> > > > > > > even though one
> > > >> > > > > > > them must be present.
> > > >> > > > > >
> > > >> > > > > > OK, I fixed that.
> > > >> > > > >
> > > >> > > > > Speaking of that: Why is there now a requirement in the
> SDP
> > section
> > > >> > > stating
> > > >> > > > > that "Either an e line or p line MUST be present." ?
> > > >> > > > >
> > > >> > > > > -- Flemming
> > > >> > > > >
> > > >> > > > > --
> > > >> > > > > Flemming Andreasen
> > > >> > > > > Cisco Systems
> > > >> > > > >
> > > >> > > > > _______________________________________________
> > > >> > > > > Sip mailing list
> > > >> > > > > Sip@ietf.org
> > > >> > > > > http://www.ietf.org/mailman/listinfo/sip
> > > >> > >
> > > >> > > --
> > > >> > > Flemming Andreasen
> > > >> > > Cisco Systems
> > > >> > >
> > > >> > > _______________________________________________
> > > >> > > Sip mailing list
> > > >> > > Sip@ietf.org
> > > >> > > http://www.ietf.org/mailman/listinfo/sip
> > > >>
> > > >>--
> > > >>Flemming Andreasen
> > > >>Cisco Systems
> > > >
> > > >  Rajesh
> > > >--------------------------------------------------------
> > > >Rajesh Kumar
> > > >Cisco Voice Technology Center
> > > >Tel: 408-527-0811, Fax: 408-853-1101
> > > >Epage: mailto:rkumar@epage.cisco.com
> > > >------------------------------------------------ --------
> > > >
> > > >
> >
> > --
> > Flemming Andreasen
> > Cisco Systems
> >
> >
> >
> > _______________________________________________
> > Sip mailing list
> > Sip@ietf.org
> > http://www.ietf.org/mailman/listinfo/sip
> 
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 14 13:27:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04733;
	Thu, 14 Jun 2001 13:27:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18882;
	Thu, 14 Jun 2001 13:23:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18854
	for ; Thu, 14 Jun 2001 13:23:00 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04651
	for ; Thu, 14 Jun 2001 13:22:29 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA02684;
	Thu, 14 Jun 2001 13:26:58 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 14 Jun 2001 13:22:57 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Flemming Andreasen'" ,
        "'sip@ietf.org'"
	 
Subject: RE: [Sip] Allow in provisional responses ?
Date: Thu, 14 Jun 2001 13:22:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]
> Sent: Thursday, June 14, 2001 11:38 AM
> To: 'sip@ietf.org'
> Subject: [Sip] Allow in provisional responses ?
> 
> 
> 2543bis-03 is silent on whether an Allow header can be used in a
> provisional response. Can I assume that it means that it can 
> (would e.g.
> be good for knowing I can send INFO during call setup), and 
> if not, why
> not ?

I think it makes sense, along with Accept and Accept-Encoding, for much the
same reasons. It probably doesn't make much sense in a 1xx to an OPTIONS, or
something that otherwise doesn't create a session.

I'll clarify in the spec.

-Jonathan R.

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


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 14 15:10:07 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07882;
	Thu, 14 Jun 2001 15:10:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22755;
	Thu, 14 Jun 2001 15:05:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22726
	for ; Thu, 14 Jun 2001 15:05:24 -0400 (EDT)
Received: from gatekeeper.calltrol.com (root@[65.105.250.35])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07803
	for ; Thu, 14 Jun 2001 15:04:49 -0400 (EDT)
Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253])
	by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id PAA28934;
	Thu, 14 Jun 2001 15:07:07 -0400
Received: by NT-SERVER with Internet Mail Service (5.5.2448.0)
	id ; Thu, 14 Jun 2001 15:07:29 -0400
Message-ID: <60A9CA50081AD4118BD60040F60C1A9F0A3DBC@NT-SERVER>
From: Wai Wu 
To: "'Jonathan Rosenberg'" ,
        "'sip@ietf.org'"
	 
Subject: RE: [Sip] Open Issue ID#100 - case sensitivity of URL parameter v
	alues
Date: Thu, 14 Jun 2001 15:07:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F505.40FB5D60"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F505.40FB5D60
Content-Type: text/plain;
	charset="iso-8859-1"

It would be nice if we all use CI. However, since I do not know what every
one else is doing, I use CI for comparisions, and send CS messages exactly
as the spec dictates.

Wai

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thursday, June 14, 2001 11:00 AM
To: 'sip@ietf.org'
Subject: [Sip] Open Issue ID#100 - case sensitivity of URL parameter
values


Folks,

The following is an open issue in bis that I would like to discuss. THe
never ending saga of case sensitivity... Here's the problem:

The rules for BNF state:

"literal"
Quotation marks surround literal text. Unless stated otherwise, the text is 
case-insensitive.

And then looking at the SIP URL:

transport-param = "transport="
( "udp" | "tcp" | "sctp" | "tls" | other-transport)

Note how udp, tcp are in quotation marks. This makes them literal text, so
that 
its case insensitive. But, the matching rules say:

Comparisons of scheme name ("sip"), domain names, parameter names and header

names are case-insensitive,
all other comparisons are case-sensitive.


Here, we are talking about a parameter value. This says its case sensitive. 

So, which is it?

Interpretations appear to be mixed. Technically, the correct answer as
written is that they are CS. The reason is that the BNF says that quoted
values are CI *unless stated otherwise*. Well, we did state otherwise.
However, this is a subtletly that is easily missed.

So, we can either stick with whats written, but clarify by explicitly
pointing to the contradiction with the BNF, or be consistent with the BNF
rules, and make it CI. CS is more efficient, CI is more interoperable. I
suspect most people are doing CI for this.

Input?

-Jonathan R.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip

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






RE: [Sip] Open Issue ID#100 - case sensitivity of URL parameter =
values




It would be nice if we all use CI. However, since I =
do not know what every one else is doing, I use CI for comparisions, =
and send CS messages exactly as the spec dictates.



Wai




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

From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent: Thursday, June 14, 2001 11:00 AM

To: 'sip@ietf.org'

Subject: [Sip] Open Issue ID#100 - case sensitivity =
of URL parameter

values






Folks,




The following is an open issue in bis that I would =
like to discuss. THe

never ending saga of case sensitivity... Here's the =
problem:




The rules for BNF state:




"literal"

Quotation marks surround literal text. Unless stated =
otherwise, the text is 

case-insensitive.




And then looking at the SIP URL:




transport-param =3D "transport=3D"

( "udp" | "tcp" | =
"sctp" | "tls" | other-transport)




Note how udp, tcp are in quotation marks. This makes =
them literal text, so

that 

its case insensitive. But, the matching rules =
say:




Comparisons of scheme name ("sip"), domain =
names, parameter names and header




names are case-insensitive,

all other comparisons are case-sensitive.






Here, we are talking about a parameter value. This =
says its case sensitive. 




So, which is it?




Interpretations appear to be mixed. Technically, the =
correct answer as

written is that they are CS. The reason is that the =
BNF says that quoted

values are CI *unless stated otherwise*. Well, we =
did state otherwise.

However, this is a subtletly that is easily =
missed.




So, we can either stick with whats written, but =
clarify by explicitly

pointing to the contradiction with the BNF, or be =
consistent with the BNF

rules, and make it CI. CS is more efficient, CI is =
more interoperable. I

suspect most people are doing CI for this.




Input?




-Jonathan R.




---

Jonathan D. Rosenberg, =
Ph.D.           &=
nbsp;    72 Eagle Rock Ave.

Chief =
Scientist          &nb=
sp;           &nb=
sp;      First Floor

dynamicsoft        &nbs=
p;           &nbs=
p;            =
East Hanover, NJ 07936

jdrosen@dynamicsoft.com     =
            =
    FAX:   (973) 952-5050

http://www.jdrosen.net    &nbs=
p;           &nbs=
p;     PHONE: (973) 952-5000

http://www.dynamicsoft.com

 




_______________________________________________

Sip mailing list

Sip@ietf.org

http://www.ietf.org/mailman/listinfo/sip





------_=_NextPart_001_01C0F505.40FB5D60--

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 14 16:04:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08963;
	Thu, 14 Jun 2001 16:04:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24588;
	Thu, 14 Jun 2001 16:00:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24560
	for ; Thu, 14 Jun 2001 16:00:31 -0400 (EDT)
Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08890
	for ; Thu, 14 Jun 2001 15:59:58 -0400 (EDT)
From: adam.roach@ericsson.com
Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f5EK00R11513;
	Thu, 14 Jun 2001 15:00:00 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f5EJxwH02504;
	Thu, 14 Jun 2001 14:59:58 -0500 (CDT)
Received: from pc050163 (pc050178.exu.ericsson.se [138.85.50.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id OAA25982; Thu, 14 Jun 2001 14:59:58 -0500 (CDT)
Reply-To: 
To: "'Jonathan Rosenberg'" , 
Subject: RE: [Sip] Open Issue ID#100 - case sensitivity of URL parameter values
Date: Thu, 14 Jun 2001 14:59:56 -0500
Message-ID: <61D824C63B99D311975E00508B0CC98502251858@eamrcnt717.exu.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

[On the topic of transport paramters to SIP URIs)

> Interpretations appear to be mixed. Technically, the correct answer as
> written is that they are CS. The reason is that the BNF says 
> that quoted
> values are CI *unless stated otherwise*. Well, we did state otherwise.
> However, this is a subtletly that is easily missed.

I'd argue to keep it as-is: that is, case *sensitive*. Add clarifying
text to the definition of the SIP URL. SIP already has some interesting
performance implications for high-agregation nodes. I'd prefer that
any remaining parsing issues be resolved towards reduction of processing
speed.

Interoperability is still top of my list, though, which is why
I'll ask everyone present: does anyone have an implementation that
sends out transports with uppercase letters?

/a


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 14 16:22:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09208;
	Thu, 14 Jun 2001 16:22:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25008;
	Thu, 14 Jun 2001 16:19:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24971
	for ; Thu, 14 Jun 2001 16:19:57 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09171
	for ; Thu, 14 Jun 2001 16:19:22 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA05438;
	Thu, 14 Jun 2001 16:22:33 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 14 Jun 2001 16:18:32 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Steve Donovan ,
        "'Mary Barnes'"
	 ,
        Jonathan Rosenberg
	 
Cc: Rakesh Shah , "'sip@ietf.org'" ,
        Ben Campbell 
Subject: RE: [SIP] First cut review of Session Timer draft
Date: Thu, 14 Jun 2001 16:18:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Finally I have a chance to get back to session timer....

 

> -----Original Message-----
> From: Steve Donovan [mailto:sdonovan@dynamicsoft.com]
> Sent: Wednesday, May 09, 2001 10:35 AM
> To: 'Mary Barnes'; Steve Donovan; Jonathan Rosenberg
> Cc: Rakesh Shah; 'sip@lists.bell-labs.com'; Ben Campbell
> Subject: RE: [SIP] First cut review of Session Timer draft
> 
> 

> - 2:5 In addition, I would suggest at a minimum to "soften" 
> the endorsement
> of session timer for NAT/Firewall control.  One suggestion would be
> rewording the paragraph to be:
> 
> "Another possible application of the session timer may be in NAT and
> firewall control."  
> 
> In line with this suggestion, I would think since the 
> referenced draft is
> still an ongoing project of the WG that it may not be prudent 
> to include
> this reference in this document going forward.  
> 
> SRD> It will be necessary to do this for the draft to advance 
> to an RFC.

I've updated the spec to not reference this I-D, since it will hinder going
to RFC. Now, it talks generally about NAT ALGs, and how the problem is
flushing of state.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jun 14 17:16:41 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09897
	for ; Thu, 14 Jun 2001 17:16:40 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 33D0A44337; Thu, 14 Jun 2001 17:17:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id B533444336
	for ; Thu, 14 Jun 2001 17:16:59 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA06070;
	Thu, 14 Jun 2001 17:20:54 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 14 Jun 2001 17:16:53 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Steve Donovan ,
        "'Adam Roach (EUS)'" ,
        Ben Campbell 
Cc: Rakesh Shah ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] First cut review of Session Timer draft.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 14 Jun 2001 17:16:48 -0400





> -----Original Message-----
> From: Steve Donovan 
> Sent: Wednesday, May 09, 2001 10:11 AM
> To: 'Adam Roach (EUS)'; Ben Campbell; Steve Donovan; Jonathan 
> Rosenberg
> Cc: Rakesh Shah; 'sip@lists.bell-labs.com'
> Subject: RE: [SIP] First cut review of Session Timer draft.
> 
> 
> > 10:2 - How can a proxy know that it is the closes proxy to 
> > the UAC that 
> > cares about the timer? Except in the trivial case where the 
> > proxy is the 
> > closest to the UAC period, this seems problematic. 
> 
> Because the *first* proxy that cares will *add* a "Session-Expires" 
> header. Other proxies will merely notice (and occasionally 
> adjust) it. So, if you see no "Session-Expires," you're the 
> first node 
> that cares. If you don't, you aren't. 
> 
> A clarification to this effect would probably be useful... 
> 
> SRD> It's already there, in 10:2 - "...For the proxy closest 
> to the UAS, the final response to the \INVITE does not 
> contain a Session-Expires header..."

I've further clarified the text on this subject. It now reads:

When the UAS sends the response, it will not contain a
\header{Session-Expires} or \header{Require} header. This response is
forwarded upstream, and it will eventually arrive at a proxy which
inserted the \header{Session-Expires} header into the request. Because
there is no \header{Session-Expires} or \header{Require} in the
response, the proxy knows it is the first session-timer-aware proxy to
receive the response. This proxy \MUST insert a
\header{Session-Expires} header into the response with the value it
remembered from the forwarded request. The proxy \MUST also
insert the \header{Require} header into the response, with the value
``timer'', before forwarding it upstream. The value of the
\header{Session-Expires} in the forwarded response represents the
expiration time of the session. For other proxies, the response will
already contain the \header{Session-Expires} and \header{Require}
header, so that this cae is indistinguishable from CASE IV.


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

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


From sip-admin@lists.bell-labs.com  Thu Jun 14 22:02:38 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13769
	for ; Thu, 14 Jun 2001 22:02:38 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 00FBE44364; Thu, 14 Jun 2001 22:03:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mip.miptel.com (unknown [210.221.183.2])
	by lists.bell-labs.com (Postfix) with ESMTP id AEE314435E
	for ; Thu, 14 Jun 2001 22:02:03 -0400 (EDT)
Received: from arnold ([210.221.183.24])
	by mip.miptel.com (8.10.1/8.8.7) with SMTP id f5F22J425577
	for ; Fri, 15 Jun 2001 11:02:19 +0900
Message-ID: <000d01c0f609$0b170350$18b7ddd2@arnold>
From: =?ks_c_5601-1987?B?wMzI8byu?= 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000A_01C0F654.7AF0EFB0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Subject: [SIP] If UAc receive Incorect URI  Contact header in 302 Moved message from SIP Redirect Server ...
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 16 Jun 2001 11:07:06 +0900

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C0F654.7AF0EFB0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

SGkgYWxsLg0KDQpJZiBVQWMgcmVjZWl2ZSBJbmNvcmVjdCBVUkkgIENvbnRhY3QgaGVhZGVyIGlu
IDMwMiBNb3ZlZCBtZXNzYWdlIGZyb20gU0lQIFJlZGlyZWN0IFNlcnZlciwNCmhvdyBkb2VzIFVB
YyBkbyA/DQoNCkRvZXMgVUFjIHNlbmQgNDA0IHJlc3BvbnNlIHRvIHRoYXQgcmVkaXJlY3Qgc2Vy
dmVyID8NCg0KQmVzdCBSZWdhcmQNCkFybm9sZC4NCg0K

------=_NextPart_000_000A_01C0F654.7AF0EFB0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz
X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjAwLjMzMTUuMjg3MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpIGFsbC48
L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SWYgVUFj
IHJlY2VpdmUgSW5jb3JlY3QgVVJJJm5ic3A7IENvbnRhY3QgaGVhZGVyIGluIDMwMiBNb3ZlZCAN
Cm1lc3NhZ2UgZnJvbSBTSVAgUmVkaXJlY3QgU2VydmVyLDwvRk9OVD48L0RJVj4NCjxESVY+PEZP
TlQgc2l6ZT0yPmhvdyBkb2VzIFVBYyBkbyA/PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJ
Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPkRvZXMgVUFjIHNlbmQgNDA0IHJlc3BvbnNlIHRvIHRoYXQg
cmVkaXJlY3Qgc2VydmVyIA0KPzwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW
PjxGT05UIHNpemU9Mj5CZXN0IFJlZ2FyZDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y
PkFybm9sZC48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo=

------=_NextPart_000_000A_01C0F654.7AF0EFB0--


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


From sip-admin@lists.bell-labs.com  Fri Jun 15 02:00:37 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20530
	for ; Fri, 15 Jun 2001 02:00:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 45CB844337; Fri, 15 Jun 2001 02:01:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from india.mercurykr.com (unknown [165.133.13.60])
	by lists.bell-labs.com (Postfix) with ESMTP id 128EA44336
	for ; Fri, 15 Jun 2001 02:00:19 -0400 (EDT)
Received: from ashwani (Param [165.133.13.33])
	by india.mercurykr.com (8.8.8+Sun/8.8.8) with SMTP id LAA05166;
	Fri, 15 Jun 2001 11:21:58 -0600 (GMT)
Message-ID: <00b701c0f560$3e581780$210d85a5@dti.daewoo.co.kr>
From: "Ashwani Kumar Kesharwani" 
To: =?ks_c_5601-1987?B?wMzI8byu?= ,
        
References: <000d01c0f609$0b170350$18b7ddd2@arnold>
Subject: Re: [SIP] If UAc receive Incorect URI  Contact header in 302 Moved message from SIP Redirect Server ...
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 15 Jun 2001 11:28:36 +0530
Content-Transfer-Encoding: 8bit

Hi

UAC can't send any response as it is meant for only receiving responses.

What it can do is to discard the addressess returned by redirect server
after it knows they are incorrect.

comments?

Ashwani

----- Original Message -----
From: ÀÌÈñ¼®
To: sip@lists.bell-labs.com
Sent: Saturday, June 16, 2001 7:37 AM
Subject: [SIP] If UAc receive Incorect URI Contact header in 302 Moved
message from SIP Redirect Server ...


Hi all.

If UAc receive Incorect URI  Contact header in 302 Moved message from SIP
Redirect Server,
how does UAc do ?

Does UAc send 404 response to that redirect server ?

Best Regard
Arnold.


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


From sip-admin@ietf.org  Fri Jun 15 11:26:30 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11750;
	Fri, 15 Jun 2001 11:26:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04487;
	Fri, 15 Jun 2001 11:19:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04459
	for ; Fri, 15 Jun 2001 11:19:19 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11574
	for ; Fri, 15 Jun 2001 11:18:46 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5FFItk22519;
	Fri, 15 Jun 2001 08:18:55 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AIM14325;
	Fri, 15 Jun 2001 08:18:46 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA12858; Fri, 15 Jun 2001 08:18:46 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15146.10069.886371.254058@thomasm-u1.cisco.com>
Date: Fri, 15 Jun 2001 08:18:45 -0700 (PDT)
To: Jonathan Rosenberg 
Cc: "'Michael Thomas'" , John.Hearty@level3.com,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Killing hung media streams
In-Reply-To: 
References: 
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg writes:
 > Lets say A and B are in a call, and B is a type of device that if it fails,
 > the call is over. When A detects this, through ICMP errors, it should not
 > bother with a re-INVITE, but rather, consider the call over. On the other
 > hand, if B is a type of device that, if it fails, a simple re-INVITE will
 > allow the call to be recovered at an alternate device (the alternate would
 > be figured out through downstream SRV or other routing approaches), then A
 > should send that re-INVITE immediately.
 > 
 > So, how does A know which to do?
 > 
 > I suppose we could mandate that a re-INVITE is always done, and then, if a
 > 481 is generated, the call is considered terminated. That would generally
 > work, I think, but would often be a waste. I suppose for simplicities sake
 > we could just specify that, although I could have sworn I had come up with a
 > reason you really needed to know....

   Unless there's some other reason, I would think that
   this is just an implementation detail, and up to the
   UA. The reason is that there are probably more reasons
   to do a re-invite than just this. For example, I may
   as a matter of course want my UA to reinvite if it's
   on a flakey network (like, oh say, cellular) to help
   smooth out bumps.

	      Mike

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Fri Jun 15 12:10:44 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13030;
	Fri, 15 Jun 2001 12:10:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06730;
	Fri, 15 Jun 2001 12:07:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06699
	for ; Fri, 15 Jun 2001 12:07:46 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12947
	for ; Fri, 15 Jun 2001 12:07:12 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA03486;
	Fri, 15 Jun 2001 12:11:38 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 15 Jun 2001 12:07:36 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Christer Holmberg'" ,
        Steve Donovan
	 
Cc: brett@broadsoft.com, "'sip@ietf.org'" 
Subject: Session timer response code (was RE: [SIP] Session timer consider
	ed harmful (was RE:   draft-ietf-sip-session- timer: refresh rate))
Date: Fri, 15 Jun 2001 12:07:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Wednesday, May 16, 2001 1:57 AM
> To: Steve Donovan
> Cc: brett@broadsoft.com; sip@lists.bell-labs.com
> Subject: Re: [SIP] Session timer considered harmful (was RE:
> draft-ietf-sip-session- timer: refresh rate)
> 
> 
> >>>Reusing Session-Expires in the 488 is fine, but it
> >>>would potentially cause confusion with the fact
> >>>that currently Session-Expires in a negative response
> >>>will still reset session timer.  [However as I've
> >>>mentioned previously, I wish negative response
> >>>couldn't extend sessions since a proxy could have
> >>>generated the negative response instead of the UAS.]
> >>
> >>[Christer]: I would still vote for a specific 4xx code. It is then
> >>possible to specify specific actions, by nodes supporting the
> >>session-timer, to be taken when it arrives, ie that the
> >>Session-Expires
> >>header would have a special meaning.
> > 
> >This can be achieved by using the combination of the 488 and 
> the presence of
> >a session-expires header.
> 
> True.


I disagree.

We have a whole bunch of scenarios where the response means "sorry, feature
X of the request is not good, please resend with that feature within the
following parameters". Examples include:

401 and Authorization
407 and Proxy-Authorization
405 and method
413 and body
414 and r-uri
420 and Require/Proxy-Require
415 and body type

In all cases, there is a specific response code, that is used to guide the
client about what was wrong, and instruct it about what to resend. This case
is no different. I would therefore propose a new response code, 422 Session
Expiration Too Short, so that we also have:

422 and Session-Expires

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Fri Jun 15 13:26:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17986;
	Fri, 15 Jun 2001 13:26:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09190;
	Fri, 15 Jun 2001 13:17:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09159
	for ; Fri, 15 Jun 2001 13:17:01 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17496
	for ; Fri, 15 Jun 2001 13:16:28 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA04423;
	Fri, 15 Jun 2001 13:20:59 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 15 Jun 2001 13:16:56 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Christer Holmberg'" ,
        "Sean Olson (EUS)" 
Cc: Steve Donovan ,
        "'sip@ietf.org'"
	 
Subject: RE: [SIP] Session timer considered harmful (was RE:  draft-ietf-s
	ip-session- timer: refresh rate)
Date: Fri, 15 Jun 2001 13:16:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Wednesday, May 09, 2001 1:58 AM
> To: Sean Olson (EUS)
> Cc: 'Steve Donovan'; sip@lists.bell-labs.com
> Subject: Re: [SIP] Session timer considered harmful (was RE:
> draft-ietf-sip-session- timer: refresh rate)
> 
> 

> >>3) We add stronger wording in the security section of the
> >>draft describing the smurf attack that Jonathan is worried 
> about.  As part of
> >>the wording, we add the statement that entities supporting 
> session timer
> >>SHOULD support a minimum time of n minutes.  I propose we 
> take Jonathan's
> >>suggestion and make n = 30.  The obvious difference here is 
> that Jonathan's
> >>suggestion becomes a SHOULD instead of a MUST.
> >
> >A recommended value of 30 minutes is fine. Making it a SHOULD seems
> >slightly too strong. Having the 488 response allows a UA to adapt
> >to the networks desire for longer session timers.
> 
> I agree. I would even argue that a recommended specific timer value
> (e.g. 30 minutes) is too "strong", because what data do we 
> have to "back
> up" that value? The proper value is depending on so many 
> things (network
> architecture, transport protocol, number of nodes, network 
> reliability,
> node reliability, network size, distance between nodes etc etc etc etc
> etc), so I would rather describe how the session-timer shall be used,
> and why a relatively high value shall be used ( 30 minutes 
> can be given
> as an EXAMPLE instead of a RECOMMENDATION). This is just a smaill
> detail, though, so we should not spend too much time arguing about it.

OK, I added text discussing this. It now reads:

Small session timer values can be destructive to the network. They
cause excessive messaging traffic that affects both user agents and
proxy servers. Since its primary purpose is to provide a means to time
out state in SIP elements, very small values won't generally be
needed. However, the 30 minute minimum is listed as a {\SHOULD}, and
not a {\MUST}, since the exact value for this number is dependent on
many network factors, including network bandwidths and latencies,
computing power, memory availability, and network topology. At the
time of publication of this document, 30 minutes seems
appropriate. Advances in technologies may result in the number being
excessively large five years hence.

-Jonathan R.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Fri Jun 15 13:28:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18101;
	Fri, 15 Jun 2001 13:28:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09400;
	Fri, 15 Jun 2001 13:23:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09371
	for ; Fri, 15 Jun 2001 13:23:19 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17812
	for ; Fri, 15 Jun 2001 13:22:46 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA04497;
	Fri, 15 Jun 2001 13:27:19 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 15 Jun 2001 13:23:17 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'brett@broadsoft.com'" ,
        Steve Donovan
	 ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Session timer considered harmful (was RE: draft-ietf-si
	p-session- timer: refresh rate)
Date: Fri, 15 Jun 2001 13:23:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Brett Tate [mailto:brett@broadsoft.com]
> Sent: Thursday, May 10, 2001 4:23 PM
> To: 'Steve Donovan'; sip@lists.bell-labs.com
> Subject: RE: [SIP] Session timer considered harmful (was RE:
> draft-ietf-sip-session- timer: refresh rate)
> 
> 
> It might also be beneficial to mention in the draft
> that support of the Session-Expires can lead to 
> more re-INVITE collisions, especially if the 
> Session-Expires value is small.

Done.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Fri Jun 15 14:07:00 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20406;
	Fri, 15 Jun 2001 14:07:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10215;
	Fri, 15 Jun 2001 13:47:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10186
	for ; Fri, 15 Jun 2001 13:47:10 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19171
	for ; Fri, 15 Jun 2001 13:46:37 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA04865;
	Fri, 15 Jun 2001 13:51:08 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 15 Jun 2001 13:47:05 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'brett@broadsoft.com'" ,
        "'sip@ietf.org'"
	 
Subject: RE: [SIP] draft-ietf-sip-session-timer-04.txt Last Call
Date: Fri, 15 Jun 2001 13:47:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Brett Tate [mailto:brett@broadsoft.com]
> Sent: Monday, April 30, 2001 8:31 PM
> To: 'SIPWG Mailing List (E-mail)'
> Subject: RE: [SIP] draft-ietf-sip-session-timer-04.txt Last Call
> 
> 
> General comment/question: 
> 
> Why can Session-Expires and Require "timer" 
> be in negative re-INVITE responses since it 
> is not guaranteed that re-INVITE has gotten 
> to the far end?  Let me know if I missed the 
> sentence that would ensure that a proxy won't
> generate such a response as means to extend
> the session timer.  Was it added as a means 
> for a proxy to help produce a BYE quicker?

This is legacy of an old problem. The problem
was that if a UAC sends a refresh, and the UAS
had since crashed and rebooted, we needed a way
for the UAS to respond to the re-INVITE and say
"sorry, this call is terminated". At the time this
text was inserted, we had not specified that a 481
response to a mid-call request terminates the call.
With that feature added, this legacy text on
Session-Expires in a non-200 response is not needed.
It has been removed.

To avoid a dependency of session timer on bis, I've added
text that says From tags are mandatory when session timer
is implemented. I've also explicitly mentioned that a UAS
should send a 481, and that a UAC MUST consider the call 
destroyed when it receives this. This is exactly what bis
says, but since its now also mandated by this extension
when the extension is used, the dependency is broken. 




> 
> Section 4 last paragraph:
> The Session-Expires immediate and Require 
> "timer" looks like a kludge for UA's 
> that don't add/use tags. 

Excellent observation, and completely correct.

 It seems strange 
> that they are current enough to implement
> timer draft but not current enough to add 
> tags to the To and From.  Note: the proxy 
> should not add the Session-Expires immediate
> and Require "timer" for the UA since the 
> proxy doesn't know the destination UA's 
> reason for the reject.  Please make being 
> able to distinguish a re-INVITE from INVITE 
> a requirement for implementing the draft.

Done.

I've also changed the text in all places so that Session-Expires can only
appear in a 2xx class response.


 
> General comment/question:
> 
> Please mention in the draft that 
> the UAS receiving a re-INVITE SHOULD NOT 
> revive a dead call-leg unless it knows that 
> the associated media session is still 
> active/allocated for that call-leg.

I've added text that says it shouldn't accept a re-INVITE 
for a call that it thinks is terminated unless it is 
explicitly trying to recover lost calls.

> 
> Reasons:
> 1) Helps ensure that the reviver is one 
>    that pays for call if the revived party
>    actually hung up previously.
> 
> 2) Helps ensure that the reviver only pays
>    for call if reviver knows it will be
>    paying for call.
> 
> 3) Only re-alerts the receiver when sender
>    really desires such a thing.

All good reasons.

-Jonathan R.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Fri Jun 15 15:19:48 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24476;
	Fri, 15 Jun 2001 15:19:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13320;
	Fri, 15 Jun 2001 15:16:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13291
	for ; Fri, 15 Jun 2001 15:16:48 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24362
	for ; Fri, 15 Jun 2001 15:16:14 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA01198;
	Fri, 15 Jun 2001 15:16:45 -0400 (EDT)
Message-ID: <3B2A601A.193D182@cs.columbia.edu>
Date: Fri, 15 Jun 2001 15:20:58 -0400
From: Henning Schulzrinne 
Reply-To: hgs@cs.columbia.edu
Organization: Lucent Technologies
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: adam.roach@ericsson.com
CC: "'Jonathan Rosenberg'" , sip@ietf.org
Subject: Re: [Sip] Open Issue ID#100 - case sensitivity of URL parameter values
References: <61D824C63B99D311975E00508B0CC98502251858@eamrcnt717.exu.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Unfortunately, making it CS somewhat contradicts the general rule in Section 6.5
for headers:

"Unless otherwise stated, parameter names, parameter values and tokens
are case-insensitive.  Values expressed as quoted strings are
case-sensitive."

The transport parameter doesn't use quotation marks and is similar to the
various token parameter values, e.g., in Contact the action parameter, or the
Call-Info purpose values, etc.), so that anything but CI would be yet another
special case.

While I sympathize with the efficiency argument, I suspect that the difference
is small between

if (strcmp(*transport, "udp") == 0) {
  t = UDP;
}
else if (strcmp(*transport, "tcp") == 0} {
  t = TCP;
}

for the "fast path" and adding an additional "slow path" 

else if (strcasecmp(*transport, "udp") == 0) {
  t = UDP;
}
etc.

adam.roach@ericsson.com wrote:
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> 
> [On the topic of transport paramters to SIP URIs)
> 
> > Interpretations appear to be mixed. Technically, the correct answer as
> > written is that they are CS. The reason is that the BNF says
> > that quoted
> > values are CI *unless stated otherwise*. Well, we did state otherwise.
> > However, this is a subtletly that is easily missed.
> 
> I'd argue to keep it as-is: that is, case *sensitive*. Add clarifying
> text to the definition of the SIP URL. SIP already has some interesting
> performance implications for high-agregation nodes. I'd prefer that
> any remaining parsing issues be resolved towards reduction of processing
> speed.
> 
> Interoperability is still top of my list, though, which is why
> I'll ask everyone present: does anyone have an implementation that
> sends out transports with uppercase letters?
>

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Fri Jun 15 16:34:25 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28663;
	Fri, 15 Jun 2001 16:34:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15131;
	Fri, 15 Jun 2001 16:19:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15101
	for ; Fri, 15 Jun 2001 16:19:13 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27825
	for ; Fri, 15 Jun 2001 16:18:39 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id AD21FD690150; Fri, 15 Jun 2001 16:16:33 -0400
Message-ID: <003101c0f5d8$6d166860$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: , "'Rich Schaaf'" ,
        
References: <61D824C63B99D311975E00508B0CC98502251846@eamrcnt717.exu.ericsson.se>
Subject: Re: [SIP] DNS SRV and authentication challenges
Date: Fri, 15 Jun 2001 16:19:05 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit




----- Original Message -----
From: 
To: "'Rich Schaaf'" ; 
Sent: Wednesday, June 13, 2001 4:35 PM
Subject: RE: [SIP] DNS SRV and authentication challenges


> > -----Original Message-----
> > From: Rich Schaaf [mailto:rschaaf@pingtel.com]
>
>   [Description of problem deleted. Synopsis: DNS points to
>    two servers with the same q-values; one issues a challenge
>    and the other receives the response]
>
> > So, if my reading of the spec is correct, the SIP client is behaving
> > correctly.  The SIP proxy behavior and DNS configuration also seem
> > reasonable.  However, the end result is that the call fails to get set
> > up.
> >
> > Please let me know if my reasoning is correct and I welcome any
> > suggestions on what _should_ happen in this situation.
>
> I would contend that, in these cirucumstances, you would
> need to have some sort of coordination between these
> "equivalent" nodes. They can share a back-end database
> or a deterministic algorithm for generating challenges
> based on, say, a synchronized clock.
>

I think it is just as reasonable to allow (or maybe require) the client to
send the INVITE with authentication to the same network address as the
initially rejected request. It seems clear to me that the intention of the
referenced text (section 1.4.2 I believe) was to ensure that any request
that required state in the "next-hop" server created by a recent prior
request is sent to the same SIP server. Although technically, it is a new
transaction, it is still the same "transaction" (placing a call) from the
user's point of view.

In either case, we may want to add text to cover this scenario.

(-:bob

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


> (I'm not a security expert, so you might want to run
> the second idea past someone who has a better idea of
> what the implications of a deterministic challenge
> algorithm might be if you intend to use it).
>
> /a
>
>
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip
>


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Fri Jun 15 17:26:29 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29909;
	Fri, 15 Jun 2001 17:26:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15971;
	Fri, 15 Jun 2001 16:37:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15940
	for ; Fri, 15 Jun 2001 16:37:15 -0400 (EDT)
Received: from mail.net2phone.com (mail.net2phone.com [216.53.3.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28794
	for ; Fri, 15 Jun 2001 16:36:41 -0400 (EDT)
Received: from mailsvr.net2phone.com (exchange.net2phone.com [216.53.60.1])
	by mail.net2phone.com (8.9.3/8.9.3) with ESMTP id QAA28258
	for ; Fri, 15 Jun 2001 16:32:15 -0400 (EDT)
Received: by mailsvr.net2phone.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 15 Jun 2001 16:37:14 -0400
Message-ID: <6F46FABB90ABD411BD690002B3152FB9260330@lkwmail01.net2phone.com>
From: Romel Khan 
To: "'sip@ietf.org'" 
Date: Fri, 15 Jun 2001 16:31:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] II digit & Calling Name
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Is there a way to pass the II digit (a.k.a. originating line info, such as,
hotel/motel/prison/coin) over SIP? 
Is there a way to pass Calling Name over SIP?

Thanks.

Romel Khan
Ph: (732)-363-0213, x241


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Fri Jun 15 17:55:45 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00393;
	Fri, 15 Jun 2001 17:55:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17232;
	Fri, 15 Jun 2001 17:25:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17204
	for ; Fri, 15 Jun 2001 17:25:23 -0400 (EDT)
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29889
	for ; Fri, 15 Jun 2001 17:24:49 -0400 (EDT)
Received: from plate (localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f5FLQVt06977;
	Fri, 15 Jun 2001 16:26:32 -0500
Message-ID: <013601c0f5e1$78dd7540$c6b954c3@adlon.se>
From: "Dean Willis" 
To: "Romel Khan" , 
References: <6F46FABB90ABD411BD690002B3152FB9260330@lkwmail01.net2phone.com>
Subject: Re: [Sip] II digit & Calling Name
Date: Fri, 15 Jun 2001 16:23:46 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Something relevant might be contained in the Privacy draft - see:

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-02.txt

which as  I recall is due for last call, meaning we NEED TO READ AND DISCUSS
THIS DRAFT!

--
Dean

----- Original Message -----
From: "Romel Khan" 
To: 
Sent: Friday, June 15, 2001 3:31 PM
Subject: [Sip] II digit & Calling Name


> Is there a way to pass the II digit (a.k.a. originating line info, such
as,
> hotel/motel/prison/coin) over SIP?
> Is there a way to pass Calling Name over SIP?
>
> Thanks.
>
> Romel Khan
> Ph: (732)-363-0213, x241
>
>
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip
>


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Sat Jun 16 01:48:09 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09208;
	Sat, 16 Jun 2001 01:48:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06628;
	Sat, 16 Jun 2001 01:44:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA06595
	for ; Sat, 16 Jun 2001 01:44:16 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09027
	for ; Sat, 16 Jun 2001 01:43:44 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA09258;
	Sat, 16 Jun 2001 01:48:16 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Sat, 16 Jun 2001 01:44:14 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'adam.roach@ericsson.com'" ,
        Jonathan Rosenberg ,
        Steve Donovan
	 
Cc: brett@broadsoft.com, sip@ietf.org
Subject: RE: Session timer response code (was RE: [SIP] Session timer cons
	ider ed harmful (was RE:   draft-ietf-sip-session- timer: refresh rate))
Date: Sat, 16 Jun 2001 01:44:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
> Sent: Friday, June 15, 2001 3:22 PM
> To: 'Jonathan Rosenberg'; Steve Donovan
> Cc: brett@broadsoft.com; sip@ietf.org
> Subject: RE: Session timer response code (was RE: [SIP] Session timer
> consider ed harmful (was RE: draft-ietf-sip-session- timer: refresh
> rate))
> 
> 
> In all cases, there is a specific response code, that is used 
> > to guide the
> > client about what was wrong, and instruct it about what to 
> > resend. This case
> > is no different. I would therefore propose a new response 
> > code, 422 Session
> > Expiration Too Short, so that we also have:
> > 
> > 422 and Session-Expires
> 
> Alright... if we need this, don't we also need the same (or a similar)
> mechanism to indicate the same thing for "Expires" in a registration?

No, since there is no reason for the registrar to refuse the request. It
simply sets the expiration to whatever it wants, and returns it in the 200
OK. The problem is simpler because there are only two elements involved.
Session timer has a whole lot more, and so more complex coordination is
needed.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Sat Jun 16 02:37:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19556;
	Sat, 16 Jun 2001 02:37:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07734;
	Sat, 16 Jun 2001 02:34:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07705
	for ; Sat, 16 Jun 2001 02:34:22 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19247
	for ; Sat, 16 Jun 2001 02:33:47 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA09396;
	Sat, 16 Jun 2001 02:38:15 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Sat, 16 Jun 2001 02:34:12 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Bob Penfield'" , adam.roach@ericsson.com,
        "'Rich Schaaf'" , sip@ietf.org
Subject: RE: [SIP] DNS SRV and authentication challenges
Date: Sat, 16 Jun 2001 02:34:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> Sent: Friday, June 15, 2001 4:19 PM
> To: adam.roach@ericsson.com; 'Rich Schaaf'; sip@ietf.org
> Subject: Re: [SIP] DNS SRV and authentication challenges
> 
> 
> > > So, if my reading of the spec is correct, the SIP client 
> is behaving
> > > correctly.  The SIP proxy behavior and DNS configuration also seem
> > > reasonable.  However, the end result is that the call 
> fails to get set
> > > up.
> > >
> > > Please let me know if my reasoning is correct and I welcome any
> > > suggestions on what _should_ happen in this situation.
> >
> > I would contend that, in these cirucumstances, you would
> > need to have some sort of coordination between these
> > "equivalent" nodes. They can share a back-end database
> > or a deterministic algorithm for generating challenges
> > based on, say, a synchronized clock.
> >
> 
> I think it is just as reasonable to allow (or maybe require) 
> the client to
> send the INVITE with authentication to the same network address as the
> initially rejected request. It seems clear to me that the 
> intention of the
> referenced text (section 1.4.2 I believe) was to ensure that 
> any request
> that required state in the "next-hop" server created by a recent prior
> request is sent to the same SIP server. Although technically, 
> it is a new
> transaction, it is still the same "transaction" (placing a 
> call) from the
> user's point of view.

I strongly disagree.

One of the nice things about the current SRV mechanism is that its nicely
layered. To properly implement it, I don't need to know the conditions under
which the transaction is being initiated. If, all of a sudden, I need to
know call level or header-level semantics in order to do the right thing
with SRV, we get a code nightmare. Therefore, requiring that the request for
the INVITE after a challenge result in the same SRV decision as the previous
INVITE is a big mistake, IMHO.

The real problem is this:
>      The SIP client sends a new INVITE request that includes
>      proxy authorization information.  Since this is a new
>      transaction, a DNS SRV lookup is performed by the SIP client
>      (which returns HostB) and the request is sent to the SIP
>      proxy at HostB.
> 
>      The SIP proxy at HostB is not the proxy that issued the challenge
>      to the SIP client so it sends back a "403 Non-Trusted Caller"
>      response and the call fails.

There are at least two things wrong with this proxy. First, and foremost,
since both proxies are the result of lookups for the given domain, they
should be equivalent, in the sense that both have access to the users
username and password, and both are similarly configured. The idea with SRV
is to provide load balancing and failure recovery across a set of
homogeneous servers for a specific domain. This means that when the new
INVITE arrives with credentials, they should be valid at this proxy as well.
The nonce computation will be identical in this proxy, if it follows the
recommended mechanisms in rfc2617 and the two proxies have synced time
(which you want for other reasons).

The second problem is the 403. Why on earth would the proxy send this? The
digest and basic authentication mechanisms are stateless. That is, the
treatment of a request with an invalid Proxy-Authorization header is
identical to the case where no Proxy-Authorization header is present. As a
result of this, the proxy does not need to remember that it issued the
challenge, in order to process the response in the next INVITE. If you have
a proxy which creates state when it issues the challenges, and uses this for
the next INVITE, well, time to throw that one out and buy a good one. This
proxy is easily the subject of a massive DoS attack, since it creates state
for unauthorized requests.

So, in the worst case, the second proxy uses a different set of
configuration params, and is not time-synchronized with the first. What
happens here? This second proxy should have sent a 401, with its own realm
and its own nonce. The UAC generates credentials for this challenge as well,
and in the third INVITE, includes both sets of credentials. It hits one of
the two servers, and since the request has credentials valid at both, it
works just dandy.

In a properly configured network with good proxies, the second transaction
would succeed at the second proxy.

-Jonathan R.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Sat Jun 16 03:02:05 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21136;
	Sat, 16 Jun 2001 03:02:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08185;
	Sat, 16 Jun 2001 02:57:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08098
	for ; Sat, 16 Jun 2001 02:57:10 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20770
	for ; Sat, 16 Jun 2001 02:56:36 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA09409;
	Sat, 16 Jun 2001 02:49:48 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Sat, 16 Jun 2001 02:45:46 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Michael Thomas'" ,
        Jonathan Rosenberg
	 
Cc: John.Hearty@level3.com, "'sip@ietf.org'" 
Subject: RE: [SIP] Killing hung media streams
Date: Sat, 16 Jun 2001 02:45:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Friday, June 15, 2001 11:19 AM
> To: Jonathan Rosenberg
> Cc: 'Michael Thomas'; John.Hearty@Level3.com; 'sip@ietf.org'
> Subject: RE: [SIP] Killing hung media streams
> 
> 
> Jonathan Rosenberg writes:
>  > Lets say A and B are in a call, and B is a type of device 
> that if it fails,
>  > the call is over. When A detects this, through ICMP 
> errors, it should not
>  > bother with a re-INVITE, but rather, consider the call 
> over. On the other
>  > hand, if B is a type of device that, if it fails, a simple 
> re-INVITE will
>  > allow the call to be recovered at an alternate device (the 
> alternate would
>  > be figured out through downstream SRV or other routing 
> approaches), then A
>  > should send that re-INVITE immediately.
>  > 
>  > So, how does A know which to do?
>  > 
>  > I suppose we could mandate that a re-INVITE is always 
> done, and then, if a
>  > 481 is generated, the call is considered terminated. That 
> would generally
>  > work, I think, but would often be a waste. I suppose for 
> simplicities sake
>  > we could just specify that, although I could have sworn I 
> had come up with a
>  > reason you really needed to know....
> 
>    Unless there's some other reason, I would think that
>    this is just an implementation detail, and up to the
>    UA. The reason is that there are probably more reasons
>    to do a re-invite than just this. For example, I may
>    as a matter of course want my UA to reinvite if it's
>    on a flakey network (like, oh say, cellular) to help
>    smooth out bumps.

Things are implementation details when the result has no impact on other
systems. That doesn't seem to be the case here. Lets say I build a
conferencing server, and if it crashes, I can recover state by having the
far side send a re-INVITE to rebuild the call legs at a backup. Now, the
implementation detail at the far end dictates the service offered overall.
The conferencing server wants to tell the other side that a re-INVITE on
ICMP is the right thing to do.

Here is a third thing one might do upon an ICMP error - send a BYE. I can
construct cases where you really, REALLY want this. Specifically, third
party call control. Consider the case of a controller in a call with A and
B. A dies. A stops sending media. B detects this. B considers its call
terminated, but sends no messages. Now, A and B have destroyed call state,
but the controller is left hanging. The controller would prefer to get a BYE
in these cases. 

So, we have three things one might do upon detecting a failed media stream:

1. re-INVITE
2. send BYE
3. do nothing and consider the call down

My argument is that the right thing depends on the entity at the other end
of the call. To me, this means some kind of signaling is desirable to
communicate which mode is preferred. Of course, it can be refused or not
obeyed, but in the cooperating or non-conflicting cases, I'd like to be able
to do the right thing.

-Jonathan R.


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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Sat Jun 16 03:02:13 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21151;
	Sat, 16 Jun 2001 03:02:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07176;
	Sat, 16 Jun 2001 02:12:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07147
	for ; Sat, 16 Jun 2001 02:12:21 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17877
	for ; Sat, 16 Jun 2001 02:11:49 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA09321;
	Sat, 16 Jun 2001 02:16:21 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Sat, 16 Jun 2001 02:12:19 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Dean Willis'" ,
        Romel Khan
	 , sip@ietf.org
Subject: RE: [Sip] II digit & Calling Name
Date: Sat, 16 Jun 2001 02:12:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Friday, June 15, 2001 5:24 PM
> To: Romel Khan; sip@ietf.org
> Subject: Re: [Sip] II digit & Calling Name
> 
> 
> 
> Something relevant might be contained in the Privacy draft - see:
> 
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-02.txt

Its also worth noting that the caller prefernces extension defines Contact
parameters that can describe the endpoint making or answering the call. Some
folks had expressed an interest in registering some Contact params for
things like payphone and prison phone, once the spec went to RFC.

The privacy draft, to some degree, is inconsistent with the caller
preferences spec in this regard. For example, one of the rpi-id-types is
"return", which is more like the Contact, in that its a "device" address,
not a user identity.

One might also argue that, if you want to allow the network to provide and
validate a user identity, then you might want the network to provide and
validate a device identity (i.e., the Contact). This would argue for the
equivalent of remote-party-id for Contact. To be honest, I never understood
why we didn't have the header called Auth-From, and now we might want to
think about Auth-Contact.....

-Jonathan R.

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


> ----- Original Message -----
> From: "Romel Khan" 
> To: 
> Sent: Friday, June 15, 2001 3:31 PM
> Subject: [Sip] II digit & Calling Name
> 
> 
> > Is there a way to pass the II digit (a.k.a. originating 
> line info, such
> as,
> > hotel/motel/prison/coin) over SIP?
> > Is there a way to pass Calling Name over SIP?
> >
> > Thanks.
> >
> > Romel Khan
> > Ph: (732)-363-0213, x241
> >
> >
> > _______________________________________________
> > Sip mailing list
> > Sip@ietf.org
> > http://www.ietf.org/mailman/listinfo/sip
> >
> 
> 
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip
> 

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Sat Jun 16 04:09:27 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22266;
	Sat, 16 Jun 2001 04:09:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09106;
	Sat, 16 Jun 2001 03:22:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09075
	for ; Sat, 16 Jun 2001 03:22:52 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22048
	for ; Sat, 16 Jun 2001 03:22:19 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA09496
	for ; Sat, 16 Jun 2001 03:26:53 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Sat, 16 Jun 2001 03:22:51 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'sip@ietf.org'" 
Date: Sat, 16 Jun 2001 03:22:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] new open issue in session timer: NEEDS resolution now!
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Folks,

Whilst writing up a discussion of the smurf attack for the session-timer
spec, I ran into a problem.

We added the ability for a proxy to reject a request if the session timer
was too low. Consider the case of a UAC A, two proxies B and C, and UAS D. A
sends an INVITE, with Supported: timer. It lists a value of 1 hour. This
hits proxy B. B feels this is too long, and wants the 30 minute minimum. So,
it reduces it. That hits C. C feels this is too short, below its 45 minute
minimum. So, it rejects the request, and includes a session-expires header
with 45 minutes. 

So, A resends the request, with a session-expires of 45 minutes. This, once
again, is too short for B, which reduces it to 30 minutes, and passes it to
C. C rejects it because its too long, and includes a session-expires header
with 45 minutes.

This will then continue ad-infinitum. Its also a nice DoS attack in and of
itself.

Dean raised this issue a while back. I had suggested the ability of a proxy
to increase the session-expires, and then include a header, say
Minimum-Timer, which indicates its minimum value that no one else can reduce
it below. He pointed out that you have problems, then, if two proxies have
non-overlapping preferences. Well, we still have that problem. The result of
the 422 rejection response is that proxies can, effectively, increase the
value of the session timer, so the same problem arises.

The only sensible out that I see is to add back this Minimum-Timer header. A
UAC, when it gets a 422 Session Timer too small, remembers the value of the
Session-Expires in that response. It stores the largest value returned in
any 422 for the call leg in question. In any re-invites with session timers,
the UAC includes a Minimum-Timer header with this value. A proxy MUSTNOT
reduce the session timer below this value. 

I welcome any other suggestions....

Another requirement for this to work is that, when a UA refreshes, it
inserts a session-expres with the same timer as the previous successful
re-INVITE, unless it explicitly wishes to disable session timers. Without
that, the smurf attack is still possible! Thats because, if each re-invite
doesn't contain the last session timer, no request will actually ever
contain a session-expires, and so there is no opportunity for a proxy in
front of the attacking proxy to reject the low values inserted by the
attacking proxy!

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Sat Jun 16 08:53:51 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23832;
	Sat, 16 Jun 2001 08:53:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14776;
	Sat, 16 Jun 2001 08:51:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14747
	for ; Sat, 16 Jun 2001 08:51:08 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23779
	for ; Sat, 16 Jun 2001 08:50:35 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id IAA09861
	for ; Sat, 16 Jun 2001 08:55:05 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Sat, 16 Jun 2001 08:51:03 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'sip@ietf.org'" 
Date: Sat, 16 Jun 2001 08:51:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Request header integrity in HTTP Digest
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Folks,

I've just submitted a new I-D to the archives. It proposes a mechanism that
allows HTTP Digest to provide request header integrity. This means that the
server can verify that the request was sent by a specific party, and that
certain header fields, such as the To, From, Contact, and Call-ID, were not
altered.

Amazingly, the proposal requires no protocol changes in the way HTTP Digest
works, nor does it require any change in the behavior of clients. It is
purely a server implementation choice. I call the proposed approach
"predictive nonces", as its based on a computation of the nonce based on a
prediction of the values of specific invariant headers in the resubmitted
request (namely, that they are unchanged from the original request that is
being challenged). It also works for HTTP, but is less useful there. The
approach is totally stateless as well, unlike one time nonces, which are
not.

Until the draft appears in the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-sip-http-pnonce-00.txt

I think this will address some important security concerns raised on the
list, many of which are summarized in the draft.

Comments, questions, and criticisms welcome as always.

Thanks,
Jonathan R.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Sat Jun 16 10:22:42 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24361;
	Sat, 16 Jun 2001 10:22:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16200;
	Sat, 16 Jun 2001 10:19:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16170
	for ; Sat, 16 Jun 2001 10:19:48 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24332
	for ; Sat, 16 Jun 2001 10:19:15 -0400 (EDT)
Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA00770;
	Sat, 16 Jun 2001 10:18:37 -0400 (EDT)
Message-ID: <3B2B6ABD.8B02BB2F@cs.columbia.edu>
Date: Sat, 16 Jun 2001 10:18:37 -0400
From: "Henning G. Schulzrinne" 
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-2cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Dean Willis'" ,
        Romel Khan , sip@ietf.org
Subject: Re: [Sip] II digit & Calling Name
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


> The privacy draft, to some degree, is inconsistent with the caller
> preferences spec in this regard. For example, one of the rpi-id-types is
> "return", which is more like the Contact, in that its a "device" address,
> not a user identity.

My interpretation was that this was more of a logical address rather
than a device address, similar to the 'reply-to' header in email. For
example, you could imagine that you want all future calls (not
transactions within the call) to sales critter S to always go to
sales@example.com. (Or the example given in the spec, of providing an
800# for return calls in outgoing calls.)

If this difference is indeed correct, I believe it would be helpful if
the authors could clarify the call vs. transactions-within-call
distinction.

> 
> One might also argue that, if you want to allow the network to provide and
> validate a user identity, then you might want the network to provide and
> validate a device identity (i.e., the Contact). This would argue for the
> equivalent of remote-party-id for Contact. To be honest, I never understood
> why we didn't have the header called Auth-From, and now we might want to
> think about Auth-Contact.....
> 

It seems pretty clear that the privacy draft makes rather traditional
assumptions about the network architecture, for example, that the entity
doing the identity checking is implied and requires no identification.
However, without cryptographic authentication of the verifier, it's not
clear how useful this whole scheme is outside tightly constrained
network architectures and rather old-fashioned trust relationships.


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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jun 18 05:21:37 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02391
	for ; Mon, 18 Jun 2001 05:21:37 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A022344337; Mon, 18 Jun 2001 05:22:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153])
	by lists.bell-labs.com (Postfix) with ESMTP id 1ACE044336
	for ; Mon, 18 Jun 2001 05:21:37 -0400 (EDT)
Received: from frmta003.netfr.alcatel.fr (frmta003.netfr.alcatel.fr [155.132.251.32])
        by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id LAA19373
        for ; Mon, 18 Jun 2001 11:21:53 +0200 (MET DST)
Received: by frmta003.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id C1256A6F.0033889A ; Mon, 18 Jun 2001 11:22:53 +0200
X-Lotus-FromDomain: ALCATEL
From: Pierre.Lacour@alcatel.fr
To: sip@lists.bell-labs.com
Message-ID: 
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] Search for a draft
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 18 Jun 2001 11:21:00 +0200



Hello,
  I am searching for the following document :
  J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application
   server component architecture for sip," Internet Draft, Internet
   Engineering Task Force, Nov. 2000.

  I am searching for recommendations and Call flows about media servers and Third Party Call Control, it is why I found the previous reference into the draft-rosenberg-sip-3pcc-02.txt, but I don't find it.

  Please,   someone can tell me where I can find this draft ?

  Thank You,

  Pierre




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


From sip-admin@ietf.org  Mon Jun 18 07:04:44 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03001;
	Mon, 18 Jun 2001 07:04:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24796;
	Mon, 18 Jun 2001 06:53:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24766
	for ; Mon, 18 Jun 2001 06:53:37 -0400 (EDT)
Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02940
	for ; Mon, 18 Jun 2001 06:53:06 -0400 (EDT)
Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca
          via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 18 Jun 2001 11:53:26 UT
Received: (private information removed)
Message-ID: <3B2DDDB1.A54AECC8@ubiquity.net>
From: James Undery 
To: Jonathan Rosenberg 
Cc: "'sip@ietf.org'" 
Subject: Re: [Sip] Request header integrity in HTTP Digest
Date: Mon, 18 Jun 2001 06:53:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



Jonathan Rosenberg wrote:

> Folks,
>
> I've just submitted a new I-D to the archives. It proposes a mechanism
that
> allows HTTP Digest to provide request header integrity. This means that
the
> server can verify that the request was sent by a specific party, and that
> certain header fields, such as the To, From, Contact, and Call-ID, were
not
> altered.
>
> Amazingly, the proposal requires no protocol changes in the way HTTP
Digest
> works, nor does it require any change in the behavior of clients. It is
> purely a server implementation choice. I call the proposed approach
> "predictive nonces", as its based on a computation of the nonce based on a
> prediction of the values of specific invariant headers in the resubmitted
> request (namely, that they are unchanged from the original request that is
> being challenged). It also works for HTTP, but is less useful there. The
> approach is totally stateless as well, unlike one time nonces, which are
> not.
>
> Until the draft appears in the archives, you can pick up a copy at:
>
> http://www.jdrosen.net/papers/draft-rosenberg-sip-http-pnonce-00.txt
>
> I think this will address some important security concerns raised on the
> list, many of which are summarized in the draft.
>
> Comments, questions, and criticisms welcome as always.

There is a large and obvious flaw, this mechanism provides NO protection
against sophisticated man in the middle attacks. If the man in the middle
alters the first request and passes back the pnonce to the user who
authenticates it, when the man in the middle alters the second request it is
perfectly acceptable to the registrar. The backwards compatibility is
exactly
the thing that breaks this attempted solution.

On the subject of man in the middle attacks being to hard to launch, I'd
direct
you to the recent problems of SourceForge.net and Apache.org where an ISP
was
compromised leading to break ins on both these sites through man in the
middle
attacks.

James Undery



_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Mon Jun 18 07:06:21 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03016;
	Mon, 18 Jun 2001 07:06:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24700;
	Mon, 18 Jun 2001 06:50:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24671
	for ; Mon, 18 Jun 2001 06:50:45 -0400 (EDT)
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02926
	for ; Mon, 18 Jun 2001 06:50:10 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 18 Jun 2001 03:50:16 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Jonathan Rosenberg'" 
Cc: "'sip@ietf.org'" 
Subject: RE: [SIP] Killing hung media streams
Date: Mon, 18 Jun 2001 03:50:12 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F7E4.7386C470"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F7E4.7386C470
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Jonathan,

Do we really need to negotiate another signaling parameter ?

Would not sending a re-INVITE eventually have the same effect as sending a
BYE (ie, causes no harm in any case and hopefully better in some)? If the
third party call controller receives a re-invite, it may or may not bother
to send its own re-INVITE to the other endpoint, right? However the third
party controller and remaining endpoint's call state will remain in-sync. If
media transport is not reestablished then the caller will eventually hangup
and the session will be BYE'd properly; otherwise the proxy/3pc/remote-UA
will take some action to restore media transport and the session can
continue. Am I missing something in your 3pc example ?
In any case, I would have thought that you should never just tear down an
established SIP session without attempting to send a BYE simply because
there are problems in a media stream. Is this not a violation of SIP ?

Rather than signaling what is the preferred action perhaps it would be
better that the re-INVITE indicated the actual error condition (ie, ICMP
errors were encountered on the media streams)? A re-INVITE with a Warning
header seems the most appropriate and transparent approach to me. Now the
3pc or proxy really knows what is going on and can make an proper, informed
decision rather than trying to "control" the UA into taking the action on
its behalf.

Regards.

Robert.

-----Original Message-----
From:	Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent:	Saturday, June 16, 2001 7:46 AM
To:	'Michael Thomas'; Jonathan Rosenberg
Cc:	John.Hearty@level3.com; 'sip@ietf.org'
Subject:	RE: [SIP] Killing hung media streams


Here is a third thing one might do upon an ICMP error - send a BYE. I can
construct cases where you really, REALLY want this. Specifically, third
party call control. Consider the case of a controller in a call with A and
B. A dies. A stops sending media. B detects this. B considers its call
terminated, but sends no messages. Now, A and B have destroyed call state,
but the controller is left hanging. The controller would prefer to get a BYE
in these cases. 

So, we have three things one might do upon detecting a failed media stream:

1. re-INVITE
2. send BYE
3. do nothing and consider the call down

My argument is that the right thing depends on the entity at the other end
of the call. To me, this means some kind of signaling is desirable to
communicate which mode is preferred. Of course, it can be refused or not
obeyed, but in the cooperating or non-conflicting cases, I'd like to be able
to do the right thing.

-Jonathan R.




------_=_NextPart_001_01C0F7E4.7386C470
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Killing hung media streams




Hi Jonathan,




Do we really need to negotiate another =
signaling parameter ?




Would not sending a re-INVITE =
eventually have the same effect as sending a BYE (ie, causes no harm in =
any case and hopefully better in some)? If the third party call =
controller receives a re-invite, it may or may not bother to send its =
own re-INVITE to the other endpoint, right? However the third party =
controller and remaining endpoint's call state will remain in-sync. If =
media transport is not reestablished then the caller will eventually =
hangup and the session will be BYE'd properly; otherwise the =
proxy/3pc/remote-UA will take some action to restore media transport =
and the session can continue. Am I missing something in your 3pc =
example ?



In any case, I would have thought that =
you should never just tear =
down an established SIP session without attempting to send a BYE simply =
because there are problems in a media stream. Is this not a violation =
of SIP ?



Rather than signaling what is the =
preferred action perhaps it would be better that the re-INVITE =
indicated the actual error condition (ie, ICMP errors were encountered =
on the media streams)? A re-INVITE with a Warning header seems the most =
appropriate and transparent approach to me. Now the 3pc or =
proxy really =
knows what is going on and can =
make an proper, informed decision rather than trying to "control" the =
UA into taking the action on its behalf.



Regards.




Robert.




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

From:   Jonathan =
Rosenberg [mailto:jdrosen@dynamicsoft.com]

Sent:   Saturday, June 16, 2001 7:46 AM

To:     'Michael Thomas'; Jonathan Rosenberg

Cc:     John.Hearty@level3.com; 'sip@ietf.org'

Subject:       =
 RE: [SIP] Killing hung media =
streams






Here is a third thing one might do =
upon an ICMP error - send a BYE. I can

construct cases where you really, =
REALLY want this. Specifically, third

party call control. Consider the case =
of a controller in a call with A and

B. A dies. A stops sending media. B =
detects this. B considers its call

terminated, but sends no messages. =
Now, A and B have destroyed call state,

but the controller is left hanging. =
The controller would prefer to get a BYE

in these cases. 




So, we have three things one might do =
upon detecting a failed media stream:




1. re-INVITE

2. send BYE

3. do nothing and consider the call =
down




My argument is that the right thing =
depends on the entity at the other end

of the call. To me, this means some =
kind of signaling is desirable to

communicate which mode is preferred. =
Of course, it can be refused or not

obeyed, but in the cooperating or =
non-conflicting cases, I'd like to be able

to do the right thing.




-Jonathan R.












------_=_NextPart_001_01C0F7E4.7386C470--

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Mon Jun 18 07:22:06 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03389;
	Mon, 18 Jun 2001 07:22:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25574;
	Mon, 18 Jun 2001 07:16:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25543
	for ; Mon, 18 Jun 2001 07:16:36 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03226;
	Mon, 18 Jun 2001 07:16:04 -0400 (EDT)
Message-Id: <200106181116.HAA03226@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 18 Jun 2001 07:16:04 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-callerprefs-04.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: SIP Caller Preferences and Callee Capabilities
	Author(s)	: H. Schulzrinne, J. Rosenberg
	Filename	: draft-ietf-sip-callerprefs-04.txt
	Pages		: 27
	Date		: 15-Jun-01
	
This document describes a set of extensions to SIP which allow a
caller to express preferences about request handling in servers.
These preferences include the ability to select which URIs a request
gets routed to, and to specify certain request handling directives in
proxies and redirect servers. It does so by defining three new
request headers, Accept-Contact, Reject-Contact and Request-
Disposition, which specify the callers preferences. The extension
also defines new parameters for the Contact header that describe the
characterstics of a UA.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-callerprefs-04.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-callerprefs-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-callerprefs-04.txt

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

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

--OtherAccess--

--NextPart--



_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jun 18 08:31:37 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05081
	for ; Mon, 18 Jun 2001 08:31:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 447CD44337; Mon, 18 Jun 2001 08:32:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mip.miptel.com (unknown [210.221.183.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 220D244336
	for ; Mon, 18 Jun 2001 08:31:24 -0400 (EDT)
Received: from arnold ([210.221.183.24])
	by mip.miptel.com (8.10.1/8.8.7) with SMTP id f5ICYlv04736
	for ; Mon, 18 Jun 2001 21:34:48 +0900
Message-ID: <001601c0f8bc$7ded2ed0$18b7ddd2@arnold>
From: =?ks_c_5601-1987?B?wMzI8byu?= 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0013_01C0F907.ED83D0A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Subject: [SIP] If there are no SDP body, how does UAc do  ?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 19 Jun 2001 21:36:41 +0900

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C0F907.ED83D0A0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

VUFjIHNlbmRzIElOVklURSBtZXNzYWdlIHRvIFVBcyBhbmQgdGhhdCBJTlZJVEUgbWFzc2FnZSBo
YXZlIHRocmVlIFJUUCBwYXlsb2FkIHR5cGVzIDAsNCxhbmQgOC4NCg0KVUFzIHNlbmRzIDE4MCBh
bmQgMjAwIHJlc3BvbnNlIHRvIFVBYyBidXQgdGhlcmUgYXJlIG5vIFNEUCBib2R5LA0KDQpBdCB0
aGlzIHRpbWUsIEhvdyBkb2VzIFVBYyBkbyA/DQoNCg==

------=_NextPart_000_0013_01C0F907.ED83D0A0
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz
X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T
SFRNTCA1LjAwLjMzMTUuMjg3MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv
SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPlVBYyBzZW5k
cyBJTlZJVEUgbWVzc2FnZSB0byBVQXMgYW5kIHRoYXQgSU5WSVRFIG1hc3NhZ2UgaGF2ZSANCnRo
cmVlIFJUUCBwYXlsb2FkIHR5cGVzIDAsNCxhbmQgOC48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNw
OzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VUFzIHNlbmRzIDE4MCBhbmQgMjAwIHJlc3BvbnNl
IHRvIFVBYyBidXQgdGhlcmUgYXJlIG5vIFNEUCANCmJvZHksPC9GT05UPjwvRElWPg0KPERJVj4m
bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkF0IHRoaXMgdGltZSwgSG93IGRvZXMgVUFj
IGRvID88L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo=

------=_NextPart_000_0013_01C0F907.ED83D0A0--


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


From sip-admin@ietf.org  Mon Jun 18 11:13:01 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09969;
	Mon, 18 Jun 2001 11:13:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03896;
	Mon, 18 Jun 2001 11:06:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03863
	for ; Mon, 18 Jun 2001 11:06:13 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09743
	for ; Mon, 18 Jun 2001 11:05:40 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA01461;
	Mon, 18 Jun 2001 02:40:28 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 18 Jun 2001 02:36:25 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'brett@broadsoft.com'" ,
        "'sip@ietf.org'"
	 
Subject: RE: [SIP] draft-ietf-sip-session-timer-04: INVITE with Require an
	d Support timer and Session-Expires
Date: Mon, 18 Jun 2001 02:36:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org




 

> -----Original Message-----
> From: Brett Tate [mailto:brett@broadsoft.com]
> Sent: Wednesday, May 30, 2001 2:58 PM
> To: SIP (E-mail)
> Subject: [SIP] draft-ietf-sip-session-timer-04: INVITE with 
> Require and
> Support timer and Session-Expires
> 
> 
> What should happen if a UAC sends an INVITE 
> with Session-Expires and both Supported timer 
> and Require timer?

The Require implies Supported, so the behavior would be identical to the
case where just Require were present. This is probably an issue best
addressed in the Supported header specification, since its more general than
session timer.


> 
> What should happen if the UAS responds to such 
> a request and includes the same the three 
> headers and values?  Are both now effectively 
> responsible for sending refreshes?  Or is the 
> UAS forbidden from sending such a response?

These are good questions. A lot of it depends on what we mean when Require
is placed in the request. In principal, its quite useless. Require normally
means "don't process the request unless you understand the extension". But,
session timer works just fine even if the UAS doesn't support the extension.
So, based on this definition, inserting it has zero meaning. However, one
might think that Require in the INVITE means, "UAS, you should do the
refreshes". 

I'm inclined to be consistent with normal Require usage. In this case, the
presence of Require in the INVITE has no impact on processing at the UAS if
it supports the extension. UAC will do the refreshes. If the UAC wants the
UAS to do them, the UAC can insert the Session-Timer header, but not a
Supported header. This will result in the UAS doing them if it supports it,
otherwise there won't be session timers. 

If people concur, I'll make the changes along those lines.


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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Mon Jun 18 11:13:03 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09980;
	Mon, 18 Jun 2001 11:13:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03819;
	Mon, 18 Jun 2001 11:05:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03794
	for ; Mon, 18 Jun 2001 11:05:38 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09721
	for ; Mon, 18 Jun 2001 11:05:05 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA01443;
	Mon, 18 Jun 2001 02:35:58 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 18 Jun 2001 02:31:54 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'ysong@telcordia.com'" ,
        "'sip@ietf.org'"
	 
Date: Mon, 18 Jun 2001 02:31:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: [Sip] RE: [Sip-implementors] contact address changes mid-call
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org


(moving this to sip@ietf.org as its an open issue)
 

> -----Original Message-----
> From: ysong@telcordia.com [mailto:ysong@telcordia.com]
> Sent: Wednesday, June 13, 2001 7:35 PM
> To: sip-implementors@cs.columbia.edu
> Subject: [Sip-implementors] contact address changes mid-call
> 
> 
> Hi,
> 
> Section 16.4 of rfc2543bis-03 mainly describes the route set 
> construction
> when a re-INVITE request is sent/received mid-call.
> I was wondering if route set can be changed with a new Contact if a
> non-INVITE request (e.g., ACK, INFO) is received with a 
> Contact header for
> an existing call leg.
> For example, if a UAS receives an ACK with Contact header 
> that is different
> from the one received in the associated INVITE, should the 
> UAS replace the
> previous Contact with the new one?

This is a good question, indeed. I don't know. It comes back to the
existing, larger open issues about record-routing of non-session initiating
methods, like NOTIFY. The problems are related, I think. We can't really
allow Contacts to be updated in an ACK or NOTIFY, but disallow these to
contain record-routes to establish a route set if one hasn't been
established. 

I'm inclined to say no. I know Adam hard argued against this. His impetus
was to establish additional call legs resulting from a forked SUBSCRIBE, by
using the NOTIFY in the reverse direction to contstruct the leg. I don't
like this, since it has problems generalizing. Other mid-call leg methods
won't be sufficient to re-establish complete state. Its only for SUB/NOTIFY
that this works. It won't work for an INFO mid call, for example.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Mon Jun 18 12:03:42 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11254;
	Mon, 18 Jun 2001 12:03:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05699;
	Mon, 18 Jun 2001 11:53:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05637
	for ; Mon, 18 Jun 2001 11:53:55 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10862
	for ; Mon, 18 Jun 2001 11:53:21 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5IFrrN01756;
	Mon, 18 Jun 2001 17:53:53 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5IFrqE29416;
	Mon, 18 Jun 2001 18:53:52 +0300 (EET DST)
Message-ID: <3B2E247A.80631ECC@lmf.ericsson.se>
Date: Mon, 18 Jun 2001 18:55:38 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'sip@ietf.org'" 
Subject: Re: [Sip] new open issue in session timer: NEEDS resolution now!
References: 
Content-Type: multipart/mixed;
 boundary="------------EE531AC74C05F09263E2C094"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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



Hi,

I think that the Minimum-Timer header could work.

However (forgive me if this issue has been raised and discussed before),
the UAC now does not know due to WHICH proxy the minimum value exists.
Maybe that proxy didn't insert a Record-Route, so the re-INVITEs would
never reach that proxy, so it doesn't matter what its minimum value is.
I guess this problem exists no matter if the Minimum-Timer header is
used or not, though, since a proxy can always return 422 if the received
value is too small.

One option would be to add a rule in the spec, saying that a proxy that
does modify the Session-Expires header, OR sends 422, also MUST insert
itself in the route. It may sound obvious, but I think it should be
written somewhere (unless it isn't allready...).

Comments?

Christer Holmberg
Ericsson Finland



Jonathan Rosenberg wrote:
> 
> Folks,
> 
> Whilst writing up a discussion of the smurf attack for the session-timer
> spec, I ran into a problem.
> 
> We added the ability for a proxy to reject a request if the session timer
> was too low. Consider the case of a UAC A, two proxies B and C, and UAS D. A
> sends an INVITE, with Supported: timer. It lists a value of 1 hour. This
> hits proxy B. B feels this is too long, and wants the 30 minute minimum. So,
> it reduces it. That hits C. C feels this is too short, below its 45 minute
> minimum. So, it rejects the request, and includes a session-expires header
> with 45 minutes.
> 
> So, A resends the request, with a session-expires of 45 minutes. This, once
> again, is too short for B, which reduces it to 30 minutes, and passes it to
> C. C rejects it because its too long, and includes a session-expires header
> with 45 minutes.
> 
> This will then continue ad-infinitum. Its also a nice DoS attack in and of
> itself.
> 
> Dean raised this issue a while back. I had suggested the ability of a proxy
> to increase the session-expires, and then include a header, say
> Minimum-Timer, which indicates its minimum value that no one else can reduce
> it below. He pointed out that you have problems, then, if two proxies have
> non-overlapping preferences. Well, we still have that problem. The result of
> the 422 rejection response is that proxies can, effectively, increase the
> value of the session timer, so the same problem arises.
> 
> The only sensible out that I see is to add back this Minimum-Timer header. A
> UAC, when it gets a 422 Session Timer too small, remembers the value of the
> Session-Expires in that response. It stores the largest value returned in
> any 422 for the call leg in question. In any re-invites with session timers,
> the UAC includes a Minimum-Timer header with this value. A proxy MUSTNOT
> reduce the session timer below this value.
> 
> I welcome any other suggestions....
> 
> Another requirement for this to work is that, when a UA refreshes, it
> inserts a session-expres with the same timer as the previous successful
> re-INVITE, unless it explicitly wishes to disable session timers. Without
> that, the smurf attack is still possible! Thats because, if each re-invite
> doesn't contain the last session timer, no request will actually ever
> contain a session-expires, and so there is no opportunity for a proxy in
> front of the attacking proxy to reject the low values inserted by the
> attacking proxy!
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip
--------------EE531AC74C05F09263E2C094
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------EE531AC74C05F09263E2C094--


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jun 18 12:04:37 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11278
	for ; Mon, 18 Jun 2001 12:04:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CFE7144344; Mon, 18 Jun 2001 12:05:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp5.andrew.cmu.edu (SMTP5.ANDREW.CMU.EDU [128.2.10.85])
	by lists.bell-labs.com (Postfix) with ESMTP id F2D3F44336
	for ; Mon, 18 Jun 2001 12:04:47 -0400 (EDT)
Received: from UNIX6.ANDREW.CMU.EDU (UNIX6.ANDREW.CMU.EDU [128.2.11.206])
	by smtp5.andrew.cmu.edu (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f5IG4jRl025333;
	Mon, 18 Jun 2001 12:04:45 -0400
From: Janak Sanjaykumar Mehta 
To: Pierre.Lacour@alcatel.fr
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Search for a draft
In-Reply-To: 
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 18 Jun 2001 12:04:46 -0400 (EDT)

Hi,

You should try following link..
sunsite.cnlab-switch.ch/ftp/mirror/internet-drafts/draft-rosenberg-sip-appcomponents-01.txt



Janak
==================================
Janak Mehta
Information Networking Institute
Canegie Mellon University
Hamburg Hall A020
4800 Forbes Avenue
Pittsburgh PA 15213

(O)# (412)-268-3029
(R)# (412)-683-9049

On Mon, 18 Jun 2001 Pierre.Lacour@alcatel.fr wrote:

> 
> 
> Hello,
>   I am searching for the following document :
>   J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application
>    server component architecture for sip," Internet Draft, Internet
>    Engineering Task Force, Nov. 2000.
> 
>   I am searching for recommendations and Call flows about media servers and Third Party Call Control, it is why I found the previous reference into the draft-rosenberg-sip-3pcc-02.txt, but I don't find it.
> 
>   Please,   someone can tell me where I can find this draft ?
> 
>   Thank You,
> 
>   Pierre
> 
> 
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> 


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


From sip-admin@ietf.org  Mon Jun 18 12:16:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11521;
	Mon, 18 Jun 2001 12:16:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06758;
	Mon, 18 Jun 2001 12:12:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06728
	for ; Mon, 18 Jun 2001 12:12:25 -0400 (EDT)
Received: from go-postal.hearme.com (go-postal.hearme.com [206.233.215.57])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11417
	for ; Mon, 18 Jun 2001 12:11:47 -0400 (EDT)
Received: by go-postal.hearme.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 18 Jun 2001 09:11:35 -0700
Message-ID: 
From: Corey Gates 
To: "'Jonathan Rosenberg'" ,
        "'sip@ietf.org'"
	 
Subject: RE: [Sip] Request header integrity in HTTP Digest
Date: Mon, 18 Jun 2001 09:11:30 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Jonathan,

I believe you left out the "private-key" in the nonce computation in
draft-rosenberg-sip-http-pnonce-00.txt.  The nonce should be:

nonce = H(source-IP::round-time:private-key)

Without this the nonce could be generated.

Corey Gates


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Mon Jun 18 12:27:13 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11937;
	Mon, 18 Jun 2001 12:27:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05291;
	Mon, 18 Jun 2001 11:39:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05258
	for ; Mon, 18 Jun 2001 11:39:52 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10633
	for ; Mon, 18 Jun 2001 11:39:19 -0400 (EDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5IFbt423788;
	Mon, 18 Jun 2001 11:37:55 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-91.cisco.com [161.44.241.91])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id AAW00470 (AUTH pkyzivat);
	Mon, 18 Jun 2001 11:39:20 -0400 (EDT)
Message-ID: <3B2E1FBC.99EAE2CD@cisco.com>
Date: Mon, 18 Jun 2001 11:35:24 -0400
From: Paul Kyzivat 
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Michael Thomas'" , John.Hearty@level3.com,
        "'sip@ietf.org'" 
Subject: Re: [SIP] Killing hung media streams
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Snippet from Jonathan Rosenberg:

> So, we have three things one might do upon detecting a failed media stream:
> 
> 1. re-INVITE
> 2. send BYE
> 3. do nothing and consider the call down
> 
> My argument is that the right thing depends on the entity at the other end
> of the call. To me, this means some kind of signaling is desirable to
> communicate which mode is preferred.

In what situation would (3) be the right thing to do?
The only case I can see is when sip signaling is no longer possible.

It also seems like the re-INVITE *is* the signaling mechanism.
Then the overall recovery process is:

- reach conclusion there is a problem
- send re-INVITE, to test the state of the other end and to 
  request actions to recover from the problem
- if re-INVITE succeeds, continue with (hopefully fixed) session
- if re-INVITE fails, try to send BYE
- if BYE succeeds consider the call down
- if BYE fails, also consider the call down

This seems to cover all of the three things one might do that you 
mentioned. Sending the re-INVITE is optional if you know that it
will fail. Seems like this would only be if the problem is at this
end and there is no alternative to offer. Attempting to send the 
BYE shouldn't be optional.

But there are some issues with the re-INVITE that I don't understand:

If I believe the problem is with my end, and there is something
I can change (e.g. in my SDP) that would help solve the problem,
then of course I can offer that. 

But it seems like either I will believe the problem is with the 
other end, or else I will have no idea where it is and have no 
idea what kind of change might help. Suppose I have received ICMP
errors on my sends, and suspect the port I am sending to, or the
path to it, are down. When I send a reinvite, there is nothing
obvious for me to change in *my* SDP - I want the other end to 
offer me something that will work better. So perhaps I send 
unchanged SDP. When the other end receives this, it may have no 
idea that anything is wrong. How does it decide that it should do 
anything other than send unchanged SDP back?

I don't see any headers that could be used in the reinvite to
signal this. Further, I don't think that the right level of
detail can be communicated via sip headers. It is possible that
the call involves several media, and that all are functioning
ok except for one. In this case, I need some way to indicate
what media need fixing. This seems to require some involvement
of SDP.

This isn't an implementation detail because it requires coordinated
actions by the two endpoints. So it really needs to be standardized.
Am I missing some existing explanation of how to do this?

	Paul Kyzivat
	Cisco Systems

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@cisco.com]
> > Sent: Friday, June 15, 2001 11:19 AM
> > To: Jonathan Rosenberg
> > Cc: 'Michael Thomas'; John.Hearty@Level3.com; 'sip@ietf.org'
> > Subject: RE: [SIP] Killing hung media streams
> >
> >
> > Jonathan Rosenberg writes:
> >  > Lets say A and B are in a call, and B is a type of device
> > that if it fails,
> >  > the call is over. When A detects this, through ICMP
> > errors, it should not
> >  > bother with a re-INVITE, but rather, consider the call
> > over. On the other
> >  > hand, if B is a type of device that, if it fails, a simple
> > re-INVITE will
> >  > allow the call to be recovered at an alternate device (the
> > alternate would
> >  > be figured out through downstream SRV or other routing
> > approaches), then A
> >  > should send that re-INVITE immediately.
> >  >
> >  > So, how does A know which to do?
> >  >
> >  > I suppose we could mandate that a re-INVITE is always
> > done, and then, if a
> >  > 481 is generated, the call is considered terminated. That
> > would generally
> >  > work, I think, but would often be a waste. I suppose for
> > simplicities sake
> >  > we could just specify that, although I could have sworn I
> > had come up with a
> >  > reason you really needed to know....
> >
> >    Unless there's some other reason, I would think that
> >    this is just an implementation detail, and up to the
> >    UA. The reason is that there are probably more reasons
> >    to do a re-invite than just this. For example, I may
> >    as a matter of course want my UA to reinvite if it's
> >    on a flakey network (like, oh say, cellular) to help
> >    smooth out bumps.
> 
> Things are implementation details when the result has no impact on other
> systems. That doesn't seem to be the case here. Lets say I build a
> conferencing server, and if it crashes, I can recover state by having the
> far side send a re-INVITE to rebuild the call legs at a backup. Now, the
> implementation detail at the far end dictates the service offered overall.
> The conferencing server wants to tell the other side that a re-INVITE on
> ICMP is the right thing to do.
> 
> Here is a third thing one might do upon an ICMP error - send a BYE. I can
> construct cases where you really, REALLY want this. Specifically, third
> party call control. Consider the case of a controller in a call with A and
> B. A dies. A stops sending media. B detects this. B considers its call
> terminated, but sends no messages. Now, A and B have destroyed call state,
> but the controller is left hanging. The controller would prefer to get a BYE
> in these cases.
> 
> So, we have three things one might do upon detecting a failed media stream:
> 
> 1. re-INVITE
> 2. send BYE
> 3. do nothing and consider the call down
> 
> My argument is that the right thing depends on the entity at the other end
> of the call. To me, this means some kind of signaling is desirable to
> communicate which mode is preferred. Of course, it can be refused or not
> obeyed, but in the cooperating or non-conflicting cases, I'd like to be able
> to do the right thing.
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Mon Jun 18 12:41:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12608;
	Mon, 18 Jun 2001 12:41:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07564;
	Mon, 18 Jun 2001 12:31:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA07531
	for ; Mon, 18 Jun 2001 12:31:18 -0400 (EDT)
Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12158
	for ; Mon, 18 Jun 2001 12:30:44 -0400 (EDT)
From: adam.roach@ericsson.com
Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f5IGU1R21646;
	Mon, 18 Jun 2001 11:30:01 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f5IGTwm07340;
	Mon, 18 Jun 2001 11:29:58 -0500 (CDT)
Received: from pc050163 (pc050178.exu.ericsson.se [138.85.50.178]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA03173; Mon, 18 Jun 2001 11:29:57 -0500 (CDT)
Reply-To: 
To: "'Jonathan Rosenberg'" ,
        "'Michael Thomas'" 
Cc: , 
Subject: RE: [SIP] Killing hung media streams
Date: Mon, 18 Jun 2001 11:29:53 -0500
Message-ID: <61D824C63B99D311975E00508B0CC9850225186E@eamrcnt717.exu.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> -----Original Message-----
> From: Jonathan Rosenberg
>
> Here is a third thing one might do upon an ICMP error - send 
> a BYE. I can
> construct cases where you really, REALLY want this. 
> Specifically, third
> party call control. Consider the case of a controller in a 
> call with A and
> B. A dies. A stops sending media. B detects this. B considers its call
> terminated, but sends no messages. Now, A and B have 
> destroyed call state,
> but the controller is left hanging. The controller would 
> prefer to get a BYE
> in these cases. 

I'd argue that anyone implementing a 3pcc without using session-timer
is just asking for buckets of trouble.

I still feel quite strongly that negotiating this behavior at call
setup time adds too much complexity for the gain. If you always send
out a re-INVITE upon media failure, the systems can be made to do the
right thing.

/a


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jun 18 13:58:36 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15096
	for ; Mon, 18 Jun 2001 13:58:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C2FD54435C; Mon, 18 Jun 2001 13:59:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 3B0C644336
	for ; Mon, 18 Jun 2001 13:58:51 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA10822;
	Mon, 18 Jun 2001 14:02:53 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id ; Mon, 18 Jun 2001 13:58:49 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Pierre.Lacour@alcatel.fr'" ,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Search for a draft
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 18 Jun 2001 13:58:42 -0400

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-app-components-01
.txt

 

> -----Original Message-----
> From: Pierre.Lacour@alcatel.fr [mailto:Pierre.Lacour@alcatel.fr]
> Sent: Monday, June 18, 2001 5:21 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Search for a draft
> 
> 
> 
> 
> Hello,
>   I am searching for the following document :
>   J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application
>    server component architecture for sip," Internet Draft, Internet
>    Engineering Task Force, Nov. 2000.
> 
>   I am searching for recommendations and Call flows about 
> media servers and Third Party Call Control, it is why I found 
> the previous reference into the 
> draft-rosenberg-sip-3pcc-02.txt, but I don't find it.
> 
>   Please,   someone can tell me where I can find this draft ?
> 
>   Thank You,
> 
>   Pierre
> 
> 
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> 

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

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


From sip-admin@lists.bell-labs.com  Mon Jun 18 14:30:36 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16028
	for ; Mon, 18 Jun 2001 14:30:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 41A1744337; Mon, 18 Jun 2001 14:31:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by lists.bell-labs.com (Postfix) with ESMTP id 6D54C44336
	for ; Mon, 18 Jun 2001 14:30:31 -0400 (EDT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GF50070E22PN8@firewall.mcit.com> for sip@lists.bell-labs.com;
 Mon, 18 Jun 2001 18:30:25 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GF500L0122MPZ@pmismtp01.wcomnet.com>;
 Mon, 18 Jun 2001 18:30:25 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GF500L4Q22A0Y@pmismtp01.wcomnet.com>; Mon,
 18 Jun 2001 18:30:11 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2653.19)
	id ; Mon, 18 Jun 2001 18:30:10 +0000
Content-return: allowed
From: "Iliff, Tina" 
Subject: RE: [SIP] Search for a draft
To: "'Jonathan Rosenberg'" ,
        "'Pierre.Lacour@alcatel.fr'" ,
        sip@lists.bell-labs.com
Message-id: <492EB4A3F68CD411ABE800508B69362E3F5992@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=ISO-8859-1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 18 Jun 2001 18:30:02 +0000

Received a 404 response.   Has this draft been removed?

Tina Iliff


 -----Original Message-----
From: 	Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
Sent:	Monday, June 18, 2001 12:59 PM
To:	'Pierre.Lacour@alcatel.fr'; sip@lists.bell-labs.com
Subject:	RE: [SIP] Search for a draft

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-app-components-01
.txt

 

> -----Original Message-----
> From: Pierre.Lacour@alcatel.fr [mailto:Pierre.Lacour@alcatel.fr]
> Sent: Monday, June 18, 2001 5:21 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Search for a draft
> 
> 
> 
> 
> Hello,
>   I am searching for the following document :
>   J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application
>    server component architecture for sip," Internet Draft, Internet
>    Engineering Task Force, Nov. 2000.
> 
>   I am searching for recommendations and Call flows about 
> media servers and Third Party Call Control, it is why I found 
> the previous reference into the 
> draft-rosenberg-sip-3pcc-02.txt, but I don't find it.
> 
>   Please,   someone can tell me where I can find this draft ?
> 
>   Thank You,
> 
>   Pierre
> 
> 
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> 

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

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

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


From sip-admin@lists.bell-labs.com  Mon Jun 18 14:33:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16156
	for ; Mon, 18 Jun 2001 14:33:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 002E244357; Mon, 18 Jun 2001 14:34:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by lists.bell-labs.com (Postfix) with ESMTP id 8304444337
	for ; Mon, 18 Jun 2001 14:33:21 -0400 (EDT)
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5IIVt406579;
	Mon, 18 Jun 2001 14:31:55 -0400 (EDT)
Received: from cisco.com (nubu-cae2-u60.cisco.com [64.102.93.70])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id AJX06815 (AUTH ntrivedi);
	Mon, 18 Jun 2001 14:33:21 -0400 (EDT)
Message-ID: <3B2E4972.5CEC115B@cisco.com>
From: Nilesh Trivedi 
Organization: Packet Development Unit
X-Mailer: Mozilla 4.08 [en] (X11; U; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: "Iliff, Tina" 
Cc: "'Jonathan Rosenberg'" ,
        "'Pierre.Lacour@alcatel.fr'" ,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Search for a draft
References: <492EB4A3F68CD411ABE800508B69362E3F5992@RIPEXCH002.wcomnet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 18 Jun 2001 11:33:23 -0700
Content-Transfer-Encoding: 7bit

Well, try it with '.txt' at the end of the URL from the
page you recieved 404.

:-)

Nilesh.

Iliff, Tina wrote:

> Received a 404 response.   Has this draft been removed?
>
> Tina Iliff
>
>  -----Original Message-----
> From:   Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent:   Monday, June 18, 2001 12:59 PM
> To:     'Pierre.Lacour@alcatel.fr'; sip@lists.bell-labs.com
> Subject:        RE: [SIP] Search for a draft
>
> http://search.ietf.org/internet-drafts/draft-rosenberg-sip-app-components-01
> .txt
>
>
>
> > -----Original Message-----
> > From: Pierre.Lacour@alcatel.fr [mailto:Pierre.Lacour@alcatel.fr]
> > Sent: Monday, June 18, 2001 5:21 AM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] Search for a draft
> >
> >
> >
> >
> > Hello,
> >   I am searching for the following document :
> >   J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application
> >    server component architecture for sip," Internet Draft, Internet
> >    Engineering Task Force, Nov. 2000.
> >
> >   I am searching for recommendations and Call flows about
> > media servers and Third Party Call Control, it is why I found
> > the previous reference into the
> > draft-rosenberg-sip-3pcc-02.txt, but I don't find it.
> >
> >   Please,   someone can tell me where I can find this draft ?
> >
> >   Thank You,
> >
> >   Pierre
> >
> >
> >
> >
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementor's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to
> > sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> >
>
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.


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


From sip-admin@lists.bell-labs.com  Mon Jun 18 14:45:37 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16448
	for ; Mon, 18 Jun 2001 14:45:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E50DA44361; Mon, 18 Jun 2001 14:46:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 964FE4435C
	for ; Mon, 18 Jun 2001 14:45:14 -0400 (EDT)
Received: from pmismtp01.wcomnet.com ([166.38.62.36])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0GF5005C52R43Z@firewall.mcit.com> for sip@lists.bell-labs.com;
 Mon, 18 Jun 2001 18:45:05 +0000 (GMT)
Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0GF5007012QXQN@pmismtp01.wcomnet.com>;
 Mon, 18 Jun 2001 18:45:04 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0GF5004F02QOEQ@pmismtp01.wcomnet.com>; Mon,
 18 Jun 2001 18:44:49 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2653.19)
	id ; Mon, 18 Jun 2001 18:44:48 +0000
Content-return: allowed
From: "Iliff, Tina" 
Subject: RE: [SIP] Search for a draft
To: "'Nilesh Trivedi'" 
Cc: "'Jonathan Rosenberg'" ,
        "'Pierre.Lacour@alcatel.fr'" ,
        sip@lists.bell-labs.com
Message-id: <492EB4A3F68CD411ABE800508B69362E3F5994@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain; charset=ISO-8859-1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 18 Jun 2001 18:44:37 +0000

Thanks!  That was the cause of the problem.  Evidently the .txt extension
was not included in the hyperlink.

Tina Iliff


 -----Original Message-----
From: 	Nilesh Trivedi [mailto:ntrivedi@cisco.com] 
Sent:	Monday, June 18, 2001 1:33 PM
To:	Iliff, Tina
Cc:	'Jonathan Rosenberg'; 'Pierre.Lacour@alcatel.fr';
sip@lists.bell-labs.com
Subject:	Re: [SIP] Search for a draft

Well, try it with '.txt' at the end of the URL from the
page you recieved 404.

:-)

Nilesh.

Iliff, Tina wrote:

> Received a 404 response.   Has this draft been removed?
>
> Tina Iliff
>
>  -----Original Message-----
> From:   Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent:   Monday, June 18, 2001 12:59 PM
> To:     'Pierre.Lacour@alcatel.fr'; sip@lists.bell-labs.com
> Subject:        RE: [SIP] Search for a draft
>
>
http://search.ietf.org/internet-drafts/draft-rosenberg-sip-app-components-01
> .txt
>
>
>
> > -----Original Message-----
> > From: Pierre.Lacour@alcatel.fr [mailto:Pierre.Lacour@alcatel.fr]
> > Sent: Monday, June 18, 2001 5:21 AM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] Search for a draft
> >
> >
> >
> >
> > Hello,
> >   I am searching for the following document :
> >   J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application
> >    server component architecture for sip," Internet Draft, Internet
> >    Engineering Task Force, Nov. 2000.
> >
> >   I am searching for recommendations and Call flows about
> > media servers and Third Party Call Control, it is why I found
> > the previous reference into the
> > draft-rosenberg-sip-3pcc-02.txt, but I don't find it.
> >
> >   Please,   someone can tell me where I can find this draft ?
> >
> >   Thank You,
> >
> >   Pierre
> >
> >
> >
> >
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementor's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to
> > sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> >
>
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.

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


From sip-admin@ietf.org  Mon Jun 18 14:47:59 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16520;
	Mon, 18 Jun 2001 14:47:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11882;
	Mon, 18 Jun 2001 14:29:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11853
	for ; Mon, 18 Jun 2001 14:29:26 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15897
	for ; Mon, 18 Jun 2001 14:28:51 -0400 (EDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f5IITJO27836;
	Mon, 18 Jun 2001 20:29:19 +0200 (MEST)
Received: from lmf.ericsson.se (racom-bo-9.bo.us.am.ericsson.se [138.85.235.239])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id UAA09417;
	Mon, 18 Jun 2001 20:29:45 +0200 (MET DST)
Message-ID: <3B2E4A3A.651C3A0D@lmf.ericsson.se>
Date: Mon, 18 Jun 2001 21:36:42 +0300
From: Gonzalo Camarillo 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Bob Penfield'" , adam.roach@ericsson.com,
        "'Rich Schaaf'" , sip@ietf.org
Subject: Re: [SIP] DNS SRV and authentication challenges
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

> > I think it is just as reasonable to allow (or maybe require)
> > the client to
> > send the INVITE with authentication to the same network address as the
> > initially rejected request. It seems clear to me that the
> > intention of the
> > referenced text (section 1.4.2 I believe) was to ensure that
> > any request
> > that required state in the "next-hop" server created by a recent prior
> > request is sent to the same SIP server. Although technically,
> > it is a new
> > transaction, it is still the same "transaction" (placing a
> > call) from the
> > user's point of view.
> 
> I strongly disagree.
> 
> One of the nice things about the current SRV mechanism is that its nicely
> layered. To properly implement it, I don't need to know the conditions under
> which the transaction is being initiated. If, all of a sudden, I need to
> know call level or header-level semantics in order to do the right thing
> with SRV, we get a code nightmare. Therefore, requiring that the request for
> the INVITE after a challenge result in the same SRV decision as the previous
> INVITE is a big mistake, IMHO.

I agree with you that the protocol should ONLY ensure that
1) retransmissions of a request
2) ACKs for non 2xx reponses
3) CANCELs
are sent to the same network address than the initial request.

Since a second INVITE with authentication stuff is not any of these 3
cases, we should use the randomization algorithm used for choosing one
network address among all the SRV records provided.


However, I do not agree that we run into a code nightmare. I believe
that the code would be even simpler. Right now, in order to send
retransmissions, CANCELs and ACKs to the same network address we
typically use a hash of some fields, such as To, From, the numeric part
of the Cseq and the Call-ID. If intead of using all these variables we
just use the Call-ID, all the requests within a call will be sent to the
same network address.

Folks might argue that we lose some randomization power by excluding the
From, To and Cseq fields in the hash calculation, but I do not think it
really matters. These variables provide randomization only within a
call. Randomization among different calls is equally acomplish by using
just the call-ID.


I also agree that mechanisms that send challenges back to the client
should be stateless, since otherwise the server will be an easy target
for a resource attack. But I can think of different scenarios where
sending requests with the same Call-ID to the same network address might
be useful. For example, a client that sends an INVITE and before the
callee picks up wants to terminate the call attempt. If this client
sends a BYE rather than a CANCEL, it would be nice if it arrives to the
same network address. Mainly if the callee is behind a gateway that was
located using SRV.

Best regards,

Gonzalo



> The real problem is this:
> >      The SIP client sends a new INVITE request that includes
> >      proxy authorization information.  Since this is a new
> >      transaction, a DNS SRV lookup is performed by the SIP client
> >      (which returns HostB) and the request is sent to the SIP
> >      proxy at HostB.
> >
> >      The SIP proxy at HostB is not the proxy that issued the challenge
> >      to the SIP client so it sends back a "403 Non-Trusted Caller"
> >      response and the call fails.
> 
> There are at least two things wrong with this proxy. First, and foremost,
> since both proxies are the result of lookups for the given domain, they
> should be equivalent, in the sense that both have access to the users
> username and password, and both are similarly configured. The idea with SRV
> is to provide load balancing and failure recovery across a set of
> homogeneous servers for a specific domain. This means that when the new
> INVITE arrives with credentials, they should be valid at this proxy as well.
> The nonce computation will be identical in this proxy, if it follows the
> recommended mechanisms in rfc2617 and the two proxies have synced time
> (which you want for other reasons).
> 
> The second problem is the 403. Why on earth would the proxy send this? The
> digest and basic authentication mechanisms are stateless. That is, the
> treatment of a request with an invalid Proxy-Authorization header is
> identical to the case where no Proxy-Authorization header is present. As a
> result of this, the proxy does not need to remember that it issued the
> challenge, in order to process the response in the next INVITE. If you have
> a proxy which creates state when it issues the challenges, and uses this for
> the next INVITE, well, time to throw that one out and buy a good one. This
> proxy is easily the subject of a massive DoS attack, since it creates state
> for unauthorized requests.
> 
> So, in the worst case, the second proxy uses a different set of
> configuration params, and is not time-synchronized with the first. What
> happens here? This second proxy should have sent a 401, with its own realm
> and its own nonce. The UAC generates credentials for this challenge as well,
> and in the third INVITE, includes both sets of credentials. It hits one of
> the two servers, and since the request has credentials valid at both, it
> works just dandy.
> 
> In a properly configured network with good proxies, the second transaction
> would succeed at the second proxy.
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Mon Jun 18 14:55:33 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16661;
	Mon, 18 Jun 2001 14:55:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12690;
	Mon, 18 Jun 2001 14:48:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12661
	for ; Mon, 18 Jun 2001 14:48:05 -0400 (EDT)
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16517
	for ; Mon, 18 Jun 2001 14:47:33 -0400 (EDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-green.research.att.com (Postfix) with ESMTP id 2FBB61E04F
	for ; Mon, 18 Jun 2001 14:48:04 -0400 (EDT)
Received: from fish.research.att.com (fish.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA03807
	for ; Mon, 18 Jun 2001 14:48:03 -0400 (EDT)
From: William Marshall 
Received: (from wtm@localhost)
	by fish.research.att.com (SGI-8.9.3/8.8.5) id OAA55517
	for sip@ietf.org; Mon, 18 Jun 2001 14:47:26 -0400 (EDT)
Date: Mon, 18 Jun 2001 14:47:26 -0400 (EDT)
Message-Id: <200106181847.OAA55517@fish.research.att.com>
To: sip@ietf.org
Subject: [Sip] SDP usage in RFC2543/100rel/bis-03/manyfolks
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

The restrictive wording in bis-03 on allowable placement of
message bodies in SIP requests/responses seems to lead to a
lot of compatibility problems with other current I-Ds.

RFC2543 allows all requests and responses to contain a body.

100rel-03 specifically allows the PRACK request to contain a
body (section 6.1), and allows reliable provisional responses
to contain a body (section 6.2).

Manyfolks-resource-01 made use of these allowable combinations,
to include the UAS SDP in the first reliable provisional response
(typically a 183 if resource reservation is supported).

Unfortunately, bis-03 disallows this combination.

While I understand the desire to restrict the allowable combinations,
so as to more quickly obtain a draft standard with two interoperable
implementations of each feature, I think this creates significant
additional complexity.

An implementation of SIP that conforms to RFC2543, and implements
100rel and manyfolks,  will not conform to 2543bis-03.  The code
for 100rel and manyfolks will actually need to be removed to make
the implementation conform.  Further, it will be necessary to
re-cycle the 100rel and manyfolks I-Ds making the identical
extensions to 2543bis, once again allowing SDP to appear in these
additional requests/responses.

If 2543bis-03 was likely to become a draft standard, all this
might be worthwhile; but since it is more likely that 2543bis will
be recycled as a proposed standard, it does not seem reasonable to
require recycling all the extensions as well.  Especially since the
text changes to 2543bis-03 are so minor.

Annex B.1, which describes the "offer-answer" model, contains the
statement "The offer MAY be placed in an INVITE, in which case the
answer MUST be in a 200 class response, and the ACK MUST NOT contain
SDP."  Changing this to "... in which case the answer MUST be in
a provisional or final response, ..."

(If the PRACK were integrated into  2543bis, this could be strengthened
to say "a reliable provisional or final response"; but the "working code"
requirement will already cause this this to happen)


The second problem with the same paragraph in Annex B.1, is that
there is a case described in the manyfolks draft that requires two
offers to be sent from the UAC.  Specifically, if the UAC requires
a QoS "sendrecv" precondition,  but is only capable of ensuring "send"
(i.e. it uses RSVP), and the UAS agrees to the precondition, but is
capable of ensuring "sendrecv" itself, the UAS may respond with a 180
Ringing instead of 183 Session Progress.  The procedures in manyfolks
then allow (and possibly should require) the UAC to re-send the SDP
with the preconditions asking for a confirmation that "sendrecv" has
been obtained before starting the alerting -- otherwise the UAC does
not really know whether the preconditions were understood or not.

Both the dcs call flows (contained in draft-dcsgroup-sip-arch-04) and
the 3gpp call flows (contained in draft-drage-3gpp-sip-establish-00)
make further use of the secondary offer to perform negotiation of
codec capabilities.  A second round of offer-answer is allowed by
RFC2543, but disallowed by 2543bis-03.  Some additional allowed
combinations in B.1 could solve this problem as well.

Bill Marshall
wtm@research.att.com

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jun 18 14:56:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16693
	for ; Mon, 18 Jun 2001 14:56:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2B15444357; Mon, 18 Jun 2001 14:57:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from revere.sonusnet.com (mail.sonusnet.com [63.99.71.102])
	by lists.bell-labs.com (Postfix) with ESMTP id 24FAB44337
	for ; Mon, 18 Jun 2001 14:56:53 -0400 (EDT)
Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53])
	by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5IIrDr05770
	for ; Mon, 18 Jun 2001 14:53:13 -0400 (EDT)
Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 18 Jun 2001 14:56:48 -0400
Message-ID: <594A6AF62343D511B4750060CF20BAF305E5B8@sonusdc5.sonusnet.com>
From: "Menon, Sunil" 
To: "'sip@lists.bell-labs.com'" 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] G729AB vs G729A
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 18 Jun 2001 14:56:47 -0400

Hi All,
	Does anyone know how one would indicate G729AB vs G729A as the
preferred codec in SDP ? 

Thanks
Sunil Menon
Sonus Networks


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


From sip-admin@lists.bell-labs.com  Mon Jun 18 18:00:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22160
	for ; Mon, 18 Jun 2001 18:00:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CE22444337; Mon, 18 Jun 2001 18:01:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ober.cs.columbia.edu (ober.cs.columbia.edu [128.59.18.100])
	by lists.bell-labs.com (Postfix) with ESMTP id 2D93844336
	for ; Mon, 18 Jun 2001 18:00:15 -0400 (EDT)
Received: from thalys (thalys.cs.columbia.edu [128.59.19.105])
	by ober.cs.columbia.edu (8.9.3/8.9.3) with SMTP id SAA20645;
	Mon, 18 Jun 2001 18:00:14 -0400 (EDT)
From: "Sankaran Narayanan" 
To: "Menon, Sunil" 
Cc: 
Subject: RE: [SIP] G729AB vs G729A
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <594A6AF62343D511B4750060CF20BAF305E5B8@sonusdc5.sonusnet.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 18 Jun 2001 18:02:37 -0400
Content-Transfer-Encoding: 7bit

> 	Does anyone know how one would indicate G729AB vs G729A as the
> preferred codec in SDP ? 
i remember reading somewhere X-G729ab and X-G729a, not sure though.


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


From sip-admin@ietf.org  Tue Jun 19 04:03:47 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16140;
	Tue, 19 Jun 2001 04:03:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12288;
	Tue, 19 Jun 2001 03:32:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12263
	for ; Tue, 19 Jun 2001 03:32:35 -0400 (EDT)
Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15934
	for ; Tue, 19 Jun 2001 03:31:44 -0400 (EDT)
Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca
          via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 19 Jun 2001 08:32:06 UT
Received: (private information removed)
Message-ID: <3B2EFFF6.38F70B59@ubiquity.net>
From: James Undery 
To: Corey Gates 
Cc: "'Jonathan Rosenberg'" ,
        "'sip@ietf.org'"
	 
Subject: Re: [Sip] Request header integrity in HTTP Digest
Date: Tue, 19 Jun 2001 03:32:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



Corey Gates wrote:

> Jonathan,
>
> I believe you left out the "private-key" in the nonce computation in
> draft-rosenberg-sip-http-pnonce-00.txt.  The nonce should be:
>
> nonce = H(source-IP: protected>:round-time:private-key)
>
> Without this the nonce could be generated.

I fail to see what you've gained by hashing the password into the nonce,
the nonce is only really
there so the server can be sure the client's messages aren't just being
replayed, the client will hash in the password to provide
authentication. (Obviously this explanation is very simplistic.)

James Undery


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Tue Jun 19 06:57:34 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17376;
	Tue, 19 Jun 2001 06:57:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA18013;
	Tue, 19 Jun 2001 06:46:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17984
	for ; Tue, 19 Jun 2001 06:46:14 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17084;
	Tue, 19 Jun 2001 06:45:38 -0400 (EDT)
Message-Id: <200106191045.GAA17084@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 19 Jun 2001 06:45:38 -0400
Subject: [Sip] I-D ACTION:draft-rosenberg-sip-http-pnonce-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Request Header Integrity in SIP and HTTP Digest using
                          Predictive Nonces
	Author(s)	: J. Rosenberg
	Filename	: draft-rosenberg-sip-http-pnonce-00.txt
	Pages		: 7
	Date		: 18-Jun-01
	
The HTTP Digest algorithm, specified in RFC 2617, allows for
authentication of a request, along with integrity checks over the
method, request URI, and optionally, the body. HTTP Digest is the
primary client authentication mechanism used by SIP. However, Digest
does not provide for integrity checks over several key SIP headers,
including the To, From, Call-ID and Contact headers. We define a
mechanism for supporting integrity over these headers, using a new
algorithm we call predictive nonces. The mechanism requires no
changes in clients, and no protocol changes. It requires only a
change in the way the nonce is computed by servers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rosenberg-sip-http-pnonce-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-rosenberg-sip-http-pnonce-00.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-rosenberg-sip-http-pnonce-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:	<20010618105538.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-rosenberg-sip-http-pnonce-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-rosenberg-sip-http-pnonce-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Tue Jun 19 07:35:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18001;
	Tue, 19 Jun 2001 07:35:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19265;
	Tue, 19 Jun 2001 07:26:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19236
	for ; Tue, 19 Jun 2001 07:26:56 -0400 (EDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17824
	for ; Tue, 19 Jun 2001 07:26:20 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5JBQ0928541
	for ; Tue, 19 Jun 2001 14:26:00 +0300 (EET DST)
Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Tue, 19 Jun 2001 14:26:52 +0300
Received: by esebh24nok with Internet Mail Service (5.5.2652.78)
	id ; Tue, 19 Jun 2001 14:26:52 +0300
Message-ID: 
To: jundery@ubiquity.net, corey@hearme.com
Cc: jdrosen@dynamicsoft.com, sip@ietf.org
Subject: RE: [Sip] Request header integrity in HTTP Digest
Date: Tue, 19 Jun 2001 14:26:46 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Hi,

> Corey Gates wrote:
> 
> > Jonathan,
> >
> > I believe you left out the "private-key" in the nonce computation in
> > draft-rosenberg-sip-http-pnonce-00.txt.  The nonce should be:
> >
> > nonce = H(source-IP: > protected>:round-time:private-key)
> >
> > Without this the nonce could be generated.
> 
> I fail to see what you've gained by hashing the password into 
> the nonce,
> the nonce is only really
> there so the server can be sure the client's messages aren't 
> just being
> replayed, the client will hash in the password to provide
> authentication. (Obviously this explanation is very simplistic.)

As in RFC 2617, I think what was meant here was, that the private-key is
just some data only known to the server and not the shared secret
(password). 

I think this would also make sense for pnonce, since otherwise all
information contained in the hash can readily be found from the message
itself.

Br,
Aki

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Tue Jun 19 08:12:48 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19102;
	Tue, 19 Jun 2001 08:12:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20143;
	Tue, 19 Jun 2001 07:56:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20118
	for ; Tue, 19 Jun 2001 07:56:19 -0400 (EDT)
Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18559
	for ; Tue, 19 Jun 2001 07:55:43 -0400 (EDT)
Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca
          via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 19 Jun 2001 12:56:04 UT
Received: (private information removed)
Message-ID: <3B2F3DE4.48CD4858@ubiquity.net>
From: James Undery 
To: aki.niemi@nokia.com
Cc: corey@hearme.com, jdrosen@dynamicsoft.com, sip@ietf.org
Subject: Re: [Sip] Request header integrity in HTTP Digest
Date: Tue, 19 Jun 2001 07:56:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



aki.niemi@nokia.com wrote:

> Hi,
>
> > Corey Gates wrote:
> >
> > > Jonathan,
> > >
> > > I believe you left out the "private-key" in the nonce computation in
> > > draft-rosenberg-sip-http-pnonce-00.txt.  The nonce should be:
> > >
> > > nonce = H(source-IP: > > protected>:round-time:private-key)
> > >
> > > Without this the nonce could be generated.
> >
> > I fail to see what you've gained by hashing the password into
> > the nonce,
> > the nonce is only really
> > there so the server can be sure the client's messages aren't
> > just being
> > replayed, the client will hash in the password to provide
> > authentication. (Obviously this explanation is very simplistic.)
>
> As in RFC 2617, I think what was meant here was, that the private-key is
> just some data only known to the server and not the shared secret
> (password).
>
> I think this would also make sense for pnonce, since otherwise all
> information contained in the hash can readily be found from the message
> itself.

True although is only a suggestion for nonce generation, and digest
authentication is quite weak.  The real problem with this draft is it is
just plain broken. To my mind it is also unfixable until backwards
compatibility is lost i.e. the client explicitly includes the required
headers in the credentials along with the server provided time stamp. Unless
this is done a MITM attack will always be possible. (Then again I could be
wrong about the fixability as security is a hard problem, not suited to the
amateur I am.)

James Undery


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Tue Jun 19 08:45:45 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19884;
	Tue, 19 Jun 2001 08:45:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21592;
	Tue, 19 Jun 2001 08:36:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21563
	for ; Tue, 19 Jun 2001 08:36:35 -0400 (EDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19454
	for ; Tue, 19 Jun 2001 08:35:59 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5JCXt928602
	for ; Tue, 19 Jun 2001 15:33:55 +0300 (EET DST)
Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Tue, 19 Jun 2001 15:34:41 +0300
Received: by esebh24nok with Internet Mail Service (5.5.2652.78)
	id ; Tue, 19 Jun 2001 15:34:41 +0300
Message-ID: 
To: jdrosen@dynamicsoft.com
Cc: sip@ietf.org
Subject: RE: [Sip] Request header integrity in HTTP Digest
Date: Tue, 19 Jun 2001 15:34:36 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Jonathan,

This really sounds like a good idea.

However, the man-in-the-middle attacks discussed in the draft are still
viable in a scenario, where the server calculates the pnonce from an already
compromised set of headers.

For example, the REGISTER case with altered Contact: 

            UA               MITM             Server
            |--Contact------->|--ContactX------>|
            |                 |                 |  Calculates pnonce
H(header:ContactX)
            |<-401, pnonce----|<--401, pnonce---|
Calculates  |                 |                 |
credentials |                 |                 |
            |-Contact, cred.->|ContactX, cred-->|  Authentication passes,
                                                   Stores wrong Contact

I admit, these kinds of attacks are probably a little trickier to make, but
the main idea still has to fail, because the headers aren't included in the
integrity hash at the client's side. 

Of course, the client can produce a pnonce of its own (call it p-cnonce),
but this won't help either, since the server doesn't know how to integrity
check the headers with p-cnonce. Real integrity protection has to be based
on a shared secret between the server and the client.

But for some increase in integrity protection, this idea has merit. Also,
since pnonce is completely an implementation issue at the server side, it is
deployable.

Br,
Aki	

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 16 June, 2001 15:51
> To: 'sip@ietf.org'
> Subject: [Sip] Request header integrity in HTTP Digest
> 
> 
> Folks,
> 
> I've just submitted a new I-D to the archives. It proposes a 
> mechanism that
> allows HTTP Digest to provide request header integrity. This 
> means that the
> server can verify that the request was sent by a specific 
> party, and that
> certain header fields, such as the To, From, Contact, and 
> Call-ID, were not
> altered.
> 
> Amazingly, the proposal requires no protocol changes in the 
> way HTTP Digest
> works, nor does it require any change in the behavior of 
> clients. It is
> purely a server implementation choice. I call the proposed approach
> "predictive nonces", as its based on a computation of the 
> nonce based on a
> prediction of the values of specific invariant headers in the 
> resubmitted
> request (namely, that they are unchanged from the original 
> request that is
> being challenged). It also works for HTTP, but is less useful 
> there. The
> approach is totally stateless as well, unlike one time 
> nonces, which are
> not.
> 
> Until the draft appears in the archives, you can pick up a copy at:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-sip-http-pnonce-00.txt
> 
> I think this will address some important security concerns 
> raised on the
> list, many of which are summarized in the draft.
> 
> Comments, questions, and criticisms welcome as always.
> 
> Thanks,
> Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>  
> 
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip
> 

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jun 19 12:23:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25797
	for ; Tue, 19 Jun 2001 12:23:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1ED5844337; Tue, 19 Jun 2001 12:24:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from dryline-fw.wireless-sys.com (dryline-fw.yyz.somanetworks.com [216.126.67.45])
	by lists.bell-labs.com (Postfix) with ESMTP id 9032344336
	for ; Tue, 19 Jun 2001 12:23:45 -0400 (EDT)
Received: from crusher.yyz.somanetworks.com.wireless-sys.com (osas@crusher.yyz.somanetworks.com [10.11.10.191])
	by dryline-fw.wireless-sys.com (8.8.7/8.8.7) with SMTP id MAA10189;
	Tue, 19 Jun 2001 12:23:41 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15151.31885.77045.435235@crusher.yyz.somanetworks.com>
From: Ovidiu Sas 
To: "Menon, Sunil" 
Cc: "'sip@lists.bell-labs.com'" 
Subject: [SIP] G729AB vs G729A
In-Reply-To: <594A6AF62343D511B4750060CF20BAF305E5B8@sonusdc5.sonusnet.com>
References: <594A6AF62343D511B4750060CF20BAF305E5B8@sonusdc5.sonusnet.com>
X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 19 Jun 2001 12:23:40 -0400 (EDT)
Content-Transfer-Encoding: 7bit


  Take a look in "draft-ietf-avt-profile-new-10.txt"
  On page 16: 4.5.5 G729 you have a description of
G729/G729A/G729B/G729AB:

   A G729 RTP packet may consist of zero or more G.729 or G.729 Annex A
   frames, followed by zero or one G.729 Annex B frames. The presence of
   a comfort noise frame can be deduced from the length of the RTP
   payload.



   In SDP you need to specify the payload type (18 - default) and the
vocoder need to handle by itself the silence packets.


   Hope this help,
              Ovidiu


____________________
Menon, Sunil writes:
 > Hi All,
 > 	Does anyone know how one would indicate G729AB vs G729A as the
 > preferred codec in SDP ? 
 > 
 > Thanks
 > Sunil Menon
 > Sonus Networks
 > 


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


From sip-admin@ietf.org  Tue Jun 19 13:01:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26998;
	Tue, 19 Jun 2001 13:01:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29375;
	Tue, 19 Jun 2001 12:12:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29346
	for ; Tue, 19 Jun 2001 12:12:50 -0400 (EDT)
Received: from go-postal.hearme.com (go-postal.hearme.com [206.233.215.57])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25303
	for ; Tue, 19 Jun 2001 12:12:13 -0400 (EDT)
Received: by go-postal.hearme.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 19 Jun 2001 09:12:07 -0700
Message-ID: 
From: Corey Gates 
To: "'James Undery'" 
Cc: sip@ietf.org
Subject: RE: [Sip] Request header integrity in HTTP Digest
Date: Tue, 19 Jun 2001 09:12:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org


James Undery wrote:

> 
> aki.niemi@nokia.com wrote:
> 
> > Hi,
> >
> > > Corey Gates wrote:
> > >
> > > > Jonathan,
> > > >
> > > > I believe you left out the "private-key" in the nonce computation in
> > > > draft-rosenberg-sip-http-pnonce-00.txt.  The nonce should be:
> > > >
> > > > nonce = H(source-IP: > > > protected>:round-time:private-key)
> > > >
> > > > Without this the nonce could be generated.
> > >
> > > I fail to see what you've gained by hashing the password into
> > > the nonce,
> > > the nonce is only really
> > > there so the server can be sure the client's messages aren't
> > > just being
> > > replayed, the client will hash in the password to provide
> > > authentication. (Obviously this explanation is very simplistic.)
> >
> > As in RFC 2617, I think what was meant here was, that the private-key is
> > just some data only known to the server and not the shared secret
> > (password).
> >
> > I think this would also make sense for pnonce, since otherwise all
> > information contained in the hash can readily be found from the message
> > itself.
> 
> True although is only a suggestion for nonce generation, and digest
> authentication is quite weak.  The real problem with this draft is it is
> just plain broken. To my mind it is also unfixable until backwards
> compatibility is lost i.e. the client explicitly includes the required
> headers in the credentials along with the server provided time stamp.
Unless
> this is done a MITM attack will always be possible. (Then again I could be
> wrong about the fixability as security is a hard problem, not suited to
the
> amateur I am.)
> 
> James Undery

I agree that the draft is broken with respect to MITM attacks.  But without
the private-key known only to the server, the nonce generation is also
broken such that an attacker can get a client to generate credentials for
nonces that can be used later, even when the client is offline and the
attacker is no longer in the "middle"!

Again, I agree that Man-in-the-Middle attacks are not addressed in the
draft.  I just don't want someone to go off and implement a nonce generation
scheme that is less secure then RFC 2617...

Corey Gates






_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jun 19 14:50:16 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00251
	for ; Tue, 19 Jun 2001 14:50:16 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7E02B44339; Tue, 19 Jun 2001 14:50:46 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgw3.netvision.net.il (mailgw3.netvision.net.il [194.90.1.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 4758F44336
	for ; Tue, 19 Jun 2001 14:49:54 -0400 (EDT)
Received: from gallery2000 ([212.143.17.59])
	by mailgw3.netvision.net.il (8.9.3/8.9.3) with SMTP id VAA03289
	for ; Tue, 19 Jun 2001 21:48:09 +0300 (IDT)
Message-ID: <001501c08250$c58339c0$3b118fd4@GTS>
From: "amir gts" 
To: 
Subject: [SIP] Sip Proxy States
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0012_01C08261.8857ADE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 19 Jan 2001 21:48:17 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01C08261.8857ADE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello All.
I'm working on development of a Sip Proxy and I'd like=20
to know if anyone knows where can I find some info regarding
Sip Proxy States & Architecture.
Thanks in Advance.
Amir.

------=_NextPart_000_0012_01C08261.8857ADE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









Hello All.


I'm working on development of a Sip =
Proxy and I'd=20
like 


to know if anyone knows where =
can I find some=20
info regarding


Sip Proxy States & =
Architecture.


Thanks in Advance.


Amir.


------=_NextPart_000_0012_01C08261.8857ADE0--


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


From sip-admin@lists.bell-labs.com  Tue Jun 19 18:01:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06277
	for ; Tue, 19 Jun 2001 18:01:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3F7424433F; Tue, 19 Jun 2001 18:02:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.pingtel.com (mail.pingtel.com [216.91.1.131])
	by lists.bell-labs.com (Postfix) with ESMTP id ADBFC44336
	for ; Tue, 19 Jun 2001 18:01:12 -0400 (EDT)
Received: from stbarth.pingtel.com (cdhcp117.pingtel.com [10.1.1.117])
	by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id f5JLxNd27319;
	Tue, 19 Jun 2001 17:59:23 -0400
Message-Id: <5.1.0.14.2.20010619175631.02e694e0@mail.pingtel.com>
X-Sender: jbatson@mail.pingtel.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: "Ashhar Farhan" ,
        "sip@lists.bell-labs.com" 
From: Jay Batson 
Subject: Re: [SIP] Authentication and billing through proxy/re-direct
  server
In-Reply-To: <20010604072807.15583.qmail@mailweb25.rediffmail.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_124484489==_.ALT"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 19 Jun 2001 17:59:06 -0400

--=====================_124484489==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

There is another possibility that "real commercial systems" might use (in 
fact, are likely to use...):

- Charge only for PSTN gateway transit.
- Sessions that stay on the IP net (only) are built into a base 
bandwidth/connectivity fee.

In this case, CDRs generated by the gateway will provide sufficient 
information about PSTN connectivity to create billing info, wouldn't 
they?  Neither the proxy nor the originating (IP-network-resident) UA need 
to know / do anything....

-jb

At 03:28 AM 6/4/01, Ashhar Farhan wrote:
>in a typical next gen telco setup, the billing is centralised and their 
>Point of presence are basically SIP servers that gateway to PSTN cloud.
>
>the INVITE gets redirected/proxied from the central server and the is 
>resend to the gateway (a sip server).
>here, we have an issue of user authentication. the user has to be 
>authenticated by the redirect/proxy server. the authentication (as per the 
>SIP recommendations) should be md5 digest.
>the scheme would be that the redirect/proxy should generate a digest over 
>the redirected INVITE request using the nonce and password of the intended 
>server.
>
>billing systems are usually needed to be centralised (esp. in those next 
>gen telcos where the servers are operated by franchises). this is a 
>commercial requirement of SIP operations.
>
>the 2543.bis does not explicitly talk of the redirect/proxies 
>authenticating requests for the gateways.
>
>the second issue:
>the call minutes are the accepted billing mechanism for atleast the next 
>couple of years. to support billing, accurate times of call start and end 
>are important.
>the call times maybe at variance between the client and the server due to 
>a the RTT nature of messaging itself. In that case, it will be advisable, 
>from a caller perspective to know when exactly did the call get 
>disconnected (a second's delay can roll the call over to the next minute) 
>and how long did the call last - as per server's record. Although MESSAGE 
>can be used for this, i would rather believe that a more intrinsic method 
>must be available to support this that can update the caller's own 'call 
>meter'.
>
>- farhan@hotfoon.com
>
>
>
>_____________________________________________________
>Chat with your friends as soon as they come online. Get Rediff Bol at
>http://bol.rediff.com
>
>
>
>
>
>_______________________________________________
>This list is for continuing development of the SIP protocol.
>The sip-implementor's list is the place to discuss implementation,
>and to receive advice on understanding existing sip.
>To subscribe to it, send mail to
>sip-implementors-request@cs.columbia.edu with "subscribe" in the body.

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


--=====================_124484489==_.ALT
Content-Type: text/html; charset="us-ascii"


There is another possibility that "real commercial systems"
might use (in fact, are likely to use...):


- Charge only for PSTN gateway transit.

- Sessions that stay on the IP net (only) are built into a base
bandwidth/connectivity fee.


In this case, CDRs generated by the gateway will provide sufficient
information about PSTN connectivity to create billing info, wouldn't
they?  Neither the proxy nor the originating (IP-network-resident)
UA need to know / do anything....


-jb


At 03:28 AM 6/4/01, Ashhar Farhan wrote:


in a typical next gen telco setup,
the billing is centralised and their Point of presence are basically SIP
servers that gateway to PSTN cloud.


the INVITE gets redirected/proxied from the central server and the is
resend to the gateway (a sip server).

here, we have an issue of user authentication. the user has to be
authenticated by the redirect/proxy server. the authentication (as per
the SIP recommendations) should be md5 digest. 

the scheme would be that the redirect/proxy should generate a digest over
the redirected INVITE request using the nonce and password of the
intended server.


billing systems are usually needed to be centralised (esp. in those next
gen telcos where the servers are operated by franchises). this is a
commercial requirement of SIP operations.


the 2543.bis does not explicitly talk of the redirect/proxies
authenticating requests for the gateways.


the second issue:

the call minutes are the accepted billing mechanism for atleast the next
couple of years. to support billing, accurate times of call start and end
are important.

the call times maybe at variance between the client and the server due to
a the RTT nature of messaging itself. In that case, it will be advisable,
from a caller perspective to know when exactly did the call get
disconnected (a second's delay can roll the call over to the next minute)
and how long did the call last - as per server's record. Although MESSAGE
can be used for this, i would rather believe that a more intrinsic method
must be available to support this that can update the caller's own 'call
meter'.


- farhan@hotfoon.com





_____________________________________________________

Chat with your friends as soon as they come online. Get Rediff Bol
at

http://bol.rediff.com








_______________________________________________

This list is for continuing development of the SIP protocol.

The sip-implementor's list is the place to discuss implementation,

and to receive advice on understanding existing sip.

To subscribe to it, send mail to 

sip-implementors-request@cs.columbia.edu with "subscribe" in
the body.



-------------

PingMe!

Jay Batson

CEO

Pingtel Corp.

mailto:jbatson@pingtel.com

781-938-5306 (office)




--=====================_124484489==_.ALT--


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


From sip-admin@lists.bell-labs.com  Tue Jun 19 18:40:34 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06873
	for ; Tue, 19 Jun 2001 18:40:33 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4503244354; Tue, 19 Jun 2001 18:41:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.pingtel.com (mail.pingtel.com [216.91.1.131])
	by lists.bell-labs.com (Postfix) with ESMTP id 95E9244341
	for ; Tue, 19 Jun 2001 18:40:15 -0400 (EDT)
Received: from stbarth.pingtel.com (cdhcp117.pingtel.com [10.1.1.117])
	by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id f5JMcNd28018;
	Tue, 19 Jun 2001 18:38:23 -0400
Message-Id: <5.1.0.14.2.20010619183318.02eea9c0@mail.pingtel.com>
X-Sender: jbatson@mail.pingtel.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: "Venkatesh Venkataramanan" ,
        "'Jean-Francois Mule'" ,
        "'Rohan Mahy'" , islain@cisco.com,
        sip@lists.bell-labs.com
From: Jay Batson 
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt
In-Reply-To: <79FEAA5FABA7D411BF580001023D1BBD1160C0@mailserver.sylantro
 .com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_126824854==_.ALT"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 19 Jun 2001 18:37:19 -0400

--=====================_126824854==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

My comments aren't timely, so my apologies.

Venkatesh's comments are also consistent with typical IETF protocol / 
application design.  Example:  Neither SMTP nor POP/IMAP specify how the 
email "user agent" (Eudora, Netscape, Outlook) provides visual indication 
of email message priority (X-Priority).

The creator of a given user agent defines its own user interfaces to 
information that is provided in the standardized lower later protocol.  End 
users then choose among available user agents (and behaviors) to get their 
desired interaction.

Applications at either end of a transaction may want to agree on 
Experimental extensions to show more information, such as the type that 
Jean-Francois suggests.  In fact, this is how X-Priority came into being in 
email!  Eudora just up and did it one day, and everybody else did what they 
did!

-jb


At 03:29 PM 4/26/01, Venkatesh Venkataramanan wrote:
>I would think that the functionality of SIP ends when it delivers the
>requested Notification. What the phone/the entity does with it(light a lamp,
>render the same on a display, provide stutter dial tone or audible
>notification et al) is more a matter of the local policy (depending upon the
>capabilities of the end point).
>
>Venkatesh
>
>-----Original Message-----
>From: Jean-Francois Mule [mailto:jfmule@clarent.com]
>Sent: Thursday, April 26, 2001 12:42 AM
>To: 'Rohan Mahy'; islain@cisco.com; sip@lists.bell-labs.com
>Subject: [SIP] draft-mahy-sip-message-waiting-01.txt
>
>
>Hi,
>The I-D mentions audible/visual message waiting indications in the
>introduction but then remains silent on this.
>Has there been any considerations to include the type of mwi
>(audible/visual) as optional in application/simple-message-summary?
>Jean-Francois Mule.
>Clarent
>
>_______________________________________________
>This list is for continuing development of the SIP protocol.
>The sip-implementor's list is the place to discuss implementation,
>and to receive advice on understanding existing sip.
>To subscribe to it, send mail to
>sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
>
>
>_______________________________________________
>This list is for continuing development of the SIP protocol.
>The sip-implementor's list is the place to discuss implementation,
>and to receive advice on understanding existing sip.
>To subscribe to it, send mail to
>sip-implementors-request@cs.columbia.edu with "subscribe" in the body.

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


--=====================_126824854==_.ALT
Content-Type: text/html; charset="us-ascii"


My comments aren't timely, so my apologies.


Venkatesh's comments are also consistent with typical IETF protocol /
application design.  Example:  Neither SMTP nor POP/IMAP
specify how the email "user agent" (Eudora, Netscape, Outlook)
provides visual indication of email message priority
(X-Priority).


The creator of a given user agent defines its own user interfaces to
information that is provided in the standardized lower later
protocol.  End users then choose among available user agents (and
behaviors) to get their desired interaction.


Applications at either end of a transaction may want to agree on
Experimental extensions to show more information, such as the type that
Jean-Francois suggests.  In fact, this is how X-Priority came into
being in email!  Eudora just up and did it one day, and everybody
else did what they did!


-jb




At 03:29 PM 4/26/01, Venkatesh Venkataramanan wrote:


I would think that the
functionality of SIP ends when it delivers the

requested Notification. What the phone/the entity does with it(light a
lamp,

render the same on a display, provide stutter dial tone or audible

notification et al) is more a matter of the local policy (depending upon
the

capabilities of the end point).


Venkatesh


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

From: Jean-Francois Mule
[mailto:jfmule@clarent.com]

Sent: Thursday, April 26, 2001 12:42 AM

To: 'Rohan Mahy'; islain@cisco.com; sip@lists.bell-labs.com

Subject: [SIP] draft-mahy-sip-message-waiting-01.txt




Hi,

The I-D mentions audible/visual message waiting indications in the

introduction but then remains silent on this.

Has there been any considerations to include the type of mwi

(audible/visual) as optional in application/simple-message-summary?

Jean-Francois Mule.

Clarent


_______________________________________________

This list is for continuing development of the SIP protocol.

The sip-implementor's list is the place to discuss implementation,

and to receive advice on understanding existing sip.

To subscribe to it, send mail to 

sip-implementors-request@cs.columbia.edu with "subscribe" in
the body.




_______________________________________________

This list is for continuing development of the SIP protocol.

The sip-implementor's list is the place to discuss implementation,

and to receive advice on understanding existing sip.

To subscribe to it, send mail to 

sip-implementors-request@cs.columbia.edu with "subscribe" in
the body.



-------------

PingMe!

Jay Batson

CEO

Pingtel Corp.

mailto:jbatson@pingtel.com

781-938-5306 (office)




--=====================_126824854==_.ALT--


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


From sip-admin@lists.bell-labs.com  Tue Jun 19 22:03:34 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11238
	for ; Tue, 19 Jun 2001 22:03:34 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6799B44341; Tue, 19 Jun 2001 22:04:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ms010ma2.cnc.intra (unknown [210.53.66.252])
	by lists.bell-labs.com (Postfix) with ESMTP id 13D7B44336
	for ; Tue, 19 Jun 2001 22:03:00 -0400 (EDT)
Received: from ms010ma2.cnc.intra ([10.1.1.252]) by ms010ma2.cnc.intra with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 20 Jun 2001 10:05:38 +0800
Received: from cncserver02.cnc.intra ([10.0.16.4]) by ms010ma2.cnc.intra with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 20 Jun 2001 10:05:38 +0800
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Message-ID: <385BFEF1F74C0246A37EF6B5E18F6EF156A133@cncserver02.cnc.intra>
Thread-Topic: SIP digest, Vol 1 #1080 - 2 msgs
Thread-Index: AcD4EKu/W+libmH/S7uFdzYijoG0hwBFuEFw
From: "Xin Zhou(TS)" 
To: 
X-OriginalArrivalTime: 20 Jun 2001 02:05:38.0448 (UTC) FILETIME=[801B2100:01C0F92D]
Subject: [SIP] help
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 10:05:15 +0800
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id WAA11238


hi,alll
I am from china netcom,a new carrier in china .in this field ,i am just
a layman,hehe
I am doing some rearch on network convergence,and in these days ,what
confused me most is 
as a  carrier,service provider,what tech we should take?h.323,sip?when
we talking about the interworking
between PSTN and IP,some services just like  the follow me ,LNP.. I
donnot know which tech is more acceptable if we adopt
The softswitch archetech or PINT..
Jude
-----ԭʼÓʼþ-----
·¢¼þÈË: sip-request@lists.bell-labs.com
[mailto:sip-request@lists.bell-labs.com]
·¢ËÍʱ¼ä: 2001Äê6ÔÂ19ÈÕ 0:01
ÊÕ¼þÈË: sip@lists.bell-labs.com
Ö÷Ìâ: SIP digest, Vol 1 #1080 - 2 msgs


Send SIP mailing list submissions to
	sip@lists.bell-labs.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.bell-labs.com/mailman/listinfo/sip
or, via email, send a message with subject or body 'help' to
	sip-request@lists.bell-labs.com

You can reach the person managing the list at
	sip-admin@lists.bell-labs.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of SIP digest..."


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


From sip-admin@lists.bell-labs.com  Tue Jun 19 23:25:34 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA13227
	for ; Tue, 19 Jun 2001 23:25:34 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 99C5F4435A; Tue, 19 Jun 2001 23:26:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb30.rediffmail.com (unknown [203.199.83.150])
	by lists.bell-labs.com (Postfix) with SMTP id 7FB3544352
	for ; Tue, 19 Jun 2001 23:25:35 -0400 (EDT)
Received: (qmail 12460 invoked by uid 510); 20 Jun 2001 03:29:31 -0000
Message-ID: <20010620032931.12459.qmail@mailweb30.rediffmail.com>
Received: from unknown (203.124.230.68) by rediffmail.com via HTTP; 20 Jun 2001 03:29:31 -0000
MIME-Version: 1.0
To: "jbatson@pingtel.com" ,
        "sip@lists.bell-labs.com" 
Subject:  Re: Re: [SIP] Authentication and billing through proxy/re-direct server
From: "Ashhar Farhan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 20 Jun 2001 03:29:31 -0000
Content-Transfer-Encoding: 7bit

jb wrote -

>>There is another possibility that "real commercial systems" might use (in fact, are likely to use...):
>>
>>- Charge only for PSTN gateway transit.
>>- Sessions that stay on the IP net (only) are built into a base bandwidth/connectivity fee.

>>In this case, CDRs generated by the gateway will provide sufficient information about PSTN connectivity to create billing info, wouldn't they?  Neither the proxy nor the originating (IP-network-resident) UA need 
to know / do anything....

I completely agree that it is PSTN transit that will be charged in for the next couple of years. the issue is who will authenticate CDRs generated by a gateway? if we are talking of a network of PSTN gateways and a central settlement system, we need a way of acknowledging the call timings and QoS at both ends to bill the call.
for instance:
1) how does a gateway know whether the caller is credit worthy? if we require a separate TLS style connection to the proxy for billing purpose, it is actually simpler to just make the proxy hold the state information and pass setup and cleardown messages over the same pipe.

2)we do not require TLS pipe between the UA and the proxy to authenticate itself. i dont see why we should require a TLS session between the gateway and the proxy to authenticate the incoming callers.

i am problematizing the issue of third party authentication for callers. this is a commercial issue with calling card vendors, meta-network operators (like itxc), or resellers (like yahoo, msn, icq resold net2phone).

- farhan@hotfoon.com

_____________________________________________________
Buy Lagaan & Yaadein music for 30% less.
Avail this special offer at http://shopping.rediff.com/shopping/music/offerrediffmailer.htm 




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


From sip-admin@lists.bell-labs.com  Wed Jun 20 00:48:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14491
	for ; Wed, 20 Jun 2001 00:48:34 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EC48344345; Wed, 20 Jun 2001 00:49:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by lists.bell-labs.com (Postfix) with SMTP id C01D744336
	for ; Wed, 20 Jun 2001 00:48:48 -0400 (EDT)
Received: (qmail 6097 invoked by uid 500); 20 Jun 2001 04:37:52 -0000
From: Pat Calhoun 
To: Ashhar Farhan 
Cc: "jbatson @ pingtel . com" ,
        "sip @ lists . bell-labs . com" 
Subject: Re: Re: [SIP] Authentication and billing through proxy/re-direct server
Message-ID: <20010619213752.T17928@charizard.diameter.org>
Mail-Followup-To: Ashhar Farhan ,
	"jbatson @ pingtel . com" ,
	"sip @ lists . bell-labs . com" 
References: <20010620032931.12459.qmail@mailweb30.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010620032931.12459.qmail@mailweb30.rediffmail.com>; from afarhan@rediffmail.com on Wed, Jun 20, 2001 at 03:29:31AM -0000
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 19 Jun 2001 21:37:52 -0700

On Wed, Jun 20, 2001 at 03:29:31AM -0000, Ashhar Farhan wrote:
> I completely agree that it is PSTN transit that will be charged in for the next couple of years. the issue is who will authenticate CDRs generated by a gateway? if we are talking of a network of PSTN gateways and a central settlement system, we need a way of acknowledging the call timings and QoS at both ends to bill the call.
> for instance:
> 1) how does a gateway know whether the caller is credit worthy? if we require a separate TLS style connection to the proxy for billing purpose, it is actually simpler to just make the proxy hold the state information and pass setup and cleardown messages over the same pipe.
> 
> 2)we do not require TLS pipe between the UA and the proxy to authenticate itself. i dont see why we should require a TLS session between the gateway and the proxy to authenticate the incoming callers.
> 
> i am problematizing the issue of third party authentication for callers. this is a commercial issue with calling card vendors, meta-network operators (like itxc), or resellers (like yahoo, msn, icq resold net2phone).

I suppose I may be missing something obvious here, but this is exactly what the AAA
WG has been working on solving for quite some time now.

PatC

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


From sip-admin@lists.bell-labs.com  Wed Jun 20 04:46:32 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00727
	for ; Wed, 20 Jun 2001 04:46:32 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5E9EF44338; Wed, 20 Jun 2001 04:47:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62])
	by lists.bell-labs.com (Postfix) with ESMTP id 54F1844336
	for ; Wed, 20 Jun 2001 04:46:42 -0400 (EDT)
Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp4.cluster.oleane.net with SMTP id f5K8kf081417 for ; Wed, 20 Jun 2001 10:46:42 +0200 (CEST)
Message-ID: <00ba01c0f965$72ce26e0$0601a8c0@oleane.com>
From: "Peter Lewis" 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00B7_01C0F976.3613D360"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: [SIP] SIP 2002
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 10:46:07 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_00B7_01C0F976.3613D360
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

The International SIP Summit, the largest international gathering =
exclusively dedicated to SIP, will take place January 15 to 18, 2002 in =
Paris (Sofitel Bercy).=20

A call for papers is online at: =
http://www.upperside.fr/sip2002/sip2002intro.htm

------=_NextPart_000_00B7_01C0F976.3613D360
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable













The International SIP Summit, the =
largest=20
international gathering exclusively dedicated to SIP, will take place=20
January 15 to 18, 2002 in Paris (Sofitel Bercy). =



 


A call for papers is online at: http://www.uppe=
rside.fr/sip2002/sip2002intro.htm


------=_NextPart_000_00B7_01C0F976.3613D360--


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


From sip-admin@lists.bell-labs.com  Wed Jun 20 09:01:33 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05652
	for ; Wed, 20 Jun 2001 09:01:33 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BD8D744355; Wed, 20 Jun 2001 09:02:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id A7F8C44336
	for ; Wed, 20 Jun 2001 09:01:54 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07683;
	Wed, 20 Jun 2001 09:01:52 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA03392;
	Wed, 20 Jun 2001 09:01:55 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 20 Jun 2001 09:01:53 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF0446559E@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Jay Batson'" ,
        Ashhar Farhan , sip@lists.bell-labs.com
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	er
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F989.2CFFEEE0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 09:01:52 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F989.2CFFEEE0
Content-Type: text/plain;
	charset="iso-8859-1"

Just for grins, what would you expect the charging to look like when the
terminating end is on a different network from the originating end, but they
were both sipphones?  Suppose there were three networks (a transit network
as well as the originating and terminating networks)?  Suppose there was
an enterprise network (no internal charging) connected to a public (IP)
network
that charged by the minute?
 
I don't want to start a debate on billing possibilities.  I do think that
you have to
accept that CDRs may have to be generated at a few places in the network.
I myself am not wild about UAs doing CDR generation.  I think proxy servers 
can do that.  The piece of information the PS doesn't have is the exact
connection
time information.  We may want to be able to get that sent on a BYE.  
 
Suppose you just thought of this stuff as statistics.  There are several
interesting
statistics you may wish to gather on a call (lost packets for example).
Sure,
you could make this a management function, but you are then faced with
storage
and other issues associated with a very large number of endpoints.  If you
could
report statistics on a BYE, the PS could then generate the CDR.
 
This may also help a problem we are currently calling "session management".
There
is some work at the Softswitch Consortium on this.  It deals with the
following
practical problem - your customer service center gets the following call "I
was
just talking to my mother and I couldn't hear her".  Okay, what equipment
was used
on that call, and where did it go wrong?  To make that really work EVERY
device
that participates in some way on the call needs to report information on the
call,
and it has to do so proactively.  This is equivalent to a CDR with more
information
(statistics).  Yes, we could get UAs to generate them, but we could also
just pass
up the info on BYE and let the PS save it, massage it, and send it on it's
way.
 
Brian
 
 
 

-----Original Message-----
From: Jay Batson [mailto:jbatson@pingtel.com]
Sent: Tuesday, June 19, 2001 5:59 PM
To: Ashhar Farhan; sip@lists.bell-labs.com
Subject: Re: [SIP] Authentication and billing through proxy/re-direct server


There is another possibility that "real commercial systems" might use (in
fact, are likely to use...):

- Charge only for PSTN gateway transit.
- Sessions that stay on the IP net (only) are built into a base
bandwidth/connectivity fee.

In this case, CDRs generated by the gateway will provide sufficient
information about PSTN connectivity to create billing info, wouldn't they?
Neither the proxy nor the originating (IP-network-resident) UA need to know
/ do anything....

-jb

At 03:28 AM 6/4/01, Ashhar Farhan wrote:


in a typical next gen telco setup, the billing is centralised and their
Point of presence are basically SIP servers that gateway to PSTN cloud.

the INVITE gets redirected/proxied from the central server and the is resend
to the gateway (a sip server).
here, we have an issue of user authentication. the user has to be
authenticated by the redirect/proxy server. the authentication (as per the
SIP recommendations) should be md5 digest. 
the scheme would be that the redirect/proxy should generate a digest over
the redirected INVITE request using the nonce and password of the intended
server.

billing systems are usually needed to be centralised (esp. in those next gen
telcos where the servers are operated by franchises). this is a commercial
requirement of SIP operations.

the 2543.bis does not explicitly talk of the redirect/proxies authenticating
requests for the gateways.

the second issue:
the call minutes are the accepted billing mechanism for atleast the next
couple of years. to support billing, accurate times of call start and end
are important.
the call times maybe at variance between the client and the server due to a
the RTT nature of messaging itself. In that case, it will be advisable, from
a caller perspective to know when exactly did the call get disconnected (a
second's delay can roll the call over to the next minute) and how long did
the call last - as per server's record. Although MESSAGE can be used for
this, i would rather believe that a more intrinsic method must be available
to support this that can update the caller's own 'call meter'.

- farhan@hotfoon.com



_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com  





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

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




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









Just for 
grins, what would you expect the charging to look like when 
the


terminating 
end is on a different network from the originating end, but 
they


were both 
sipphones?  Suppose there were three networks (a transit 
network


as well as 
the originating and terminating networks)?  Suppose there 
was


an enterprise 
network (no internal charging) connected to a public (IP) 
network


that charged 
by the minute?


 


I don't want 
to start a debate on billing possibilities.  I do think that you have 
to


accept that 
CDRs may have to be generated at a few places in the 
network.


I myself am 
not wild about UAs doing CDR generation.  I think proxy servers 



can do 
that.  The piece of information the PS doesn't have is the exact 
connection


time 
information.  We may want to be able to get that sent on a BYE.  



 


Suppose you 
just thought of this stuff as statistics.  There are several 
interesting


statistics 
you may wish to gather on a call (lost packets for example).  
Sure,


you could 
make this a management function, but you are then faced with 
storage


and other 
issues associated with a very large number of endpoints.  If you 
could


report 
statistics on a BYE, the PS could then generate the CDR.


 


This may also 
help a problem we are currently calling "session management".  
There


is some work 
at the Softswitch Consortium on this.  It deals with the 
following


practical 
problem - your customer service center gets the following call "I 
was


just talking 
to my mother and I couldn't hear her".  Okay, what equipment was 
used


on that call, 
and where did it go wrong?  To make that really work EVERY 
device


that 
participates in some way on the call needs to report information on the 
call,


and it has to 
do so proactively.  This is equivalent to a CDR with more 
information


(statistics).  Yes, we could get UAs to generate them, but we 
could also just pass


up the info 
on BYE and let the PS save it, massage it, and send it on it's 
way.


 


Brian


 


 


 



  
-----Original Message-----
From: Jay Batson 
  [mailto:jbatson@pingtel.com]
Sent: Tuesday, June 19, 2001 5:59 
  PM
To: Ashhar Farhan; sip@lists.bell-labs.com
Subject: Re: 
  [SIP] Authentication and billing through proxy/re-direct 
  server

There is another possibility that "real commercial 
  systems" might use (in fact, are likely to use...):

- Charge only for 
  PSTN gateway transit.
- Sessions that stay on the IP net (only) are built 
  into a base bandwidth/connectivity fee.

In this case, CDRs generated by 
  the gateway will provide sufficient information about PSTN connectivity to 
  create billing info, wouldn't they?  Neither the proxy nor the 
  originating (IP-network-resident) UA need to know / do 
  anything....

-jb

At 03:28 AM 6/4/01, Ashhar Farhan wrote:

  
in a typical next gen telco setup, 
    the billing is centralised and their Point of presence are basically SIP 
    servers that gateway to PSTN cloud.

the INVITE gets 
    redirected/proxied from the central server and the is resend to the gateway 
    (a sip server).
here, we have an issue of user authentication. the user 
    has to be authenticated by the redirect/proxy server. the authentication (as 
    per the SIP recommendations) should be md5 digest. 
the scheme would be 
    that the redirect/proxy should generate a digest over the redirected INVITE 
    request using the nonce and password of the intended server.

billing 
    systems are usually needed to be centralised (esp. in those next gen telcos 
    where the servers are operated by franchises). this is a commercial 
    requirement of SIP operations.

the 2543.bis does not explicitly talk 
    of the redirect/proxies authenticating requests for the gateways.

the 
    second issue:
the call minutes are the accepted billing mechanism for 
    atleast the next couple of years. to support billing, accurate times of call 
    start and end are important.
the call times maybe at variance between the 
    client and the server due to a the RTT nature of messaging itself. In that 
    case, it will be advisable, from a caller perspective to know when exactly 
    did the call get disconnected (a second's delay can roll the call over to 
    the next minute) and how long did the call last - as per server's record. 
    Although MESSAGE can be used for this, i would rather believe that a more 
    intrinsic method must be available to support this that can update the 
    caller's own 'call meter'.

- 
    farhan@hotfoon.com



_____________________________________________________
Chat 
    with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





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

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



------_=_NextPart_001_01C0F989.2CFFEEE0--

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


From sip-admin@lists.bell-labs.com  Wed Jun 20 10:33:33 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09138
	for ; Wed, 20 Jun 2001 10:33:33 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 33CD24435B; Wed, 20 Jun 2001 10:34:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 6670E44336
	for ; Wed, 20 Jun 2001 10:33:31 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5KEXUh03881;
	Wed, 20 Jun 2001 07:33:30 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AIX21405;
	Wed, 20 Jun 2001 07:33:28 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA14469; Wed, 20 Jun 2001 07:33:28 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15152.46136.176031.1595@thomasm-u1.cisco.com>
To: "Rosen, Brian" 
Cc: "'Jay Batson'" ,
        Ashhar Farhan , sip@lists.bell-labs.com
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	er
In-Reply-To: <4FBEA8857476D311A03300204840E1CF0446559E@whq-msgusr-02.pit.comms.marconi.com>
References: <4FBEA8857476D311A03300204840E1CF0446559E@whq-msgusr-02.pit.comms.marconi.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 07:33:28 -0700 (PDT)
Content-Transfer-Encoding: 7bit


I agree with Brian that "statistics" is a far
better word to use than "billing" because it
doesn't set off alarms. However, if the statistics
are going to be used in such a way that fraudlent
statistics could result in theft, that must
obviously be defended against. There is no set
answer here on how one can do this. To be free
from fraud, a trusted device *in the media path*
must be capable of determining session start and
end, etc. Not the signaling path; it can be
duped. For calls terminating in a trusted PSTN
gateway, you can obviously generate statistics
there. However, for calls that begin and terminate
on untrusted devices (say, our Brian and my home
SIP phones), you either need some sort of middle
box, or you need to just get over any thought of
it being secure.

The Packetcable/manyfolks drafts use the "middle
box" approach for gating resources at the
untrusted edge by using RSVP/COPS at the access
router to delineate where resources are consumed
on the cable plant in the case of Packetcable. 
It should be noted that if Brian and I don't care
about elevated QoS, there is nothing that the
service provider can do to prevent us from having
a chat. Obviously, similar schemes can be hatched
for other scenarios such as DSL, cellular, etc.

	  Mike


Rosen, Brian writes:
 > Just for grins, what would you expect the charging to look like when the
 > terminating end is on a different network from the originating end, but they
 > were both sipphones?  Suppose there were three networks (a transit network
 > as well as the originating and terminating networks)?  Suppose there was
 > an enterprise network (no internal charging) connected to a public (IP)
 > network
 > that charged by the minute?
 >  
 > I don't want to start a debate on billing possibilities.  I do think that
 > you have to
 > accept that CDRs may have to be generated at a few places in the network.
 > I myself am not wild about UAs doing CDR generation.  I think proxy servers 
 > can do that.  The piece of information the PS doesn't have is the exact
 > connection
 > time information.  We may want to be able to get that sent on a BYE.  
 >  
 > Suppose you just thought of this stuff as statistics.  There are several
 > interesting
 > statistics you may wish to gather on a call (lost packets for example).
 > Sure,
 > you could make this a management function, but you are then faced with
 > storage
 > and other issues associated with a very large number of endpoints.  If you
 > could
 > report statistics on a BYE, the PS could then generate the CDR.
 >  
 > This may also help a problem we are currently calling "session management".
 > There
 > is some work at the Softswitch Consortium on this.  It deals with the
 > following
 > practical problem - your customer service center gets the following call "I
 > was
 > just talking to my mother and I couldn't hear her".  Okay, what equipment
 > was used
 > on that call, and where did it go wrong?  To make that really work EVERY
 > device
 > that participates in some way on the call needs to report information on the
 > call,
 > and it has to do so proactively.  This is equivalent to a CDR with more
 > information
 > (statistics).  Yes, we could get UAs to generate them, but we could also
 > just pass
 > up the info on BYE and let the PS save it, massage it, and send it on it's
 > way.
 >  
 > Brian
 >  
 >  
 >  
 > 
 > -----Original Message-----
 > From: Jay Batson [mailto:jbatson@pingtel.com]
 > Sent: Tuesday, June 19, 2001 5:59 PM
 > To: Ashhar Farhan; sip@lists.bell-labs.com
 > Subject: Re: [SIP] Authentication and billing through proxy/re-direct server
 > 
 > 
 > There is another possibility that "real commercial systems" might use (in
 > fact, are likely to use...):
 > 
 > - Charge only for PSTN gateway transit.
 > - Sessions that stay on the IP net (only) are built into a base
 > bandwidth/connectivity fee.
 > 
 > In this case, CDRs generated by the gateway will provide sufficient
 > information about PSTN connectivity to create billing info, wouldn't they?
 > Neither the proxy nor the originating (IP-network-resident) UA need to know
 > / do anything....
 > 
 > -jb
 > 
 > At 03:28 AM 6/4/01, Ashhar Farhan wrote:
 > 
 > 
 > in a typical next gen telco setup, the billing is centralised and their
 > Point of presence are basically SIP servers that gateway to PSTN cloud.
 > 
 > the INVITE gets redirected/proxied from the central server and the is resend
 > to the gateway (a sip server).
 > here, we have an issue of user authentication. the user has to be
 > authenticated by the redirect/proxy server. the authentication (as per the
 > SIP recommendations) should be md5 digest. 
 > the scheme would be that the redirect/proxy should generate a digest over
 > the redirected INVITE request using the nonce and password of the intended
 > server.
 > 
 > billing systems are usually needed to be centralised (esp. in those next gen
 > telcos where the servers are operated by franchises). this is a commercial
 > requirement of SIP operations.
 > 
 > the 2543.bis does not explicitly talk of the redirect/proxies authenticating
 > requests for the gateways.
 > 
 > the second issue:
 > the call minutes are the accepted billing mechanism for atleast the next
 > couple of years. to support billing, accurate times of call start and end
 > are important.
 > the call times maybe at variance between the client and the server due to a
 > the RTT nature of messaging itself. In that case, it will be advisable, from
 > a caller perspective to know when exactly did the call get disconnected (a
 > second's delay can roll the call over to the next minute) and how long did
 > the call last - as per server's record. Although MESSAGE can be used for
 > this, i would rather believe that a more intrinsic method must be available
 > to support this that can update the caller's own 'call meter'.
 > 
 > - farhan@hotfoon.com
 > 
 > 
 > 
 > _____________________________________________________
 > Chat with your friends as soon as they come online. Get Rediff Bol at
 > http://bol.rediff.com  
 > 
 > 
 > 
 > 
 > 
 > _______________________________________________
 > This list is for continuing development of the SIP protocol.
 > The sip-implementor's list is the place to discuss implementation,
 > and to receive advice on understanding existing sip.
 > To subscribe to it, send mail to 
 > sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
 > 
 > -------------
 > PingMe!
 > Jay Batson
 > CEO
 > Pingtel Corp.
 > mailto:jbatson@pingtel.com  
 > 781-938-5306 (office)
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
Just for 
 > grins, what would you expect the charging to look like when 
 > the

 > 
terminating 
 > end is on a different network from the originating end, but 
 > they

 > 
were both 
 > sipphones?  Suppose there were three networks (a transit 
 > network

 > 
as well as 
 > the originating and terminating networks)?  Suppose there 
 > was

 > 
an enterprise 
 > network (no internal charging) connected to a public (IP) 
 > network

 > 
that charged 
 > by the minute?

 > 
 color=#0000ff> 

 > 
I don't want 
 > to start a debate on billing possibilities.  I do think that you have 
 > to

 > 
accept that 
 > CDRs may have to be generated at a few places in the 
 > network.

 > 
I myself am 
 > not wild about UAs doing CDR generation.  I think proxy servers 
 > 

 > 
can do 
 > that.  The piece of information the PS doesn't have is the exact 
 > connection

 > 
time 
 > information.  We may want to be able to get that sent on a BYE.  
 > 

 > 
 color=#0000ff> 

 > 
Suppose you 
 > just thought of this stuff as statistics.  There are several 
 > interesting

 > 
statistics 
 > you may wish to gather on a call (lost packets for example).  
 > Sure,

 > 
you could 
 > make this a management function, but you are then faced with 
 > storage

 > 
and other 
 > issues associated with a very large number of endpoints.  If you 
 > could

 > 
report 
 > statistics on a BYE, the PS could then generate the CDR.

 > 
 color=#0000ff> 

 > 
This may also 
 > help a problem we are currently calling "session management".  
 > There

 > 
is some work 
 > at the Softswitch Consortium on this.  It deals with the 
 > following

 > 
practical 
 > problem - your customer service center gets the following call "I 
 > was

 > 
just talking 
 > to my mother and I couldn't hear her".  Okay, what equipment was 
 > used

 > 
on that call, 
 > and where did it go wrong?  To make that really work EVERY 
 > device

 > 
that 
 > participates in some way on the call needs to report information on the 
 > call,

 > 
and it has to 
 > do so proactively.  This is equivalent to a CDR with more 
 > information

 > 
 color=#0000ff>(statistics).  Yes, we could get UAs to generate them, but we 
 > could also just pass

 > 
up the info 
 > on BYE and let the PS save it, massage it, and send it on it's 
 > way.

 > 
 color=#0000ff> 

 > 
 color=#0000ff>Brian

 > 
 color=#0000ff> 

 > 
 color=#0000ff> 

 > 
 color=#0000ff> 

 > 
 style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
 >   
   size=2>-----Original Message-----
From: Jay Batson 
 >   [mailto:jbatson@pingtel.com]
Sent: Tuesday, June 19, 2001 5:59 
 >   PM
To: Ashhar Farhan; sip@lists.bell-labs.com
Subject: Re: 
 >   [SIP] Authentication and billing through proxy/re-direct 
 >   server

There is another possibility that "real commercial 
 >   systems" might use (in fact, are likely to use...):

- Charge only for 
 >   PSTN gateway transit.
- Sessions that stay on the IP net (only) are built 
 >   into a base bandwidth/connectivity fee.

In this case, CDRs generated by 
 >   the gateway will provide sufficient information about PSTN connectivity to 
 >   create billing info, wouldn't they?  Neither the proxy nor the 
 >   originating (IP-network-resident) UA need to know / do 
 >   anything....

-jb

At 03:28 AM 6/4/01, Ashhar Farhan wrote:

 >   
in a typical next gen telco setup, 
 >     the billing is centralised and their Point of presence are basically SIP 
 >     servers that gateway to PSTN cloud.

the INVITE gets 
 >     redirected/proxied from the central server and the is resend to the gateway 
 >     (a sip server).
here, we have an issue of user authentication. the user 
 >     has to be authenticated by the redirect/proxy server. the authentication (as 
 >     per the SIP recommendations) should be md5 digest. 
the scheme would be 
 >     that the redirect/proxy should generate a digest over the redirected INVITE 
 >     request using the nonce and password of the intended server.

billing 
 >     systems are usually needed to be centralised (esp. in those next gen telcos 
 >     where the servers are operated by franchises). this is a commercial 
 >     requirement of SIP operations.

the 2543.bis does not explicitly talk 
 >     of the redirect/proxies authenticating requests for the gateways.

the 
 >     second issue:
the call minutes are the accepted billing mechanism for 
 >     atleast the next couple of years. to support billing, accurate times of call 
 >     start and end are important.
the call times maybe at variance between the 
 >     client and the server due to a the RTT nature of messaging itself. In that 
 >     case, it will be advisable, from a caller perspective to know when exactly 
 >     did the call get disconnected (a second's delay can roll the call over to 
 >     the next minute) and how long did the call last - as per server's record. 
 >     Although MESSAGE can be used for this, i would rather believe that a more 
 >     intrinsic method must be available to support this that can update the 
 >     caller's own 'call meter'.

- 
 >     farhan@hotfoon.com



_____________________________________________________
Chat 
 >     with your friends as soon as they come online. Get Rediff Bol at
     href="http://bol.rediff.com/" 
 >     eudora="autourl">http://bol.rediff.com





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

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



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


From sip-admin@lists.bell-labs.com  Wed Jun 20 10:37:34 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09302
	for ; Wed, 20 Jun 2001 10:37:33 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1CFED44370; Wed, 20 Jun 2001 10:38:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from gatekeeper.calltrol.com (unknown [65.105.250.35])
	by lists.bell-labs.com (Postfix) with ESMTP id 641F94436F
	for ; Wed, 20 Jun 2001 10:37:32 -0400 (EDT)
Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253])
	by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id KAA01423;
	Wed, 20 Jun 2001 10:36:56 -0400
Received: by NT-SERVER with Internet Mail Service (5.5.2448.0)
	id ; Wed, 20 Jun 2001 10:39:41 -0400
Message-ID: <60A9CA50081AD4118BD60040F60C1A9F0A3DBE@NT-SERVER>
From: Wai Wu 
To: "'Jay Batson'" ,
        Venkatesh Venkataramanan ,
        "'Jean-Francois Mule'" ,
        "'Rohan Mahy'" , islain@cisco.com,
        sip@lists.bell-labs.com
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F996.D65894F0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 10:39:35 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F996.D65894F0
Content-Type: text/plain;
	charset="iso-8859-1"

I think features normally found on a PBX phone (e.g. message waiting)
shouldn't be part of SIP at all. If we put all these things in SIP, it will
make SIP not much different from a "standardized PBX protocol". 

-----Original Message-----
From: Jay Batson [mailto:jbatson@pingtel.com]
Sent: Tuesday, June 19, 2001 3:37 PM
To: Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan Mahy';
islain@cisco.com; sip@lists.bell-labs.com
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt


My comments aren't timely, so my apologies.

Venkatesh's comments are also consistent with typical IETF protocol /
application design.  Example:  Neither SMTP nor POP/IMAP specify how the
email "user agent" (Eudora, Netscape, Outlook) provides visual indication of
email message priority (X-Priority).

The creator of a given user agent defines its own user interfaces to
information that is provided in the standardized lower later protocol.  End
users then choose among available user agents (and behaviors) to get their
desired interaction.

Applications at either end of a transaction may want to agree on
Experimental extensions to show more information, such as the type that
Jean-Francois suggests.  In fact, this is how X-Priority came into being in
email!  Eudora just up and did it one day, and everybody else did what they
did!

-jb


At 03:29 PM 4/26/01, Venkatesh Venkataramanan wrote:


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

Venkatesh

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


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

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


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

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




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









I 
think features normally found on a PBX phone (e.g. message waiting) shouldn't be 
part of SIP at all. If we put all these things in SIP, it will make SIP not much 
different from a "standardized PBX protocol".  



  
-----Original Message-----
From: Jay Batson 
  [mailto:jbatson@pingtel.com]
Sent: Tuesday, June 19, 2001 3:37 
  PM
To: Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan Mahy'; 
  islain@cisco.com; sip@lists.bell-labs.com
Subject: RE: [SIP] 
  draft-mahy-sip-message-waiting-01.txt

My comments aren't 
  timely, so my apologies.

Venkatesh's comments are also consistent with 
  typical IETF protocol / application design.  Example:  Neither SMTP 
  nor POP/IMAP specify how the email "user agent" (Eudora, Netscape, Outlook) 
  provides visual indication of email message priority (X-Priority).

The 
  creator of a given user agent defines its own user interfaces to information 
  that is provided in the standardized lower later protocol.  End users 
  then choose among available user agents (and behaviors) to get their desired 
  interaction.

Applications at either end of a transaction may want to 
  agree on Experimental extensions to show more information, such as the type 
  that Jean-Francois suggests.  In fact, this is how X-Priority came into 
  being in email!  Eudora just up and did it one day, and everybody else 
  did what they did!

-jb


At 03:29 PM 4/26/01, Venkatesh 
  Venkataramanan wrote:

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

Venkatesh

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


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

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


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

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



------_=_NextPart_001_01C0F996.D65894F0--

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


From sip-admin@lists.bell-labs.com  Wed Jun 20 10:40:26 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09434
	for ; Wed, 20 Jun 2001 10:40:25 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 92BF244377; Wed, 20 Jun 2001 10:40:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from gatekeeper.calltrol.com (unknown [65.105.250.35])
	by lists.bell-labs.com (Postfix) with ESMTP id C17374436F
	for ; Wed, 20 Jun 2001 10:39:55 -0400 (EDT)
Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253])
	by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id KAA01430;
	Wed, 20 Jun 2001 10:39:26 -0400
Received: by NT-SERVER with Internet Mail Service (5.5.2448.0)
	id ; Wed, 20 Jun 2001 10:42:11 -0400
Message-ID: <60A9CA50081AD4118BD60040F60C1A9F0A3DBF@NT-SERVER>
From: Wai Wu 
To: "'Xin Zhou(TS)'" , sip@lists.bell-labs.com
Subject: RE: [SIP] help
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F997.2FEC6BC0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 10:42:08 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F997.2FEC6BC0
Content-Type: text/plain;
	charset="iso-8859-1"

Use SIP, it is great. It would've be better is the messages are in XML

-----Original Message-----
From: Xin Zhou(TS) [mailto:zhouxin@china-netcom.com]
Sent: Tuesday, June 19, 2001 7:05 PM
To: sip@lists.bell-labs.com
Subject: [SIP] help



hi,alll
I am from china netcom,a new carrier in china .in this field ,i am just
a layman,hehe
I am doing some rearch on network convergence,and in these days ,what
confused me most is 
as a  carrier,service provider,what tech we should take?h.323,sip?when
we talking about the interworking
between PSTN and IP,some services just like  the follow me ,LNP.. I
donnot know which tech is more acceptable if we adopt
The softswitch archetech or PINT..
Jude
-----????-----
???: sip-request@lists.bell-labs.com
[mailto:sip-request@lists.bell-labs.com]
????: 2001?6?19? 0:01
???: sip@lists.bell-labs.com
??: SIP digest, Vol 1 #1080 - 2 msgs


Send SIP mailing list submissions to
	sip@lists.bell-labs.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.bell-labs.com/mailman/listinfo/sip
or, via email, send a message with subject or body 'help' to
	sip-request@lists.bell-labs.com

You can reach the person managing the list at
	sip-admin@lists.bell-labs.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of SIP digest..."



------_=_NextPart_001_01C0F997.2FEC6BC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] help




Use SIP, it is great. It would've be better is the =
messages are in XML




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

From: Xin Zhou(TS) [mailto:zhouxin@china-netcom.com=
]

Sent: Tuesday, June 19, 2001 7:05 PM

To: sip@lists.bell-labs.com

Subject: [SIP] help








hi,alll

I am from china netcom,a new carrier in china .in =
this field ,i am just

a layman,hehe

I am doing some rearch on network convergence,and in =
these days ,what

confused me most is 

as a  carrier,service provider,what tech we =
should take?h.323,sip?when

we talking about the interworking

between PSTN and IP,some services just like  =
the follow me ,LNP.. I

donnot know which tech is more acceptable if we =
adopt

The softswitch archetech or PINT..

Jude

-----????-----

???: sip-request@lists.bell-labs.com

[mailto:sip-request@lists=
.bell-labs.com]

????: 2001?6?19? 0:01

???: sip@lists.bell-labs.com

??: SIP digest, Vol 1 #1080 - 2 msgs






Send SIP mailing list submissions to

        sip@lists.bell-labs.com




To subscribe or unsubscribe via the World Wide Web, =
visit

        http://lists.bell-labs.com/mailman/listinfo/sip

or, via email, send a message with subject or body =
'help' to

        sip-request@lists.bell-labs.com




You can reach the person managing the list at

        sip-admin@lists.bell-labs.com




When replying, please edit your Subject line so it is =
more specific

than "Re: Contents of SIP =
digest..."







------_=_NextPart_001_01C0F997.2FEC6BC0--

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


From sip-admin@lists.bell-labs.com  Wed Jun 20 10:52:34 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09815
	for ; Wed, 20 Jun 2001 10:52:34 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A3AF54436F; Wed, 20 Jun 2001 10:53:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from gatekeeper.calltrol.com (unknown [65.105.250.35])
	by lists.bell-labs.com (Postfix) with ESMTP id EA64C4436A
	for ; Wed, 20 Jun 2001 10:52:45 -0400 (EDT)
Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253])
	by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id KAA01435;
	Wed, 20 Jun 2001 10:52:16 -0400
Received: by NT-SERVER with Internet Mail Service (5.5.2448.0)
	id ; Wed, 20 Jun 2001 10:55:01 -0400
Message-ID: <60A9CA50081AD4118BD60040F60C1A9F0A3DC0@NT-SERVER>
From: Wai Wu 
To: "'Rosen, Brian'" ,
        "'Jay Batson'" ,
        Ashhar Farhan , sip@lists.bell-labs.com
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	 er
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F998.FB1F5220"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 10:54:59 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F998.FB1F5220
Content-Type: text/plain;
	charset="iso-8859-1"

This is how I would like it. Either the BYE or the ACK for the BYE will
contain a Total-Charge header, and each proxy will add up the amount from
the proxy next in the chain, the final charge will end up to the calling
UAC. This might not work if you are billing by bandwidth used since RTP
parket losts either can or cannot be billed within a network.

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Wednesday, June 20, 2001 6:02 AM
To: 'Jay Batson'; Ashhar Farhan; sip@lists.bell-labs.com
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
er


Just for grins, what would you expect the charging to look like when the
terminating end is on a different network from the originating end, but they
were both sipphones?  Suppose there were three networks (a transit network
as well as the originating and terminating networks)?  Suppose there was
an enterprise network (no internal charging) connected to a public (IP)
network
that charged by the minute?
 
I don't want to start a debate on billing possibilities.  I do think that
you have to
accept that CDRs may have to be generated at a few places in the network.
I myself am not wild about UAs doing CDR generation.  I think proxy servers 
can do that.  The piece of information the PS doesn't have is the exact
connection
time information.  We may want to be able to get that sent on a BYE.  
 
Suppose you just thought of this stuff as statistics.  There are several
interesting
statistics you may wish to gather on a call (lost packets for example).
Sure,
you could make this a management function, but you are then faced with
storage
and other issues associated with a very large number of endpoints.  If you
could
report statistics on a BYE, the PS could then generate the CDR.
 
This may also help a problem we are currently calling "session management".
There
is some work at the Softswitch Consortium on this.  It deals with the
following
practical problem - your customer service center gets the following call "I
was
just talking to my mother and I couldn't hear her".  Okay, what equipment
was used
on that call, and where did it go wrong?  To make that really work EVERY
device
that participates in some way on the call needs to report information on the
call,
and it has to do so proactively.  This is equivalent to a CDR with more
information
(statistics).  Yes, we could get UAs to generate them, but we could also
just pass
up the info on BYE and let the PS save it, massage it, and send it on it's
way.
 
Brian
 
 
 

-----Original Message-----
From: Jay Batson [mailto:jbatson@pingtel.com]
Sent: Tuesday, June 19, 2001 5:59 PM
To: Ashhar Farhan; sip@lists.bell-labs.com
Subject: Re: [SIP] Authentication and billing through proxy/re-direct server


There is another possibility that "real commercial systems" might use (in
fact, are likely to use...):

- Charge only for PSTN gateway transit.
- Sessions that stay on the IP net (only) are built into a base
bandwidth/connectivity fee.

In this case, CDRs generated by the gateway will provide sufficient
information about PSTN connectivity to create billing info, wouldn't they?
Neither the proxy nor the originating (IP-network-resident) UA need to know
/ do anything....

-jb

At 03:28 AM 6/4/01, Ashhar Farhan wrote:


in a typical next gen telco setup, the billing is centralised and their
Point of presence are basically SIP servers that gateway to PSTN cloud.

the INVITE gets redirected/proxied from the central server and the is resend
to the gateway (a sip server).
here, we have an issue of user authentication. the user has to be
authenticated by the redirect/proxy server. the authentication (as per the
SIP recommendations) should be md5 digest. 
the scheme would be that the redirect/proxy should generate a digest over
the redirected INVITE request using the nonce and password of the intended
server.

billing systems are usually needed to be centralised (esp. in those next gen
telcos where the servers are operated by franchises). this is a commercial
requirement of SIP operations.

the 2543.bis does not explicitly talk of the redirect/proxies authenticating
requests for the gateways.

the second issue:
the call minutes are the accepted billing mechanism for atleast the next
couple of years. to support billing, accurate times of call start and end
are important.
the call times maybe at variance between the client and the server due to a
the RTT nature of messaging itself. In that case, it will be advisable, from
a caller perspective to know when exactly did the call get disconnected (a
second's delay can roll the call over to the next minute) and how long did
the call last - as per server's record. Although MESSAGE can be used for
this, i would rather believe that a more intrinsic method must be available
to support this that can update the caller's own 'call meter'.

- farhan@hotfoon.com



_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com  





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

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




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









This 
is how I would like it. Either the BYE or the ACK for the BYE will contain a 
Total-Charge header, and each proxy will add up the amount from the proxy next 
in the chain, the final charge will end up to the calling UAC. This might not 
work if you are billing by bandwidth used since RTP parket losts either can or 
cannot be billed within a network.



  
-----Original Message-----
From: Rosen, Brian 
  [mailto:Brian.Rosen@marconi.com]
Sent: Wednesday, June 20, 2001 6:02 
  AM
To: 'Jay Batson'; Ashhar Farhan; 
  sip@lists.bell-labs.com
Subject: RE: [SIP] Authentication and 
  billing through proxy/re-direct serv er


  
Just for 
  grins, what would you expect the charging to look like when 
  the

  
terminating 
  end is on a different network from the originating end, but 
  they

  
were both 
  sipphones?  Suppose there were three networks (a transit 
  network

  
as well as 
  the originating and terminating networks)?  Suppose there 
  was

  
an 
  enterprise network (no internal charging) connected to a public (IP) 
  network

  
that 
  charged by the minute?

  
 

  
I don't 
  want to start a debate on billing possibilities.  I do think that you 
  have to

  
accept that 
  CDRs may have to be generated at a few places in the 
  network.

  
I myself am 
  not wild about UAs doing CDR generation.  I think proxy servers 
  

  
can do 
  that.  The piece of information the PS doesn't have is the exact 
  connection

  
time 
  information.  We may want to be able to get that sent on a BYE.  
  

  
 

  
Suppose you 
  just thought of this stuff as statistics.  There are several 
  interesting

  
statistics 
  you may wish to gather on a call (lost packets for example).  
  Sure,

  
you could 
  make this a management function, but you are then faced with 
  storage

  
and other 
  issues associated with a very large number of endpoints.  If you 
  could

  
report 
  statistics on a BYE, the PS could then generate the CDR.

  
 

  
This may 
  also help a problem we are currently calling "session management".  
  There

  
is some 
  work at the Softswitch Consortium on this.  It deals with the 
  following

  
practical 
  problem - your customer service center gets the following call "I 
  was

  
just 
  talking to my mother and I couldn't hear her".  Okay, what equipment was 
  used

  
on that 
  call, and where did it go wrong?  To make that really work EVERY 
  device

  
that 
  participates in some way on the call needs to report information on the 
  call,

  
and it has 
  to do so proactively.  This is equivalent to a CDR with more 
  information

  
(statistics).  Yes, we could get UAs to generate them, but we 
  could also just pass

  
up the info 
  on BYE and let the PS save it, massage it, and send it on it's 
  way.

  
 

  
Brian

  
 

  
 

  
 

  

    
-----Original Message-----
From: Jay Batson 
    [mailto:jbatson@pingtel.com]
Sent: Tuesday, June 19, 2001 5:59 
    PM
To: Ashhar Farhan; sip@lists.bell-labs.com
Subject: 
    Re: [SIP] Authentication and billing through proxy/re-direct 
    server

There is another possibility that "real 
    commercial systems" might use (in fact, are likely to use...):

- 
    Charge only for PSTN gateway transit.
- Sessions that stay on the IP net 
    (only) are built into a base bandwidth/connectivity fee.

In this 
    case, CDRs generated by the gateway will provide sufficient information 
    about PSTN connectivity to create billing info, wouldn't they?  Neither 
    the proxy nor the originating (IP-network-resident) UA need to know / do 
    anything....

-jb

At 03:28 AM 6/4/01, Ashhar Farhan wrote:

    
in a typical next gen telco setup, 
      the billing is centralised and their Point of presence are basically SIP 
      servers that gateway to PSTN cloud.

the INVITE gets 
      redirected/proxied from the central server and the is resend to the 
      gateway (a sip server).
here, we have an issue of user authentication. 
      the user has to be authenticated by the redirect/proxy server. the 
      authentication (as per the SIP recommendations) should be md5 digest. 
      
the scheme would be that the redirect/proxy should generate a digest 
      over the redirected INVITE request using the nonce and password of the 
      intended server.

billing systems are usually needed to be 
      centralised (esp. in those next gen telcos where the servers are operated 
      by franchises). this is a commercial requirement of SIP 
      operations.

the 2543.bis does not explicitly talk of the 
      redirect/proxies authenticating requests for the gateways.

the 
      second issue:
the call minutes are the accepted billing mechanism for 
      atleast the next couple of years. to support billing, accurate times of 
      call start and end are important.
the call times maybe at variance 
      between the client and the server due to a the RTT nature of messaging 
      itself. In that case, it will be advisable, from a caller perspective to 
      know when exactly did the call get disconnected (a second's delay can roll 
      the call over to the next minute) and how long did the call last - as per 
      server's record. Although MESSAGE can be used for this, i would rather 
      believe that a more intrinsic method must be available to support this 
      that can update the caller's own 'call meter'.

- 
      farhan@hotfoon.com



_____________________________________________________
Chat 
      with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





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

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



------_=_NextPart_001_01C0F998.FB1F5220--

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


From sip-admin@ietf.org  Wed Jun 20 11:11:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10354;
	Wed, 20 Jun 2001 11:11:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22348;
	Wed, 20 Jun 2001 10:51:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22321
	for ; Wed, 20 Jun 2001 10:51:53 -0400 (EDT)
Received: from mail.pingtel.com (IDENT:root@mail.pingtel.com [216.91.1.131])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09796
	for ; Wed, 20 Jun 2001 10:51:17 -0400 (EDT)
Received: from stbarth.pingtel.com (cdhcp117.pingtel.com [10.1.1.117])
	by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id f5KEntd03886;
	Wed, 20 Jun 2001 10:49:55 -0400
Message-Id: <5.1.0.14.2.20010620104612.033517a0@mail.pingtel.com>
X-Sender: jbatson@mail.pingtel.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 20 Jun 2001 10:50:07 -0400
To: "Ashhar Farhan" , sip@ietf.org
From: Jay Batson 
Subject: Re: Re: [SIP] Authentication and billing through
  proxy/re-direct server
In-Reply-To: <20010620032931.12459.qmail@mailweb30.rediffmail.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_50235074==_.ALT"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

--=====================_50235074==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

I'm not as technically deep as others in this, but here's a response.... 
(routed back through the "new" mailing list at IETF for SIP):

At 11:29 PM 6/19/01, Ashhar Farhan wrote:
>1) how does a gateway know whether the caller is credit worthy? if we 
>require a separate TLS style connection to the proxy for billing purpose, 
>it is actually simpler to just make the proxy hold the state information 
>and pass setup and cleardown messages over the same pipe.
>
>2)we do not require TLS pipe between the UA and the proxy to authenticate 
>itself. i dont see why we should require a TLS session between the gateway 
>and the proxy to authenticate the incoming callers.

The gateway doesn't want to know, the proxy should.  Via network design 
(vs. protocol design) you can make the gateway only accept INVITEs from an 
authenticated Proxy.  The proxy doesn't need to maintain state to 
authenticate if the caller is credit worthy on a session-by-session basis 
-- it can simply deny a registration to any UA it doesn't want to serve 
(e.g. a customer that isn't credit worthy.)  No registration, no INVITE 
gets through to the gateway.  TLS is irrelevant.


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


--=====================_50235074==_.ALT
Content-Type: text/html; charset="us-ascii"


I'm not as technically deep as others in this, but here's a response....
(routed back through the "new" mailing list at IETF for
SIP):


At 11:29 PM 6/19/01, Ashhar Farhan wrote:


1) how does a gateway know whether
the caller is credit worthy? if we require a separate TLS style
connection to the proxy for billing purpose, it is actually simpler to
just make the proxy hold the state information and pass setup and
cleardown messages over the same pipe.



2)we do not require TLS pipe between the UA and the proxy to authenticate
itself. i dont see why we should require a TLS session between the
gateway and the proxy to authenticate the incoming
callers.


The gateway doesn't want to know, the proxy should.  Via network
design (vs. protocol design) you can make the gateway only accept INVITEs
from an authenticated Proxy.  The proxy doesn't need to maintain
state to authenticate if the caller is credit worthy on a
session-by-session basis -- it can simply deny a registration to any UA
it doesn't want to serve (e.g. a customer that isn't credit
worthy.)  No registration, no INVITE gets through to the
gateway.  TLS is irrelevant.




-------------

PingMe!

Jay Batson

CEO

Pingtel Corp.

mailto:jbatson@pingtel.com

781-938-5306 (office)




--=====================_50235074==_.ALT--


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 20 11:35:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11257;
	Wed, 20 Jun 2001 11:35:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23567;
	Wed, 20 Jun 2001 11:21:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23536
	for ; Wed, 20 Jun 2001 11:21:00 -0400 (EDT)
Received: from gatekeeper.calltrol.com (root@[65.105.250.35])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10704
	for ; Wed, 20 Jun 2001 11:20:24 -0400 (EDT)
Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253])
	by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id LAA01448;
	Wed, 20 Jun 2001 11:20:37 -0400
Received: by NT-SERVER with Internet Mail Service (5.5.2448.0)
	id ; Wed, 20 Jun 2001 11:23:22 -0400
Message-ID: <60A9CA50081AD4118BD60040F60C1A9F0A3DC1@NT-SERVER>
From: Wai Wu 
To: "'Jay Batson'" ,
        Ashhar Farhan
	 , sip@ietf.org
Subject: RE: Re: [SIP] Authentication and billing through proxy/re-direct 
	server
Date: Wed, 20 Jun 2001 11:23:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F99C.F0FA1D60"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F99C.F0FA1D60
Content-Type: text/plain;
	charset="iso-8859-1"

 

-----Original Message-----
From: Jay Batson [mailto:jbatson@pingtel.com]
Sent: Wednesday, June 20, 2001 10:50 AM
To: Ashhar Farhan; sip@ietf.org
Subject: Re: Re: [SIP] Authentication and billing through proxy/re-direct
server


I'm not as technically deep as others in this, but here's a response....
(routed back through the "new" mailing list at IETF for SIP):

At 11:29 PM 6/19/01, Ashhar Farhan wrote:


1) how does a gateway know whether the caller is credit worthy? if we
require a separate TLS style connection to the proxy for billing purpose, it
is actually simpler to just make the proxy hold the state information and
pass setup and cleardown messages over the same pipe.

2)we do not require TLS pipe between the UA and the proxy to authenticate
itself. i dont see why we should require a TLS session between the gateway
and the proxy to authenticate the incoming callers.


The gateway doesn't want to know, the proxy should.  Via network design (vs.
protocol design) you can make the gateway only accept INVITEs from an
authenticated Proxy.  The proxy doesn't need to maintain state to
authenticate if the caller is credit worthy on a session-by-session basis --
it can simply deny a registration to any UA it doesn't want to serve (e.g. a
customer that isn't credit worthy.)  No registration, no INVITE gets through
to the gateway.  TLS is irrelevant.

[Wai Wu] Now the gateway has to implement only to process INVITEs from THAT
proxy. On a side note, the proxy has to allow caller to register just to
make internal calls. 


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




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









 



  
-----Original Message-----
From: Jay Batson 
  [mailto:jbatson@pingtel.com]
Sent: Wednesday, June 20, 2001 10:50 
  AM
To: Ashhar Farhan; sip@ietf.org
Subject: Re: Re: [SIP] 
  Authentication and billing through proxy/re-direct 
  server

I'm not as technically deep as others in this, but 
  here's a response.... (routed back through the "new" mailing list at IETF for 
  SIP):

At 11:29 PM 6/19/01, Ashhar Farhan wrote:

  
1) how does a gateway know whether 
    the caller is credit worthy? if we require a separate TLS style connection 
    to the proxy for billing purpose, it is actually simpler to just make the 
    proxy hold the state information and pass setup and cleardown messages over 
    the same pipe.

2)we do not require TLS pipe between the UA and the 
    proxy to authenticate itself. i dont see why we should require a TLS session 
    between the gateway and the proxy to authenticate the incoming 
  callers.

The gateway doesn't want to know, the proxy 
  should.  Via network design (vs. protocol design) you can make the 
  gateway only accept INVITEs from an authenticated Proxy.  The proxy 
  doesn't need to maintain state to authenticate if the caller is credit worthy 
  on a session-by-session basis -- it can simply deny a registration to any UA 
  it doesn't want to serve (e.g. a customer that isn't credit worthy.)  No 
  registration, no INVITE gets through to the gateway.  TLS is 
  irrelevant.

[Wai Wu] Now the gateway has to implement only 
  to process INVITEs from THAT proxy. On a side note, the proxy 
  has to allow caller to register just to make internal 
  calls. 

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



------_=_NextPart_001_01C0F99C.F0FA1D60--

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jun 20 12:08:32 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12256
	for ; Wed, 20 Jun 2001 12:08:32 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 347B74436E; Wed, 20 Jun 2001 12:09:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from zsc3s002.nortelnetworks.com (h86s136a81n47.user.nortelnetworks.com [47.81.136.86])
	by lists.bell-labs.com (Postfix) with SMTP id 92AD044369
	for ; Wed, 20 Jun 2001 12:08:33 -0400 (EDT)
Received: from smtprch1.nortel.com by zsc3s002.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id IAA25183; Wed, 20 Jun 2001 08:38:21 -0700
Received: from zrchb213.us.nortel.com by smtprch1.nortel.com;
          Wed, 20 Jun 2001 11:07:38 -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 20 Jun 2001 11:07:34 -0500
Message-ID: <63E0DAD7784FD21188310000F80824B306A0A031@zmpkdx02.us.nortel.com>
From: "Francois Audet" 
To: "'sip@lists.bell-labs.com'" 
Cc: "'Rosen, Brian'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv er
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0F9A3.1C54D140"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 11:07:31 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F9A3.1C54D140
Content-Type: text/plain;
	charset="ISO-8859-1"

On the other hand, it may make a lot of sense for UAs to generate CDRs if it
is a gateway (especially if it is a gateway to an expensive PSTN where you
need to track charges accurately which I don't think will be possible if it
is based on SIP signalling).

It seems to me that they'd be network level CDRs using proxy servers, and
"local" ones that can be useful when somebody has figured our how to abuse
the system, or to calculate "real" charges from the PSTN.

> -----Original Message-----
> From:	Rosen, Brian [SMTP:Brian.Rosen@marconi.com]
> Sent:	Wednesday, June 20, 2001 06:02
> To:	'Jay Batson'; Ashhar Farhan; sip@lists.bell-labs.com
> Subject:	RE: [SIP] Authentication and billing through proxy/re-direct
> serv er
> 
> Just for grins, what would you expect the charging to look like when the
> terminating end is on a different network from the originating end, but
> they
> were both sipphones?  Suppose there were three networks (a transit network
> as well as the originating and terminating networks)?  Suppose there was
> an enterprise network (no internal charging) connected to a public (IP)
> network
> that charged by the minute?
>  
> I don't want to start a debate on billing possibilities.  I do think that
> you have to
> accept that CDRs may have to be generated at a few places in the network.
> I myself am not wild about UAs doing CDR generation.  I think proxy
> servers 
> can do that.  The piece of information the PS doesn't have is the exact
> connection
> time information.  We may want to be able to get that sent on a BYE.  
>  
> Suppose you just thought of this stuff as statistics.  There are several
> interesting
> statistics you may wish to gather on a call (lost packets for example).
> Sure,
> you could make this a management function, but you are then faced with
> storage
> and other issues associated with a very large number of endpoints.  If you
> could
> report statistics on a BYE, the PS could then generate the CDR.
>  
> This may also help a problem we are currently calling "session
> management".  There
> is some work at the Softswitch Consortium on this.  It deals with the
> following
> practical problem - your customer service center gets the following call
> "I was
> just talking to my mother and I couldn't hear her".  Okay, what equipment
> was used
> on that call, and where did it go wrong?  To make that really work EVERY
> device
> that participates in some way on the call needs to report information on
> the call,
> and it has to do so proactively.  This is equivalent to a CDR with more
> information
> (statistics).  Yes, we could get UAs to generate them, but we could also
> just pass
> up the info on BYE and let the PS save it, massage it, and send it on it's
> way.
>  
> Brian
>  
>  
>  
> 
> 	-----Original Message-----
> 	From: Jay Batson [mailto:jbatson@pingtel.com]
> 	Sent: Tuesday, June 19, 2001 5:59 PM
> 	To: Ashhar Farhan; sip@lists.bell-labs.com
> 	Subject: Re: [SIP] Authentication and billing through
> proxy/re-direct server
> 	
> 	
> 	There is another possibility that "real commercial systems" might
> use (in fact, are likely to use...):
> 	
> 	- Charge only for PSTN gateway transit.
> 	- Sessions that stay on the IP net (only) are built into a base
> bandwidth/connectivity fee.
> 	
> 	In this case, CDRs generated by the gateway will provide sufficient
> information about PSTN connectivity to create billing info, wouldn't they?
> Neither the proxy nor the originating (IP-network-resident) UA need to
> know / do anything....
> 	
> 	-jb
> 	
> 	At 03:28 AM 6/4/01, Ashhar Farhan wrote:
> 	
> 
> 		in a typical next gen telco setup, the billing is
> centralised and their Point of presence are basically SIP servers that
> gateway to PSTN cloud.
> 		
> 		the INVITE gets redirected/proxied from the central server
> and the is resend to the gateway (a sip server).
> 		here, we have an issue of user authentication. the user has
> to be authenticated by the redirect/proxy server. the authentication (as
> per the SIP recommendations) should be md5 digest. 
> 		the scheme would be that the redirect/proxy should generate
> a digest over the redirected INVITE request using the nonce and password
> of the intended server.
> 		
> 		billing systems are usually needed to be centralised (esp.
> in those next gen telcos where the servers are operated by franchises).
> this is a commercial requirement of SIP operations.
> 		
> 		the 2543.bis does not explicitly talk of the
> redirect/proxies authenticating requests for the gateways.
> 		
> 		the second issue:
> 		the call minutes are the accepted billing mechanism for
> atleast the next couple of years. to support billing, accurate times of
> call start and end are important.
> 		the call times maybe at variance between the client and the
> server due to a the RTT nature of messaging itself. In that case, it will
> be advisable, from a caller perspective to know when exactly did the call
> get disconnected (a second's delay can roll the call over to the next
> minute) and how long did the call last - as per server's record. Although
> MESSAGE can be used for this, i would rather believe that a more intrinsic
> method must be available to support this that can update the caller's own
> 'call meter'.
> 		
> 		- farhan@hotfoon.com
> 		
> 		
> 		
> 		_____________________________________________________
> 		Chat with your friends as soon as they come online. Get
> Rediff Bol at
> 		
> 		
> 		
> 		
> 		
> 		
> 		_______________________________________________
> 		This list is for continuing development of the SIP protocol.
> 		The sip-implementor's list is the place to discuss
> implementation,
> 		and to receive advice on understanding existing sip.
> 		To subscribe to it, send mail to 
> 		sip-implementors-request@cs.columbia.edu with "subscribe" in
> the body.
> 
> 	-------------
> 	PingMe!
> 	Jay Batson
> 	CEO
> 	Pingtel Corp.
> 	
> 	781-938-5306 (office)
> 	
> 	
> 

------_=_NextPart_001_01C0F9A3.1C54D140
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Authentication and billing through proxy/re-direct =
serv er




On the other hand, =
it may make a lot of sense for UAs to generate CDRs if it is a gateway =
(especially if it is a gateway to an expensive PSTN where you need to =
track charges accurately which I don't think will be possible if it is =
based on SIP signalling).



It seems to me that =
they'd be network level CDRs using proxy servers, and "local" =
ones that can be useful when somebody has figured our how to abuse the =
system, or to calculate "real" charges from the =
PSTN.


    

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

    From:   Rosen, Brian =
[SMTP:Brian.Rosen@marconi.com]

    Sent:   Wednesday, June 20, 2001 06:02

    To:     'Jay Batson'; Ashhar Farhan; =
sip@lists.bell-labs.com

    Subject:       =
 RE: [SIP] Authentication and billing =
through proxy/re-direct serv er

    


    Just for grins, what would =
you expect the charging to look like when the

    terminating end is on a =
different network from the originating end, but they

    were both sipphones?=A0 =
Suppose there were three networks (a transit network

    as well as the originating =
and terminating networks)?=A0 Suppose there was

    an enterprise network (no =
internal charging) connected to a public (IP) network

    that charged by the =
minute?

    =A0

    I don't want to start a =
debate on billing possibilities.=A0 I do think that you have to

    accept that CDRs may have to =
be generated at a few places in the network.

    I myself am not wild about =
UAs doing CDR generation.=A0 I think proxy servers=20

    can do that.=A0 The piece of =
information the PS doesn't have is the exact connection

    time information.=A0 We may =
want to be able to get that sent on a BYE.=A0=20

    =A0

    Suppose you just thought of =
this stuff as statistics.=A0 There are several interesting

    statistics you may wish to =
gather on a call (lost packets for example).=A0 Sure,

    you could make this a =
management function, but you are then faced with storage

    and other issues associated =
with a very large number of endpoints.=A0 If you could

    report statistics on a BYE, =
the PS could then generate the CDR.

    =A0

    This may also help a problem =
we are currently calling "session management".=A0 =
There

    is some work at the =
Softswitch Consortium on this.=A0 It deals with the following

    practical problem - your =
customer service center gets the following call "I was

    just talking to my mother =
and I couldn't hear her".=A0 Okay, what equipment was used

    on that call, and where did =
it go wrong?=A0 To make that really work EVERY device

    that participates in some =
way on the call needs to report information on the call,

    and it has to do so =
proactively.=A0 This is equivalent to a CDR with more =
information

    (statistics).=A0 Yes, we =
could get UAs to generate them, but we could also just pass

    up the info on BYE and let =
the PS save it, massage it, and send it on it's way.

    =A0

    Brian

    =A0

    =A0

    =A0

    

      

      -----Original Message-----
      
      From: Jay Batson [mailto:jbatson@pingtel.com]
      
      Sent: Tuesday, June 19, 2001 5:59 PM
      
      To: Ashhar Farhan; sip@lists.bell-labs.com
      
      Subject: Re: [SIP] Authentication and billing through =
proxy/re-direct server
      

      
      

      There is another possibility that "real =
commercial systems" might use (in fact, are likely to use...):
      

      
- Charge only for PSTN gateway transit.
      
- Sessions that stay on the IP net (only) are built into a base =
bandwidth/connectivity fee.
      

      
In this case, CDRs generated by the gateway will provide sufficient =
information about PSTN connectivity to create billing info, wouldn't =
they?=A0 Neither the proxy nor the originating (IP-network-resident) UA =
need to know / do anything....
      

      
-jb
      

      
At 03:28 AM 6/4/01, Ashhar Farhan wrote:
      
      

      

        

        in a typical next gen telco setup, the billing =
is centralised and their Point of presence are basically SIP servers =
that gateway to PSTN cloud.
        

        
the INVITE gets redirected/proxied from the central server and the is =
resend to the gateway (a sip server).
        
here, we have an issue of user authentication. the user has to be =
authenticated by the redirect/proxy server. the authentication (as per =
the SIP recommendations) should be md5 digest.
        
the scheme would be that the redirect/proxy should generate a digest =
over the redirected INVITE request using the nonce and password of the =
intended server.
        

        
billing systems are usually needed to be centralised (esp. in those =
next gen telcos where the servers are operated by franchises). this is =
a commercial requirement of SIP operations.
        

        
the 2543.bis does not explicitly talk of the redirect/proxies =
authenticating requests for the gateways.
        

        
the second issue:
        
the call minutes are the accepted billing mechanism for atleast the =
next couple of years. to support billing, accurate times of call start =
and end are important.
        
the call times maybe at variance between the client and the server due =
to a the RTT nature of messaging itself. In that case, it will be =
advisable, from a caller perspective to know when exactly did the call =
get disconnected (a second's delay can roll the call over to the next =
minute) and how long did the call last - as per server's record. =
Although MESSAGE can be used for this, i would rather believe that a =
more intrinsic method must be available to support this that can update =
the caller's own 'call meter'.
        

        
- farhan@hotfoon.com
        

        

        

        
_____________________________________________________
        
Chat with your friends as soon as they come online. Get Rediff Bol =
at
        
        <http://bol.rediff.com/>
        

        

        

        

        

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

        

      

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

      
      

      




------_=_NextPart_001_01C0F9A3.1C54D140--

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


From sip-admin@lists.bell-labs.com  Wed Jun 20 12:26:33 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12812
	for ; Wed, 20 Jun 2001 12:26:32 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9BFB944367; Wed, 20 Jun 2001 12:27:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mitl.MITL.Research.Panasonic.COM (mitl.MITL.Research.Panasonic.COM [150.169.1.4])
	by lists.bell-labs.com (Postfix) with ESMTP id 72E2544362
	for ; Wed, 20 Jun 2001 12:26:02 -0400 (EDT)
Received: from GURUSUSWIN2K (viruswall.MITL.Research.Panasonic.COM [150.169.1.26])
	by mitl.MITL.Research.Panasonic.COM (8.9.3+Sun/8.9.3) with SMTP id MAA20573
	for ; Wed, 20 Jun 2001 12:26:22 -0400 (EDT)
Message-ID: <007f01c0f9a5$7dd958d0$9d01a996@GURUSUSWIN2K>
From: "Srinivas" 
To: 
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_007C_01C0F983.F6A62710"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Subject: [SIP] Help!!! SIP on Linux7.1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 12:24:34 -0400

This is a multi-part message in MIME format.

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

Hi,
Did any body tried to compile SIP on Linux7.1. I wanted make it work on =
Linux7.1. Do i need any other software/patches or simply modifying make =
files is enough...Pl. help me if anybody had done this...

Thanks,
Srini

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









Hi,


Did any body tried to compile =
SIP on Linux7.1.=20
I wanted make it work on Linux7.1. Do i need any other=20
software/patches or simply modifying make files is enough...Pl. help me =
if=20
anybody had done this...


 


Thanks,


Srini


------=_NextPart_000_007C_01C0F983.F6A62710--


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


From sip-admin@lists.bell-labs.com  Wed Jun 20 12:34:34 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13066
	for ; Wed, 20 Jun 2001 12:34:34 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 595514438F; Wed, 20 Jun 2001 12:35:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id A3C7844387
	for ; Wed, 20 Jun 2001 12:34:38 -0400 (EDT)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA24901;
	Wed, 20 Jun 2001 12:34:39 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA08046;
	Wed, 20 Jun 2001 12:34:29 -0400 (EDT)
Message-ID: <3B2F7C3E.BBC1A256@cs.columbia.edu>
From: Henning Schulzrinne 
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sankaran Narayanan 
Cc: "Menon, Sunil" , sip@lists.bell-labs.com
Subject: Re: [SIP] G729AB vs G729A
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 19 Jun 2001 09:22:22 -0700
Content-Transfer-Encoding: 7bit

Please - no X-anything codec names.

Sankaran Narayanan wrote:
> 
> >       Does anyone know how one would indicate G729AB vs G729A as the
> > preferred codec in SDP ?
> i remember reading somewhere X-G729ab and X-G729a, not sure though.
>



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


From sip-admin@ietf.org  Wed Jun 20 13:07:51 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14289;
	Wed, 20 Jun 2001 13:07:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26902;
	Wed, 20 Jun 2001 12:30:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26876
	for ; Wed, 20 Jun 2001 12:30:17 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12887
	for ; Wed, 20 Jun 2001 12:29:40 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA29221;
	Wed, 20 Jun 2001 12:29:44 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA06474;
	Wed, 20 Jun 2001 12:29:48 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 20 Jun 2001 12:29:46 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF044655B0@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Francois Audet'" ,
        "''sip@letf.org'"
	 
Cc: "Rosen, Brian" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	 er
Date: Wed, 20 Jun 2001 12:29:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F9A6.364B8460"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F9A6.364B8460
Content-Type: text/plain;
	charset="iso-8859-1"


Don't have a problem with UAs generating CDRs, and gateways are one place
where you might want to do that.  That would be a device implementation 
decision, and would not subject to standardization.  If we wanted to have a
UA 
send statistics somewhere, that would have protocol implications.
 
Brian

-----Original Message-----
From: Francois Audet [mailto:audet@nortelnetworks.com]
Sent: Wednesday, June 20, 2001 12:08 PM
To: 'sip@lists.bell-labs.com'
Cc: 'Rosen, Brian'
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
er



On the other hand, it may make a lot of sense for UAs to generate CDRs if it
is a gateway (especially if it is a gateway to an expensive PSTN where you
need to track charges accurately which I don't think will be possible if it
is based on SIP signalling).

It seems to me that they'd be network level CDRs using proxy servers, and
"local" ones that can be useful when somebody has figured our how to abuse
the system, or to calculate "real" charges from the PSTN.

	-----Original Message----- 
From:   Rosen, Brian [SMTP:Brian.Rosen@marconi.com] 
Sent:   Wednesday, June 20, 2001 06:02 
To:     'Jay Batson'; Ashhar Farhan; sip@lists.bell-labs.com 
Subject:        RE: [SIP] Authentication and billing through proxy/re-direct
serv er 

	Just for grins, what would you expect the charging to look like when
the 
terminating end is on a different network from the originating end, but they

were both sipphones?  Suppose there were three networks (a transit network 
as well as the originating and terminating networks)?  Suppose there was 
an enterprise network (no internal charging) connected to a public (IP)
network 
that charged by the minute? 
  
I don't want to start a debate on billing possibilities.  I do think that
you have to 
accept that CDRs may have to be generated at a few places in the network. 
I myself am not wild about UAs doing CDR generation.  I think proxy servers 
can do that.  The piece of information the PS doesn't have is the exact
connection 
time information.  We may want to be able to get that sent on a BYE.  
  
Suppose you just thought of this stuff as statistics.  There are several
interesting 
statistics you may wish to gather on a call (lost packets for example).
Sure, 
you could make this a management function, but you are then faced with
storage 
and other issues associated with a very large number of endpoints.  If you
could 
report statistics on a BYE, the PS could then generate the CDR. 
  
This may also help a problem we are currently calling "session management".
There 
is some work at the Softswitch Consortium on this.  It deals with the
following 
practical problem - your customer service center gets the following call "I
was 
just talking to my mother and I couldn't hear her".  Okay, what equipment
was used 
on that call, and where did it go wrong?  To make that really work EVERY
device 
that participates in some way on the call needs to report information on the
call, 
and it has to do so proactively.  This is equivalent to a CDR with more
information 
(statistics).  Yes, we could get UAs to generate them, but we could also
just pass 
up the info on BYE and let the PS save it, massage it, and send it on it's
way. 
  
Brian 
  
  
  

	-----Original Message-----
From: Jay Batson [ mailto:jbatson@pingtel.com  ]
Sent: Tuesday, June 19, 2001 5:59 PM
To: Ashhar Farhan; sip@lists.bell-labs.com
Subject: Re: [SIP] Authentication and billing through proxy/re-direct server


There is another possibility that "real commercial systems" might use (in
fact, are likely to use...):

- Charge only for PSTN gateway transit.
- Sessions that stay on the IP net (only) are built into a base
bandwidth/connectivity fee.

In this case, CDRs generated by the gateway will provide sufficient
information about PSTN connectivity to create billing info, wouldn't they?
Neither the proxy nor the originating (IP-network-resident) UA need to know
/ do anything....

-jb

At 03:28 AM 6/4/01, Ashhar Farhan wrote:


	in a typical next gen telco setup, the billing is centralised and
their Point of presence are basically SIP servers that gateway to PSTN
cloud.

the INVITE gets redirected/proxied from the central server and the is resend
to the gateway (a sip server).
here, we have an issue of user authentication. the user has to be
authenticated by the redirect/proxy server. the authentication (as per the
SIP recommendations) should be md5 digest.
the scheme would be that the redirect/proxy should generate a digest over
the redirected INVITE request using the nonce and password of the intended
server.

billing systems are usually needed to be centralised (esp. in those next gen
telcos where the servers are operated by franchises). this is a commercial
requirement of SIP operations.

the 2543.bis does not explicitly talk of the redirect/proxies authenticating
requests for the gateways.

the second issue:
the call minutes are the accepted billing mechanism for atleast the next
couple of years. to support billing, accurate times of call start and end
are important.
the call times maybe at variance between the client and the server due to a
the RTT nature of messaging itself. In that case, it will be advisable, from
a caller perspective to know when exactly did the call get disconnected (a
second's delay can roll the call over to the next minute) and how long did
the call last - as per server's record. Although MESSAGE can be used for
this, i would rather believe that a more intrinsic method must be available
to support this that can update the caller's own 'call meter'.

- farhan@hotfoon.com



_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
< http://bol.rediff.com/  >





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

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




------_=_NextPart_001_01C0F9A6.364B8460
Content-Type: text/html;
	charset="iso-8859-1"




RE: [SIP] Authentication and billing through proxy/re-direct serv er




<moved to 
sip@ietf.org>


Don't have a 
problem with UAs generating CDRs, and gateways are one place


where you 
might want to do that.  That would be a device 
implementation 


decision, and 
would not subject to standardization.  If we wanted to 
have a UA 


send 
statistics somewhere, that would have protocol 
implications.


 


Brian



  
-----Original Message-----
From: Francois Audet 
  [mailto:audet@nortelnetworks.com]
Sent: Wednesday, June 20, 2001 
  12:08 PM
To: 'sip@lists.bell-labs.com'
Cc: 'Rosen, 
  Brian'
Subject: RE: [SIP] Authentication and billing through 
  proxy/re-direct serv er


  
On the other hand, it may make a lot 
  of sense for UAs to generate CDRs if it is a gateway (especially if it is a 
  gateway to an expensive PSTN where you need to track charges accurately which 
  I don't think will be possible if it is based on SIP signalling).

  
It seems to me that they'd be network 
  level CDRs using proxy servers, and "local" ones that can be useful when 
  somebody has figured our how to abuse the system, or to calculate "real" 
  charges from the PSTN.

  
    
    
    -----Original Message----- 
    From:   Rosen, Brian [SMTP:Brian.Rosen@marconi.com] 
    Sent:   Wednesday, June 20, 2001 06:02 
    To:     'Jay 
    Batson'; Ashhar Farhan; sip@lists.bell-labs.com 
    Subject:        RE: [SIP] Authentication and billing through 
    proxy/re-direct serv er 
    
    
    Just for grins, what would you expect the 
    charging to look like when the 
    terminating end is on a different network from the originating 
    end, but they 
    were both 
    sipphones?  Suppose there were three networks (a transit network 
    
    as well as the originating and 
    terminating networks)?  Suppose there was 
    an enterprise network (no internal charging) connected to a 
    public (IP) network 
    that charged 
    by the minute? 
      
    I don't want to start a debate on billing 
    possibilities.  I do think that you have to 
    accept that CDRs may have to be generated at a few places in 
    the network. 
    I myself am not wild 
    about UAs doing CDR generation.  I think proxy servers 
    can do that.  The piece of information the PS 
    doesn't have is the exact connection 
    time information.  We may want to be able to get that 
    sent on a BYE.  
      
    Suppose you just thought of this stuff as 
    statistics.  There are several interesting 
    statistics you may wish to gather on a call (lost packets for 
    example).  Sure, 
    you could 
    make this a management function, but you are then faced with storage 
    
    and other issues associated with a very 
    large number of endpoints.  If you could 
    report statistics on a BYE, the PS could then generate the 
    CDR. 
      
    This may also help a problem we are currently calling "session 
    management".  There 
    is some 
    work at the Softswitch Consortium on this.  It deals with the 
    following 
    practical problem - your 
    customer service center gets the following call "I was 
    just talking to my mother and I couldn't hear 
    her".  Okay, what equipment was used 
    on that call, and where did it go wrong?  To make that 
    really work EVERY device 
    that 
    participates in some way on the call needs to report information on the 
    call, 
    and it has to do so 
    proactively.  This is equivalent to a CDR with more information 
    
    (statistics).  Yes, we could get UAs 
    to generate them, but we could also just pass 
    up the info on BYE and let the PS save it, massage it, and 
    send it on it's way. 
      
    Brian 
      
    
      
      
    
    
      
      
      -----Original Message-----
      From: Jay Batson 
      [mailto:jbatson@pingtel.com]
      Sent: Tuesday, June 
      19, 2001 5:59 PM
      To: Ashhar Farhan; 
      sip@lists.bell-labs.com
      Subject: Re: [SIP] 
      Authentication and billing through proxy/re-direct 
      server


      There is another possibility 
      that "real commercial systems" might use (in fact, are likely to 
      use...):

      - Charge only for PSTN gateway transit.
      - Sessions that 
      stay on the IP net (only) are built into a base bandwidth/connectivity 
      fee.

      In this case, CDRs generated by the gateway will provide 
      sufficient information about PSTN connectivity to create billing info, 
      wouldn't they?  Neither the proxy nor the originating 
      (IP-network-resident) UA need to know / do 
      anything....

      -jb

      At 03:28 AM 6/4/01, Ashhar Farhan 
      wrote:
      
      
        
        
        in a typical next gen telco setup, the billing is 
        centralised and their Point of presence are basically SIP servers that 
        gateway to PSTN cloud.

        the INVITE gets redirected/proxied from 
        the central server and the is resend to the gateway (a sip 
        server).
        here, we have an issue of user authentication. the user has 
        to be authenticated by the redirect/proxy server. the authentication (as 
        per the SIP recommendations) should be md5 digest.
        the scheme would 
        be that the redirect/proxy should generate a digest over the redirected 
        INVITE request using the nonce and password of the intended 
        server.

        billing systems are usually needed to be centralised 
        (esp. in those next gen telcos where the servers are operated by 
        franchises). this is a commercial requirement of SIP 
        operations.

        the 2543.bis does not explicitly talk of the 
        redirect/proxies authenticating requests for the gateways.

        the 
        second issue:
        the call minutes are the accepted billing mechanism for 
        atleast the next couple of years. to support billing, accurate times of 
        call start and end are important.
        the call times maybe at variance 
        between the client and the server due to a the RTT nature of messaging 
        itself. In that case, it will be advisable, from a caller perspective to 
        know when exactly did the call get disconnected (a second's delay can 
        roll the call over to the next minute) and how long did the call last - 
        as per server's record. Although MESSAGE can be used for this, i would 
        rather believe that a more intrinsic method must be available to support 
        this that can update the caller's own 'call meter'.

        - 
        farhan@hotfoon.com



        _____________________________________________________
        Chat 
        with your friends as soon as they come online. Get Rediff Bol 
        at
        <http://bol.rediff.com/>





        _______________________________________________
        This list 
        is for continuing development of the SIP protocol.
        The 
        sip-implementor's list is the place to discuss implementation,
        and to 
        receive advice on understanding existing sip.
        To subscribe to it, 
        send mail to
        sip-implementors-request@cs.columbia.edu with 
        "subscribe" in the body.         
      
      
      -------------
      Ping      Me!
      Jay Batson
      CEO
      Pingtel Corp.
      <mailto:jbatson@pingtel.com>
      781-938-5306 
(office)



------_=_NextPart_001_01C0F9A6.364B8460--

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 20 13:26:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15044;
	Wed, 20 Jun 2001 13:26:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28740;
	Wed, 20 Jun 2001 13:04:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28711
	for ; Wed, 20 Jun 2001 13:04:04 -0400 (EDT)
Received: from ertpg15e1.nortelnetworks.com (ertpg15e1.nortelnetworks.com [47.234.0.36])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14168
	for ; Wed, 20 Jun 2001 13:03:29 -0400 (EDT)
Received: from ertpg14e1.nortelnetworks.com (zrtph06m [47.125.208.110])
	by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f5KH3Xq15728
	for ; Wed, 20 Jun 2001 13:03:33 -0400 (EDT)
Received: from zrtpd004.us.nortel.com (actually zrtpd004) 
          by ertpg14e1.nortelnetworks.com; Wed, 20 Jun 2001 13:03:21 -0400
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id ; Wed, 20 Jun 2001 13:03:21 -0400
Message-ID: <63E0DAD7784FD21188310000F80824B306A0A138@zmpkdx02.us.nortel.com>
From: "Francois Audet" 
To: "'Rosen, Brian'" ,
        "''sip@letf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv er
Date: Wed, 20 Jun 2001 13:03:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0F9AA.DF219350"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F9AA.DF219350
Content-Type: text/plain

Agreed.

> -----Original Message-----
> From:	Rosen, Brian [SMTP:Brian.Rosen@marconi.com]
> Sent:	Wednesday, June 20, 2001 09:30
> To:	Audet, Francois [SC2:4K02:EXCH]; ''sip@letf.org'
> Cc:	Rosen, Brian
> Subject:	RE: [SIP] Authentication and billing through proxy/re-direct
> serv er
> 
> 
> Don't have a problem with UAs generating CDRs, and gateways are one place
> where you might want to do that.  That would be a device implementation 
> decision, and would not subject to standardization.  If we wanted to have
> a UA 
> send statistics somewhere, that would have protocol implications.
>  
> Brian
> 
> 

------_=_NextPart_001_01C0F9AA.DF219350
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Authentication and billing through proxy/re-direct =
serv er




Agreed.



    

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

    From:   Rosen, Brian =
[SMTP:Brian.Rosen@marconi.com]

    Sent:   Wednesday, June 20, 2001 09:30

    To:     Audet, Francois [SC2:4K02:EXCH]; ''sip@letf.org'

    Cc:     Rosen, Brian

    Subject:       =
 RE: [SIP] Authentication and billing =
through proxy/re-direct serv er

    


    <moved to =
sip@ietf.org>

    Don't have a problem with =
UAs generating CDRs, and gateways are one place

    where you might want to do =
that.=A0 That would be a device implementation=A0

    decision, and would not =
subject to standardization.=A0 If we wanted to have a UA=20

    send statistics somewhere, =
that would have protocol implications.

    =A0

    Brian

    

    




------_=_NextPart_001_01C0F9AA.DF219350--

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jun 20 13:56:34 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16046
	for ; Wed, 20 Jun 2001 13:56:34 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 862BE4437A; Wed, 20 Jun 2001 13:57:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from bosx.mck.com (unknown [208.51.231.25])
	by lists.bell-labs.com (Postfix) with ESMTP id 339D644336
	for ; Wed, 20 Jun 2001 13:56:15 -0400 (EDT)
Received: by bosx.mck.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 20 Jun 2001 13:51:43 -0400
Message-ID: <03941963AA30D4119A68009027D5BFFDB402FC@bosx.mck.com>
From: Dean Bogdanovic 
To: "'Wai Wu'" , "'Jay Batson'" ,
        Venkatesh Venkataramanan ,
        "'Jean-Francois Mule'" ,
        "'Rohan Mahy'" , islain@cisco.com,
        sip@lists.bell-labs.com
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F9B1.A727E0B0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 13:51:37 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F9B1.A727E0B0
Content-Type: text/plain;
	charset="iso-8859-1"

Wai
I would disagree with you. Audio/visual notifications are important to end
user and I belive giving some extensions to SIP will help the adoption by
the endusers. As Jay had mentioned it
 

Regards 

Dean Bogdanovic 
MCK Communications 
phone:(617)454 6165 
fax:(617)454 6101 
___________________ 
"the answer is 42" 


-----Original Message-----
From: Wai Wu [mailto:wwu@calltrol.com]
Sent: Wednesday, June 20, 2001 10:40 AM
To: 'Jay Batson'; Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan
Mahy'; islain@cisco.com; sip@lists.bell-labs.com
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt


I think features normally found on a PBX phone (e.g. message waiting)
shouldn't be part of SIP at all. If we put all these things in SIP, it will
make SIP not much different from a "standardized PBX protocol". 

-----Original Message-----
From: Jay Batson [mailto:jbatson@pingtel.com]
Sent: Tuesday, June 19, 2001 3:37 PM
To: Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan Mahy';
islain@cisco.com; sip@lists.bell-labs.com
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt


My comments aren't timely, so my apologies.

Venkatesh's comments are also consistent with typical IETF protocol /
application design.  Example:  Neither SMTP nor POP/IMAP specify how the
email "user agent" (Eudora, Netscape, Outlook) provides visual indication of
email message priority (X-Priority).

The creator of a given user agent defines its own user interfaces to
information that is provided in the standardized lower later protocol.  End
users then choose among available user agents (and behaviors) to get their
desired interaction.

Applications at either end of a transaction may want to agree on
Experimental extensions to show more information, such as the type that
Jean-Francois suggests.  In fact, this is how X-Priority came into being in
email!  Eudora just up and did it one day, and everybody else did what they
did!

-jb


At 03:29 PM 4/26/01, Venkatesh Venkataramanan wrote:


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

Venkatesh

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


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

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


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

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




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









Wai


I 
would disagree with you. Audio/visual notifications are important to end user 
and I belive giving some extensions to SIP will help the adoption by the 
endusers. As Jay had mentioned it


 


Regards 


Dean Bogdanovic 
MCK Communications 
phone:(617)454 
6165 
fax:(617)454 6101 
___________________ 
"the 
answer is 42" 




  
-----Original Message-----
From: Wai Wu 
  [mailto:wwu@calltrol.com]
Sent: Wednesday, June 20, 2001 10:40 
  AM
To: 'Jay Batson'; Venkatesh Venkataramanan; 'Jean-Francois Mule'; 
  'Rohan Mahy'; islain@cisco.com; sip@lists.bell-labs.com
Subject: RE: 
  [SIP] draft-mahy-sip-message-waiting-01.txt


  
I 
  think features normally found on a PBX phone (e.g. message waiting) shouldn't 
  be part of SIP at all. If we put all these things in SIP, it will make SIP not 
  much different from a "standardized PBX protocol". 

  

    
-----Original Message-----
From: Jay Batson 
    [mailto:jbatson@pingtel.com]
Sent: Tuesday, June 19, 2001 3:37 
    PM
To: Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan 
    Mahy'; islain@cisco.com; sip@lists.bell-labs.com
Subject: RE: 
    [SIP] draft-mahy-sip-message-waiting-01.txt

My comments 
    aren't timely, so my apologies.

Venkatesh's comments are also 
    consistent with typical IETF protocol / application design.  
    Example:  Neither SMTP nor POP/IMAP specify how the email "user agent" 
    (Eudora, Netscape, Outlook) provides visual indication of email message 
    priority (X-Priority).

The creator of a given user agent defines its 
    own user interfaces to information that is provided in the standardized 
    lower later protocol.  End users then choose among available user 
    agents (and behaviors) to get their desired interaction.

Applications 
    at either end of a transaction may want to agree on Experimental extensions 
    to show more information, such as the type that Jean-Francois 
    suggests.  In fact, this is how X-Priority came into being in 
    email!  Eudora just up and did it one day, and everybody else did what 
    they did!

-jb


At 03:29 PM 4/26/01, Venkatesh 
    Venkataramanan wrote:

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

Venkatesh

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


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

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


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

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



------_=_NextPart_001_01C0F9B1.A727E0B0--

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


From sip-admin@lists.bell-labs.com  Wed Jun 20 13:58:23 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16104
	for ; Wed, 20 Jun 2001 13:58:22 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8CDD644394; Wed, 20 Jun 2001 13:57:20 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailstore.ttiworld.com (mailstore.ttimail.com [216.86.19.120])
	by lists.bell-labs.com (Postfix) with ESMTP id 8B8D644336
	for ; Wed, 20 Jun 2001 13:56:46 -0400 (EDT)
Received: from ttimail.com ([10.10.100.1])
	by mailstore.ttiworld.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id MAA18679
	for ; Wed, 20 Jun 2001 12:56:46 -0500
Received: from host-1.ttiworld.com (host-1.ttiworld.com) by ttimail.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Wed, 20 Jun 2001 12:56:42 -0500
x-mimeole: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
Subject: RE: [SIP] G729AB vs G729A
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <902018BBF7D7A0469225C83FBFE45F860C173F@host-1.ttiworld.com>
Thread-Topic: [SIP] G729AB vs G729A
Thread-Index: AcD5pw+QdGV7QxcbSSSjabD2Zn9+IwACzq7w
From: "Kevin Summers" 
To: "Henning Schulzrinne" ,
        "Sankaran Narayanan" 
Cc: "Sunil Menon" , 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 12:56:42 -0500
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA16104

Does this qualify as a new payload type to be registered with IANA?

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Tuesday, June 19, 2001 11:22 AM
To: Sankaran Narayanan
Cc: Sunil Menon; sip@lists.bell-labs.com
Subject: Re: [SIP] G729AB vs G729A


Please - no X-anything codec names.

Sankaran Narayanan wrote:
> 
> >       Does anyone know how one would indicate G729AB vs G729A as the
> > preferred codec in SDP ?
> i remember reading somewhere X-G729ab and X-G729a, not sure though.
>



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

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


From sip-admin@lists.bell-labs.com  Wed Jun 20 14:02:05 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16295
	for ; Wed, 20 Jun 2001 14:02:05 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9F38D443AE; Wed, 20 Jun 2001 14:00:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from revere.sonusnet.com (mail.sonusnet.com [63.99.71.102])
	by lists.bell-labs.com (Postfix) with ESMTP id 48F24443AC
	for ; Wed, 20 Jun 2001 13:59:53 -0400 (EDT)
Received: from sonusdc3.sonusnet.com (sonusdc3 [10.128.32.53])
	by revere.sonusnet.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5KHtZr23263;
	Wed, 20 Jun 2001 13:55:35 -0400 (EDT)
Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 20 Jun 2001 13:59:11 -0400
Message-ID: <594A6AF62343D511B4750060CF20BAF305E5F3@sonusdc5.sonusnet.com>
From: "Menon, Sunil" 
To: "Summers, Kevin" ,
        Henning Schulzrinne ,
        Sankaran Narayanan 
Cc: "Menon, Sunil" , sip@lists.bell-labs.com
Subject: RE: [SIP] G729AB vs G729A
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 13:59:11 -0400

Is it expected that devices interpret 18 as either G729A or G729AB,
according to their resource availability, configuration etc, and that G729A
and G729AB are interoperable ? 

-----Original Message-----
From: Kevin Summers [mailto:Kevin.Summers@ttimail.com]
Sent: Wednesday, June 20, 2001 1:57 PM
To: Henning Schulzrinne; Sankaran Narayanan
Cc: Sunil Menon; sip@lists.bell-labs.com
Subject: RE: [SIP] G729AB vs G729A


Does this qualify as a new payload type to be registered with IANA?

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Tuesday, June 19, 2001 11:22 AM
To: Sankaran Narayanan
Cc: Sunil Menon; sip@lists.bell-labs.com
Subject: Re: [SIP] G729AB vs G729A


Please - no X-anything codec names.

Sankaran Narayanan wrote:
> 
> >       Does anyone know how one would indicate G729AB vs G729A as the
> > preferred codec in SDP ?
> i remember reading somewhere X-G729ab and X-G729a, not sure though.
>



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

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


From sip-admin@lists.bell-labs.com  Wed Jun 20 14:23:33 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17067
	for ; Wed, 20 Jun 2001 14:23:33 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CAD604438E; Wed, 20 Jun 2001 14:24:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from voyager.pointone.com (p1-5424223.PointOne.com [216.54.242.23])
	by lists.bell-labs.com (Postfix) with ESMTP id 584734438D
	for ; Wed, 20 Jun 2001 14:23:55 -0400 (EDT)
Received: by Voyager.pointone.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 20 Jun 2001 13:19:32 -0500
Message-ID: <4835F9A29A7BD411A9C600B0D049359B01346854@Voyager.pointone.com>
From: Jasson Casey 
To: "'sip@lists.bell-labs.com'" 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] [SIP]Transcoding
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 13:19:30 -0500

I was curious if there had been any work done on standard call flows for
transcoding devices. If anyone could point me to some reference material it
would be appreciated.

Thanks,

Jasson Casey
jcasey@pointone.com

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


From sip-admin@lists.bell-labs.com  Wed Jun 20 14:29:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17230
	for ; Wed, 20 Jun 2001 14:29:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5023C4439F; Wed, 20 Jun 2001 14:30:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id C522F4438D
	for ; Wed, 20 Jun 2001 14:29:57 -0400 (EDT)
Received: from jku.fokus.gmd.de (dhcp045 [195.37.78.173])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id UAA01497;
	Wed, 20 Jun 2001 20:29:37 +0200 (MET DST)
Message-Id: <5.1.0.14.0.20010620202239.026b0898@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: "Rosen, Brian" ,
        "'Jay Batson'" ,
        Ashhar Farhan , sip@lists.bell-labs.com
From: Jiri Kuthan 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct
  serv er
In-Reply-To: <4FBEA8857476D311A03300204840E1CF0446559E@whq-msgusr-02.pit
 .comms.marconi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 20:33:02 +0200

At 03:01 PM 6/20/2001, Rosen, Brian wrote:
[...]
>I myself am not wild about UAs doing CDR generation.  I think proxy servers 
>can do that.  The piece of information the PS doesn't have is the exact connection
>time information.  

My opinion on network configuration is that CDR/AAA functionality 
is best hooked to the same place where the particular AAA-fizied 
service is actually provided. 

If we speak about PSTN call termination service, I think gateways 
would be a better place to hook AAA than proxies. A particular advantage 
of gateways (i.e., UAs from SIP perspective) doing the AAA job is it 
works even if subsequent SIP requests take a different path and do not
hit the same proxy. It sounds better to me than attempts to force 
routes by RR or B2B.

If transport services were hooked to AAA systems somehow (e.g., premium 
PSTN termination service incl. RSVP), it would be probably also easier 
to do the AAA job in gateways rather than in SIP proxies.

Note that having gateways done the AAA job from SIP perspective does not 
necessarily imply that the entire AAA functionality resides in gateways. 
More likely, it would be outsourced to a AAA server.

Jiri


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


From sip-admin@lists.bell-labs.com  Wed Jun 20 14:38:37 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17569
	for ; Wed, 20 Jun 2001 14:38:36 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 017994438C; Wed, 20 Jun 2001 14:39:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from commserver.iperia.com (unknown [63.84.167.3])
	by lists.bell-labs.com (Postfix) with ESMTP id 83F2444336
	for ; Wed, 20 Jun 2001 14:38:50 -0400 (EDT)
Received: by commserver with Internet Mail Service (5.5.2653.19)
	id ; Wed, 20 Jun 2001 14:37:26 -0400
Message-ID: <5143F854B82ED211B05E00104B235F64807BD5@commserver>
From: Gordon Ledgard 
To: "'Dean Bogdanovic'" , "'Wai Wu'" ,
        "'Jay Batson'" ,
        Venkatesh Venkataramanan ,
        "'Jean-Francois Mule'" ,
        "'Rohan Mahy'" , islain@cisco.com,
        sip@lists.bell-labs.com
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0F9B8.0C81DD70"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 14:37:24 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0F9B8.0C81DD70
Content-Type: text/plain;
	charset="iso-8859-1"

Agree.
 
There isn't anything inherently un-SIP like about providing some set of
common network
or user notification features.  The danger, as Venkatesh points out, is
making them application
specific, like jumping to the conclusion that I want to turn on a light, or
dictating how that
notification is to be interpreted by the recieving endpoint.
 

-----Original Message-----
From: Dean Bogdanovic [mailto:deanb@mck.com]
Sent: Wednesday, June 20, 2001 1:52 PM
To: 'Wai Wu'; 'Jay Batson'; Venkatesh Venkataramanan; 'Jean-Francois Mule';
'Rohan Mahy'; islain@cisco.com; sip@lists.bell-labs.com
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt


Wai
I would disagree with you. Audio/visual notifications are important to end
user and I belive giving some extensions to SIP will help the adoption by
the endusers. As Jay had mentioned it
 

Regards 

Dean Bogdanovic 
MCK Communications 
phone:(617)454 6165 
fax:(617)454 6101 
___________________ 
"the answer is 42" 


-----Original Message-----
From: Wai Wu [mailto:wwu@calltrol.com]
Sent: Wednesday, June 20, 2001 10:40 AM
To: 'Jay Batson'; Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan
Mahy'; islain@cisco.com; sip@lists.bell-labs.com
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt


I think features normally found on a PBX phone (e.g. message waiting)
shouldn't be part of SIP at all. If we put all these things in SIP, it will
make SIP not much different from a "standardized PBX protocol". 

-----Original Message-----
From: Jay Batson [mailto:jbatson@pingtel.com]
Sent: Tuesday, June 19, 2001 3:37 PM
To: Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan Mahy';
islain@cisco.com; sip@lists.bell-labs.com
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt


My comments aren't timely, so my apologies.

Venkatesh's comments are also consistent with typical IETF protocol /
application design.  Example:  Neither SMTP nor POP/IMAP specify how the
email "user agent" (Eudora, Netscape, Outlook) provides visual indication of
email message priority (X-Priority).

The creator of a given user agent defines its own user interfaces to
information that is provided in the standardized lower later protocol.  End
users then choose among available user agents (and behaviors) to get their
desired interaction.

Applications at either end of a transaction may want to agree on
Experimental extensions to show more information, such as the type that
Jean-Francois suggests.  In fact, this is how X-Priority came into being in
email!  Eudora just up and did it one day, and everybody else did what they
did!

-jb


At 03:29 PM 4/26/01, Venkatesh Venkataramanan wrote:


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

Venkatesh

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


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

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


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

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




------_=_NextPart_001_01C0F9B8.0C81DD70
Content-Type: text/html;
	charset="iso-8859-1"









Agree.


 


There 
isn't anything inherently un-SIP like about providing some set of common 
network


or 
user notification features.  The danger, as Venkatesh points 
out, is making them application


specific, like jumping to the conclusion that I want to turn on a light, 
or dictating how that


notification is to be interpreted by the recieving 
endpoint.


 



  
-----Original Message-----
From: Dean Bogdanovic 
  [mailto:deanb@mck.com]
Sent: Wednesday, June 20, 2001 1:52 
  PM
To: 'Wai Wu'; 'Jay Batson'; Venkatesh Venkataramanan; 
  'Jean-Francois Mule'; 'Rohan Mahy'; islain@cisco.com; 
  sip@lists.bell-labs.com
Subject: RE: [SIP] 
  draft-mahy-sip-message-waiting-01.txt


  
Wai

  
I 
  would disagree with you. Audio/visual notifications are important to end user 
  and I belive giving some extensions to SIP will help the adoption by the 
  endusers. As Jay had mentioned it

  
 

  
Regards 

  
Dean Bogdanovic 
MCK Communications 
phone:(617)454 
  6165 
fax:(617)454 6101 
___________________ 
"the 
  answer is 42" 


  

    
-----Original Message-----
From: Wai Wu 
    [mailto:wwu@calltrol.com]
Sent: Wednesday, June 20, 2001 10:40 
    AM
To: 'Jay Batson'; Venkatesh Venkataramanan; 'Jean-Francois 
    Mule'; 'Rohan Mahy'; islain@cisco.com; 
    sip@lists.bell-labs.com
Subject: RE: [SIP] 
    draft-mahy-sip-message-waiting-01.txt


    
I 
    think features normally found on a PBX phone (e.g. message waiting) 
    shouldn't be part of SIP at all. If we put all these things in SIP, it will 
    make SIP not much different from a "standardized PBX protocol". 
    

    

      
-----Original Message-----
From: Jay Batson 
      [mailto:jbatson@pingtel.com]
Sent: Tuesday, June 19, 2001 3:37 
      PM
To: Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan 
      Mahy'; islain@cisco.com; sip@lists.bell-labs.com
Subject: RE: 
      [SIP] draft-mahy-sip-message-waiting-01.txt

My 
      comments aren't timely, so my apologies.

Venkatesh's comments are 
      also consistent with typical IETF protocol / application design.  
      Example:  Neither SMTP nor POP/IMAP specify how the email "user 
      agent" (Eudora, Netscape, Outlook) provides visual indication of email 
      message priority (X-Priority).

The creator of a given user agent 
      defines its own user interfaces to information that is provided in the 
      standardized lower later protocol.  End users then choose among 
      available user agents (and behaviors) to get their desired 
      interaction.

Applications at either end of a transaction may want 
      to agree on Experimental extensions to show more information, such as the 
      type that Jean-Francois suggests.  In fact, this is how X-Priority 
      came into being in email!  Eudora just up and did it one day, and 
      everybody else did what they did!

-jb


At 03:29 PM 
      4/26/01, Venkatesh Venkataramanan wrote:

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

Venkatesh

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


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

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


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

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



------_=_NextPart_001_01C0F9B8.0C81DD70--

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


From sip-admin@lists.bell-labs.com  Wed Jun 20 15:13:34 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18920
	for ; Wed, 20 Jun 2001 15:13:33 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 41116443A7; Wed, 20 Jun 2001 15:14:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailstore.ttiworld.com (mailstore.ttimail.com [216.86.19.120])
	by lists.bell-labs.com (Postfix) with ESMTP id C1BAC44352
	for ; Wed, 20 Jun 2001 15:13:59 -0400 (EDT)
Received: from ttimail.com ([10.10.100.1])
	by mailstore.ttiworld.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id OAA18728
	for ; Wed, 20 Jun 2001 14:14:00 -0500
Received: from host-1.ttiworld.com (host-1.ttiworld.com) by ttimail.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Wed, 20 Jun 2001 14:13:58 -0500
x-mimeole: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
Subject: RE: [SIP] G729AB vs G729A 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <902018BBF7D7A0469225C83FBFE45F860C1743@host-1.ttiworld.com>
Thread-Topic: [SIP] G729AB vs G729A 
Thread-Index: AcD5ucItIT6yCb4aS0mmqdSQ2vKCgQAAuftQ
From: "Kevin Summers" 
To: "Colin Perkins" ,
        "Kevin Summers" 
Cc: "Henning Schulzrinne" ,
        "Sankaran Narayanan" ,
        "Sunil Menon" , 
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 20 Jun 2001 14:13:58 -0500
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA18920

Thanks, Colin. It does indeed seem to be sufficient.

-----Original Message-----
From: Colin Perkins [mailto:csp@isi.edu]
Sent: Wednesday, June 20, 2001 1:03 PM
To: Kevin Summers
Cc: Henning Schulzrinne; Sankaran Narayanan; Sunil Menon;
sip@lists.bell-labs.com
Subject: Re: [SIP] G729AB vs G729A 


Can someone explain why the existing signalling method is not
sufficient? 
See draft-ietf-avt-profile-new-10.txt and draft-ietf-avt-rtp-mime-04.txt


Colin



--> "Kevin Summers" writes:
>Does this qualify as a new payload type to be registered with IANA?
>
>-----Original Message-----
>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
>Sent: Tuesday, June 19, 2001 11:22 AM
>To: Sankaran Narayanan
>Cc: Sunil Menon; sip@lists.bell-labs.com
>Subject: Re: [SIP] G729AB vs G729A
>
>
>Please - no X-anything codec names.
>
>Sankaran Narayanan wrote:
>> 
>> >       Does anyone know how one would indicate G729AB vs G729A as
the
>> > preferred codec in SDP ?
>> i remember reading somewhere X-G729ab and X-G729a, not sure though.
>>
>
>
>
>_______________________________________________
>This list is for continuing development of the SIP protocol.
>The sip-implementor's list is the place to discuss implementation,
>and to receive advice on understanding existing sip.
>To subscribe to it, send mail to 
>sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
>
>_______________________________________________
>This list is for continuing development of the SIP protocol.
>The sip-implementor's list is the place to discuss implementation,
>and to receive advice on understanding existing sip.
>To subscribe to it, send mail to 
>sip-implementors-request@cs.columbia.edu with "subscribe" in the body.

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


From sip-admin@ietf.org  Wed Jun 20 16:16:09 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21025;
	Wed, 20 Jun 2001 16:16:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05856;
	Wed, 20 Jun 2001 16:04:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05826
	for ; Wed, 20 Jun 2001 16:04:04 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20678
	for ; Wed, 20 Jun 2001 16:03:27 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA05492;
	Wed, 20 Jun 2001 16:08:00 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 20 Jun 2001 16:03:55 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'James Undery'" , aki.niemi@nokia.com
Cc: corey@hearme.com, Jonathan Rosenberg ,
        sip@ietf.org
Subject: RE: [Sip] Request header integrity in HTTP Digest
Date: Wed, 20 Jun 2001 16:03:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: James Undery [mailto:jundery@ubiquity.net]
> Sent: Tuesday, June 19, 2001 7:56 AM
> To: aki.niemi@nokia.com
> Cc: corey@hearme.com; jdrosen@dynamicsoft.com; sip@ietf.org
> Subject: Re: [Sip] Request header integrity in HTTP Digest
> 
> 
> 
> 
> aki.niemi@nokia.com wrote:
> 
> > Hi,
> >
> > > Corey Gates wrote:
> > >
> > > > Jonathan,
> > > >
> > > > I believe you left out the "private-key" in the nonce 
> computation in
> > > > draft-rosenberg-sip-http-pnonce-00.txt.  The nonce should be:
> > > >
> > > > nonce = H(source-IP: > > > protected>:round-time:private-key)
> > > >
> > > > Without this the nonce could be generated.
> > >
> > > I fail to see what you've gained by hashing the password into
> > > the nonce,
> > > the nonce is only really
> > > there so the server can be sure the client's messages aren't
> > > just being
> > > replayed, the client will hash in the password to provide
> > > authentication. (Obviously this explanation is very simplistic.)
> >
> > As in RFC 2617, I think what was meant here was, that the 
> private-key is
> > just some data only known to the server and not the shared secret
> > (password).
> >
> > I think this would also make sense for pnonce, since otherwise all
> > information contained in the hash can readily be found from 
> the message
> > itself.
> 
> True although is only a suggestion for nonce generation, and digest
> authentication is quite weak.  The real problem with this 
> draft is it is
> just plain broken. 

The only thing thats broken is your perception of the problem being solved.

Your gripe is with the authors of rfc2617, not me. Please feel free to send
them a note saying that rfc2617 is "just plain broken". They may be
offended, but they will probably have to agree with you that the problem you
describe exists. The problem is not a problem with this draft, its a problem
with digest, and is not fixed by this draft. Digest provides weak security,
no doubt. The right way to ultimately fix it is to have a nice, fully scoped
out, shared secret and/or public key encryption/authentication mechanism.
But, we don't have that right now. 

The mechanism described in the draft provides a level of security that is
better than digest. It fixes some of the most horrible and easiest to launch
attacks (especially the replay ones). It doesn't fix all of them, including
the MITM attack you describe. However, the cost for this fix is *zero*,
since it requires no changes in the specs or client behaviors. It is an
implementation choice for the server, and the decision to use it can be made
independently for each transaction in each server, without impacting any
other devices. The only reason why it even needs to be discussed at all is
that it is best served by a one-liner in the SIP spec that says you
shouldn't generally change the SIP message between the initial request and
the new request with credentials. Not that anyone actually does change the
headers that are being protected, as far as I know, but its nice to just say
it.

So, to be clear, I am not proposing that this is the be-all and end-all of
security. It is, IMHO, a very elegant and simple fix that improves the
performance of digest significantly beyond where it is now. 

-Jonathan R.


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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 20 17:22:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23400;
	Wed, 20 Jun 2001 17:22:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08351;
	Wed, 20 Jun 2001 17:14:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA08318
	for ; Wed, 20 Jun 2001 17:14:11 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23076
	for ; Wed, 20 Jun 2001 17:13:28 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA21131;
	Wed, 20 Jun 2001 17:13:32 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19195;
	Wed, 20 Jun 2001 17:13:36 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 20 Jun 2001 17:13:34 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF044655B1@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Jiri Kuthan'" ,
        "Rosen, Brian"
	 ,
        Ashhar Farhan ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	 er
Date: Wed, 20 Jun 2001 17:13:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



I don't want to cast this in terms of billing == too narrow.
I want to be able to get information about a call out of
all of the devices in a call, including the proxies and the
UAs, and that includes the gateways.  The information I want to
get is statistics about the call.

I CAN do this with another interface; Radius for example, or SNMP.
I suspect it might be better, for UAs at least, to send this
call-related info up the chain to a proxy server.  If I don't,
then I force EVERY device in my network to have to implement this
other interface, whatever it is.

If it is done by some other interface, or it is done locally in the
UA, then we don't have any work in the sip WG.  If we DO want to
be able to pass statistics up, then we might need something in sip.

I would specifically point out that doing some things in gateways
limits network design.  What if the call doesn't have one end on
a gateway?  It IS reasonable to do some things in UAs, but then it
has to work reasonably in all UAs.

Brian



> -----Original Message-----
> From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de]
> Sent: Wednesday, June 20, 2001 2:33 PM
> To: Rosen, Brian; 'Jay Batson'; Ashhar Farhan; sip@lists.bell-labs.com
> Subject: RE: [SIP] Authentication and billing through proxy/re-direct
> serv er
> 
> 
> At 03:01 PM 6/20/2001, Rosen, Brian wrote:
> [...]
> >I myself am not wild about UAs doing CDR generation.  I 
> think proxy servers 
> >can do that.  The piece of information the PS doesn't have 
> is the exact connection
> >time information.  
> 
> My opinion on network configuration is that CDR/AAA functionality 
> is best hooked to the same place where the particular AAA-fizied 
> service is actually provided. 
> 
> If we speak about PSTN call termination service, I think gateways 
> would be a better place to hook AAA than proxies. A 
> particular advantage 
> of gateways (i.e., UAs from SIP perspective) doing the AAA job is it 
> works even if subsequent SIP requests take a different path and do not
> hit the same proxy. It sounds better to me than attempts to force 
> routes by RR or B2B.
> 
> If transport services were hooked to AAA systems somehow 
> (e.g., premium 
> PSTN termination service incl. RSVP), it would be probably 
> also easier 
> to do the AAA job in gateways rather than in SIP proxies.
> 
> Note that having gateways done the AAA job from SIP 
> perspective does not 
> necessarily imply that the entire AAA functionality resides 
> in gateways. 
> More likely, it would be outsourced to a AAA server.
> 
> Jiri
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> 

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Wed Jun 20 19:16:07 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26046;
	Wed, 20 Jun 2001 19:16:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11985;
	Wed, 20 Jun 2001 19:06:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11899
	for ; Wed, 20 Jun 2001 19:06:47 -0400 (EDT)
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25768
	for ; Wed, 20 Jun 2001 19:06:12 -0400 (EDT)
Received: from jku.fokus.gmd.de (dhcp045 [195.37.78.173])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id BAA23075;
	Thu, 21 Jun 2001 01:06:34 +0200 (MET DST)
Message-Id: <5.1.0.14.0.20010621005545.00aac608@mailhub.fokus.gmd.de>
X-Sender: jku@mailhub.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 21 Jun 2001 01:09:58 +0200
To: Michael Thomas , "Rosen, Brian" 
From: Jiri Kuthan 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct
  serv er
Cc: "'Jay Batson'" ,
        Ashhar Farhan , sip@ietf.org
In-Reply-To: <15152.46136.176031.1595@thomasm-u1.cisco.com>
References: <4FBEA8857476D311A03300204840E1CF0446559E@whq-msgusr-02.pit.comms.marconi.com>
 <4FBEA8857476D311A03300204840E1CF0446559E@whq-msgusr-02.pit.comms.marconi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

At 04:33 PM 6/20/2001, Michael Thomas wrote:
[...]
> To be free
>from fraud, a trusted device *in the media path*
>must be capable of determining session start and
>end, etc. Not the signaling path; it can be
>duped. 

Michael,

could you give more details on what kind of fraud is
expected to be prevented by what kind of middleboxes?

> However, for calls that begin and terminate
>on untrusted devices (say, our Brian and my home
>SIP phones), you either need some sort of middle
>box, or you need to just get over any thought of
>it being secure.

I did not understand this either -- I think that
if you call Brian using your SIP phone and both of 
you guys pay to your ISP, everyone will be happy. 
What do I need a middlebox for?

Jiri


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jun 21 00:24:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03803
	for ; Thu, 21 Jun 2001 00:24:35 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1E8324434C; Thu, 21 Jun 2001 00:25:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from md4.vsnl.net.in (md4.vsnl.net.in [202.54.6.60])
	by lists.bell-labs.com (Postfix) with ESMTP id 80B0D44336
	for ; Thu, 21 Jun 2001 00:24:06 -0400 (EDT)
Received: from VOYAGER (unknown [61.1.217.35])
	by md4.vsnl.net.in (Postfix) with SMTP id E92D6A242
	for ; Thu, 21 Jun 2001 09:53:33 +0530 (IST)
Received: by VOYAGER with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 09:44:23 +0530
Message-ID: 
From: Sameer sheth 
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] How to unsubscribe
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 21 Jun 2001 09:44:19 +0530


Hi !

	Can anyone tell me how to unsubscribe from this list.

Thank you

Sincerely
Sameer
> -----------------------------------
> Sameer.Sheth
> Analysts
> Justvox ---> We(b) Speak, Your Way
> T/F: +91-422-446127 / 456753 
> 
> ***************************************
> 
> 

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


From sip-admin@ietf.org  Thu Jun 21 02:48:28 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19352;
	Thu, 21 Jun 2001 02:48:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00483;
	Thu, 21 Jun 2001 02:27:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00452
	for ; Thu, 21 Jun 2001 02:27:49 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17556
	for ; Thu, 21 Jun 2001 02:27:14 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA12276;
	Thu, 21 Jun 2001 02:31:45 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 02:27:40 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Rosen, Brian'" ,
        "'Jiri Kuthan'"
	 ,
        Ashhar Farhan ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	 er
Date: Thu, 21 Jun 2001 02:27:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: Wednesday, June 20, 2001 5:14 PM
> To: 'Jiri Kuthan'; Rosen, Brian; Ashhar Farhan; 'sip@ietf.org'
> Subject: RE: [SIP] Authentication and billing through proxy/re-direct
> serv er
> 
> 
> 
> 
> I don't want to cast this in terms of billing == too narrow.
> I want to be able to get information about a call out of
> all of the devices in a call, including the proxies and the
> UAs, and that includes the gateways.  The information I want to
> get is statistics about the call.
> 
> I CAN do this with another interface; Radius for example, or SNMP.
> I suspect it might be better, for UAs at least, to send this
> call-related info up the chain to a proxy server.  If I don't,
> then I force EVERY device in my network to have to implement this
> other interface, whatever it is.

I really, really disagree that we should ever be propagating usage
information in SIP in order to avoid interfaces between multiple elements
and backened recording servers. Why? Well, what information is needed
depends a WHOLE lot on the service being offered, the billing models, the
operational requirements, etc. Since it depends on the service being
offered, standardizing a protocol extension for conveying this information
is akin to standardizing the set of services one might eventually offer. I
think people know my opinion on standardizing all the services on might
offer... horrible idea. 

So, the idea is to buy SIP elements (proxies, gateways, media servers, etc.)
that can generate usage recording with every darn piece of information one
might ever want to see, and make it nicely configurable. Then, depending on
the service you offer, different information is generated.

Its very likely that more complex services will require usage information
from elements beyond just the gateways (although call duration is only
reliably obtained from gateways, as people have observed). But, my
observation is that this is why billing mediation companies exist; to
collect information from multiple elements, and aggregate them together to
provide a coherent view of the service being offered.

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


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 02:59:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20170;
	Thu, 21 Jun 2001 02:59:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01117;
	Thu, 21 Jun 2001 02:46:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01084
	for ; Thu, 21 Jun 2001 02:46:41 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19193
	for ; Thu, 21 Jun 2001 02:46:05 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA12447;
	Thu, 21 Jun 2001 02:50:46 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 02:46:41 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'William Marshall'" , sip@ietf.org
Subject: RE: [Sip] SDP usage in RFC2543/100rel/bis-03/manyfolks
Date: Thu, 21 Jun 2001 02:46:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: William Marshall [mailto:wtm@research.att.com]
> Sent: Monday, June 18, 2001 2:47 PM
> To: sip@ietf.org
> Subject: [Sip] SDP usage in RFC2543/100rel/bis-03/manyfolks
> 
> 
> The restrictive wording in bis-03 on allowable placement of
> message bodies in SIP requests/responses seems to lead to a
> lot of compatibility problems with other current I-Ds.
> 
> RFC2543 allows all requests and responses to contain a body.
> 
> 100rel-03 specifically allows the PRACK request to contain a
> body (section 6.1), and allows reliable provisional responses
> to contain a body (section 6.2).

bis-03 doesn't rule this out. Where do you get the impression it does?

> 
> Manyfolks-resource-01 made use of these allowable combinations,
> to include the UAS SDP in the first reliable provisional response
> (typically a 183 if resource reservation is supported).
> 
> Unfortunately, bis-03 disallows this combination.

Hows that? It merely states that if the INVITE contained SDP, so MUST the
200, and not the ACK. Nothing in there about PRACK or 18x. Similarly, when
INVITE doesn't have SDP, it MUST be in 200, and MUST be in ACK. Doesn't rule
out anything else.

> If 2543bis-03 was likely to become a draft standard, all this
> might be worthwhile; but since it is more likely that 2543bis will
> be recycled as a proposed standard, it does not seem reasonable to
> require recycling all the extensions as well.  Especially since the
> text changes to 2543bis-03 are so minor.

The goal is not to break those specs, I assure you. 

> 
> Annex B.1, which describes the "offer-answer" model, contains the
> statement "The offer MAY be placed in an INVITE, in which case the
> answer MUST be in a 200 class response, and the ACK MUST NOT contain
> SDP."  Changing this to "... in which case the answer MUST be in
> a provisional or final response, ..."

Why? This would mean that you would be OK sending the answer in the
provisional, and NOT the final. I think that should be disallowed, and I
don't think any of the dcs drafts depend on that. The wording doesn't
prevent the 2xx from containing SDP, AND the 18x.


> The second problem with the same paragraph in Annex B.1, is that
> there is a case described in the manyfolks draft that requires two
> offers to be sent from the UAC.  Specifically, if the UAC requires
> a QoS "sendrecv" precondition,  but is only capable of ensuring "send"
> (i.e. it uses RSVP), and the UAS agrees to the precondition, but is
> capable of ensuring "sendrecv" itself, the UAS may respond with a 180
> Ringing instead of 183 Session Progress.  The procedures in manyfolks
> then allow (and possibly should require) the UAC to re-send the SDP
> with the preconditions asking for a confirmation that "sendrecv" has
> been obtained before starting the alerting -- otherwise the UAC does
> not really know whether the preconditions were understood or not.

You lost me here. I don't follow the send/sendrecv stuff, or what this has
to do with 180 vs. 183. Not also sure how one re-sends the SDP.

> 
> Both the dcs call flows (contained in draft-dcsgroup-sip-arch-04) and
> the 3gpp call flows (contained in draft-drage-3gpp-sip-establish-00)
> make further use of the secondary offer to perform negotiation of
> codec capabilities.  A second round of offer-answer is allowed by
> RFC2543,

Thats not clear at all. 

> but disallowed by 2543bis-03.  Some additional allowed
> combinations in B.1 could solve this problem as well.

I am trying to avoid the preponderance of a million ways of doing things,
which has plagued other standards that shall remain nameless. 

-Jonathan R.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 03:00:55 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20324;
	Thu, 21 Jun 2001 03:00:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01173;
	Thu, 21 Jun 2001 02:47:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01140
	for ; Thu, 21 Jun 2001 02:47:48 -0400 (EDT)
Received: from mailweb29.rediffmail.com (IDENT:qmailr@[203.199.83.149])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19266
	for ; Thu, 21 Jun 2001 02:47:12 -0400 (EDT)
Received: (qmail 28408 invoked by uid 510); 21 Jun 2001 06:49:47 -0000
Date: 21 Jun 2001 06:49:47 -0000
Message-ID: <20010621064947.28407.qmail@mailweb29.rediffmail.com>
Received: from unknown (203.197.251.9) by rediffmail.com via HTTP; 21 Jun 2001 06:49:47 -0000
MIME-Version: 1.0
To: "jdrosen@dynamicsoft.com" ,
        "Brian.Rosen@marconi.com" ,
        "kuthan@fokus.gmd.de" ,
        "sip@ietf.org" 
Subject:  Re: [SIP] Authentication and billing through proxy/re-direct serv er
From: "Ashhar Farhan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

jdrosen wrote -
>> I think people know my opinion on standardizing all the services on might offer... horrible idea. 
then you should oppose the very idea of sdp, and even sip.
- farhan@hotfoon.com



_____________________________________________________
Buy Lagaan & Yaadein music for 30% less.
Avail this special offer at http://shopping.rediff.com/shopping/music/offerrediffmailer.htm 




_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 03:18:44 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20833;
	Thu, 21 Jun 2001 03:18:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01974;
	Thu, 21 Jun 2001 03:05:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01944
	for ; Thu, 21 Jun 2001 03:05:16 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20669
	for ; Thu, 21 Jun 2001 03:04:40 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA12685;
	Thu, 21 Jun 2001 03:09:16 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 03:05:11 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'adam.roach@ericsson.com'" ,
        Jonathan Rosenberg ,
        "'Michael Thomas'"
	 
Cc: John.Hearty@level3.com, sip@ietf.org
Subject: RE: [SIP] Killing hung media streams
Date: Thu, 21 Jun 2001 03:05:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
> Sent: Monday, June 18, 2001 12:30 PM
> To: 'Jonathan Rosenberg'; 'Michael Thomas'
> Cc: John.Hearty@Level3.com; sip@ietf.org
> Subject: RE: [SIP] Killing hung media streams
> 
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg
> >
> > Here is a third thing one might do upon an ICMP error - send 
> > a BYE. I can
> > construct cases where you really, REALLY want this. 
> > Specifically, third
> > party call control. Consider the case of a controller in a 
> > call with A and
> > B. A dies. A stops sending media. B detects this. B 
> considers its call
> > terminated, but sends no messages. Now, A and B have 
> > destroyed call state,
> > but the controller is left hanging. The controller would 
> > prefer to get a BYE
> > in these cases. 
> 
> I'd argue that anyone implementing a 3pcc without using session-timer
> is just asking for buckets of trouble.
> 
> I still feel quite strongly that negotiating this behavior at call
> setup time adds too much complexity for the gain. If you always send
> out a re-INVITE upon media failure, the systems can be made to do the
> right thing.

Having thought about this some more, I am inclined to agree at this point.
If a re-INVITE is always sent, the far end can (1) accept it, potentially
re-establishing the session elsewhere if it can, or (2) reject with a 481,
which will cause the UAC to believe the call is down. Intermediaries (like a
3pcc controller) would see the 481 and also determine that the call is down.

So, this begs a related question, which Pauls email introduces. If we say
that a 481 to the INVITE means the call is down, does that mean the UAC
should issue a BYE, or just destroy the call state? Right now, bis-03 says
it should consider the call down, and does not mandate that a BYE should be
sent (since, in any case, it will also result in a 481). The advantage of
sending a BYE is for call-stateful boxes in the middle. It gives us the nice
property that a call is always terminated by a BYE, even if triggered as a
result of some other event in the SIP signaling path. This reduces the
number of cases that devices need to worry about.

So, I would propose that text be added to bis-03 which further mandates that
a BYE be sent upon receiving a 481 to a mid-call request. Any objections? 

Paul also wrote:
> But there are some issues with the re-INVITE that I don't understand:
> 
> If I believe the problem is with my end, and there is something
> I can change (e.g. in my SDP) that would help solve the problem,
> then of course I can offer that. 
> 
> But it seems like either I will believe the problem is with the 
> other end, or else I will have no idea where it is and have no 
> idea what kind of change might help. Suppose I have received ICMP
> errors on my sends, and suspect the port I am sending to, or the
> path to it, are down. When I send a reinvite, there is nothing
> obvious for me to change in *my* SDP - I want the other end to 
> offer me something that will work better. So perhaps I send 
> unchanged SDP. When the other end receives this, it may have no 
> idea that anything is wrong. How does it decide that it should do 
> anything other than send unchanged SDP back?

Well, its the job of the user at the other end to know that there is a
problem if one of its media streams has failed. How it knows this depends on
the device. In the case of a decomposed gateway, if the gateway fails,
presumably the MGC can detect this, and therefore do something about it when
the re-INVITE arrives.

The interesting case is when the failure in the media stream is not due to
either endpoint, but rather something in the network. In this case, a
re-INVITE won't help, as it will change nothing (both sides offer the same
SDP as before). In this case, you UA has to know to stop re-INVITing after a
while, if the re-INVITEs don't eventually solve the problem. I suspect this
will be a rare case, since if the media fails due to a network failure, the
signaling will probably fail as well.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 03:24:47 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20927;
	Thu, 21 Jun 2001 03:24:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02249;
	Thu, 21 Jun 2001 03:10:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02219
	for ; Thu, 21 Jun 2001 03:10:09 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20762
	for ; Thu, 21 Jun 2001 03:09:32 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA12765;
	Thu, 21 Jun 2001 03:14:06 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 03:10:01 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Christer Holmberg'" 
Cc: "'sip@ietf.org'" 
Subject: RE: [Sip] new open issue in session timer: NEEDS resolution now!
Date: Thu, 21 Jun 2001 03:09:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Monday, June 18, 2001 11:56 AM
> To: Jonathan Rosenberg
> Cc: 'sip@ietf.org'
> Subject: Re: [Sip] new open issue in session timer: NEEDS resolution
> now!
> 
> 
> 
> 
> Hi,
> 
> I think that the Minimum-Timer header could work.
> 
> However (forgive me if this issue has been raised and 
> discussed before),
> the UAC now does not know due to WHICH proxy the minimum value exists.
> Maybe that proxy didn't insert a Record-Route, so the re-INVITEs would
> never reach that proxy, so it doesn't matter what its minimum 
> value is.
> I guess this problem exists no matter if the Minimum-Timer header is
> used or not, though, since a proxy can always return 422 if 
> the received
> value is too small.

I don't understand the problem. Why does it matter which proxy was the one
that complained? Even if the one that complained is not on the route, so
what? The call will still succeed; perhaps with a larger timer than might
have been needed, but this is an oddball case we are talking about.

> 
> One option would be to add a rule in the spec, saying that a 
> proxy that
> does modify the Session-Expires header, OR sends 422, also MUST insert
> itself in the route. It may sound obvious, but I think it should be
> written somewhere (unless it isn't allready...).

Again, I don't understand the problem you are trying to fix.

-Jonathan R.

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


> 
> Comments?
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > Folks,
> > 
> > Whilst writing up a discussion of the smurf attack for the 
> session-timer
> > spec, I ran into a problem.
> > 
> > We added the ability for a proxy to reject a request if the 
> session timer
> > was too low. Consider the case of a UAC A, two proxies B 
> and C, and UAS D. A
> > sends an INVITE, with Supported: timer. It lists a value of 
> 1 hour. This
> > hits proxy B. B feels this is too long, and wants the 30 
> minute minimum. So,
> > it reduces it. That hits C. C feels this is too short, 
> below its 45 minute
> > minimum. So, it rejects the request, and includes a 
> session-expires header
> > with 45 minutes.
> > 
> > So, A resends the request, with a session-expires of 45 
> minutes. This, once
> > again, is too short for B, which reduces it to 30 minutes, 
> and passes it to
> > C. C rejects it because its too long, and includes a 
> session-expires header
> > with 45 minutes.
> > 
> > This will then continue ad-infinitum. Its also a nice DoS 
> attack in and of
> > itself.
> > 
> > Dean raised this issue a while back. I had suggested the 
> ability of a proxy
> > to increase the session-expires, and then include a header, say
> > Minimum-Timer, which indicates its minimum value that no 
> one else can reduce
> > it below. He pointed out that you have problems, then, if 
> two proxies have
> > non-overlapping preferences. Well, we still have that 
> problem. The result of
> > the 422 rejection response is that proxies can, 
> effectively, increase the
> > value of the session timer, so the same problem arises.
> > 
> > The only sensible out that I see is to add back this 
> Minimum-Timer header. A
> > UAC, when it gets a 422 Session Timer too small, remembers 
> the value of the
> > Session-Expires in that response. It stores the largest 
> value returned in
> > any 422 for the call leg in question. In any re-invites 
> with session timers,
> > the UAC includes a Minimum-Timer header with this value. A 
> proxy MUSTNOT
> > reduce the session timer below this value.
> > 
> > I welcome any other suggestions....
> > 
> > Another requirement for this to work is that, when a UA 
> refreshes, it
> > inserts a session-expres with the same timer as the 
> previous successful
> > re-INVITE, unless it explicitly wishes to disable session 
> timers. Without
> > that, the smurf attack is still possible! Thats because, if 
> each re-invite
> > doesn't contain the last session timer, no request will 
> actually ever
> > contain a session-expires, and so there is no opportunity 
> for a proxy in
> > front of the attacking proxy to reject the low values 
> inserted by the
> > attacking proxy!
> > 
> > -Jonathan R.
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> > 
> > 
> > _______________________________________________
> > Sip mailing list
> > Sip@ietf.org
> > http://www.ietf.org/mailman/listinfo/sip
> 

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 03:28:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20968;
	Thu, 21 Jun 2001 03:28:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02597;
	Thu, 21 Jun 2001 03:20:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02566
	for ; Thu, 21 Jun 2001 03:20:47 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20882
	for ; Thu, 21 Jun 2001 03:20:10 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA12912;
	Thu, 21 Jun 2001 03:24:46 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 03:20:41 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Christian Huitema'" ,
        Anders Kristensen
	 
Cc: Flemming Andreasen , sip@ietf.org
Subject: RE: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of bis3]]
Date: Thu, 21 Jun 2001 03:20:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> Sent: Thursday, June 14, 2001 11:17 AM
> To: Anders Kristensen
> Cc: Flemming Andreasen; sip@ietf.org; Jonathan Rosenberg
> Subject: RE: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of
> bis3]]
> 
> 
> Yes. In fact, we could make a session explaining that SDP was 
> originally
> defined for an entirely different purpose, that it is currently being
> revised, and that a bunch of fields defined in SDP shall be considered
> optional when used with SIP. I bet that this includes essentially all
> the fields that are not directly related to specifying 
> addresses, ports
> and coding parameters, plus the version field that we use in
> "re-invite."

Well, I'm trying to avoid the case where we have two separate SDP specs -
one for SAP, and one for SIP. Thus, I want the usage of SDP within SIP to be
completely compliant to the specification we have available, which is
rfc2327. I think we can agree that although the BNF doesn't require it, the
text is clear that rfc2327 mandates either e or p lines.

I AM willing, however, to mandate that people be willing to accept SDP
without these. Thus, the text would basically say that either e or p should
be present, as mandated by rfc2327, but because it serves little value in
sip, and is often ignored in practice, you MUST be prepared to process SDP
without it.

Maybe the difference is really academic, but I don't want to mandate that
people construct SDP in violation of the spec. I'd rather mandate that they
accept SDP that violates the spec.

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


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 03:29:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20984;
	Thu, 21 Jun 2001 03:29:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02421;
	Thu, 21 Jun 2001 03:15:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02392
	for ; Thu, 21 Jun 2001 03:15:24 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20805
	for ; Thu, 21 Jun 2001 03:14:48 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA12833;
	Thu, 21 Jun 2001 03:19:26 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 03:15:21 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Henning G. Schulzrinne'" 
Cc: "'Dean Willis'" ,
        Romel Khan
	 , sip@ietf.org
Subject: RE: [Sip] II digit & Calling Name
Date: Thu, 21 Jun 2001 03:15:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Saturday, June 16, 2001 10:19 AM
> To: Jonathan Rosenberg
> Cc: 'Dean Willis'; Romel Khan; sip@ietf.org
> Subject: Re: [Sip] II digit & Calling Name
> 
> > 
> > One might also argue that, if you want to allow the network 
> to provide and
> > validate a user identity, then you might want the network 
> to provide and
> > validate a device identity (i.e., the Contact). This would 
> argue for the
> > equivalent of remote-party-id for Contact. To be honest, I 
> never understood
> > why we didn't have the header called Auth-From, and now we 
> might want to
> > think about Auth-Contact.....
> > 
> 
> It seems pretty clear that the privacy draft makes rather traditional
> assumptions about the network architecture, for example, that 
> the entity
> doing the identity checking is implied and requires no identification.
> However, without cryptographic authentication of the 
> verifier, it's not
> clear how useful this whole scheme is outside tightly constrained
> network architectures and rather old-fashioned trust relationships.

I agree that having cryptographic identification of the verifier is a good
thing, as there will definitely be cases where there is not a transitivity
of trust. My point is that the verification can be done for two things - to
verify the user, and to verify the device. In that case, one might imagine
both a Auth-From and Auth-Contact header (same idea as Remote-Party-ID, but
renamed to indicate which information is being provided), both of which
would need to have cryptographic authentication of the verifier.

-Jonathan R.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 03:45:24 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21192;
	Thu, 21 Jun 2001 03:45:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03272;
	Thu, 21 Jun 2001 03:37:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03245
	for ; Thu, 21 Jun 2001 03:37:43 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21112
	for ; Thu, 21 Jun 2001 03:37:07 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA13060;
	Thu, 21 Jun 2001 03:41:27 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 03:37:22 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Deepika Giri'" 
Cc: "'sip@ietf.org'" 
Subject: RE: [SIP] Re-invites in a multi-party call
Date: Thu, 21 Jun 2001 03:37:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Deepika Giri [mailto:deepika@mascon.co.in]
> Sent: Wednesday, June 13, 2001 8:27 AM
> To: Jonathan Rosenberg
> Cc: sip@lists.bell-labs.com
> Subject: RE: [SIP] Re-invites in a multi-party call
> 
> 
> My conferencing model centralized in nature, where the conference
> server/bridge does the mixing.  The usr A is not aware that 
> he's connected
> to the bridge, only the Conference Control application does 
> the bridging of
> all the users to the CB, this is using 3pcc.
> 
> As far as A is concerned, he knows that he is in conference 
> with B and C,
> so, he can put them on hold by sending them messages 
> individually. right? or
> can he send a single hold message that will put both of the 
> users on hold?
> how does a standard SIP phone do this?

Adam responded:
> Not with the architecture you just described. As far as user A's
> equipment is concerned, he is communicating with exactly one
> party: the conference bridge. He will hold the conference bridge.

That is correct. To add to that, it doesn't even make sense. If A sends a
hold to C, so that C stops sending media to the mixer, then B will not hear
A. That doesn't make sense.

Perhaps what you want is that A gets to decide that it doesn't want to hear
C anymore, but that B should still continue to hear C. To do this, you need
a conference control protocol in order to set the mixing matrix used by the
bridge. There is not yet a standardized protocol, but I would note that
using a web interface to control this can get you a very long way.

> 
> what if there is a situation where there is one more user D in the
> conference(brought in by C, whose presence A is not aware of? 
>  He cannot
> send a hold message to D, he doesn't even know he exists, 
> unless the list of
> participants in the conference is constantly given to each of 
> the users.

No, there is a direct SIP signaling relationship between each user an the
bridge. There are no other SIP relationships.

-Jonathan R.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 04:34:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21697;
	Thu, 21 Jun 2001 04:34:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04660;
	Thu, 21 Jun 2001 04:25:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04631
	for ; Thu, 21 Jun 2001 04:25:13 -0400 (EDT)
Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21569
	for ; Thu, 21 Jun 2001 04:24:35 -0400 (EDT)
Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca
          via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 21 Jun 2001 09:25:00 UT
Received: (private information removed)
Message-ID: <3B31A4C6.79AFAF86@ubiquity.net>
From: James Undery 
To: Jonathan Rosenberg 
Cc: aki.niemi@nokia.com, corey@hearme.com, sip@ietf.org
Subject: Re: [Sip] Request header integrity in HTTP Digest
Date: Thu, 21 Jun 2001 03:39:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: James Undery [mailto:jundery@ubiquity.net]
> > Sent: Tuesday, June 19, 2001 7:56 AM
> > To: aki.niemi@nokia.com
> > Cc: corey@hearme.com; jdrosen@dynamicsoft.com; sip@ietf.org
> > Subject: Re: [Sip] Request header integrity in HTTP Digest
> >
> > > I think this would also make sense for pnonce, since otherwise all
> > > information contained in the hash can readily be found from
> > the message
> > > itself.
> >
> > True although is only a suggestion for nonce generation, and digest
> > authentication is quite weak.  The real problem with this
> > draft is it is
> > just plain broken.
>
> The only thing thats broken is your perception of the problem being
solved.

That's exactly what I was getting at this approach will never solve the
problems
it claims to.

> Your gripe is with the authors of rfc2617, not me. Please feel free to
send
> them a note saying that rfc2617 is "just plain broken". They may be
> offended, but they will probably have to agree with you that the problem
you
> describe exists. The problem is not a problem with this draft, its a
problem
> with digest, and is not fixed by this draft. Digest provides weak
security,
> no doubt. The right way to ultimately fix it is to have a nice, fully
scoped
> out, shared secret and/or public key encryption/authentication mechanism.
> But, we don't have that right now.
>

HTTP is totally different from SIP I have no problem at all with that draft
Section 4 is very clear about the limitations of the draft.

>
> The mechanism described in the draft provides a level of security that is
> better than digest. It fixes some of the most horrible and easiest to
launch
> attacks (especially the replay ones).

UA sends a "Contact: *",  "Expires: 0" REGISTER request and authenticates
it.
Bad guy sniffs the authenticated register
UA then sends the new contacts for the user.
Bad guy then replays the first message with an incremented CSeq quickly.

Common scenario, simple attack how does you draft help?

> It doesn't fix all of them, including
> the MITM attack you describe. However, the cost for this fix is *zero*,
> since it requires no changes in the specs or client behaviors. It is an
> implementation choice for the server, and the decision to use it can be
made
> independently for each transaction in each server, without impacting any
> other devices. The only reason why it even needs to be discussed at all is
> that it is best served by a one-liner in the SIP spec that says you
> shouldn't generally change the SIP message between the initial request and
> the new request with credentials. Not that anyone actually does change the
> headers that are being protected, as far as I know, but its nice to just
say
> it.

The whole point is to better secure digest authentication the UA needs to
include important headers and the server supplied nonce hashed in the
credentials, so the UA knows exactly what it is authenticating. This still
leaves all the problems of digest authentication but puts SIP on a similar
level
to HTTP.

> So, to be clear, I am not proposing that this is the be-all and end-all of
> security. It is, IMHO, a very elegant and simple fix that improves the
> performance of digest significantly beyond where it is now.

I think if worsens it as Corey pointed out (and I totally missed even when
he
did). IMHO it is a simple fix to very little, although an important area for
the
WG to investigate, and as I've said before I think a new type of
authentication
based on HTTP digest authentication but tailored for SIP is important.

James Undery


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 04:56:30 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21916;
	Thu, 21 Jun 2001 04:56:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05557;
	Thu, 21 Jun 2001 04:43:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05465
	for ; Thu, 21 Jun 2001 04:43:46 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21836
	for ; Thu, 21 Jun 2001 04:43:09 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5L8hiN02593;
	Thu, 21 Jun 2001 10:43:45 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.7])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5L8hi529488;
	Thu, 21 Jun 2001 11:43:44 +0300 (EET DST)
Message-ID: <3B31B3B8.9CBB9F7B@lmf.ericsson.se>
Date: Thu, 21 Jun 2001 11:43:36 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'sip@ietf.org'" 
Subject: Re: [Sip] new open issue in session timer: NEEDS resolution now!
References: 
Content-Type: multipart/mixed;
 boundary="------------87A737556327968E2F27C373"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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


Hi,

The issue is not about which proxy is complaining, but that a proxy that
will not be in the call path may affect the session-timer value in a
negative way. 

For example, it may decrease the value, which the next server (proxy or
UA), which WILL be in the call path, does not except, so it will send
422. The UAC will not have to send a new request, even if the original
value given in the first request would have been accepted by all parties
that will be in the call path, but the "non path" proxy decreased it.

I don't see this as a big problem, but as a bad situation that MAY
occure, so that's why I was wondering if it at least in the draft could
be RECOMMENDED that proxis that do not insert Record-Route will not care
about the session-timer value.

Regards,

Christer Holmberg
Ericsson Finland





Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> > Sent: Monday, June 18, 2001 11:56 AM
> > To: Jonathan Rosenberg
> > Cc: 'sip@ietf.org'
> > Subject: Re: [Sip] new open issue in session timer: NEEDS resolution
> > now!
> >
> >
> >
> >
> > Hi,
> >
> > I think that the Minimum-Timer header could work.
> >
> > However (forgive me if this issue has been raised and
> > discussed before),
> > the UAC now does not know due to WHICH proxy the minimum value exists.
> > Maybe that proxy didn't insert a Record-Route, so the re-INVITEs would
> > never reach that proxy, so it doesn't matter what its minimum
> > value is.
> > I guess this problem exists no matter if the Minimum-Timer header is
> > used or not, though, since a proxy can always return 422 if
> > the received
> > value is too small.
> 
> I don't understand the problem. Why does it matter which proxy was the one
> that complained? Even if the one that complained is not on the route, so
> what? The call will still succeed; perhaps with a larger timer than might
> have been needed, but this is an oddball case we are talking about.
> 
> >
> > One option would be to add a rule in the spec, saying that a
> > proxy that
> > does modify the Session-Expires header, OR sends 422, also MUST insert
> > itself in the route. It may sound obvious, but I think it should be
> > written somewhere (unless it isn't allready...).
> 
> Again, I don't understand the problem you are trying to fix.
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> >
> > Comments?
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> >
> >
> > Jonathan Rosenberg wrote:
> > >
> > > Folks,
> > >
> > > Whilst writing up a discussion of the smurf attack for the
> > session-timer
> > > spec, I ran into a problem.
> > >
> > > We added the ability for a proxy to reject a request if the
> > session timer
> > > was too low. Consider the case of a UAC A, two proxies B
> > and C, and UAS D. A
> > > sends an INVITE, with Supported: timer. It lists a value of
> > 1 hour. This
> > > hits proxy B. B feels this is too long, and wants the 30
> > minute minimum. So,
> > > it reduces it. That hits C. C feels this is too short,
> > below its 45 minute
> > > minimum. So, it rejects the request, and includes a
> > session-expires header
> > > with 45 minutes.
> > >
> > > So, A resends the request, with a session-expires of 45
> > minutes. This, once
> > > again, is too short for B, which reduces it to 30 minutes,
> > and passes it to
> > > C. C rejects it because its too long, and includes a
> > session-expires header
> > > with 45 minutes.
> > >
> > > This will then continue ad-infinitum. Its also a nice DoS
> > attack in and of
> > > itself.
> > >
> > > Dean raised this issue a while back. I had suggested the
> > ability of a proxy
> > > to increase the session-expires, and then include a header, say
> > > Minimum-Timer, which indicates its minimum value that no
> > one else can reduce
> > > it below. He pointed out that you have problems, then, if
> > two proxies have
> > > non-overlapping preferences. Well, we still have that
> > problem. The result of
> > > the 422 rejection response is that proxies can,
> > effectively, increase the
> > > value of the session timer, so the same problem arises.
> > >
> > > The only sensible out that I see is to add back this
> > Minimum-Timer header. A
> > > UAC, when it gets a 422 Session Timer too small, remembers
> > the value of the
> > > Session-Expires in that response. It stores the largest
> > value returned in
> > > any 422 for the call leg in question. In any re-invites
> > with session timers,
> > > the UAC includes a Minimum-Timer header with this value. A
> > proxy MUSTNOT
> > > reduce the session timer below this value.
> > >
> > > I welcome any other suggestions....
> > >
> > > Another requirement for this to work is that, when a UA
> > refreshes, it
> > > inserts a session-expres with the same timer as the
> > previous successful
> > > re-INVITE, unless it explicitly wishes to disable session
> > timers. Without
> > > that, the smurf attack is still possible! Thats because, if
> > each re-invite
> > > doesn't contain the last session timer, no request will
> > actually ever
> > > contain a session-expires, and so there is no opportunity
> > for a proxy in
> > > front of the attacking proxy to reject the low values
> > inserted by the
> > > attacking proxy!
> > >
> > > -Jonathan R.
> > > ---
> > > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > > Chief Scientist                             First Floor
> > > dynamicsoft                                 East Hanover, NJ 07936
> > > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > > http://www.dynamicsoft.com
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list
> > > Sip@ietf.org
> > > http://www.ietf.org/mailman/listinfo/sip
> >
--------------87A737556327968E2F27C373
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------87A737556327968E2F27C373--


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jun 21 05:30:34 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22308
	for ; Thu, 21 Jun 2001 05:30:33 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9359B4437B; Thu, 21 Jun 2001 05:31:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18])
	by lists.bell-labs.com (Postfix) with ESMTP id EF6D644374
	for ; Thu, 21 Jun 2001 05:30:14 -0400 (EDT)
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA09122
	for ; Thu, 21 Jun 2001 11:30:12 +0200 (MET DST)
Received: from mchh159e.mch.pn.siemens.de ([139.21.130.171])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA25766
	for ; Thu, 21 Jun 2001 11:30:13 +0200 (MET DST)
Received: by mchh159e.mch.pn.siemens.de with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 11:30:13 +0200
Message-ID: <45DE2268C874D21198880001FA7E416CAA335A@mchh155e.mch.pn.siemens.de>
From: Klaghofer Karl ICN EN HC ID 71 
To: sip@lists.bell-labs.com
Subject: AW: [SIP] draft-mahy-sip-message-waiting-01.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FA34.C3CB0700"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 21 Jun 2001 11:30:09 +0200

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FA34.C3CB0700
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

There is no need to tell the endpoint HOW the message waiting =
notification
is to be presented at the user inferface (visual, audible). Actually, =
it
does not make sense to signal this explicitly since the messaging =
server may
not know the user interface capabilities of the endpoint (PC Client , =
IP
Phone, etc.). =20
However, the important part is that one can signal to an endpoint that =
there
is a message waiting in general at a certain destination (e.g. on a
messaging server).=20
This message waiting notification may include parameters like service =
type
(voice, video,...), number of messages waiting, address of the endpoint
server to call to retrieve the message, identification of the user that =
left
the message, etc.
=20
A different question: Can anyone please tell me the expected proceeding =
with
this message waiting indication draft. I saw that it will expire soon =
(in
July). Will it become an official SIP WG work item ? Is the plan to =
make an
RFC out of it ?
=20
Thanks,
Karl
------------------------------------
Karl Klaghofer
Siemens AG
  karl.klaghofer@icn.siemens.de

-----Urspr=FCngliche Nachricht-----
Von: Gordon Ledgard [mailto:gledgard@iperia.com]
Gesendet: Mittwoch, 20. Juni 2001 20:37
An: 'Dean Bogdanovic'; 'Wai Wu'; 'Jay Batson'; Venkatesh =
Venkataramanan;
'Jean-Francois Mule'; 'Rohan Mahy'; islain@cisco.com;
sip@lists.bell-labs.com
Betreff: RE: [SIP] draft-mahy-sip-message-waiting-01.txt


Agree.
=20
There isn't anything inherently un-SIP like about providing some set of
common network
or user notification features.  The danger, as Venkatesh points out, is
making them application
specific, like jumping to the conclusion that I want to turn on a =
light, or
dictating how that
notification is to be interpreted by the recieving endpoint.
=20

-----Original Message-----
From: Dean Bogdanovic [mailto:deanb@mck.com]
Sent: Wednesday, June 20, 2001 1:52 PM
To: 'Wai Wu'; 'Jay Batson'; Venkatesh Venkataramanan; 'Jean-Francois =
Mule';
'Rohan Mahy'; islain@cisco.com; sip@lists.bell-labs.com
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt


Wai
I would disagree with you. Audio/visual notifications are important to =
end
user and I belive giving some extensions to SIP will help the adoption =
by
the endusers. As Jay had mentioned it
=20

Regards=20

Dean Bogdanovic=20
MCK Communications=20
phone:(617)454 6165=20
fax:(617)454 6101=20
___________________=20
"the answer is 42"=20


-----Original Message-----
From: Wai Wu [mailto:wwu@calltrol.com]
Sent: Wednesday, June 20, 2001 10:40 AM
To: 'Jay Batson'; Venkatesh Venkataramanan; 'Jean-Francois Mule'; =
'Rohan
Mahy'; islain@cisco.com; sip@lists.bell-labs.com
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt


I think features normally found on a PBX phone (e.g. message waiting)
shouldn't be part of SIP at all. If we put all these things in SIP, it =
will
make SIP not much different from a "standardized PBX protocol".=20

-----Original Message-----
From: Jay Batson [mailto:jbatson@pingtel.com]
Sent: Tuesday, June 19, 2001 3:37 PM
To: Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan Mahy';
islain@cisco.com; sip@lists.bell-labs.com
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt


My comments aren't timely, so my apologies.

Venkatesh's comments are also consistent with typical IETF protocol /
application design.  Example:  Neither SMTP nor POP/IMAP specify how =
the
email "user agent" (Eudora, Netscape, Outlook) provides visual =
indication of
email message priority (X-Priority).

The creator of a given user agent defines its own user interfaces to
information that is provided in the standardized lower later protocol.  =
End
users then choose among available user agents (and behaviors) to get =
their
desired interaction.

Applications at either end of a transaction may want to agree on
Experimental extensions to show more information, such as the type that
Jean-Francois suggests.  In fact, this is how X-Priority came into =
being in
email!  Eudora just up and did it one day, and everybody else did what =
they
did!

-jb


At 03:29 PM 4/26/01, Venkatesh Venkataramanan wrote:


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

Venkatesh

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


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

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


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

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




------_=_NextPart_001_01C0FA34.C3CB0700
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









There=20
is no need to tell the endpoint HOW the message waiting =
notification is to=20
be presented at the user inferface (visual, audible). Actually, =
it does not=20
make sense to signal this explicitly since the messaging server may not =
know the=20
user interface capabilities of the endpoint (PC Client , IP Phone, =
etc.). =20



However, the important part is that one can =
signal to=20
an endpoint that there is a message waiting in general at a certain =
destination=20
(e.g. on a messaging server). 


This=20
message waiting notification may include parameters like =
service type=20
(voice, video,...), number of messages waiting, address of the =
endpoint=20
server to call to retrieve the message, identification of the user =
that=20
left the message, etc.


 


A=20
different question: Can anyone please tell me the expected proceeding =
with this=20
message waiting indication draft. I saw that it will expire soon (in =
July). Will=20
it become an official SIP WG work item ? Is the plan to make an RFC out =
of it=20
?


 


Thanks,


Karl


------------------------------------


Karl Klaghofer


Siemens AG


karl.klaghofer@icn.sie=
mens.de



  
-----Urspr=FCngliche Nachricht-----
Von: Gordon =
Ledgard=20
  [mailto:gledgard@iperia.com]
Gesendet: Mittwoch, 20. Juni =
2001=20
  20:37
An: 'Dean Bogdanovic'; 'Wai Wu'; 'Jay Batson'; =
Venkatesh=20
  Venkataramanan; 'Jean-Francois Mule'; 'Rohan Mahy'; islain@cisco.com; =

  sip@lists.bell-labs.com
Betreff: RE: [SIP]=20
  draft-mahy-sip-message-waiting-01.txt


  
Agree.

  
 

  
There isn't anything inherently un-SIP like about providing =
some set of=20
  common network

  
or=20
  user notification features.  The danger, as =
Venkatesh=20
  points out, is making them application

  
specific, like jumping to the conclusion that I want to turn =
on a=20
  light, or dictating how that

  
notification is to be interpreted by the =
recieving=20
  endpoint.

  
 

  

    
-----Original Message-----
From: Dean Bogdanovic =

    [mailto:deanb@mck.com]
Sent: Wednesday, June 20, 2001 =
1:52=20
    PM
To: 'Wai Wu'; 'Jay Batson'; Venkatesh Venkataramanan;=20
    'Jean-Francois Mule'; 'Rohan Mahy'; islain@cisco.com;=20
    sip@lists.bell-labs.com
Subject: RE: [SIP]=20
    draft-mahy-sip-message-waiting-01.txt


    
Wai

    
I=20
    would disagree with you. Audio/visual notifications are important =
to end=20
    user and I belive giving some extensions to SIP will help the =
adoption by=20
    the endusers. As Jay had mentioned it

    
 

    
Regards 

    
Dean Bogdanovic =

MCK Communications 
phone:(617)454 6165 
fax:(617)454=20
    6101 
___________________ 
"the answer is 42" 


    
      
-----Original Message-----
From: Wai Wu=20
      [mailto:wwu@calltrol.com]
Sent: Wednesday, June 20, =
2001 10:40=20
      AM
To: 'Jay Batson'; Venkatesh Venkataramanan; =
'Jean-Francois=20
      Mule'; 'Rohan Mahy'; islain@cisco.com;=20
      sip@lists.bell-labs.com
Subject: RE: [SIP]=20
      draft-mahy-sip-message-waiting-01.txt


      
I think features normally found on a =
PBX phone=20
      (e.g. message waiting) shouldn't be part of SIP at all. If we put =
all=20
      these things in SIP, it will make SIP not much different from a=20
      "standardized PBX protocol". 

      

        
-----Original Message-----
From: Jay Batson=20
        [mailto:jbatson@pingtel.com]
Sent: Tuesday, June 19, =
2001 3:37=20
        PM
To: Venkatesh Venkataramanan; 'Jean-Francois =
Mule'; 'Rohan=20
        Mahy'; islain@cisco.com; =
sip@lists.bell-labs.com
Subject: RE:=20
        [SIP] =
draft-mahy-sip-message-waiting-01.txt

My=20
        comments aren't timely, so my apologies.

Venkatesh's =
comments are=20
        also consistent with typical IETF protocol / application =
design. =20
        Example:  Neither SMTP nor POP/IMAP specify how the email =
"user=20
        agent" (Eudora, Netscape, Outlook) provides visual indication =
of email=20
        message priority (X-Priority).

The creator of a given =
user agent=20
        defines its own user interfaces to information that is provided =
in the=20
        standardized lower later protocol.  End users then choose =
among=20
        available user agents (and behaviors) to get their desired=20
        interaction.

Applications at either end of a transaction =
may want=20
        to agree on Experimental extensions to show more information, =
such as=20
        the type that Jean-Francois suggests.  In fact, this is =
how=20
        X-Priority came into being in email!  Eudora just up and =
did it one=20
        day, and everybody else did what they =
did!

-jb


At=20
        03:29 PM 4/26/01, Venkatesh Venkataramanan wrote:

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

Venkatesh

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


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

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


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

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

=


------_=_NextPart_001_01C0FA34.C3CB0700--

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


From sip-admin@ietf.org  Thu Jun 21 05:46:05 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22511;
	Thu, 21 Jun 2001 05:46:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07224;
	Thu, 21 Jun 2001 05:31:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA07193
	for ; Thu, 21 Jun 2001 05:31:46 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22343
	for ; Thu, 21 Jun 2001 05:31:08 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5L9VhN21522;
	Thu, 21 Jun 2001 11:31:43 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.7])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5L9Vh501495;
	Thu, 21 Jun 2001 12:31:43 +0300 (EET DST)
Message-ID: <3B31BEF7.809E84C5@lmf.ericsson.se>
Date: Thu, 21 Jun 2001 12:31:35 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "'sip@ietf.org'" 
CC: Jonathan Rosenberg 
Subject: Re: [Sip] new open issue in session timer: NEEDS resolution now!
References:  <3B31B3B8.9CBB9F7B@lmf.ericsson.se>
Content-Type: multipart/mixed;
 boundary="------------EB614599A5B6C9B6FC35032C"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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


Hi,

Just a small correction to my previous mail.

In the second chapter it should be "The UAC will have to send a new
request", instead of "The UAC will not have to send a new request".

Regards,

Christer Holmberg
Ericsson Finland



Christer Holmberg wrote:
> 
> Hi,
> 
> The issue is not about which proxy is complaining, but that a proxy that
> will not be in the call path may affect the session-timer value in a
> negative way.
> 
> For example, it may decrease the value, which the next server (proxy or
> UA), which WILL be in the call path, does not except, so it will send
> 422. The UAC will not have to send a new request, even if the original
> value given in the first request would have been accepted by all parties
> that will be in the call path, but the "non path" proxy decreased it.
> 
> I don't see this as a big problem, but as a bad situation that MAY
> occure, so that's why I was wondering if it at least in the draft could
> be RECOMMENDED that proxis that do not insert Record-Route will not care
> about the session-timer value.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> Jonathan Rosenberg wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> > > Sent: Monday, June 18, 2001 11:56 AM
> > > To: Jonathan Rosenberg
> > > Cc: 'sip@ietf.org'
> > > Subject: Re: [Sip] new open issue in session timer: NEEDS resolution
> > > now!
> > >
> > >
> > >
> > >
> > > Hi,
> > >
> > > I think that the Minimum-Timer header could work.
> > >
> > > However (forgive me if this issue has been raised and
> > > discussed before),
> > > the UAC now does not know due to WHICH proxy the minimum value exists.
> > > Maybe that proxy didn't insert a Record-Route, so the re-INVITEs would
> > > never reach that proxy, so it doesn't matter what its minimum
> > > value is.
> > > I guess this problem exists no matter if the Minimum-Timer header is
> > > used or not, though, since a proxy can always return 422 if
> > > the received
> > > value is too small.
> >
> > I don't understand the problem. Why does it matter which proxy was the one
> > that complained? Even if the one that complained is not on the route, so
> > what? The call will still succeed; perhaps with a larger timer than might
> > have been needed, but this is an oddball case we are talking about.
> >
> > >
> > > One option would be to add a rule in the spec, saying that a
> > > proxy that
> > > does modify the Session-Expires header, OR sends 422, also MUST insert
> > > itself in the route. It may sound obvious, but I think it should be
> > > written somewhere (unless it isn't allready...).
> >
> > Again, I don't understand the problem you are trying to fix.
> >
> > -Jonathan R.
> >
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > >
> > > Comments?
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > >
> > >
> > > Jonathan Rosenberg wrote:
> > > >
> > > > Folks,
> > > >
> > > > Whilst writing up a discussion of the smurf attack for the
> > > session-timer
> > > > spec, I ran into a problem.
> > > >
> > > > We added the ability for a proxy to reject a request if the
> > > session timer
> > > > was too low. Consider the case of a UAC A, two proxies B
> > > and C, and UAS D. A
> > > > sends an INVITE, with Supported: timer. It lists a value of
> > > 1 hour. This
> > > > hits proxy B. B feels this is too long, and wants the 30
> > > minute minimum. So,
> > > > it reduces it. That hits C. C feels this is too short,
> > > below its 45 minute
> > > > minimum. So, it rejects the request, and includes a
> > > session-expires header
> > > > with 45 minutes.
> > > >
> > > > So, A resends the request, with a session-expires of 45
> > > minutes. This, once
> > > > again, is too short for B, which reduces it to 30 minutes,
> > > and passes it to
> > > > C. C rejects it because its too long, and includes a
> > > session-expires header
> > > > with 45 minutes.
> > > >
> > > > This will then continue ad-infinitum. Its also a nice DoS
> > > attack in and of
> > > > itself.
> > > >
> > > > Dean raised this issue a while back. I had suggested the
> > > ability of a proxy
> > > > to increase the session-expires, and then include a header, say
> > > > Minimum-Timer, which indicates its minimum value that no
> > > one else can reduce
> > > > it below. He pointed out that you have problems, then, if
> > > two proxies have
> > > > non-overlapping preferences. Well, we still have that
> > > problem. The result of
> > > > the 422 rejection response is that proxies can,
> > > effectively, increase the
> > > > value of the session timer, so the same problem arises.
> > > >
> > > > The only sensible out that I see is to add back this
> > > Minimum-Timer header. A
> > > > UAC, when it gets a 422 Session Timer too small, remembers
> > > the value of the
> > > > Session-Expires in that response. It stores the largest
> > > value returned in
> > > > any 422 for the call leg in question. In any re-invites
> > > with session timers,
> > > > the UAC includes a Minimum-Timer header with this value. A
> > > proxy MUSTNOT
> > > > reduce the session timer below this value.
> > > >
> > > > I welcome any other suggestions....
> > > >
> > > > Another requirement for this to work is that, when a UA
> > > refreshes, it
> > > > inserts a session-expres with the same timer as the
> > > previous successful
> > > > re-INVITE, unless it explicitly wishes to disable session
> > > timers. Without
> > > > that, the smurf attack is still possible! Thats because, if
> > > each re-invite
> > > > doesn't contain the last session timer, no request will
> > > actually ever
> > > > contain a session-expires, and so there is no opportunity
> > > for a proxy in
> > > > front of the attacking proxy to reject the low values
> > > inserted by the
> > > > attacking proxy!
> > > >
> > > > -Jonathan R.
> > > > ---
> > > > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > > > Chief Scientist                             First Floor
> > > > dynamicsoft                                 East Hanover, NJ 07936
> > > > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > > > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > > > http://www.dynamicsoft.com
> > > >
> > > >
> > > > _______________________________________________
> > > > Sip mailing list
> > > > Sip@ietf.org
> > > > http://www.ietf.org/mailman/listinfo/sip
> > >
--------------EB614599A5B6C9B6FC35032C
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------EB614599A5B6C9B6FC35032C--


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 07:19:52 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23520;
	Thu, 21 Jun 2001 07:19:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09845;
	Thu, 21 Jun 2001 07:00:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09814
	for ; Thu, 21 Jun 2001 07:00:43 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23218;
	Thu, 21 Jun 2001 07:00:06 -0400 (EDT)
Message-Id: <200106211100.HAA23218@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 21 Jun 2001 07:00:05 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-mib-03.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

--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		: Management Information Base for Session Initiation 
                          Protocol
	Author(s)	: K. Lingle, J. Maeng, J. Mule, D. Walker
	Filename	: draft-ietf-sip-mib-03.txt
	Pages		: 85
	Date		: 20-Jun-01
	
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes a set of managed objects that are used
to manage Session Initiation Protocol(SIP) [17] devices, which
include User Agent, Proxy server, Redirect server and Registrar.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-mib-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-mib-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-mib-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:	<20010620132333.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-mib-03.txt

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

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

--OtherAccess--

--NextPart--



_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jun 21 09:33:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28104
	for ; Thu, 21 Jun 2001 09:33:38 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 23DB144374; Thu, 21 Jun 2001 09:34:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exch-nyc1.deltathree.com (unknown [213.137.71.26])
	by lists.bell-labs.com (Postfix) with ESMTP id 930E04433E
	for ; Thu, 21 Jun 2001 09:33:13 -0400 (EDT)
Received: from exch-jlm2.deltathree.com (n171-19.deltathree.com [208.170.171.19]) by exch-nyc1.deltathree.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id NJQY7CVH; Thu, 21 Jun 2001 09:32:00 -0400
Received: by exch-jlm2.deltathree.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 21 Jun 2001 16:29:54 +0300
Message-ID: 
From: David Schwartz 
To: "'Jiri Kuthan'" ,
        "'Rosen, Brian'" ,
        "'Jay Batson'" ,
        "'Ashhar Farhan'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct  ser
	v er
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 21 Jun 2001 16:29:49 +0300

I have not been in on this entire thread so excuse me if I say things that
have been said but I would like to throw in my 2 cents.

It is important to distiguish between the 3 "A's" as well as the CDR
creation process. To often we say that AAA/CDR should be here or there as if
it is one big object when in reality it does not have to be. In other words
there are things that probably should be in the gateway while there are
others that cannot. One such thing is A1 or Authentication.

I for one would not want anyone getting to my gateway (even to be rejected)
who is not authenticated. By authentication I mean "Who are you" and not "Do
you have enough money to make this call". So instead I put up an
authenticating proxy at the border of my network to filter out those that I
shouldn't be speaking with. 

Next we look at call start (A2 and A3) and call stop (CDR creation)
requests.

Here to it is important to look at the pros and cons in doing this in an
internal proxy Vs. using the gateway. The big con in using the proxy is that
it causes another statefull element in the network and since the VG must be
statefull anyway why have another statefull element. In addition when it
comes to the call stop (CDR creation) there is some information that might
be needed about the user (e.g. internal username) that may only be available
from the call start response. So the typical solution is to use the VG. The
con with using the VG is that you must own the VG. If you wish to terminate
on someone elses network it can be tricky retrieving the CDR's. 

One possible stateless solution might be to use the proxy for call start and
call stop. The Record-Route header is used to ensure that the proxy sees the
BYE message. Any proxy that gets an invite generates a call start (on
receiving the 200 OK) which writes to some file that a particular callID has
started a call at this particular time, and any proxy getting a BYE
generates a call stop which writes to a file (potentialy on a different
machine) that a particular callID has stopped a call at a different time.
There is no state that needs to be saved. Instead, a different process
constantly moniters these files and correlates the call starts with the call
stops. This seperate process is the one that generates the CDR's. This also
reduces the load on the VG's enabling them to focus on the call setup and
teardown.

One issue with this approach is what if the proxy that added the
Record-Route falls down the message has routing problems. This problem can
be solved in many ways and is out of the scope of this discussion.

David Schwartz

-----Original Message-----
From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jiri Kuthan
Sent: Wed, June 20, 2001 8:33 PM
To: Rosen, Brian; 'Jay Batson'; Ashhar Farhan; sip@lists.bell-labs.com
Subject: RE: [SIP] Authentication and billing through proxy/re-direct
serv er


At 03:01 PM 6/20/2001, Rosen, Brian wrote:
[...]
>I myself am not wild about UAs doing CDR generation.  I think proxy servers

>can do that.  The piece of information the PS doesn't have is the exact
connection
>time information.  

My opinion on network configuration is that CDR/AAA functionality 
is best hooked to the same place where the particular AAA-fizied 
service is actually provided. 

If we speak about PSTN call termination service, I think gateways 
would be a better place to hook AAA than proxies. A particular advantage 
of gateways (i.e., UAs from SIP perspective) doing the AAA job is it 
works even if subsequent SIP requests take a different path and do not
hit the same proxy. It sounds better to me than attempts to force 
routes by RR or B2B.

If transport services were hooked to AAA systems somehow (e.g., premium 
PSTN termination service incl. RSVP), it would be probably also easier 
to do the AAA job in gateways rather than in SIP proxies.

Note that having gateways done the AAA job from SIP perspective does not 
necessarily imply that the entire AAA functionality resides in gateways. 
More likely, it would be outsourced to a AAA server.

Jiri



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


From sip-admin@lists.bell-labs.com  Thu Jun 21 10:07:34 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29505
	for ; Thu, 21 Jun 2001 10:07:33 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 76E5A44392; Thu, 21 Jun 2001 10:08:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb3.rediffmail.com (unknown [202.54.124.148])
	by lists.bell-labs.com (Postfix) with SMTP id BBF864433E
	for ; Thu, 21 Jun 2001 10:07:58 -0400 (EDT)
Received: (qmail 21213 invoked by uid 510); 21 Jun 2001 14:13:22 -0000
Message-ID: <20010621141322.21212.qmail@mailweb3.rediffmail.com>
Received: from unknown (203.197.251.9) by rediffmail.com via HTTP; 21 Jun 2001 14:13:22 -0000
MIME-Version: 1.0
To: "davids@deltathree.com" ,
        "kuthan@fokus.gmd.de" ,
        "Brian.Rosen@marconi.com" ,
        "jbatson@pingtel.com" ,
        "sip@lists.bell-labs.com" 
Subject:  Re: RE: [SIP] Authentication and billing through proxy/re-direct  serv er
From: "Ashhar Farhan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 21 Jun 2001 14:13:22 -0000
Content-Transfer-Encoding: 7bit

i work on another proprietory telephony protocol -the lightweight telephony protocol that is sort of a cut-down binary equivalent of the sip. we have third party authentication scheme in-built into that protocol.

the we do in ltp is this:
1) an INVITE request arrives at a redirect server.
2) the redirect server checks for authnetication (by a challenge for an md5 response).
3) redirect server then, signs the invite message with the current nonce, userid and password of the gateway but returns the invite response back to the caller.
4) the caller now forwards this invite message to the gateway.
5) upon succseful propagation of this call, the gateway issues a NOTIFY message to the redirect server signalling a call start.
6) at the end of the call, another NOTIFY message is sent from the gateway to the server.
7) the gateway periodically sends NOTIFY messages to the server to keep the server informed of the gateway's availability and state. If a notification doesnt arrive for sufficient length of time (60 seconds), the gateway is thought to be offline.


the key points are:
1) the md5 digest is generated only over select headers so that they are replicated as in the message to the gateway.
2) the redirect server itself remains stateless.
3) NOTIFY messages are signed with md5 digest using the gateway's own password, userid.
4) we use NOTIFY to update the state of the gateway as opposed to REGISTER because REGISTER doesnt support any further state propagation. (gateway busy/idle/etc.)
5) if a gateway fails to successfully send a NOTIFY message to the server, it drops the current call (if any) and waits for the gateway <-> server connection to resume before accepting any further calls.

ps. i have lost the mail to re-register myself on sip@ietf.org, i will be glad if someone can send me the web url where i can subscribe to the new list.

- farhan@hotfoon.com


_____________________________________________________
Buy Lagaan & Yaadein music for 30% less.
Avail this special offer at http://shopping.rediff.com/shopping/music/offerrediffmailer.htm 




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


From sip-admin@ietf.org  Thu Jun 21 10:16:45 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29778;
	Thu, 21 Jun 2001 10:16:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14831;
	Thu, 21 Jun 2001 09:48:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14796
	for ; Thu, 21 Jun 2001 09:48:45 -0400 (EDT)
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28762
	for ; Thu, 21 Jun 2001 09:48:07 -0400 (EDT)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA20995; Thu, 21 Jun 2001 09:48:12 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AIV11159;
	Thu, 21 Jun 2001 09:48:10 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010621094629.03a59b30@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 21 Jun 2001 09:50:03 -0400
To: Jonathan Rosenberg 
From: Michael Hammer 
Subject: RE: [SIP] Re-invites in a multi-party call
Cc: "'Deepika Giri'" , "'sip@ietf.org'" 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

In the centralized model, is the concept that one controls the other 
parties streams or that one controls the flows to/from oneself?  That is, 
when I do a hold, I am not putting other parties on hold from the bridge, I 
am putting myself on hold from the bridge.  I control myself, not 
others.  If other parties wish to continue communicating, I have no control 
over that.  I believe this latter makes more sense in a distributed control 
environment.

Mike


At 03:37 AM 6/21/2001 -0400, Jonathan Rosenberg wrote:


>
>
> > -----Original Message-----
> > From: Deepika Giri [mailto:deepika@mascon.co.in]
> > Sent: Wednesday, June 13, 2001 8:27 AM
> > To: Jonathan Rosenberg
> > Cc: sip@lists.bell-labs.com
> > Subject: RE: [SIP] Re-invites in a multi-party call
> >
> >
> > My conferencing model centralized in nature, where the conference
> > server/bridge does the mixing.  The usr A is not aware that
> > he's connected
> > to the bridge, only the Conference Control application does
> > the bridging of
> > all the users to the CB, this is using 3pcc.
> >
> > As far as A is concerned, he knows that he is in conference
> > with B and C,
> > so, he can put them on hold by sending them messages
> > individually. right? or
> > can he send a single hold message that will put both of the
> > users on hold?
> > how does a standard SIP phone do this?
>
>Adam responded:
> > Not with the architecture you just described. As far as user A's
> > equipment is concerned, he is communicating with exactly one
> > party: the conference bridge. He will hold the conference bridge.
>
>That is correct. To add to that, it doesn't even make sense. If A sends a
>hold to C, so that C stops sending media to the mixer, then B will not hear
>A. That doesn't make sense.
>
>Perhaps what you want is that A gets to decide that it doesn't want to hear
>C anymore, but that B should still continue to hear C. To do this, you need
>a conference control protocol in order to set the mixing matrix used by the
>bridge. There is not yet a standardized protocol, but I would note that
>using a web interface to control this can get you a very long way.
>
> >
> > what if there is a situation where there is one more user D in the
> > conference(brought in by C, whose presence A is not aware of?
> >  He cannot
> > send a hold message to D, he doesn't even know he exists,
> > unless the list of
> > participants in the conference is constantly given to each of
> > the users.
>
>No, there is a direct SIP signaling relationship between each user an the
>bridge. There are no other SIP relationships.
>
>-Jonathan R.
>
>---
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com
>
>_______________________________________________
>Sip mailing list
>Sip@ietf.org
>http://www.ietf.org/mailman/listinfo/sip


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 11:50:09 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03454;
	Thu, 21 Jun 2001 11:50:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17537;
	Thu, 21 Jun 2001 10:40:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17510
	for ; Thu, 21 Jun 2001 10:40:26 -0400 (EDT)
Received: from bfgbhome.inetint.com (IDENT:root@tnt-dal-42-216.dallas.net [209.44.42.216])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00665
	for ; Thu, 21 Jun 2001 10:39:47 -0400 (EDT)
Received: (from brian@localhost)
	by bfgbhome.inetint.com (8.9.3/8.9.3) id JAA02698;
	Thu, 21 Jun 2001 09:39:57 -0500
Date: Thu, 21 Jun 2001 09:39:57 -0500
From: "Brian F. G. Bidulock" 
To: Jonathan Rosenberg 
Cc: "'Rosen, Brian'" ,
        "'Jiri Kuthan'" ,
        Ashhar Farhan ,
        "'sip@ietf.org'" 
Subject: Re: [SIP] Authentication and billing through proxy/re-direct serv er
Message-ID: <20010621093957.B30861@bfgbhome>
Reply-To: bidulock@openss7.org
Mail-Followup-To: Jonathan Rosenberg ,
	"'Rosen, Brian'" ,
	'Jiri Kuthan' ,
	Ashhar Farhan ,
	"'sip@ietf.org'" 
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: ; from jdrosen@dynamicsoft.com on Thu, Jun 21, 2001 at 02:27:34AM -0400
Organization: http://www.openss7.org/
Dsn-Notification-To: 
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Jonathan,

Jonathan Rosenberg wrote:                    (Thu, 21 Jun 2001 02:27:34)
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > Sent: Wednesday, June 20, 2001 5:14 PM
> > To: 'Jiri Kuthan'; Rosen, Brian; Ashhar Farhan; 'sip@ietf.org'
> > Subject: RE: [SIP] Authentication and billing through proxy/re-direct
> > serv er
> > 
> > 
> > 
> > 
> > I don't want to cast this in terms of billing == too narrow.
> > I want to be able to get information about a call out of
> > all of the devices in a call, including the proxies and the
> > UAs, and that includes the gateways.  The information I want to
> > get is statistics about the call.
> > 
> > I CAN do this with another interface; Radius for example, or SNMP.
> > I suspect it might be better, for UAs at least, to send this
> > call-related info up the chain to a proxy server.  If I don't,
> > then I force EVERY device in my network to have to implement this
> > other interface, whatever it is.
> 
> I really, really disagree that we should ever be propagating usage
> information in SIP in order to avoid interfaces between multiple elements
> and backened recording servers. Why? Well, what information is needed
> depends a WHOLE lot on the service being offered, the billing models, the
> operational requirements, etc. Since it depends on the service being
> offered, standardizing a protocol extension for conveying this information
> is akin to standardizing the set of services one might eventually offer. I
> think people know my opinion on standardizing all the services on might
> offer... horrible idea. 
> 
> So, the idea is to buy SIP elements (proxies, gateways, media servers, etc.)
> that can generate usage recording with every darn piece of information one
> might ever want to see, and make it nicely configurable. Then, depending on
> the service you offer, different information is generated.
> 
> Its very likely that more complex services will require usage information
> from elements beyond just the gateways (although call duration is only
> reliably obtained from gateways, as people have observed). But, my
> observation is that this is why billing mediation companies exist; to
> collect information from multiple elements, and aggregate them together to
> provide a coherent view of the service being offered.
> 
The corellation and agrgregation approach normally precludes the entire
range of real-time billing services.  This spectrum of real-time billing
services include popular services like pre-paid service (checking remaining
balance mid-call), and simple traditional services like time and charges.

Anybody can come up with a cool service, but being able to order, provision
and bill it becomes easier with the availalbility of a full range of ordering,
provisioning and billing mechanisms.  Ruling out the protocol elements
necessary to support a real time billing mechanism because you "don't like it"
or because you think it is the responsibilty of something other than call
control is IMHO irresponsible.


-- 
Brian F. G. Bidulock
bidulock@openss7.org
http://www.openss7.org/

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 12:48:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06266;
	Thu, 21 Jun 2001 12:48:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06579;
	Thu, 21 Jun 2001 12:32:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06551
	for ; Thu, 21 Jun 2001 12:32:30 -0400 (EDT)
Received: from mushroom (mushroom.icoe.net [194.242.71.50])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05467
	for ; Thu, 21 Jun 2001 12:31:53 -0400 (EDT)
Received: from romeo-w2000.icoe.att.com (unknown [135.76.80.37])
	by watermelon.icoe.att.com (Postfix) with ESMTP
	id 830C311592; Thu, 21 Jun 2001 18:31:55 +0200 (MET DST)
Message-Id: <5.1.0.14.0.20010621173803.028ddea8@watermelon.icoe.att.com>
X-Sender:  (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 21 Jun 2001 18:34:18 +0200
To: Jonathan Rosenberg ,
        "'William Marshall'" , sip@ietf.org
From: Romeo Zwart 
Subject: RE: [Sip] SDP usage in RFC2543/100rel/bis-03/manyfolks
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

At 08:46 AM 6/21/2001, Jonathan Rosenberg wrote:
> > -----Original Message-----
> > From: William Marshall [mailto:wtm@research.att.com]
> > Sent: Monday, June 18, 2001 2:47 PM
> > To: sip@ietf.org
> > Subject: [Sip] SDP usage in RFC2543/100rel/bis-03/manyfolks
> >
> > The restrictive wording in bis-03 on allowable placement of
> > message bodies in SIP requests/responses seems to lead to a
> > lot of compatibility problems with other current I-Ds.
> > [...]
> > Manyfolks-resource-01 made use of these allowable combinations,
> > to include the UAS SDP in the first reliable provisional response
> > (typically a 183 if resource reservation is supported).
> >
> > Unfortunately, bis-03 disallows this combination.
>
>Hows that? It merely states that if the INVITE contained SDP, so MUST the
>200, and not the ACK. Nothing in there about PRACK or 18x. Similarly, when
>INVITE doesn't have SDP, it MUST be in 200, and MUST be in ACK. Doesn't rule
>out anything else.

It's good to hear that bis-3 was not intended to ban out mechanisms
such as the manyfolks work propose. I think many people took the text
of annex B.1 to rule out SDP in 183's.

> >[...]
> > Both the dcs call flows (contained in draft-dcsgroup-sip-arch-04) and
> > the 3gpp call flows (contained in draft-drage-3gpp-sip-establish-00)
> > make further use of the secondary offer to perform negotiation of
> > codec capabilities.  A second round of offer-answer is allowed by
> > RFC2543,
>
>Thats not clear at all.
 >
> > but disallowed by 2543bis-03.  Some additional allowed
> > combinations in B.1 could solve this problem as well.
>
>I am trying to avoid the preponderance of a million ways of doing things,
>which has plagued other standards that shall remain nameless.

It is clear that 'a million ways of doing things' is not helping different
implementations to work together. From your earlier statement that sending
SDP in, e.g., 183 or PRACK is not excluded by bis03 and since sending
multiple 18x's is perfectly fine according to bis03 too, it would seem
that 'manyfolks' is not in conflict with bis03.

An additional few words in B.1. referring back to e.g. section 11.1 for
rules on (additional) SDP in 1xx responses might still be helpful to
avoid confusion.

Romeo


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 12:57:09 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06757;
	Thu, 21 Jun 2001 12:57:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10246;
	Thu, 21 Jun 2001 12:51:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10173
	for ; Thu, 21 Jun 2001 12:51:36 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06347
	for ; Thu, 21 Jun 2001 12:50:59 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA25488;
	Thu, 21 Jun 2001 12:55:09 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 12:51:04 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'David Schwartz'" ,
        "'Jiri Kuthan'"
	 ,
        "'Rosen, Brian'" ,
        "'Jay Batson'" ,
        "'Ashhar Farhan'"
	 ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct  ser
	 v er
Date: Thu, 21 Jun 2001 12:50:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: David Schwartz [mailto:davids@deltathree.com]
> Sent: Thursday, June 21, 2001 9:30 AM
> To: 'Jiri Kuthan'; 'Rosen, Brian'; 'Jay Batson'; 'Ashhar Farhan';
> 'sip@lists.bell-labs.com'
> Subject: RE: [SIP] Authentication and billing through proxy/re-direct
> ser v er
> 
> Here to it is important to look at the pros and cons in doing 
> this in an
> internal proxy Vs. using the gateway. The big con in using 
> the proxy is that
> it causes another statefull element in the network and since 
> the VG must be
> statefull anyway why have another statefull element. In 
> addition when it
> comes to the call stop (CDR creation) there is some 
> information that might
> be needed about the user (e.g. internal username) that may 
> only be available
> from the call start response. So the typical solution is to 
> use the VG. The
> con with using the VG is that you must own the VG. If you 
> wish to terminate
> on someone elses network it can be tricky retrieving the CDR's. 
> 
> One possible stateless solution might be to use the proxy for 
> call start and
> call stop. The Record-Route header is used to ensure that the 
> proxy sees the
> BYE message. Any proxy that gets an invite generates a call start (on
> receiving the 200 OK) which writes to some file that a 
> particular callID has
> started a call at this particular time, and any proxy getting a BYE
> generates a call stop which writes to a file (potentialy on a 
> different
> machine) that a particular callID has stopped a call at a 
> different time.
> There is no state that needs to be saved. Instead, a different process
> constantly moniters these files and correlates the call 
> starts with the call
> stops. This seperate process is the one that generates the 
> CDR's. This also
> reduces the load on the VG's enabling them to focus on the 
> call setup and
> teardown.

Using a proxy to generate minutes of usage is very hard. Ultimately, the
gateway knows the call call duration, as it is the arbiter of whether the
call is still in progress with the PSTN. For proxy-based duration to work,
you need to be able to prove that the proxy is always in continuous
synchronization (in terms of call state) with the gateway, within a
reasonable time lag. So, can you prove that an attacker cannot force the
proxy and gateway to go out of sync? I know of several attacks that are
possible in order to convince the proxy that the call is down, but the
gateway that the call is up (Max-Forwards values which cause the BYE to pass
the proxy but fail at the gateway, for example). This results in free
service. Someone more creative than I might come up with a few more.

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


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 13:09:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07557;
	Thu, 21 Jun 2001 13:09:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13044;
	Thu, 21 Jun 2001 13:01:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12962
	for ; Thu, 21 Jun 2001 13:01:05 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07033
	for ; Thu, 21 Jun 2001 13:00:28 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA25726;
	Thu, 21 Jun 2001 13:04:55 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 13:00:50 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'bidulock@openss7.org'" ,
        Jonathan Rosenberg
	 
Cc: "'Rosen, Brian'" ,
        "'Jiri Kuthan'"
	 ,
        Ashhar Farhan ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	 er
Date: Thu, 21 Jun 2001 13:00:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]
> Sent: Thursday, June 21, 2001 10:40 AM
> To: Jonathan Rosenberg
> Cc: 'Rosen, Brian'; 'Jiri Kuthan'; Ashhar Farhan; 'sip@ietf.org'
> Subject: Re: [SIP] Authentication and billing through proxy/re-direct
> serv er
> 
> 
> > Its very likely that more complex services will require 
> usage information
> > from elements beyond just the gateways (although call 
> duration is only
> > reliably obtained from gateways, as people have observed). But, my
> > observation is that this is why billing mediation companies 
> exist; to
> > collect information from multiple elements, and aggregate 
> them together to
> > provide a coherent view of the service being offered.
> > 
> The corellation and agrgregation approach normally precludes 
> the entire
> range of real-time billing services.  This spectrum of 
> real-time billing
> services include popular services like pre-paid service 
> (checking remaining
> balance mid-call), and simple traditional services like time 
> and charges.
> 
> Anybody can come up with a cool service, but being able to 
> order, provision
> and bill it becomes easier with the availalbility of a full 
> range of ordering,
> provisioning and billing mechanisms.  Ruling out the protocol elements
> necessary to support a real time billing mechanism because 
> you "don't like it"
> or because you think it is the responsibilty of something 
> other than call
> control is IMHO irresponsible.

I am not trying to rule out services. I very much appreicate the importance
and complexity of provisioning and billing systems, as much of the time of
my "real" job is spent worrying about such things. I am trying to argue that
construction of new services (with or without real time billing) do not
require the propagation of reporting information in SIP. Prepaid calling,
for example, can (and has) been constructed with existing SIP, and requires
no propagation of call duration, or other usage reporting, within SIP.

The burden is on those who want the information to be present to construct a
specific proposal, and to argue concisely why existing protocol capabilities
or architectures are not sufficient, and these new functions are needed.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 13:12:30 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07765;
	Thu, 21 Jun 2001 13:12:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08589;
	Thu, 21 Jun 2001 12:42:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08558
	for ; Thu, 21 Jun 2001 12:42:13 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05981
	for ; Thu, 21 Jun 2001 12:41:36 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA25287;
	Thu, 21 Jun 2001 12:46:00 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 12:41:55 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'James Undery'" ,
        Jonathan Rosenberg
	 
Cc: aki.niemi@nokia.com, corey@hearme.com, sip@ietf.org
Subject: RE: [Sip] Request header integrity in HTTP Digest
Date: Thu, 21 Jun 2001 12:41:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: James Undery [mailto:jundery@ubiquity.net]
> Sent: Thursday, June 21, 2001 3:40 AM
> To: Jonathan Rosenberg
> Cc: aki.niemi@nokia.com; corey@hearme.com; sip@ietf.org
> Subject: Re: [Sip] Request header integrity in HTTP Digest
> 
> 
> > The only thing thats broken is your perception of the problem being
> solved.
> 
> That's exactly what I was getting at this approach will never 
> solve the
> problems
> it claims to.

It solves all three replay attacks presented section 2. It won't solve the
MITM attacks if the attacker is smart and is careful about modifying the
request in the same way between the original one and resubmitted one. 

If you believe if doesn't solve the problems it claims to, please indicate
clearly, for the three replay attacks, how these are not prevented by the
mechanism, even though I claim they are.


> 
> > Your gripe is with the authors of rfc2617, not me. Please 
> feel free to
> send
> > them a note saying that rfc2617 is "just plain broken". They may be
> > offended, but they will probably have to agree with you 
> that the problem
> you
> > describe exists. The problem is not a problem with this draft, its a
> problem
> > with digest, and is not fixed by this draft. Digest provides weak
> security,
> > no doubt. The right way to ultimately fix it is to have a 
> nice, fully
> scoped
> > out, shared secret and/or public key 
> encryption/authentication mechanism.
> > But, we don't have that right now.
> >
> 
> HTTP is totally different from SIP I have no problem at all 
> with that draft
> Section 4 is very clear about the limitations of the draft.

I am missing your point here. SIP digest is identical to http digest.

> 
> >
> > The mechanism described in the draft provides a level of 
> security that is
> > better than digest. It fixes some of the most horrible and 
> easiest to
> launch
> > attacks (especially the replay ones).
> 
> UA sends a "Contact: *",  "Expires: 0" REGISTER request and 
> authenticates
> it.
> Bad guy sniffs the authenticated register
> UA then sends the new contacts for the user.
> Bad guy then replays the first message with an incremented 
> CSeq quickly.
> 
> Common scenario, simple attack how does you draft help?

Common scenario? It only works when the UA sends a Contact: * Expires: 0 and
the re-registers with new contacts right away. Doesn't seem that frequent a
case at all. When would this happen in practice? The mechanism will not
protect you from attacks where the attacker replays (but doesn't modify) the
request. That is a subset of the attacks possible with digest, where you can
replay modified requests.

> 
> > It doesn't fix all of them, including
> > the MITM attack you describe. However, the cost for this 
> fix is *zero*,
> > since it requires no changes in the specs or client 
> behaviors. It is an
> > implementation choice for the server, and the decision to 
> use it can be
> made
> > independently for each transaction in each server, without 
> impacting any
> > other devices. The only reason why it even needs to be 
> discussed at all is
> > that it is best served by a one-liner in the SIP spec that says you
> > shouldn't generally change the SIP message between the 
> initial request and
> > the new request with credentials. Not that anyone actually 
> does change the
> > headers that are being protected, as far as I know, but its 
> nice to just
> say
> > it.
> 
> The whole point is to better secure digest authentication the 
> UA needs to
> include important headers and the server supplied nonce hashed in the
> credentials, so the UA knows exactly what it is 
> authenticating. This still
> leaves all the problems of digest authentication but puts SIP 
> on a similar
> level
> to HTTP.

I agree that the ultimate mechanism will make sure the client knows what it
is authenticating. Digest, both HTTP and SIP (as they are the same) doesn't
work this way.

> 
> > So, to be clear, I am not proposing that this is the be-all 
> and end-all of
> > security. It is, IMHO, a very elegant and simple fix that 
> improves the
> > performance of digest significantly beyond where it is now.
> 
> I think if worsens it as Corey pointed out (and I totally 
> missed even when
> he
> did). 

Utter nonsense. Corey pointed out that the nonce should include a private
key so that its not guessable. Guessing it doesn't help you terribly much,
but fine, we'll do that. The same issue arises with regular digest. 

I claim that this approach improves security, since it removes replay
attacks that require modification of the message. An example is modifying
the Contact in a REGISTER to route calls to my phone. Regular http digest
doesn't protect against this. The pnonce does. So, if you still believe that
pnonce is useless, please argue that:

1. I am incorrect, and this attack is not possible with digest, or
2. I am incorrect, and this attack is possible with digest, but still
possible in my proposed approach.

Continuously throwing out attacks that are still possible with pnonces
proves nothing, and only shows that you continue to miss the point. It only
proves that digest, with or without pnonce, are susceptible to these. I have
offered, in the doc, three CONCRETE replay attacks that are prevented with
pnonces. If you believe that this mechanism makes things worse, please point
out a concrete attack which is not possible in regular digest, but is now
possible with pnonces. If you cannot offer such an attack, then your claims
that it fixes nothing are bogus.

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

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 13:22:47 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08309;
	Thu, 21 Jun 2001 13:22:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10671;
	Thu, 21 Jun 2001 12:53:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10642
	for ; Thu, 21 Jun 2001 12:53:06 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06453
	for ; Thu, 21 Jun 2001 12:52:30 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA25527;
	Thu, 21 Jun 2001 12:56:59 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 12:52:54 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Michael Hammer'" ,
        Jonathan Rosenberg
	 
Cc: "'Deepika Giri'" , "'sip@ietf.org'" 
Subject: RE: [SIP] Re-invites in a multi-party call
Date: Thu, 21 Jun 2001 12:52:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Michael Hammer [mailto:mhammer@cisco.com]
> Sent: Thursday, June 21, 2001 9:50 AM
> To: Jonathan Rosenberg
> Cc: 'Deepika Giri'; 'sip@ietf.org'
> Subject: RE: [SIP] Re-invites in a multi-party call
> 
> 
> In the centralized model, is the concept that one controls the other 
> parties streams or that one controls the flows to/from 
> oneself? 

To/from oneself, just like a regular call.

> That is, 
> when I do a hold, I am not putting other parties on hold from 
> the bridge, I 
> am putting myself on hold from the bridge. 

Right. If you send a re-INVITE with 0.0.0.0 in the SDP, you will stop
receiving media. This has nothing to do with anyone else.

-Jonathan R.

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


> > > -----Original Message-----
> > > From: Deepika Giri [mailto:deepika@mascon.co.in]
> > > Sent: Wednesday, June 13, 2001 8:27 AM
> > > To: Jonathan Rosenberg
> > > Cc: sip@lists.bell-labs.com
> > > Subject: RE: [SIP] Re-invites in a multi-party call
> > >
> > >
> > > My conferencing model centralized in nature, where the conference
> > > server/bridge does the mixing.  The usr A is not aware that
> > > he's connected
> > > to the bridge, only the Conference Control application does
> > > the bridging of
> > > all the users to the CB, this is using 3pcc.
> > >
> > > As far as A is concerned, he knows that he is in conference
> > > with B and C,
> > > so, he can put them on hold by sending them messages
> > > individually. right? or
> > > can he send a single hold message that will put both of the
> > > users on hold?
> > > how does a standard SIP phone do this?
> >
> >Adam responded:
> > > Not with the architecture you just described. As far as user A's
> > > equipment is concerned, he is communicating with exactly one
> > > party: the conference bridge. He will hold the conference bridge.
> >
> >That is correct. To add to that, it doesn't even make sense. 
> If A sends a
> >hold to C, so that C stops sending media to the mixer, then 
> B will not hear
> >A. That doesn't make sense.
> >
> >Perhaps what you want is that A gets to decide that it 
> doesn't want to hear
> >C anymore, but that B should still continue to hear C. To do 
> this, you need
> >a conference control protocol in order to set the mixing 
> matrix used by the
> >bridge. There is not yet a standardized protocol, but I 
> would note that
> >using a web interface to control this can get you a very long way.
> >
> > >
> > > what if there is a situation where there is one more user D in the
> > > conference(brought in by C, whose presence A is not aware of?
> > >  He cannot
> > > send a hold message to D, he doesn't even know he exists,
> > > unless the list of
> > > participants in the conference is constantly given to each of
> > > the users.
> >
> >No, there is a direct SIP signaling relationship between 
> each user an the
> >bridge. There are no other SIP relationships.
> >
> >-Jonathan R.
> >
> >---
> >Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> >Chief Scientist                             First Floor
> >dynamicsoft                                 East Hanover, NJ 07936
> >jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> >http://www.jdrosen.net                      PHONE: (973) 952-5000
> >http://www.dynamicsoft.com
> >
> >_______________________________________________
> >Sip mailing list
> >Sip@ietf.org
> >http://www.ietf.org/mailman/listinfo/sip
> 

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 13:29:16 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08789;
	Thu, 21 Jun 2001 13:29:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17651;
	Thu, 21 Jun 2001 13:23:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17623
	for ; Thu, 21 Jun 2001 13:23:02 -0400 (EDT)
Received: from mailweb4.rediffmail.com (IDENT:qmailr@[202.54.124.149])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08291
	for ; Thu, 21 Jun 2001 13:22:24 -0400 (EDT)
Received: (qmail 5786 invoked by uid 510); 21 Jun 2001 17:27:50 -0000
Date: 21 Jun 2001 17:27:50 -0000
Message-ID: <20010621172750.5785.qmail@mailweb4.rediffmail.com>
Received: from unknown (203.197.251.9) by rediffmail.com via HTTP; 21 Jun 2001 17:27:50 -0000
MIME-Version: 1.0
To: "sip@ietf.org" 
Subject:  RE: [SIP] Authentication and billing through proxy/re-direct  serv er
From: "Ashhar Farhan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

davids wrote -
>> What is the lifetime of your nonce? What if someone is sniffing the
packets and sends a different request to the VG with your authentication
information?

the nonce is regenerated every 3 minutes.

if the information is changed, the digest will change. the digest is over gateway's userid, password, nonce and certain headers of the invite (as generated by the caller).


>> How is the redirect server identified? via Record-Route (I don't think so
since the user is going directly to the VG) or is it preconfigured in the
VG? If the latter, what if the redirect server goes down? is there some sort
of hot backup mechanism?

if the redirect server goes down, the gateway should stop responding to INVITEs. yes, the redirect server is preconfigured at the VG.

>> What if the VG goes down? are all the current calls with their CDR
information lost?

the vg does not start the next call unless the record of the previous call is recorded by the server and confirmed back with a 200 response.

- farhan@hotfoon.com


_____________________________________________________
Buy Lagaan & Yaadein music for 30% less.
Avail this special offer at http://shopping.rediff.com/shopping/music/offerrediffmailer.htm 




_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 13:59:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10622;
	Thu, 21 Jun 2001 13:59:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24473;
	Thu, 21 Jun 2001 13:53:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24439
	for ; Thu, 21 Jun 2001 13:53:08 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10189
	for ; Thu, 21 Jun 2001 13:52:29 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22605
	for ; Thu, 21 Jun 2001 13:52:31 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06803
	for ; Thu, 21 Jun 2001 13:52:35 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Thu, 21 Jun 2001 13:52:33 -0400
Message-ID: <4FBEA8857476D311A03300204840E1CF044655C3@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'sip@ietf.org'" 
Date: Thu, 21 Jun 2001 13:52:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Administrivia - List Maintainer has no patience with quotas/routi
 ng problems/etc
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Folks, I (at the moment, and by choice) alone, maintain the sip
(and sipping) lists.  That means I get the bounces, the errors
and the misdirected missives.  I have a lot to do in my day,
and I have no patience for problems that it appears to me are
caused by individual negligence.

If mail starts bouncing because you are overquota, or your account is
deactivated, or you subscribed to a non-working account,
I will unsubscribe you pretty quick.  I try to let a day go by,
but rarely more than that.  If MailMan detects a serious problem (like
a forwarding loop), it automatically deactivates you immediately

If the problem appears to be more serious (every once in a while,
a whole domain gets in trouble, for example), I will be more
tolerant, but only a day or two's worth.

When you are unsubscribed, you get a message, but as you may 
guess, if your account is screwed up, you may not get that message.
Sorry about that.  

A great many people are subscribed through email servers that have
quotas.  If you are going to be unable to read your mail for a
while, I suggest you manually unsubscribe and resubscribe.
As you know, a couple of days of sip, sip-implementors and sipping
can fill an inbox pretty darn quick.  Two people got booted today.

Thanks
Brian

_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


From sip-admin@ietf.org  Thu Jun 21 15:13:45 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14709;
	Thu, 21 Jun 2001 15:13:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08962;
	Thu, 21 Jun 2001 14:43:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08873
	for ; Thu, 21 Jun 2001 14:43:33 -0400 (EDT)
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13698
	for ; Thu, 21 Jun 2001 14:42:54 -0400 (EDT)
Received: from plate (localhost.localdomain [127.0.0.1])
	by kevlar.softarmor.com (8.11.2/8.11.2) with SMTP id f5LIb2c05407;
	Thu, 21 Jun 2001 13:37:02 -0500
Message-ID: <00ff01c0fa81$6c51cfc0$c7b954c3@adlon.se>
From: "Dean Willis" 
To: "Ashhar Farhan" , ,
        "Jay Batson" 
References: <5.1.0.14.2.20010620104612.033517a0@mail.pingtel.com>
Subject: Re: Re: [SIP] Authentication and billing through  proxy/re-direct server
Date: Thu, 21 Jun 2001 13:38:50 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00FC_01C0FA57.819E2E20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_00FC_01C0FA57.819E2E20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Actually, we can go one step further and eliminate the requirement for =
registration.

A proxy fronting a gateway could conceivably check the credit on a =
per-INVITE basis. Auethnticated INVITES with adequate credit would be =
passed to the gateway for call completion. This is transaction stateful =
in the proxy(not CALL stateful), but this isn't a particularly bad thing =
-- the proxy is going to want to be transaction stateful so that it can =
feed back a provisional response and slow down the retransmit timers =
anyhow.

Despitewhat the mobile phone people think, reception of a SIP REGISTER =
message by a proxy is NOT a requirement to be able to process INVITES. =
You MAY have to REGISTER to receive a call -- you SHOULD NOT have to =
register to make a call.

Now, of one were to implement call metering in the gateway, one could go =
so far as to send a gateway-specific header indicating the available =
credit. It's more common to front-end a prepaid gateway with a B2BUA =
prepaid app, which is easy to build on an app server. That may be the =
only legitimate use of a signaling-only back-to-back user agent.=20

--
Dean

--
Dean
  ----- Original Message -----=20
  From: Jay Batson=20
  To: Ashhar Farhan ; sip@ietf.org=20
  Sent: Wednesday, June 20, 2001 9:50 AM
  Subject: Re: Re: [SIP] Authentication and billing through =
proxy/re-direct server


  I'm not as technically deep as others in this, but here's a =
response.... (routed back through the "new" mailing list at IETF for =
SIP):

  At 11:29 PM 6/19/01, Ashhar Farhan wrote:

    1) how does a gateway know whether the caller is credit worthy? if =
we require a separate TLS style connection to the proxy for billing =
purpose, it is actually simpler to just make the proxy hold the state =
information and pass setup and cleardown messages over the same pipe.

    2)we do not require TLS pipe between the UA and the proxy to =
authenticate itself. i dont see why we should require a TLS session =
between the gateway and the proxy to authenticate the incoming callers.

  The gateway doesn't want to know, the proxy should.  Via network =
design (vs. protocol design) you can make the gateway only accept =
INVITEs from an authenticated Proxy.  The proxy doesn't need to maintain =
state to authenticate if the caller is credit worthy on a =
session-by-session basis -- it can simply deny a registration to any UA =
it doesn't want to serve (e.g. a customer that isn't credit worthy.)  No =
registration, no INVITE gets through to the gateway.  TLS is irrelevant.


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




------=_NextPart_000_00FC_01C0FA57.819E2E20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









 


Actually, we can go one step further =
and eliminate=20
the requirement for registration.


 


A proxy fronting a gateway could =
conceivably check=20
the credit on a per-INVITE basis. Auethnticated INVITES with =
adequate=20
credit would be passed to the gateway for call completion. This is =
transaction=20
stateful in the proxy(not CALL stateful), but this isn't a particularly =
bad=20
thing -- the proxy is going to want to be transaction stateful so that =
it can=20
feed back a provisional response and slow down the retransmit timers=20
anyhow.


 


Despitewhat the mobile phone people =
think,=20
reception of a SIP REGISTER message by a proxy is NOT a requirement to =
be able=20
to process INVITES. You MAY have to REGISTER to receive a call -- you =
SHOULD NOT=20
have to register to make a call.


 


Now, of one were to implement call =
metering in the=20
gateway, one could go so far as to send a gateway-specific header =
indicating the=20
available credit. It's more common to front-end a prepaid gateway with a =
B2BUA=20
prepaid app, which is easy to build on an app server. That may be the =
only=20
legitimate use of a signaling-only back-to-back user agent. =



 


--


Dean


 


--


Dean



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

  From:=20
  Jay =
Batson=20
  

  
  
Sent: Wednesday, June 20, 2001 =
9:50=20
  AM

  
Subject: Re: Re: [SIP] =
Authentication and=20
  billing through proxy/re-direct server

  

I'm not as technically deep as others in this, but =
here's a=20
  response.... (routed back through the "new" mailing list at IETF for=20
  SIP):

At 11:29 PM 6/19/01, Ashhar Farhan wrote:

  
1) how does a gateway know =
whether=20
    the caller is credit worthy? if we require a separate TLS style =
connection=20
    to the proxy for billing purpose, it is actually simpler to just =
make the=20
    proxy hold the state information and pass setup and cleardown =
messages over=20
    the same pipe.

2)we do not require TLS pipe between the UA =
and the=20
    proxy to authenticate itself. i dont see why we should require a TLS =
session=20
    between the gateway and the proxy to authenticate the incoming=20
  callers.

The gateway doesn't want to know, the proxy=20
  should.  Via network design (vs. protocol design) you can make =
the=20
  gateway only accept INVITEs from an authenticated Proxy.  The =
proxy=20
  doesn't need to maintain state to authenticate if the caller is credit =
worthy=20
  on a session-by-session basis -- it can simply deny a registration to =
any UA=20
  it doesn't want to serve (e.g. a customer that isn't credit =
worthy.)  No=20
  registration, no INVITE gets through to the gateway.  TLS is=20
  irrelevant.


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



------=_NextPart_000_00FC_01C0FA57.819E2E20--


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


From sip-admin@ietf.org  Thu Jun 21 15:21:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15019;
	Thu, 21 Jun 2001 15:21:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10714;
	Thu, 21 Jun 2001 15:13:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10686
	for ; Thu, 21 Jun 2001 15:13:54 -0400 (EDT)
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14648
	for ; Thu, 21 Jun 2001 15:13:16 -0400 (EDT)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA25542; Thu, 21 Jun 2001 15:13:15 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AIV14702;
	Thu, 21 Jun 2001 15:13:14 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010621151040.03a55f08@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 21 Jun 2001 15:15:08 -0400
To: "Dean Willis" 
From: Michael Hammer 
Subject: Re: Re: [SIP] Authentication and billing through 
  proxy/re-direct server
Cc: "Ashhar Farhan" , ,
        "Jay Batson" 
In-Reply-To: <00ff01c0fa81$6c51cfc0$c7b954c3@adlon.se>
References: <5.1.0.14.2.20010620104612.033517a0@mail.pingtel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

At 01:38 PM 6/21/2001 -0500, Dean Willis wrote:
>
>Actually, we can go one step further and eliminate the requirement for 
>registration.
>
>A proxy fronting a gateway could conceivably check the credit on a 
>per-INVITE basis. Auethnticated INVITES with adequate credit would be 
>passed to the gateway for call completion. This is transaction stateful in 
>the proxy(not CALL stateful), but this isn't a particularly bad thing -- 
>the proxy is going to want to be transaction stateful so that it can feed 
>back a provisional response and slow down the retransmit timers anyhow.
>
>Despitewhat the mobile phone people think, reception of a SIP REGISTER 
>message by a proxy is NOT a requirement to be able to process INVITES. You 
>MAY have to REGISTER to receive a call -- you SHOULD NOT have to register 
>to make a call.

So long as you are willing to provide your radio network for free, that's 
fine.  But I would bet that most operators that paid millions to get 
airwave licenses would like to recoup their costs at a minimum.  You must 
be sure that you can settle with the home network in order to get 
paid.  Mobile operators see the location aspects of register also 
intertwined with the authorization/billing aspects.

Mike

>
>Now, of one were to implement call metering in the gateway, one could go 
>so far as to send a gateway-specific header indicating the available 
>credit. It's more common to front-end a prepaid gateway with a B2BUA 
>prepaid app, which is easy to build on an app server. That may be the only 
>legitimate use of a signaling-only back-to-back user agent.
>
>--
>Dean
>
>--
>Dean
>----- Original Message -----
>From: Jay Batson
>To: Ashhar Farhan ; 
>sip@ietf.org
>Sent: Wednesday, June 20, 2001 9:50 AM
>Subject: Re: Re: [SIP] Authentication and billing through proxy/re-direct 
>server
>
>I'm not as technically deep as others in this, but here's a response.... 
>(routed back through the "new" mailing list at IETF for SIP):
>
>At 11:29 PM 6/19/01, Ashhar Farhan wrote:
>>1) how does a gateway know whether the caller is credit worthy? if we 
>>require a separate TLS style connection to the proxy for billing purpose, 
>>it is actually simpler to just make the proxy hold the state information 
>>and pass setup and cleardown messages over the same pipe.
>>
>>2)we do not require TLS pipe between the UA and the proxy to authenticate 
>>itself. i dont see why we should require a TLS session between the 
>>gateway and the proxy to authenticate the incoming callers.
>The gateway doesn't want to know, the proxy should.  Via network design 
>(vs. protocol design) you can make the gateway only accept INVITEs from an 
>authenticated Proxy.  The proxy doesn't need to maintain state to 
>authenticate if the caller is credit worthy on a session-by-session basis 
>-- it can simply deny a registration to any UA it doesn't want to serve 
>(e.g. a customer that isn't credit worthy.)  No registration, no INVITE 
>gets through to the gateway.  TLS is irrelevant.
>
>-------------
>PingMe!
>Jay Batson
>CEO
>Pingtel Corp.
>mailto:jbatson@pingtel.com
>781-938-5306 (office)


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


From sip-admin@ietf.org  Thu Jun 21 16:49:07 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17443;
	Thu, 21 Jun 2001 16:49:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13512;
	Thu, 21 Jun 2001 16:41:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13479
	for ; Thu, 21 Jun 2001 16:41:57 -0400 (EDT)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17252
	for ; Thu, 21 Jun 2001 16:41:18 -0400 (EDT)
Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id UAA08741;
	Thu, 21 Jun 2001 20:41:26 GMT
Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 21 Jun 2001 20:41:25 0000 (GMT)
Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 13:41:23 -0700
Message-ID: <4148FEAAD879D311AC5700A0C969E89006E18BF3@orsmsx35.jf.intel.com>
From: "Gross, Gerhard" 
To: "'bidulock@openss7.org'" ,
        Jonathan Rosenberg
	 
Cc: "'Rosen, Brian'" ,
        "'Jiri Kuthan'"
	 ,
        Ashhar Farhan ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	er
Date: Thu, 21 Jun 2001 13:41:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

A solution to *ONE PIECE* of the AAA problem discussed
in this thread is addressed by slapping a PEP (policy
enforcement point) layer on top of the SIP proxy
and using a AAA/policy server in the domain as
the PDP (policy decision point). The COPS extension
for SIP and usage instructions are specified in
http://www.ietf.org/internet-drafts/draft-gross-cops-sip-01.txt.

The PDP is made aware of INVITES, responses, ACKs,
BYEs, etc. through the PEP. So the PDP can tabulate
call event and timing statistics. These can be used
for whatever accounting (and subsequent charging and
billing) models that happen to be deployed. The
AAA/policy server is owned and maintained by the
service provider and is therefore protected and trusted.

Call statefulness is handled by COPS and the PDP, not
by the SIP proxy. The PDP (AAA server) may interact
with a clearing house (broker, billing mediation company,
etc.) for inter-domain AAA purposes as people see fit.
As far as I know, there is no reason this can not be real
time so that "real-time billing services" can be used.

The additional benefit of providing local policy management
of SIP usage is also there.

This does not directly address the issue of byte counts
per session in case billing were dependent on that.
Having the UA deliver CDRs when the call is over seems
like asking for fraud since the UA is generally not
owned by the service provider. How can it be trusted
to report accurate CDRs?

As others have said, the burden of collecting
other call/session statistics (e.g. byte count)
should fall on the entity providing the service
who wants to get paid for it. That entity may,
for example, deploy some monitoring module at
its egress points.


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


From sip-admin@ietf.org  Thu Jun 21 17:01:06 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17729;
	Thu, 21 Jun 2001 17:01:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13850;
	Thu, 21 Jun 2001 16:55:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13823
	for ; Thu, 21 Jun 2001 16:55:25 -0400 (EDT)
Received: from go-postal.hearme.com (go-postal.hearme.com [206.233.215.57])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17618
	for ; Thu, 21 Jun 2001 16:54:48 -0400 (EDT)
Received: by go-postal.hearme.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 21 Jun 2001 13:54:39 -0700
Message-ID: 
From: Corey Gates 
To: "'Jonathan Rosenberg'" ,
        "'sip@ietf.org'"
	 
Subject: RE: [Sip] Request header integrity in HTTP Digest
Date: Thu, 21 Jun 2001 13:54:38 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



Jonathan Rosenberg wrote:

>
<>
> 
> It solves all three replay attacks presented section 2. It won't solve the
> MITM attacks if the attacker is smart and is careful about modifying the
> request in the same way between the original one and resubmitted one. 

> If you believe if doesn't solve the problems it claims to, please indicate
> clearly, for the three replay attacks, how these are not prevented by the
> mechanism, even though I claim they are.
>

I agree that the three specific replay attacks as described in the document
are mitigated with the use of pnonce.  Note that they are also mitigated
using standard 2617 nonces if the server rejects previously used nonces
during the timespan of the nonce, but this is not as nice.  

The problem I have is that a small modification of the replay attacks are
possible if the "private-key" is not included.  This small modification is
to get the client to authorize a "pnonce" the attacker generates, which can
then be used later.  Since there is no "private-key" included in the hash,
the server does not know that the pnonce was generated by the attacker.
This fake pnonce could include the headers and source IP that the attacker
wants to use.  Note that this is NOT a MITM attack, because the attacker
needs only to elicit an authorized INVITE or REGISTER from the UAC, not
intercept/forward a transaction.  This could be done by sending a
constructed 401 as soon as the attacker sees any message leaving the UAC.  

By adding the "private-key" to the pnonce generation, the attacker must
guess the "private-key" in order to generate the pnonce, making this
modified replay attack more difficult.

>
<>
> 
> Utter nonsense. Corey pointed out that the nonce should include a private
> key so that its not guessable. Guessing it doesn't help you terribly much,
> but fine, we'll do that. The same issue arises with regular digest. 
> 
> I claim that this approach improves security, since it removes replay
> attacks that require modification of the message. An example is modifying
> the Contact in a REGISTER to route calls to my phone. Regular http digest
> doesn't protect against this. The pnonce does. So, if you still believe
that
> pnonce is useless, please argue that:
> 
> 1. I am incorrect, and this attack is not possible with digest, or
> 2. I am incorrect, and this attack is possible with digest, but still
> possible in my proposed approach.
> 
> Continuously throwing out attacks that are still possible with pnonces
> proves nothing, and only shows that you continue to miss the point. It
only
> proves that digest, with or without pnonce, are susceptible to these. I
have
> offered, in the doc, three CONCRETE replay attacks that are prevented with
> pnonces. If you believe that this mechanism makes things worse, please
point
> out a concrete attack which is not possible in regular digest, but is now
> possible with pnonces. If you cannot offer such an attack, then your
claims
> that it fixes nothing are bogus.
>

I was trying to point out that fake pnonces are possible without the use of
the "private-key" as specified in 2617.  

Note that the draft could potentially be as simple as saying that the "ETag"
field used in generating nonces in 2617 is replaced with "" and be done with it.  This would be clear and understandable.
pnonces are simply a method of assigning a resource tag to a transaction set
and otherwise follow 2617.  Obviously this means that most of the attacks
presented in 2617 are the same and still there.  Now, however, it easier for
the server to reject bad nonces without having to store them for a time.

I think this is a good idea and a helpful draft.  I simply want to keep the
nonce generation par with 2617, so we need to include "private-key" in the
pnonce generation.

Corey Gates

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


From sip-admin@ietf.org  Thu Jun 21 19:10:12 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19958;
	Thu, 21 Jun 2001 19:10:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17979;
	Thu, 21 Jun 2001 19:05:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17937
	for ; Thu, 21 Jun 2001 19:05:18 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19819
	for ; Thu, 21 Jun 2001 19:04:41 -0400 (EDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5LN3H422227;
	Thu, 21 Jun 2001 19:03:17 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-91.cisco.com [161.44.241.91])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ABA04536 (AUTH pkyzivat);
	Thu, 21 Jun 2001 19:04:42 -0400 (EDT)
Message-ID: <3B327C98.68D3F9D@cisco.com>
Date: Thu, 21 Jun 2001 19:00:40 -0400
From: Paul Kyzivat 
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Michael Hammer'" ,
        "'Deepika Giri'" ,
        "'sip@ietf.org'" 
Subject: Re: [SIP] Re-invites in a multi-party call
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:
[snip] 
> Right. If you send a re-INVITE with 0.0.0.0 in the SDP, you will stop
> receiving media. This has nothing to do with anyone else.

This is really only true with cooperative partners isn't it?

I have asked the other party to stop sending media,
but if he ignores my request and continues sending, and if I
am still using the socket (perhaps for some other call),
then I will still receive what he sends.

	Paul Kyzivat
	Cisco Systems

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


From sip-admin@ietf.org  Thu Jun 21 19:38:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20455;
	Thu, 21 Jun 2001 19:38:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19087;
	Thu, 21 Jun 2001 19:34:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA19057
	for ; Thu, 21 Jun 2001 19:34:03 -0400 (EDT)
Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20339
	for ; Thu, 21 Jun 2001 19:33:26 -0400 (EDT)
Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.2) id f5LNXv459813; Thu, 21 Jun 2001 19:33:57 -0400 (EDT)
Reply-To: 
From: "Brett Tate" 
To: "'Jonathan Rosenberg'" , 
Subject: RE: [Sip] new open issue in session timer: NEEDS resolution now!
Date: Thu, 21 Jun 2001 19:37:05 -0400
Message-ID: <002c01c0faab$14ba5000$2b01a8c0@broadsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: 
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> We added the ability for a proxy to reject a request if the 
> session timer
> was too low. Consider the case of a UAC A, two proxies B and 
> C, and UAS D. A
> sends an INVITE, with Supported: timer. It lists a value of 1 
> hour. This
> hits proxy B. B feels this is too long, and wants the 30 
> minute minimum. So,
> it reduces it. That hits C. C feels this is too short, below 
> its 45 minute
> minimum. So, it rejects the request, and includes a 
> session-expires header
> with 45 minutes. 
> 
> So, A resends the request, with a session-expires of 45 
> minutes. This, once
> again, is too short for B, which reduces it to 30 minutes, 
> and passes it to
> C. C rejects it because its too long, and includes a 
> session-expires header
> with 45 minutes.
> 
> This will then continue ad-infinitum. Its also a nice DoS 
> attack in and of
> itself.
> 
> Dean raised this issue a while back. I had suggested the 
> ability of a proxy
> to increase the session-expires, and then include a header, say
> Minimum-Timer, which indicates its minimum value that no one 
> else can reduce
> it below. He pointed out that you have problems, then, if two 
> proxies have
> non-overlapping preferences. Well, we still have that 
> problem. The result of
> the 422 rejection response is that proxies can, effectively, 
> increase the
> value of the session timer, so the same problem arises.
> 
> The only sensible out that I see is to add back this 
> Minimum-Timer header. A
> UAC, when it gets a 422 Session Timer too small, remembers 
> the value of the
> Session-Expires in that response. It stores the largest value 
> returned in
> any 422 for the call leg in question. In any re-invites with 
> session timers,
> the UAC includes a Minimum-Timer header with this value. A 
> proxy MUSTNOT
> reduce the session timer below this value. 
>

Using the 422 and Minimum-Timer sounds fine with 
me.  It solves the problem while allowing for 
Session-Expires negotiation.

The header name is also ok since the option-tag 
for the draft is "timer".  Minimum-Session-Expires 
seems a little more precise, but it is little 
longer.

Intentional or not, the solution reduces the 
possibility of smaller Session-Expires values 
that might want to be used in pre-paid services 
through proxies.  However I guess that it is 
better than adding a parameter to
Session-Expires to indicate that the session 
will not or cannot be extended; thus please 
allow this small value.  The parameter would
also guarantee faster cleanup of sessions known 
to be of a predetermined short length.

> I welcome any other suggestions....
> 
> Another requirement for this to work is that, when a UA refreshes, it
> inserts a session-expres with the same timer as the previous 
> successful
> re-INVITE, unless it explicitly wishes to disable session 
> timers. Without
> that, the smurf attack is still possible! Thats because, if 
> each re-invite
> doesn't contain the last session timer, no request will actually ever
> contain a session-expires, and so there is no opportunity for 
> a proxy in
> front of the attacking proxy to reject the low values inserted by the
> attacking proxy!

I'm not sure that I understand your reasoning 
for requiring the same Session-Expires for 
re-INVITEs that were in the previous INVITE.  
Can't the whole renegotiation process take 
place again among the entities that stayed 
in the route?  This would force the smurf 
requesting small values to stay in the route.  
If you are suggesting the use of the same 
Minimum-Timer header to avoid the 422's, I agree.


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


From sip-admin@ietf.org  Thu Jun 21 20:48:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22266;
	Thu, 21 Jun 2001 20:48:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA23424;
	Thu, 21 Jun 2001 20:42:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA23335
	for ; Thu, 21 Jun 2001 20:42:29 -0400 (EDT)
Received: from yourwebsite.com (24.100.115.107.on.wave.home.com [24.100.115.107])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22113
	for ; Thu, 21 Jun 2001 20:41:48 -0400 (EDT)
From: TimeForAChange@real.com
Message-Id: <200106220041.UAA22113@ietf.org>
Reply-To: kchmystery@yahoo.com
To: sip@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Thu, 21 Jun 2001 20:40:19 -0400
Subject: [Sip] Don't take my word for it
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Earn up to $500K in 120 Days Sending Email!!
> 

________________________________________________________________________________
Note
Transmissions to you by the sender of 'this' email will be stopped promptly by sending an e-mail with 
"unsubscribe" in the subject line. Simply hit reply and send and we will remove you from our database. 
Please Note-This is a one time mailing.Thank you.
________________________________________________________________________________

> 
>Excuse us for bothering you but we would like to share our 
>good luck with everybody. 
> 
>My wife received this e-mail and forwarded it to me to review. 
>We've both read completely through it and have been in contact 
>with some of the individuals listed below. 
> 
>We think it's an excellent opportunity that is well worth the small 
>investment of time and money, and believe that you will, too! 
> 
> 
>===== PRINT THIS NOW FOR YOUR FUTURE REFERENCE ====== 
>If you would like to make at least $500,000 every 4 to 5 months easily and 
>comfortably, please read the following... 
> 
>THEN READ IT AGAIN and AGAIN!!! 
> 
> 
>FOLLOW THE SIMPLE INSTRUCTIONS BELOW AND YOUR FINANCIAL 
>DREAMS WILL COME TRUE, GUARANTEED! 
> 
>INSTRUCTIONS: 
>Order all 5 reports shown on the list below 
> 
>For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT 
>YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose 
>name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN 
>ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail 
>problems. 
> 
>When you place your order, make sure you order each of the 5 reports. 
> 
> 
>You will need all 5 reports so that you can save them on your computer 
>and resell them. YOUR TOTAL COST $5 X 5=$25.00. 
> 
>Within a few days you will receive, vie e-mail, each of the 5 re ports from 
>these 5 different individuals. Save them on your computer so they will be 
>accessible for you to send to the 1,000's of people who will order them 
>from you. Also make a floppy of these reports and keep it on your desk in 
>case something happens to your computer. 
> 
> 
>IMPORTANT - DO NOT alter the names of the people who are listed next 
>to each report, or their sequence on the list, in any way other than what is 
>instructed below in step '' 1 through 6 '' or you will loose out on a 
>majority of your profits. Once you understand the way this works, 
>you will also see how it does not work if you change it. Remember, 
>this method has been tested, and if altered, it will NOT work !!! 
>People have tried to put their friends/relatives names on all five thinking 
>they could get all the money. But it does not work this way. Believe us, 
>and Do Not try to change anything other than what is instructed. If you do, 
>it will not work for you. 
>Remember, honesty reaps the reward!!! 
> 
> 
> 
> 
> 
>1.... After you have ordered all 5 reports, take this advertisement and 
>REMOVE the name & address of the person in REPORT # 5. This person 
>has made it through the cycle and is no doubt counting their fortune 
> 
> 
>2....Move the name & address in REPORT # 4 down toREPORT # 5. 
> 
> 
>3....Move the name & address in REPORT # 3 down TO REPORT # 4. 
> 
> 
>4....Move the name & address in REPORT # 2 downTO REPORT # 3. 
> 
> 
>5.... Move the name & address in REPORT # 1 down TO REPORT # 2 
> 
> 
>6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE 
>SURE you copy every name & address ACCURATELY! 
>****Take this entire letter, with the modified list of names, and save it on 
>your computer. DO NOT MAKE ANY OTHER CHANGES. 
> 
> 
>Save this on a disk as well, just in case you loose any data. To assist you 
>with marketing your business on the internet, the 5 reports you purchase 
>will provide you with invaluable marketing information which includes how 
>to send bulk e-mails legally, where to find thousands of free classified ads 
>and much more. 
> 
> 
>There are 2 Primary methods to get this venture going: 
> 
> 
>METHOD # 1:BY SENDING BULK E-MAIL LEGALLY 
> 
>Let's say that you decide to start small, just to see how it goes, and we 
>Will assume you and those involved send out only 5,000 e-mails each. Let's 
>also assume that the mailing receive only a 0.2% response (the response 
>could be much better but lets just say it is only 0.2%. Also many people 
>will send out hundreds of thousands e-mails instead of only 5,000 each). 
>Continuing with this example, you send out only 5,000 e-mails. With a 0.2% 
>response, that is only 10 orders for report # 1. Those 10 people responded 
>by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 
>e-mails only 0.2% responded with orders. That's=100 people responded and 
>ordered Report # 2. 
> 
> 
>Those 100 people mail out 5,000 e-mails each for a total of 500,000 
>e-mails. The 0.2% response to that is 1000 orders for Report # 3. 
> 
> 
>Those 1000 people send out 5,000 e-mails each for a total of 5 million 
>e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 
>4. 
> 
> 
>Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 
>(50 million) e-mails. 
> 
> 
> 
>The 0.2% response to that is 100,000 orders for Report # 5 
> 
> THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). 
>Your total income in this example is: 1..... $50 + 2..... $500 + 3..... 
>$5,000 + 4 .... $50,000 + 5..... $500,000 ........ Grand Total=$555,550.00 
> 
> 
>NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT 
>THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU 
>CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! 
> 
> 
> 
>REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE 
>ORDERING OUT OF 5,000 YOU MAILED TO. 
> 
>Dare to think for a moment what would happen if everyone or half or even 
>one 4th of those people mailed 100,000 e-mails each or more? There are 
>over 150 million people on the Internet worldwide and counting. Believe me, 
>many people will do just that, and more! 
> 
> 
> 
>METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET 
>Advertising on the net is very very inexpensive and there are hundreds 
>of FREE places to advertise. Placing a lot of free ads on the Internet will 
>easily get a larger response. We strongly suggest you start with Method # 1 
>and add METHOD # 2 as you go along. For every $5 you receive, all you 
>must do is e-mail them the Report they ordered. That's it. Always provide 
>same day service on all orders. 
> 
>This will guarantee that the e-mail they send out, with your name and 
>address on it, will be prompt because they can not advertise until they 
>receive the report. 
> 
> 
>========= AVAILABLE REPORTS ============= 
>ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: 
> 
>============================================== 
>Always send $5 cash (U.S. CURRENCY only) for each Report. 
> 
>Checks NOT accepted. 
>Make sure the cash is concealed by wrapping it in at least 2 sheets 
>of paper. 
> 
> On one of those sheets of paper, Write 
> 
> a.The NUMBER & the NAME of the Report 
> 
> you are ordering, 
> 
> b. YOUR E-MAIL ADDRESS and 
> 
> c. your name and postal address. 
> 
> (In case of mail difficulties.) 
> 
> 
>PLACE YOUR ORDER FOR THESE REPORTS NOW : 
> 
>REPORT # 1: "The Insider's Guide to Advertising for Free on the Net" 
>Order Report #1 from: 
>Kerry G. 
>PO Box 210132 
>San Francisco, CA 94121 
>USA 
>_________________________________________________________ 
>REPORT # 2: "The Insider's Guide to Sending Bulk e-mail on the Net" 
>Order Report # 2 from: 
>P.Harry 
>P.O. Box 470015 
>Brooklyn, NY 11247 
> USA 
>__________________________________________________________ 
>REPORT # 3: "Secret to Multi-Level Marketing on the Net" 
>Order Report # 3 from: 
>Mary Morgan 
>12 Condotti Drive 
>Woodbridge, Ontario, L4H 2C8 
>Canada 
>__________________________________________________________ 
>REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net" 
>Order Report # 4 from: 
>D. Harris 
>6717 Main Street 
>Stouffville, ON L4A 6B3 
>Canada 
>__________________________________________________________ 
>REPORT #5: "How to Send Out One Million e-mails for Free" 
>Order Report # 5 from: 
>Christa H 
>6021 Yonge Street, Ste. 1021
>Toronto, ON M2M 3W2 
>Canada
> 
>_________________________________________________________ 
>You can KEEP TRACK of your PROGRESS by watching which report 
>people are ordering from you. IF YOU WANT TO GENERATE MORE 
>INCOME SEND ANOTHER BATCH OF E-MAILS AND START 
>THE WHOLE PROCESS AGAIN. 
>_________________________________________________________ 
>$$$$$$$$$YOUR SUCCESS GUIDELINES $$$$$$$$$$$ 
> 
> 
>Follow these guidelines to guarantee your success: 
> 
> 
>=== If you do not receive at least 10 orders for Report #1 within 2 
>weeks, continue sending e-mails until you do. 
> 
> 
>=== After you have received 10 orders, 2 to 3 weeks after that you 
>should receive 100 orders or more for REPORT # 2. If you did not, 
>continue advertising or sending e-mails until you do. 
> 
> 
>=== Once you have received 100 or more orders for Report # 2, YOU 
>CAN RELAX, because the system is already working for you, and the 
>cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: 
>Every time your name is moved down on the list, you are placed in front 
>of a Different report. 
> 
> 
>There is NO LIMIT to the income you can generate from this business !!! 
> 
> 
>=============================================== 
> 
> 
>FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS 
>PROGRAM: 
> 
>You have just received information that can give you 
>financial freedom for the rest of your life, with NO RISK and JUST 
>A LITTLE BIT OF EFFORT. You can make more money in the next 
>few weeks and months than you have ever imagined. Follow the program 
>EXACTLY AS INSTRUCTED. Do Not change it in any way. It works 
>exceedingly well as it is now. 
> 
> 
>Remember to e-mail a copy of this exciting report after you have put 
>your name and address in Report #1 and moved others to #2 ..........# 5 
>as instructed above. One of the people you send this to may send out 
>100,000 or more e-mails and your name will be on every one of them. 
>Remember though, the more you send out the more potential customers 
>you will reach. 
> 
> 
>So my friend, I have given you the ideas, information, materials and 
>opportunity to become financially independent. IT IS UP TO YOU NOW ! 
> 
> 
>============ TESTIMONIALS ================ 
> 
>This is what one had to say: ''Thanks to this profitable opportunity. I 
>was approached many times before but each time I passed on it. I am 
>so glad I finally joined just to see what one could expect in return for the 
>minimal effort and money required. 
> 
>To my astonishment, I received total $610,470.00 in 21 weeks, 
>with money still coming in." 
>Pam Hedland, Fort Lee, New Jersey 
> 
> 
>Here is another testimonial: 
> 
>"This program has been around for a long time but I never believed 
>in it. But one day when I received this again in the mail I decided to 
>gamble my $25 on it. I followed the simple instructions and walaa 
>..... 3 weeks later the money started to come in. 
> 
>First month I only made $240.00 but the next 2 months after that I made 
>a total of $290,000.00. So far, in the past 8 months by re-entering the 
>program, I have made over $710,000.00 and I am playing it again. The 
>key to success in this program is to follow the simple steps and NOT change 
>anything.'' 
> 
> 
>"My name is Mitchell. My wife, Jody and I live in Chicago. I am an 
>accountant with a major U.S. Corporation and I make pretty good money. 
>When I received this program I grumbled to Jody about receiving ''junk 
>mail''. I made fun of the whole thing, spouting my knowledge of the 
>population and percentages involved. I ''knew'' it wouldn't work. 
>Jody totally ignored my supposed intelligence and a few days later 
>she jumped in with both feet. 
> 
>I made merciless fun of her, and was ready to lay the old ''I told you so'' on 
>her when the thing didn't work. Well, the laugh was on me! Within 3 weeks 
>she had received 50 responses. Within the next 45 days she had received 
>total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody 
>in her ''hobby''. 
> 
>Mitchell Wolf M.D., Chicago, Illinois 
> 
>================================================ 
> 
> 
>''Not being the gambling type, it took me several weeks to make up my 
>mind to participate in this plan. But conservative that I am, I decided that 
>the initial investment was so little that there was just no way that I 
>wouldn't get enough orders to at least get my money back''. '' I was 
>surprised when I found my medium size post office box crammed with 
>orders. I made $319,210.00 in the first 12 weeks. The nice thing about 
>this deal is that it does not matter where people live. There simply isn't a 
>better investment with a faster return and so big." 
>Dan Sondstrom, Alberta, Canada 
> 
> 
>================================================ 
>''I had received this program before. I deleted it, but later I wondered 
>if I should have given it a try. Of course, I had no idea who to contact to 
>get another copy, so I had to wait until I was e-mailed agai n by someone 
>else.........11 months passed then it luckily came again...... I did not 
>delete this one! I made more than $490,000 on my first try and all the 
>money came within 22 weeks." 
>Susan De Suza, New York, N.Y. 
> 
> 
>================================================= 
> 
> 
>''It really is a great opportunity to make relatively easy money with 
>little cost to you. I followed the simple instructions carefully and 
>within 10 days the money started to come in. My first month I made 
>$20,560.00 and by the end of third month my total cash count was 
>$362,840.00. Life is beautiful, Thanks to internet.". 
>Fred Dellaca, Westport, New Zealand 
> 
> 
>================================================= 
>ORDER YOUR REPORTS TODAY AND GET STARTED ON 
>'YOUR' ROAD TO FINANCIAL FREEDOM ! 
>================================================= 
> 
> 
>About 50,000 new people get online every month! 
>_______________________________________________________ 
> 
> 
> 
> 
>FOR YOUR INFORMATION.... 
>If you need help with starting a business, registering a business name, 
>learning how income tax is handled, etc., contact your local office of the 
>Small Business Administration (a Federal agency) 1-(800)827-5722 for free 
>help and answers to questions. Also, the Internal Revenue Service offers 
>free help via telephone and free seminars about business tax requirements. 
> 
>Under Bill S1618 Title III passed by the 105th US Congress this letter 
>cannot be considered spam as long as the sender includes contact 
>information 
>and a method of removal. This is a one-time e-mail transmission. No request 
>for removal is necessary. 
> 
>If you have any questions of the legality of this program, contact the 
>Office of Associate Director for Marketing Practices, Federal Trade 
>Commission, Bureau of Consumer Protection, Washington, D.C. 
> 
> 


Transmissions to you by the sender of 'this' email will be stopped promptly by sending an e-mail with 
"unsubscribe" in the subject line. Simply hit reply and send and we will remove you from our database. 
Please Note-This is a one time mailing.Thank you.


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


From sip-admin@ietf.org  Thu Jun 21 22:24:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25159;
	Thu, 21 Jun 2001 22:24:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA26756;
	Thu, 21 Jun 2001 22:16:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA26727
	for ; Thu, 21 Jun 2001 22:16:47 -0400 (EDT)
Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24933
	for ; Thu, 21 Jun 2001 22:16:07 -0400 (EDT)
Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.2) id f5M2GhS84379; Thu, 21 Jun 2001 22:16:43 -0400 (EDT)
Reply-To: 
From: "Brett Tate" 
To: "'Jonathan Rosenberg'" , 
Subject: RE: [SIP] draft-ietf-sip-session-timer-04: INVITE with Require and Support timer and Session-Expires
Date: Thu, 21 Jun 2001 22:19:51 -0400
Message-ID: <002d01c0fac1$d21b4ad0$2b01a8c0@broadsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: 
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan, 

Thanks for the response.  Comments inline.

> > What should happen if a UAC sends an INVITE 
> > with Session-Expires and both Supported timer 
> > and Require timer?
> 
> The Require implies Supported, so the behavior would be 
> identical to the
> case where just Require were present. This is probably an issue best
> addressed in the Supported header specification, since its 
> more general than
> session timer.

The "Require implies Supported" needs to be 
reflected in the timer draft since Table 3 
is otherwise misleading if UAC includes 
Require timer with session-expires without 
Supported timer.

If a UAC both requires and supports an option-tag, 
should it include it in both headers?  

Isn't the "require implies supported" going to limit 
devices that want to require others to support an 
extension without them actually supporting it?

> > 
> > What should happen if the UAS responds to such 
> > a request and includes the same the three 
> > headers and values?  Are both now effectively 
> > responsible for sending refreshes?  Or is the 
> > UAS forbidden from sending such a response?
> 
> These are good questions. A lot of it depends on what we mean 
> when Require
> is placed in the request. In principal, its quite useless. 
> Require normally
> means "don't process the request unless you understand the 
> extension". But,
> session timer works just fine even if the UAS doesn't support 
> the extension.
> So, based on this definition, inserting it has zero meaning. 
> However, one
> might think that Require in the INVITE means, "UAS, you should do the
> refreshes". 
> 
> I'm inclined to be consistent with normal Require usage. In 
> this case, the
> presence of Require in the INVITE has no impact on processing 
> at the UAS if
> it supports the extension. UAC will do the refreshes. If the 
> UAC wants the
> UAS to do them, the UAC can insert the Session-Timer header, but not a
> Supported header. This will result in the UAS doing them if 
> it supports it,
> otherwise there won't be session timers. 

Sounds fine.

It has some restrictions since the Supported 
and Require headers are still being used to indicate 
who is refreshing instead of what is supported 
and required.  However without an extra parameter 
in Session-Expires to indicate who is refreshing, 
I can't think of a better solution.

Actually the same parameter could be used to allow 
for smaller Session-Expires values which are not to 
be refreshed.

Session-Expires  =  
  ("Session-Expires" | "x") ":" 
              ( SIP-date | delta-seconds ) [refresher]

refresher = ";" "refresher" "=" "uas"|"uac"|"none"


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


From sip-admin@ietf.org  Fri Jun 22 03:56:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14329;
	Fri, 22 Jun 2001 03:56:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12842;
	Fri, 22 Jun 2001 03:51:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12809
	for ; Fri, 22 Jun 2001 03:51:10 -0400 (EDT)
Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14301
	for ; Fri, 22 Jun 2001 03:50:35 -0400 (EDT)
Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca
          via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 22 Jun 2001 08:51:00 UT
Received: (private information removed)
Message-ID: <3B32F76D.35AAB942@ubiquity.net>
From: James Undery 
To: Jonathan Rosenberg 
Cc: aki.niemi@nokia.com, corey@hearme.com, sip@ietf.org
Subject: Re: [Sip] Request header integrity in HTTP Digest
Date: Fri, 22 Jun 2001 03:44:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: James Undery [mailto:jundery@ubiquity.net]
> > Sent: Thursday, June 21, 2001 3:40 AM
> > To: Jonathan Rosenberg
> > Cc: aki.niemi@nokia.com; corey@hearme.com; sip@ietf.org
> > Subject: Re: [Sip] Request header integrity in HTTP Digest
> >
> >
> > > The only thing thats broken is your perception of the problem being
> > solved.
> >
> > That's exactly what I was getting at this approach will never
> > solve the
> > problems
> > it claims to.
>
> It solves all three replay attacks presented section 2. It won't solve the
> MITM attacks if the attacker is smart and is careful about modifying the
> request in the same way between the original one and resubmitted one.
>
> If you believe if doesn't solve the problems it claims to, please indicate
> clearly, for the three replay attacks, how these are not prevented by the
> mechanism, even though I claim they are.

You selected only cases this works for, failed to mention the myriad of
cases it
is no use at all for. By dumbing down the attacks you protect yourself from
security is easy, why not have a Forged header that attackers have to set to
true and claim you can find all forged messages that are SIP complient ;)

>
> > HTTP is totally different from SIP I have no problem at all
> > with that draft
> > Section 4 is very clear about the limitations of the draft.
>
> I am missing your point here. SIP digest is identical to http digest.
>

SIP and HTTP share a lot of the same headers, request response model
granted,
but these similarities shouldn't fool you into thinking that the protocols
are
similar. Transactions in SIP and HTTP are totally different in nature, a
security model for one does not map to a security model for the other.

>
> >
> > >
> > > The mechanism described in the draft provides a level of
> > security that is
> > > better than digest. It fixes some of the most horrible and
> > easiest to
> > launch
> > > attacks (especially the replay ones).
> >
> > UA sends a "Contact: *",  "Expires: 0" REGISTER request and
> > authenticates
> > it.
> > Bad guy sniffs the authenticated register
> > UA then sends the new contacts for the user.
> > Bad guy then replays the first message with an incremented
> > CSeq quickly.
> >
> > Common scenario, simple attack how does you draft help?
>
> Common scenario? It only works when the UA sends a Contact: * Expires: 0
and
> the re-registers with new contacts right away.

Clearing the old registrations and moving to a new location isn't a common
scenario?

> Doesn't seem that frequent a
> case at all. When would this happen in practice? The mechanism will not
> protect you from attacks where the attacker replays (but doesn't modify)
the
> request. That is a subset of the attacks possible with digest, where you
can
> replay modified requests.
>
> > I think if worsens it as Corey pointed out (and I totally
> > missed even when
> > he
> > did).
>
> Utter nonsense. Corey pointed out that the nonce should include a private
> key so that its not guessable. Guessing it doesn't help you terribly much,
> but fine, we'll do that. The same issue arises with regular digest.
>

What Corey pointed out was a rouge poxy can request a UA to register using a
nonce that it knows a second proxy will give it at some time in the future
(of
the rouge proxies choosing). If you think that is nonsense we might as well
stop
discussing any security now.

>
> I claim that this approach improves security, since it removes replay
> attacks that require modification of the message. An example is modifying
> the Contact in a REGISTER to route calls to my phone. Regular http digest
> doesn't protect against this. The pnonce does. So, if you still believe
that
> pnonce is useless, please argue that:
>
> 1. I am incorrect, and this attack is not possible with digest, or
> 2. I am incorrect, and this attack is possible with digest, but still
> possible in my proposed approach.

As pointed out before UA sends a REGISTER with contact X. Bad Guy changes X
to Y
and proxies on the request, the registrar 401 with contact Y encrypted into
the
nonce. Bad guy proxies on this response, UA sends a REGISTER with Contact X
and
credentials for Contact Y in the nonce. The bad guy changes X to Y and
forwards
to the registrar with the credentials provided by the UA. The registrar
accepts
the registration with contact Y.


>
> Continuously throwing out attacks that are still possible with pnonces
> proves nothing, and only shows that you continue to miss the point. It
only
> proves that digest, with or without pnonce, are susceptible to these. I
have
> offered, in the doc, three CONCRETE replay attacks that are prevented with
> pnonces. If you believe that this mechanism makes things worse, please
point
> out a concrete attack which is not possible in regular digest, but is now
> possible with pnonces. If you cannot offer such an attack, then your
claims
> that it fixes nothing are bogus.

UA registers with Bad guy, bad guy constructs a pnonce it knows a registrar
will
construct in an hours time using its IP address, headers the server will
protect
and the round time an hour in the future. The UA authenticates this and in
an
hour the bad guy replays the message and authenticates with the credentials
the
UA provided an hour ago.

But submitting a draft that doesn't mention you are only protected from
these
specific attacks but not more sophisticated ones youI haven't mentioned
provides
the reader with a false sense of security. This is far worse than just
pointing
out the limitations. Selling snake oil will do SIP security no favours.

James Undery


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


From sip-admin@ietf.org  Fri Jun 22 04:18:14 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14507;
	Fri, 22 Jun 2001 04:18:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13633;
	Fri, 22 Jun 2001 04:10:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13604
	for ; Fri, 22 Jun 2001 04:10:21 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14448
	for ; Fri, 22 Jun 2001 04:09:45 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5M8ALN20059
	for ; Fri, 22 Jun 2001 10:10:21 +0200 (MEST)
Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Jun 22 10:10:18 2001 +0200
Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Fri, 22 Jun 2001 10:05:47 +0200
Message-ID: <7BA41B5547CCD411833B0002A52CD457037281C1@enlrynt306.etm.ericsson.se>
From: "Arnoud van Wijk (ELN)" 
To: "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct  ser
	 v er
Date: Fri, 22 Jun 2001 10:10:19 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Yup. And that is now exactly my problem with Charging and Billing.
The signalling and the bearer traverse different nodes/servers and pathways. So, SIP is currently unreliable to obtain exact call duration.

But if some people get a great idea how to solve this problem and it requires a new SIP header. Will those people get Lynched? :-)

Just my 2 cents

Greetz

Arnoud

_______________________________________________________________
ERICSSON EUROLABS NETHERLANDS BV
Arnoud van Wijk
Innovation Unit
Research & Development (ELN/V)
Fax: +31-161 247569
_______________________________________________________________







-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: donderdag 21 jun 2001 18:51
To: 'David Schwartz'; 'Jiri Kuthan'; 'Rosen, Brian'; 'Jay Batson';
'Ashhar Farhan'; 'sip@ietf.org'
Subject: RE: [SIP] Authentication and billing through proxy/re-direct
ser v er




 

> -----Original Message-----
> From: David Schwartz [mailto:davids@deltathree.com]
> Sent: Thursday, June 21, 2001 9:30 AM
> To: 'Jiri Kuthan'; 'Rosen, Brian'; 'Jay Batson'; 'Ashhar Farhan';
> 'sip@lists.bell-labs.com'
> Subject: RE: [SIP] Authentication and billing through proxy/re-direct
> ser v er
> 
> Here to it is important to look at the pros and cons in doing 
> this in an
> internal proxy Vs. using the gateway. The big con in using 
> the proxy is that
> it causes another statefull element in the network and since 
> the VG must be
> statefull anyway why have another statefull element. In 
> addition when it
> comes to the call stop (CDR creation) there is some 
> information that might
> be needed about the user (e.g. internal username) that may 
> only be available
> from the call start response. So the typical solution is to 
> use the VG. The
> con with using the VG is that you must own the VG. If you 
> wish to terminate
> on someone elses network it can be tricky retrieving the CDR's. 
> 
> One possible stateless solution might be to use the proxy for 
> call start and
> call stop. The Record-Route header is used to ensure that the 
> proxy sees the
> BYE message. Any proxy that gets an invite generates a call start (on
> receiving the 200 OK) which writes to some file that a 
> particular callID has
> started a call at this particular time, and any proxy getting a BYE
> generates a call stop which writes to a file (potentialy on a 
> different
> machine) that a particular callID has stopped a call at a 
> different time.
> There is no state that needs to be saved. Instead, a different process
> constantly moniters these files and correlates the call 
> starts with the call
> stops. This seperate process is the one that generates the 
> CDR's. This also
> reduces the load on the VG's enabling them to focus on the 
> call setup and
> teardown.

Using a proxy to generate minutes of usage is very hard. Ultimately, the
gateway knows the call call duration, as it is the arbiter of whether the
call is still in progress with the PSTN. For proxy-based duration to work,
you need to be able to prove that the proxy is always in continuous
synchronization (in terms of call state) with the gateway, within a
reasonable time lag. So, can you prove that an attacker cannot force the
proxy and gateway to go out of sync? I know of several attacks that are
possible in order to convince the proxy that the call is down, but the
gateway that the call is up (Max-Forwards values which cause the BYE to pass
the proxy but fail at the gateway, for example). This results in free
service. Someone more creative than I might come up with a few more.

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


_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip

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


From sip-admin@lists.bell-labs.com  Fri Jun 22 09:13:37 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20185
	for ; Fri, 22 Jun 2001 09:13:37 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D511A4433E; Fri, 22 Jun 2001 09:14:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102])
	by lists.bell-labs.com (Postfix) with ESMTP id D806044336
	for ; Fri, 22 Jun 2001 09:13:58 -0400 (EDT)
Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100])
	by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id WAA04254
	for ; Fri, 22 Jun 2001 22:13:58 +0900 (JST)
	(envelope-from nakamura.hidefumi@lab.ntt.co.jp)
Received: from eclscan3.m.ecl.ntt.co.jp
	by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/03/21/01) with ESMTP id WAA21367
	for ; Fri, 22 Jun 2001 22:13:58 +0900 (JST)
	(envelope-from nakamura.hidefumi@lab.ntt.co.jp)
Received: from ime.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id WAA26905;
	Fri, 22 Jun 2001 22:13:57 +0900 (JST)
Received: from lab.ntt.co.jp (nakhidevaio.nslab.ecl.ntt.co.jp [129.60.13.249])
	by ime.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id WAA26683;
	Fri, 22 Jun 2001 22:13:57 +0900 (JST)
Message-ID: <3B33455C.A01A4E4E@lab.ntt.co.jp>
From: Hidefumi Nakamura 
X-Mailer: Mozilla 4.75 [ja] (Win98; U)
X-Accept-Language: ja
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Subject: [SIP] Congestion control
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 22 Jun 2001 22:17:16 +0900
Content-Transfer-Encoding: 7bit

Hi. all,

I have a couple of questions about the suitable way to let the user agents/
proxy-servers know the congestion of sip-proxy(stateful) or location server, 
and the suitable action after the notification.

As long as I review the sip document (rfc2543bis-03), I think
the most suitable way is to return a "503 service unavailable" message
with "Retry-after" field.  Is is correct understanding?

The other question is of the case when the INVITE request comes via
several (stateful) proxy servers.  That is, INVITE comes through

UAa --> proxy A --> proxy B --> UAb

and proxy B is in congestion.

In this case, proxy B will return a "503" message to UserAgent-a (UAa)
via proxy A if my understanding of the first question is correct.   UAa
will postpone to send a message to proxy A, but what should "proxy A"
do if it receives other INVITE messages for proxyB, say, from UAc, within
the period indicated in "retry-after" field?
Should proxy-A send "503" to UAc or transfer the INVITE message
to proxy-B even if proxy-A already has the information that proxy-B
is in congestion?

Please let me know.

Thanks.

---
Hidefumi NAKAMURA
NTT Network Service Systems Laboratories
tel:+81 (422)59 3904; fax:+81 (422)60 4012
---

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


From sip-admin@ietf.org  Fri Jun 22 09:57:55 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21794;
	Fri, 22 Jun 2001 09:57:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23139;
	Fri, 22 Jun 2001 09:48:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23108
	for ; Fri, 22 Jun 2001 09:48:48 -0400 (EDT)
Received: from mail.pingtel.com (IDENT:root@mail.pingtel.com [216.91.1.131])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21416
	for ; Fri, 22 Jun 2001 09:48:12 -0400 (EDT)
Received: from stbarth.pingtel.com (cdhcp117.pingtel.com [10.1.1.117])
	by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id f5MDkFd32214;
	Fri, 22 Jun 2001 09:46:20 -0400
Message-Id: <5.1.0.14.2.20010622092254.029477c0@mail.pingtel.com>
X-Sender: jbatson@mail.pingtel.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 22 Jun 2001 09:45:17 -0400
To: Gordon Ledgard , "'Dean Bogdanovic'" ,
        "'Wai Wu'" ,
        Venkatesh Venkataramanan ,
        "'Jean-Francois Mule'" ,
        "'Rohan Mahy'" , islain@cisco.com, sip@ietf.org
From: Jay Batson 
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt
In-Reply-To: <5143F854B82ED211B05E00104B235F64807BD5@commserver>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_136469382==_.ALT"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

--=====================_136469382==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Exactly.  The protocol is responsible for encoding the underlying 
information, the user agent is responsible for the "presentation" of that 
information in whatever manner is appropriate for that product.  Indicating 
that a high priority message should be displayed is different for a UA with 
no light or display, or for a UA built for deaf or blind users, or 
....  That's why we *have* distinctions between encoding and presentation 
layers.

-jb


At 02:37 PM 6/20/01, Gordon Ledgard wrote:
>Agree.
>
>There isn't anything inherently un-SIP like about providing some set of 
>common network
>or user notification features.  The danger, as Venkatesh points out, is 
>making them application
>specific, like jumping to the conclusion that I want to turn on a light, 
>or dictating how that
>notification is to be interpreted by the recieving endpoint.
>
>-----Original Message-----
>From: Dean Bogdanovic [mailto:deanb@mck.com]
>Sent: Wednesday, June 20, 2001 1:52 PM
>To: 'Wai Wu'; 'Jay Batson'; Venkatesh Venkataramanan; 'Jean-Francois 
>Mule'; 'Rohan Mahy'; islain@cisco.com; sip@lists.bell-labs.com
>Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt
>
>Wai
>I would disagree with you. Audio/visual notifications are important to end 
>user and I belive giving some extensions to SIP will help the adoption by 
>the endusers. As Jay had mentioned it
>
>
>Regards
>
>Dean Bogdanovic
>MCK Communications
>phone:(617)454 6165
>fax:(617)454 6101
>___________________
>"the answer is 42"
>
>-----Original Message-----
>From: Wai Wu [mailto:wwu@calltrol.com]
>Sent: Wednesday, June 20, 2001 10:40 AM
>To: 'Jay Batson'; Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan 
>Mahy'; islain@cisco.com; sip@lists.bell-labs.com
>Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt
>
>I think features normally found on a PBX phone (e.g. message waiting) 
>shouldn't be part of SIP at all. If we put all these things in SIP, it 
>will make SIP not much different from a "standardized PBX protocol".
>-----Original Message-----
>From: Jay Batson [mailto:jbatson@pingtel.com]
>Sent: Tuesday, June 19, 2001 3:37 PM
>To: Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan Mahy'; 
>islain@cisco.com; sip@lists.bell-labs.com
>Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt
>
>My comments aren't timely, so my apologies.
>
>Venkatesh's comments are also consistent with typical IETF protocol / 
>application design.  Example:  Neither SMTP nor POP/IMAP specify how the 
>email "user agent" (Eudora, Netscape, Outlook) provides visual indication 
>of email message priority (X-Priority).
>
>The creator of a given user agent defines its own user interfaces to 
>information that is provided in the standardized lower later 
>protocol.  End users then choose among available user agents (and 
>behaviors) to get their desired interaction.
>
>Applications at either end of a transaction may want to agree on 
>Experimental extensions to show more information, such as the type that 
>Jean-Francois suggests.  In fact, this is how X-Priority came into being 
>in email!  Eudora just up and did it one day, and everybody else did what 
>they did!
>
>-jb
>
>
>
>At 03:29 PM 4/26/01, Venkatesh Venkataramanan wrote:
>>I would think that the functionality of SIP ends when it delivers the
>>requested Notification. What the phone/the entity does with it(light a lamp,
>>render the same on a display, provide stutter dial tone or audible
>>notification et al) is more a matter of the local policy (depending upon the
>>capabilities of the end point).
>>
>>Venkatesh
>>
>>-----Original Message-----
>>From: Jean-Francois Mule [mailto:jfmule@clarent.com]
>>Sent: Thursday, April 26, 2001 12:42 AM
>>To: 'Rohan Mahy'; islain@cisco.com; sip@lists.bell-labs.com
>>Subject: [SIP] draft-mahy-sip-message-waiting-01.txt
>>
>>
>>
>>Hi,
>>The I-D mentions audible/visual message waiting indications in the
>>introduction but then remains silent on this.
>>Has there been any considerations to include the type of mwi
>>(audible/visual) as optional in application/simple-message-summary?
>>Jean-Francois Mule.
>>Clarent
>>
>>_______________________________________________
>>This list is for continuing development of the SIP protocol.
>>The sip-implementor's list is the place to discuss implementation,
>>and to receive advice on understanding existing sip.
>>To subscribe to it, send mail to
>>sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
>>
>>
>>
>>_______________________________________________
>>This list is for continuing development of the SIP protocol.
>>The sip-implementor's list is the place to discuss implementation,
>>and to receive advice on understanding existing sip.
>>To subscribe to it, send mail to
>>sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
>-------------
>PingMe!
>Jay Batson
>CEO
>Pingtel Corp.
>mailto:jbatson@pingtel.com
>781-938-5306 (office)

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


--=====================_136469382==_.ALT
Content-Type: text/html; charset="us-ascii"


Exactly.  The protocol is responsible for encoding the underlying
information, the user agent is responsible for the
"presentation" of that information in whatever manner is
appropriate for that product.  Indicating that a high priority
message should be displayed is different for a UA with no light or
display, or for a UA built for deaf or blind users, or ....  That's
why we *have* distinctions between encoding and presentation
layers.


-jb




At 02:37 PM 6/20/01, Gordon Ledgard wrote:


Agree.

 

There isn't anything inherently
un-SIP like about providing some set of common network

or user notification
features.  The danger, as Venkatesh points out, is making them
application

specific, like jumping to the
conclusion that I want to turn on a light, or dictating how
that

notification is to be
interpreted by the recieving endpoint.

 



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

From: Dean Bogdanovic
[mailto:deanb@mck.com]

Sent: Wednesday, June 20, 2001 1:52 PM

To: 'Wai Wu'; 'Jay Batson'; Venkatesh Venkataramanan;
'Jean-Francois Mule'; 'Rohan Mahy'; islain@cisco.com;
sip@lists.bell-labs.com

Subject: RE: [SIP] 
draft-mahy-sip-message-waiting-01.txt




Wai

I would disagree with you. Audio/visual notifications are important
to end user and I belive giving some extensions to SIP will help the
adoption by the endusers. As Jay had mentioned it

 




Regards 




Dean Bogdanovic 

MCK Communications 

phone:(617)454 6165 

fax:(617)454 6101 

___________________ 

"the answer is 42" 




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

From: Wai Wu
[mailto:wwu@calltrol.com]

Sent: Wednesday, June 20, 2001 10:40 AM

To: 'Jay Batson'; Venkatesh Venkataramanan; 'Jean-Francois Mule';
'Rohan Mahy'; islain@cisco.com; sip@lists.bell-labs.com

Subject: RE: [SIP] 
draft-mahy-sip-message-waiting-01.txt




I think features normally found on a PBX phone (e.g. message waiting)
shouldn't be part of SIP at all. If we put all these things in SIP, it
will make SIP not much different from a "standardized PBX
protocol". 

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

From: Jay Batson
[mailto:jbatson@pingtel.com]

Sent: Tuesday, June 19, 2001 3:37 PM

To: Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan Mahy';
islain@cisco.com; sip@lists.bell-labs.com

Subject: RE: [SIP] 
draft-mahy-sip-message-waiting-01.txt




My comments aren't timely, so my apologies.




Venkatesh's comments are also consistent with typical IETF protocol /
application design.  Example:  Neither SMTP nor POP/IMAP
specify how the email "user agent" (Eudora, Netscape, Outlook)
provides visual indication of email message priority
(X-Priority).




The creator of a given user agent defines its own user interfaces to
information that is provided in the standardized lower later
protocol.  End users then choose among available user agents (and
behaviors) to get their desired interaction.




Applications at either end of a transaction may want to agree on
Experimental extensions to show more information, such as the type that
Jean-Francois suggests.  In fact, this is how X-Priority came into
being in email!  Eudora just up and did it one day, and everybody
else did what they did!




-jb







At 03:29 PM 4/26/01, Venkatesh Venkataramanan
wrote:


I would think that the functionality of SIP ends when it delivers
the

requested Notification. What the phone/the entity does with it(light
a lamp,

render the same on a display, provide stutter dial tone or audible

notification et al) is more a matter of the local policy (depending
upon the

capabilities of the end point).




Venkatesh




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

From: Jean-Francois Mule
[mailto:jfmule@clarent.com]

Sent: Thursday, April 26, 2001 12:42 AM

To: 'Rohan Mahy'; islain@cisco.com; sip@lists.bell-labs.com

Subject: [SIP] draft-mahy-sip-message-waiting-01.txt







Hi,

The I-D mentions audible/visual message waiting indications in the

introduction but then remains silent on this.

Has there been any considerations to include the type of mwi

(audible/visual) as optional in application/simple-message-summary?

Jean-Francois Mule.

Clarent




_______________________________________________

This list is for continuing development of the SIP protocol.

The sip-implementor's list is the place to discuss implementation,

and to receive advice on understanding existing sip.

To subscribe to it, send mail to 

sip-implementors-request@cs.columbia.edu with "subscribe"
in the body.







_______________________________________________

This list is for continuing development of the SIP protocol.

The sip-implementor's list is the place to discuss implementation,

and to receive advice on understanding existing sip.

To subscribe to it, send mail to 

sip-implementors-request@cs.columbia.edu with "subscribe"
in the body.


-------------

PingMe!

Jay Batson

CEO

Pingtel Corp.

mailto:jbatson@pingtel.com

781-938-5306 (office)




-------------

PingMe!

Jay Batson

CEO

Pingtel Corp.

mailto:jbatson@pingtel.com

781-938-5306 (office)




--=====================_136469382==_.ALT--


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


From sip-admin@ietf.org  Fri Jun 22 09:57:57 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21807;
	Fri, 22 Jun 2001 09:57:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23196;
	Fri, 22 Jun 2001 09:50:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23167
	for ; Fri, 22 Jun 2001 09:50:00 -0400 (EDT)
Received: from gatekeeper.calltrol.com (root@[65.105.250.35])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21468
	for ; Fri, 22 Jun 2001 09:49:24 -0400 (EDT)
Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253])
	by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id JAA02374;
	Fri, 22 Jun 2001 09:49:34 -0400
Received: by NT-SERVER with Internet Mail Service (5.5.2448.0)
	id ; Fri, 22 Jun 2001 09:52:15 -0400
Message-ID: <60A9CA50081AD4118BD60040F60C1A9F0A3DC5@NT-SERVER>
From: Wai Wu 
To: "'Ashhar Farhan'" , jdrosen@dynamicsoft.com,
        Brian.Rosen@marconi.com, kuthan@fokus.gmd.de, sip@ietf.org
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	 er
Date: Fri, 22 Jun 2001 09:52:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FB22.8AF042E0"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FB22.8AF042E0
Content-Type: text/plain;
	charset="iso-8859-1"

this is very impolite

-----Original Message-----
From: Ashhar Farhan [mailto:afarhan@rediffmail.com]
Sent: Wednesday, June 20, 2001 11:50 PM
To: jdrosen@dynamicsoft.com; Brian.Rosen@marconi.com;
kuthan@fokus.gmd.de; sip@ietf.org
Subject: Re: [SIP] Authentication and billing through proxy/re-direct
serv er


jdrosen wrote -
>> I think people know my opinion on standardizing all the services on might
offer... horrible idea. 
then you should oppose the very idea of sdp, and even sip.
- farhan@hotfoon.com



_____________________________________________________
Buy Lagaan & Yaadein music for 30% less.
Avail this special offer at
http://shopping.rediff.com/shopping/music/offerrediffmailer.htm 




_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip

------_=_NextPart_001_01C0FB22.8AF042E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Authentication and billing through proxy/re-direct =
serv er




this is very impolite




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

From: Ashhar Farhan [mailto:afarhan@rediffmail.com=
]

Sent: Wednesday, June 20, 2001 11:50 PM

To: jdrosen@dynamicsoft.com; =
Brian.Rosen@marconi.com;

kuthan@fokus.gmd.de; sip@ietf.org

Subject: Re: [SIP] Authentication and billing =
through proxy/re-direct

serv er






jdrosen wrote -

>> I think people know my opinion on =
standardizing all the services on might offer... horrible idea. 

then you should oppose the very idea of sdp, and =
even sip.

- farhan@hotfoon.com








_____________________________________________________

Buy Lagaan & Yaadein music for 30% less.

Avail this special offer at http://shopping.rediff.com/shopping/music/offerrediffm=
ailer.htm 










_______________________________________________

Sip mailing list

Sip@ietf.org

http://www.ietf.org/mailman/listinfo/sip





------_=_NextPart_001_01C0FB22.8AF042E0--

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


From sip-admin@ietf.org  Fri Jun 22 10:24:55 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22805;
	Fri, 22 Jun 2001 10:24:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24079;
	Fri, 22 Jun 2001 10:14:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23992
	for ; Fri, 22 Jun 2001 10:14:22 -0400 (EDT)
Received: from gatekeeper.calltrol.com (root@[65.105.250.35])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22404
	for ; Fri, 22 Jun 2001 10:13:45 -0400 (EDT)
Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253])
	by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id KAA02386;
	Fri, 22 Jun 2001 10:13:51 -0400
Received: by NT-SERVER with Internet Mail Service (5.5.2448.0)
	id ; Fri, 22 Jun 2001 10:16:32 -0400
Message-ID: <60A9CA50081AD4118BD60040F60C1A9F0A3DC6@NT-SERVER>
From: Wai Wu 
To: "'Jay Batson'" ,
        Gordon Ledgard
	 ,
        "'Dean Bogdanovic'" , Wai Wu
	 ,
        Venkatesh Venkataramanan
	 ,
        "'Jean-Francois Mule'"
	 ,
        "'Rohan Mahy'" , islain@cisco.com, sip@ietf.org
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt
Date: Fri, 22 Jun 2001 10:16:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FB25.EFF2C240"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FB25.EFF2C240
Content-Type: text/plain;
	charset="iso-8859-1"

I think audio/video info can be done completely without sip, such as having
the device pulling its messaging server via HTTP. It is difficult to define
a set of COMMON features. Some common features on the PBX I am using
includes speed dials, macro programming of speed dial key, and shows the
number of new and old messages I have. 

-----Original Message-----
From: Jay Batson [mailto:jbatson@pingtel.com]
Sent: Friday, June 22, 2001 6:45 AM
To: Gordon Ledgard; 'Dean Bogdanovic'; 'Wai Wu'; Venkatesh Venkataramanan;
'Jean-Francois Mule'; 'Rohan Mahy'; islain@cisco.com; sip@ietf.org
Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt


Exactly.  The protocol is responsible for encoding the underlying
information, the user agent is responsible for the "presentation" of that
information in whatever manner is appropriate for that product.  Indicating
that a high priority message should be displayed is different for a UA with
no light or display, or for a UA built for deaf or blind users, or ....
That's why we *have* distinctions between encoding and presentation layers.

-jb


At 02:37 PM 6/20/01, Gordon Ledgard wrote:


Agree.
 
There isn't anything inherently un-SIP like about providing some set of
common network
or user notification features.  The danger, as Venkatesh points out, is
making them application
specific, like jumping to the conclusion that I want to turn on a light, or
dictating how that
notification is to be interpreted by the recieving endpoint.
  


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

From: Dean Bogdanovic [ mailto:deanb@mck.com  ] 

Sent: Wednesday, June 20, 2001 1:52 PM 

To: 'Wai Wu'; 'Jay Batson'; Venkatesh Venkataramanan; 'Jean-Francois Mule';
'Rohan Mahy'; islain@cisco.com; sip@lists.bell-labs.com 

Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt



Wai 

I would disagree with you. Audio/visual notifications are important to end
user and I belive giving some extensions to SIP will help the adoption by
the endusers. As Jay had mentioned it 



  

Regards 



Dean Bogdanovic 

MCK Communications 

phone:(617)454 6165 

fax:(617)454 6101 

___________________ 

"the answer is 42" 



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

From: Wai Wu [ mailto:wwu@calltrol.com  ] 

Sent: Wednesday, June 20, 2001 10:40 AM 

To: 'Jay Batson'; Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan
Mahy'; islain@cisco.com; sip@lists.bell-labs.com 

Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt



I think features normally found on a PBX phone (e.g. message waiting)
shouldn't be part of SIP at all. If we put all these things in SIP, it will
make SIP not much different from a "standardized PBX protocol". 

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

From: Jay Batson [ mailto:jbatson@pingtel.com  ]


Sent: Tuesday, June 19, 2001 3:37 PM 

To: Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan Mahy';
islain@cisco.com; sip@lists.bell-labs.com 

Subject: RE: [SIP] draft-mahy-sip-message-waiting-01.txt



My comments aren't timely, so my apologies.



Venkatesh's comments are also consistent with typical IETF protocol /
application design.  Example:  Neither SMTP nor POP/IMAP specify how the
email "user agent" (Eudora, Netscape, Outlook) provides visual indication of
email message priority (X-Priority).



The creator of a given user agent defines its own user interfaces to
information that is provided in the standardized lower later protocol.  End
users then choose among available user agents (and behaviors) to get their
desired interaction.



Applications at either end of a transaction may want to agree on
Experimental extensions to show more information, such as the type that
Jean-Francois suggests.  In fact, this is how X-Priority came into being in
email!  Eudora just up and did it one day, and everybody else did what they
did!



-jb





At 03:29 PM 4/26/01, Venkatesh Venkataramanan wrote: 


I would think that the functionality of SIP ends when it delivers the 

requested Notification. What the phone/the entity does with it(light a lamp,


render the same on a display, provide stutter dial tone or audible 

notification et al) is more a matter of the local policy (depending upon the


capabilities of the end point).



Venkatesh



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

From: Jean-Francois Mule [ mailto:jfmule@clarent.com
 ] 

Sent: Thursday, April 26, 2001 12:42 AM 

To: 'Rohan Mahy'; islain@cisco.com; sip@lists.bell-labs.com 

Subject: [SIP] draft-mahy-sip-message-waiting-01.txt





Hi, 

The I-D mentions audible/visual message waiting indications in the 

introduction but then remains silent on this. 

Has there been any considerations to include the type of mwi 

(audible/visual) as optional in application/simple-message-summary? 

Jean-Francois Mule. 

Clarent



_______________________________________________ 

This list is for continuing development of the SIP protocol. 

The sip-implementor's list is the place to discuss implementation, 

and to receive advice on understanding existing sip. 

To subscribe to it, send mail to 

sip-implementors-request@cs.columbia.edu with "subscribe" in the body.





_______________________________________________ 

This list is for continuing development of the SIP protocol. 

The sip-implementor's list is the place to discuss implementation, 

and to receive advice on understanding existing sip. 

To subscribe to it, send mail to 

sip-implementors-request@cs.columbia.edu with "subscribe" in the body.

------------- 

PingMe! 

Jay Batson 

CEO 

Pingtel Corp. 

mailto:jbatson@pingtel.com   

781-938-5306 (office)




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




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









I 
think audio/video info can be done completely without sip, such as having the 
device pulling its messaging server via HTTP. It is difficult to define a set of 
COMMON features. Some common features on the PBX I am using includes speed 
dials, macro programming of speed dial key, and shows the number of new and old 
messages I have. 



  
-----Original Message-----
From: Jay Batson 
  [mailto:jbatson@pingtel.com]
Sent: Friday, June 22, 2001 6:45 
  AM
To: Gordon Ledgard; 'Dean Bogdanovic'; 'Wai Wu'; Venkatesh 
  Venkataramanan; 'Jean-Francois Mule'; 'Rohan Mahy'; islain@cisco.com; 
  sip@ietf.org
Subject: RE: [SIP] 
  draft-mahy-sip-message-waiting-01.txt

Exactly.  The 
  protocol is responsible for encoding the underlying information, the user 
  agent is responsible for the "presentation" of that information in whatever 
  manner is appropriate for that product.  Indicating that a high priority 
  message should be displayed is different for a UA with no light or display, or 
  for a UA built for deaf or blind users, or ....  That's why we *have* 
  distinctions between encoding and presentation 
  layers.

-jb


At 02:37 PM 6/20/01, Gordon Ledgard wrote:

  
Agree.
 
There isn't anything inherently un-SIP like about providing some set 
    of common network
or user 
    notification features.  The danger, as Venkatesh points out, is making 
    them application
specific, 
    like jumping to the conclusion that I want to turn on a light, or dictating 
    how that
notification is to 
    be interpreted by the recieving endpoint.
  
    

      
-----Original Message----- 
      
From: Dean Bogdanovic [mailto:deanb@mck.com] 
      
Sent: Wednesday, June 20, 2001 1:52 PM 
      
To: 'Wai Wu'; 'Jay Batson'; Venkatesh Venkataramanan; 
      'Jean-Francois Mule'; 'Rohan Mahy'; islain@cisco.com; 
      sip@lists.bell-labs.com 
      
Subject: RE: [SIP] 
      draft-mahy-sip-message-waiting-01.txt


      
Wai 
      
I would disagree with you. Audio/visual notifications are important to 
      end user and I belive giving some extensions to SIP will help the adoption 
      by the endusers. As Jay had mentioned it 
      


 
      
Regards 


      
Dean Bogdanovic 
      
MCK Communications 
      
phone:(617)454 6165 
      
fax:(617)454 6101 
      
___________________ 
      
"the answer is 42" 


      
-----Original Message----- 
      
From: Wai Wu [mailto:wwu@calltrol.com] 
      
Sent: Wednesday, June 20, 2001 10:40 AM 
      
To: 'Jay Batson'; Venkatesh Venkataramanan; 'Jean-Francois Mule'; 
      'Rohan Mahy'; islain@cisco.com; sip@lists.bell-labs.com 
      
Subject: RE: [SIP] 
      draft-mahy-sip-message-waiting-01.txt


      
I think features normally found on a PBX phone (e.g. message waiting) 
      shouldn't be part of SIP at all. If we put all these things in SIP, it 
      will make SIP not much different from a "standardized PBX protocol". 
      
      
-----Original Message----- 
      
From: Jay Batson [mailto:jbatson@pingtel.com] 
      
Sent: Tuesday, June 19, 2001 3:37 PM 
      
To: Venkatesh Venkataramanan; 'Jean-Francois Mule'; 'Rohan Mahy'; 
      islain@cisco.com; sip@lists.bell-labs.com 
      
Subject: RE: [SIP] 
      draft-mahy-sip-message-waiting-01.txt


      
My comments aren't timely, so my apologies.


      
Venkatesh's comments are also consistent with typical IETF protocol / 
      application design.  Example:  Neither SMTP nor POP/IMAP specify 
      how the email "user agent" (Eudora, Netscape, Outlook) provides visual 
      indication of email message priority (X-Priority).


      
The creator of a given user agent defines its own user interfaces to 
      information that is provided in the standardized lower later 
      protocol.  End users then choose among available user agents (and 
      behaviors) to get their desired interaction.


      
Applications at either end of a transaction may want to agree on 
      Experimental extensions to show more information, such as the type that 
      Jean-Francois suggests.  In fact, this is how X-Priority came into 
      being in email!  Eudora just up and did it one day, and everybody 
      else did what they did!


      
-jb




      
At 03:29 PM 4/26/01, Venkatesh Venkataramanan wrote:
      

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


        
Venkatesh


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




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


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




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

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

  

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



------_=_NextPart_001_01C0FB25.EFF2C240--

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


From sip-admin@lists.bell-labs.com  Fri Jun 22 13:13:47 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00822
	for ; Fri, 22 Jun 2001 13:13:46 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AA880443A9; Fri, 22 Jun 2001 13:14:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from gatekeeper.calltrol.com (unknown [65.105.250.35])
	by lists.bell-labs.com (Postfix) with ESMTP id EA66E44336
	for ; Fri, 22 Jun 2001 13:13:31 -0400 (EDT)
Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253])
	by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id NAA02436;
	Fri, 22 Jun 2001 13:13:14 -0400
Received: by NT-SERVER with Internet Mail Service (5.5.2448.0)
	id ; Fri, 22 Jun 2001 13:15:55 -0400
Message-ID: <60A9CA50081AD4118BD60040F60C1A9F0A3DC8@NT-SERVER>
From: Wai Wu 
To: "'Hidefumi Nakamura'" ,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Congestion control
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FB3E.FE95D120"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 22 Jun 2001 13:15:54 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FB3E.FE95D120
Content-Type: text/plain;
	charset="iso-8859-1"

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

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

Wai


-----Original Message-----
From: Hidefumi Nakamura [mailto:nakamura.hidefumi@lab.ntt.co.jp]
Sent: Friday, June 22, 2001 6:17 AM
To: sip@lists.bell-labs.com
Subject: [SIP] Congestion control


Hi. all,

I have a couple of questions about the suitable way to let the user agents/
proxy-servers know the congestion of sip-proxy(stateful) or location server,

and the suitable action after the notification.

As long as I review the sip document (rfc2543bis-03), I think
the most suitable way is to return a "503 service unavailable" message
with "Retry-after" field.  Is is correct understanding?

The other question is of the case when the INVITE request comes via
several (stateful) proxy servers.  That is, INVITE comes through

UAa --> proxy A --> proxy B --> UAb

and proxy B is in congestion.

In this case, proxy B will return a "503" message to UserAgent-a (UAa)
via proxy A if my understanding of the first question is correct.   UAa
will postpone to send a message to proxy A, but what should "proxy A"
do if it receives other INVITE messages for proxyB, say, from UAc, within
the period indicated in "retry-after" field?
Should proxy-A send "503" to UAc or transfer the INVITE message
to proxy-B even if proxy-A already has the information that proxy-B
is in congestion?

Please let me know.

Thanks.

---
Hidefumi NAKAMURA
NTT Network Service Systems Laboratories
tel:+81 (422)59 3904; fax:+81 (422)60 4012
---




------_=_NextPart_001_01C0FB3E.FE95D120
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Congestion control




"but what should "proxy A"

do if it receives other INVITE messages for proxyB, =
say, from UAc, within

the period indicated in "retry-after" =
field?

Should proxy-A send "503" to UAc or =
transfer the INVITE message

to proxy-B even if proxy-A already has the =
information that proxy-B

is in congestion?"




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




Wai






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

From: Hidefumi Nakamura [mailto:nakamura.hidefumi=
@lab.ntt.co.jp]

Sent: Friday, June 22, 2001 6:17 AM

To: sip@lists.bell-labs.com

Subject: [SIP] Congestion control






Hi. all,




I have a couple of questions about the suitable way =
to let the user agents/

proxy-servers know the congestion of =
sip-proxy(stateful) or location server, 

and the suitable action after the =
notification.




As long as I review the sip document (rfc2543bis-03), =
I think

the most suitable way is to return a "503 =
service unavailable" message

with "Retry-after" field.  Is is =
correct understanding?




The other question is of the case when the INVITE =
request comes via

several (stateful) proxy servers.  That is, =
INVITE comes through




UAa --> proxy A --> proxy B --> UAb




and proxy B is in congestion.




In this case, proxy B will return a "503" =
message to UserAgent-a (UAa)

via proxy A if my understanding of the first =
question is correct.   UAa

will postpone to send a message to proxy A, but what =
should "proxy A"

do if it receives other INVITE messages for proxyB, =
say, from UAc, within

the period indicated in "retry-after" =
field?

Should proxy-A send "503" to UAc or =
transfer the INVITE message

to proxy-B even if proxy-A already has the =
information that proxy-B

is in congestion?




Please let me know.




Thanks.




---

Hidefumi NAKAMURA

NTT Network Service Systems Laboratories

tel:+81 (422)59 3904; fax:+81 (422)60 4012

---









------_=_NextPart_001_01C0FB3E.FE95D120--

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


From sip-admin@ietf.org  Fri Jun 22 13:59:33 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02295;
	Fri, 22 Jun 2001 13:59:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01277;
	Fri, 22 Jun 2001 13:48:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01247
	for ; Fri, 22 Jun 2001 13:48:12 -0400 (EDT)
Received: from mailweb10.rediffmail.com (IDENT:qmailr@[203.199.83.22])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01875
	for ; Fri, 22 Jun 2001 13:47:36 -0400 (EDT)
Received: (qmail 14933 invoked by uid 510); 22 Jun 2001 17:49:51 -0000
Date: 22 Jun 2001 17:49:51 -0000
Message-ID: <20010622174951.14932.qmail@mailweb10.rediffmail.com>
Received: from unknown (210.214.209.117) by rediffmail.com via HTTP; 22 Jun 2001 17:49:51 -0000
MIME-Version: 1.0
To: "wwu@calltrol.com" ,
        "jdrosen@dynamicsoft.com" ,
        "Brian.Rosen@marconi.com" ,
        "kuthan@fokus.gmd.de" ,
        "sip@ietf.org" 
Subject:  Re: RE: [SIP] Authentication and billing through proxy/re-direct serv er
From: "Ashhar Farhan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

>this is very impolite

let me clarify,
i have high regard for everything that rosenberg says and writes. infact, i owe him a great debt for having putting me on track regarding the 3-way handshake, which on his recommendation i modified into a 4 way handshake for our own telephony protocol (substituting invite/ack by two separate ring and answer requests).
i am was only trying to drive home the point that rosenberg was facing a self-contradiction when he opposes standardisation of services which are an important element of a telephony protocol (the discussions on this thread amply bear this out).
i offer my unconditional apologies if i have offended him.

- farhan@hotfoon.com

------------- Original Message --------------
Wai Wu  wrote:
To:"'Ashhar Farhan'" , jdrosen@dynamicsoft.com,
       Brian.Rosen@marconi.com, kuthan@fokus.gmd.de, sip@ietf.org
From:Wai Wu 
Date:Fri, 22 Jun 2001 09:52:13 -0400
Subject:RE: [SIP] Authentication and billing through proxy/re-direct serv
 er

-----Original Message-----
From: Ashhar Farhan [mailto:afarhan@rediffmail.com]
Sent: Wednesday, June 20, 2001 11:50 PM
To: jdrosen@dynamicsoft.com; Brian.Rosen@marconi.com;
kuthan@fokus.gmd.de; sip@ietf.org
Subject: Re: [SIP] Authentication and billing through proxy/re-direct
serv er


jdrosen wrote -
>> I think people know my opinion on standardizing all the services on might
offer... horrible idea. 
then you should oppose the very idea of sdp, and even sip.
- farhan@hotfoon.com



_____________________________________________________
Buy Lagaan & Yaadein music for 30% less.
Avail this special offer at
http://shopping.rediff.com/shopping/music/offerrediffmailer.htm 




_______________________________________________
Sip mailing list
Sip@ietf.org
http://www.ietf.org/mailman/listinfo/sip


_____________________________________________________
Buy Lagaan & Yaadein music for 30% less.
Avail this special offer at http://shopping.rediff.com/shopping/music/offerrediffmailer.htm 




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


From sip-admin@ietf.org  Fri Jun 22 15:40:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06823;
	Fri, 22 Jun 2001 15:40:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05132;
	Fri, 22 Jun 2001 15:32:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05102
	for ; Fri, 22 Jun 2001 15:32:00 -0400 (EDT)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06441
	for ; Fri, 22 Jun 2001 15:31:24 -0400 (EDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP id 54B004DF41
	for ; Fri, 22 Jun 2001 15:32:00 -0400 (EDT)
Received: from fish.research.att.com (fish.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id PAA03666
	for ; Fri, 22 Jun 2001 15:31:59 -0400 (EDT)
From: William Marshall 
Received: (from wtm@localhost)
	by fish.research.att.com (SGI-8.9.3/8.8.5) id PAA20999
	for sip@ietf.org; Fri, 22 Jun 2001 15:32:18 -0400 (EDT)
Date: Fri, 22 Jun 2001 15:32:18 -0400 (EDT)
Message-Id: <200106221932.PAA20999@fish.research.att.com>
To: sip@ietf.org
Subject: [Sip] SDP usage in RFC2543/100rel/bis-03/manyfolks
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

At 08:46 AM 6/21/2001, Jonathan Rosenberg wrote:
> > -----Original Message-----
> > From: William Marshall [mailto:wtm@research.att.com]
> > Sent: Monday, June 18, 2001 2:47 PM
> > To: sip@ietf.org
> > Subject: [Sip] SDP usage in RFC2543/100rel/bis-03/manyfolks
> >
> > The restrictive wording in bis-03 on allowable placement of
> > message bodies in SIP requests/responses seems to lead to a
> > lot of compatibility problems with other current I-Ds.
> > [...]
> > Manyfolks-resource-01 made use of these allowable combinations,
> > to include the UAS SDP in the first reliable provisional response
> > (typically a 183 if resource reservation is supported).
> >
> > Unfortunately, bis-03 disallows this combination.
>
>Hows that? It merely states that if the INVITE contained SDP, so MUST the
>200, and not the ACK. Nothing in there about PRACK or 18x. Similarly, when
>INVITE doesn't have SDP, it MUST be in 200, and MUST be in ACK. Doesn't rule
>out anything else.

The problem of the UA receiving multiple SDPs from the other end was the
basic reason for the re-writing of the Annex on SDP usage.  Otherwise,
the simple rule of using the last one received (the RFC2543 way) would
work just fine, and there would be no reason to restrict the places
SDP may appear.

So if 2543bis says SDP MUST appear in the 200OK, and manyfolks says
SDP MUST appear in the 183, then the UAC MUST deal with multiple SDPs.
Therefore it MUST deal with differences between them.  How?  By ignoring
the second SDP?  Then why was it sent?  By ignoring the first?  Then
I know of several QoS architectures that will not work.

The basic principle I recall from the Minneapolis IETF was that the
UA should not be forced to deal with these complexities; thus the
simplification of only one SDP sent in each direction.  This
simplification can be maintained in almost all cases, by simply
allowing the SDP response to appear in a provisional response instead
of the final response.  The second round offer, if needed, can  be
restricted to a subset of the initial offer in order to keep the
processing simple.

Bill Marshall
wtm@research.att.com

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


From sip-admin@lists.bell-labs.com  Fri Jun 22 15:51:38 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07425
	for ; Fri, 22 Jun 2001 15:51:34 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CFB26443BA; Fri, 22 Jun 2001 15:52:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by lists.bell-labs.com (Postfix) with SMTP id D285744336
	for ; Fri, 22 Jun 2001 15:51:42 -0400 (EDT)
Received: from 157.54.9.101 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Jun 2001 12:49:08 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 22 Jun 2001 12:48:57 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Fri, 22 Jun 2001 12:48:55 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 22 Jun 2001 12:48:29 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FB54.4F1DB391"
Message-ID: <2E33960095B58E40A4D3345AB9F65EC1112049@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Definition of Server header.
Thread-Index: AcD7VF+P5iLrCKwuQxqLFAw/7ebFdw==
From: "David Simons" 
To: 
X-OriginalArrivalTime: 22 Jun 2001 19:48:29.0296 (UTC) FILETIME=[4F51CF00:01C0FB54]
Subject: [SIP] Definition of Server header.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 22 Jun 2001 12:48:28 -0700

This is a multi-part message in MIME format.

------_=_NextPart_001_01C0FB54.4F1DB391
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In RFC 2543 there is the following description of the Server header:

		6.34 Server

		   The Server response-header field contains information
about the
		   software used by the user agent server to handle the
request. The
		   syntax for this field is defined in [H14.39].

I can't quit figure out what [H14.39] is.  Could someone enlighten me?

Regards,

David J. Simons
Development Lead
Microsoft Windows RTC



------_=_NextPart_001_01C0FB54.4F1DB391
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






Definition of Server header.





In =
RFC 2543 there is the following description of the Server header:


      

      6.34 Server
      


         The Server response-header field contains information =
about the
      


         software used by the user agent server to handle the =
request. The
      


         syntax for this field is defined in =
[H14.39].
      



I =
can’t quit figure out what [H14.39] is.  Could someone =
enlighten me?



Regards,



David J. =
Simons



Development Lead



Microsoft Windows RTC







------_=_NextPart_001_01C0FB54.4F1DB391--

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


From sip-admin@lists.bell-labs.com  Fri Jun 22 16:11:33 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08180
	for ; Fri, 22 Jun 2001 16:11:32 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7977F443C8; Fri, 22 Jun 2001 16:12:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by lists.bell-labs.com (Postfix) with SMTP id 7D1A5443C1
	for ; Fri, 22 Jun 2001 16:11:57 -0400 (EDT)
Received: from 157.54.7.67 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Jun 2001 13:11:51 -0700 (Pacific Daylight Time)
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Fri, 22 Jun 2001 13:11:39 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883);
	 Fri, 22 Jun 2001 13:11:37 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 22 Jun 2001 13:11:11 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FB57.7AD58328"
Subject: RE: [SIP] Definition of Server header.
Message-ID: <2E33960095B58E40A4D3345AB9F65EC1A841B7@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [SIP] Definition of Server header.
Thread-Index: AcD7VF+P5iLrCKwuQxqLFAw/7ebFdwAAvSVw
From: "Junhua Wang" 
To: "David Simons" , 
X-OriginalArrivalTime: 22 Jun 2001 20:11:11.0249 (UTC) FILETIME=[7B1B5810:01C0FB57]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 22 Jun 2001 13:11:10 -0700

This is a multi-part message in MIME format.

------_=_NextPart_001_01C0FB57.7AD58328
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

HTTP 1.1 RFC section 14.38
=20
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.38

	-----Original Message-----
	From: David Simons=20
	Sent: Friday, June 22, 2001 12:48 PM
	To: sip@lists.bell-labs.com
	Subject: [SIP] Definition of Server header.
=09
=09

	In RFC 2543 there is the following description of the Server
header:

			6.34 Server

			   The Server response-header field contains
information about the

			   software used by the user agent server to
handle the request. The

			   syntax for this field is defined in [H14.39].

	I can't quit figure out what [H14.39] is.  Could someone
enlighten me?

	Regards,

	David J. Simons

	Development Lead

	Microsoft Windows RTC

=09


------_=_NextPart_001_01C0FB57.7AD58328
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Message




HTTP 1.1 RFC =
section=20
14.38


 


=
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.38



  

  
-----Original Message-----
From: =
David Simons=20
  
Sent: Friday, June 22, 2001 12:48 PM
To:=20
  sip@lists.bell-labs.com
Subject: [SIP] Definition of Server=20
  header.


  
In RFC =
2543 there is=20
  the following description of the Server =
header:

  
    
    
      
      
      6.34=20
      Server
      
      
         The Server response-header field contains =
information=20
      about the
      
      
         software used by the user agent server to =
handle the=20
      request. The
      
      
         syntax for this field is defined in=20
      [H14.39].

  
I=20
  can’t quit figure out what [H14.39] is.  Could =
someone=20
  enlighten me?

  
Regards,

  
David J. =
Simons

  
Development Lead

  
Microsoft Windows RTC

  

=00
------_=_NextPart_001_01C0FB57.7AD58328--

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


From sip-admin@ietf.org  Fri Jun 22 17:32:09 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12010;
	Fri, 22 Jun 2001 17:32:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07770;
	Fri, 22 Jun 2001 17:02:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07739
	for ; Fri, 22 Jun 2001 17:02:47 -0400 (EDT)
Received: from mail.ipunity.com ([12.44.179.201])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10109
	for ; Fri, 22 Jun 2001 17:02:12 -0400 (EDT)
Received: from ipunity.com (192-168-181-67.ipunity.com [192.168.181.67] (may be forged))
	by mail.ipunity.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id NAA05015
	for ; Fri, 22 Jun 2001 13:53:47 -0700
Message-ID: <3B33B198.E2CABE29@ipunity.com>
Date: Fri, 22 Jun 2001 13:59:04 -0700
From: Swaroop Kulkarni 
Organization: IPUNITY
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Clarification needed on CANCEL request
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello everyone,

The question I have is as follows :-

If the UAS receives a CANCEL after sending the 200 Ok to the INVITE
request, what is the desired behaviour from it.
Should it cancel the call or wait for an explicit BYE request from the
UAC.
If it has to wait for a BYE, what is the response to the CANCEL
request??

Thanks a lot in advance
Swaroop

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


From sip-admin@ietf.org  Fri Jun 22 18:12:44 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13237;
	Fri, 22 Jun 2001 18:12:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09230;
	Fri, 22 Jun 2001 18:04:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09205
	for ; Fri, 22 Jun 2001 18:04:41 -0400 (EDT)
Received: from mail.inetmail.att.net (mailhost1.inetmail.att.net [204.127.132.33])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13035
	for ; Fri, 22 Jun 2001 18:04:05 -0400 (EDT)
Received: from ranjit ([12.41.17.140])
          by mail.inetmail.att.net (mtiagic01) with SMTP
          id <20010622220411gi128285hte>; Fri, 22 Jun 2001 22:04:11 +0000
Message-ID: <03a901c0fb68$f4c510a0$0d00000a@testone.masconit.com>
Reply-To: "Ranjit Avasarala" 
From: "Ranjit Avasarala" 
To: "Swaroop Kulkarni" , 
References: <3B33B198.E2CABE29@ipunity.com>
Subject: Re: [Sip] Clarification needed on CANCEL request
Date: Fri, 22 Jun 2001 17:16:15 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi
   According to bis RFC for an INVITE to be terminated both CANCEL and BYE
are to be sent . so in your case it should wait for
explicit BYE to terminate the call.

Regards
Ranjit







----- Original Message -----
From: Swaroop Kulkarni 
To: 
Sent: Friday, June 22, 2001 3:59 PM
Subject: [Sip] Clarification needed on CANCEL request


Hello everyone,

The question I have is as follows :-

If the UAS receives a CANCEL after sending the 200 Ok to the INVITE
request, what is the desired behaviour from it.
Should it cancel the call or wait for an explicit BYE request from the
UAC.
If it has to wait for a BYE, what is the response to the CANCEL
request??

Thanks a lot in advance
Swaroop

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


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


From sip-admin@ietf.org  Fri Jun 22 21:25:15 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17638;
	Fri, 22 Jun 2001 21:25:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13649;
	Fri, 22 Jun 2001 21:18:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13617
	for ; Fri, 22 Jun 2001 21:18:09 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17595
	for ; Fri, 22 Jun 2001 21:17:33 -0400 (EDT)
Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f5N1Hex12771;
	Fri, 22 Jun 2001 18:17:40 -0700 (PDT)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f5N1Hau29860;
	Fri, 22 Jun 2001 18:17:36 -0700 (PDT)
Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id SAA19166; Fri, 22 Jun 2001 18:17:31 -0700 (PDT)
Message-ID: <3B33EE88.9F17031E@cisco.com>
Date: Fri, 22 Jun 2001 21:19:04 -0400
From: Flemming Andreasen 
Organization: Cisco Systems
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Christian Huitema'" ,
        Anders Kristensen , sip@ietf.org
Subject: Re: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of bis3]]
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: Christian Huitema [mailto:huitema@windows.microsoft.com]
> > Sent: Thursday, June 14, 2001 11:17 AM
> > To: Anders Kristensen
> > Cc: Flemming Andreasen; sip@ietf.org; Jonathan Rosenberg
> > Subject: RE: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of
> > bis3]]
> >
> >
> > Yes. In fact, we could make a session explaining that SDP was
> > originally
> > defined for an entirely different purpose, that it is currently being
> > revised, and that a bunch of fields defined in SDP shall be considered
> > optional when used with SIP. I bet that this includes essentially all
> > the fields that are not directly related to specifying
> > addresses, ports
> > and coding parameters, plus the version field that we use in
> > "re-invite."
>
> Well, I'm trying to avoid the case where we have two separate SDP specs -
> one for SAP, and one for SIP. Thus, I want the usage of SDP within SIP to be
> completely compliant to the specification we have available, which is
> rfc2327. I think we can agree that although the BNF doesn't require it, the
> text is clear that rfc2327 mandates either e or p lines.
>

That's not what Colin's reply indicated.


>
> I AM willing, however, to mandate that people be willing to accept SDP
> without these. Thus, the text would basically say that either e or p should
> be present, as mandated by rfc2327, but because it serves little value in
> sip, and is often ignored in practice, you MUST be prepared to process SDP
> without it.
>
> Maybe the difference is really academic, but I don't want to mandate that
> people construct SDP in violation of the spec. I'd rather mandate that they
> accept SDP that violates the spec.

If the concern is simply to be SDP compliant, then why say anything about it (on
the sending side) ? Text duplication is the sure way to inconsistency so there
should rather just be a reference to RFC 2327. On the receiving side, I agree
it's a good idea to mandate lenient behavior.


-- Flemming


>
>
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip

--
Flemming Andreasen
Cisco Systems



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


From sip-admin@ietf.org  Fri Jun 22 22:23:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19229;
	Fri, 22 Jun 2001 22:23:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA15012;
	Fri, 22 Jun 2001 22:14:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA14981
	for ; Fri, 22 Jun 2001 22:14:35 -0400 (EDT)
Received: from purple.east.isi.edu (purpleish.east.isi.edu [38.245.76.9])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19160
	for ; Fri, 22 Jun 2001 22:13:58 -0400 (EDT)
Received: from purple (localhost [127.0.0.1])
	by purple.east.isi.edu (8.9.3/8.9.3) with ESMTP id WAA03657;
	Fri, 22 Jun 2001 22:14:20 -0400
Message-Id: <200106230214.WAA03657@purple.east.isi.edu>
To: Flemming Andreasen 
cc: Jonathan Rosenberg ,
        "'Christian Huitema'" ,
        Anders Kristensen , sip@ietf.org
Subject: Re: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of bis3]] 
In-Reply-To: Your message of "Fri, 22 Jun 2001 21:19:04 EDT."
             <3B33EE88.9F17031E@cisco.com> 
Date: Fri, 22 Jun 2001 22:14:20 -0400
From: Colin Perkins 
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

--> Flemming Andreasen writes:
>Jonathan Rosenberg wrote:
>> > -----Original Message-----
>> > From: Christian Huitema [mailto:huitema@windows.microsoft.com]
>> > Sent: Thursday, June 14, 2001 11:17 AM
>> > To: Anders Kristensen
>> > Cc: Flemming Andreasen; sip@ietf.org; Jonathan Rosenberg
>> > Subject: RE: [Fwd: [Fwd: [Sip] Few tiny issues with SDP section of
>> > bis3]]
>> >
>> >
>> > Yes. In fact, we could make a session explaining that SDP was
>> > originally
>> > defined for an entirely different purpose, that it is currently being
>> > revised, and that a bunch of fields defined in SDP shall be considered
>> > optional when used with SIP. I bet that this includes essentially all
>> > the fields that are not directly related to specifying
>> > addresses, ports
>> > and coding parameters, plus the version field that we use in
>> > "re-invite."
>>
>> Well, I'm trying to avoid the case where we have two separate SDP specs -
>> one for SAP, and one for SIP. Thus, I want the usage of SDP within SIP to be
>> completely compliant to the specification we have available, which is
>> rfc2327. I think we can agree that although the BNF doesn't require it, the
>> text is clear that rfc2327 mandates either e or p lines.
>
>That's not what Colin's reply indicated.

That's what the current SDP spec mandates. Since it is widely ignored, and
we have an update of SDP in progress, we could make it optional in the new
revision.

>> I AM willing, however, to mandate that people be willing to accept SDP
>> without these. Thus, the text would basically say that either e or p should
>> be present, as mandated by rfc2327, but because it serves little value in
>> sip, and is often ignored in practice, you MUST be prepared to process SDP
>> without it.
>>
>> Maybe the difference is really academic, but I don't want to mandate that
>> people construct SDP in violation of the spec. I'd rather mandate that they
>> accept SDP that violates the spec.
>
>If the concern is simply to be SDP compliant, then why say anything about it (on
>the sending side) ? Text duplication is the sure way to inconsistency so there
>should rather just be a reference to RFC 2327. On the receiving side, I agree
>it's a good idea to mandate lenient behavior.

I think it would be better for SIP to be silent on the issue, and the
revision of SDP (for draft standard) to clarify one way or the other.

Colin

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


From sip-admin@lists.bell-labs.com  Mon Jun 25 08:14:32 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12413
	for ; Mon, 25 Jun 2001 08:14:32 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3198944337; Mon, 25 Jun 2001 08:15:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53])
	by lists.bell-labs.com (Postfix) with ESMTP id DE08E44336
	for ; Mon, 25 Jun 2001 08:14:51 -0400 (EDT)
Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id ;
 Mon, 25 Jun 2001 13:14:47 +0100
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-32) id NAA00016; Mon, 25 Jun 2001 13:14:46 +0100 (BST)
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 80256A76.00432E74 ; Mon, 25 Jun 2001 13:13:48 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Wayne Cutler" 
To: Gonzalo Camarillo 
Cc: sip@lists.bell-labs.com
Message-ID: <80256A76.004326CC.00@marconicomms.com>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] Re Mapping of ISUP overlap signalling to SIP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 25 Jun 2001 13:13:28 +0100



For the specific scenario of using SIP as a "bridge" between PSTN signalling
points, then why not make the SIP headers
independent of the e164 digit string. In this specific case, the SIP endpoints
are the 2 MGCs that are using SIP to encapsulate the ISUP
and realize the bridge between the PSTN n/w at each side. Therefore, the SIP
headers are set up to reflect the MGC/Server identities and the
PSTN address is reflected only in the encapsulated ISUP. For overlap working,
the IAM gets sent in the INVITE and SAMs get sent in an INFO.
Whilst the applicability of this proposal is limited, it is a perfectly
valid/workable solution to an ETSI ISUP bridging scenario. Could it be added
to your draft as another alternative?

Regards, Wayne.



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


From sip-admin@lists.bell-labs.com  Mon Jun 25 11:56:29 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19308
	for ; Mon, 25 Jun 2001 11:56:29 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 764E14433A; Mon, 25 Jun 2001 11:57:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153])
	by lists.bell-labs.com (Postfix) with ESMTP id 2A63544336
	for ; Mon, 25 Jun 2001 11:56:40 -0400 (EDT)
Received: from frmta003.netfr.alcatel.fr (frmta003.netfr.alcatel.fr [155.132.251.32])
        by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id RAA25853
        for ; Mon, 25 Jun 2001 17:57:02 +0200 (MET DST)
Received: by frmta003.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id C1256A76.005794F6 ; Mon, 25 Jun 2001 17:56:37 +0200
X-Lotus-FromDomain: ALCATEL
From: Pierre.Lacour@alcatel.fr
To: sip@lists.bell-labs.com
Message-ID: 
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] SIP and IN services environment
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 25 Jun 2001 16:30:41 +0200




Hello,
I am new in the SIP world, and  my English is not my native language, so please, be indulgent .

I make some mismatch with the following notions : SIP proxy /redirect server, the application server, the 3d Party Call control and the softwitch.

If I understand :
SIP PROXY : In a SIP request, the SIP proxy can change the URI, add or delete a Via field and add or delete data into the record-route field.
The SIP Proxy can originate a CANCEL but not a BYE.
Controller : A 3d Party Call Control or controller is able to create, modify and terminate call with other entities.
So the controller is allowed to modify all the fields of the Header and the body of a SIP INVITE coming from a Caller , in order to re-route the call to a different entity than the original callee such as a media server, it is called B2BUA .
 Does the controller manage is own call ID and CSeq or it has to take the call ID from the Caller INVITE ?
A Controller can Initiate a  call leg to a Media Server, in order for example, to play mid-call announcement.
The application server can act as a Controller.  The application server provides  services not the controller.

About the mapping with the IN :
Can we make the correlation between the SSP in a IN environment and the Controller B2BUA in a SIP environment ??

About the notion of Softswitch :
Does the softswitch can act as an extended proxy or a controller or an application server? Or it must act as a controller only ?

Thank you

Pierre






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


From sip-admin@ietf.org  Mon Jun 25 12:13:38 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19714;
	Mon, 25 Jun 2001 12:13:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13118;
	Mon, 25 Jun 2001 12:05:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13087
	for ; Mon, 25 Jun 2001 12:05:24 -0400 (EDT)
Received: from mail.net2phone.com (mail.net2phone.com [216.53.3.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19490
	for ; Mon, 25 Jun 2001 12:04:44 -0400 (EDT)
Received: from mailsvr.net2phone.com (exchange.net2phone.com [216.53.60.1])
	by mail.net2phone.com (8.9.3/8.9.3) with ESMTP id LAA07012;
	Mon, 25 Jun 2001 11:26:56 -0400 (EDT)
Received: by mailsvr.net2phone.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 25 Jun 2001 11:32:00 -0400
Message-ID: <6F46FABB90ABD411BD690002B3152FB9260350@lkwmail01.net2phone.com>
From: Romel Khan 
To: "'Gonzalo Camarillo'" ,
        "'sip@ietf.org'" ,
        "'adam.roach@ericsson.com'"
	 
Subject:  [SIP] I-D ACTION:draft-ietf-sip-isup-01.txt
Date: Mon, 25 Jun 2001 11:25:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

A few questions/comments on ISUP to SIP mapping draft:

1. How this draft ties with "SIP Extensions for Caller Identity and Privacy"
needs to be addressed. The sip-privacy draft can be used for transporting II
digit information and presentation restriction information which is
important if the termination is a SIP endpoint.

2. Sec. 12, pg 47: Talking about ANSI ISUP, it has been stated "the
recommended behaviour is sending REL in response to CRM". Rather, shouldn't
the recommended behaviour following GR-394 (which will not actually result
in sending SIP Invite until the IAM finally comes)? There could be SIP GWs
in USA which interfaces using SS7 using SS7 with PSTN Access Tandem switches
that follow GR-394 and could potentially send CRM. 

3. In up front sections such as sec. 6.2.1.1 tel URL has been mentioned in a
way to make me think that SIP URL is not allowed (until I read further on).
Won't it be clearer to say statements such as "telephone number in the tel
URL" as "telephone number in the tel URL or SIP URL"

4. Sec. 6.2.6, last sentence: Shouldn't ACM also be included in the body of
the 183 response? Only 180 response is mentioned.

5. In sec. 6.2.1.1, page 16, 3rd para.: a set of parameters are called
"immediately useful". Why is Called Party Number (CPN) missing from this
list?


Thanks.

Romel Khan
Ph: (732)-363-0213, x241



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


From sip-admin@lists.bell-labs.com  Mon Jun 25 12:16:29 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19790
	for ; Mon, 25 Jun 2001 12:16:29 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5F22944343; Mon, 25 Jun 2001 12:17:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id 6730044341
	for ; Mon, 25 Jun 2001 12:16:08 -0400 (EDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5PGG8N23136;
	Mon, 25 Jun 2001 18:16:08 +0200 (MEST)
Received: from lmf.ericsson.se (racom-sd-118.sd.us.am.ericsson.se [142.133.141.119])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id SAA03075;
	Mon, 25 Jun 2001 18:16:38 +0200 (MET DST)
Message-ID: <3B3765B0.A91C5EC1@lmf.ericsson.se>
From: Gonzalo Camarillo 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Wayne Cutler 
Cc: sip@lists.bell-labs.com
References: <80256A76.004326CC.00@marconicomms.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: Re Mapping of ISUP overlap signalling to SIP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 25 Jun 2001 19:24:16 +0300
Content-Transfer-Encoding: 7bit

Hello,

There have been millons of mails sent to the mailins list in the past
discussing exactly what you are proposing. Besides, this has been
presented in several WG meetings.

Feel free to check the archives to find more information about this.

Best regards,

Gonzalo

Wayne Cutler wrote:
> 
> For the specific scenario of using SIP as a "bridge" between PSTN signalling
> points, then why not make the SIP headers
> independent of the e164 digit string. In this specific case, the SIP endpoints
> are the 2 MGCs that are using SIP to encapsulate the ISUP
> and realize the bridge between the PSTN n/w at each side. Therefore, the SIP
> headers are set up to reflect the MGC/Server identities and the
> PSTN address is reflected only in the encapsulated ISUP. For overlap working,
> the IAM gets sent in the INVITE and SAMs get sent in an INFO.
> Whilst the applicability of this proposal is limited, it is a perfectly
> valid/workable solution to an ETSI ISUP bridging scenario. Could it be added
> to your draft as another alternative?
> 
> Regards, Wayne.

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

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


From sip-admin@ietf.org  Mon Jun 25 12:22:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19995;
	Mon, 25 Jun 2001 12:22:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13656;
	Mon, 25 Jun 2001 12:15:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13629
	for ; Mon, 25 Jun 2001 12:15:19 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19750
	for ; Mon, 25 Jun 2001 12:14:39 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5PGFJE18375
	for ; Mon, 25 Jun 2001 12:15:19 -0400 (EDT)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5PGFIC18366;
	Mon, 25 Jun 2001 12:15:18 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA03773; Mon, 25 Jun 2001 11:15:17 -0500 (CDT)
Message-ID: <3B37637B.46A2E6DB@lucent.com>
Date: Mon, 25 Jun 2001 11:14:51 -0500
From: Vijay Gurbani 
Organization: Lucent Technologies/Bell Laboratories
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pierre.Lacour@alcatel.fr
CC: SIP LIST 
Subject: Re: [SIP] SIP and IN services environment
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

[...Pierre -- the SIP WG list has moved to sip@ietf.org, please make a note
    of it...]

Pierre.Lacour@alcatel.fr wrote:
> 
> Hello,
> I am new in the SIP world, and  my English is not my native language, so 
> please, be indulgent .
> 
> I make some mismatch with the following notions : SIP proxy /redirect 
> server, the application server, the 3d Party Call control and the 
> softwitch.
> 
> If I understand :
> SIP PROXY : In a SIP request, the SIP proxy can change the URI, add or 
> delete a Via field and add or delete data into the record-route field.

It can only add/delete *it's* Via field; add a R-R with *it's* URI, and
remove a Route with *it's* URI.

> About the mapping with the IN :
> Can we make the correlation between the SSP in a IN environment and the 
> Controller B2BUA in a SIP environment ??

Sort of; see the following I-Ds on this:

http://search.ietf.org/internet-drafts/draft-gurbani-iptel-sip-to-in-04.txt
http://search.ietf.org/internet-drafts/draft-gurbani-iptel-sip-in-imp-01.txt
http://search.ietf.org/internet-drafts/draft-haerens-sip-in-00.txt

Also, there is an IETF design team on SIP/IN interworking.  Interested
parties can contact me privately and I can fill you in on the current
happenings in the design team.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

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


From sip-admin@ietf.org  Mon Jun 25 16:21:46 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26101;
	Mon, 25 Jun 2001 16:21:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23668;
	Mon, 25 Jun 2001 16:05:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23635
	for ; Mon, 25 Jun 2001 16:04:52 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25807
	for ; Mon, 25 Jun 2001 16:04:10 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA22819;
	Mon, 25 Jun 2001 16:08:39 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 25 Jun 2001 16:04:33 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Barry Desborough'" ,
        "'Paul Kyzivat'"
	 ,
        Bob Penfield 
Cc: "'sip@ietf.org'" 
Date: Mon, 25 Jun 2001 16:04:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] RE: [Sip-implementors] another problem related to multiple call l
 egs at   UAC
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 Moving from sip-implementors to sip since there are some open issues and
changes to bis in here.


> -----Original Message-----
> From: Barry Desborough [mailto:BarryD@vegastream.com]
> Sent: Thursday, June 21, 2001 6:34 AM
> To: 'Paul Kyzivat'; Bob Penfield
> Cc: sip-implementors@cs.columbia.edu
> Subject: RE: [Sip-implementors] another problem related to 
> multiple call
> l egs at UAC
> 
> 
> I like the NAK idea. Consider a prong of a fork which gets 
> routed to a PSDN
> gateway. When the PSDN called party picks up, a connection 
> charge may be
> incurred if the gateway gets ACK-followed-by-BYE

Don't confuse billing and SIP messaging. You can just as easily not charge
users if a BYE follows the ACK by some small time lag.

> 
> I also agree that encoded reasons should be added to BYEs and 
> CANCELs such
> that a PSDN gateway can map them to and from Q.931 cause codes.

I also like these BYE reasons. This has come up countless times. Its also
helpful in CANCEL, to know whether a call was cancelled because the caller
aborted, or because some other branch picked up (the former would generate a
missed call entry in a call log, whilst the other won't). I don't think
Warning is right, but some kind of header that conveys both a
machine-interpretable and human-interpretable value would be good.

Paul writes:
 > Bob Penfield wrote:
> > [snip]
> > > If the UAC only wants the first 200-OK, it can accept it. If it
> > > sees another 200-OK, it can just ACK it and send a BYE.
> >
> > I have seen this answer many times.
> > But I have never seen any discussion of the kind of user
> > experience this provides.
> 
> More often than not, the callee will just get dead air.

Lets be clear that this will happen only under race conditions. Generally,
when a 200 OK arrives, this generates a CANCEL that stops the other lines
from ringing. This is therefore like the home phone experience (the behavior
is different if you pick up after the call is answered - this is the Single
Line Extension work that was going to define how to emulate that model where
if you pick up, you get to join a conference call).

That said, I agree that having a reason in BYE/CANCEL would help the
experience under the race condition, should it happen. 

Harpreet writes:
> Another thing  Section 5.2 of bis 03.txt also says that
> "A proxy client generates a CANCEL request for branches without
>    a final response after it has forked a request and 
> receives a 2xx or
>    6xx response from one of the branches. "
> Whereas section 17.4, pg. 122 says that
> "After receiving a 2xx, the server MAY terminate all other
>              pending requests by sending a CANCEL request"
> 
> Note that there is no "MAY" in section 5.2.

These need to be consistent. Honestly, it should probably be a SHOULD as
opposed to a MAY in both places. Anyone object to me changing that?

Harpreet writes:
> I have a basic question here. The intent of the UAC by sending the
> INVITE to the proxy was to open just one call leg, but the proxy's
> forking resulted in formation of multiple call legs. Now why isn't it
> made mandatory in SIP for the proxy to handle all these extra multiple
> call legs & present the UAC with just one 2xx for one call 
> leg only. Why

No, the intent of the IVNITE is not to open one call leg, its to contact the
user at the multiple places they may reside.

If a SIP proxy handles the multiple call legs, then forking proxies must
become B2BUAs. We want to avoid keeping stateful devices in the network like
this in order to support what is, IMHO, a key component for any user
discovery system. Ultimately, the end-to-end principle will argue that
treatment of the multiple-200 case is best left to the client, since it
needs to handle it no matter what (serverless operation), and it is best
positioned to determine what the right treatment is. 


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

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


From sip-admin@ietf.org  Mon Jun 25 16:54:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26798;
	Mon, 25 Jun 2001 16:54:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25056;
	Mon, 25 Jun 2001 16:45:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25026
	for ; Mon, 25 Jun 2001 16:45:16 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26552
	for ; Mon, 25 Jun 2001 16:44:37 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A24A1403EE; Mon, 25 Jun 2001 16:42:50 -0400
Message-ID: <002b01c0fdb7$a5fdf3a0$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: "Jonathan Rosenberg" ,
        "'Barry Desborough'" ,
        "'Paul Kyzivat'" 
Cc: 
References: 
Date: Mon, 25 Jun 2001 16:44:35 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: [Sip-implementors] another problem related to multiple call l egs at   UAC
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg writes:

> Harpreet writes:
> > Another thing  Section 5.2 of bis 03.txt also says that
> > "A proxy client generates a CANCEL request for branches without
> >    a final response after it has forked a request and
> > receives a 2xx or
> >    6xx response from one of the branches. "
> > Whereas section 17.4, pg. 122 says that
> > "After receiving a 2xx, the server MAY terminate all other
> >              pending requests by sending a CANCEL request"
> >
> > Note that there is no "MAY" in section 5.2.
>
> These need to be consistent. Honestly, it should probably be a SHOULD as
> opposed to a MAY in both places. Anyone object to me changing that?
>

Wouldn't that break the cancel-feature of the Request-Disposition header in
the caller preferences draft? If the proxies always cancel the other legs,
then clients that do fancy things with multiple answers could never work.

For example, I use a one-number service (unfortunately PSTN based) with a
call screening feature that tells the callee who the call is for and who is
holding and asks the callee to press 1 to accept the call. The service
simultaneouly rings my office, home, and cell phone. If this were
implemented in SIP with a forking proxy to get to all the devices I
registered, and the proxy canceled the unanswered call legs as soon as one
answered, I could not receive the call if my wife picked up the home phone
before I answered my office or cell phone.

I think it should be a MAY.

(-:bob


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


From sip-admin@ietf.org  Mon Jun 25 17:10:02 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27175;
	Mon, 25 Jun 2001 17:10:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25872;
	Mon, 25 Jun 2001 17:04:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25843
	for ; Mon, 25 Jun 2001 17:04:10 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27030
	for ; Mon, 25 Jun 2001 17:03:32 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A6CBF90264; Mon, 25 Jun 2001 17:02:03 -0400
Message-ID: <004201c0fdba$540daa60$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: "Jonathan Rosenberg" ,
        "'Barry Desborough'" ,
        "'Paul Kyzivat'" 
Cc: 
References: 
Date: Mon, 25 Jun 2001 17:03:47 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [Sip] reason code in BYE/CANCEL (was [Sip-implementors] another problem related to multiple call l egs at   UAC)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Jonathan Rosenberg wrote:
>
>
>  Moving from sip-implementors to sip since there are some open issues and
> changes to bis in here.
>
>


> Barry Desborough wrote:
>
> > I also agree that encoded reasons should be added to BYEs and
> > CANCELs such
> > that a PSDN gateway can map them to and from Q.931 cause codes.
>
> I also like these BYE reasons. This has come up countless times. Its also
> helpful in CANCEL, to know whether a call was cancelled because the caller
> aborted, or because some other branch picked up (the former would generate
a
> missed call entry in a call log, whilst the other won't). I don't think
> Warning is right, but some kind of header that conveys both a
> machine-interpretable and human-interpretable value would be good.
>
How about a "Reason" request header (or is that already defined elswhere)
that uses the same format as the Warning header?

        Reason        =  "Reason" ":" 1#reason-value
        reason-value  =  reason-code SP reason-agent SP reason-text
        reason-code   =  3DIGIT
        reason-agent  =  host [ ":" port ]
                          ;  the name of the server adding
                          ;  the Reason header, for use in tracing/debugging
        reason-text   =  quoted-string




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


From sip-admin@lists.bell-labs.com  Mon Jun 25 17:38:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27764
	for ; Mon, 25 Jun 2001 17:38:51 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9B73C44338; Mon, 25 Jun 2001 17:39:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.pingtel.com (mail.pingtel.com [216.91.1.131])
	by lists.bell-labs.com (Postfix) with ESMTP id 916CB44336
	for ; Mon, 25 Jun 2001 17:38:36 -0400 (EDT)
Received: from pingtel.com (cdhcp162.pingtel.com [10.1.1.162])
	by mail.pingtel.com (8.11.0/8.11.0) with ESMTP id f5PLZRd09937;
	Mon, 25 Jun 2001 17:35:31 -0400
Message-ID: <3B37AF3A.EB9C81EE@pingtel.com>
From: "Daniel G. Petrie" 
Organization: Pingtel Corp. http://www.pingtel.com
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Billy Biggs 
Cc: Alan Johnston , Dvir Oren ,
        SIP Implementors ,
        SIP List 
Subject: Re: [SIP] Replaces leg matching (was Re: [Sip-implementors] replaces)
References: <15130.21550.973473.551003@jodie.lucid> <20010604093456.A7248@div8.net> <3B21336E.4C1FF35C@wcom.com> <20010609004736.A243@div8.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 25 Jun 2001 17:38:02 -0400
Content-Transfer-Encoding: 7bit

It was agreed at the Interim SIP meeting in Feb. that is was
legal to create calls using the same call-id.  (i.e. on a conference
bridge).  There is no semantics assumed, it is just another call
as long as the To or From field differ.
http://www.softarmor.com/sipwg/meets/interim-feb-01/notes/dwillis.html
Has this decision changed somewhere along the line?

So call-id by itself is not sufficient.  Tags are optional in some cases
of RFC2543.  So how do we ensure uniqueness:
1) Require 2543-bis for Replaces (i.e. MUST have To & From tags)
or
2) Require at least the user-id, host, port, tag parts of the To & From
    fields

Billy Biggs wrote:

>   Alan,
>
>   I'm posting this to the SIP WG list as well to solicit more opinions.
>
> > I know others have been thinking about whether we need the full To and
> > From URLs (or a MD5 hash of them) in the Replaces header.  I'm not
> > convinced myself, but there is one possible scenario that could cause
> > trouble.  A RFC2543 UAC which is redirected directly to another
> > RFC2543 UAS (no proxies in between) could result in a call without any
> > tags (To tags are not mandatory in RFC2543 unless there are more than
> > one Via headers, ie a proxy in the path).  Now, we are down to relying
> > only on the uniqueness of the Call-ID.  Of course, any bis UA will use
> > From and To tags.
>
>   Since the Call-ID is unique, I don't see a matching problem.  We can
> also recommend that any UA which supports Replaces must also support
> bis (at least use tags).
>
> > The only other argument that I've heard that could sway me is that if
> > this actual situation was encountered in the real world, the result
> > would be disaster.  If a Gateway replaces the wrong session, then the
> > wrong session will be dropped and two parties that had no intention of
> > talking will suddenly be connected - a very hard thing to explain to
> > your customers!
>
>   I see this as the best argument for including the full call leg
> identification.
>
> > Wouldn't a MD5 hash of specific parts of the To and From headers
> > (user, host, port, and tags, with rules for default handling) answer
> > your concerns about URL escaping and header size and eliminate the
> > possibility of the wrong session being replaced?
>
>   If only a subset of the information in the To and From is required for
> the hash, is this any better than just the tags?  A call-leg matches
> when the full URI including parameters and all header parameters match.
> So, to _always_ match correctly, we must be complete.
>
>   The problem then becomes one of debugging.  We need to decide on a
> canonical form of a URI for conversions (remove all spaces and line
> folding, lower case everything you can, make sure you watch for quotes,
> careful for invalid URIs, etc etc), and then hope nobody messes up.  If
> someone's phone is sending Replaces headers which don't work and a
> customer complains, it's difficult to figure who's phone is broken,
> since all you have is the hash.
>
>   This may be an acceptable loss, since Replaces has the nice property
> that if things do go wrong and everyone has multi-line phones, the
> transfer will work fine, but somebody's phone may ring unexpectedly.
>
>   I'd rather just stick with the tags.
>
> > My main concern is that we finish this discussion now so that we can
> > finalize the attended transfer call flows now that REFER seems to be
> > stable.
>
>   I'd definitely like to see this issue closed.  More thoughts
> appreciated.
>
> > Billy Biggs wrote:
> >
> > > Dvir Oren (dvir@lucidvon.com):
> > >
> > > > Are the tags in 'to' and 'from' plus the call-id sufficient to
> > > > find a call-leg?  It appears from the replaces draft that this is
> > > > all is needed.  However, at least in my implementation, I also
> > > > need the 'to' and 'from' themselves, and not only the tags.
> > >
> > >   It's unclear to my why you feel so strongly about needing the full
> > > to and from headers.
> > >
> > >   In almost all cases, the call-id alone should be sufficient to
> > > identify an active call.  For Replaces, the only cases I can think
> > > of where the call-id might be insufficient are:
> > >
> > >   a) Two UAs answer the same call and both are accepted.  When an
> > >      INVITE arrives with a replaces, there is a possibility that
> > >      both UAs receive the INVITE (some transparent proxy may have
> > >      decided to fork it).  In this case, the UAs each check to see
> > >      who's tags are listed to determine if they should honour the
> > >      Replaces.
> > >
> > >   b) Some broken UA makes many calls under the same call-id.  In
> > >      this case, checking the tags is a cheap way of identifying
> > >      which call was intended.
> > >
> > >   Clearly in these cases, having the tags is useful, and having the
> > > full to and from would be more 'correct' (but AFAICT not, as you
> > > claim, required).  My reason for just using the tags is a
> > > practical one:  if the full to and from are used, the escaping and
> > > unescaping gets much worse for very little gain, and we've also
> > > greatly increased the length of the header.
> > >
> > >   I worry about:
> > >   Replaces: 8c43a98f-ff8f@dumbterm.net;to=billy@billybiggs.com%3bmobileid%3d9775
> > >                                       ;to-tag=88f787f
> > >
> > >   from:
> > >   Refer-To: sip:dvir@lucidvon.com?
> > >             Replaces=8c43a98f-ff8f@dumbterm.net%3bto%3dbilly@billybiggs.com
> > >                      %253bmobileid%253d9775%3dto-tag%3d88f787f
> > >
> > >   Where double-escape code decoding is required.
>
> --
> Billy Biggs                     bbiggs@dumbterm.net
> http://www.billybiggs.com/      wbiggs@uwaterloo.ca
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.


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


From sip-admin@ietf.org  Mon Jun 25 17:58:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28049;
	Mon, 25 Jun 2001 17:58:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27649;
	Mon, 25 Jun 2001 17:52:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27619
	for ; Mon, 25 Jun 2001 17:52:55 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27996
	for ; Mon, 25 Jun 2001 17:52:16 -0400 (EDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5PLoj406767;
	Mon, 25 Jun 2001 17:50:45 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-91.cisco.com [161.44.241.91])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ABN03781 (AUTH pkyzivat);
	Mon, 25 Jun 2001 17:52:13 -0400 (EDT)
Message-ID: <3B37B18E.EB9EDE56@cisco.com>
Date: Mon, 25 Jun 2001 17:47:58 -0400
From: Paul Kyzivat 
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Barry Desborough'" ,
        Bob Penfield ,
        "'sip@ietf.org'" 
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: [Sip-implementors] another problem related to multiple call legs
 at   UAC
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> > I like the NAK idea. Consider a prong of a fork which gets
> > routed to a PSDN
> > gateway. When the PSDN called party picks up, a connection
> > charge may be
> > incurred if the gateway gets ACK-followed-by-BYE
> 
> Don't confuse billing and SIP messaging. You can just as easily not charge
> users if a BYE follows the ACK by some small time lag.

[Beware - I freely admit I don't know squat about phone systems billing,
so take this with a grain of salt...]

The way I understood this conversation, the concern was that the gateway
would incur a charge from the PSTN. While it may be possible to detect
the ACK-quickly-followed-by-BYE and prevent the generation of a bill to
the SIP user by the gateway, the PSTN charge may still be present. If
the gateway is owned by the PSTN provider then this may not be an issue,
but if the gateway is owned by a separate enterprise or provider then it
could be a problem.

Of course, if the race condition that leads to this situation happens
infrequently enough then maybe nobody will care.

	Paul

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


From sip-admin@ietf.org  Mon Jun 25 18:16:59 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28431;
	Mon, 25 Jun 2001 18:16:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28596;
	Mon, 25 Jun 2001 18:12:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28563
	for ; Mon, 25 Jun 2001 18:12:35 -0400 (EDT)
Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28341
	for ; Mon, 25 Jun 2001 18:11:54 -0400 (EDT)
From: Jon.Peterson@level3.com
Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id WAA10541;
	Mon, 25 Jun 2001 22:12:32 GMT
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id WAA12273;
	Mon, 25 Jun 2001 22:12:32 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19)
	id ; Mon, 25 Jun 2001 16:12:32 -0600
Message-ID: <6384220893BCD411BDFE0008C791B79CA3E658@N0228IDC1.oss.level3.com>
To: rkhan@net2phone.com, Gonzalo.Camarillo@lmf.ericsson.se, sip@ietf.org,
        adam.roach@ericsson.com
Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-isup-01.txt
Date: Mon, 25 Jun 2001 16:12:30 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Thanks for your comments. Some responses below.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Romel Khan [mailto:rkhan@net2phone.com]
Sent: Monday, June 25, 2001 9:26 AM
To: 'Gonzalo Camarillo'; 'sip@ietf.org'; 'adam.roach@ericsson.com'
Subject: [SIP] I-D ACTION:draft-ietf-sip-isup-01.txt


A few questions/comments on ISUP to SIP mapping draft:

1. How this draft ties with "SIP Extensions for Caller Identity and Privacy"
needs to be addressed. The sip-privacy draft can be used for transporting II
digit information and presentation restriction information which is
important if the termination is a SIP endpoint.

 I agree that the relationship between these two needs to be clarified.
Our draft should adhere to any general SIP privacy mechanism that is defined
by the WG. It doesn't seem unlikely that the work represented in the DCS
sip-privacy draft could evolve into such a mechanism, but today it isn't
clear that the entities on which sip-privacy relies are required for the
operation of SIP-T. 

2. Sec. 12, pg 47: Talking about ANSI ISUP, it has been stated "the
recommended behaviour is sending REL in response to CRM". Rather, shouldn't
the recommended behaviour following GR-394 (which will not actually result
in sending SIP Invite until the IAM finally comes)? There could be SIP GWs
in USA which interfaces using SS7 using SS7 with PSTN Access Tandem switches
that follow GR-394 and could potentially send CRM. 

 The point here is that it doesn't make any sense for a SIP gateway to
receive a CRM from the SS7 side. If it does, it is probably the result of a
network configuration error, since CRMs are only used in MF-SS7 interworking
points (which is why they are discussed in 394). 

3. In up front sections such as sec. 6.2.1.1 tel URL has been mentioned in a
way to make me think that SIP URL is not allowed (until I read further on).
Won't it be clearer to say statements such as "telephone number in the tel
URL" as "telephone number in the tel URL or SIP URL"

 Since a SIP URI is potentially partially composed of a tel URL I don't
find this particularly misleading. 

4. Sec. 6.2.6, last sentence: Shouldn't ACM also be included in the body of
the 183 response? Only 180 response is mentioned.

 The preceding paragraph in that section mentions a couple of cases in
which 183 would be sent rather than 180. 

5. In sec. 6.2.1.1, page 16, 3rd para.: a set of parameters are called
"immediately useful". Why is Called Party Number (CPN) missing from this
list?

 This is a list of optional parameters. The preceding paragraphs
discuss the role of mandatory parameters like the CPN. 

Thanks.

Romel Khan
Ph: (732)-363-0213, x241



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

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


From sip-admin@ietf.org  Mon Jun 25 18:53:12 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28956;
	Mon, 25 Jun 2001 18:53:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29606;
	Mon, 25 Jun 2001 18:42:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29573
	for ; Mon, 25 Jun 2001 18:42:44 -0400 (EDT)
Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28812
	for ; Mon, 25 Jun 2001 18:42:04 -0400 (EDT)
Received: from iere.net.avaya.com (localhost [127.0.0.1])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5PMg2S17273
	for ; Mon, 25 Jun 2001 18:42:02 -0400 (EDT)
Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5PMg2E17261
	for ; Mon, 25 Jun 2001 18:42:02 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FDC8.2AC77498"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Subject: RE: [Sip] RE: [Sip-implementors] another problem related to multiple call legs at   UAC
Date: Mon, 25 Jun 2001 16:42:51 -0600
Message-ID: 
Thread-Topic: [Sip] RE: [Sip-implementors] another problem related to multiple call legs at   UAC
Thread-Index: AcD9tMDEMrSR4GdvT2uv5irJEI6PdAADwS6w
From: "Zmolek, Andrew (Andrew)" 
To: "Jonathan Rosenberg" ,
        "Barry Desborough" ,
        "Paul Kyzivat" ,
        "Bob Penfield" 
Cc: 
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C0FDC8.2AC77498
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

>> Another thing  Section 5.2 of bis 03.txt also says that
>> "A proxy client generates a CANCEL request for branches without
>>    a final response after it has forked a request and=20
>> receives a 2xx or
>>    6xx response from one of the branches. "
>> Whereas section 17.4, pg. 122 says that
>> "After receiving a 2xx, the server MAY terminate all other
>>              pending requests by sending a CANCEL request"
>>=20
>> Note that there is no "MAY" in section 5.2.
>
> These need to be consistent. Honestly, it should probably be a SHOULD
as
> opposed to a MAY in both places. Anyone object to me changing that?

Given that we already have a product that provides this kind of forking
across both the PBX and PSTN environments and whose default behavior is
to bridge all the parties that accept the call, it seems natural that we
would want to extend this to provide the same capability in the SIP
world, and perhaps extend this in other ways. Therefore, I strongly
object to the use of "SHOULD" here in place of "MAY" and suggest that if
alternative wording is required, something like the following be used:

"After receiving a 2xx, the server SHOULD either (1) drop all other
pending requests by sending a CANCEL request or (2) bridge or otherwise
provide an alternative service to each branch connection that responds
with a 2XX."=20

Note that "terminate" has a specific meaning in the voice world which is
not consistent with CANCEL as the text now reads. Call termination is
the completion of a process that starts with call origination, and while
I know we don't want to replicate the PSTN world, we would do well not
to muddy the terminology we share by equating termination with something
more akin to tear-down.=20

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

            zmolek@avaya.com
              +1 720 444 4001

------_=_NextPart_001_01C0FDC8.2AC77498
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Sip] RE: [Sip-implementors] another problem related to =
multiple call legs at   UAC





>> Another thing  Section 5.2 of bis 03.txt =
also says that


>> "A proxy client generates a CANCEL =
request for branches without


>>    a final response after it =
has forked a request and 


>> receives a 2xx or


>>    6xx response from one of =
the branches. "


>> Whereas section 17.4, pg. 122 says =
that


>> "After receiving a 2xx, the server MAY =
terminate all other


>>         &n=
bsp;    pending requests by sending a CANCEL =
request"


>> 


>> Note that there is no "MAY" in =
section 5.2.


>


> These need to be consistent. Honestly, it should =
probably be a SHOULD as


> opposed to a MAY in both places. Anyone object =
to me changing that?




Given that we already have a product that provides =
this kind of forking across both the PBX and PSTN environments and whose =
default behavior is to bridge all the parties that accept the call, it =
seems natural that we would want to extend this to provide the same =
capability in the SIP world, and perhaps extend this in other ways. =
Therefore, I strongly object to the use of "SHOULD" here in =
place of "MAY" and suggest that if alternative wording is =
required, something like the following be used:



"After receiving a 2xx, the server SHOULD either =
(1) drop all other pending requests by sending a CANCEL request or (2) =
bridge or otherwise provide an alternative service to each branch =
connection that responds with a 2XX." 



Note that "terminate" has a specific meaning =
in the voice world which is not consistent with CANCEL as the text now =
reads. Call termination is the completion of a process that starts with =
call origination, and while I know we don't want to replicate the PSTN =
world, we would do well not to muddy the terminology we share by =
equating termination with something more akin to tear-down. 



--Andy Zmolek


    Technology & Standards =
Engineer


      CTO Standards


        Avaya =
Inc.




          &nbs=
p; zmolek@avaya.com


          &nbs=
p;   +1 720 444 4001





------_=_NextPart_001_01C0FDC8.2AC77498--

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


From sip-admin@lists.bell-labs.com  Mon Jun 25 21:51:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03134
	for ; Mon, 25 Jun 2001 21:51:34 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E214E44341; Mon, 25 Jun 2001 21:52:09 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from femail1.rdc1.on.home.com (femail1.rdc1.on.home.com [24.2.9.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 745E044336
	for ; Mon, 25 Jun 2001 21:51:50 -0400 (EDT)
Received: from cybertron.div8.net ([24.114.8.64])
          by femail1.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP
          id <20010626015150.JVIA11457.femail1.rdc1.on.home.com@cybertron.div8.net>;
          Mon, 25 Jun 2001 18:51:50 -0700
Received: from vektor by cybertron.div8.net with local (Exim 3.12 #1 (Debian))
	id 15Ei6p-0000Fy-00; Mon, 25 Jun 2001 21:57:43 -0400
From: Billy Biggs 
To: "Daniel G. Petrie" 
Cc: Alan Johnston , Dvir Oren ,
        SIP List 
Subject: Re: [SIP] Replaces leg matching (was Re: [Sip-implementors] replaces)
Message-ID: <20010625215742.A980@div8.net>
References: <15130.21550.973473.551003@jodie.lucid> <20010604093456.A7248@div8.net> <3B21336E.4C1FF35C@wcom.com> <20010609004736.A243@div8.net> <3B37AF3A.EB9C81EE@pingtel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B37AF3A.EB9C81EE@pingtel.com>; from dpetrie@pingtel.com on Mon, Jun 25, 2001 at 05:38:02PM -0400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 25 Jun 2001 21:57:43 -0400

Daniel G. Petrie (dpetrie@pingtel.com):

> It was agreed at the Interim SIP meeting in Feb. that is was legal to
> create calls using the same call-id.  (i.e. on a conference bridge).
> There is no semantics assumed, it is just another call as long as the
> To or From field differ.

  Great.  Sure hope they use a new tag on their end. :)

> So call-id by itself is not sufficient.  Tags are optional in some
> cases of RFC2543.  So how do we ensure uniqueness:
> 1) Require 2543-bis for Replaces (i.e. MUST have To & From tags)

  I like this option best.

> 2) Require at least the user-id, host, port, tag parts of the To &
>    From fields

  Unfortunately, the full to and from are needed for leg matching.  If
we're only going to go part way, why not settle with the tags.  I'd like
to hear a few more opinions though.

> Billy Biggs wrote:
> 
> >   Alan,
> >
> >   I'm posting this to the SIP WG list as well to solicit more opinions.
> >
> > > I know others have been thinking about whether we need the full To and
> > > From URLs (or a MD5 hash of them) in the Replaces header.  I'm not
> > > convinced myself, but there is one possible scenario that could cause
> > > trouble.  A RFC2543 UAC which is redirected directly to another
> > > RFC2543 UAS (no proxies in between) could result in a call without any
> > > tags (To tags are not mandatory in RFC2543 unless there are more than
> > > one Via headers, ie a proxy in the path).  Now, we are down to relying
> > > only on the uniqueness of the Call-ID.  Of course, any bis UA will use
> > > From and To tags.
> >
> >   Since the Call-ID is unique, I don't see a matching problem.  We can
> > also recommend that any UA which supports Replaces must also support
> > bis (at least use tags).
> >
> > > The only other argument that I've heard that could sway me is that if
> > > this actual situation was encountered in the real world, the result
> > > would be disaster.  If a Gateway replaces the wrong session, then the
> > > wrong session will be dropped and two parties that had no intention of
> > > talking will suddenly be connected - a very hard thing to explain to
> > > your customers!
> >
> >   I see this as the best argument for including the full call leg
> > identification.
> >
> > > Wouldn't a MD5 hash of specific parts of the To and From headers
> > > (user, host, port, and tags, with rules for default handling) answer
> > > your concerns about URL escaping and header size and eliminate the
> > > possibility of the wrong session being replaced?
> >
> >   If only a subset of the information in the To and From is required for
> > the hash, is this any better than just the tags?  A call-leg matches
> > when the full URI including parameters and all header parameters match.
> > So, to _always_ match correctly, we must be complete.
> >
> >   The problem then becomes one of debugging.  We need to decide on a
> > canonical form of a URI for conversions (remove all spaces and line
> > folding, lower case everything you can, make sure you watch for quotes,
> > careful for invalid URIs, etc etc), and then hope nobody messes up.  If
> > someone's phone is sending Replaces headers which don't work and a
> > customer complains, it's difficult to figure who's phone is broken,
> > since all you have is the hash.
> >
> >   This may be an acceptable loss, since Replaces has the nice property
> > that if things do go wrong and everyone has multi-line phones, the
> > transfer will work fine, but somebody's phone may ring unexpectedly.
> >
> >   I'd rather just stick with the tags.
> >
> > > My main concern is that we finish this discussion now so that we can
> > > finalize the attended transfer call flows now that REFER seems to be
> > > stable.
> >
> >   I'd definitely like to see this issue closed.  More thoughts
> > appreciated.
> >
> > > Billy Biggs wrote:
> > >
> > > > Dvir Oren (dvir@lucidvon.com):
> > > >
> > > > > Are the tags in 'to' and 'from' plus the call-id sufficient to
> > > > > find a call-leg?  It appears from the replaces draft that this is
> > > > > all is needed.  However, at least in my implementation, I also
> > > > > need the 'to' and 'from' themselves, and not only the tags.
> > > >
> > > >   It's unclear to my why you feel so strongly about needing the full
> > > > to and from headers.
> > > >
> > > >   In almost all cases, the call-id alone should be sufficient to
> > > > identify an active call.  For Replaces, the only cases I can think
> > > > of where the call-id might be insufficient are:
> > > >
> > > >   a) Two UAs answer the same call and both are accepted.  When an
> > > >      INVITE arrives with a replaces, there is a possibility that
> > > >      both UAs receive the INVITE (some transparent proxy may have
> > > >      decided to fork it).  In this case, the UAs each check to see
> > > >      who's tags are listed to determine if they should honour the
> > > >      Replaces.
> > > >
> > > >   b) Some broken UA makes many calls under the same call-id.  In
> > > >      this case, checking the tags is a cheap way of identifying
> > > >      which call was intended.
> > > >
> > > >   Clearly in these cases, having the tags is useful, and having the
> > > > full to and from would be more 'correct' (but AFAICT not, as you
> > > > claim, required).  My reason for just using the tags is a
> > > > practical one:  if the full to and from are used, the escaping and
> > > > unescaping gets much worse for very little gain, and we've also
> > > > greatly increased the length of the header.
> > > >
> > > >   I worry about:
> > > >   Replaces: 8c43a98f-ff8f@dumbterm.net;to=billy@billybiggs.com%3bmobileid%3d9775
> > > >                                       ;to-tag=88f787f
> > > >
> > > >   from:
> > > >   Refer-To: sip:dvir@lucidvon.com?
> > > >             Replaces=8c43a98f-ff8f@dumbterm.net%3bto%3dbilly@billybiggs.com
> > > >                      %253bmobileid%253d9775%3dto-tag%3d88f787f
> > > >
> > > >   Where double-escape code decoding is required.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

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


From sip-admin@lists.bell-labs.com  Tue Jun 26 00:21:31 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07115
	for ; Tue, 26 Jun 2001 00:21:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 124A344353; Tue, 26 Jun 2001 00:22:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from femail4.rdc1.on.home.com (femail4.rdc1.on.home.com [24.2.9.91])
	by lists.bell-labs.com (Postfix) with ESMTP id F0E8644336
	for ; Tue, 26 Jun 2001 00:21:01 -0400 (EDT)
Received: from cybertron.div8.net ([24.114.8.64])
          by femail4.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP
          id <20010626042102.MMVY6738.femail4.rdc1.on.home.com@cybertron.div8.net>;
          Mon, 25 Jun 2001 21:21:02 -0700
Received: from vektor by cybertron.div8.net with local (Exim 3.12 #1 (Debian))
	id 15EkRD-0000H1-00; Tue, 26 Jun 2001 00:26:55 -0400
From: Billy Biggs 
To: Jonathan Rosenberg 
Cc: Alan Johnston , Dvir Oren ,
        SIP List 
Subject: Re: [SIP] Replaces leg matching (was Re: [Sip-implementors] repla ces)
Message-ID: <20010626002655.B1027@div8.net>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: ; from jdrosen@dynamicsoft.com on Mon, Jun 11, 2001 at 02:18:01AM -0400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 26 Jun 2001 00:26:55 -0400

Jonathan Rosenberg (jdrosen@dynamicsoft.com):

> >   Since the Call-ID is unique, I don't see a matching problem.  We
> > can also recommend that any UA which supports Replaces must also
> > support bis (at least use tags).
> 
> Another practical issue worth considering is that many implementations
> in gateways store call leg objects indexed by the hash of the call leg
> ID.  There is no direct index of calls based on call-id, since its
> really not needed. Therefore, it becomes a practical problem to find
> the matching call leg with just the call-id.

  This would be solved by having the full to and from in the header, but
putting instead a hash would just mean standardizing the hash function
used by gateways, or force them to index by another hash.

  If we're forcing them to index on another hash, I'd rather just let
that be the call-id + tags.

  Nasty situation regardless.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

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


From sip-admin@ietf.org  Tue Jun 26 01:16:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08701;
	Tue, 26 Jun 2001 01:16:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11903;
	Tue, 26 Jun 2001 01:00:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11876
	for ; Tue, 26 Jun 2001 01:00:37 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07743
	for ; Tue, 26 Jun 2001 00:59:59 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA29501;
	Tue, 26 Jun 2001 01:04:38 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 01:00:31 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Zmolek, Andrew (Andrew)'" ,
        Jonathan Rosenberg
	 ,
        Barry Desborough ,
        Paul Kyzivat ,
        Bob Penfield
	 
Cc: sip@ietf.org
Subject: RE: [Sip] RE: [Sip-implementors] another problem related to multi
	ple call legs at   UAC
Date: Tue, 26 Jun 2001 01:00:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org




-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com]
Sent: Monday, June 25, 2001 6:43 PM
To: Jonathan Rosenberg; Barry Desborough; Paul Kyzivat; Bob Penfield
Cc: sip@ietf.org
Subject: RE: [Sip] RE: [Sip-implementors] another problem related to
multiple call legs at UAC


>>> Another thing  Section 5.2 of bis 03.txt also says that 
>>> "A proxy client generates a CANCEL request for branches without 
>>>    a final response after it has forked a request and 
>>> receives a 2xx or 
>>>    6xx response from one of the branches. " 
>>> Whereas section 17.4, pg. 122 says that 
>>> "After receiving a 2xx, the server MAY terminate all other 
>>>              pending requests by sending a CANCEL request" 
>>> 
>>> Note that there is no "MAY" in section 5.2. 
>> 
>> These need to be consistent. Honestly, it should probably be a SHOULD as 
>> opposed to a MAY in both places. Anyone object to me changing that? 
>
>Given that we already have a product that provides this kind of forking
across 
>both the PBX and PSTN environments and whose default behavior is to bridge
all 
>the parties that accept the call, it seems natural that we would want to
extend 
>this to provide the same capability in the SIP world, and perhaps extend
this 
>in other ways. Therefore, I strongly object to the use of "SHOULD" here in 
>place of "MAY" and suggest that if alternative wording is required,
something 
>like the following be used:
>
>"After receiving a 2xx, the server SHOULD either (1) drop all other pending

>requests by sending a CANCEL request or (2) bridge or otherwise provide an 
>alternative service to each branch connection that responds with a 2XX." 

If your server does bridging, its not a proxy so this doesn't apply. A
B2BUA, which is what this would need to be, can do whatever it wants. Please
feel free to bridge as you are doing. With proxies, if the proxy doesn't
CANCEL, the UA will need to CANCEL. Since it doesn't know whether downstream
proxies forked, a UA would effectively need to CANCEL every time a 2xx
arrives. Really ugly. THe proxy that forks should do this.

-Jonathan R.


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

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


From sip-admin@ietf.org  Tue Jun 26 01:17:28 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08812;
	Tue, 26 Jun 2001 01:17:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12034;
	Tue, 26 Jun 2001 01:04:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11997
	for ; Tue, 26 Jun 2001 01:04:26 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07786
	for ; Tue, 26 Jun 2001 01:03:47 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA29432;
	Tue, 26 Jun 2001 00:55:37 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 00:51:30 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Billy Biggs'" ,
        Jonathan Rosenberg
	 
Cc: Alan Johnston , Dvir Oren ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Replaces leg matching (was Re: [Sip-implementors] repla
	 ces)
Date: Tue, 26 Jun 2001 00:51:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Billy Biggs [mailto:billy@billybiggs.com]
> Sent: Tuesday, June 26, 2001 12:27 AM
> To: Jonathan Rosenberg
> Cc: Alan Johnston; Dvir Oren; SIP List
> Subject: Re: [SIP] Replaces leg matching (was Re: [Sip-implementors]
> repla ces)
> 
> 
> Jonathan Rosenberg (jdrosen@dynamicsoft.com):
> 
> > >   Since the Call-ID is unique, I don't see a matching problem.  We
> > > can also recommend that any UA which supports Replaces must also
> > > support bis (at least use tags).
> > 
> > Another practical issue worth considering is that many 
> implementations
> > in gateways store call leg objects indexed by the hash of 
> the call leg
> > ID.  There is no direct index of calls based on call-id, since its
> > really not needed. Therefore, it becomes a practical problem to find
> > the matching call leg with just the call-id.
> 
>   This would be solved by having the full to and from in the 
> header, but
> putting instead a hash would just mean standardizing the hash function
> used by gateways, or force them to index by another hash.
> 
>   If we're forcing them to index on another hash, I'd rather just let
> that be the call-id + tags.
> 
>   Nasty situation regardless.

I don't want to standardize this hash. What is the issue with just including
the full To, From, Call-ID along with tags? Just the length?

-Jonathan R.

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

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


From sip-admin@ietf.org  Tue Jun 26 01:29:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09709;
	Tue, 26 Jun 2001 01:29:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20009;
	Tue, 26 Jun 2001 01:17:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19923
	for ; Tue, 26 Jun 2001 01:17:11 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08696
	for ; Tue, 26 Jun 2001 01:16:29 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA29687;
	Tue, 26 Jun 2001 01:21:08 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 01:17:01 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Bob Penfield'" ,
        Jonathan Rosenberg
	 ,
        "'Barry Desborough'" ,
        "'Paul Kyzivat'" 
Cc: sip@ietf.org
Date: Tue, 26 Jun 2001 01:16:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] RE: [Sip-implementors] another problem related to multiple call l
 egs at   UAC
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> Sent: Monday, June 25, 2001 4:45 PM
> To: Jonathan Rosenberg; 'Barry Desborough'; 'Paul Kyzivat'
> Cc: sip@ietf.org
> Subject: Re: [Sip-implementors] another problem related to 
> multiple call
> l egs at UAC
> 
> 
> Jonathan Rosenberg writes:
> 
> > Harpreet writes:
> > > Another thing  Section 5.2 of bis 03.txt also says that
> > > "A proxy client generates a CANCEL request for branches without
> > >    a final response after it has forked a request and
> > > receives a 2xx or
> > >    6xx response from one of the branches. "
> > > Whereas section 17.4, pg. 122 says that
> > > "After receiving a 2xx, the server MAY terminate all other
> > >              pending requests by sending a CANCEL request"
> > >
> > > Note that there is no "MAY" in section 5.2.
> >
> > These need to be consistent. Honestly, it should probably 
> be a SHOULD as
> > opposed to a MAY in both places. Anyone object to me changing that?
> >
> 
> Wouldn't that break the cancel-feature of the 
> Request-Disposition header in
> the caller preferences draft? If the proxies always cancel 
> the other legs,
> then clients that do fancy things with multiple answers could 
> never work.

No; caller preferences would override this otherwise default behavior.

> 
> For example, I use a one-number service (unfortunately PSTN 
> based) with a
> call screening feature that tells the callee who the call is 
> for and who is
> holding and asks the callee to press 1 to accept the call. The service
> simultaneouly rings my office, home, and cell phone. If this were
> implemented in SIP with a forking proxy to get to all the devices I
> registered, and the proxy canceled the unanswered call legs 
> as soon as one
> answered, I could not receive the call if my wife picked up 
> the home phone
> before I answered my office or cell phone.
> 
> I think it should be a MAY.

Won't help. The caller here doesn't know about this service, so they would
simply generate the CANCEL. Even if this weren't true, you have another
problem. Multiple accepted call legs would only be established under the
race condition where you and your wife pick up at once. What you REALLY want
is that when you wife picks up, you can still pick up that call (even though
your phone isn't ringing anymore) at any time until she hangs up, and then
press 1 to accept. THis is the standard home phone line behavior, which the
single line extension group was working on. Doing this properly requires far
more than just not cancelling.

I have some ideas on how to actually support this given our current set of
tools for conferencing, and so I will (hopefully) have a draft on how to
properly do it before London.

-Jonathan R.

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

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


From sip-admin@ietf.org  Tue Jun 26 01:44:38 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10515;
	Tue, 26 Jun 2001 01:44:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21204;
	Tue, 26 Jun 2001 01:40:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21177
	for ; Tue, 26 Jun 2001 01:40:14 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10345
	for ; Tue, 26 Jun 2001 01:39:35 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA29912;
	Tue, 26 Jun 2001 01:44:20 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 01:40:12 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Mathieu, Marie-Noelle'" ,
        "'sip@ietf.org'" 
Date: Tue, 26 Jun 2001 01:40:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] RE: [Sipping] Call and call-id
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This belongs on sip.

  
-----Original Message-----
From: Mathieu, Marie-Noelle [mailto:Marie-Noelle.Mathieu@compaq.com]
Sent: Monday, June 25, 2001 5:42 AM
To: 'sipping@ietf.org'
Subject: [Sipping] Call and call-id
>
>
>Hello,
>
>I have a doubt concerning the definition of a call-id.
>I read that a call "consists of all participants in a session invited by a 
>common source".
>
>I understand that one INVITE request (and so one call-id) may result with 
>several call-legs due to forking.
>
>My question is :  
>
> Is it possible to use the same call-id in 2 differents INVITE requests to
2 
>differents User Agents ? 
>
>
>Let say User Agent A invites User Agent B and user Agent C. Will it use the

>same call-id in the 2 INVITE requests, is this allowed ?

Well, the current spec would indicate that you shouldn't do this:

>The callid MUST be a globally unique identifier and MUST NOT be reused for 
>later calls.

However, I recall some discussion at an IETF that people were using the same
call-id across different call legs as a local identifier to correlate those
call legs. With unique From tags and From fields, there really shouldn't be
a problem, so I think its OK. However, if we are going to allow it, the spec
should reflect it. Comments?

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

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


From sip-admin@ietf.org  Tue Jun 26 01:46:44 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10671;
	Tue, 26 Jun 2001 01:46:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20956;
	Tue, 26 Jun 2001 01:32:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20925
	for ; Tue, 26 Jun 2001 01:32:02 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09871
	for ; Tue, 26 Jun 2001 01:31:24 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA29806;
	Tue, 26 Jun 2001 01:35:39 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 01:31:31 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Bob Penfield'" ,
        Jonathan Rosenberg
	 ,
        "'Barry Desborough'" ,
        "'Paul Kyzivat'" 
Cc: sip@ietf.org
Date: Tue, 26 Jun 2001 01:31:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] RE: reason code in BYE/CANCEL (was [Sip-implementors] another pro
 blem related to multiple call l egs at   UAC)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> Sent: Monday, June 25, 2001 5:04 PM
> To: Jonathan Rosenberg; 'Barry Desborough'; 'Paul Kyzivat'
> Cc: sip@ietf.org
> Subject: reason code in BYE/CANCEL (was [Sip-implementors] another
> problem related to multiple call l egs at UAC)
> 
> 
> 
> Jonathan Rosenberg wrote:
> >
> >
> >  Moving from sip-implementors to sip since there are some 
> open issues and
> > changes to bis in here.
> >
> >
> 
> 
> > Barry Desborough wrote:
> >
> > > I also agree that encoded reasons should be added to BYEs and
> > > CANCELs such
> > > that a PSDN gateway can map them to and from Q.931 cause codes.
> >
> > I also like these BYE reasons. This has come up countless 
> times. Its also
> > helpful in CANCEL, to know whether a call was cancelled 
> because the caller
> > aborted, or because some other branch picked up (the former 
> would generate
> a
> > missed call entry in a call log, whilst the other won't). I 
> don't think
> > Warning is right, but some kind of header that conveys both a
> > machine-interpretable and human-interpretable value would be good.
> >
> How about a "Reason" request header (or is that already 
> defined elswhere)
> that uses the same format as the Warning header?
> 
>         Reason        =  "Reason" ":" 1#reason-value
>         reason-value  =  reason-code SP reason-agent SP reason-text
>         reason-code   =  3DIGIT
>         reason-agent  =  host [ ":" port ]
>                           ;  the name of the server adding
>                           ;  the Reason header, for use in 
> tracing/debugging
>         reason-text   =  quoted-string
> 
> 
> 

Reason is not used. Seems reasonable for the header name.

I'm not sure the reason-agent is needed. 

The trick is defining the codes. A few I can think of:

400 Caller hung up
 
  this would be in a CANCEL if the UAC hangs up before an INVITE generates a
final response, or in a BYE at any point later. Its the normal call
termination case.

401 INVITE succeeded elsewhere 

  this would be in a CANCEL generated because an INVITE generated a 2xx on
another branch.

402 media stream failure

  this would be in a BYE that was sent because there was some failure in the
media streams or something like that.


other suggestions?

-Jonathan R.


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

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


From sip-admin@ietf.org  Tue Jun 26 02:08:52 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19445;
	Tue, 26 Jun 2001 02:08:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21672;
	Tue, 26 Jun 2001 01:59:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21641
	for ; Tue, 26 Jun 2001 01:59:50 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11513
	for ; Tue, 26 Jun 2001 01:59:11 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA00142;
	Tue, 26 Jun 2001 02:03:50 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 01:59:43 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'James Undery'" ,
        Jonathan Rosenberg
	 
Cc: aki.niemi@nokia.com, corey@hearme.com, sip@ietf.org
Subject: RE: [Sip] Request header integrity in HTTP Digest
Date: Tue, 26 Jun 2001 01:59:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: James Undery [mailto:jundery@ubiquity.net]
> Sent: Friday, June 22, 2001 3:45 AM
> To: Jonathan Rosenberg
> Cc: aki.niemi@nokia.com; corey@hearme.com; sip@ietf.org
> Subject: Re: [Sip] Request header integrity in HTTP Digest
> 
> 
> > It solves all three replay attacks presented section 2. It 
> won't solve the
> > MITM attacks if the attacker is smart and is careful about 
> modifying the
> > request in the same way between the original one and 
> resubmitted one.
> >
> > If you believe if doesn't solve the problems it claims to, 
> please indicate
> > clearly, for the three replay attacks, how these are not 
> prevented by the
> > mechanism, even though I claim they are.
> 
> You selected only cases this works for, failed to mention the 
> myriad of
> cases it
> is no use at all for. By dumbing down the attacks you protect 
> yourself from
> security is easy, why not have a Forged header that attackers 
> have to set to
> true and claim you can find all forged messages that are SIP 
> complient ;)

You are still missing the point.

My point is *not* that it fixes all problems. My point is that it fixes some
problems that regular digest has, and doesn't introduce any new security
weaknesses. In that case, how can one possibly object to it?

> 
> >
> > > HTTP is totally different from SIP I have no problem at all
> > > with that draft
> > > Section 4 is very clear about the limitations of the draft.
> >
> > I am missing your point here. SIP digest is identical to 
> http digest.
> >
> 
> SIP and HTTP share a lot of the same headers, request response model
> granted,
> but these similarities shouldn't fool you into thinking that 
> the protocols
> are
> similar. Transactions in SIP and HTTP are totally different 
> in nature, a
> security model for one does not map to a security model for the other.

Really? SIP references HTTP Basic and digest directly, since they are
directly useful in SIP. If the security models were not compatible, how
could we do this?


> 
> > Utter nonsense. Corey pointed out that the nonce should 
> include a private
> > key so that its not guessable. Guessing it doesn't help you 
> terribly much,
> > but fine, we'll do that. The same issue arises with regular digest.
> >
> 
> What Corey pointed out was a rouge poxy can request a UA to 
> register using a
> nonce that it knows a second proxy will give it at some time 
> in the future
> (of
> the rouge proxies choosing). If you think that is nonsense we 
> might as well
> stop
> discussing any security now.

James, this attack is possible in regular digest if you don't do the same
thing Corey suggests. Thus, your point is utter nonsense since you are
trying to argue against the mechanism based on general digest issues that
are not specific to the proposal at all. As I said, send a complaint to the
authors of rfc2617.

> 
> >
> > I claim that this approach improves security, since it 
> removes replay
> > attacks that require modification of the message. An 
> example is modifying
> > the Contact in a REGISTER to route calls to my phone. 
> Regular http digest
> > doesn't protect against this. The pnonce does. So, if you 
> still believe
> that
> > pnonce is useless, please argue that:
> >
> > 1. I am incorrect, and this attack is not possible with digest, or
> > 2. I am incorrect, and this attack is possible with digest, 
> but still
> > possible in my proposed approach.
> 
> As pointed out before UA sends a REGISTER with contact X. Bad 
> Guy changes X
> to Y
> and proxies on the request, the registrar 401 with contact Y 
> encrypted into
> the
> nonce. Bad guy proxies on this response, UA sends a REGISTER 
> with Contact X
> and
> credentials for Contact Y in the nonce. The bad guy changes X to Y and
> forwards
> to the registrar with the credentials provided by the UA. The 
> registrar
> accepts
> the registration with contact Y.

Sigh. I don't know how much clearer I can be. Perhaps if I try e-shouting.
THE ATTACK YOU DESCRIBE IS POSSIBLE IN REGULAR DIGEST!!!!! This attack is
not fixed by the pnonce and still exists there. I am not claiming that this
mechanism fixes all the problems in digest. I am claiming that it is better
than digest. I am claiming that because it fixes some attacks present in
regular digest, and introduces no new ones. So, your objections are
completely nonsense unless, as I requested above, you can demonstrate an
attack that is not possible with regular temporal-based + private key nonces
(i.e., nonce = H(round-time:key), but is present in a nonce that is
temporal-based + private key and includes a hash of some request headers
(i.e., a pnonce = H(round-time:key:request-headers)). 

> 
> 
> >
> > Continuously throwing out attacks that are still possible 
> with pnonces
> > proves nothing, and only shows that you continue to miss 
> the point. It
> only
> > proves that digest, with or without pnonce, are susceptible 
> to these. I
> have
> > offered, in the doc, three CONCRETE replay attacks that are 
> prevented with
> > pnonces. If you believe that this mechanism makes things 
> worse, please
> point
> > out a concrete attack which is not possible in regular 
> digest, but is now
> > possible with pnonces. If you cannot offer such an attack, then your
> claims
> > that it fixes nothing are bogus.
> 
> UA registers with Bad guy, bad guy constructs a pnonce it 
> knows a registrar
> will
> construct in an hours time using its IP address, headers the 
> server will
> protect
> and the round time an hour in the future. The UA 
> authenticates this and in
> an
> hour the bad guy replays the message and authenticates with 
> the credentials
> the
> UA provided an hour ago.

Well, there is one problem here, James. This attack is also possible in
regular digest if you use a nonce that is based on time rounded to the
nearest hour. Put a private key in the nonce, and it fixes this problem in
any challenge response mechanism, including the pnonce. My apologies for
leaving off the private key from the hash in the document. As I already
responded to Corey's original mail, he is correct and that security is
improved if its there. THats true for plain-old digest as well.

> 
> But submitting a draft that doesn't mention you are only 
> protected from
> these
> specific attacks but not more sophisticated ones youI haven't 
> mentioned
> provides
> the reader with a false sense of security. This is far worse than just
> pointing
> out the limitations. Selling snake oil will do SIP security 
> no favours.

There is a difference between claiming the draft doesn't mention problems
that remain, and claiming that the mechanism is worthless. You have accused
me of foolishness by proposing a worthless mechanism that makes security
worse. I claim that you are completely wrong, and that this mechanism fixes
many important attacks, yet introduces no new ones. So, do you, or do you
not, claim that this mechanism worsens security compared to more traditional
nonce computations?

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

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


From sip-admin@ietf.org  Tue Jun 26 02:22:29 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20462;
	Tue, 26 Jun 2001 02:22:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22106;
	Tue, 26 Jun 2001 02:07:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22073
	for ; Tue, 26 Jun 2001 02:07:40 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19337
	for ; Tue, 26 Jun 2001 02:07:01 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA00266;
	Tue, 26 Jun 2001 02:11:40 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 02:07:33 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Corey Gates'" ,
        Jonathan Rosenberg
	 ,
        "'sip@ietf.org'" 
Subject: RE: [Sip] Request header integrity in HTTP Digest
Date: Tue, 26 Jun 2001 02:07:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Corey Gates [mailto:corey@hearme.com]
> Sent: Thursday, June 21, 2001 4:55 PM
> To: 'Jonathan Rosenberg'; 'sip@ietf.org'
> Subject: RE: [Sip] Request header integrity in HTTP Digest
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> 
> >
> <>
> > 
> > It solves all three replay attacks presented section 2. It 
> won't solve the
> > MITM attacks if the attacker is smart and is careful about 
> modifying the
> > request in the same way between the original one and 
> resubmitted one. 
> 
> > If you believe if doesn't solve the problems it claims to, 
> please indicate
> > clearly, for the three replay attacks, how these are not 
> prevented by the
> > mechanism, even though I claim they are.
> >
> 
> I agree that the three specific replay attacks as described 
> in the document
> are mitigated with the use of pnonce.  Note that they are 
> also mitigated
> using standard 2617 nonces if the server rejects previously 
> used nonces
> during the timespan of the nonce, but this is not as nice.  

Right, and I point this out in the draft.

> 
> The problem I have is that a small modification of the replay 
> attacks are
> possible if the "private-key" is not included.  This small 
> modification is
> to get the client to authorize a "pnonce" the attacker 
> generates, which can
> then be used later.  Since there is no "private-key" included 
> in the hash,
> the server does not know that the pnonce was generated by the 
> attacker.
> This fake pnonce could include the headers and source IP that 
> the attacker
> wants to use.  Note that this is NOT a MITM attack, because 
> the attacker
> needs only to elicit an authorized INVITE or REGISTER from 
> the UAC, not
> intercept/forward a transaction.  This could be done by sending a
> constructed 401 as soon as the attacker sees any message 
> leaving the UAC.  

I agree completely. The lack of a private-key was not a statement that I
didn't think it should be there, but rather an omission. The idea is to add
a few more things to the nonce, not to remove some.

> Note that the draft could potentially be as simple as saying 
> that the "ETag"
> field used in generating nonces in 2617 is replaced with 
> " values>" and be done with it.

Another way of saying the same thing, sure.

>  This would be clear and understandable.
> pnonces are simply a method of assigning a resource tag to a 
> transaction set
> and otherwise follow 2617. 

Correct. Thats why I have said its an implementation choice and not a
protocol change.

> I think this is a good idea and a helpful draft.  I simply 
> want to keep the
> nonce generation par with 2617, so we need to include 
> "private-key" in the
> pnonce generation.

Agreed. Thanks for your helpful comments.

-Jonathan R.

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

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


From sip-admin@ietf.org  Tue Jun 26 02:28:35 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20999;
	Tue, 26 Jun 2001 02:28:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22375;
	Tue, 26 Jun 2001 02:16:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22345
	for ; Tue, 26 Jun 2001 02:16:35 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19997
	for ; Tue, 26 Jun 2001 02:15:56 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA00394;
	Tue, 26 Jun 2001 02:20:40 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 02:16:33 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'brett@broadsoft.com'" ,
        Jonathan Rosenberg
	 , sip@ietf.org
Subject: RE: [SIP] draft-ietf-sip-session-timer-04: INVITE with Require an
	d Support timer and Session-Expires
Date: Tue, 26 Jun 2001 02:16:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Brett Tate [mailto:brett@broadsoft.com]
> Sent: Thursday, June 21, 2001 10:20 PM
> To: 'Jonathan Rosenberg'; sip@ietf.org
> Subject: RE: [SIP] draft-ietf-sip-session-timer-04: INVITE 
> with Require
> and Support timer and Session-Expires
> 
> 
> Jonathan, 
> 
> Thanks for the response.  Comments inline.
> 
> > > What should happen if a UAC sends an INVITE 
> > > with Session-Expires and both Supported timer 
> > > and Require timer?
> > 
> > The Require implies Supported, so the behavior would be 
> > identical to the
> > case where just Require were present. This is probably an issue best
> > addressed in the Supported header specification, since its 
> > more general than
> > session timer.
> 
> The "Require implies Supported" needs to be 
> reflected in the timer draft since Table 3 
> is otherwise misleading if UAC includes 
> Require timer with session-expires without 
> Supported timer.

Good point.

> 
> If a UAC both requires and supports an option-tag, 
> should it include it in both headers?  

Its redundant. If it requires it, wouldn't that be because it supports it?

> 
> Isn't the "require implies supported" going to limit 
> devices that want to require others to support an 
> extension without them actually supporting it?

I can't think of a case where such a thing would make sense. Do you have a
specific example?


> 
> > > 
> > > What should happen if the UAS responds to such 
> > > a request and includes the same the three 
> > > headers and values?  Are both now effectively 
> > > responsible for sending refreshes?  Or is the 
> > > UAS forbidden from sending such a response?
> > 
> > These are good questions. A lot of it depends on what we mean 
> > when Require
> > is placed in the request. In principal, its quite useless. 
> > Require normally
> > means "don't process the request unless you understand the 
> > extension". But,
> > session timer works just fine even if the UAS doesn't support 
> > the extension.
> > So, based on this definition, inserting it has zero meaning. 
> > However, one
> > might think that Require in the INVITE means, "UAS, you 
> should do the
> > refreshes". 
> > 
> > I'm inclined to be consistent with normal Require usage. In 
> > this case, the
> > presence of Require in the INVITE has no impact on processing 
> > at the UAS if
> > it supports the extension. UAC will do the refreshes. If the 
> > UAC wants the
> > UAS to do them, the UAC can insert the Session-Timer 
> header, but not a
> > Supported header. This will result in the UAS doing them if 
> > it supports it,
> > otherwise there won't be session timers. 
> 
> Sounds fine.
> 
> It has some restrictions since the Supported 
> and Require headers are still being used to indicate 
> who is refreshing instead of what is supported 
> and required. 

Hmm, this is a good point. I am definitely overloading Supported and Require
to convey this information. I would be amenable to being more explicit about
it through a Session-Expires parameter, as you suggest. THis might simplify
the draft quite a bit, but there are folks who have implementations already
that might not like it (then again, it might be compatible anyway).

Anyone?



> However without an extra parameter 
> in Session-Expires to indicate who is refreshing, 
> I can't think of a better solution.
> 
> Actually the same parameter could be used to allow 
> for smaller Session-Expires values which are not to 
> be refreshed.
> 
> Session-Expires  =  
>   ("Session-Expires" | "x") ":" 
>               ( SIP-date | delta-seconds ) [refresher]
> 
> refresher = ";" "refresher" "=" "uas"|"uac"|"none"
> 

What would be the usage of none? I don't see the value in that...??

-Jonathan R.

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

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


From sip-admin@ietf.org  Tue Jun 26 02:38:54 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21740;
	Tue, 26 Jun 2001 02:38:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22677;
	Tue, 26 Jun 2001 02:27:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22650
	for ; Tue, 26 Jun 2001 02:27:00 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20820
	for ; Tue, 26 Jun 2001 02:26:20 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA00478;
	Tue, 26 Jun 2001 02:31:01 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 02:26:53 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'brett@broadsoft.com'" ,
        Jonathan Rosenberg
	 , sip@ietf.org
Subject: RE: [Sip] new open issue in session timer: NEEDS resolution now!
Date: Tue, 26 Jun 2001 02:26:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Brett Tate [mailto:brett@broadsoft.com]
> Sent: Thursday, June 21, 2001 7:37 PM
> To: 'Jonathan Rosenberg'; sip@ietf.org
> Subject: RE: [Sip] new open issue in session timer: NEEDS resolution
> now!
> 
> > The only sensible out that I see is to add back this 
> > Minimum-Timer header. A
> > UAC, when it gets a 422 Session Timer too small, remembers 
> > the value of the
> > Session-Expires in that response. It stores the largest value 
> > returned in
> > any 422 for the call leg in question. In any re-invites with 
> > session timers,
> > the UAC includes a Minimum-Timer header with this value. A 
> > proxy MUSTNOT
> > reduce the session timer below this value. 
> >
> 
> Using the 422 and Minimum-Timer sounds fine with 
> me.  It solves the problem while allowing for 
> Session-Expires negotiation.

OK, great.

> 
> The header name is also ok since the option-tag 
> for the draft is "timer".  Minimum-Session-Expires 
> seems a little more precise, but it is little 
> longer.

How about Min-SE?

> 
> Intentional or not, the solution reduces the 
> possibility of smaller Session-Expires values 
> that might want to be used in pre-paid services 
> through proxies.  

You're going to have troubles using session-timer for duration-based billing
for prepaid anyway.

> However I guess that it is 
> better than adding a parameter to
> Session-Expires to indicate that the session 
> will not or cannot be extended; thus please 
> allow this small value.  The parameter would
> also guarantee faster cleanup of sessions known 
> to be of a predetermined short length.

The minimum of 30min that we have discussed is a SHOULD, not a MUST. You can
put 1 minute in there if you want, and if none of the proxies object with a
422, you're good to go.

> 
> > I welcome any other suggestions....
> > 
> > Another requirement for this to work is that, when a UA 
> refreshes, it
> > inserts a session-expres with the same timer as the previous 
> > successful
> > re-INVITE, unless it explicitly wishes to disable session 
> > timers. Without
> > that, the smurf attack is still possible! Thats because, if 
> > each re-invite
> > doesn't contain the last session timer, no request will 
> actually ever
> > contain a session-expires, and so there is no opportunity for 
> > a proxy in
> > front of the attacking proxy to reject the low values 
> inserted by the
> > attacking proxy!
> 
> I'm not sure that I understand your reasoning 
> for requiring the same Session-Expires for 
> re-INVITEs that were in the previous INVITE.  
> Can't the whole renegotiation process take 
> place again among the entities that stayed 
> in the route?  This would force the smurf 
> requesting small values to stay in the route.  

Thats true, but I don't consider this sufficient deterrent for this attack
to be prevented. In any case, the session-expires can still be renegotiated.
However, I think the more common case is a constant session-timer for the
call leg anyway.

> If you are suggesting the use of the same 
> Minimum-Timer header to avoid the 422's, I agree.
> 

No, it was the same Session-Expires, not Minimum-Timer.

-Jonathan R.


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

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


From sip-admin@ietf.org  Tue Jun 26 02:54:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22934;
	Tue, 26 Jun 2001 02:54:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23535;
	Tue, 26 Jun 2001 02:48:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23453
	for ; Tue, 26 Jun 2001 02:48:07 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22433
	for ; Tue, 26 Jun 2001 02:47:28 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA00727;
	Tue, 26 Jun 2001 02:52:12 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 02:48:04 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: Jonathan Rosenberg ,
        "'Hidefumi Nakamura'"
	 ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Congestion control
Date: Tue, 26 Jun 2001 02:48:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-2022-jp"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This brings up an interesting question, actually. Does "try an alternate
server" mean that the next SRV record entry should be tried? If so, this
needs specification in draft-ietf-sip-srv.

-Jonathan R.

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

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, June 26, 2001 2:45 AM
> To: 'Hidefumi Nakamura'; 'sip@ietf.org'
> Subject: RE: [SIP] Congestion control
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Hidefumi Nakamura [mailto:nakamura.hidefumi@lab.ntt.co.jp]
> > Sent: Friday, June 22, 2001 9:17 AM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] Congestion control
> > 
> > 
> > Hi. all,
> > 
> > I have a couple of questions about the suitable way to let 
> > the user agents/
> > proxy-servers know the congestion of sip-proxy(stateful) or 
> > location server, 
> > and the suitable action after the notification.
> > 
> > As long as I review the sip document (rfc2543bis-03), I think
> > the most suitable way is to return a "503 service 
> unavailable" message
> > with "Retry-after" field.  Is is correct understanding?
> 
> Yes. 
> 
> > 
> > The other question is of the case when the INVITE request comes via
> > several (stateful) proxy servers.  That is, INVITE comes through
> > 
> > UAa --> proxy A --> proxy B --> UAb
> > 
> > and proxy B is in congestion.
> > 
> > In this case, proxy B will return a "503" message to 
> UserAgent-a (UAa)
> > via proxy A if my understanding of the first question is 
> > correct.  
> 
> Well, proxy A may or may not forward that upstream. The best 
> behavior for
> proxy A is to try some alternate, and only if all downstream 
> servers are
> unavailable should it return a 503 upstream.
> 
> 
> > UAa
> > will postpone to send a message to proxy A, but what should 
> "proxy A"
> > do if it receives other INVITE messages for proxyB, say, from 
> > UAc, within
> > the period indicated in "retry-after" field?
> > Should proxy-A send "503" to UAc or transfer the INVITE message
> > to proxy-B even if proxy-A already has the information that proxy-B
> > is in congestion?
> 
> Proxy-A should try somewhere else, and only return a 503 
> upstream if nothing
> is available.
> 
> I think the spec would benefit on some additional text on 503 
> handling.
> Specifically:
> 
> 1. 503 is the appropriate response to indicate congestion or any other
> resource constraints that make a server temporarily congested.
> 
> 2. A client receiving a 503 SHOULD attempt to contact an 
> alternate server.
> 
> 3. A server should generate and/or forward a 503 upstream only if all
> requests that would reach the server cannot be serviced. This 
> means that the
> server itself is congested, or every possible next-hop it can 
> route to is
> congested (which is fairly unlikely but can happen in certain
> configurations).
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

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


From sip-admin@lists.bell-labs.com  Tue Jun 26 02:58:30 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23240
	for ; Tue, 26 Jun 2001 02:58:29 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D79264434C; Tue, 26 Jun 2001 02:59:06 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 33D7A44336
	for ; Tue, 26 Jun 2001 02:58:36 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA00839;
	Tue, 26 Jun 2001 03:02:42 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 02:58:34 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Jasson Casey'" ,
        "'sip@lists.bell-labs.com'" 
Subject: RE: [SIP] [SIP]Transcoding
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 26 Jun 2001 02:58:26 -0400



 

> -----Original Message-----
> From: Jasson Casey [mailto:jcasey@pointone.com]
> Sent: Wednesday, June 20, 2001 2:20 PM
> To: 'sip@lists.bell-labs.com'
> Subject: [SIP] [SIP]Transcoding
> 
> 
> I was curious if there had been any work done on standard 
> call flows for
> transcoding devices. If anyone could point me to some 
> reference material it
> would be appreciated.

http://www.jdrosen.net/papers/draft-rosenberg-sip-hearingimpaired-00.txt
discusses translation services, including voice to video and voice to
text-over-RTP. While not the same as transcoding, I think the call flows
will be similar.

-Jonathan R.

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

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


From sip-admin@ietf.org  Tue Jun 26 03:14:45 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24262;
	Tue, 26 Jun 2001 03:14:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24272;
	Tue, 26 Jun 2001 03:01:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24212
	for ; Tue, 26 Jun 2001 03:01:41 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23427
	for ; Tue, 26 Jun 2001 03:01:00 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA00891;
	Tue, 26 Jun 2001 03:05:42 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 03:01:34 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Gonzalo Camarillo'" ,
        Jonathan Rosenberg 
Cc: "'Bob Penfield'" , adam.roach@ericsson.com,
        "'Rich Schaaf'" , sip@ietf.org
Subject: RE: [SIP] DNS SRV and authentication challenges
Date: Tue, 26 Jun 2001 03:01:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Monday, June 18, 2001 2:37 PM
> To: Jonathan Rosenberg
> Cc: 'Bob Penfield'; adam.roach@ericsson.com; 'Rich Schaaf'; 
> sip@ietf.org
> Subject: Re: [SIP] DNS SRV and authentication challenges
> 
> > One of the nice things about the current SRV mechanism is 
> that its nicely
> > layered. To properly implement it, I don't need to know the 
> conditions under
> > which the transaction is being initiated. If, all of a 
> sudden, I need to
> > know call level or header-level semantics in order to do 
> the right thing
> > with SRV, we get a code nightmare. Therefore, requiring 
> that the request for
> > the INVITE after a challenge result in the same SRV 
> decision as the previous
> > INVITE is a big mistake, IMHO.
> 
> I agree with you that the protocol should ONLY ensure that
> 1) retransmissions of a request
> 2) ACKs for non 2xx reponses
> 3) CANCELs
> are sent to the same network address than the initial request.
> 
> Since a second INVITE with authentication stuff is not any of these 3
> cases, we should use the randomization algorithm used for choosing one
> network address among all the SRV records provided.
> 
> 
> However, I do not agree that we run into a code nightmare. I believe
> that the code would be even simpler. Right now, in order to send
> retransmissions, CANCELs and ACKs to the same network address we
> typically use a hash of some fields, such as To, From, the 
> numeric part
> of the Cseq and the Call-ID. If intead of using all these variables we
> just use the Call-ID, all the requests within a call will be 
> sent to the
> same network address.

What I was objecting to was making the SRV process dependent on the
particular request scenario (i.e., special treatment for requests that are a
result of a 401/407). 

I have no issues with just using the Call-ID to generate the pseudo-random
number for SRV, as opposed to the transaction ID. As you have pointed out,
it seems to solve a few problems. Can anyone think of any difficulties this
change would introduce?

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

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


From sip-admin@ietf.org  Tue Jun 26 03:16:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24296;
	Tue, 26 Jun 2001 03:16:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23408;
	Tue, 26 Jun 2001 02:45:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23375
	for ; Tue, 26 Jun 2001 02:45:19 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22244
	for ; Tue, 26 Jun 2001 02:44:40 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA00699;
	Tue, 26 Jun 2001 02:49:22 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 02:45:15 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Hidefumi Nakamura'" ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Congestion control
Date: Tue, 26 Jun 2001 02:45:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-2022-jp"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Hidefumi Nakamura [mailto:nakamura.hidefumi@lab.ntt.co.jp]
> Sent: Friday, June 22, 2001 9:17 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Congestion control
> 
> 
> Hi. all,
> 
> I have a couple of questions about the suitable way to let 
> the user agents/
> proxy-servers know the congestion of sip-proxy(stateful) or 
> location server, 
> and the suitable action after the notification.
> 
> As long as I review the sip document (rfc2543bis-03), I think
> the most suitable way is to return a "503 service unavailable" message
> with "Retry-after" field.  Is is correct understanding?

Yes. 

> 
> The other question is of the case when the INVITE request comes via
> several (stateful) proxy servers.  That is, INVITE comes through
> 
> UAa --> proxy A --> proxy B --> UAb
> 
> and proxy B is in congestion.
> 
> In this case, proxy B will return a "503" message to UserAgent-a (UAa)
> via proxy A if my understanding of the first question is 
> correct.  

Well, proxy A may or may not forward that upstream. The best behavior for
proxy A is to try some alternate, and only if all downstream servers are
unavailable should it return a 503 upstream.


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

Proxy-A should try somewhere else, and only return a 503 upstream if nothing
is available.

I think the spec would benefit on some additional text on 503 handling.
Specifically:

1. 503 is the appropriate response to indicate congestion or any other
resource constraints that make a server temporarily congested.

2. A client receiving a 503 SHOULD attempt to contact an alternate server.

3. A server should generate and/or forward a 503 upstream only if all
requests that would reach the server cannot be serviced. This means that the
server itself is congested, or every possible next-hop it can route to is
congested (which is fairly unlikely but can happen in certain
configurations).

-Jonathan R.

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

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


From sip-admin@ietf.org  Tue Jun 26 03:30:50 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24415;
	Tue, 26 Jun 2001 03:30:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23688;
	Tue, 26 Jun 2001 02:52:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23661
	for ; Tue, 26 Jun 2001 02:52:37 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA22796
	for ; Tue, 26 Jun 2001 02:51:57 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA00760;
	Tue, 26 Jun 2001 02:56:32 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 02:52:24 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Paul Kyzivat'" ,
        Jonathan Rosenberg
	 
Cc: "'Michael Hammer'" ,
        "'Deepika Giri'"
	 ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Re-invites in a multi-party call
Date: Tue, 26 Jun 2001 02:52:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Thursday, June 21, 2001 7:01 PM
> To: Jonathan Rosenberg
> Cc: 'Michael Hammer'; 'Deepika Giri'; 'sip@ietf.org'
> Subject: Re: [SIP] Re-invites in a multi-party call
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> [snip] 
> > Right. If you send a re-INVITE with 0.0.0.0 in the SDP, you 
> will stop
> > receiving media. This has nothing to do with anyone else.
> 
> This is really only true with cooperative partners isn't it?

Sure, but its not that interesting to have a phone call with a UA that
doesn't actually want to cooperate with you. THere are lots of other things
it can choose to ignore (such as the entire INVITE in the first place).

-Jonathan R.

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

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


From sip-admin@ietf.org  Tue Jun 26 03:40:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24564;
	Tue, 26 Jun 2001 03:40:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24157;
	Tue, 26 Jun 2001 03:00:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24127
	for ; Tue, 26 Jun 2001 03:00:42 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23368
	for ; Tue, 26 Jun 2001 03:00:02 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA00794;
	Tue, 26 Jun 2001 02:59:12 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 02:55:04 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Gross, Gerhard'" ,
        "'bidulock@openss7.org'"
	 ,
        Jonathan Rosenberg 
Cc: "'Rosen, Brian'" ,
        "'Jiri Kuthan'"
	 ,
        Ashhar Farhan ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	 er
Date: Tue, 26 Jun 2001 02:54:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Gross, Gerhard [mailto:gerhard.gross@intel.com]
> Sent: Thursday, June 21, 2001 4:41 PM
> To: 'bidulock@openss7.org'; Jonathan Rosenberg
> Cc: 'Rosen, Brian'; 'Jiri Kuthan'; Ashhar Farhan; 'sip@ietf.org'
> Subject: RE: [SIP] Authentication and billing through proxy/re-direct
> serv er
> 
> 
> A solution to *ONE PIECE* of the AAA problem discussed
> in this thread is addressed by slapping a PEP (policy
> enforcement point) layer on top of the SIP proxy
> and using a AAA/policy server in the domain as
> the PDP (policy decision point). The COPS extension
> for SIP and usage instructions are specified in
> http://www.ietf.org/internet-drafts/draft-gross-cops-sip-01.txt.

Adding a layer of AAA does not help at all with the problems in this thread.
Those problems have to do with a proxy not having the same information on
call state as a gateway that actually provides service. Since the PDP knows
what the proxy knows, if the proxy can't know, how can the PDP? It can't.

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

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


From sip-admin@ietf.org  Tue Jun 26 04:01:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24796;
	Tue, 26 Jun 2001 04:01:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25752;
	Tue, 26 Jun 2001 03:48:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25721
	for ; Tue, 26 Jun 2001 03:48:44 -0400 (EDT)
Received: from mailweb17.rediffmail.com (IDENT:qmailr@[203.199.83.141])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24677
	for ; Tue, 26 Jun 2001 03:48:04 -0400 (EDT)
Received: (qmail 16021 invoked by uid 510); 26 Jun 2001 07:47:02 -0000
Date: 26 Jun 2001 07:47:02 -0000
Message-ID: <20010626074702.16019.qmail@mailweb17.rediffmail.com>
Received: from unknown (203.197.251.9) by rediffmail.com via HTTP; 26 Jun 2001 07:47:02 -0000
MIME-Version: 1.0
To: "jdrosen@dynamicsoft.com" ,
        "gerhard.gross@intel.com" ,
        "bidulock@openss7.org" 
Subject:  RE: [SIP] Authentication and billing through proxy/re-direct serv er
CC: "Brian.Rosen@marconi.com" ,
        "kuthan@fokus.gmd.de" ,
        "sip@ietf.org" 
From: "Ashhar Farhan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

i guess, that the issue of differing call-states
means that either the proxy or the gateway is right. therefore, logically, and arbitarirly, one has to be
accepted as having the right state.

now, if we accept that the gateway is right, and assume that given the current mechanism of a NOTIFY message already in place, it will make sense if the a NOTIFY message is generated from the gateway. NOTIFY message
as received at the proxy can be challenged for an MD5 based authentication and also forward to the INVITEr for statistical purpose.

as i see it, the rosenberg draft on NOTIFY usage is enough for the purpose being currently discussed. it is obvious that SIP cannot evolve an algorithm to arbitrate
between teh gateway and the proxy on differing call-states. SIP will have to assume that one of them is right. whichever entity is right, should communicate it's state to the misinformed entity via a NOTIFYcation.

- farhan@hotfoon.coim


_____________________________________________________
Buy Lagaan & Yaadein music for 30% less.
Avail this special offer at http://shopping.rediff.com/shopping/music/offerrediffmailer.htm 




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


From sip-admin@ietf.org  Tue Jun 26 04:16:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25021;
	Tue, 26 Jun 2001 04:16:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26137;
	Tue, 26 Jun 2001 04:00:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26110
	for ; Tue, 26 Jun 2001 04:00:04 -0400 (EDT)
Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24757
	for ; Tue, 26 Jun 2001 03:59:23 -0400 (EDT)
Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca
          via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 26 Jun 2001 08:59:52 UT
Received: (private information removed)
Message-ID: <3B384078.F36F3FBD@ubiquity.net>
From: James Undery 
To: Jonathan Rosenberg 
Cc: sip@ietf.org
Subject: Re: [Sip] Request header integrity in HTTP Digest
Date: Tue, 26 Jun 2001 03:57:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: James Undery [mailto:jundery@ubiquity.net]
>
> My point is *not* that it fixes all problems. My point is that it fixes
some
> problems that regular digest has, and doesn't introduce any new security
> weaknesses. In that case, how can one possibly object to it?

It fixes no problems in regular Digest Authentication, that is the point,
replay
attacks don't exist if you allow the client to only use a nonce once before
it
goes stale.


>
> > SIP and HTTP share a lot of the same headers, request response model

> > granted,
> > but these similarities shouldn't fool you into thinking that
> > the protocols
> > are
> > similar. Transactions in SIP and HTTP are totally different
> > in nature, a
> > security model for one does not map to a security model for the other.
>
> Really? SIP references HTTP Basic and digest directly, since they are
> directly useful in SIP. If the security models were not compatible, how
> could we do this?
>

Well I am in the process of writing a draft, I believe fixes HTTP digest so
it
works as well for SIP (i.e. it has only the same flaws as HTTP, but allows
the
server to check it is seeing what the client sent with the integrity of
relevant
headers intact.) A register request for instance requires the To, From,
Contact
and Expires headers remain intact for the integrity of the request. The big
problem is it will be a new scheme, requiring changes to servers and
clients,
something your draft doesn't require and the reason it adds nothing new (see
the
end of the message for the challenge if you think it does) .

I only hope people read it and tell me what it is I've missed, and as
security
is hard I know I'll have missed something.

>
> > What Corey pointed out was a rouge poxy can request a UA to
> > register using a
> > nonce that it knows a second proxy will give it at some time
> > in the future
> > (of
> > the rouge proxies choosing). If you think that is nonsense we
> > might as well
> > stop
> > discussing any security now.
>
> James, this attack is possible in regular digest if you don't do the same
> thing Corey suggests. Thus, your point is utter nonsense since you are
> trying to argue against the mechanism based on general digest issues that
> are not specific to the proposal at all. As I said, send a complaint to
the
> authors of rfc2617.
>

If you choose to ignore their advice and break the nonce generation, it
states
Security Considerations the importance of a proper nonce. In fact my only
issue
with rfc2617 is the don't mention about removal or downgrading of the qop
parameter as a possible attack to interfere with the body of the request.

> Sigh. I don't know how much clearer I can be. Perhaps if I try e-shouting.
> THE ATTACK YOU DESCRIBE IS POSSIBLE IN REGULAR DIGEST!!!!! This attack is
> not fixed by the pnonce and still exists there. I am not claiming that
this
> mechanism fixes all the problems in digest. I am claiming that it is
better
> than digest. I am claiming that because it fixes some attacks present in
> regular digest, and introduces no new ones. So, your objections are
> completely nonsense unless, as I requested above, you can demonstrate an
> attack that is not possible with regular temporal-based + private key
nonces
> (i.e., nonce = H(round-time:key), but is present in a nonce that is
> temporal-based + private key and includes a hash of some request headers
> (i.e., a pnonce = H(round-time:key:request-headers)).
>

And all the protection you describe is possible with no modification of
rfc2617
just use it as is, your scheme increases the chance of legitimate clients
failing and solves nothing but the most half-hearted attacks, my point is
why
bother producing yet another ID for people to implement that adds minimal
value.

> >
> > But submitting a draft that doesn't mention you are only
> > protected from
> > these
> > specific attacks but not more sophisticated ones youI haven't
> > mentioned
> > provides
> > the reader with a false sense of security. This is far worse than just
> > pointing
> > out the limitations. Selling snake oil will do SIP security
> > no favours.
>
> There is a difference between claiming the draft doesn't mention problems
> that remain, and claiming that the mechanism is worthless. You have
accused
> me of foolishness by proposing a worthless mechanism that makes security
> worse. I claim that you are completely wrong, and that this mechanism
fixes
> many important attacks, yet introduces no new ones. So, do you, or do you
> not, claim that this mechanism worsens security compared to more
traditional
> nonce computations?

No, I am not claiming you introduce new weaknesses now you're fixed the
private-key issue, the problem is this draft does nothing plain old HTTP
digest
doesn't do, by saying I will protect against attack X and attack X is
defended
by the base spec being implemented properly, you are just reiterating the
original spec. As you point out all the attacks I describe are possible
against
regular HTTP digest.

The challenge for you is to provide a single case where you are protecting
against an attack possible in rfc2617 (I will be choosing to generate nonces
as
per section 4.3 of rfc2617 and making them go stale after one use ).

James Undery


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


From sip-admin@ietf.org  Tue Jun 26 04:19:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25082;
	Tue, 26 Jun 2001 04:19:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26542;
	Tue, 26 Jun 2001 04:05:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26511
	for ; Tue, 26 Jun 2001 04:05:20 -0400 (EDT)
Received: from nt-mail.tlv.radvision.com ([212.143.185.30])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24851
	for ; Tue, 26 Jun 2001 04:04:40 -0400 (EDT)
Received: by NT-MAIL with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Jun 2001 11:05:50 +0300
Message-ID: 
From: Itamar Gilad 
To: "'SIP list'" 
Date: Tue, 26 Jun 2001 11:05:50 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1255"
Subject: [Sip] Consecutive REFERs
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Below are a couple of questions regarding REFER scenarios and appropriate
response code usage. I'm sorry if this has been asked before.

1) A sends a REFER to B directing it to call C.  B sets up a call with C
successfully.  Now A sends another (new) REFER to B directing it to contact
D.  B wants to reject this REFER on the grounds that it currently can't take
additional calls.  Is 486 the appropriate response?

2) Same as A, but this time the second REFER directs B to call C again.  B
wants to reject this on the grounds that it already has a call-leg setup
with C.  What's the response code B should use here?
 
Thanks,

Itamar Gilad
RADVISION
itamarg@radvision.com               24 Raul Wallenberg St.
tel: +972 3 7659938                 Building D
cel: +972 56 429938                 Tel-Aviv 69719
fax: +972 3 6472637                 Israel


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


From sip-admin@ietf.org  Tue Jun 26 04:47:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25379;
	Tue, 26 Jun 2001 04:47:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27557;
	Tue, 26 Jun 2001 04:30:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA27526
	for ; Tue, 26 Jun 2001 04:30:33 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25183
	for ; Tue, 26 Jun 2001 04:29:52 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f5Q8UUO00642
	for ; Tue, 26 Jun 2001 10:30:31 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.7])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5Q8UU528924
	for ; Tue, 26 Jun 2001 11:30:30 +0300 (EET DST)
Message-ID: <3B384823.AC343408@lmf.ericsson.se>
Date: Tue, 26 Jun 2001 11:30:27 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: multipart/mixed;
 boundary="------------AA895AFC6CB51755A6F79C23"
Subject: [Sip] Some thoughts about CANCEL for specific legs, together with SIP
 extensions
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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


Hi,

Some thoughts/issues came to my mind when I read the thread (the SIP
implementors list) about using CANCEL for specific call-legs.

I KNOW we have spent lots of time discussing this, but I am not pretty
sure that we have really thought about all the scenarios when some of
the SIP EXTENSIONS (in this mail I mention the Caller preferences-,
PRACK- and pre-call-setup requests features, and the scenario where the
UAC wants to choose specific call-legs for a call). 

Instead, I think we mostly have assumed that a call setup is simply an
INVITE, possible provisonal responses, and one or many final responses
plus their ACKs, and in those cases I don't think we have any major
problems.

I even think some of the extensions may LOOSE some of the good stuff
they are supposed to provide due to these issues.


Issue 1: Caller preferences

The Caller preferences feature allow the UAS to indicate the feature
parameter in the response. The draft mentions the 200 response, but I
guess it is (at least it should be) allowed also in a provisional
response with a To-tag and Contact header. So, now the UAC may at a very
early stage of the call setup find out about what kind of servers it has
received provisional responses from, which means it may at a very early
stage find out that it does not want a specific call-leg (for example,
one could receive provisional responses from two different answering
machinges, or something...). However, the UAC is not able to cancel any
call leg (without terminating the whole call setup) before it has
received a final response from one UAS, which means it may have to
handle PRACKs, INFOs, and who knows what, with all servers - also those
it will never establish a call with. A solution to this could be to
allow CANCEL for a specific leg (assuming that the provisional responses
included a To-tag and Contact). If PRACKs (or other requests used before
the call is setup) are involved, the provisinal responses most likely
will include the tag and Contact, so...


Issue 2: Multi-leg call

This could be related to the previous issue, but it can also be a "stand
alone" issue. Again, a UAC may receive multiple provisional responses.
It is going to establish a multi-leg call, ie it is going to accept a
specific set of final responses. Again, however, it receives provisonal
responses also from other servers, but again - it is not able to cancel
those legs before it has received the final responses for ALL parties
that will be in the multi-leg call. Allowing CANCEL for a specific leg
would help also here.

What also may happen here, is that we receive a final response for a leg
that we do NOT want in the call, but we still want to wait for another
final response. Now we could simply ACK and BYE that leg, but then we
come to the issue about sending BYE requests before the whole call has
been setup. However, the bis DOES say that BYE is used to terminate an
established call-leg, and that is what we would be doing here - no
matter if the WHOLE multi-leg call is setup or not - BUT, the bis also
says "To terminate a call instead of just pending searches, the UAC must
use BYE instead of or in addition to CANCEL". So, I guess some
clarifications in the bis may be needed here.



Conclusion:

So, I don't know if we are talking about changes, or simple
clarifications, in the spec, but the issues are:

1. Should we allow CANCEL for a specific call-leg, IF we have received a
To-tag and Contact in the provisional response?

2. Should we allow BYE for an established call-leg, even if the whole
call is yet not setup (the UAC is waiting for another final response)?

I know that we have the issue about a UAS receiving the same request
from different locations (when the request has been forked), so we have
to find out in which scenarios this can be a problem, and how likely it
is that those scenarios will take place.


Comments?

Regards,

Christer Holmberg
Ericsson Finland
--------------AA895AFC6CB51755A6F79C23
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------AA895AFC6CB51755A6F79C23--


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


From sip-admin@ietf.org  Tue Jun 26 06:02:50 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26147;
	Tue, 26 Jun 2001 06:02:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00306;
	Tue, 26 Jun 2001 05:52:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00272
	for ; Tue, 26 Jun 2001 05:52:52 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25979
	for ; Tue, 26 Jun 2001 05:52:11 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5Q9qnN04794
	for ; Tue, 26 Jun 2001 11:52:49 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.7])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5Q9qm502014
	for ; Tue, 26 Jun 2001 12:52:48 +0300 (EET DST)
Message-ID: <3B385B6D.BD124609@lmf.ericsson.se>
Date: Tue, 26 Jun 2001 12:52:45 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org
Subject: Re: [Sip] Some thoughts about CANCEL for specific legs, together with 
 SIPextensions
References: <3B384823.AC343408@lmf.ericsson.se>
Content-Type: multipart/mixed;
 boundary="------------7D34628EF9CE576FDCCE1681"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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


Hi,

Some clarificatons to my previous mail.

>Hi,
> 
>Some thoughts/issues came to my mind when I read the thread (the SIP
>implementors list) about using CANCEL for specific call-legs.
> 
>I KNOW we have spent lots of time discussing this, but I am not pretty
>sure that we have really thought about all the scenarios when some of
>the SIP EXTENSIONS (in this mail I mention the Caller preferences-,
>PRACK- and pre-call-setup requests features, and the scenario where the
>UAC wants to choose specific call-legs for a call).
> 
>Instead, I think we mostly have assumed that a call setup is simply an
>INVITE, possible provisonal responses, and one or many final responses
>plus their ACKs, and in those cases I don't think we have any major
>problems.
> 
>I even think some of the extensions may LOOSE some of the good stuff
>they are supposed to provide due to these issues.
> 
>Issue 1: Caller preferences
> 
>The Caller preferences feature allow the UAS to indicate the feature
>parameter in the response. The draft mentions the 200 response, but I
>guess it is (at least it should be) allowed also in a provisional
>response with a To-tag and Contact header. So, now the UAC may at a very
>early stage of the call setup find out about what kind of servers it has
>received provisional responses from, which means it may at a very early
>stage find out that it does not want a specific call-leg (for example,
>one could receive provisional responses from two different answering
>machinges, or something...). However, the UAC is not able to cancel any
>call leg (without terminating the whole call setup) before it has
>received a final response from one UAS, which means it may have to
>handle PRACKs, INFOs, and who knows what, with all servers - also those
>it will never establish a call with. A solution to this could be to
>allow CANCEL for a specific leg (assuming that the provisional responses
>included a To-tag and Contact). If PRACKs (or other requests used before
>the call is setup) are involved, the provisinal responses most likely
>will include the tag and Contact, so...
> 
>Issue 2: Multi-leg call
> 
>This could be related to the previous issue, but it can also be a "stand
>alone" issue. Again, a UAC may receive multiple provisional responses.
>It is going to establish a multi-leg call, ie it is going to accept a
>specific set of final responses. Again, however, it receives provisonal
>responses also from other servers, but again - it is not able to cancel
>those legs before it has received the final responses for ALL parties
>that will be in the multi-leg call. Allowing CANCEL for a specific leg
>would help also here.
> 
>What also may happen here, is that we receive a final response for a leg
>that we do NOT want in the call, but we still want to wait for another
>final response. Now we could simply ACK and BYE that leg, but then we
>come to the issue about sending BYE requests before the whole call has
>been setup. However, the bis DOES say that BYE is used to terminate an
>established call-leg, and that is what we would be doing here - no
>matter if the WHOLE multi-leg call is setup or not - BUT, the bis also
>says "To terminate a call instead of just pending searches, the UAC must
>use BYE instead of or in addition to CANCEL". So, I guess some
>clarifications in the bis may be needed here.

First, since multi-leg calls, ie conferences, are handled in a different
way I guess that can be dropped from this issue. 

Also, when I talked about not accepting the first 200, I did not only
mean clients, but also a forking proxies (and, since it has been said
that proxies SHOULD cancel all the other legs when the first 200 is
received, it SHOULD not even be an issue for a client). However, the
issue is if the proxy should be able NOT to accept and forward the first
200, since it has received provisonal responses also from another UAS
that it wants to be in the call.
 
> Conclusion:
> 
> So, I don't know if we are talking about changes, or simple
> clarifications, in the spec, but the issues are:
> 
> 1. Should we allow CANCEL for a specific call-leg, IF we have received a
> To-tag and Contact in the provisional response?
> 
> 2. Should we allow BYE for an established call-leg, even if the whole
> call is yet not setup (the UAC is waiting for another final response)?

Again, the second issue is only valid for forking proxies, IF they
cancel all other legs when the first 200 is received.


Regards,

Christer Holmberg
Ericsson Finland





> 
> I know that we have the issue about a UAS receiving the same request
> from different locations (when the request has been forked), so we have
> to find out in which scenarios this can be a problem, and how likely it
> is that those scenarios will take place.
> 
> Comments?
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
--------------7D34628EF9CE576FDCCE1681
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------7D34628EF9CE576FDCCE1681--


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


From sip-admin@lists.bell-labs.com  Tue Jun 26 08:19:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29787
	for ; Tue, 26 Jun 2001 08:19:34 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9BCC54434D; Tue, 26 Jun 2001 08:20:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53])
	by lists.bell-labs.com (Postfix) with ESMTP id EB3AB44336
	for ; Tue, 26 Jun 2001 08:19:59 -0400 (EDT)
Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id ;
 Tue, 26 Jun 2001 13:19:48 +0100
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-32) id NAA14947; Tue, 26 Jun 2001 13:19:53 +0100 (BST)
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 80256A77.0043B516 ; Tue, 26 Jun 2001 13:19:32 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Wayne Cutler" 
To: Gonzalo Camarillo 
Cc: sip@lists.bell-labs.com
Message-ID: <80256A77.0043AEE0.00@marconicomms.com>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] Re: Re Mapping of ISUP overlap signalling to SIP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 26 Jun 2001 13:19:20 +0100



>Hello,

>There have been millons of mails sent to the mailins list in the past
>discussing exactly what you are proposing. Besides, this has been
>presented in several WG meetings.

>Feel free to check the archives to find more information about this.

Whilst here has been a good deal of discussion on the general topic (over at
least 3 threads), the vast majority
were concerned with including the overlap digits in various SIP headers.
Therefore, there hasn't been a great deal
of discussion about making the SIP headers independent of the overlap digits. I
do recall your presentation in the last
WG meeting but that suggested sending multiple INVITEs and (as I recall) there
was nothing said about the option of
making the SIP headers independent of the overlap digits.

So, for limited scenarios, I fail to see why it is wrong/improper to make the
headers independent of the overlap digits. Such an
approach is workable and  does not require any changes to the SIP protocol. So
why can't it be added as another option, with a
suitable health warning about its limited applicability?

Wayne.



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


From sip-admin@ietf.org  Tue Jun 26 09:06:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01795;
	Tue, 26 Jun 2001 09:06:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06264;
	Tue, 26 Jun 2001 08:49:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA06233
	for ; Tue, 26 Jun 2001 08:49:50 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00965
	for ; Tue, 26 Jun 2001 08:49:10 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A47015B0264; Tue, 26 Jun 2001 08:47:44 -0400
Message-ID: <005c01c0fe3e$432e2920$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: "Jonathan Rosenberg" 
Cc: 
References: 
Subject: Re:[Sip] [Sip-implementors] another problem related to multiple call l egs at   UAC
Date: Tue, 26 Jun 2001 08:48:11 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg writes:

> Bob Penfield writes:
> > Jonathan Rosenberg writes:
> > 
> >
> > For example, I use a one-number service (unfortunately PSTN
> > based) with a
> > call screening feature that tells the callee who the call is
> > for and who is
> > holding and asks the callee to press 1 to accept the call. The service
> > simultaneouly rings my office, home, and cell phone. If this were
> > implemented in SIP with a forking proxy to get to all the devices I
> > registered, and the proxy canceled the unanswered call legs
> > as soon as one
> > answered, I could not receive the call if my wife picked up
> > the home phone
> > before I answered my office or cell phone.
> >
> > I think it should be a MAY.
>
> Won't help. The caller here doesn't know about this service, so they would
> simply generate the CANCEL. Even if this weren't true, you have another
> problem. Multiple accepted call legs would only be established under the
> race condition where you and your wife pick up at once. What you REALLY
want
> is that when you wife picks up, you can still pick up that call (even
though
> your phone isn't ringing anymore) at any time until she hangs up, and then
> press 1 to accept. THis is the standard home phone line behavior, which
the
> single line extension group was working on. Doing this properly requires
far
> more than just not cancelling.
>
> I have some ideas on how to actually support this given our current set of
> tools for conferencing, and so I will (hopefully) have a draft on how to
> properly do it before London.
>
You don't necessarily need conferencing to do this.

To implement this service in SIPland would require some sort of application
server to prompt callees with the screening information. BTW, as long as my
wife does not press 1 to accept the call, I can still pick up the call even
if I answer long after she does because the service keeps ringing the other
phones until a callee presses 1.

But anyway, it would look something like this:

+--------+              +------------+              +-----+------------>
home
| caller |------------->| app server |------------->|proxy|------------>
office
+--------+              +------------+              +-----+------------>
cell

The SIP URL people use to call me would point to the app server. The app
server would know to send an invite to my local proxy/registrar. The app
server would act as a B2BUA or connect to the accepting callee using REFER.
But in this case, the app server is the UAC that is capable of handling
multiple 200-OKs (it would send SDP in the ACK as opposed to the INVITE).
The app server would issue a cancel when the callee accepts by pressing 1.
If my local proxy always canceled incomplete legs when it got the first
200-OK, it breaks the application. And if the proxy does not support caller
preferences, then the app server can't tell it not to cancel.

(-:bob

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



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


From sip-admin@ietf.org  Tue Jun 26 10:11:48 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09220;
	Tue, 26 Jun 2001 10:11:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08240;
	Tue, 26 Jun 2001 09:39:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08159
	for ; Tue, 26 Jun 2001 09:39:35 -0400 (EDT)
Received: from exch-nyc1.deltathree.com ([213.137.71.26])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04585
	for ; Tue, 26 Jun 2001 09:38:53 -0400 (EDT)
Received: from exch-jlm2.deltathree.com (n171-18.deltathree.com [208.170.171.18]) by exch-nyc1.deltathree.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id NJQY7HW6; Tue, 26 Jun 2001 09:37:52 -0400
Received: by exch-jlm2.deltathree.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Jun 2001 16:35:41 +0300
Message-ID: 
From: David Schwartz 
To: "'Jonathan Rosenberg'" ,
        "'Jiri Kuthan'"
	 ,
        "'Rosen, Brian'" ,
        "'Jay Batson'" ,
        "'Ashhar Farhan'"
	 ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct  ser
	ver
Date: Tue, 26 Jun 2001 16:35:40 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Hi Jonathan.

I think all would agree that the ideal place for call control is in the
Voice Gateway. It is already stateful and it is the only element as you said
that has a true picture of which calls are connected and which are not. The
problem faced too often, however, is that a particular company doesn't want
to terminate traffic yet they want to bill for the service. Another scenario
might be if a call passes through more than one network before termination.
In that case each network owner might want to charge for use of his/her
network. There must a mechanism within these networks to detect call
completion.

With that said, I think your point about synchronization is a good one and I
can think of a few ways to solve it. 

The best way I believe would be for the call controller to SUBSCRIBE to the
gateway for a BYE event notification. In this way, the call controller would
not terminate any traffic when receiving a BYE but rather when receiving a
NOTIFY with the BYE event specified. All information necessary for the
Account Stop would then be contained in the body of the NOTIFY message. I
prefer this method since it allows the call controller to remains
essentially stateless. The problem is that at last count most GW
manufacturers have yet to fully implement SUBSCRIBE/NOTIFY on their
gateways.

An alternate approach might be to have the call controller set a session
timer between it and the gateway. The time interval can be as much as a
minute since most companies charge on a per minute basis. In this scenario
if indeed the Max-Forwards was set to end at the call controller, the call
controller would close the session thereby ceasing to send the re-INVITE
with the updated session time so the voice gateway would defacto close the
session. The reason I like this event less is because it forces the call
controller to be call stateful.

There are a few other mechanisms I can think of but I think these two will
suffice.

David Schwartz

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Thu, June 21, 2001 6:51 PM
To: David Schwartz; 'Jiri Kuthan'; 'Rosen, Brian'; 'Jay Batson'; 'Ashhar
Farhan'; 'sip@ietf.org'
Subject: RE: [SIP] Authentication and billing through proxy/re-direct
ser v er




 

> -----Original Message-----
> From: David Schwartz [mailto:davids@deltathree.com]
> Sent: Thursday, June 21, 2001 9:30 AM
> To: 'Jiri Kuthan'; 'Rosen, Brian'; 'Jay Batson'; 'Ashhar Farhan';
> 'sip@lists.bell-labs.com'
> Subject: RE: [SIP] Authentication and billing through proxy/re-direct
> ser v er
> 
> Here to it is important to look at the pros and cons in doing 
> this in an
> internal proxy Vs. using the gateway. The big con in using 
> the proxy is that
> it causes another statefull element in the network and since 
> the VG must be
> statefull anyway why have another statefull element. In 
> addition when it
> comes to the call stop (CDR creation) there is some 
> information that might
> be needed about the user (e.g. internal username) that may 
> only be available
> from the call start response. So the typical solution is to 
> use the VG. The
> con with using the VG is that you must own the VG. If you 
> wish to terminate
> on someone elses network it can be tricky retrieving the CDR's. 
> 
> One possible stateless solution might be to use the proxy for 
> call start and
> call stop. The Record-Route header is used to ensure that the 
> proxy sees the
> BYE message. Any proxy that gets an invite generates a call start (on
> receiving the 200 OK) which writes to some file that a 
> particular callID has
> started a call at this particular time, and any proxy getting a BYE
> generates a call stop which writes to a file (potentialy on a 
> different
> machine) that a particular callID has stopped a call at a 
> different time.
> There is no state that needs to be saved. Instead, a different process
> constantly moniters these files and correlates the call 
> starts with the call
> stops. This seperate process is the one that generates the 
> CDR's. This also
> reduces the load on the VG's enabling them to focus on the 
> call setup and
> teardown.

Using a proxy to generate minutes of usage is very hard. Ultimately, the
gateway knows the call call duration, as it is the arbiter of whether the
call is still in progress with the PSTN. For proxy-based duration to work,
you need to be able to prove that the proxy is always in continuous
synchronization (in terms of call state) with the gateway, within a
reasonable time lag. So, can you prove that an attacker cannot force the
proxy and gateway to go out of sync? I know of several attacks that are
possible in order to convince the proxy that the call is down, but the
gateway that the call is up (Max-Forwards values which cause the BYE to pass
the proxy but fail at the gateway, for example). This results in free
service. Someone more creative than I might come up with a few more.

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


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


From sip-admin@ietf.org  Tue Jun 26 10:11:57 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09231;
	Tue, 26 Jun 2001 10:11:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08944;
	Tue, 26 Jun 2001 09:55:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08914
	for ; Tue, 26 Jun 2001 09:55:37 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06648
	for ; Tue, 26 Jun 2001 09:54:56 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A3DC18D0264; Tue, 26 Jun 2001 09:53:32 -0400
Message-ID: <00e201c0fe47$6c470260$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: "Christer Holmberg" , 
References: <3B384823.AC343408@lmf.ericsson.se> <3B385B6D.BD124609@lmf.ericsson.se>
Subject: Re: [Sip] Some thoughts about CANCEL for specific legs, together with  SIPextensions
Date: Tue, 26 Jun 2001 09:53:45 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Christer Holmberg" 
To: 
Sent: Tuesday, June 26, 2001 5:52 AM
Subject: Re: [Sip] Some thoughts about CANCEL for specific legs, together
with SIPextensions


>
> Hi,
>
> Some clarificatons to my previous mail.
>
> >Hi,
> >
> >Some thoughts/issues came to my mind when I read the thread (the SIP
> >implementors list) about using CANCEL for specific call-legs.
> >
> >I KNOW we have spent lots of time discussing this, but I am not pretty
> >sure that we have really thought about all the scenarios when some of
> >the SIP EXTENSIONS (in this mail I mention the Caller preferences-,
> >PRACK- and pre-call-setup requests features, and the scenario where the
> >UAC wants to choose specific call-legs for a call).
> >
> >Instead, I think we mostly have assumed that a call setup is simply an
> >INVITE, possible provisonal responses, and one or many final responses
> >plus their ACKs, and in those cases I don't think we have any major
> >problems.
> >
> >I even think some of the extensions may LOOSE some of the good stuff
> >they are supposed to provide due to these issues.
> >
> >Issue 1: Caller preferences
> >
> >The Caller preferences feature allow the UAS to indicate the feature
> >parameter in the response. The draft mentions the 200 response, but I
> >guess it is (at least it should be) allowed also in a provisional
> >response with a To-tag and Contact header. So, now the UAC may at a very
> >early stage of the call setup find out about what kind of servers it has
> >received provisional responses from, which means it may at a very early
> >stage find out that it does not want a specific call-leg (for example,
> >one could receive provisional responses from two different answering
> >machinges, or something...). However, the UAC is not able to cancel any
> >call leg (without terminating the whole call setup) before it has
> >received a final response from one UAS, which means it may have to
> >handle PRACKs, INFOs, and who knows what, with all servers - also those
> >it will never establish a call with. A solution to this could be to
> >allow CANCEL for a specific leg (assuming that the provisional responses
> >included a To-tag and Contact). If PRACKs (or other requests used before
> >the call is setup) are involved, the provisinal responses most likely
> >will include the tag and Contact, so...
> >
> >Issue 2: Multi-leg call
> >
> >This could be related to the previous issue, but it can also be a "stand
> >alone" issue. Again, a UAC may receive multiple provisional responses.
> >It is going to establish a multi-leg call, ie it is going to accept a
> >specific set of final responses. Again, however, it receives provisonal
> >responses also from other servers, but again - it is not able to cancel
> >those legs before it has received the final responses for ALL parties
> >that will be in the multi-leg call. Allowing CANCEL for a specific leg
> >would help also here.
> >
> >What also may happen here, is that we receive a final response for a leg
> >that we do NOT want in the call, but we still want to wait for another
> >final response. Now we could simply ACK and BYE that leg, but then we
> >come to the issue about sending BYE requests before the whole call has
> >been setup. However, the bis DOES say that BYE is used to terminate an
> >established call-leg, and that is what we would be doing here - no
> >matter if the WHOLE multi-leg call is setup or not - BUT, the bis also
> >says "To terminate a call instead of just pending searches, the UAC must
> >use BYE instead of or in addition to CANCEL". So, I guess some
> >clarifications in the bis may be needed here.
>
> First, since multi-leg calls, ie conferences, are handled in a different
> way I guess that can be dropped from this issue.
>
> Also, when I talked about not accepting the first 200, I did not only
> mean clients, but also a forking proxies (and, since it has been said
> that proxies SHOULD cancel all the other legs when the first 200 is
> received, it SHOULD not even be an issue for a client). However, the
> issue is if the proxy should be able NOT to accept and forward the first
> 200, since it has received provisonal responses also from another UAS
> that it wants to be in the call.
>
> > Conclusion:
> >
> > So, I don't know if we are talking about changes, or simple
> > clarifications, in the spec, but the issues are:
> >
> > 1. Should we allow CANCEL for a specific call-leg, IF we have received a
> > To-tag and Contact in the provisional response?
> >

I personally like the idea.

> > 2. Should we allow BYE for an established call-leg, even if the whole
> > call is yet not setup (the UAC is waiting for another final response)?

If by "established call-leg", you mean one that has received a 2xx response,
sending BYE is just for that leg is just fine.

Section 6 of bis-03 says we SHOULD NOT send a BYE to terminate a request
that has not recieved either a final or provisional response. Does that mean
we can send BYE if we have received a provisional response? A UAS is suppose
to cancel a call-leg that it has not generated a final response for if it
gets a BYE. Is it legal (and desireable) to terminate a provisional call-leg
with BYE?

>
> Again, the second issue is only valid for forking proxies, IF they
> cancel all other legs when the first 200 is received.

If a provisional response had reached the UAC shouldn't that UAC still get a
487 response when the proxy cancels the call leg? Or would that only happen
if the provisional response is PRACK'd?

>
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
>
>
>
> >
> > I know that we have the issue about a UAS receiving the same request
> > from different locations (when the request has been forked), so we have
> > to find out in which scenarios this can be a problem, and how likely it
> > is that those scenarios will take place.
> >
> > Comments?
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland


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


From sip-admin@ietf.org  Tue Jun 26 10:37:07 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13434;
	Tue, 26 Jun 2001 10:37:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10052;
	Tue, 26 Jun 2001 10:12:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10024
	for ; Tue, 26 Jun 2001 10:12:07 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09116
	for ; Tue, 26 Jun 2001 10:11:25 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A7B91950264; Tue, 26 Jun 2001 10:10:01 -0400
Message-ID: <013c01c0fe49$b7344e20$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: 
Subject: Re:[Sip] [Sip-implementors] another problem related to multiple call l egs at   UAC
Date: Tue, 26 Jun 2001 10:10:12 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

oops, I messed up who wrote what

Jonathan Rosenberg writes:
> Bob Penfield writes:
> >
> > For example, I use a one-number service (unfortunately PSTN
> > based) with a
> > call screening feature that tells the callee who the call is
> > for and who is
> > holding and asks the callee to press 1 to accept the call. The service
> > simultaneouly rings my office, home, and cell phone. If this were
> > implemented in SIP with a forking proxy to get to all the devices I
> > registered, and the proxy canceled the unanswered call legs
> > as soon as one
> > answered, I could not receive the call if my wife picked up
> > the home phone
> > before I answered my office or cell phone.
> >
> > I think it should be a MAY.
>
> Won't help. The caller here doesn't know about this service, so they would
> simply generate the CANCEL. Even if this weren't true, you have another
> problem. Multiple accepted call legs would only be established under the
> race condition where you and your wife pick up at once. What you REALLY
want
> is that when you wife picks up, you can still pick up that call (even
though
> your phone isn't ringing anymore) at any time until she hangs up, and then
> press 1 to accept. THis is the standard home phone line behavior, which
the
> single line extension group was working on. Doing this properly requires
far
> more than just not cancelling.
>
> I have some ideas on how to actually support this given our current set of
> tools for conferencing, and so I will (hopefully) have a draft on how to
> properly do it before London.

You don't necessarily need conferencing to do this.

To implement this service in SIPland would require some sort of application
server to prompt callees with the screening information. BTW, as long as my
wife does not press 1 to accept the call, I can still pick up the call even
if I answer long after she does because the service keeps ringing the other
phones until a callee presses 1.

But anyway, it would look something like this:

+--------+         +------------+         +-----+------->home
| caller |-------->| app server |-------->|proxy|------->office
+--------+         +------------+         +-----+------->cell

The SIP URL people use to call me would point to the app server. The app
server would know to send an invite to my local proxy/registrar. The app
server would act as a B2BUA or connect to the accepting callee using REFER.
But in this case, the app server is the UAC that is capable of handling
multiple 200-OKs (it would send SDP in the ACK as opposed to the INVITE).
The app server would issue a cancel when the callee accepts by pressing 1.
If my local proxy always canceled incomplete legs when it got the first
200-OK, it breaks the application. And if the proxy does not support caller
preferences, then the app server can't tell it not to cancel.

(-:bob

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


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


From sip-admin@ietf.org  Tue Jun 26 10:45:27 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15002;
	Tue, 26 Jun 2001 10:45:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10697;
	Tue, 26 Jun 2001 10:28:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10665
	for ; Tue, 26 Jun 2001 10:28:32 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11891
	for ; Tue, 26 Jun 2001 10:27:51 -0400 (EDT)
Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f5QESUa19602
	for ; Tue, 26 Jun 2001 09:28:30 -0500 (CDT)
Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37])
	by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f5QESUg28342
	for ; Tue, 26 Jun 2001 09:28:30 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Jun 26 09:28:29 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 09:28:29 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Jonathan Rosenberg'" ,
        "'Mathieu, Marie-Noelle'" ,
        "'sip@ietf.org'" 
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Date: Tue, 26 Jun 2001 09:28:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FE4C.429255F0"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FE4C.429255F0
Content-Type: text/plain;
	charset="ISO-8859-1"


>>The callid MUST be a globally unique identifier and MUST NOT 
>be reused for 
>>later calls.
>
>However, I recall some discussion at an IETF that people were 
>using the same
>call-id across different call legs as a local identifier to 
>correlate those
>call legs. With unique From tags and From fields, there really 
>shouldn't be
>a problem, so I think its OK. However, if we are going to 
>allow it, the spec
>should reflect it. Comments?
>
>-Jonathan R.

Given that the notion of a "call" associated with a Call-ID
is a fiction (only call legs are really meaningful), re-use
of the Call-ID seems acceptable. 

/sean

------_=_NextPart_001_01C0FE4C.429255F0
Content-Type: text/html;
	charset="ISO-8859-1"






RE: [Sip] RE: [Sipping] Call and call-id






>>The callid MUST be a globally unique identifier and MUST NOT 

>be reused for 

>>later calls.

>

>However, I recall some discussion at an IETF that people were 

>using the same

>call-id across different call legs as a local identifier to 

>correlate those

>call legs. With unique From tags and From fields, there really 

>shouldn't be

>a problem, so I think its OK. However, if we are going to 

>allow it, the spec

>should reflect it. Comments?

>

>-Jonathan R.




Given that the notion of a "call" associated with a Call-ID

is a fiction (only call legs are really meaningful), re-use

of the Call-ID seems acceptable. 




/sean





------_=_NextPart_001_01C0FE4C.429255F0--

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


From sip-admin@ietf.org  Tue Jun 26 10:50:59 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16037;
	Tue, 26 Jun 2001 10:50:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11391;
	Tue, 26 Jun 2001 10:38:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11362
	for ; Tue, 26 Jun 2001 10:38:45 -0400 (EDT)
Received: from mail.net2phone.com (mail.net2phone.com [216.53.3.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13572
	for ; Tue, 26 Jun 2001 10:38:03 -0400 (EDT)
Received: from mailsvr.net2phone.com (exchange.net2phone.com [216.53.60.1])
	by mail.net2phone.com (8.9.3/8.9.3) with ESMTP id KAA13330;
	Tue, 26 Jun 2001 10:38:30 -0400 (EDT)
Received: by mailsvr.net2phone.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 10:38:30 -0400
Message-ID: <6F46FABB90ABD411BD690002B3152FB9260356@lkwmail01.net2phone.com>
From: Romel Khan 
To: "'Jon.Peterson@Level3.com'" ,
        Gonzalo.Camarillo@lmf.ericsson.se, sip@ietf.org,
        adam.roach@ericsson.com
Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-isup-01.txt
Date: Tue, 26 Jun 2001 10:32:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Thanks for the response. 
Regarding the CRM handling (item 2 below), I would like further
clarification. Doesn't the following scenario hold (if not, why not?): 
SIP GW (in this case analogous to an IXC) connects to an ILEC Access Tandem
(AT) using SS7. The ILEC AT may connect to one of the ILEC's class 5 end
office using MF. In this scenario, AT will send the CRM to SIP GW as per
GR394.



Thanks.

Romel Khan
Ph: (732)-363-0213, x241


-----Original Message-----
From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com]
Sent: Monday, June 25, 2001 6:13 PM
To: rkhan@net2phone.com; Gonzalo.Camarillo@lmf.ericsson.se;
sip@ietf.org; adam.roach@ericsson.com
Subject: RE: [SIP] I-D ACTION:draft-ietf-sip-isup-01.txt


Thanks for your comments. Some responses below.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Romel Khan [mailto:rkhan@net2phone.com]
Sent: Monday, June 25, 2001 9:26 AM
To: 'Gonzalo Camarillo'; 'sip@ietf.org'; 'adam.roach@ericsson.com'
Subject: [SIP] I-D ACTION:draft-ietf-sip-isup-01.txt


A few questions/comments on ISUP to SIP mapping draft:

1. How this draft ties with "SIP Extensions for Caller Identity and Privacy"
needs to be addressed. The sip-privacy draft can be used for transporting II
digit information and presentation restriction information which is
important if the termination is a SIP endpoint.

 I agree that the relationship between these two needs to be clarified.
Our draft should adhere to any general SIP privacy mechanism that is defined
by the WG. It doesn't seem unlikely that the work represented in the DCS
sip-privacy draft could evolve into such a mechanism, but today it isn't
clear that the entities on which sip-privacy relies are required for the
operation of SIP-T. 

2. Sec. 12, pg 47: Talking about ANSI ISUP, it has been stated "the
recommended behaviour is sending REL in response to CRM". Rather, shouldn't
the recommended behaviour following GR-394 (which will not actually result
in sending SIP Invite until the IAM finally comes)? There could be SIP GWs
in USA which interfaces using SS7 using SS7 with PSTN Access Tandem switches
that follow GR-394 and could potentially send CRM. 

 The point here is that it doesn't make any sense for a SIP gateway to
receive a CRM from the SS7 side. If it does, it is probably the result of a
network configuration error, since CRMs are only used in MF-SS7 interworking
points (which is why they are discussed in 394). 

3. In up front sections such as sec. 6.2.1.1 tel URL has been mentioned in a
way to make me think that SIP URL is not allowed (until I read further on).
Won't it be clearer to say statements such as "telephone number in the tel
URL" as "telephone number in the tel URL or SIP URL"

 Since a SIP URI is potentially partially composed of a tel URL I don't
find this particularly misleading. 

4. Sec. 6.2.6, last sentence: Shouldn't ACM also be included in the body of
the 183 response? Only 180 response is mentioned.

 The preceding paragraph in that section mentions a couple of cases in
which 183 would be sent rather than 180. 

5. In sec. 6.2.1.1, page 16, 3rd para.: a set of parameters are called
"immediately useful". Why is Called Party Number (CPN) missing from this
list?

 This is a list of optional parameters. The preceding paragraphs
discuss the role of mandatory parameters like the CPN. 

Thanks.

Romel Khan
Ph: (732)-363-0213, x241



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

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


From sip-admin@ietf.org  Tue Jun 26 10:53:28 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16479;
	Tue, 26 Jun 2001 10:53:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11151;
	Tue, 26 Jun 2001 10:33:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11114
	for ; Tue, 26 Jun 2001 10:33:23 -0400 (EDT)
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12689
	for ; Tue, 26 Jun 2001 10:32:41 -0400 (EDT)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA06689; Tue, 26 Jun 2001 10:32:50 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AJJ07319;
	Tue, 26 Jun 2001 10:32:48 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010626103037.00b0cca0@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 26 Jun 2001 10:34:49 -0400
To: Christer Holmberg 
From: Michael Hammer 
Subject: Re: [Sip] Some thoughts about CANCEL for specific legs,
  together with SIP extensions
Cc: sip@ietf.org
In-Reply-To: <3B384823.AC343408@lmf.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Christer,

Could you clarify whether the multi-leg call is due to forking?  It is not 
clear why you invited the call-leg to begin with, then later wanted to cancel.

Issue 2 seems to be tied up in the meaning of call versus call-leg, where 
the existing rules about sessions apply to a call-leg, but are termed a 
call.  If each leg in the call is requested by different session 
transactions then the sequences of setup and release could progress 
independently.

Is there some nuance missing?

Mike



At 11:30 AM 6/26/2001 +0300, Christer Holmberg wrote:

>Hi,
>
>Some thoughts/issues came to my mind when I read the thread (the SIP
>implementors list) about using CANCEL for specific call-legs.
>
>I KNOW we have spent lots of time discussing this, but I am not pretty
>sure that we have really thought about all the scenarios when some of
>the SIP EXTENSIONS (in this mail I mention the Caller preferences-,
>PRACK- and pre-call-setup requests features, and the scenario where the
>UAC wants to choose specific call-legs for a call).
>
>Instead, I think we mostly have assumed that a call setup is simply an
>INVITE, possible provisonal responses, and one or many final responses
>plus their ACKs, and in those cases I don't think we have any major
>problems.
>
>I even think some of the extensions may LOOSE some of the good stuff
>they are supposed to provide due to these issues.
>
>
>Issue 1: Caller preferences
>
>The Caller preferences feature allow the UAS to indicate the feature
>parameter in the response. The draft mentions the 200 response, but I
>guess it is (at least it should be) allowed also in a provisional
>response with a To-tag and Contact header. So, now the UAC may at a very
>early stage of the call setup find out about what kind of servers it has
>received provisional responses from, which means it may at a very early
>stage find out that it does not want a specific call-leg (for example,
>one could receive provisional responses from two different answering
>machinges, or something...). However, the UAC is not able to cancel any
>call leg (without terminating the whole call setup) before it has
>received a final response from one UAS, which means it may have to
>handle PRACKs, INFOs, and who knows what, with all servers - also those
>it will never establish a call with. A solution to this could be to
>allow CANCEL for a specific leg (assuming that the provisional responses
>included a To-tag and Contact). If PRACKs (or other requests used before
>the call is setup) are involved, the provisinal responses most likely
>will include the tag and Contact, so...
>
>
>Issue 2: Multi-leg call
>
>This could be related to the previous issue, but it can also be a "stand
>alone" issue. Again, a UAC may receive multiple provisional responses.
>It is going to establish a multi-leg call, ie it is going to accept a
>specific set of final responses. Again, however, it receives provisonal
>responses also from other servers, but again - it is not able to cancel
>those legs before it has received the final responses for ALL parties
>that will be in the multi-leg call. Allowing CANCEL for a specific leg
>would help also here.
>
>What also may happen here, is that we receive a final response for a leg
>that we do NOT want in the call, but we still want to wait for another
>final response. Now we could simply ACK and BYE that leg, but then we
>come to the issue about sending BYE requests before the whole call has
>been setup. However, the bis DOES say that BYE is used to terminate an
>established call-leg, and that is what we would be doing here - no
>matter if the WHOLE multi-leg call is setup or not - BUT, the bis also
>says "To terminate a call instead of just pending searches, the UAC must
>use BYE instead of or in addition to CANCEL". So, I guess some
>clarifications in the bis may be needed here.
>
>
>
>Conclusion:
>
>So, I don't know if we are talking about changes, or simple
>clarifications, in the spec, but the issues are:
>
>1. Should we allow CANCEL for a specific call-leg, IF we have received a
>To-tag and Contact in the provisional response?
>
>2. Should we allow BYE for an established call-leg, even if the whole
>call is yet not setup (the UAC is waiting for another final response)?
>
>I know that we have the issue about a UAS receiving the same request
>from different locations (when the request has been forked), so we have
>to find out in which scenarios this can be a problem, and how likely it
>is that those scenarios will take place.
>
>
>Comments?
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland


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


From sip-admin@ietf.org  Tue Jun 26 10:53:48 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16562;
	Tue, 26 Jun 2001 10:53:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08585;
	Tue, 26 Jun 2001 09:45:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08555
	for ; Tue, 26 Jun 2001 09:45:50 -0400 (EDT)
Received: from femail3.rdc1.on.home.com (femail3.rdc1.on.home.com [24.2.9.90])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05369
	for ; Tue, 26 Jun 2001 09:45:09 -0400 (EDT)
Received: from cybertron.div8.net ([24.114.8.64])
          by femail3.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP
          id <20010626134538.DGSR25851.femail3.rdc1.on.home.com@cybertron.div8.net>;
          Tue, 26 Jun 2001 06:45:38 -0700
Received: from vektor by cybertron.div8.net with local (Exim 3.12 #1 (Debian))
	id 15EtFe-0000SM-00; Tue, 26 Jun 2001 09:51:34 -0400
Date: Tue, 26 Jun 2001 09:51:34 -0400
From: Billy Biggs 
To: Jonathan Rosenberg 
Cc: Alan Johnston , Dvir Oren ,
        SIP List 
Subject: Re: [SIP] Replaces leg matching (was Re: [Sip-implementors] repla ces)
Message-ID: <20010626095134.A1750@div8.net>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: ; from jdrosen@dynamicsoft.com on Tue, Jun 26, 2001 at 12:51:21AM -0400
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Jonathan Rosenberg (jdrosen@dynamicsoft.com):

> >   This would be solved by having the full to and from in the header,
> > but putting instead a hash would just mean standardizing the hash
> > function used by gateways, or force them to index by another hash.
> > 
> >   If we're forcing them to index on another hash, I'd rather just
> > let that be the call-id + tags.
> > 
> >   Nasty situation regardless.
> 
> I don't want to standardize this hash. What is the issue with just
> including the full To, From, Call-ID along with tags? Just the length?

  The length and the escaping, since the full To and From includes all
parameters, some of which may be quoted strings, etc etc.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

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


From sip-admin@lists.bell-labs.com  Tue Jun 26 10:54:31 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16689
	for ; Tue, 26 Jun 2001 10:54:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 741A344351; Tue, 26 Jun 2001 10:55:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id 49E9544336
	for ; Tue, 26 Jun 2001 10:54:44 -0400 (EDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5QEseN10474;
	Tue, 26 Jun 2001 16:54:41 +0200 (MEST)
Received: from lmf.ericsson.se (racom-sd-81.sd.us.am.ericsson.se [142.133.141.82])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA23137;
	Tue, 26 Jun 2001 16:55:11 +0200 (MET DST)
Message-ID: <3B38A41F.2CC723E1@lmf.ericsson.se>
From: Gonzalo Camarillo 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Wayne Cutler 
Cc: sip 
References: <80256A77.00438B80.00@marconicomms.com> <3B38A3BC.116055C@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: Re Mapping of ISUP overlap signalling to SIP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 26 Jun 2001 18:02:55 +0300
Content-Transfer-Encoding: 7bit

Hello Wayne,
 
Sending further digits in INFOs without modifying any header was
presented in the SIP WG meeting (the presentation you are referring to).
It is not a good idea because SIP servers that provide services will
usually inspect the headers of the INVITE in order to know which service
should be applied.

Therefore, if the INVITE does not contain all the information in the
headers, SIP proxies that provide services will have to be made aware of
the INFO approach. That is, they will have to know that an INFO might
carry additional digits, and the service logic in the proxy will have to
be extended.

Using INVITEs all the time solves this problem.

Best regards,

Gonzalo

> Wayne Cutler wrote:
> >
> > >Hello,
> >
> > >There have been millons of mails sent to the mailins list in the past
> > >discussing exactly what you are proposing. Besides, this has been
> > >presented in several WG meetings.
> >
> > >Feel free to check the archives to find more information about this.
> >
> > Whilst here has been a good deal of discussion on the general topic (over at
> > least 3 threads), the vast majority
> > were concerned with including the overlap digits in various SIP headers.
> > Therefore, there hasn't been a great deal
> > of discussion about making the SIP headers independent of the overlap digits. I
> > do recall your presentation in the last
> > WG meeting but that suggested sending multiple INVITEs and (as I recall) there
> > was nothing said about the option of
> > making the SIP headers independent of the overlap digits.
> >
> > So, for limited scenarios, I fail to see why it is wrong/improper to make the
> > headers independent of the overlap digits. Such an
> > approach is workable and  does not require any changes to the SIP protocol. So
> > why can't it be added as another option, with a
> > suitable health warning about its limited applicability?
> >
> > Wayne.
> 
> --
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027
> USA                              Gonzalo.Camarillo@ericsson.com

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

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


From sip-admin@ietf.org  Tue Jun 26 10:55:19 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16808;
	Tue, 26 Jun 2001 10:55:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11044;
	Tue, 26 Jun 2001 10:32:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11010
	for ; Tue, 26 Jun 2001 10:32:39 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12502
	for ; Tue, 26 Jun 2001 10:31:57 -0400 (EDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5QEUa404868;
	Tue, 26 Jun 2001 10:30:36 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-91.cisco.com [161.44.241.91])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ABN06732 (AUTH pkyzivat);
	Tue, 26 Jun 2001 10:32:04 -0400 (EDT)
Message-ID: <3B389BE2.6DC089F5@cisco.com>
Date: Tue, 26 Jun 2001 10:27:46 -0400
From: Paul Kyzivat 
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Bob Penfield'" ,
        "'Barry Desborough'" , sip@ietf.org
Subject: Re: [Sip] RE: reason code in BYE/CANCEL (was [Sip-implementors] another 
 problem related to multiple call l egs at   UAC)
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Didn't Dave Oran float a proposal a month or two ago that included
something like this? I think it might even have used the "Reason"
header. I'd ask him, but I think he is away.

	Paul Kyzivat
	Cisco Systems

Jonathan Rosenberg wrote:
> 
> > -----Original Message-----
> > From: Bob Penfield [mailto:bpenfield@acmepacket.com]

> > How about a "Reason" request header (or is that already
> > defined elswhere)
> > that uses the same format as the Warning header?
> >
> >         Reason        =  "Reason" ":" 1#reason-value
> >         reason-value  =  reason-code SP reason-agent SP reason-text
> >         reason-code   =  3DIGIT
> >         reason-agent  =  host [ ":" port ]
> >                           ;  the name of the server adding
> >                           ;  the Reason header, for use in
> > tracing/debugging
> >         reason-text   =  quoted-string
> >
> >
> >
> 
> Reason is not used. Seems reasonable for the header name.

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


From sip-admin@ietf.org  Tue Jun 26 10:57:34 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17151;
	Tue, 26 Jun 2001 10:57:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11795;
	Tue, 26 Jun 2001 10:47:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11712
	for ; Tue, 26 Jun 2001 10:47:44 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15300
	for ; Tue, 26 Jun 2001 10:47:03 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5QElu325660
	for ; Tue, 26 Jun 2001 17:47:56 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id ;
 Tue, 26 Jun 2001 17:47:41 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id ; Tue, 26 Jun 2001 17:47:41 +0300
Message-ID: 
To: jundery@ubiquity.net, jdrosen@dynamicsoft.com
Cc: sip@ietf.org
Subject: RE: [Sip] Request header integrity in HTTP Digest
Date: Tue, 26 Jun 2001 17:47:37 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Hi,

May have missed some points in this thread. But let's not totally trash this
idea, creative usage of nonce values does indeed increase security. I think
this is stated in 2617, and this draft is exactly that, a creative usage of
nonce values.

But I have to agree with James on the fact, that ultimatelly, the same
threats present with digest are still present with pnonce. Hence, it doesn't
deliver the goods it promises, which is integrity of headers.

Br,
Aki

> -----Original Message-----
> From: ext James Undery [mailto:jundery@ubiquity.net]
> Sent: 26 June, 2001 10:58
> To: Jonathan Rosenberg
> Cc: sip@ietf.org
> Subject: Re: [Sip] Request header integrity in HTTP Digest
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: James Undery [mailto:jundery@ubiquity.net]
> >
> > My point is *not* that it fixes all problems. My point is 
> that it fixes
> some
> > problems that regular digest has, and doesn't introduce any 
> new security
> > weaknesses. In that case, how can one possibly object to it?
> 
> It fixes no problems in regular Digest Authentication, that 
> is the point,
> replay
> attacks don't exist if you allow the client to only use a 
> nonce once before
> it
> goes stale.
> 
> 
> >
> > > SIP and HTTP share a lot of the same headers, request 
> response model
> 
> > > granted,
> > > but these similarities shouldn't fool you into thinking that
> > > the protocols
> > > are
> > > similar. Transactions in SIP and HTTP are totally different
> > > in nature, a
> > > security model for one does not map to a security model 
> for the other.
> >
> > Really? SIP references HTTP Basic and digest directly, 
> since they are
> > directly useful in SIP. If the security models were not 
> compatible, how
> > could we do this?
> >
> 
> Well I am in the process of writing a draft, I believe fixes 
> HTTP digest so
> it
> works as well for SIP (i.e. it has only the same flaws as 
> HTTP, but allows
> the
> server to check it is seeing what the client sent with the 
> integrity of
> relevant
> headers intact.) A register request for instance requires the 
> To, From,
> Contact
> and Expires headers remain intact for the integrity of the 
> request. The big
> problem is it will be a new scheme, requiring changes to servers and
> clients,
> something your draft doesn't require and the reason it adds 
> nothing new (see
> the
> end of the message for the challenge if you think it does) .
> 
> I only hope people read it and tell me what it is I've missed, and as
> security
> is hard I know I'll have missed something.
> 
> >
> > > What Corey pointed out was a rouge poxy can request a UA to
> > > register using a
> > > nonce that it knows a second proxy will give it at some time
> > > in the future
> > > (of
> > > the rouge proxies choosing). If you think that is nonsense we
> > > might as well
> > > stop
> > > discussing any security now.
> >
> > James, this attack is possible in regular digest if you 
> don't do the same
> > thing Corey suggests. Thus, your point is utter nonsense 
> since you are
> > trying to argue against the mechanism based on general 
> digest issues that
> > are not specific to the proposal at all. As I said, send a 
> complaint to
> the
> > authors of rfc2617.
> >
> 
> If you choose to ignore their advice and break the nonce 
> generation, it
> states
> Security Considerations the importance of a proper nonce. In 
> fact my only
> issue
> with rfc2617 is the don't mention about removal or 
> downgrading of the qop
> parameter as a possible attack to interfere with the body of 
> the request.
> 
> > Sigh. I don't know how much clearer I can be. Perhaps if I 
> try e-shouting.
> > THE ATTACK YOU DESCRIBE IS POSSIBLE IN REGULAR DIGEST!!!!! 
> This attack is
> > not fixed by the pnonce and still exists there. I am not 
> claiming that
> this
> > mechanism fixes all the problems in digest. I am claiming that it is
> better
> > than digest. I am claiming that because it fixes some 
> attacks present in
> > regular digest, and introduces no new ones. So, your objections are
> > completely nonsense unless, as I requested above, you can 
> demonstrate an
> > attack that is not possible with regular temporal-based + 
> private key
> nonces
> > (i.e., nonce = H(round-time:key), but is present in a nonce that is
> > temporal-based + private key and includes a hash of some 
> request headers
> > (i.e., a pnonce = H(round-time:key:request-headers)).
> >
> 
> And all the protection you describe is possible with no 
> modification of
> rfc2617
> just use it as is, your scheme increases the chance of 
> legitimate clients
> failing and solves nothing but the most half-hearted attacks, 
> my point is
> why
> bother producing yet another ID for people to implement that 
> adds minimal
> value.
> 
> > >
> > > But submitting a draft that doesn't mention you are only
> > > protected from
> > > these
> > > specific attacks but not more sophisticated ones youI haven't
> > > mentioned
> > > provides
> > > the reader with a false sense of security. This is far 
> worse than just
> > > pointing
> > > out the limitations. Selling snake oil will do SIP security
> > > no favours.
> >
> > There is a difference between claiming the draft doesn't 
> mention problems
> > that remain, and claiming that the mechanism is worthless. You have
> accused
> > me of foolishness by proposing a worthless mechanism that 
> makes security
> > worse. I claim that you are completely wrong, and that this 
> mechanism
> fixes
> > many important attacks, yet introduces no new ones. So, do 
> you, or do you
> > not, claim that this mechanism worsens security compared to more
> traditional
> > nonce computations?
> 
> No, I am not claiming you introduce new weaknesses now you're 
> fixed the
> private-key issue, the problem is this draft does nothing 
> plain old HTTP
> digest
> doesn't do, by saying I will protect against attack X and attack X is
> defended
> by the base spec being implemented properly, you are just 
> reiterating the
> original spec. As you point out all the attacks I describe 
> are possible
> against
> regular HTTP digest.
> 
> The challenge for you is to provide a single case where you 
> are protecting
> against an attack possible in rfc2617 (I will be choosing to 
> generate nonces
> as
> per section 4.3 of rfc2617 and making them go stale after one use ).
> 
> James Undery
> 
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

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


From sip-admin@ietf.org  Tue Jun 26 11:16:08 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19486;
	Tue, 26 Jun 2001 11:16:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12716;
	Tue, 26 Jun 2001 11:02:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12684
	for ; Tue, 26 Jun 2001 11:02:49 -0400 (EDT)
Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17840
	for ; Tue, 26 Jun 2001 11:02:09 -0400 (EDT)
Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca
          via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 26 Jun 2001 16:02:37 UT
Received: (private information removed)
Message-ID: 
From: Neil Deason 
To: David Schwartz ,
        "'Jonathan Rosenberg'"
	 ,
        "'Jiri Kuthan'" ,
        "'Rosen, Brian'" ,
        "'Jay Batson'"
	 ,
        "'Ashhar Farhan'" , sip@ietf.org
Subject: RE: [SIP] Authentication and billing through proxy/re-direct  ser
	ver
Date: Tue, 26 Jun 2001 11:05:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org


> I think all would agree that the ideal place for call control
> is in the
> Voice Gateway. It is already stateful and it is the only
> element as you said
> that has a true picture of which calls are connected and
> which are not. The
> problem faced too often, however, is that a particular
> company doesn't want
> to terminate traffic yet they want to bill for the service.
> Another scenario
> might be if a call passes through more than one network
> before termination.
> In that case each network owner might want to charge for use
> of his/her
> network. There must a mechanism within these networks to detect call
> completion.
>
> With that said, I think your point about synchronization is a
> good one and I
> can think of a few ways to solve it.
>
> The best way I believe would be for the call controller to
> SUBSCRIBE to the
> gateway for a BYE event notification. In this way, the call
> controller would
> not terminate any traffic when receiving a BYE but rather
> when receiving a
> NOTIFY with the BYE event specified. All information necessary for the
> Account Stop would then be contained in the body of the
> NOTIFY message. I
> prefer this method since it allows the call controller to remains
> essentially stateless. The problem is that at last count most GW
> manufacturers have yet to fully implement SUBSCRIBE/NOTIFY on their
> gateways.

By 'call controller' do you mean a Proxy being used
for call duration billing and by 'terminate traffic' on a
BYE/NOTIFY you mean generate a minutes used record??
Anyway I can't see how all this helps with your opening
example of where the terminating GW is not owned by the
charging network if no sufficient trust relationship exists?
Regardless of mechanisms that are dreamed up the bottom
line is that SIP is not intended to solve this type of
problem.

> An alternate approach might be to have the call controller
> set a session
> timer between it and the gateway. The time interval can be as
> much as a
> minute since most companies charge on a per minute basis. In
> this scenario
> if indeed the Max-Forwards was set to end at the call
> controller, the call
> controller would close the session thereby ceasing to send
> the re-INVITE
> with the updated session time so the voice gateway would
> defacto close the
> session. The reason I like this event less is because it
> forces the call
> controller to be call stateful.

I think the revised session timer draft will point out
that it is an inapporpriate mechanism for billing
solutions.

> There are a few other mechanisms I can think of but I think
> these two will
> suffice.

The best answer has already been given - use event feeds
from the nework servers into mediation systems. This does
not require making SIP into a billing protocol. As was also
pointed out models that charge on call durations will find
only doing so for PSTN transit and not for the time users
may, or may not, have been sending packets on IP networks
work best. Not a co-incidence.

Cheers,
Neil.
--
Ubiquity Software Corporation, UK        http://www.ubiquity.net




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


From sip-admin@ietf.org  Tue Jun 26 11:24:30 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20698;
	Tue, 26 Jun 2001 11:24:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12642;
	Tue, 26 Jun 2001 11:02:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12611
	for ; Tue, 26 Jun 2001 11:02:12 -0400 (EDT)
Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17718
	for ; Tue, 26 Jun 2001 11:01:32 -0400 (EDT)
Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca
          via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 26 Jun 2001 16:02:01 UT
Received: (private information removed)
Message-ID: <3B38A3AC.650EEC39@ubiquity.net>
From: James Undery 
To: aki.niemi@nokia.com
Cc: jdrosen@dynamicsoft.com, sip@ietf.org
Subject: Re: [Sip] Request header integrity in HTTP Digest
Date: Tue, 26 Jun 2001 11:01:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



aki.niemi@nokia.com wrote:

> Hi,
>
> May have missed some points in this thread. But let's not totally trash
this
> idea, creative usage of nonce values does indeed increase security. I
think
> this is stated in 2617, and this draft is exactly that, a creative usage
of
> nonce values.

Unfortunately, the source-IP part is also suspect if the hop before the
server
is a farm of stateless proxies, but don't get me started on stateless
proxies
;-)

James Undery


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


From sip-admin@ietf.org  Tue Jun 26 11:32:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21947;
	Tue, 26 Jun 2001 11:32:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13478;
	Tue, 26 Jun 2001 11:21:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13445
	for ; Tue, 26 Jun 2001 11:21:28 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20238
	for ; Tue, 26 Jun 2001 11:20:44 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5QFJCH29465;
	Tue, 26 Jun 2001 08:19:14 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AJO00530;
	Tue, 26 Jun 2001 08:20:30 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA01644; Tue, 26 Jun 2001 08:20:30 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15160.43070.343030.890219@thomasm-u1.cisco.com>
Date: Tue, 26 Jun 2001 08:20:30 -0700 (PDT)
To: "Gross, Gerhard" 
Cc: "'bidulock@openss7.org'" ,
        Jonathan Rosenberg
	 ,
        "'Rosen, Brian'" ,
        "'Jiri Kuthan'"
	 ,
        Ashhar Farhan ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	er
In-Reply-To: <4148FEAAD879D311AC5700A0C969E89006E18BF3@orsmsx35.jf.intel.com>
References: <4148FEAAD879D311AC5700A0C969E89006E18BF3@orsmsx35.jf.intel.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


As Jonathan points out, this is trivially defrauded.

The rule is simple: if you don't see the begin/end
of the actual media stream (either directly or
through some router that controls, say, QoS
resources), or whatever other kind of session you
might be basing session duration based billing on,
then you are just whistling in the dark. Moving
the call statefulness to a PDP only obfuscates
which box got defrauded.

	  Mike

Gross, Gerhard writes:
 > A solution to *ONE PIECE* of the AAA problem discussed
 > in this thread is addressed by slapping a PEP (policy
 > enforcement point) layer on top of the SIP proxy
 > and using a AAA/policy server in the domain as
 > the PDP (policy decision point). The COPS extension
 > for SIP and usage instructions are specified in
 > http://www.ietf.org/internet-drafts/draft-gross-cops-sip-01.txt.
 > 
 > The PDP is made aware of INVITES, responses, ACKs,
 > BYEs, etc. through the PEP. So the PDP can tabulate
 > call event and timing statistics. These can be used
 > for whatever accounting (and subsequent charging and
 > billing) models that happen to be deployed. The
 > AAA/policy server is owned and maintained by the
 > service provider and is therefore protected and trusted.
 > 
 > Call statefulness is handled by COPS and the PDP, not
 > by the SIP proxy. The PDP (AAA server) may interact
 > with a clearing house (broker, billing mediation company,
 > etc.) for inter-domain AAA purposes as people see fit.
 > As far as I know, there is no reason this can not be real
 > time so that "real-time billing services" can be used.
 > 
 > The additional benefit of providing local policy management
 > of SIP usage is also there.
 > 
 > This does not directly address the issue of byte counts
 > per session in case billing were dependent on that.
 > Having the UA deliver CDRs when the call is over seems
 > like asking for fraud since the UA is generally not
 > owned by the service provider. How can it be trusted
 > to report accurate CDRs?
 > 
 > As others have said, the burden of collecting
 > other call/session statistics (e.g. byte count)
 > should fall on the entity providing the service
 > who wants to get paid for it. That entity may,
 > for example, deploy some monitoring module at
 > its egress points.
 > 
 > 
 > _______________________________________________
 > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
 > This list is for NEW development of the core SIP Protocol
 > Use sip-implementors@cs.columbia.edu for questions on current sip
 > Use sipping@ietf.org for new developments on the application of sip

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


From sip-admin@ietf.org  Tue Jun 26 11:52:53 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23309;
	Tue, 26 Jun 2001 11:52:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13651;
	Tue, 26 Jun 2001 11:26:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13619
	for ; Tue, 26 Jun 2001 11:26:11 -0400 (EDT)
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20898
	for ; Tue, 26 Jun 2001 11:25:30 -0400 (EDT)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA08321; Tue, 26 Jun 2001 11:25:39 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AJJ07971;
	Tue, 26 Jun 2001 11:25:37 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010626112550.03839a48@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 26 Jun 2001 11:27:39 -0400
To: Paul Kyzivat 
From: Michael Hammer 
Subject: Re: [Sip] RE: reason code in BYE/CANCEL (was
  [Sip-implementors] another  problem related to multiple call l egs at 
   UAC)
Cc: Jonathan Rosenberg ,
        "'Bob Penfield'" ,
        "'Barry Desborough'" , sip@ietf.org
In-Reply-To: <3B389BE2.6DC089F5@cisco.com>
References: 
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org


Yes, he did, in an email dated 5/11/2001.  Do you need
a copy?



Mike





At 10:27 AM 6/26/2001 -0400, Paul Kyzivat wrote:




Didn't Dave Oran float a proposal a month or
two ago that included

something like this? I think it might even have used the
"Reason"

header. I'd ask him, but I think he is away.



        Paul
Kyzivat

        Cisco
Systems



Jonathan Rosenberg wrote:

> 

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

> > From: Bob Penfield
[mailto:bpenfield@acmepacket.com]



> > How about a "Reason" request header (or is that
already

> > defined elswhere)

> > that uses the same format as the Warning header?

> >

> >        
Reason        = 
"Reason" ":" 1#reason-value

> >        
reason-value  =  reason-code SP reason-agent SP
reason-text

> >        
reason-code   =  3DIGIT

> >        
reason-agent  =  host [ ":" port ]

>
>                          
;  the name of the server adding

>
>                          
;  the Reason header, for use in

> > tracing/debugging

> >        
reason-text   =  quoted-string

> >

> >

> >

> 

> Reason is not used. Seems reasonable for the header name.



_______________________________________________

Sip mailing list 
http://www.ietf.org/mailman/listinfo/sip

This list is for NEW development of the core SIP Protocol

Use sip-implementors@cs.columbia.edu for questions on current sip

Use sipping@ietf.org for new developments on the application of sip




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


From sip-admin@ietf.org  Tue Jun 26 12:17:02 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24411;
	Tue, 26 Jun 2001 12:17:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15830;
	Tue, 26 Jun 2001 12:05:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15801
	for ; Tue, 26 Jun 2001 12:05:38 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23833
	for ; Tue, 26 Jun 2001 12:04:56 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5QG4Uh26680;
	Tue, 26 Jun 2001 09:04:30 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AJO01467;
	Tue, 26 Jun 2001 09:04:28 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA01652; Tue, 26 Jun 2001 09:04:28 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15160.45708.351589.734911@thomasm-u1.cisco.com>
Date: Tue, 26 Jun 2001 09:04:28 -0700 (PDT)
To: David Schwartz 
Cc: "'Jonathan Rosenberg'" ,
        "'Jiri Kuthan'"
	 ,
        "'Rosen, Brian'" ,
        "'Jay Batson'" ,
        "'Ashhar Farhan'"
	 ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct  ser
	ver
In-Reply-To: 
References: 
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

David Schwartz writes:
 > Hi Jonathan.
 > 
 > I think all would agree that the ideal place for call control is in the
 > Voice Gateway. It is already stateful and it is the only element as you said
 > that has a true picture of which calls are connected and which are not. The
 > problem faced too often, however, is that a particular company doesn't want
 > to terminate traffic yet they want to bill for the service.

   There are lots of things people want; I'll note that not
   only did I not get a California lottery ticket, I also
   didn't win the $141M.

   The real question here is whether you can trust the gateway
   or not, regardless of who operates it. This is mainly a
   business question. If the risk is tolerable, than generating
   CDR's on that UA, sending NOTIFY's, etc, etc, are all fine
   ways of generating accounting records. If they aren't, then,
   well, I didn't win the lottery either.

>  Another scenario
 > might be if a call passes through more than one network before termination.
 > In that case each network owner might want to charge for use of his/her
 > network. There must a mechanism within these networks to detect call
 > completion.

   If you're trying to account for RTP traffic,
   then what you want is RSVP/COPS, not SIP.

	     Mike

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


From sip-admin@lists.bell-labs.com  Tue Jun 26 12:33:31 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25270
	for ; Tue, 26 Jun 2001 12:33:31 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 621AB44364; Tue, 26 Jun 2001 12:34:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by lists.bell-labs.com (Postfix) with ESMTP id CA0F844360
	for ; Tue, 26 Jun 2001 12:33:15 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f5QGX5w03891
	for ; Tue, 26 Jun 2001 17:33:05 +0100 (BST)
Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com;
          Tue, 26 Jun 2001 17:32:50 +0100
Received: by znsgd00t.europe.nortel.com 
          with Internet Mail Service (5.5.2653.19) id ;
          Tue, 26 Jun 2001 17:32:48 +0100
Message-ID: 
From: "Mark Watson" 
To: "'Wayne Cutler'" ,
        Gonzalo Camarillo 
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Re: Re Mapping of ISUP overlap signalling to SIP
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0FE5D.97240DF0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 26 Jun 2001 17:32:28 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FE5D.97240DF0
Content-Type: text/plain;
	charset="iso-8859-1"

Wayne,

Your proposal presumes that the incoming PSTN/SIP gateway can identify the
outgoing SIP/PSTN gateway. If this knowledge is instead in an intermediate
SIP proxy, then the digit information will need to be in the SIP headers,
because the proxy will not examine the ISUP payload.

IMO, once the INVITE has reached the o/g SIP/PSTN gateway, it would be of
value for subsequent digits to travel in INFOs (a backwards indication that
this was allowed would be needed at this point).

But as Gonzalo says this has been discussed ad nauseum on this list, to no
clear conclusion AFAIK.

Regards,

Mark Watson
Nortel Networks



> -----Original Message-----
> From: Wayne Cutler [mailto:Wayne.Cutler@marconi.com]
> Sent: 26 June 2001 13:19
> To: Gonzalo Camarillo
> Cc: sip@lists.bell-labs.com
> Subject: [SIP] Re: Re Mapping of ISUP overlap signalling to SIP
> 
> 
> 
> 
> >Hello,
> 
> >There have been millons of mails sent to the mailins list in the past
> >discussing exactly what you are proposing. Besides, this has been
> >presented in several WG meetings.
> 
> >Feel free to check the archives to find more information about this.
> 
> Whilst here has been a good deal of discussion on the general 
> topic (over at
> least 3 threads), the vast majority
> were concerned with including the overlap digits in various 
> SIP headers.
> Therefore, there hasn't been a great deal
> of discussion about making the SIP headers independent of the 
> overlap digits. I
> do recall your presentation in the last
> WG meeting but that suggested sending multiple INVITEs and 
> (as I recall) there
> was nothing said about the option of
> making the SIP headers independent of the overlap digits.
> 
> So, for limited scenarios, I fail to see why it is 
> wrong/improper to make the
> headers independent of the overlap digits. Such an
> approach is workable and  does not require any changes to the 
> SIP protocol. So
> why can't it be added as another option, with a
> suitable health warning about its limited applicability?
> 
> Wayne.
> 
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> 

------_=_NextPart_001_01C0FE5D.97240DF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Re: Re Mapping of ISUP overlap signalling to =
SIP




Wayne,




Your proposal presumes that the incoming PSTN/SIP =
gateway can identify the outgoing SIP/PSTN gateway. If this knowledge =
is instead in an intermediate SIP proxy, then the digit information =
will need to be in the SIP headers, because the proxy will not examine =
the ISUP payload.



IMO, once the INVITE has reached the o/g SIP/PSTN =
gateway, it would be of value for subsequent digits to travel in INFOs =
(a backwards indication that this was allowed would be needed at this =
point).



But as Gonzalo says this has been discussed ad =
nauseum on this list, to no clear conclusion AFAIK.




Regards,




Mark Watson

Nortel Networks








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

> From: Wayne Cutler [mailto:Wayne.Cutler@marconi.com=
]

> Sent: 26 June 2001 13:19

> To: Gonzalo Camarillo

> Cc: sip@lists.bell-labs.com

> Subject: [SIP] Re: Re Mapping of ISUP overlap =
signalling to SIP

> 

> 

> 

> 

> >Hello,

> 

> >There have been millons of mails sent to =
the mailins list in the past

> >discussing exactly what you are proposing. =
Besides, this has been

> >presented in several WG meetings.

> 

> >Feel free to check the archives to find =
more information about this.

> 

> Whilst here has been a good deal of discussion =
on the general 

> topic (over at

> least 3 threads), the vast majority

> were concerned with including the overlap =
digits in various 

> SIP headers.

> Therefore, there hasn't been a great =
deal

> of discussion about making the SIP headers =
independent of the 

> overlap digits. I

> do recall your presentation in the last

> WG meeting but that suggested sending multiple =
INVITEs and 

> (as I recall) there

> was nothing said about the option of

> making the SIP headers independent of the =
overlap digits.

> 

> So, for limited scenarios, I fail to see why it =
is 

> wrong/improper to make the

> headers independent of the overlap digits. Such =
an

> approach is workable and  does not require =
any changes to the 

> SIP protocol. So

> why can't it be added as another option, with =
a

> suitable health warning about its limited =
applicability?

> 

> Wayne.

> 

> 

> 

> =
_______________________________________________

> This list is for continuing development of the =
SIP protocol.

> The sip-implementor's list is the place to =
discuss implementation,

> and to receive advice on understanding existing =
sip.

> To subscribe to it, send mail to 

> sip-implementors-request@cs.columbia.edu with =
"subscribe" in the body.

> 





------_=_NextPart_001_01C0FE5D.97240DF0--

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


From sip-admin@ietf.org  Tue Jun 26 12:39:59 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25603;
	Tue, 26 Jun 2001 12:39:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16483;
	Tue, 26 Jun 2001 12:27:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16455
	for ; Tue, 26 Jun 2001 12:26:58 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24940
	for ; Tue, 26 Jun 2001 12:26:17 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (localhost [127.0.0.1])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5QGQtS22834
	for ; Tue, 26 Jun 2001 12:26:56 -0400 (EDT)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150])
	by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f5QGQs722805
	for ; Tue, 26 Jun 2001 12:26:55 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21)
	id ; Tue, 26 Jun 2001 17:11:51 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB001AC3282@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" 
To: "'sip@ietf.org'" ,
        "'Jonathan Rosenberg'"
	 
Subject: RE: [SIP] Congestion control
Date: Tue, 26 Jun 2001 17:11:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

see below

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com

> ----------
> From: 	Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com]
> Sent: 	26 June 2001 7:45
> To: 	'Hidefumi Nakamura'; 'sip@ietf.org'
> Subject: 	RE: [SIP] Congestion control
> 
> 
> 
> I think the spec would benefit on some additional text on 503 handling.
> Specifically:
> 
> 1. 503 is the appropriate response to indicate congestion or any other
> resource constraints that make a server temporarily congested.
> 
> 2. A client receiving a 503 SHOULD attempt to contact an alternate server.
> 
> 3. A server should generate and/or forward a 503 upstream only if all
> requests that would reach the server cannot be serviced. This means that
> the
> server itself is congested, or every possible next-hop it can route to is
> congested (which is fairly unlikely but can happen in certain
> configurations).
> 
What if the registrar of the terminating user is congested? Should such an
entity return a 503 if it knows there is no other server?

I believe the requirement "SHOULD contact an alternative server", and a
general requirement to return a 503 are not particularly consistent -
either:

a)	the general requirement to return a 503 results in a MAY contact an
additional server

b)	a 503 should be returned only when it is believed an additional
server exists, and therefore under those circumstances the client SHOULD
contact an additional server.

> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

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


From sip-admin@ietf.org  Tue Jun 26 12:46:01 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25970;
	Tue, 26 Jun 2001 12:45:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16993;
	Tue, 26 Jun 2001 12:35:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16965
	for ; Tue, 26 Jun 2001 12:35:07 -0400 (EDT)
Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25328
	for ; Tue, 26 Jun 2001 12:34:28 -0400 (EDT)
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05889
	for ; Tue, 26 Jun 2001 12:34:16 -0400 (EDT)
Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05875
	for ; Tue, 26 Jun 2001 12:34:15 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FE5D.F8CEDBB6"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Date: Tue, 26 Jun 2001 10:35:12 -0600
Message-ID: 
Thread-Topic: [Sip] RE: [Sipping] Call and call-id
Thread-Index: AcD+AzfiZ0nBah04Tz2YBFZZNsDlRAAWgf8w
From: "Zmolek, Andrew (Andrew)" 
To: "Jonathan Rosenberg" ,
        "Mathieu, Marie-Noelle" ,
        
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C0FE5D.F8CEDBB6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> >same call-id in the 2 INVITE requests, is this allowed ?
>
> Well, the current spec would indicate that you shouldn't do this:
>
> >The callid MUST be a globally unique identifier and MUST NOT be
reused for=20
> >later calls.
>
> However, I recall some discussion at an IETF that people were using
the same
> call-id across different call legs as a local identifier to correlate
those
> call legs. With unique From tags and From fields, there really
shouldn't be
> a problem, so I think its OK. However, if we are going to allow it,
the spec
> should reflect it. Comments?

If that's the proper way to solve this problem, then let's put that in
the spec. But I'm not convinced that this alone will solve all cases,
especially when this correlated information needs to be presented by a
call leg attempting to join (as in the consultative transfer case). It
only seems to work when the correlating entity initiates all the calls.
If there's a reliable way to correlate an incoming call leg with an
existing call, I'd love to hear about it.

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

            zmolek@avaya.com
              +1 720 444 4001



------_=_NextPart_001_01C0FE5D.F8CEDBB6
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Sip] RE: [Sipping] Call and call-id





> >same call-id in the 2 INVITE requests, is =
this allowed ?


>


> Well, the current spec would indicate that you =
shouldn't do this:


>


> >The callid MUST be a globally unique =
identifier and MUST NOT be reused for 


> >later calls.


>


> However, I recall some discussion at an IETF =
that people were using the same


> call-id across different call legs as a local =
identifier to correlate those


> call legs. With unique From tags and From =
fields, there really shouldn't be


> a problem, so I think its OK. However, if we are =
going to allow it, the spec


> should reflect it. Comments?




If that's the proper way to solve this problem, then =
let's put that in the spec. But I'm not convinced that this alone will =
solve all cases, especially when this correlated information needs to be =
presented by a call leg attempting to join (as in the consultative =
transfer case). It only seems to work when the correlating entity =
initiates all the calls. If there's a reliable way to correlate an =
incoming call leg with an existing call, I'd love to hear about =
it.



--Andy Zmolek


    Technology & Standards =
Engineer


      CTO Standards


        Avaya =
Inc.




          &nbs=
p; zmolek@avaya.com


          &nbs=
p;   +1 720 444 4001







------_=_NextPart_001_01C0FE5D.F8CEDBB6--

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


From sip-admin@ietf.org  Tue Jun 26 13:35:17 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29106;
	Tue, 26 Jun 2001 13:35:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18547;
	Tue, 26 Jun 2001 13:13:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18515
	for ; Tue, 26 Jun 2001 13:13:55 -0400 (EDT)
Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27361
	for ; Tue, 26 Jun 2001 13:13:15 -0400 (EDT)
Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.2) id f5QHDqN61382; Tue, 26 Jun 2001 13:13:52 -0400 (EDT)
Reply-To: 
From: "Brett Tate" 
To: "'Jonathan Rosenberg'" , 
Subject: RE: [SIP] draft-ietf-sip-session-timer-04: INVITE with Require and Support timer and Session-Expires
Date: Tue, 26 Jun 2001 13:17:05 -0400
Message-ID: <002401c0fe63$d386fb30$2b01a8c0@broadsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: 
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> > 
> > If a UAC both requires and supports an option-tag, 
> > should it include it in both headers?  
> 
> Its redundant. If it requires it, wouldn't that be because it 
> supports it?

It depends on if the requires option-tag was 
added by a proxy or a UA.  For instance, the proxy
currently can add timer to Require header in 2xx
responses as a means to indicate who is supposed 
to be sending refreshes.  However if require 
implies supported, this would also mean that the 
UAC can assume that timer is supported by 
the UAS which isn't true.

> > Isn't the "require implies supported" going to limit 
> > devices that want to require others to support an 
> > extension without them actually supporting it?
> 
> I can't think of a case where such a thing would make sense. 
> Do you have a
> specific example?

Actually the timer draft is a good example as 
reflected in the example of a proxy adding 
require timer.  The receiver would incorrectly 
think that the UA supported something that it 
didn't.

I currently can't recall any receiver only 
extensions since they all require extension 
support by sender.  The timer draft had the 
potential until the INVITE's require timer 
only meant that the receiver supports the 
draft and not necessarily that the extension 
would be used on the call-leg and refreshed 
by receiver.

> > However without an extra parameter 
> > in Session-Expires to indicate who is refreshing, 
> > I can't think of a better solution.
> > 
> > Actually the same parameter could be used to allow 
> > for smaller Session-Expires values which are not to 
> > be refreshed.
> > 
> > Session-Expires  =  
> >   ("Session-Expires" | "x") ":" 
> >               ( SIP-date | delta-seconds ) [refresher]
> > 
> > refresher = ";" "refresher" "=" "uas"|"uac"|"none"
> > 
> 
> What would be the usage of none? I don't see the value in that...??

The "none" would indicate neither party will be 
extending the session; thus please allow the 
small session-expires value.


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


From sip-admin@ietf.org  Tue Jun 26 13:40:14 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00144;
	Tue, 26 Jun 2001 13:40:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18834;
	Tue, 26 Jun 2001 13:25:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18806
	for ; Tue, 26 Jun 2001 13:25:17 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28042
	for ; Tue, 26 Jun 2001 13:24:37 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5QHOlN16809;
	Tue, 26 Jun 2001 10:24:47 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AJO03821;
	Tue, 26 Jun 2001 10:24:37 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA01668; Tue, 26 Jun 2001 10:24:37 -0700 (PDT)
From: Michael Thomas 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15160.50517.140068.57682@thomasm-u1.cisco.com>
Date: Tue, 26 Jun 2001 10:24:37 -0700 (PDT)
To: "Arnoud van Wijk (ELN)" 
Cc: "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct  ser
	 v er
In-Reply-To: <7BA41B5547CCD411833B0002A52CD457037281C1@enlrynt306.etm.ericsson.se>
References: <7BA41B5547CCD411833B0002A52CD457037281C1@enlrynt306.etm.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Arnoud van Wijk (ELN) writes:
 > Yup. And that is now exactly my problem with Charging and Billing.
 > The signalling and the bearer traverse different nodes/servers and
>  pathways. So, SIP is currently unreliable to obtain exact call
> duration.

  This isn't a SIP problem, per se; it's an inherent information
  problem where a potentially untrusted device(s) is the only
  thing in possession of the necessary information for which it
  has high incentive to withhold/lie. The reason that this doesn't
  come up in the PSTN is because the things beyond the trust 
  boundary of the provider aren't the sole keepers of that
  information. 

 > 
 > But if some people get a great idea how to solve this problem and it requires a new SIP header. Will those people get Lynched? :-)

   If such a thing were possible, it might be entertained. I've
   yet to see any proposal that doesn't have a fatal flaw.

	  Mike

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


From sip-admin@ietf.org  Tue Jun 26 13:57:00 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01049;
	Tue, 26 Jun 2001 13:57:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19788;
	Tue, 26 Jun 2001 13:46:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19763
	for ; Tue, 26 Jun 2001 13:46:44 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00588
	for ; Tue, 26 Jun 2001 13:46:04 -0400 (EDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5QHih418554;
	Tue, 26 Jun 2001 13:44:43 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-91.cisco.com [161.44.241.91])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ABN08329 (AUTH pkyzivat);
	Tue, 26 Jun 2001 13:46:11 -0400 (EDT)
Message-ID: <3B38C960.98EEAFB5@cisco.com>
Date: Tue, 26 Jun 2001 13:41:52 -0400
From: Paul Kyzivat 
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Hammer 
CC: Jonathan Rosenberg ,
        "'Bob Penfield'" ,
        "'Barry Desborough'" , sip@ietf.org
Subject: Re: [Sip] RE: reason code in BYE/CANCEL (was[Sip-implementors] another  
 problem related to multiple call l egs at UAC)
References:  <4.3.2.7.2.20010626112550.03839a48@cia.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Michael Hammer wrote:
> 
> Yes, he did, in an email dated 5/11/2001.  Do you need a copy?

No, I guess not. After you provided the particulars I find I still have
it. But from what I can see I don't think it was ever published. And
others in this discussion were also on it:

Internet Engineering Task Force                                   SIP WG
Internet Draft                                Schulzrinne/Oran/Rosenberg
draft-schulzrinne-sip-reason-00.txt        Columbia U./Cisco/dynamicsoft
May 11, 2001
Expires: November 2001

Did the authors reconsider and decide not to publish this? I don't find
it on the IETF site.

	Paul

> 
> Mike
> 
> At 10:27 AM 6/26/2001 -0400, Paul Kyzivat wrote:
> 
> > Didn't Dave Oran float a proposal a month or two ago that included
> > something like this? I think it might even have used the "Reason"
> > header. I'd ask him, but I think he is away.
> >
> >         Paul Kyzivat
> >         Cisco Systems
> >
> > Jonathan Rosenberg wrote:
> > >
> > > > -----Original Message-----
> > > > From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> >
> > > > How about a "Reason" request header (or is that already
> > > > defined elswhere)
> > > > that uses the same format as the Warning header?
> > > >
> > > >         Reason        =  "Reason" ":" 1#reason-value
> > > >         reason-value  =  reason-code SP reason-agent SP
> > reason-text
> > > >         reason-code   =  3DIGIT
> > > >         reason-agent  =  host [ ":" port ]
> > > >                           ;  the name of the server adding
> > > >                           ;  the Reason header, for use in
> > > > tracing/debugging
> > > >         reason-text   =  quoted-string
> > > >
> > > >
> > > >
> > >
> > > Reason is not used. Seems reasonable for the header name.
> >
> > _______________________________________________
> > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip

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


From sip-admin@ietf.org  Tue Jun 26 14:27:46 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02068;
	Tue, 26 Jun 2001 14:27:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20590;
	Tue, 26 Jun 2001 14:04:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA20557
	for ; Tue, 26 Jun 2001 14:04:33 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01295
	for ; Tue, 26 Jun 2001 14:03:53 -0400 (EDT)
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5QI2V419881;
	Tue, 26 Jun 2001 14:02:31 -0400 (EDT)
Received: from bgracely-pc (bgracely-isdn1.cisco.com [10.83.118.50])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id ABP08319;
	Tue, 26 Jun 2001 14:03:59 -0400 (EDT)
Message-Id: <4.2.0.58.20010626135715.00a4bea0@dingdong.cisco.com>
X-Sender: bgracely@dingdong.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 26 Jun 2001 14:01:03 -0400
To: Paul Kyzivat , Michael Hammer 
From: Brian Gracely 
Subject: Re: [Sip] RE: reason code in BYE/CANCEL (was[Sip-implementors]
  another   problem related to multiple call l egs at UAC)
Cc: Jonathan Rosenberg ,
        "'Bob Penfield'" ,
        "'Barry Desborough'" , sip@ietf.org
In-Reply-To: <3B38C960.98EEAFB5@cisco.com>
References: 
 <4.3.2.7.2.20010626112550.03839a48@cia.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Dave never published it to I-D archives.   It just got circulated amongst 
some folks with similar email addresses as Dave's and with Henning & 
Jonathan.   A few other discussions we going on at the time on the aliases 
over whether headers like this we're too ISDN-like, so he didn't want it to 
get caught-up in the other "discussions".

BG


At 01:41 PM 06/26/2001 -0400, Paul Kyzivat wrote:


>Michael Hammer wrote:
> >
> > Yes, he did, in an email dated 5/11/2001.  Do you need a copy?
>
>No, I guess not. After you provided the particulars I find I still have
>it. But from what I can see I don't think it was ever published. And
>others in this discussion were also on it:
>
>Internet Engineering Task Force                                   SIP WG
>Internet Draft                                Schulzrinne/Oran/Rosenberg
>draft-schulzrinne-sip-reason-00.txt        Columbia U./Cisco/dynamicsoft
>May 11, 2001
>Expires: November 2001
>
>Did the authors reconsider and decide not to publish this? I don't find
>it on the IETF site.
>
>         Paul
>
> >
> > Mike
> >
> > At 10:27 AM 6/26/2001 -0400, Paul Kyzivat wrote:
> >
> > > Didn't Dave Oran float a proposal a month or two ago that included
> > > something like this? I think it might even have used the "Reason"
> > > header. I'd ask him, but I think he is away.
> > >
> > >         Paul Kyzivat
> > >         Cisco Systems
> > >
> > > Jonathan Rosenberg wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> > >
> > > > > How about a "Reason" request header (or is that already
> > > > > defined elswhere)
> > > > > that uses the same format as the Warning header?
> > > > >
> > > > >         Reason        =  "Reason" ":" 1#reason-value
> > > > >         reason-value  =  reason-code SP reason-agent SP
> > > reason-text
> > > > >         reason-code   =  3DIGIT
> > > > >         reason-agent  =  host [ ":" port ]
> > > > >                           ;  the name of the server adding
> > > > >                           ;  the Reason header, for use in
> > > > > tracing/debugging
> > > > >         reason-text   =  quoted-string
> > > > >
> > > > >
> > > > >
> > > >
> > > > Reason is not used. Seems reasonable for the header name.
> > >
> > > _______________________________________________
> > > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the application of sip
>
>_______________________________________________
>Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


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


From sip-admin@ietf.org  Tue Jun 26 15:11:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04398;
	Tue, 26 Jun 2001 15:11:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22690;
	Tue, 26 Jun 2001 14:54:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA22657
	for ; Tue, 26 Jun 2001 14:54:31 -0400 (EDT)
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02887
	for ; Tue, 26 Jun 2001 14:53:50 -0400 (EDT)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA13833; Tue, 26 Jun 2001 14:46:48 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AJK00573;
	Tue, 26 Jun 2001 14:46:46 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010626143919.00b0afd8@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 26 Jun 2001 14:48:47 -0400
To: "Zmolek, Andrew (Andrew)" 
From: Michael Hammer 
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Cc: "Jonathan Rosenberg" ,
        "Mathieu, Marie-Noelle" ,
        
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Andy,

It would appear that an independent "call ID" attribute not used as part of 
the key to the call-leg identity would be needed, unless you do a re-Invite 
backwards and use the same Call ID and replace the incoming session.  But, 
there are no guarantees that the backward session will succeed.  It's also 
not very elegant to hang up on one line while the call jumps to a second 
"line" as a new call, which I observed happening to someone once.  There 
could also be billing implications related to who placed the call and pays.

If the party called someone, then transferred that call separately from the 
held call or conference, then I would not expect the same Call ID.  If the 
incoming call was answered (other party on hold) and then transferred, that 
would also use additional Call IDs.

As for joining additional incoming calls into a conference, I too would be 
interested.

Mike

At 10:35 AM 6/26/2001 -0600, Zmolek, Andrew (Andrew) wrote:

> > >same call-id in the 2 INVITE requests, is this allowed ?
> >
> > Well, the current spec would indicate that you shouldn't do this:
> >
> > >The callid MUST be a globally unique identifier and MUST NOT be reused 
> for
> > >later calls.
> >
> > However, I recall some discussion at an IETF that people were using the 
> same
> > call-id across different call legs as a local identifier to correlate 
> those
> > call legs. With unique From tags and From fields, there really 
> shouldn't be
> > a problem, so I think its OK. However, if we are going to allow it, the 
> spec
> > should reflect it. Comments?
>
>If that's the proper way to solve this problem, then let's put that in the 
>spec. But I'm not convinced that this alone will solve all cases, 
>especially when this correlated information needs to be presented by a 
>call leg attempting to join (as in the consultative transfer case). It 
>only seems to work when the correlating entity initiates all the calls. If 
>there's a reliable way to correlate an incoming call leg with an existing 
>call, I'd love to hear about it.
>
>--Andy Zmolek
>     Technology & Standards Engineer
>       CTO Standards
>         Avaya Inc.
>
>             zmolek@avaya.com
>               +1 720 444 4001


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


From sip-admin@ietf.org  Tue Jun 26 15:19:10 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05076;
	Tue, 26 Jun 2001 15:19:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23229;
	Tue, 26 Jun 2001 15:04:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23198
	for ; Tue, 26 Jun 2001 15:04:12 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03826
	for ; Tue, 26 Jun 2001 15:03:31 -0400 (EDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5QJ48N24042;
	Tue, 26 Jun 2001 21:04:09 +0200 (MEST)
Received: from lmf.ericsson.se (racom-sd-81.sd.us.am.ericsson.se [142.133.141.82])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id VAA04860;
	Tue, 26 Jun 2001 21:04:40 +0200 (MET DST)
Message-ID: <3B38DE92.7058AA19@lmf.ericsson.se>
Date: Tue, 26 Jun 2001 22:12:18 +0300
From: Gonzalo Camarillo 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'adam.roach@ericsson.com'" ,
        "'Michael Thomas'" , John.Hearty@level3.com,
        sip@ietf.org
Subject: Re: [SIP] Killing hung media streams
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

> So, this begs a related question, which Pauls email introduces. If we say
> that a 481 to the INVITE means the call is down, does that mean the UAC
> should issue a BYE, or just destroy the call state? Right now, bis-03 says
> it should consider the call down, and does not mandate that a BYE should be
> sent (since, in any case, it will also result in a 481). The advantage of
> sending a BYE is for call-stateful boxes in the middle. It gives us the nice
> property that a call is always terminated by a BYE, even if triggered as a
> result of some other event in the SIP signaling path. This reduces the
> number of cases that devices need to worry about.

With this addition we basically recover the nice feature of treating
unknown 4xx reponses as 400. SIP entities that do not understand 481
will be able to treat a 481 received as a 400. That is, 481 indicates
that the request failed (as any other 4xx response), but it does not
indicate that the session has been terminated. This will still be
indicated by a BYE.

Best regards,

Gonzalo



> 
> So, I would propose that text be added to bis-03 which further mandates that
> a BYE be sent upon receiving a 481 to a mid-call request. Any objections?
> 
> Paul also wrote:
> > But there are some issues with the re-INVITE that I don't understand:
> >
> > If I believe the problem is with my end, and there is something
> > I can change (e.g. in my SDP) that would help solve the problem,
> > then of course I can offer that.
> >
> > But it seems like either I will believe the problem is with the
> > other end, or else I will have no idea where it is and have no
> > idea what kind of change might help. Suppose I have received ICMP
> > errors on my sends, and suspect the port I am sending to, or the
> > path to it, are down. When I send a reinvite, there is nothing
> > obvious for me to change in *my* SDP - I want the other end to
> > offer me something that will work better. So perhaps I send
> > unchanged SDP. When the other end receives this, it may have no
> > idea that anything is wrong. How does it decide that it should do
> > anything other than send unchanged SDP back?
> 
> Well, its the job of the user at the other end to know that there is a
> problem if one of its media streams has failed. How it knows this depends on
> the device. In the case of a decomposed gateway, if the gateway fails,
> presumably the MGC can detect this, and therefore do something about it when
> the re-INVITE arrives.
> 
> The interesting case is when the failure in the media stream is not due to
> either endpoint, but rather something in the network. In this case, a
> re-INVITE won't help, as it will change nothing (both sides offer the same
> SDP as before). In this case, you UA has to know to stop re-INVITing after a
> while, if the re-INVITEs don't eventually solve the problem. I suspect this
> will be a rare case, since if the media fails due to a network failure, the
> signaling will probably fail as well.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

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


From sip-admin@ietf.org  Tue Jun 26 15:27:32 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05769;
	Tue, 26 Jun 2001 15:27:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23668;
	Tue, 26 Jun 2001 15:18:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23583
	for ; Tue, 26 Jun 2001 15:18:22 -0400 (EDT)
Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04953
	for ; Tue, 26 Jun 2001 15:17:40 -0400 (EDT)
Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.2) id f5QJIHQ83978; Tue, 26 Jun 2001 15:18:17 -0400 (EDT)
Reply-To: 
From: "Brett Tate" 
To: "'Jonathan Rosenberg'" , 
Subject: RE: [Sip] new open issue in session timer: NEEDS resolution now!
Date: Tue, 26 Jun 2001 15:21:31 -0400
Message-ID: <002b01c0fe75$354a89c0$2b01a8c0@broadsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: 
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> > Intentional or not, the solution reduces the 
> > possibility of smaller Session-Expires values 
> > that might want to be used in pre-paid services 
> > through proxies.  
> 
> You're going to have troubles using session-timer for 
> duration-based billing
> for prepaid anyway.

I agree.  However I assume that there are 
products and services that might desire using 
Session-Expires for quicker cleanup on errors when 
predetermine max length of session happens to be 
smaller than the acceptable 
minimum-session-expires value.  The "none" value 
of the refresher parameter would easily accommodate 
such a thing.

http://www.ietf.org/mail-archive/working-groups/sip/current/msg00168.html

> 
> > 
> > > I welcome any other suggestions....
> > > 
> > > Another requirement for this to work is that, when a UA 
> > refreshes, it
> > > inserts a session-expres with the same timer as the previous 
> > > successful
> > > re-INVITE, unless it explicitly wishes to disable session 
> > > timers. Without
> > > that, the smurf attack is still possible! Thats because, if 
> > > each re-invite
> > > doesn't contain the last session timer, no request will 
> > actually ever
> > > contain a session-expires, and so there is no opportunity for 
> > > a proxy in
> > > front of the attacking proxy to reject the low values 
> > inserted by the
> > > attacking proxy!
> > 
> > I'm not sure that I understand your reasoning 
> > for requiring the same Session-Expires for 
> > re-INVITEs that were in the previous INVITE.  
> > Can't the whole renegotiation process take 
> > place again among the entities that stayed 
> > in the route?  This would force the smurf 
> > requesting small values to stay in the route.  
> 
> Thats true, but I don't consider this sufficient deterrent 
> for this attack
> to be prevented. In any case, the session-expires can still 
> be renegotiated.
> However, I think the more common case is a constant 
> session-timer for the
> call leg anyway.

The text that I was questioning was the part about
- 
  without inserting the same timer value in subsequent 
  re-invites, it opens the call-leg up to smurf attack.
-
The same smurf attack will always exist when the 
proxy returns small timer values to the refresher 
without having added/proxied the small value forward.  
(Note: This attack is performed by malicious proxies 
since that draft requires proxies to added their 
session-expires modifications in the request before 
blindly/maliciously adding them in the response.)


A---P1-----P2------B (INVITE/reinvite direction A to B)

If your concern was with A or P1 being able to 
reject a session-expires added by P2 or B; then 
minimum-session-expires can be added/updated by A 
or P1 in the INVITE/re-INVITE.  It sounds like 
minimum-session-expires should be added/updated 
in INVITE/re-INVITE by all proxies/UACs that are 
concerned or do not intend to honor small 
session-expires values that could otherwise added 
by P2 or B.  The minimum-session-expires value in 
a request can be increased but not decreased as it 
traverses proxies.


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


From sip-admin@ietf.org  Tue Jun 26 17:39:41 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22833;
	Tue, 26 Jun 2001 17:39:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27856;
	Tue, 26 Jun 2001 17:19:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27830
	for ; Tue, 26 Jun 2001 17:19:58 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20019
	for ; Tue, 26 Jun 2001 17:19:15 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA19456
	for ; Tue, 26 Jun 2001 17:23:58 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 17:19:50 -0400
Message-ID: 
From: Rakesh Shah 
To: "SIPWG Mailing List (E-mail)" 
Date: Tue, 26 Jun 2001 17:19:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] WGLC UPDATE - draft-ietf-sip-session-timer-04.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

The subject draft is nearly complete with working group open discussion.
Jonathan Rosenberg has identified two areas that still need clarification
before the -05 version can be completed. The two areas are:

     - Semantics of Require in request
     - Min-Timer header still needs to be there?

The open discussion will be closed on 9-Jul-01. If comments and discussion
on these topics are not forwarded to Jonathan by that time, he will develop
a solution and complete the document.

Thank you for your continued support on the reviews! 

Regards,

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


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


From sip-admin@ietf.org  Tue Jun 26 17:59:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25485;
	Tue, 26 Jun 2001 17:59:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28906;
	Tue, 26 Jun 2001 17:50:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28878
	for ; Tue, 26 Jun 2001 17:50:47 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24267
	for ; Tue, 26 Jun 2001 17:50:04 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA20006;
	Tue, 26 Jun 2001 17:54:48 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 17:50:40 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Zmolek, Andrew (Andrew)'" ,
        Jonathan Rosenberg
	 ,
        "Mathieu, Marie-Noelle"
	 ,
        sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Date: Tue, 26 Jun 2001 17:50:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



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


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

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

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



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

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

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

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

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


From sip-admin@ietf.org  Tue Jun 26 18:15:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28158;
	Tue, 26 Jun 2001 18:15:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29565;
	Tue, 26 Jun 2001 18:07:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29534
	for ; Tue, 26 Jun 2001 18:07:30 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26541
	for ; Tue, 26 Jun 2001 18:06:50 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA20256;
	Tue, 26 Jun 2001 18:11:20 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 18:07:12 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Michael Thomas'" ,
        "Arnoud van Wijk (ELN)"
	 
Cc: "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct  ser
	 v er
Date: Tue, 26 Jun 2001 18:07:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Tuesday, June 26, 2001 1:25 PM
> To: Arnoud van Wijk (ELN)
> Cc: 'sip@ietf.org'
> Subject: RE: [SIP] Authentication and billing through proxy/re-direct
> ser v er
> 
> 
> Arnoud van Wijk (ELN) writes:
>  > Yup. And that is now exactly my problem with Charging and Billing.
>  > The signalling and the bearer traverse different nodes/servers and
> >  pathways. So, SIP is currently unreliable to obtain exact call
> > duration.
> 
>   This isn't a SIP problem, per se; it's an inherent information
>   problem where a potentially untrusted device(s) is the only
>   thing in possession of the necessary information for which it
>   has high incentive to withhold/lie. The reason that this doesn't
>   come up in the PSTN is because the things beyond the trust 
>   boundary of the provider aren't the sole keepers of that
>   information. 

I would assert that if you are trying to reconstruct call duration at some
element B (a proxy or B2BUA) outside of the gateway which terminates the
call, this process is provably impossible if there is no trust relationship
between the gateway and B.

Now, if a trust relationship exists, the trick is just making sure that any
changes in call state detected by the gateway are reliably sent to B. If B
and the gateway communicate through a series of trusted peering connections
(i.e., TLS connections), AND the gateway only accepts and sends messages
over this connection, AND we can avoid attacks that cause the message to be
dropped or misrouted between the gateway and B (like Max-Forwards attacks)
we can be sure that any messages seen by the gateway are seen by B, and vice
a versa. The final trick is that the gateway needs to send a BYE if it
determines that the call has failed for some reason, such as a media
failure. We've been talking about that possibility on another thread (where
a re-INVITE 481 causes the server to generate a BYE).

One can ensure state synchronization through other means, like NOTIFYs, but
that seems silly. Rather, just ensure that the messages which affect state
changes at the gateway are always seen by element B. 

Given these constraints, one can reconstruct call duration in remote element
B within a time granularity on the order of magnitude of SIP message
transmit times, which are going to be seconds (32s being the maximum
transaction duration). Of course, network failures may cause
desynchronization as well, and this problem is unavoidable.

These contraints are significant, and hard to meet, but not insurmoutable.
The trick is the realization that a trust relationship through something
like TLS is a requirement. Of course, if at all possible, duration based
billing in the gateway is the best place. However, there are definitely
legitimate architectures and business models where it is not possible for
the call duration and billing information to be determined from the gateway.


-Jonathan R.

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

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


From sip-admin@ietf.org  Tue Jun 26 18:19:46 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28725;
	Tue, 26 Jun 2001 18:19:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29789;
	Tue, 26 Jun 2001 18:12:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29755
	for ; Tue, 26 Jun 2001 18:12:02 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27520
	for ; Tue, 26 Jun 2001 18:11:21 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA20356;
	Tue, 26 Jun 2001 18:16:03 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 18:11:56 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Drage, Keith (Keith)'" ,
        "'sip@ietf.org'"
	 
Subject: RE: [SIP] Congestion control
Date: Tue, 26 Jun 2001 18:11:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Drage, Keith (Keith) [mailto:drage@lucent.com]
> Sent: Tuesday, June 26, 2001 12:12 PM
> To: 'sip@ietf.org'; 'Jonathan Rosenberg'
> Subject: RE: [SIP] Congestion control
> 
> > 3. A server should generate and/or forward a 503 upstream 
> only if all
> > requests that would reach the server cannot be serviced. 
> This means that
> > the
> > server itself is congested, or every possible next-hop it 
> can route to is
> > congested (which is fairly unlikely but can happen in certain
> > configurations).
> > 
> What if the registrar of the terminating user is congested? 
> Should such an
> entity return a 503 if it knows there is no other server?

Yes. Similarly, a gateway would return a 503 if it runs out of ports.

> 
> I believe the requirement "SHOULD contact an alternative 
> server", and a
> general requirement to return a 503 are not particularly consistent -
> either:
> 
> a)	the general requirement to return a 503 results in a 
> MAY contact an
> additional server
> 
> b)	a 503 should be returned only when it is believed an additional
> server exists, and therefore under those circumstances the 
> client SHOULD
> contact an additional server.

Well, there may not be a way for some server X to know whether the upstream
server Y knows an alternative to X. THerefore, its unreasonable to say that
X should only return a 503 if it knows Y might find an alternate. A classic
example is where X is a PSTN gateway, and Y a proxy with a series of phone
routes. In this case, if X is busy, Y can try a different (and perhaps more
expensive) gateway. But, I don't want to have X need to know about the
existence of all other gateways.

Thus, I do not see how the requirements are in conflict.

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

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


From sip-admin@ietf.org  Tue Jun 26 18:24:51 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29569;
	Tue, 26 Jun 2001 18:24:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00072;
	Tue, 26 Jun 2001 18:18:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00042
	for ; Tue, 26 Jun 2001 18:18:49 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28556
	for ; Tue, 26 Jun 2001 18:18:09 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA20437;
	Tue, 26 Jun 2001 18:22:53 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 18:18:45 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'aki.niemi@nokia.com'" , jundery@ubiquity.net
Cc: sip@ietf.org
Subject: RE: [Sip] Request header integrity in HTTP Digest
Date: Tue, 26 Jun 2001 18:18:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Tuesday, June 26, 2001 10:48 AM
> To: jundery@ubiquity.net; jdrosen@dynamicsoft.com
> Cc: sip@ietf.org
> Subject: RE: [Sip] Request header integrity in HTTP Digest
> 
> 
> Hi,
> 
> May have missed some points in this thread. But let's not 
> totally trash this
> idea, creative usage of nonce values does indeed increase 
> security. I think
> this is stated in 2617, and this draft is exactly that, a 
> creative usage of
> nonce values.
> 
> But I have to agree with James on the fact, that ultimatelly, the same
> threats present with digest are still present with pnonce. 
> Hence, it doesn't
> deliver the goods it promises, which is integrity of headers.

I will back down on the statement that it provides header integrity, because
of the MITM attack that I agree is still possible.

However, it prevents against replay attacks which modify protected header
fields. These attacks can also be prevented with one time nonces. I will
agree that the approach cannot prevent any attacks that are prevented by
one-time nonces in rfc2617. But as the draft points out, one time nonces
require state in the server between the original request, and the new
request with credentials. As a result of this, the server becomes amenable
to DoS attacks since it stores state for unauthenticated requests. The
proposed mechanism, which is well within the spirit of rfc2617, which allows
for creative nonces as Aki has pointed out, provides the same benefits as
one time nonces without the cost of state.

In any case, its a local choice at the server, and need not be standardized.
If you think it won't help you, don't do it.

-Jonathan R.



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


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


From sip-admin@ietf.org  Tue Jun 26 18:39:49 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01977;
	Tue, 26 Jun 2001 18:39:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00322;
	Tue, 26 Jun 2001 18:24:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00288
	for ; Tue, 26 Jun 2001 18:24:07 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29368
	for ; Tue, 26 Jun 2001 18:23:27 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA20515;
	Tue, 26 Jun 2001 18:28:14 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 18:24:06 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Bob Penfield'" 
Cc: sip@ietf.org
Subject: RE: [Sip] [Sip-implementors] another problem related to multiple 
	call l egs at   UAC
Date: Tue, 26 Jun 2001 18:23:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> Sent: Tuesday, June 26, 2001 8:48 AM
> To: Jonathan Rosenberg
> Cc: sip@ietf.org
> Subject: Re:[Sip] [Sip-implementors] another problem related 
> to multiple
> call l egs at UAC
> 
> 
> Jonathan Rosenberg writes:
> 
> > Bob Penfield writes:
> > > Jonathan Rosenberg writes:
> > > 
> > >
> > > For example, I use a one-number service (unfortunately PSTN
> > > based) with a
> > > call screening feature that tells the callee who the call is
> > > for and who is
> > > holding and asks the callee to press 1 to accept the 
> call. The service
> > > simultaneouly rings my office, home, and cell phone. If this were
> > > implemented in SIP with a forking proxy to get to all the 
> devices I
> > > registered, and the proxy canceled the unanswered call legs
> > > as soon as one
> > > answered, I could not receive the call if my wife picked up
> > > the home phone
> > > before I answered my office or cell phone.
> > >
> > > I think it should be a MAY.
> >
> > Won't help. The caller here doesn't know about this 
> service, so they would
> > simply generate the CANCEL. Even if this weren't true, you 
> have another
> > problem. Multiple accepted call legs would only be 
> established under the
> > race condition where you and your wife pick up at once. 
> What you REALLY
> want
> > is that when you wife picks up, you can still pick up that 
> call (even
> though
> > your phone isn't ringing anymore) at any time until she 
> hangs up, and then
> > press 1 to accept. THis is the standard home phone line 
> behavior, which
> the
> > single line extension group was working on. Doing this 
> properly requires
> far
> > more than just not cancelling.
> >
> > I have some ideas on how to actually support this given our 
> current set of
> > tools for conferencing, and so I will (hopefully) have a 
> draft on how to
> > properly do it before London.
> >
> You don't necessarily need conferencing to do this.
> 
> To implement this service in SIPland would require some sort 
> of application
> server to prompt callees with the screening information. BTW, 
> as long as my
> wife does not press 1 to accept the call, I can still pick up 
> the call even
> if I answer long after she does because the service keeps 
> ringing the other
> phones until a callee presses 1.

Egads. Not a very nice user interface, but thats a separate discussion. 

> 
> But anyway, it would look something like this:
> 
> +--------+              +------------+              
> +-----+------------>
> home
> | caller |------------->| app server 
> |------------->|proxy|------------>
> office
> +--------+              +------------+              
> +-----+------------>
> cell
> 
> The SIP URL people use to call me would point to the app 
> server. The app
> server would know to send an invite to my local 
> proxy/registrar. The app
> server would act as a B2BUA or connect to the accepting 
> callee using REFER.
> But in this case, the app server is the UAC that is capable 
> of handling
> multiple 200-OKs (it would send SDP in the ACK as opposed to 
> the INVITE).
> The app server would issue a cancel when the callee accepts 
> by pressing 1.
> If my local proxy always canceled incomplete legs when it got 
> the first
> 200-OK, it breaks the application. And if the proxy does not 
> support caller
> preferences, then the app server can't tell it not to cancel.

Well, it comes down to which is the more common case. What you want is
readily supported so long as caller prefs is supported in the proxies.
Agreed. However, it is not the common case. The more common case is a normal
forked call whose objective is to reach the first user that picks up. Since
the caller doesn't know which proxies have forked, pushing the
responsibility to CANCEL to the caller doesn't seem appropriate.
Effectively, every UA would have to generate a CANCEL every time it gets a
2xx. Yuck. Thus, I would argue that the proxies which fork are the ones that
should be handling the CANCEL in the common case.

In other words, the common case should be the one thats a SHOULD, and the
exceptional cases handled with extensions.

-Jonathan R.

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

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


From sip-admin@ietf.org  Tue Jun 26 21:27:16 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08933;
	Tue, 26 Jun 2001 21:27:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05683;
	Tue, 26 Jun 2001 21:18:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05652
	for ; Tue, 26 Jun 2001 21:18:35 -0400 (EDT)
Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06615
	for ; Tue, 26 Jun 2001 21:17:54 -0400 (EDT)
From: John.Hearty@level3.com
Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id BAA20252
	for ; Wed, 27 Jun 2001 01:18:32 GMT
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id BAA22869
	for ; Wed, 27 Jun 2001 01:18:32 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19)
	id ; Tue, 26 Jun 2001 19:18:32 -0600
Message-ID: <17052388D394D411803900508BDFFAF6013DCA05@n0214idc1.oss.level3.com>
To: sip@ietf.org
Date: Tue, 26 Jun 2001 19:18:31 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Transport parm in Record-Route
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org


 We have encountered a problem with the requirement in 16.3 where
Record-Route MUST NOT contain the transport parameter.  I realize this was
designed to handle the possibility of requiring a UA that does not support a
particular transport to use said transport, resulting in a failure.
However, this also causes problems when the proxy must use only one
transport for all transactions.  Take for example a proxy (B) in a private
network that has a TLS connection with a trusted peer proxy (A) on the open
Internet.  The flow for an Invite might be something like:

UAC -> proxy (A) -> proxy (B) -> UAS

 Now if both proxies are record-routed without the transport parm, the
initial transaction could be setup on TLS OK based on proxy (A) routing
decisions, but if a subsequent transaction such as BYE came from the UAC,
proxy (A) would see a Route header with no transport parm, use it as the
req-URI which, lacking a transport parm results in using default UDP (see
reference below).  Since proxy (B) only trusts and listens for requests over
a TLS connection, the request fails.

From section 2, descrition of URL parameters:

UDP is to be assumed when no explicit transport parameter is included.

 Perhaps some new verbage is needed describing proxy behaviour and how to
select the transport protocol when not specified, i.e. look for open TLS or
TCP sockets to the destination first.  This still might not help if for
example the transport was TCP and the socket timed out due to inactivity.
There may be other ways around this problem I have not thought through yet.
Comments?


John Hearty
Level3

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


From sip-admin@ietf.org  Wed Jun 27 01:12:31 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08553;
	Wed, 27 Jun 2001 01:12:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12065;
	Wed, 27 Jun 2001 01:01:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12034
	for ; Wed, 27 Jun 2001 01:01:20 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02972
	for ; Wed, 27 Jun 2001 01:00:38 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f5R51CO11735;
	Wed, 27 Jun 2001 07:01:13 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.7])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5R51C524569;
	Wed, 27 Jun 2001 08:01:12 +0300 (EET DST)
Message-ID: <3B396890.C2FE0ED9@lmf.ericsson.se>
Date: Wed, 27 Jun 2001 08:01:04 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Hammer 
CC: sip@ietf.org
Subject: Re: [Sip] Some thoughts about CANCEL for specific legs,together with SIP 
 extensions
References: <4.3.2.7.2.20010626103037.00b0cca0@cia.cisco.com>
Content-Type: multipart/mixed;
 boundary="------------657BAFA4789D36A1375A6768"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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


Hi Michael,

Thanks for your comments.

Michael Hammer wrote:
> 
>Christer,
> 
>Could you clarify whether the multi-leg call is due to forking?  It is not
>clear why you invited the call-leg to begin with, then later wanted to cancel.

It is due to forking.
 
>Issue 2 seems to be tied up in the meaning of call versus call-leg, where
>the existing rules about sessions apply to a call-leg, but are termed a
>call.  If each leg in the call is requested by different session
>transactions then the sequences of setup and release could progress
>independently.

From a UAC point of view it is the same transaction, because it sends a
single INVITE. However, the proxy then forks it, and it may receive
multiple final responses (including multiple 200 OK).

Regards,

Christer Holmberg
Ericsson Finland




> 
> Is there some nuance missing?
> 
> Mike
> 
> At 11:30 AM 6/26/2001 +0300, Christer Holmberg wrote:
> 
> >Hi,
> >
> >Some thoughts/issues came to my mind when I read the thread (the SIP
> >implementors list) about using CANCEL for specific call-legs.
> >
> >I KNOW we have spent lots of time discussing this, but I am not pretty
> >sure that we have really thought about all the scenarios when some of
> >the SIP EXTENSIONS (in this mail I mention the Caller preferences-,
> >PRACK- and pre-call-setup requests features, and the scenario where the
> >UAC wants to choose specific call-legs for a call).
> >
> >Instead, I think we mostly have assumed that a call setup is simply an
> >INVITE, possible provisonal responses, and one or many final responses
> >plus their ACKs, and in those cases I don't think we have any major
> >problems.
> >
> >I even think some of the extensions may LOOSE some of the good stuff
> >they are supposed to provide due to these issues.
> >
> >
> >Issue 1: Caller preferences
> >
> >The Caller preferences feature allow the UAS to indicate the feature
> >parameter in the response. The draft mentions the 200 response, but I
> >guess it is (at least it should be) allowed also in a provisional
> >response with a To-tag and Contact header. So, now the UAC may at a very
> >early stage of the call setup find out about what kind of servers it has
> >received provisional responses from, which means it may at a very early
> >stage find out that it does not want a specific call-leg (for example,
> >one could receive provisional responses from two different answering
> >machinges, or something...). However, the UAC is not able to cancel any
> >call leg (without terminating the whole call setup) before it has
> >received a final response from one UAS, which means it may have to
> >handle PRACKs, INFOs, and who knows what, with all servers - also those
> >it will never establish a call with. A solution to this could be to
> >allow CANCEL for a specific leg (assuming that the provisional responses
> >included a To-tag and Contact). If PRACKs (or other requests used before
> >the call is setup) are involved, the provisinal responses most likely
> >will include the tag and Contact, so...
> >
> >
> >Issue 2: Multi-leg call
> >
> >This could be related to the previous issue, but it can also be a "stand
> >alone" issue. Again, a UAC may receive multiple provisional responses.
> >It is going to establish a multi-leg call, ie it is going to accept a
> >specific set of final responses. Again, however, it receives provisonal
> >responses also from other servers, but again - it is not able to cancel
> >those legs before it has received the final responses for ALL parties
> >that will be in the multi-leg call. Allowing CANCEL for a specific leg
> >would help also here.
> >
> >What also may happen here, is that we receive a final response for a leg
> >that we do NOT want in the call, but we still want to wait for another
> >final response. Now we could simply ACK and BYE that leg, but then we
> >come to the issue about sending BYE requests before the whole call has
> >been setup. However, the bis DOES say that BYE is used to terminate an
> >established call-leg, and that is what we would be doing here - no
> >matter if the WHOLE multi-leg call is setup or not - BUT, the bis also
> >says "To terminate a call instead of just pending searches, the UAC must
> >use BYE instead of or in addition to CANCEL". So, I guess some
> >clarifications in the bis may be needed here.
> >
> >
> >
> >Conclusion:
> >
> >So, I don't know if we are talking about changes, or simple
> >clarifications, in the spec, but the issues are:
> >
> >1. Should we allow CANCEL for a specific call-leg, IF we have received a
> >To-tag and Contact in the provisional response?
> >
> >2. Should we allow BYE for an established call-leg, even if the whole
> >call is yet not setup (the UAC is waiting for another final response)?
> >
> >I know that we have the issue about a UAS receiving the same request
> >from different locations (when the request has been forked), so we have
> >to find out in which scenarios this can be a problem, and how likely it
> >is that those scenarios will take place.
> >
> >
> >Comments?
> >
> >Regards,
> >
> >Christer Holmberg
> >Ericsson Finland
--------------657BAFA4789D36A1375A6768
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------657BAFA4789D36A1375A6768--


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


From sip-admin@ietf.org  Wed Jun 27 01:19:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12006;
	Wed, 27 Jun 2001 01:19:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19605;
	Wed, 27 Jun 2001 01:13:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19501
	for ; Wed, 27 Jun 2001 01:13:46 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08901
	for ; Wed, 27 Jun 2001 01:13:03 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5R5DfN17121;
	Wed, 27 Jun 2001 07:13:42 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.7])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5R5Df524830;
	Wed, 27 Jun 2001 08:13:41 +0300 (EET DST)
Message-ID: <3B396B7D.A6EA11C6@lmf.ericsson.se>
Date: Wed, 27 Jun 2001 08:13:33 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Penfield 
CC: sip@ietf.org
Subject: Re: [Sip] Some thoughts about CANCEL for specific legs, together with  
 SIPextensions
References: <3B384823.AC343408@lmf.ericsson.se> <3B385B6D.BD124609@lmf.ericsson.se> <00e201c0fe47$6c470260$2300000a@acmepacket.com>
Content-Type: multipart/mixed;
 boundary="------------57BB9EC50F2B008BEFEFED7E"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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


Hi Bob,

> > Hi,
> >
> > Some clarificatons to my previous mail.
> >
> > >Hi,
> > >
> > >Some thoughts/issues came to my mind when I read the thread (the SIP
> > >implementors list) about using CANCEL for specific call-legs.
> > >
> > >I KNOW we have spent lots of time discussing this, but I am not pretty
> > >sure that we have really thought about all the scenarios when some of
> > >the SIP EXTENSIONS (in this mail I mention the Caller preferences-,
> > >PRACK- and pre-call-setup requests features, and the scenario where the
> > >UAC wants to choose specific call-legs for a call).
> > >
> > >Instead, I think we mostly have assumed that a call setup is simply an
> > >INVITE, possible provisonal responses, and one or many final responses
> > >plus their ACKs, and in those cases I don't think we have any major
> > >problems.
> > >
> > >I even think some of the extensions may LOOSE some of the good stuff
> > >they are supposed to provide due to these issues.
> > >
> > >Issue 1: Caller preferences
> > >
> > >The Caller preferences feature allow the UAS to indicate the feature
> > >parameter in the response. The draft mentions the 200 response, but I
> > >guess it is (at least it should be) allowed also in a provisional
> > >response with a To-tag and Contact header. So, now the UAC may at a very
> > >early stage of the call setup find out about what kind of servers it has
> > >received provisional responses from, which means it may at a very early
> > >stage find out that it does not want a specific call-leg (for example,
> > >one could receive provisional responses from two different answering
> > >machinges, or something...). However, the UAC is not able to cancel any
> > >call leg (without terminating the whole call setup) before it has
> > >received a final response from one UAS, which means it may have to
> > >handle PRACKs, INFOs, and who knows what, with all servers - also those
> > >it will never establish a call with. A solution to this could be to
> > >allow CANCEL for a specific leg (assuming that the provisional responses
> > >included a To-tag and Contact). If PRACKs (or other requests used before
> > >the call is setup) are involved, the provisinal responses most likely
> > >will include the tag and Contact, so...
> > >
> > >Issue 2: Multi-leg call
> > >
> > >This could be related to the previous issue, but it can also be a "stand
> > >alone" issue. Again, a UAC may receive multiple provisional responses.
> > >It is going to establish a multi-leg call, ie it is going to accept a
> > >specific set of final responses. Again, however, it receives provisonal
> > >responses also from other servers, but again - it is not able to cancel
> > >those legs before it has received the final responses for ALL parties
> > >that will be in the multi-leg call. Allowing CANCEL for a specific leg
> > >would help also here.
> > >
> > >What also may happen here, is that we receive a final response for a leg
> > >that we do NOT want in the call, but we still want to wait for another
> > >final response. Now we could simply ACK and BYE that leg, but then we
> > >come to the issue about sending BYE requests before the whole call has
> > >been setup. However, the bis DOES say that BYE is used to terminate an
> > >established call-leg, and that is what we would be doing here - no
> > >matter if the WHOLE multi-leg call is setup or not - BUT, the bis also
> > >says "To terminate a call instead of just pending searches, the UAC must
> > >use BYE instead of or in addition to CANCEL". So, I guess some
> > >clarifications in the bis may be needed here.
> >
> > First, since multi-leg calls, ie conferences, are handled in a different
> > way I guess that can be dropped from this issue.
> >
> > Also, when I talked about not accepting the first 200, I did not only
> > mean clients, but also a forking proxies (and, since it has been said
> > that proxies SHOULD cancel all the other legs when the first 200 is
> > received, it SHOULD not even be an issue for a client). However, the
> > issue is if the proxy should be able NOT to accept and forward the first
> > 200, since it has received provisonal responses also from another UAS
> > that it wants to be in the call.
> >
> > > Conclusion:
> > >
> > > So, I don't know if we are talking about changes, or simple
> > > clarifications, in the spec, but the issues are:
> > >
> > > 1. Should we allow CANCEL for a specific call-leg, IF we have received a
> > > To-tag and Contact in the provisional response?
> > >
> 
>I personally like the idea.

I think it can be useful also in other areas, for example when we talk
about EARLY MEDIA and media address/port verification. For example, if
the UAC receives multiple 18x, with multiple different session
descriptions, it can choose which leg to use and cancel the others - and
the good thing is that all this can be done before the call is
established.
 
Another scenario is when we send pre-call INFOs. If we have received
multiple provisonal responses, representing different call-legs, the UAC
may not know to which server it should send the INFOs, or if it has to
send the INFO to all servers, OR if the INFOs should be sent like the
original INVITE (and currently also like CANCEL), ie without any tags,
routes and other leg information. This problem was also mentioned in a
mail by Jonathan a few days ago, I think.

>>>2. Should we allow BYE for an established call-leg, even if the whole
>>>call is yet not setup (the UAC is waiting for another final response)?
> 
>If by "established call-leg", you mean one that has received a 2xx response,
>sending BYE is just for that leg is just fine.
> 
>Section 6 of bis-03 says we SHOULD NOT send a BYE to terminate a request
>that has not recieved either a final or provisional response. Does that mean
>we can send BYE if we have received a provisional response? A UAS is suppose
>to cancel a call-leg that it has not generated a final response for if it
>gets a BYE. Is it legal (and desireable) to terminate a provisional call-leg
>with BYE?

This has been discussed alot, and the decission was that it IS allowed.
However, I guess that we still have the same issue that we have with
CANCEL: are we allowed to BYE a specific call-leg before we have
received a final response for that leg, or is the BYE supposed to
terminate all call-leg setups?

Thanks for your comments!

Regards,

Christer Holmberg
Ericsson Finland



> 
> >
> > Again, the second issue is only valid for forking proxies, IF they
> > cancel all other legs when the first 200 is received.
> 
> If a provisional response had reached the UAC shouldn't that UAC still get a
> 487 response when the proxy cancels the call leg? Or would that only happen
> if the provisional response is PRACK'd?
> 
> >
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> >
> >
> >
> >
> > >
> > > I know that we have the issue about a UAS receiving the same request
> > > from different locations (when the request has been forked), so we have
> > > to find out in which scenarios this can be a problem, and how likely it
> > > is that those scenarios will take place.
> > >
> > > Comments?
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
--------------57BB9EC50F2B008BEFEFED7E
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------57BB9EC50F2B008BEFEFED7E--


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


From sip-admin@ietf.org  Wed Jun 27 01:40:30 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22930;
	Wed, 27 Jun 2001 01:40:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20752;
	Wed, 27 Jun 2001 01:34:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20723
	for ; Wed, 27 Jun 2001 01:34:20 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19376
	for ; Wed, 27 Jun 2001 01:33:39 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f5R5YHO17113;
	Wed, 27 Jun 2001 07:34:17 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.7])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5R5YG525334;
	Wed, 27 Jun 2001 08:34:16 +0300 (EET DST)
Message-ID: <3B397050.3EB25640@lmf.ericsson.se>
Date: Wed, 27 Jun 2001 08:34:08 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Zmolek, Andrew (Andrew)'" ,
        "Mathieu, Marie-Noelle" ,
        sip@ietf.org
Subject: Re: [Sip] RE: [Sipping] Call and call-id
References: 
Content-Type: multipart/mixed;
 boundary="------------8A778B4B6943FCF29C628BA1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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


Hi,

Just a couple of small comments.

If we allow this, I guess using From tags has to be a MUST, since the
two (or more) separate INVITE requests may end up at the same physical
node - even if they are sent to different "logical" nodes (UA B and UA
C).

Also, I also think that it shall be clearly written, on a general call
level, that the From tag must be used when nodes map requests to
specific calls. Currently I think the bis only talks about this on a
transaction level.

Regards,

Christer Holmberg
Ericsson Finland



Jonathan Rosenberg wrote:
> 
> 
> -----Original Message-----
> From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com]
> Sent: Tuesday, June 26, 2001 12:35 PM
> To: Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org
> Subject: RE: [Sip] RE: [Sipping] Call and call-id
> 
> >> >same call-id in the 2 INVITE requests, is this allowed ?
> >>
> >> Well, the current spec would indicate that you shouldn't do this:
> >>
> >> >The callid MUST be a globally unique identifier and MUST NOT be reused
> for
> >> >later calls.
> >>
> >> However, I recall some discussion at an IETF that people were using the
> same
> >> call-id across different call legs as a local identifier to correlate
> those
> >> call legs. With unique From tags and From fields, there really shouldn't
> be
> >> a problem, so I think its OK. However, if we are going to allow it, the
> spec
> >> should reflect it. Comments?
> >
> >If that's the proper way to solve this problem, then let's put that in the
> >spec. But I'm not convinced that this alone will solve all cases,
> especially
> >when this correlated information needs to be presented by a call leg
> attempting
> >to join (as in the consultative transfer case).
> 
> Careful; I am not proposing that two call legs with the same Call-ID convey
> any semantics. Specifically, receiving an INVITE from A, while in a call
> with B, where the call-id in the INVITE from A equals the call-id in the leg
> with B, does NOT imply that this is a consultative transfer. For that, we
> have Replaces, which lists the replaced leg explicitly.
> 
> All I am saying is that a Call-ID may be reused for local convenience, if
> desired, but that it has NO semantics outside of the entity that selected
> that call-id.
> 
> > It only seems to work when the
> >correlating entity initiates all the calls. If there's a reliable way to
> >correlate an incoming call leg with an existing call, I'd love to hear
> about
> >it.
> 
> http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00.txt
> 
> needs updating and adoption though, if we plan to move forward with it. As
> you can see, its currently in the morgue.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
--------------8A778B4B6943FCF29C628BA1
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------8A778B4B6943FCF29C628BA1--


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


From sip-admin@ietf.org  Wed Jun 27 02:02:16 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04402;
	Wed, 27 Jun 2001 02:02:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21246;
	Wed, 27 Jun 2001 01:55:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21213
	for ; Wed, 27 Jun 2001 01:55:21 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28618
	for ; Wed, 27 Jun 2001 01:54:39 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5R5tHN26585;
	Wed, 27 Jun 2001 07:55:17 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.7])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5R5tG525829;
	Wed, 27 Jun 2001 08:55:16 +0300 (EET DST)
Message-ID: <3B39753C.CE406DBF@lmf.ericsson.se>
Date: Wed, 27 Jun 2001 08:55:08 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Bob Penfield'" ,
        "'Barry Desborough'" ,
        "'Paul Kyzivat'" , sip@ietf.org,
        gonzalo.camarillo@lmf.ericsson.se
Subject: Re: [Sip] RE: reason code in BYE/CANCEL (was [Sip-implementors] another 
 problem related to multiple call l egs at   UAC)
References: 
Content-Type: multipart/mixed;
 boundary="------------B850F66EE87D37E7645A5D16"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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



Hi,

Some example of codes that maybe could be useful.


403 Session-timer expired

This would be used if the call is released when the session-timer
expires.


404 Another leg chosen

This would be useful IF we allow CANCELs and pre-call-setup BYEs for
specific call-legs (discussion on this in another thread...)


405 Service not available

This could be used for many purposes. One example could be some kind of
calling card/pre-pay call service. When the caller runs out of money, or
the call time limit is exceeded, the call could be terminated using this
Reason.


406 Client error

This would be used if the client, for any internal reason, must
terminate the call. Load balancing is one example where this could be
used. Another example is if the call state somehow gets messed up in the
client, and it deciedes to release the call. 

This Reason could also be used, for the same purpose, by proxies, or
there could be a separate Reason value for those (407 Proxy error)

A couple of issues, though:


Issue 1: Use existing codes

Before we start defining a new set of codes, I DO think that we should
have a look at the existing response codes, and see if they (or part of
them) can be used for the Reason header. Then, if we define new codes,
they may also be used for responses.


Issue 2: ISUP-SIP

I assume this COULD also affect the ISUP-SIP mapping, IF different
Reason header values will produce different mapping. I guess Gonzalo can
comment on this.


Regards,

Christer Holmberg
Ericsson Finland





Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> > Sent: Monday, June 25, 2001 5:04 PM
> > To: Jonathan Rosenberg; 'Barry Desborough'; 'Paul Kyzivat'
> > Cc: sip@ietf.org
> > Subject: reason code in BYE/CANCEL (was [Sip-implementors] another
> > problem related to multiple call l egs at UAC)
> >
> >
> >
> > Jonathan Rosenberg wrote:
> > >
> > >
> > >  Moving from sip-implementors to sip since there are some
> > open issues and
> > > changes to bis in here.
> > >
> > >
> >
> > 
> > > Barry Desborough wrote:
> > >
> > > > I also agree that encoded reasons should be added to BYEs and
> > > > CANCELs such
> > > > that a PSDN gateway can map them to and from Q.931 cause codes.
> > >
> > > I also like these BYE reasons. This has come up countless
> > times. Its also
> > > helpful in CANCEL, to know whether a call was cancelled
> > because the caller
> > > aborted, or because some other branch picked up (the former
> > would generate
> > a
> > > missed call entry in a call log, whilst the other won't). I
> > don't think
> > > Warning is right, but some kind of header that conveys both a
> > > machine-interpretable and human-interpretable value would be good.
> > >
> > How about a "Reason" request header (or is that already
> > defined elswhere)
> > that uses the same format as the Warning header?
> >
> >         Reason        =  "Reason" ":" 1#reason-value
> >         reason-value  =  reason-code SP reason-agent SP reason-text
> >         reason-code   =  3DIGIT
> >         reason-agent  =  host [ ":" port ]
> >                           ;  the name of the server adding
> >                           ;  the Reason header, for use in
> > tracing/debugging
> >         reason-text   =  quoted-string
> >
> >
> >
> 
> Reason is not used. Seems reasonable for the header name.
> 
> I'm not sure the reason-agent is needed.
> 
> The trick is defining the codes. A few I can think of:
> 
> 400 Caller hung up
> 
>   this would be in a CANCEL if the UAC hangs up before an INVITE generates a
> final response, or in a BYE at any point later. Its the normal call
> termination case.
> 
> 401 INVITE succeeded elsewhere
> 
>   this would be in a CANCEL generated because an INVITE generated a 2xx on
> another branch.
> 
> 402 media stream failure
> 
>   this would be in a BYE that was sent because there was some failure in the
> media streams or something like that.
> 
> other suggestions?
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
--------------B850F66EE87D37E7645A5D16
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------B850F66EE87D37E7645A5D16--


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


From sip-admin@lists.bell-labs.com  Wed Jun 27 03:49:30 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08193
	for ; Wed, 27 Jun 2001 03:49:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6971244344; Wed, 27 Jun 2001 03:50:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id EFD6444336
	for ; Wed, 27 Jun 2001 03:49:23 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f5R7nON10719
	for ; Wed, 27 Jun 2001 09:49:24 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Jun 27 09:49:23 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Wed, 27 Jun 2001 09:49:22 +0200
Message-ID: <1367DA832A24D311A95C0008C791C77008AB3D0E@eitrmnt100.tei.ericsson.se>
From: "Giuseppe De Marco (TEI)" 
To: "'Hidefumi Nakamura '" ,
        "'sip@lists.bell-labs.com '" 
Subject: RE: [SIP] Congestion control
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-2022-jp"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 27 Jun 2001 09:49:16 +0200

 
I am not an expert on SIP. But, reading your message, I think that there are two way to solve the problem:
1) By modifyng the proxy A which would changes its state machine if receive a 503 response from other proxy server, so that the next calls form othe UA's will be propley delayd, without proxying calls away;
2) whitout modifyng the proxy, proxy A ignores the information about congestion on others proxies, and repeats its function for every call as it is a first call.

bye

giuseppe de marco


-----Original Message-----
From: Hidefumi Nakamura
To: sip@lists.bell-labs.com
Sent: 22/06/01 15.17
Subject: [SIP] Congestion control

Hi. all,

I have a couple of questions about the suitable way to let the user
agents/
proxy-servers know the congestion of sip-proxy(stateful) or location
server, 
and the suitable action after the notification.

As long as I review the sip document (rfc2543bis-03), I think
the most suitable way is to return a "503 service unavailable" message
with "Retry-after" field.  Is is correct understanding?

The other question is of the case when the INVITE request comes via
several (stateful) proxy servers.  That is, INVITE comes through

UAa --> proxy A --> proxy B --> UAb

and proxy B is in congestion.

In this case, proxy B will return a "503" message to UserAgent-a (UAa)
via proxy A if my understanding of the first question is correct.   UAa
will postpone to send a message to proxy A, but what should "proxy A"
do if it receives other INVITE messages for proxyB, say, from UAc,
within
the period indicated in "retry-after" field?
Should proxy-A send "503" to UAc or transfer the INVITE message
to proxy-B even if proxy-A already has the information that proxy-B
is in congestion?

Please let me know.

Thanks.

---
Hidefumi NAKAMURA
NTT Network Service Systems Laboratories
tel:+81 (422)59 3904; fax:+81 (422)60 4012
---

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

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


From sip-admin@lists.bell-labs.com  Wed Jun 27 04:18:31 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22935
	for ; Wed, 27 Jun 2001 04:18:29 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9CB9444367; Wed, 27 Jun 2001 04:19:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis22.marconicomms.com (unknown [195.99.244.54])
	by lists.bell-labs.com (Postfix) with ESMTP id CFD1044360
	for ; Wed, 27 Jun 2001 04:18:21 -0400 (EDT)
Received: from cvis03.gpt.co.uk (unverified) by cvis22.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id ;
 Wed, 27 Jun 2001 09:17:41 +0100
Received: from marconicomms.com by cvis03.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-32) id JAA27604; Wed, 27 Jun 2001 09:17:46 +0100 (BST)
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 80256A78.002CD367 ; Wed, 27 Jun 2001 09:09:37 +0100
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Wayne Cutler" 
To: "Mark Watson" 
Cc: sip@lists.bell-labs.com
Message-ID: <80256A78.002CC82B.00@marconicomms.com>
Subject: RE: [SIP] Re: Re Mapping of ISUP overlap signalling to SIP
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=dLXlfmmJooJ8ZnJ77fiOEaobKnzJA2e3gAmAoylZg3gcBFOwO8F9fgT0"
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 27 Jun 2001 09:09:12 +0100

--0__=dLXlfmmJooJ8ZnJ77fiOEaobKnzJA2e3gAmAoylZg3gcBFOwO8F9fgT0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Mark,

Yes, you're correct that my proposal does assume that the i/c GW can identify
the o/g GW.

So, whilst not being a general case, it is still a valid scenario for a limited
applicability.

I agree that there hasn't been a conclusion and as it stands it appears that
ETSI ISUP gets forced to work
en-bloc by default.

Regards, Wayne.








"Mark Watson"  on 26/06/2001 17:32:28
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      Wayne Cutler/MAIN/MC1@MCMAIN, Gonzalo Camarillo     
                           
                                                              
 cc:      sip@lists.bell-labs.com                             
                                                              
                                                              
                                                              
 Subject: RE: [SIP] Re: Re Mapping of ISUP overlap signalling 
          to SIP                                              
                                                              







Wayne,

Your proposal presumes that the incoming PSTN/SIP gateway can identify the
outgoing SIP/PSTN gateway. If this knowledge is instead in an intermediate
SIP proxy, then the digit information will need to be in the SIP headers,
because the proxy will not examine the ISUP payload.

IMO, once the INVITE has reached the o/g SIP/PSTN gateway, it would be of
value for subsequent digits to travel in INFOs (a backwards indication that
this was allowed would be needed at this point).

But as Gonzalo says this has been discussed ad nauseum on this list, to no
clear conclusion AFAIK.

Regards,

Mark Watson
Nortel Networks



> -----Original Message-----
> From: Wayne Cutler [mailto:Wayne.Cutler@marconi.com]
> Sent: 26 June 2001 13:19
> To: Gonzalo Camarillo
> Cc: sip@lists.bell-labs.com
> Subject: [SIP] Re: Re Mapping of ISUP overlap signalling to SIP
>
>
>
>
> >Hello,
>
> >There have been millons of mails sent to the mailins list in the past
> >discussing exactly what you are proposing. Besides, this has been
> >presented in several WG meetings.
>
> >Feel free to check the archives to find more information about this.
>
> Whilst here has been a good deal of discussion on the general
> topic (over at
> least 3 threads), the vast majority
> were concerned with including the overlap digits in various
> SIP headers.
> Therefore, there hasn't been a great deal
> of discussion about making the SIP headers independent of the
> overlap digits. I
> do recall your presentation in the last
> WG meeting but that suggested sending multiple INVITEs and
> (as I recall) there
> was nothing said about the option of
> making the SIP headers independent of the overlap digits.
>
> So, for limited scenarios, I fail to see why it is
> wrong/improper to make the
> headers independent of the overlap digits. Such an
> approach is workable and  does not require any changes to the
> SIP protocol. So
> why can't it be added as another option, with a
> suitable health warning about its limited applicability?
>
> Wayne.
>
>
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
>


--0__=dLXlfmmJooJ8ZnJ77fiOEaobKnzJA2e3gAmAoylZg3gcBFOwO8F9fgT0
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC41OSI+DQo8VElUTEU+UkU6IFtT
SVBdIFJlOiBSZSBNYXBwaW5nIG9mIElTVVAgb3ZlcmxhcCBzaWduYWxsaW5nIHRvIFNJUDwvVElU
TEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPldheW5lLDwvRk9OVD4NCjwv
UD4NCg0KPFA+PEZPTlQgU0laRT0yPllvdXIgcHJvcG9zYWwgcHJlc3VtZXMgdGhhdCB0aGUgaW5j
b21pbmcgUFNUTi9TSVAgZ2F0ZXdheSBjYW4gaWRlbnRpZnkgdGhlIG91dGdvaW5nIFNJUC9QU1RO
IGdhdGV3YXkuIElmIHRoaXMga25vd2xlZGdlIGlzIGluc3RlYWQgaW4gYW4gaW50ZXJtZWRpYXRl
IFNJUCBwcm94eSwgdGhlbiB0aGUgZGlnaXQgaW5mb3JtYXRpb24gd2lsbCBuZWVkIHRvIGJlIGlu
IHRoZSBTSVAgaGVhZGVycywgYmVjYXVzZSB0aGUgcHJveHkgd2lsbCBub3QgZXhhbWluZSB0aGUg
SVNVUCBwYXlsb2FkLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5JTU8sIG9uY2UgdGhl
IElOVklURSBoYXMgcmVhY2hlZCB0aGUgby9nIFNJUC9QU1ROIGdhdGV3YXksIGl0IHdvdWxkIGJl
IG9mIHZhbHVlIGZvciBzdWJzZXF1ZW50IGRpZ2l0cyB0byB0cmF2ZWwgaW4gSU5GT3MgKGEgYmFj
a3dhcmRzIGluZGljYXRpb24gdGhhdCB0aGlzIHdhcyBhbGxvd2VkIHdvdWxkIGJlIG5lZWRlZCBh
dCB0aGlzIHBvaW50KS48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+QnV0IGFzIEdvbnph
bG8gc2F5cyB0aGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBhZCBuYXVzZXVtIG9uIHRoaXMgbGlzdCwg
dG8gbm8gY2xlYXIgY29uY2x1c2lvbiBBRkFJSy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJ
WkU9Mj5SZWdhcmRzLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPk1hcmsgV2F0c29u
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Ob3J0ZWwgTmV0d29ya3M8L0ZPTlQ+DQo8L1A+DQo8
QlI+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEZyb206IFdheW5lIEN1dGxlciBbPEEg
SFJFRj0ibWFpbHRvOldheW5lLkN1dGxlckBtYXJjb25pLmNvbSI+bWFpbHRvOldheW5lLkN1dGxl
ckBtYXJjb25pLmNvbTwvQT5dPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFNlbnQ6IDI2
IEp1bmUgMjAwMSAxMzoxOTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBUbzogR29uemFs
byBDYW1hcmlsbG88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgQ2M6IHNpcEBsaXN0cy5i
ZWxsLWxhYnMuY29tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFN1YmplY3Q6IFtTSVBd
IFJlOiBSZSBNYXBwaW5nIG9mIElTVVAgb3ZlcmxhcCBzaWduYWxsaW5nIHRvIFNJUDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0
OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0O0hlbGxvLDwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0O1RoZXJl
IGhhdmUgYmVlbiBtaWxsb25zIG9mIG1haWxzIHNlbnQgdG8gdGhlIG1haWxpbnMgbGlzdCBpbiB0
aGUgcGFzdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ZGlzY3Vzc2luZyBleGFj
dGx5IHdoYXQgeW91IGFyZSBwcm9wb3NpbmcuIEJlc2lkZXMsIHRoaXMgaGFzIGJlZW48L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0O3ByZXNlbnRlZCBpbiBzZXZlcmFsIFdHIG1lZXRp
bmdzLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgJmd0O0ZlZWwgZnJlZSB0byBjaGVjayB0aGUgYXJjaGl2ZXMgdG8gZmluZCBtb3Jl
IGluZm9ybWF0aW9uIGFib3V0IHRoaXMuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBXaGlsc3QgaGVyZSBoYXMgYmVlbiBhIGdvb2Qg
ZGVhbCBvZiBkaXNjdXNzaW9uIG9uIHRoZSBnZW5lcmFsIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTI+Jmd0OyB0b3BpYyAob3ZlciBhdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBsZWFz
dCAzIHRocmVhZHMpLCB0aGUgdmFzdCBtYWpvcml0eTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+
Jmd0OyB3ZXJlIGNvbmNlcm5lZCB3aXRoIGluY2x1ZGluZyB0aGUgb3ZlcmxhcCBkaWdpdHMgaW4g
dmFyaW91cyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgU0lQIGhlYWRlcnMuPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFRoZXJlZm9yZSwgdGhlcmUgaGFzbid0IGJlZW4gYSBn
cmVhdCBkZWFsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IG9mIGRpc2N1c3Npb24gYWJv
dXQgbWFraW5nIHRoZSBTSVAgaGVhZGVycyBpbmRlcGVuZGVudCBvZiB0aGUgPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9Mj4mZ3Q7IG92ZXJsYXAgZGlnaXRzLiBJPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9Mj4mZ3Q7IGRvIHJlY2FsbCB5b3VyIHByZXNlbnRhdGlvbiBpbiB0aGUgbGFzdDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBXRyBtZWV0aW5nIGJ1dCB0aGF0IHN1Z2dlc3RlZCBzZW5k
aW5nIG11bHRpcGxlIElOVklURXMgYW5kIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAo
YXMgSSByZWNhbGwpIHRoZXJlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHdhcyBub3Ro
aW5nIHNhaWQgYWJvdXQgdGhlIG9wdGlvbiBvZjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0
OyBtYWtpbmcgdGhlIFNJUCBoZWFkZXJzIGluZGVwZW5kZW50IG9mIHRoZSBvdmVybGFwIGRpZ2l0
cy48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
Mj4mZ3Q7IFNvLCBmb3IgbGltaXRlZCBzY2VuYXJpb3MsIEkgZmFpbCB0byBzZWUgd2h5IGl0IGlz
IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB3cm9uZy9pbXByb3BlciB0byBtYWtlIHRo
ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBoZWFkZXJzIGluZGVwZW5kZW50IG9mIHRo
ZSBvdmVybGFwIGRpZ2l0cy4gU3VjaCBhbjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBh
cHByb2FjaCBpcyB3b3JrYWJsZSBhbmQmbmJzcDsgZG9lcyBub3QgcmVxdWlyZSBhbnkgY2hhbmdl
cyB0byB0aGUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFNJUCBwcm90b2NvbC4gU288
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgd2h5IGNhbid0IGl0IGJlIGFkZGVkIGFzIGFu
b3RoZXIgb3B0aW9uLCB3aXRoIGE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgc3VpdGFi
bGUgaGVhbHRoIHdhcm5pbmcgYWJvdXQgaXRzIGxpbWl0ZWQgYXBwbGljYWJpbGl0eT88L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFdh
eW5lLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBUaGlzIGxpc3QgaXMgZm9yIGNvbnRp
bnVpbmcgZGV2ZWxvcG1lbnQgb2YgdGhlIFNJUCBwcm90b2NvbC48L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yPiZndDsgVGhlIHNpcC1pbXBsZW1lbnRvcidzIGxpc3QgaXMgdGhlIHBsYWNlIHRvIGRp
c2N1c3MgaW1wbGVtZW50YXRpb24sPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGFuZCB0
byByZWNlaXZlIGFkdmljZSBvbiB1bmRlcnN0YW5kaW5nIGV4aXN0aW5nIHNpcC48L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yPiZndDsgVG8gc3Vic2NyaWJlIHRvIGl0LCBzZW5kIG1haWwgdG8gPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHNpcC1pbXBsZW1lbnRvcnMtcmVxdWVzdEBjcy5j
b2x1bWJpYS5lZHUgd2l0aCAmcXVvdDtzdWJzY3JpYmUmcXVvdDsgaW4gdGhlIGJvZHkuPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1M
Pg==

--0__=dLXlfmmJooJ8ZnJ77fiOEaobKnzJA2e3gAmAoylZg3gcBFOwO8F9fgT0--


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


From sip-admin@ietf.org  Wed Jun 27 05:23:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23673;
	Wed, 27 Jun 2001 05:23:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28763;
	Wed, 27 Jun 2001 05:11:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28734
	for ; Wed, 27 Jun 2001 05:11:19 -0400 (EDT)
Received: from firewall.ubiquity.ca (firewall.ubiquity.ca [209.167.187.162])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA15871
	for ; Wed, 27 Jun 2001 05:10:38 -0400 (EDT)
Received: from accesstree.ubiquity.ca by firewall.ubiquity.ca
          via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 27 Jun 2001 10:11:08 UT
Received: (private information removed)
Message-ID: <3B39A320.A8C0DE24@ubiquity.net>
From: James Undery 
To: Jonathan Rosenberg 
Cc: "'aki.niemi@nokia.com'" , sip@ietf.org
Subject: Re: [Sip] Request header integrity in HTTP Digest
Date: Wed, 27 Jun 2001 05:10:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> >
> > But I have to agree with James on the fact, that ultimatelly, the same
> > threats present with digest are still present with pnonce.
> > Hence, it doesn't
> > deliver the goods it promises, which is integrity of headers.
>
> I will back down on the statement that it provides header integrity,
because
> of the MITM attack that I agree is still possible.
>

Well now it'll be time to admit I also quite like this idea (and playing
Devils
Advocate), although I would remove the source-IP field (farms of stateless
proxies combined with IP spoofing make this of doubtful worth), add a
private
key, put a copy of N inside the hash to prevent tampering and use a
time-stamp
in a similar way to better control granularity. e.g.

nonce = H(private-key ":"  ":" N ":" time-stamp) "." N
"."
time-stamp

which would prevent replays at an arbitrarily fine level (rather than a
minute)
make the nonce unguessable with the private key, allow simple checking of
the
time-stamp before checking the hash and provide integrity for the time-stamp
and
N.

>
> However, it prevents against replay attacks which modify protected header
> fields. These attacks can also be prevented with one time nonces. I will
> agree that the approach cannot prevent any attacks that are prevented by
> one-time nonces in rfc2617. But as the draft points out, one time nonces
> require state in the server between the original request, and the new
> request with credentials. As a result of this, the server becomes amenable
> to DoS attacks since it stores state for unauthenticated requests. The
> proposed mechanism, which is well within the spirit of rfc2617, which
allows
> for creative nonces as Aki has pointed out, provides the same benefits as
> one time nonces without the cost of state.

I'd also be a bit careful making this DoS claim, the authentication state is
going to be minimal and large tags and Call-IDs could soon make up the
difference.

James Undery


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


From sip-admin@ietf.org  Wed Jun 27 07:04:12 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26864;
	Wed, 27 Jun 2001 07:04:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02443;
	Wed, 27 Jun 2001 06:53:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02358
	for ; Wed, 27 Jun 2001 06:53:05 -0400 (EDT)
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18870
	for ; Wed, 27 Jun 2001 06:52:24 -0400 (EDT)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 27 Jun 2001 03:52:33 -0700
Message-ID: 
From: "Fairlie-Cuninghame, Robert" 
To: "'Gonzalo Camarillo'" ,
        Jonathan Rosenberg 
Cc: sip@ietf.org
Subject: RE: [SIP] Killing hung media streams
Date: Wed, 27 Jun 2001 03:52:32 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FEF7.44434390"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FEF7.44434390
Content-Type: text/plain;
	charset="iso-8859-1"


The only problem here is if either
a)	UA does not send the BYE or if more specifically,
b)	a Record-Routed proxy sees the 481 and tears down the call. Further
Record-Routed proxies will then never see the BYE generated by the 481.

So now you need to mandate that a proxy MUST not consider a call torn down
because of a 481 to a re-INVITE - which puts us back at square one. It seems
to very strange (and risky) that one UA can clearly indicate that the call
has been torn down but the proxies MUST ignore this indication. This means
that all record-routing proxies in a call-leg (and UA's) must conform to
bis-04 to avoid zombie call-leg's in this situation! 

Perhaps something along the lines that a proxy MAY use a 481 inidication to
remove a call from a active call-state; however, call state must be retained
for at least 32 seconds so that BYE requests may be propagated to all
record-routed proxy.

Robert.

-----Original Message-----
From:	Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
Sent:	Tuesday, June 26, 2001 8:12 PM
To:	Jonathan Rosenberg
Cc:	'adam.roach@ericsson.com'; 'Michael Thomas'; John.Hearty@level3.com;
sip@ietf.org
Subject:	Re: [SIP] Killing hung media streams

Hello,

> So, this begs a related question, which Pauls email introduces. If we say
> that a 481 to the INVITE means the call is down, does that mean the UAC
> should issue a BYE, or just destroy the call state? Right now, bis-03 says
> it should consider the call down, and does not mandate that a BYE should
be
> sent (since, in any case, it will also result in a 481). The advantage of
> sending a BYE is for call-stateful boxes in the middle. It gives us the
nice
> property that a call is always terminated by a BYE, even if triggered as a
> result of some other event in the SIP signaling path. This reduces the
> number of cases that devices need to worry about.

With this addition we basically recover the nice feature of treating
unknown 4xx reponses as 400. SIP entities that do not understand 481
will be able to treat a 481 received as a 400. That is, 481 indicates
that the request failed (as any other 4xx response), but it does not
indicate that the session has been terminated. This will still be
indicated by a BYE.

Best regards,

Gonzalo



> 
> So, I would propose that text be added to bis-03 which further mandates
that
> a BYE be sent upon receiving a 481 to a mid-call request. Any objections?
> 
> Paul also wrote:
> > But there are some issues with the re-INVITE that I don't understand:
> >
> > If I believe the problem is with my end, and there is something
> > I can change (e.g. in my SDP) that would help solve the problem,
> > then of course I can offer that.
> >
> > But it seems like either I will believe the problem is with the
> > other end, or else I will have no idea where it is and have no
> > idea what kind of change might help. Suppose I have received ICMP
> > errors on my sends, and suspect the port I am sending to, or the
> > path to it, are down. When I send a reinvite, there is nothing
> > obvious for me to change in *my* SDP - I want the other end to
> > offer me something that will work better. So perhaps I send
> > unchanged SDP. When the other end receives this, it may have no
> > idea that anything is wrong. How does it decide that it should do
> > anything other than send unchanged SDP back?
> 
> Well, its the job of the user at the other end to know that there is a
> problem if one of its media streams has failed. How it knows this depends
on
> the device. In the case of a decomposed gateway, if the gateway fails,
> presumably the MGC can detect this, and therefore do something about it
when
> the re-INVITE arrives.
> 
> The interesting case is when the failure in the media stream is not due to
> either endpoint, but rather something in the network. In this case, a
> re-INVITE won't help, as it will change nothing (both sides offer the same
> SDP as before). In this case, you UA has to know to stop re-INVITing after
a
> while, if the re-INVITEs don't eventually solve the problem. I suspect
this
> will be a rare case, since if the media fails due to a network failure,
the
> signaling will probably fail as well.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list
> Sip@ietf.org
> http://www.ietf.org/mailman/listinfo/sip

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

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

------_=_NextPart_001_01C0FEF7.44434390
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [SIP] Killing hung media streams






The only problem here is if =
either


  1. UA does not send the BYE =
or if more specifically,
    2. 

  2. a Record-Routed proxy sees the 481 =
and tears down the call. Further Record-Routed proxies will then never =
see the BYE generated by the 481.
    3. 

    



So now you need to mandate that a =
proxy MUST not consider a call torn down because of a 481 to a =
re-INVITE - which puts us back at square one. It seems to very strange =
(and risky) that one UA can clearly indicate that the call has been =
torn down but the proxies MUST ignore =
this indication. This means that all =
record-routing proxies in a call-leg (and UA's) must conform to bis-04 =
to avoid zombie call-leg's in this situation! 



Perhaps something along the lines that =
a proxy MAY use a 481 inidication to remove a call from a active =
call-state; however, call state must be retained for at least 32 =
seconds so that BYE requests may be propagated to all record-routed =
proxy.



Robert.




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

From:   Gonzalo =
Camarillo [mailto:Gonzalo.Camaril=
lo@lmf.ericsson.se]

Sent:   Tuesday, June 26, 2001 8:12 PM

To:     Jonathan Rosenberg

Cc:     'adam.roach@ericsson.com'; 'Michael Thomas'; =
John.Hearty@level3.com; sip@ietf.org

Subject:       =
 Re: [SIP] Killing hung media =
streams




Hello,




> So, this begs a related question, =
which Pauls email introduces. If we say

> that a 481 to the INVITE means =
the call is down, does that mean the UAC

> should issue a BYE, or just =
destroy the call state? Right now, bis-03 says

> it should consider the call =
down, and does not mandate that a BYE should be

> sent (since, in any case, it =
will also result in a 481). The advantage of

> sending a BYE is for =
call-stateful boxes in the middle. It gives us the nice

> property that a call is always =
terminated by a BYE, even if triggered as a

> result of some other event in =
the SIP signaling path. This reduces the

> number of cases that devices =
need to worry about.




With this addition we basically =
recover the nice feature of treating

unknown 4xx reponses as 400. SIP =
entities that do not understand 481

will be able to treat a 481 received =
as a 400. That is, 481 indicates

that the request failed (as any other =
4xx response), but it does not

indicate that the session has been =
terminated. This will still be

indicated by a BYE.




Best regards,




Gonzalo








> 

> So, I would propose that text be =
added to bis-03 which further mandates that

> a BYE be sent upon receiving a =
481 to a mid-call request. Any objections?

> 

> Paul also wrote:

> > But there are some issues =
with the re-INVITE that I don't understand:

> >

> > If I believe the problem is =
with my end, and there is something

> > I can change (e.g. in my =
SDP) that would help solve the problem,

> > then of course I can offer =
that.

> >

> > But it seems like either I =
will believe the problem is with the

> > other end, or else I will =
have no idea where it is and have no

> > idea what kind of change =
might help. Suppose I have received ICMP

> > errors on my sends, and =
suspect the port I am sending to, or the

> > path to it, are down. When =
I send a reinvite, there is nothing

> > obvious for me to change in =
*my* SDP - I want the other end to

> > offer me something that =
will work better. So perhaps I send

> > unchanged SDP. When the =
other end receives this, it may have no

> > idea that anything is =
wrong. How does it decide that it should do

> > anything other than send =
unchanged SDP back?

> 

> Well, its the job of the user at =
the other end to know that there is a

> problem if one of its media =
streams has failed. How it knows this depends on

> the device. In the case of a =
decomposed gateway, if the gateway fails,

> presumably the MGC can detect =
this, and therefore do something about it when

> the re-INVITE arrives.

> 

> The interesting case is when the =
failure in the media stream is not due to

> either endpoint, but rather =
something in the network. In this case, a

> re-INVITE won't help, as it will =
change nothing (both sides offer the same

> SDP as before). In this case, =
you UA has to know to stop re-INVITing after a

> while, if the re-INVITEs don't =
eventually solve the problem. I suspect this

> will be a rare case, since if =
the media fails due to a network failure, the

> signaling will probably fail as =
well.

> 

> -Jonathan R.

> ---

> Jonathan D. Rosenberg, =
Ph.D.           &=
nbsp;    72 Eagle Rock Ave.

> Chief =
Scientist          &nb=
sp;           &nb=
sp;      First Floor

> =
dynamicsoft          &=
nbsp;           &=
nbsp;          East =
Hanover, NJ 07936

> =
jdrosen@dynamicsoft.com        &=
nbsp;            =
FAX:   (973) 952-5050

> http://www.jdrosen.net    &nbs=
p;           &nbs=
p;     PHONE: (973) 952-5000

> http://www.dynamicsoft.com

> 

> =
_______________________________________________

> Sip mailing list

> Sip@ietf.org

> http://www.ietf.org/mailman/listinfo/sip




-- 

Gonzalo =
Camarillo          &nb=
sp;         Phone :   =
+1 212 939 71 71

Columbia =
University          &n=
bsp;       Mobile:  +358 40 702 35 =
35

472 Computer Science =
Building        Fax   =
:  +358  9 299 30 52

1214 Amsterdam Ave., Mail Code =
0401  http://www.hut.fi/~gonzalo

New York, NY =
10027           &=
nbsp;       

USA         =
            =
         =
Gonzalo.Camarillo@ericsson.com




_______________________________________________

Sip mailing list  http://www.ietf.org/mailman/listinfo/sip

This list is for NEW development of =
the core SIP Protocol

Use sip-implementors@cs.columbia.edu =
for questions on current sip

Use sipping@ietf.org for new =
developments on the application of sip





------_=_NextPart_001_01C0FEF7.44434390--

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


From sip-admin@ietf.org  Wed Jun 27 07:09:50 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00577;
	Wed, 27 Jun 2001 07:09:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03165;
	Wed, 27 Jun 2001 07:03:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03134
	for ; Wed, 27 Jun 2001 07:03:56 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26222;
	Wed, 27 Jun 2001 07:03:16 -0400 (EDT)
Message-Id: <200106271103.HAA26222@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 27 Jun 2001 07:03:15 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-service-examples-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: SIP Service Examples
	Author(s)	: A. Johnston, R. Sparks, C. Cunningham, 
                          S. Donovan, K. Summers
	Filename	: draft-ietf-sip-service-examples-02.txt
	Pages		: 107
	Date		: 26-Jun-01
	
This informational document gives examples of SIP (Session Initiation
Protocol) services.  This covers most features offered in so-called
Centrex offerings from local exchange carriers and PBX (Private
Branch Exchange) features.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-service-examples-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-service-examples-02.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-service-examples-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-service-examples-02.txt

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

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

--OtherAccess--

--NextPart--



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


From sip-admin@ietf.org  Wed Jun 27 08:08:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07589;
	Wed, 27 Jun 2001 08:08:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04944;
	Wed, 27 Jun 2001 07:59:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04912
	for ; Wed, 27 Jun 2001 07:59:28 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01457
	for ; Wed, 27 Jun 2001 07:58:46 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5RBxNN03905;
	Wed, 27 Jun 2001 13:59:23 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.7])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5RBxM508791;
	Wed, 27 Jun 2001 14:59:22 +0300 (EET DST)
Message-ID: <3B39CA99.BEE9D133@lmf.ericsson.se>
Date: Wed, 27 Jun 2001 14:59:21 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" 
CC: "'Gonzalo Camarillo'" ,
        Jonathan Rosenberg , sip@ietf.org
Subject: Re: [SIP] Killing hung media streams
References: 
Content-Type: multipart/mixed;
 boundary="------------CE835B3186B32711C0B6E7E5"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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


Hi,

Some small comments.

First, one could argue that this has nothing to with SIP, since SIP is
signalling and media is another thing. For example, a client could have
some kind of internal mechanism to make sure that it doesn't have any
active media streams without a matching call state. However, my comments
are on SIP.

I don't think that a proxy should consider a call torn down if it
receives 481, and especially not then ASSUME that the UA does the same.
In this case one could argue that the proxy should generate BYE
transactions in both directions, to torn down the call at the UAs, and I
don't think we want to go into that discussion... One could also argue
that the UAS(!) should send a BYE after it has sent 481, and I don't
think we want that either...

I think the idea behind the session-timer is for the UA to make sure
that proxies don't loose call-state, by sending re-INVITEs, so why can't
the UAs then also tell the proxies that the call doesn't exist anymore
if 481 is received, by sending BYE?

However, like Gonzalo mentioned, it is not mandatory for a UA to
understand the specific 481 response code, so in any case I think it
could only be a RECOMMENDATION/SHOULD to send BYE.

One option is to simply have it as an implementation issue. Some clients
may then even have it as a configuration variable, depending on what the
user/network provider/whoever wants.

Another option is to add a Supported/Require option-tag (I use 'relBYE'
as an example...), to indicate the sending of BYE when 481 is received
as a FEATURE.

example:

UA1                   UA2

-----INVITE------------->	
     Supported: relBYE
<----200-----------------
     Require: relBYE

//UA1 is required by UA2 to send BYE if UA1 at any stage receives 481

..or..

-----INVITE------------->	
     Supported: relBYE
<----200-----------------
     Supported: relBYE

//Both UAs will now send BYE if any of them at any stage receive 481
     
..or..

-----INVITE------------->	
     Require: relBYE
<----200-----------------
     Supported: relBYE

//UA1 requires UA2 to send BYE if it at any stage receive 481

..or..

-----INVITE------------->	
     Supported: relBYE
     Require: relBYE
<----200-----------------
     Supported: relBYE

//UA2 is required to send BYE, and UA1 indicate that it will also send
BYE, if
//at any stage 481 is recieved


The use of the 32 seconds, mentioned by Robert, is also an option, but
again I don't think it shall be a MUST. Maybe it could also be a
feature, indicated by some Proxy-Require option-tag...


Comments?

Regards,

Christer Holmberg
Ericsson Finland



"Fairlie-Cuninghame, Robert" wrote:
> 
> The only problem here is if either
> 
>   a. UA does not send the BYE or if more specifically,
>   b. a Record-Routed proxy sees the 481 and tears down the call.
>      Further Record-Routed proxies will then never see the BYE
>      generated by the 481.
> 
> So now you need to mandate that a proxy MUST not consider a call torn
> down because of a 481 to a re-INVITE - which puts us back at square
> one. It seems to very strange (and risky) that one UA can clearly
> indicate that the call has been torn down but the proxies MUST ignore
> this indication. This means that all record-routing proxies in a
> call-leg (and UA's) must conform to bis-04 to avoid zombie call-leg's
> in this situation!
> 
> Perhaps something along the lines that a proxy MAY use a 481
> inidication to remove a call from a active call-state; however, call
> state must be retained for at least 32 seconds so that BYE requests
> may be propagated to all record-routed proxy.
> 
> Robert.
> 
> -----Original Message-----
> From:   Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent:   Tuesday, June 26, 2001 8:12 PM
> To:     Jonathan Rosenberg
> Cc:     'adam.roach@ericsson.com'; 'Michael Thomas';
> John.Hearty@level3.com; sip@ietf.org
> Subject:        Re: [SIP] Killing hung media streams
> 
> Hello,
> 
> > So, this begs a related question, which Pauls email introduces. If
> we say
> > that a 481 to the INVITE means the call is down, does that mean the
> UAC
> > should issue a BYE, or just destroy the call state? Right now,
> bis-03 says
> > it should consider the call down, and does not mandate that a BYE
> should be
> > sent (since, in any case, it will also result in a 481). The
> advantage of
> > sending a BYE is for call-stateful boxes in the middle. It gives us
> the nice
> > property that a call is always terminated by a BYE, even if
> triggered as a
> > result of some other event in the SIP signaling path. This reduces
> the
> > number of cases that devices need to worry about.
> 
> With this addition we basically recover the nice feature of treating
> unknown 4xx reponses as 400. SIP entities that do not understand 481
> will be able to treat a 481 received as a 400. That is, 481 indicates
> that the request failed (as any other 4xx response), but it does not
> indicate that the session has been terminated. This will still be
> indicated by a BYE.
> 
> Best regards,
> 
> Gonzalo
> 
> >
> > So, I would propose that text be added to bis-03 which further
> mandates that
> > a BYE be sent upon receiving a 481 to a mid-call request. Any
> objections?
> >
> > Paul also wrote:
> > > But there are some issues with the re-INVITE that I don't
> understand:
> > >
> > > If I believe the problem is with my end, and there is something
> > > I can change (e.g. in my SDP) that would help solve the problem,
> > > then of course I can offer that.
> > >
> > > But it seems like either I will believe the problem is with the
> > > other end, or else I will have no idea where it is and have no
> > > idea what kind of change might help. Suppose I have received ICMP
> > > errors on my sends, and suspect the port I am sending to, or the
> > > path to it, are down. When I send a reinvite, there is nothing
> > > obvious for me to change in *my* SDP - I want the other end to
> > > offer me something that will work better. So perhaps I send
> > > unchanged SDP. When the other end receives this, it may have no
> > > idea that anything is wrong. How does it decide that it should do
> > > anything other than send unchanged SDP back?
> >
> > Well, its the job of the user at the other end to know that there is
> a
> > problem if one of its media streams has failed. How it knows this
> depends on
> > the device. In the case of a decomposed gateway, if the gateway
> fails,
> > presumably the MGC can detect this, and therefore do something about
> it when
> > the re-INVITE arrives.
> >
> > The interesting case is when the failure in the media stream is not
> due to
> > either endpoint, but rather something in the network. In this case,
> a
> > re-INVITE won't help, as it will change nothing (both sides offer
> the same
> > SDP as before). In this case, you UA has to know to stop re-INVITing
> after a
> > while, if the re-INVITEs don't eventually solve the problem. I
> suspect this
> > will be a rare case, since if the media fails due to a network
> failure, the
> > signaling will probably fail as well.
> >
> > -Jonathan R.
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > Sip mailing list
> > Sip@ietf.org
> > http://www.ietf.org/mailman/listinfo/sip
> 
> --
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027
> USA                              Gonzalo.Camarillo@ericsson.com
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
--------------CE835B3186B32711C0B6E7E5
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------CE835B3186B32711C0B6E7E5--


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


From sip-admin@ietf.org  Wed Jun 27 10:30:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28577;
	Wed, 27 Jun 2001 10:30:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10001;
	Wed, 27 Jun 2001 10:10:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA09969
	for ; Wed, 27 Jun 2001 10:10:47 -0400 (EDT)
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23010
	for ; Wed, 27 Jun 2001 10:10:07 -0400 (EDT)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA08484; Wed, 27 Jun 2001 10:10:13 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AJM01143;
	Wed, 27 Jun 2001 10:10:11 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010627101027.00b0a818@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 27 Jun 2001 10:12:13 -0400
To: Christer Holmberg 
From: Michael Hammer 
Subject: Re: [Sip] RE: reason code in BYE/CANCEL (was
  [Sip-implementors] another  problem related to multiple call l egs at 
   UAC)
Cc: Jonathan Rosenberg ,
        "'Bob Penfield'" ,
        "'Barry Desborough'" ,
        "'Paul Kyzivat'" , sip@ietf.org,
        gonzalo.camarillo@lmf.ericsson.se
In-Reply-To: <3B39753C.CE406DBF@lmf.ericsson.se>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Comment below.

At 08:55 AM 6/27/2001 +0300, Christer Holmberg wrote:


>Hi,
>
>Some example of codes that maybe could be useful.
>
>
>403 Session-timer expired
>
>This would be used if the call is released when the session-timer
>expires.
>
>
>404 Another leg chosen
>
>This would be useful IF we allow CANCELs and pre-call-setup BYEs for
>specific call-legs (discussion on this in another thread...)
>
>
>405 Service not available
>
>This could be used for many purposes. One example could be some kind of
>calling card/pre-pay call service. When the caller runs out of money, or
>the call time limit is exceeded, the call could be terminated using this
>Reason.
>
>
>406 Client error
>
>This would be used if the client, for any internal reason, must
>terminate the call. Load balancing is one example where this could be
>used. Another example is if the call state somehow gets messed up in the
>client, and it deciedes to release the call.
>
>This Reason could also be used, for the same purpose, by proxies, or
>there could be a separate Reason value for those (407 Proxy error)
>
>A couple of issues, though:
>
>
>Issue 1: Use existing codes
>
>Before we start defining a new set of codes, I DO think that we should
>have a look at the existing response codes, and see if they (or part of
>them) can be used for the Reason header. Then, if we define new codes,
>they may also be used for responses.

One of the key values of the reason code is that it can be sent in forward 
requests, not just backward responses.


>Issue 2: ISUP-SIP
>
>I assume this COULD also affect the ISUP-SIP mapping, IF different
>Reason header values will produce different mapping. I guess Gonzalo can
>comment on this.
>
>
>Regards,
>
>Christer Holmberg
>Ericsson Finland
>
>
>
>
>
>Jonathan Rosenberg wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> > > Sent: Monday, June 25, 2001 5:04 PM
> > > To: Jonathan Rosenberg; 'Barry Desborough'; 'Paul Kyzivat'
> > > Cc: sip@ietf.org
> > > Subject: reason code in BYE/CANCEL (was [Sip-implementors] another
> > > problem related to multiple call l egs at UAC)
> > >
> > >
> > >
> > > Jonathan Rosenberg wrote:
> > > >
> > > >
> > > >  Moving from sip-implementors to sip since there are some
> > > open issues and
> > > > changes to bis in here.
> > > >
> > > >
> > >
> > > 
> > > > Barry Desborough wrote:
> > > >
> > > > > I also agree that encoded reasons should be added to BYEs and
> > > > > CANCELs such
> > > > > that a PSDN gateway can map them to and from Q.931 cause codes.
> > > >
> > > > I also like these BYE reasons. This has come up countless
> > > times. Its also
> > > > helpful in CANCEL, to know whether a call was cancelled
> > > because the caller
> > > > aborted, or because some other branch picked up (the former
> > > would generate
> > > a
> > > > missed call entry in a call log, whilst the other won't). I
> > > don't think
> > > > Warning is right, but some kind of header that conveys both a
> > > > machine-interpretable and human-interpretable value would be good.
> > > >
> > > How about a "Reason" request header (or is that already
> > > defined elswhere)
> > > that uses the same format as the Warning header?
> > >
> > >         Reason        =  "Reason" ":" 1#reason-value
> > >         reason-value  =  reason-code SP reason-agent SP reason-text
> > >         reason-code   =  3DIGIT
> > >         reason-agent  =  host [ ":" port ]
> > >                           ;  the name of the server adding
> > >                           ;  the Reason header, for use in
> > > tracing/debugging
> > >         reason-text   =  quoted-string
> > >
> > >
> > >
> >
> > Reason is not used. Seems reasonable for the header name.
> >
> > I'm not sure the reason-agent is needed.
> >
> > The trick is defining the codes. A few I can think of:
> >
> > 400 Caller hung up
> >
> >   this would be in a CANCEL if the UAC hangs up before an INVITE 
> generates a
> > final response, or in a BYE at any point later. Its the normal call
> > termination case.
> >
> > 401 INVITE succeeded elsewhere
> >
> >   this would be in a CANCEL generated because an INVITE generated a 2xx on
> > another branch.
> >
> > 402 media stream failure
> >
> >   this would be in a BYE that was sent because there was some failure 
> in the
> > media streams or something like that.
> >
> > other suggestions?
> >
> > -Jonathan R.
> >
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip


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


From sip-admin@ietf.org  Wed Jun 27 10:30:12 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28624;
	Wed, 27 Jun 2001 10:30:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10310;
	Wed, 27 Jun 2001 10:19:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10279
	for ; Wed, 27 Jun 2001 10:19:07 -0400 (EDT)
Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25219
	for ; Wed, 27 Jun 2001 10:18:26 -0400 (EDT)
From: John.Hearty@level3.com
Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id OAA21090
	for ; Wed, 27 Jun 2001 14:19:02 GMT
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id OAA29326
	for ; Wed, 27 Jun 2001 14:19:02 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 27 Jun 2001 08:19:01 -0600
Message-ID: <17052388D394D411803900508BDFFAF6013DCA08@n0214idc1.oss.level3.com>
To: sip@ietf.org
Date: Wed, 27 Jun 2001 08:18:59 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Maintaining transport between servers (was: Transport parm in Rec
 ord-Route)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org


 I had another thought on this prompting me to rename the thread.  The goal
is to use the same transport between two servers for subsequent
transactions.  Simply putting the transport in a record-route has an
undesirable side affect.  That route could be used by the hop on either side
of the server that added it.  In the original example, if UAS sent a
subsequent request it might try to do it over TLS when all that is needed
there is UDP.  We need some mechanism in SIP to communicate a desired
transport between two specific servers in the Route list that will work for
subsequent requests in either direction.

John



> We have encountered a problem with the requirement in 16.3 where
>Record-Route MUST NOT contain the transport parameter.  I realize this was
>designed to handle the possibility of requiring a UA that does not support
a
>particular transport to use said transport, resulting in a failure.
>However, this also causes problems when the proxy must use only one
>transport for all transactions.  Take for example a proxy (B) in a private
>network that has a TLS connection with a trusted peer proxy (A) on the open
>Internet.  The flow for an Invite might be something like:
>
>UAC -> proxy (A) -> proxy (B) -> UAS
>
> Now if both proxies are record-routed without the transport parm, the
>initial transaction could be setup on TLS OK based on proxy (A) routing
>decisions, but if a subsequent transaction such as BYE came from the UAC,
>proxy (A) would see a Route header with no transport parm, use it as the
>req-URI which, lacking a transport parm results in using default UDP (see
>reference below).  Since proxy (B) only trusts and listens for requests
over
>a TLS connection, the request fails.
>
>From section 2, descrition of URL parameters:
>
>UDP is to be assumed when no explicit transport parameter is included.
>
> Perhaps some new verbage is needed describing proxy behaviour and how to
>select the transport protocol when not specified, i.e. look for open TLS or
>TCP sockets to the destination first.  This still might not help if for
>example the transport was TCP and the socket timed out due to inactivity.
>There may be other ways around this problem I have not thought through yet.
>Comments?
>
>
>John Hearty
>Level3
>

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


From sip-admin@ietf.org  Wed Jun 27 10:44:38 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05518;
	Wed, 27 Jun 2001 10:44:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10718;
	Wed, 27 Jun 2001 10:29:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10691
	for ; Wed, 27 Jun 2001 10:29:45 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28113
	for ; Wed, 27 Jun 2001 10:29:04 -0400 (EDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5RETiN04878;
	Wed, 27 Jun 2001 16:29:44 +0200 (MEST)
Received: from lmf.ericsson.se (racom107086.am.ericsson.se [147.117.107.86])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA19020;
	Wed, 27 Jun 2001 16:30:14 +0200 (MET DST)
Message-ID: <3B39EFCA.CF209BA0@lmf.ericsson.se>
Date: Wed, 27 Jun 2001 17:38:02 +0300
From: Gonzalo Camarillo 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Christer Holmberg 
CC: Jonathan Rosenberg ,
        "'Bob Penfield'" ,
        "'Barry Desborough'" ,
        "'Paul Kyzivat'" , sip@ietf.org
Subject: Re: [Sip] RE: reason code in BYE/CANCEL (was [Sip-implementors] another 
 problem related to multiple call l egs at   UAC)
References:  <3B39753C.CE406DBF@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello Christer,

> Issue 1: Use existing codes
> 
> Before we start defining a new set of codes, I DO think that we should
> have a look at the existing response codes, and see if they (or part of
> them) can be used for the Reason header. Then, if we define new codes,
> they may also be used for responses.

I agree with this. Being able to use the same code in a response and in
a BYE would be very useful for 3pcc. 

> Issue 2: ISUP-SIP
> 
> I assume this COULD also affect the ISUP-SIP mapping, IF different
> Reason header values will produce different mapping. I guess Gonzalo can
> comment on this.

We will be sending the REL message (with the cause code) in the BYE's
body. I do not think we want to come up with a new mapping of cause
codes to BYE reasons. However, the mapping from cause values to status
codes is already done. We might want to use existing status codes for
BYEs' reasons (like in the previous point).

Best regards,

Gonzalo


> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> Jonathan Rosenberg wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> > > Sent: Monday, June 25, 2001 5:04 PM
> > > To: Jonathan Rosenberg; 'Barry Desborough'; 'Paul Kyzivat'
> > > Cc: sip@ietf.org
> > > Subject: reason code in BYE/CANCEL (was [Sip-implementors] another
> > > problem related to multiple call l egs at UAC)
> > >
> > >
> > >
> > > Jonathan Rosenberg wrote:
> > > >
> > > >
> > > >  Moving from sip-implementors to sip since there are some
> > > open issues and
> > > > changes to bis in here.
> > > >
> > > >
> > >
> > > 
> > > > Barry Desborough wrote:
> > > >
> > > > > I also agree that encoded reasons should be added to BYEs and
> > > > > CANCELs such
> > > > > that a PSDN gateway can map them to and from Q.931 cause codes.
> > > >
> > > > I also like these BYE reasons. This has come up countless
> > > times. Its also
> > > > helpful in CANCEL, to know whether a call was cancelled
> > > because the caller
> > > > aborted, or because some other branch picked up (the former
> > > would generate
> > > a
> > > > missed call entry in a call log, whilst the other won't). I
> > > don't think
> > > > Warning is right, but some kind of header that conveys both a
> > > > machine-interpretable and human-interpretable value would be good.
> > > >
> > > How about a "Reason" request header (or is that already
> > > defined elswhere)
> > > that uses the same format as the Warning header?
> > >
> > >         Reason        =  "Reason" ":" 1#reason-value
> > >         reason-value  =  reason-code SP reason-agent SP reason-text
> > >         reason-code   =  3DIGIT
> > >         reason-agent  =  host [ ":" port ]
> > >                           ;  the name of the server adding
> > >                           ;  the Reason header, for use in
> > > tracing/debugging
> > >         reason-text   =  quoted-string
> > >
> > >
> > >
> >
> > Reason is not used. Seems reasonable for the header name.
> >
> > I'm not sure the reason-agent is needed.
> >
> > The trick is defining the codes. A few I can think of:
> >
> > 400 Caller hung up
> >
> >   this would be in a CANCEL if the UAC hangs up before an INVITE generates a
> > final response, or in a BYE at any point later. Its the normal call
> > termination case.
> >
> > 401 INVITE succeeded elsewhere
> >
> >   this would be in a CANCEL generated because an INVITE generated a 2xx on
> > another branch.
> >
> > 402 media stream failure
> >
> >   this would be in a BYE that was sent because there was some failure in the
> > media streams or something like that.
> >
> > other suggestions?
> >
> > -Jonathan R.
> >
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

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


From sip-admin@ietf.org  Wed Jun 27 10:50:14 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09722;
	Wed, 27 Jun 2001 10:50:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11492;
	Wed, 27 Jun 2001 10:43:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11403
	for ; Wed, 27 Jun 2001 10:43:30 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04229
	for ; Wed, 27 Jun 2001 10:42:49 -0400 (EDT)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123])
	by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f5REhIM23913
	for ; Wed, 27 Jun 2001 09:43:18 -0500 (CDT)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f5REhIX25024
	for ; Wed, 27 Jun 2001 09:43:18 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Jun 27 09:43:18 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Wed, 27 Jun 2001 09:43:18 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'John.Hearty@Level3.com'" , sip@ietf.org
Subject: RE: [Sip] Maintaining transport between servers (was: Transport p
	arm in Rec ord-Route)
Date: Wed, 27 Jun 2001 09:43:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FF17.7F76B2B0"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FF17.7F76B2B0
Content-Type: text/plain;
	charset="ISO-8859-1"

I thought we agree the RR could be asymmetric. That is
the RR could be different in either direction to allow
for the types of variations that you are speaking of.

/sean

>-----Original Message-----
>From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com]
>Sent: Wednesday, June 27, 2001 9:19 AM
>To: sip@ietf.org
>Subject: [Sip] Maintaining transport between servers (was: Transport
>parm in Rec ord-Route)
>
>
>
> I had another thought on this prompting me to rename the 
>thread.  The goal
>is to use the same transport between two servers for subsequent
>transactions.  Simply putting the transport in a record-route has an
>undesirable side affect.  That route could be used by the hop 
>on either side
>of the server that added it.  In the original example, if UAS sent a
>subsequent request it might try to do it over TLS when all 
>that is needed
>there is UDP.  We need some mechanism in SIP to communicate a desired
>transport between two specific servers in the Route list that 
>will work for
>subsequent requests in either direction.
>
>John
>
>
>
>> We have encountered a problem with the requirement in 16.3 where
>>Record-Route MUST NOT contain the transport parameter.  I 
>realize this was
>>designed to handle the possibility of requiring a UA that 
>does not support
>a
>>particular transport to use said transport, resulting in a failure.
>>However, this also causes problems when the proxy must use only one
>>transport for all transactions.  Take for example a proxy (B) 
>in a private
>>network that has a TLS connection with a trusted peer proxy 
>(A) on the open
>>Internet.  The flow for an Invite might be something like:
>>
>>UAC -> proxy (A) -> proxy (B) -> UAS
>>
>> Now if both proxies are record-routed without the transport parm, the
>>initial transaction could be setup on TLS OK based on proxy 
>(A) routing
>>decisions, but if a subsequent transaction such as BYE came 
>from the UAC,
>>proxy (A) would see a Route header with no transport parm, 
>use it as the
>>req-URI which, lacking a transport parm results in using 
>default UDP (see
>>reference below).  Since proxy (B) only trusts and listens 
>for requests
>over
>>a TLS connection, the request fails.
>>
>>From section 2, descrition of URL parameters:
>>
>>UDP is to be assumed when no explicit transport parameter is included.
>>
>> Perhaps some new verbage is needed describing proxy 
>behaviour and how to
>>select the transport protocol when not specified, i.e. look 
>for open TLS or
>>TCP sockets to the destination first.  This still might not 
>help if for
>>example the transport was TCP and the socket timed out due to 
>inactivity.
>>There may be other ways around this problem I have not 
>thought through yet.
>>Comments?
>>
>>
>>John Hearty
>>Level3
>>
>
>_______________________________________________
>Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP 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_01C0FF17.7F76B2B0
Content-Type: text/html;
	charset="ISO-8859-1"






RE: [Sip] Maintaining transport between servers (was: Transport parm in Rec ord-Route)




I thought we agree the RR could be asymmetric. That is

the RR could be different in either direction to allow

for the types of variations that you are speaking of.




/sean




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

>From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com]

>Sent: Wednesday, June 27, 2001 9:19 AM

>To: sip@ietf.org

>Subject: [Sip] Maintaining transport between servers (was: Transport

>parm in Rec ord-Route)

>

>

>

> I had another thought on this prompting me to rename the 

>thread.  The goal

>is to use the same transport between two servers for subsequent

>transactions.  Simply putting the transport in a record-route has an

>undesirable side affect.  That route could be used by the hop 

>on either side

>of the server that added it.  In the original example, if UAS sent a

>subsequent request it might try to do it over TLS when all 

>that is needed

>there is UDP.  We need some mechanism in SIP to communicate a desired

>transport between two specific servers in the Route list that 

>will work for

>subsequent requests in either direction.

>

>John

>

>

>

>> We have encountered a problem with the requirement in 16.3 where

>>Record-Route MUST NOT contain the transport parameter.  I 

>realize this was

>>designed to handle the possibility of requiring a UA that 

>does not support

>a

>>particular transport to use said transport, resulting in a failure.

>>However, this also causes problems when the proxy must use only one

>>transport for all transactions.  Take for example a proxy (B) 

>in a private

>>network that has a TLS connection with a trusted peer proxy 

>(A) on the open

>>Internet.  The flow for an Invite might be something like:

>>

>>UAC -> proxy (A) -> proxy (B) -> UAS

>>

>> Now if both proxies are record-routed without the transport parm, the

>>initial transaction could be setup on TLS OK based on proxy 

>(A) routing

>>decisions, but if a subsequent transaction such as BYE came 

>from the UAC,

>>proxy (A) would see a Route header with no transport parm, 

>use it as the

>>req-URI which, lacking a transport parm results in using 

>default UDP (see

>>reference below).  Since proxy (B) only trusts and listens 

>for requests

>over

>>a TLS connection, the request fails.

>>

>>From section 2, descrition of URL parameters:

>>

>>UDP is to be assumed when no explicit transport parameter is included.

>>

>> Perhaps some new verbage is needed describing proxy 

>behaviour and how to

>>select the transport protocol when not specified, i.e. look 

>for open TLS or

>>TCP sockets to the destination first.  This still might not 

>help if for

>>example the transport was TCP and the socket timed out due to 

>inactivity.

>>There may be other ways around this problem I have not 

>thought through yet.

>>Comments?

>>

>>

>>John Hearty

>>Level3

>>

>

>_______________________________________________

>Sip mailing list  http://www.ietf.org/mailman/listinfo/sip

>This list is for NEW development of the core SIP 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_01C0FF17.7F76B2B0--

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


From sip-admin@ietf.org  Wed Jun 27 11:08:09 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17928;
	Wed, 27 Jun 2001 11:08:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11887;
	Wed, 27 Jun 2001 10:54:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11859
	for ; Wed, 27 Jun 2001 10:54:44 -0400 (EDT)
Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12020
	for ; Wed, 27 Jun 2001 10:53:58 -0400 (EDT)
Received: from iere.net.avaya.com (localhost [127.0.0.1])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5RErtM05290
	for ; Wed, 27 Jun 2001 10:53:55 -0400 (EDT)
Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5RErsr05261
	for ; Wed, 27 Jun 2001 10:53:54 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FF19.19D7E63E"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Date: Wed, 27 Jun 2001 08:54:43 -0600
Message-ID: 
Thread-Topic: [Sip] RE: [Sipping] Call and call-id
Thread-Index: AcD+8GBD0qTkeHHDR0WaKMe9ATsvZwAJr7xQ
From: "Zmolek, Andrew (Andrew)" 
To: "Chris Hogg" ,
        "Jonathan Rosenberg" ,
        "Mathieu, Marie-Noelle" ,
        
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C0FF19.19D7E63E
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

            zmolek@avaya.com
              +1 720 444 4001


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



Hi Jonathan,=20

Jonathan Rosenberg wrote:=20

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

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

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

Comments?=20


Regards,=20

Chris Hogg=20
Nortel Networks.=20


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




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


>> >same call-id in the 2 INVITE requests, is this allowed ?=20
>>=20
>> Well, the current spec would indicate that you shouldn't do this:=20
>>=20
>> >The callid MUST be a globally unique identifier and MUST NOT be
reused=20
for=20
>> >later calls.=20
>>=20
>> However, I recall some discussion at an IETF that people were using
the=20
same=20
>> call-id across different call legs as a local identifier to correlate

those=20
>> call legs. With unique From tags and From fields, there really
shouldn't=20
be=20
>> a problem, so I think its OK. However, if we are going to allow it,
the=20
spec=20
>> should reflect it. Comments?=20
>=20
>If that's the proper way to solve this problem, then let's put that in
the=20
>spec. But I'm not convinced that this alone will solve all cases,=20
especially=20
>when this correlated information needs to be presented by a call leg=20
attempting=20
>to join (as in the consultative transfer case).=20

Careful; I am not proposing that two call legs with the same Call-ID
convey=20
any semantics. Specifically, receiving an INVITE from A, while in a call

with B, where the call-id in the INVITE from A equals the call-id in the
leg=20
with B, does NOT imply that this is a consultative transfer. For that,
we=20
have Replaces, which lists the replaced leg explicitly.=20

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



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

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

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

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

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


------_=_NextPart_001_01C0FF19.19D7E63E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




RE: [Sip] RE: [Sipping] Call and call-id




I=20
think it would be good to clarify our terminology, particularly =
since we=20
sometimes forget SIP does not provide directly for a call with multiple =
active=20
call legs (i.e. B2BUA is needed to rationalize each individual SIP =
call=20
with the overall session). I propose we define "call" to =
mean the two=20
participants in any given transaction and "session" to be some =
collection of=20
calls associated within a given UA (note that "invited by a common =
source" is=20
not a complete description since some or all of the invites could have=20
originated outside the UA). 


 


This=20
thread brings out several reasons why Call-ID should not be used to =
define a=20
"session" of multiple "calls" as defined above. Mainly because of this, =
I'm=20
preparing an I-D to address this need through the use of header=20
extensions for cookies, which each UA can independently grant and =
accept in=20
order to correlate call legs and potentially provide additional context =
for a=20
given call. The alternative is vendor-specific headers and a walled =
garden=20
approach to many features available in conventional PBXes today, and I =
don't=20
think that's beneficial for SIP in the long run.


 




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

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


 


 


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




  
Hi Jonathan, 

  
Jonathan Rosenberg wrote: 

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

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

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

  
Comments? 


  
Regards, 

  
Chris Hogg 
Nortel =
Networks.=20
  


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




  
  
-----Original=20
  Message----- 
From: Zmolek, Andrew (Andrew) =
[mailto:zmolek@avaya.com] =

Sent: Tuesday, June 26, 2001 12:35 PM 
To:=20
  Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org =

Subject: RE: [Sip] RE: [Sipping] Call and call-id =



  
>> >same call-id in the 2 INVITE requests, =
is this=20
  allowed ? 
>> 
>>=20
  Well, the current spec would indicate that you shouldn't do this:=20
  
>> 
>> =
>The=20
  callid MUST be a globally unique identifier and MUST NOT be =
reused=20
  
for 
>> >later =
calls.=20
  
>> 
>> =
However, I=20
  recall some discussion at an IETF that people were using the =

same 
>> call-id across =
different call=20
  legs as a local identifier to correlate 
those=20
  
>> call legs. With unique From tags =
and From=20
  fields, there really shouldn't 
be =

>> a problem, so I think its OK. However, if we are =
going to=20
  allow it, the 
spec 
>>=20
  should reflect it. Comments? 
> =

>If that's the proper way to solve this problem, then =
let's put that=20
  in the 
>spec. But I'm not convinced that =
this alone=20
  will solve all cases, 
especially =

>when this correlated information needs to be presented by =
a call=20
  leg 
attempting 
>to join (as=20
  in the consultative transfer case). 

  
Careful; I am not proposing that two call legs with =
the same=20
  Call-ID convey 
any semantics. Specifically, =
receiving=20
  an INVITE from A, while in a call 
with B, =
where the=20
  call-id in the INVITE from A equals the call-id in the leg =

with B, does NOT imply that this is a consultative transfer. =
For that,=20
  we 
have Replaces, which lists the replaced =
leg=20
  explicitly. 

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



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

>it. 

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

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

  
-Jonathan R. 
--- =

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

  
_______________________________________________=20
  
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip =

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


------_=_NextPart_001_01C0FF19.19D7E63E--

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


From sip-admin@ietf.org  Wed Jun 27 11:10:05 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19163;
	Wed, 27 Jun 2001 11:10:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12522;
	Wed, 27 Jun 2001 11:02:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12488
	for ; Wed, 27 Jun 2001 11:02:20 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16108
	for ; Wed, 27 Jun 2001 11:01:39 -0400 (EDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5RF2JN25679;
	Wed, 27 Jun 2001 17:02:19 +0200 (MEST)
Received: from lmf.ericsson.se (racom107086.am.ericsson.se [147.117.107.86])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id RAA21210;
	Wed, 27 Jun 2001 17:02:50 +0200 (MET DST)
Message-ID: <3B39F76E.FB31D18D@lmf.ericsson.se>
Date: Wed, 27 Jun 2001 18:10:38 +0300
From: Gonzalo Camarillo 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" 
CC: Jonathan Rosenberg , sip@ietf.org
Subject: Re: [SIP] Killing hung media streams
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

> Perhaps something along the lines that a proxy MAY use a 481
> inidication to remove a call from a active call-state; however, call
> state must be retained for at least 32 seconds so that BYE requests
> may be propagated to all record-routed proxy.

If a proxy considers the call down when the 481 is received, it will
just have to route the BYE that will be received later as an
out-of-the-blue BYE. Since the BYE will have record-route, I do not
think this is a major problem.

Regards,

Gonzalo


> 
> Robert.
> 
> -----Original Message-----
> From:   Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent:   Tuesday, June 26, 2001 8:12 PM
> To:     Jonathan Rosenberg
> Cc:     'adam.roach@ericsson.com'; 'Michael Thomas';
> John.Hearty@level3.com; sip@ietf.org
> Subject:        Re: [SIP] Killing hung media streams
> 
> Hello,
> 
> > So, this begs a related question, which Pauls email introduces. If
> we say
> > that a 481 to the INVITE means the call is down, does that mean the
> UAC
> > should issue a BYE, or just destroy the call state? Right now,
> bis-03 says
> > it should consider the call down, and does not mandate that a BYE
> should be
> > sent (since, in any case, it will also result in a 481). The
> advantage of
> > sending a BYE is for call-stateful boxes in the middle. It gives us
> the nice
> > property that a call is always terminated by a BYE, even if
> triggered as a
> > result of some other event in the SIP signaling path. This reduces
> the
> > number of cases that devices need to worry about.
> 
> With this addition we basically recover the nice feature of treating
> unknown 4xx reponses as 400. SIP entities that do not understand 481
> will be able to treat a 481 received as a 400. That is, 481 indicates
> that the request failed (as any other 4xx response), but it does not
> indicate that the session has been terminated. This will still be
> indicated by a BYE.
> 
> Best regards,
> 
> Gonzalo
> 
> >
> > So, I would propose that text be added to bis-03 which further
> mandates that
> > a BYE be sent upon receiving a 481 to a mid-call request. Any
> objections?
> >
> > Paul also wrote:
> > > But there are some issues with the re-INVITE that I don't
> understand:
> > >
> > > If I believe the problem is with my end, and there is something
> > > I can change (e.g. in my SDP) that would help solve the problem,
> > > then of course I can offer that.
> > >
> > > But it seems like either I will believe the problem is with the
> > > other end, or else I will have no idea where it is and have no
> > > idea what kind of change might help. Suppose I have received ICMP
> > > errors on my sends, and suspect the port I am sending to, or the
> > > path to it, are down. When I send a reinvite, there is nothing
> > > obvious for me to change in *my* SDP - I want the other end to
> > > offer me something that will work better. So perhaps I send
> > > unchanged SDP. When the other end receives this, it may have no
> > > idea that anything is wrong. How does it decide that it should do
> > > anything other than send unchanged SDP back?
> >
> > Well, its the job of the user at the other end to know that there is
> a
> > problem if one of its media streams has failed. How it knows this
> depends on
> > the device. In the case of a decomposed gateway, if the gateway
> fails,
> > presumably the MGC can detect this, and therefore do something about
> it when
> > the re-INVITE arrives.
> >
> > The interesting case is when the failure in the media stream is not
> due to
> > either endpoint, but rather something in the network. In this case,
> a
> > re-INVITE won't help, as it will change nothing (both sides offer
> the same
> > SDP as before). In this case, you UA has to know to stop re-INVITing
> after a
> > while, if the re-INVITEs don't eventually solve the problem. I
> suspect this
> > will be a rare case, since if the media fails due to a network
> failure, the
> > signaling will probably fail as well.
> >
> > -Jonathan R.
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > Sip mailing list
> > Sip@ietf.org
> > http://www.ietf.org/mailman/listinfo/sip
> 
> --
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027
> USA                              Gonzalo.Camarillo@ericsson.com
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

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


From sip-admin@ietf.org  Wed Jun 27 11:31:04 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03138;
	Wed, 27 Jun 2001 11:31:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12465;
	Wed, 27 Jun 2001 11:01:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12434
	for ; Wed, 27 Jun 2001 11:01:06 -0400 (EDT)
Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15586
	for ; Wed, 27 Jun 2001 11:00:25 -0400 (EDT)
From: John.Hearty@Level3.com
Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id PAA06594;
	Wed, 27 Jun 2001 15:01:06 GMT
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id PAA09058;
	Wed, 27 Jun 2001 15:01:06 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 27 Jun 2001 09:01:05 -0600
Message-ID: <17052388D394D411803900508BDFFAF6013DCA0A@n0214idc1.oss.level3.com>
To: sean.olson@ericsson.com, sip@ietf.org
Subject: RE: [Sip] Maintaining transport between servers (was: Transport p
	 arm in Rec ord-Route)
Date: Wed, 27 Jun 2001 09:01:02 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

 Are you referring to the discussions involving a proxy being able to add
the RR looking a certain way in the request, and modify the RR in the
response to look different to the other side?  That would work to solve my
latest concern.  We still need to get past the verbage disallowing the
transport parm in the RR.
 
John
 

-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Wednesday, June 27, 2001 8:43 AM
To: Hearty, John; sip@ietf.org
Subject: RE: [Sip] Maintaining transport between servers (was: Transport p
arm in Rec ord-Route)



I thought we agree the RR could be asymmetric. That is 
the RR could be different in either direction to allow 
for the types of variations that you are speaking of. 

/sean 

>-----Original Message----- 
>From: John.Hearty@Level3.com [ mailto:John.Hearty@Level3.com
 ] 
>Sent: Wednesday, June 27, 2001 9:19 AM 
>To: sip@ietf.org 
>Subject: [Sip] Maintaining transport between servers (was: Transport 
>parm in Rec ord-Route) 
> 
> 
> 
> I had another thought on this prompting me to rename the 
>thread.  The goal 
>is to use the same transport between two servers for subsequent 
>transactions.  Simply putting the transport in a record-route has an 
>undesirable side affect.  That route could be used by the hop 
>on either side 
>of the server that added it.  In the original example, if UAS sent a 
>subsequent request it might try to do it over TLS when all 
>that is needed 
>there is UDP.  We need some mechanism in SIP to communicate a desired 
>transport between two specific servers in the Route list that 
>will work for 
>subsequent requests in either direction. 
> 
>John 
> 
> 
> 
>> We have encountered a problem with the requirement in 16.3 where 
>>Record-Route MUST NOT contain the transport parameter.  I 
>realize this was 
>>designed to handle the possibility of requiring a UA that 
>does not support 
>a 
>>particular transport to use said transport, resulting in a failure. 
>>However, this also causes problems when the proxy must use only one 
>>transport for all transactions.  Take for example a proxy (B) 
>in a private 
>>network that has a TLS connection with a trusted peer proxy 
>(A) on the open 
>>Internet.  The flow for an Invite might be something like: 
>> 
>>UAC -> proxy (A) -> proxy (B) -> UAS 
>> 
>> Now if both proxies are record-routed without the transport parm, the 
>>initial transaction could be setup on TLS OK based on proxy 
>(A) routing 
>>decisions, but if a subsequent transaction such as BYE came 
>from the UAC, 
>>proxy (A) would see a Route header with no transport parm, 
>use it as the 
>>req-URI which, lacking a transport parm results in using 
>default UDP (see 
>>reference below).  Since proxy (B) only trusts and listens 
>for requests 
>over 
>>a TLS connection, the request fails. 
>> 
>>From section 2, descrition of URL parameters: 
>> 
>>UDP is to be assumed when no explicit transport parameter is included. 
>> 
>> Perhaps some new verbage is needed describing proxy 
>behaviour and how to 
>>select the transport protocol when not specified, i.e. look 
>for open TLS or 
>>TCP sockets to the destination first.  This still might not 
>help if for 
>>example the transport was TCP and the socket timed out due to 
>inactivity. 
>>There may be other ways around this problem I have not 
>thought through yet. 
>>Comments? 
>> 
>> 
>>John Hearty 
>>Level3 
>> 
> 
>_______________________________________________ 
>Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
  
>This list is for NEW development of the core SIP Protocol 
>Use sip-implementors@cs.columbia.edu for questions on current sip 
>Use sipping@ietf.org for new developments on the application of sip 
> 


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


From sip-admin@ietf.org  Wed Jun 27 11:54:42 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19108;
	Wed, 27 Jun 2001 11:54:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14530;
	Wed, 27 Jun 2001 11:42:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14443
	for ; Wed, 27 Jun 2001 11:41:56 -0400 (EDT)
Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09681
	for ; Wed, 27 Jun 2001 11:41:14 -0400 (EDT)
Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id PAA23885;
	Wed, 27 Jun 2001 15:41:24 GMT
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 27 Jun 2001 15:41:23 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 27 Jun 2001 08:41:21 -0700
Message-ID: <4148FEAAD879D311AC5700A0C969E89006E18C19@orsmsx35.jf.intel.com>
From: "Gross, Gerhard" 
To: "'Jonathan Rosenberg'" ,
        "Gross, Gerhard"
	 ,
        "'bidulock@openss7.org'"
	 
Cc: "'Rosen, Brian'" ,
        "'Jiri Kuthan'"
	 ,
        Ashhar Farhan ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	 er
Date: Wed, 27 Jun 2001 08:40:17 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

OK, I wasn't clear. The thread has _recently_ focused on recording
session times. Previous msgs in this thread covered other things,
such as:

[Jonathan Rosenberg wrote]
> Its very likely that more complex services will require usage information
> from elements beyond just the gateways (although call duration is only
> reliably obtained from gateways, as people have observed). But, my
> observation is that this is why billing mediation companies exist; to
> collect information from multiple elements, and aggregate them together to
> provide a coherent view of the service being offered.

and

[David Schwartz wrote]
> I for one would not want anyone getting to my gateway (even to be
rejected)
> who is not authenticated. By authentication I mean "Who are you" and not
"Do
> you have enough money to make this call". So instead I put up an
> authenticating proxy at the border of my network to filter out those that
I
> shouldn't be speaking with.


It is these items I address with the PEP-PDP usage scenario. For
example, another service that requires usage info from elements
that supply it is QoS. As mentioned in other drafts, the
AAA/policy server may act as a PDP for
devices that provide QoS, as well as acting as a PDP for SIP
usage (local policy management). If the PDP is made a trusted
entity in a domain through some neutral party trust relationship
(billing mediation company, clearinghouse), it can be one focal point
of some session info collection before subsequent aggregation at the
clearinghouse. It is likely not the only necessary focal point,
just one of them. Session times coming from a gateway type device
may have to go to another focal point.

Service providers will likely want to provide their own accounting
services for internal bookeeping/auditing. If the gateway is owned by
a different entity, and will charge the service provider for its
usage, the service provider will want to double check its own
records against those claimed by the entity owning the gateway.
For this reason, collecting session timing information independent
of the gateway can be useful, even if they are not completely accurate.

To address the issue raised by David Schwartz above, the AAA/pol svr
PDP can act as an authentication/authorization (A1 and A2) proxy
for SIP. If a call must go through an internally owned gateway,
the provider may configure the PDP to require strict A1 and A2
before media is transmitted.

[Gerhard Gross wrote]

> > A solution to *ONE PIECE* of the AAA problem discussed
> > in this thread is addressed by slapping a PEP (policy
> > enforcement point) layer on top of the SIP proxy
> > and using a AAA/policy server in the domain as
> > the PDP (policy decision point). The COPS extension
> > for SIP and usage instructions are specified in
> > http://www.ietf.org/internet-drafts/draft-gross-cops-sip-01.txt.
> 

[Jonathan Rosenberg wrote]

> Adding a layer of AAA does not help at all with the problems 
> in this thread.
> Those problems have to do with a proxy not having the same 
> information on
> call state as a gateway that actually provides service. Since 
> the PDP knows
> what the proxy knows, if the proxy can't know, how can the 
> PDP? It can't.
> 
> -Jonathan R.


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


From sip-admin@ietf.org  Wed Jun 27 12:05:58 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26802;
	Wed, 27 Jun 2001 12:05:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15288;
	Wed, 27 Jun 2001 11:58:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15257
	for ; Wed, 27 Jun 2001 11:58:56 -0400 (EDT)
Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21576
	for ; Wed, 27 Jun 2001 11:58:14 -0400 (EDT)
Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id PAA26739;
	Wed, 27 Jun 2001 15:58:31 GMT
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 27 Jun 2001 15:58:31 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id ; Wed, 27 Jun 2001 08:58:28 -0700
Message-ID: <4148FEAAD879D311AC5700A0C969E89006E18C1A@orsmsx35.jf.intel.com>
From: "Gross, Gerhard" 
To: "'Michael Thomas'" ,
        "Gross, Gerhard"
	 
Cc: "'bidulock@openss7.org'" ,
        Jonathan Rosenberg
	 ,
        "'Rosen, Brian'" ,
        "'Jiri Kuthan'" ,
        Ashhar Farhan
	 ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv
	 er
Date: Wed, 27 Jun 2001 08:52:32 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Again, my comments weren't specifically directed at solving
the problem of recording absolute session times.

Gery

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Tuesday, June 26, 2001 8:21 AM
> To: Gross, Gerhard
> Cc: 'bidulock@openss7.org'; Jonathan Rosenberg; 'Rosen, Brian'; 'Jiri
> Kuthan'; Ashhar Farhan; 'sip@ietf.org'
> Subject: RE: [SIP] Authentication and billing through proxy/re-direct
> serv er
> 
> 
> 
> As Jonathan points out, this is trivially defrauded.
> 
> The rule is simple: if you don't see the begin/end
> of the actual media stream (either directly or
> through some router that controls, say, QoS
> resources), or whatever other kind of session you
> might be basing session duration based billing on,
> then you are just whistling in the dark. Moving
> the call statefulness to a PDP only obfuscates
> which box got defrauded.
> 
> 	  Mike
> 
> Gross, Gerhard writes:
>  > A solution to *ONE PIECE* of the AAA problem discussed
>  > in this thread is addressed by slapping a PEP (policy
>  > enforcement point) layer on top of the SIP proxy
>  > and using a AAA/policy server in the domain as
>  > the PDP (policy decision point). The COPS extension
>  > for SIP and usage instructions are specified in
>  > http://www.ietf.org/internet-drafts/draft-gross-cops-sip-01.txt.
>  > 
>  > The PDP is made aware of INVITES, responses, ACKs,
>  > BYEs, etc. through the PEP. So the PDP can tabulate
>  > call event and timing statistics. These can be used
>  > for whatever accounting (and subsequent charging and
>  > billing) models that happen to be deployed. The
>  > AAA/policy server is owned and maintained by the
>  > service provider and is therefore protected and trusted.
>  > 
>  > Call statefulness is handled by COPS and the PDP, not
>  > by the SIP proxy. The PDP (AAA server) may interact
>  > with a clearing house (broker, billing mediation company,
>  > etc.) for inter-domain AAA purposes as people see fit.
>  > As far as I know, there is no reason this can not be real
>  > time so that "real-time billing services" can be used.
>  > 
>  > The additional benefit of providing local policy management
>  > of SIP usage is also there.
>  > 
>  > This does not directly address the issue of byte counts
>  > per session in case billing were dependent on that.
>  > Having the UA deliver CDRs when the call is over seems
>  > like asking for fraud since the UA is generally not
>  > owned by the service provider. How can it be trusted
>  > to report accurate CDRs?
>  > 
>  > As others have said, the burden of collecting
>  > other call/session statistics (e.g. byte count)
>  > should fall on the entity providing the service
>  > who wants to get paid for it. That entity may,
>  > for example, deploy some monitoring module at
>  > its egress points.
>  > 
>  > 
>  > _______________________________________________
>  > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
>  > This list is for NEW development of the core SIP Protocol
>  > Use sip-implementors@cs.columbia.edu for questions on current sip
>  > Use sipping@ietf.org for new developments on the application of sip
> 


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


From sip-admin@ietf.org  Wed Jun 27 13:08:47 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24594;
	Wed, 27 Jun 2001 13:08:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19002;
	Wed, 27 Jun 2001 13:00:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18954
	for ; Wed, 27 Jun 2001 13:00:29 -0400 (EDT)
Received: from cmail.mantraonline.com (cmail.mantraonline.com [202.56.230.27])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24253
	for ; Wed, 27 Jun 2001 12:59:45 -0400 (EDT)
Received: from mtv01ex01.mindtree.com ([202.56.254.10]) by
          cmail.mantraonline.com (Netscape Messaging Server 4.15) with
          ESMTP id GFLLU200.E1E; Wed, 27 Jun 2001 22:28:50 +0530 
content-class: urn:content-classes:message
Subject: RE: [Sip] Clarification needed on CANCEL request
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 27 Jun 2001 22:31:21 +0530
Message-ID: <2330401A6FE03445ADA682F5EBB7502D013519C2@mtv01ex01.mindtree.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Thread-Topic: [Sip] Clarification needed on CANCEL request
Thread-Index: AcD7ZcfSFsy5TpzETuWtbU/HR1ds2ADxNmhQ
From: "Mayank Sharma" 
To: "Swaroop Kulkarni" , 
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA18973
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

As pointed out earlier it has to wait for BYE,

> If it has to wait for a BYE, what is the response to the CANCEL
> request??

send a Call Leg/Transaction Does Not Exist response 

Regards,
Mayank Sharma
Mindtree Consulting Pvt. Ltd.

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


From sip-admin@ietf.org  Wed Jun 27 13:12:54 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24857;
	Wed, 27 Jun 2001 13:12:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18616;
	Wed, 27 Jun 2001 12:57:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18589
	for ; Wed, 27 Jun 2001 12:57:08 -0400 (EDT)
Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24097
	for ; Wed, 27 Jun 2001 12:56:26 -0400 (EDT)
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17675
	for ; Wed, 27 Jun 2001 12:56:12 -0400 (EDT)
Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17665
	for ; Wed, 27 Jun 2001 12:56:11 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FF2A.33C208FC"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Date: Wed, 27 Jun 2001 10:57:08 -0600
Message-ID: 
Thread-Topic: [Sip] RE: [Sipping] Call and call-id
Thread-Index: AcD/HMYrBx2f4H/WQsKNwz6I9PAORgAC9F5Q
From: "Zmolek, Andrew (Andrew)" 
To: "Sean Olson (EUS)" ,
        "Chris Hogg" ,
        "Jonathan Rosenberg" ,
        "Mathieu, Marie-Noelle" ,
        
Cc: "Boyle, Frank J (Duffy)" ,
        "Freundlich, Glen G (Glen)" 
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C0FF2A.33C208FC
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Does DCS state only operate in one direction (ie.only from the SIP
transaction initiator)? If so, it would need to be extended to provide
equivalent information when two endpoints have hundreds or thousands of
individual call legs in hundreds of sessions and either end might
initiate any given SIP transaction.=20
=20
Also, what are the rules for passing DCS state with respect in the REFER
case?
=20
If DCS state is extensible to provide an equivalent session identifier
at both ends of any given call, then I agree that there isn't any need
for bi-directional cookies to be grantable and remittable by either end.
But given the current draft's focus on proxies and what appears to be a
unidirectional call state, I'm not sure that it's complete enough to
solve the whole problem. Please correct me if I've missed something...
=20
--Andy

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


Have you considered the DCS State: draft for this mechanism?
See=20
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt
=20
=20
IMHO, I don't see a need for such a use of a Cookie. Correlating
messages to calls is not that difficult. The key thing to note, as you=20
have, is that Call-ID is not necessarily useful for tying multiple call
legs together.=20
=20
/sean

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


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

            zmolek@avaya.com
              +1 720 444 4001


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



Hi Jonathan,=20

Jonathan Rosenberg wrote:=20

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

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

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

Comments?=20


Regards,=20

Chris Hogg=20
Nortel Networks.=20


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




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


>> >same call-id in the 2 INVITE requests, is this allowed ?=20
>>=20
>> Well, the current spec would indicate that you shouldn't do this:=20
>>=20
>> >The callid MUST be a globally unique identifier and MUST NOT be
reused=20
for=20
>> >later calls.=20
>>=20
>> However, I recall some discussion at an IETF that people were using
the=20
same=20
>> call-id across different call legs as a local identifier to correlate

those=20
>> call legs. With unique From tags and From fields, there really
shouldn't=20
be=20
>> a problem, so I think its OK. However, if we are going to allow it,
the=20
spec=20
>> should reflect it. Comments?=20
>=20
>If that's the proper way to solve this problem, then let's put that in
the=20
>spec. But I'm not convinced that this alone will solve all cases,=20
especially=20
>when this correlated information needs to be presented by a call leg=20
attempting=20
>to join (as in the consultative transfer case).=20

Careful; I am not proposing that two call legs with the same Call-ID
convey=20
any semantics. Specifically, receiving an INVITE from A, while in a call

with B, where the call-id in the INVITE from A equals the call-id in the
leg=20
with B, does NOT imply that this is a consultative transfer. For that,
we=20
have Replaces, which lists the replaced leg explicitly.=20

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



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

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

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

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

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


------_=_NextPart_001_01C0FF2A.33C208FC
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




RE: [Sip] RE: [Sipping] Call and call-id




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

transaction. 


 


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


 


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


 


--Andy



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


  

  
Have=20
  you considered the DCS State: draft for this =
mechanism?

  
See=20
  

  
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt

  
 

  
IMHO, I =
don't see a=20
  need for such a use of a Cookie. =
Correlating

  
messages =
to calls is=20
  not that difficult. The key thing to note, as you =


  
have, is =
that Call-ID=20
  is not necessarily useful for tying multiple =
call

  
legs =
together.=20
  

  
 

  
/sean

  

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


    
I=20
    think it would be good to clarify our terminology, particularly=20
    since we sometimes forget SIP does not provide directly for a =
call with=20
    multiple active call legs (i.e. B2BUA is needed to rationalize =
each=20
    individual SIP call with the overall session). I propose=20
    we define "call" to mean the two =
participants in any=20
    given transaction and "session" to be some collection of calls =
associated=20
    within a given UA (note that "invited by a common source" is not a =
complete=20
    description since some or all of the invites could have originated =
outside=20
    the UA). 

    
 

    
This thread brings out several reasons =
why Call-ID=20
    should not be used to define a "session" of multiple "calls" as =
defined=20
    above. Mainly because of this, I'm preparing an I-D to address this =
need=20
    through the use of header extensions for cookies, which each UA =
can=20
    independently grant and accept in order to correlate call legs and=20
    potentially provide additional context for a given call. The =
alternative is=20
    vendor-specific headers and a walled garden approach to many =
features=20
    available in conventional PBXes today, and I don't think that's =
beneficial=20
    for SIP in the long run.

    
 

    

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

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

    
 

    
 

    
 -----Original=20
    Message-----
From: Chris Hogg=20
    [mailto:chogg@nortelnetworks.com]
Sent: Wednesday, June =
27, 2001=20
    4:03 AM
To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew); =

    Mathieu, Marie-Noelle; sip@ietf.org
Subject: RE: [Sip] RE: =

    [Sipping] Call and call-id


    

      
Hi Jonathan, 

      
Jonathan Rosenberg wrote: 

      
>Careful; I am not proposing that two call =
legs with=20
      the same Call-ID convey 
>any =
semantics.=20
      Specifically, receiving an INVITE from A, while in a call =

>with B, where the call-id in the INVITE from A equals =
the=20
      call-id in the leg 
>with B, does NOT =
imply that=20
      this is a consultative transfer. For that, we 
>have Replaces, which lists the replaced leg =
explicitly.=20
      

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

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

      
Comments? 


      
Regards, 

      
Chris Hogg 
Nortel =
Networks.=20
      


      
-----Original Message----- 
From:=20
      Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20
      
Sent: 26 June 2001 22:51 
To:=20
      'Zmolek, Andrew (Andrew)'; Jonathan Rosenberg; Mathieu, =

Marie-Noelle; sip@ietf.org 
Subject: RE:=20
      [Sip] RE: [Sipping] Call and call-id 




      
  
-----Original=20
      Message----- 
From: Zmolek, Andrew =
(Andrew) [mailto:zmolek@avaya.com]=20
      
Sent: Tuesday, June 26, 2001 12:35 PM =

To: Jonathan Rosenberg; Mathieu, Marie-Noelle; =
sip@ietf.org=20
      
Subject: RE: [Sip] RE: [Sipping] Call and =
call-id=20
      


      
>> >same call-id in the 2 INVITE =
requests, is=20
      this allowed ? 
>> 
>> Well, the current spec would indicate that you =
shouldn't=20
      do this: 
>> 
>>=20
      >The callid MUST be a globally unique identifier and MUST NOT =
be=20
      reused 
for 
>>=20
      >later calls. 
>> =

>> However, I recall some discussion at an IETF =
that people=20
      were using the 
same 
>> call-id across different call legs as a local =
identifier=20
      to correlate 
those 
>> call legs. With unique From tags and From =
fields, there=20
      really shouldn't 
be 
>> a problem, so I think its OK. However, if we are =
going to=20
      allow it, the 
spec 
>> should reflect it. Comments? 
> 
>If that's the proper =
way to solve=20
      this problem, then let's put that in the 
>spec.=20
      But I'm not convinced that this alone will solve all cases, =

      
especially 
>when =
this=20
      correlated information needs to be presented by a call leg=20
      
attempting 
>to =
join (as in the=20
      consultative transfer case). 

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

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



      
> It only seems to work when the =

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

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

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

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

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


------_=_NextPart_001_01C0FF2A.33C208FC--

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


From sip-admin@ietf.org  Wed Jun 27 13:12:57 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24855;
	Wed, 27 Jun 2001 13:12:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15147;
	Wed, 27 Jun 2001 11:56:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15116
	for ; Wed, 27 Jun 2001 11:56:40 -0400 (EDT)
Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19958
	for ; Wed, 27 Jun 2001 11:55:54 -0400 (EDT)
Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f5RFJVB18639
	for ; Wed, 27 Jun 2001 10:19:31 -0500 (CDT)
Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f5RFJQX16589
	for ; Wed, 27 Jun 2001 10:19:26 -0500 (CDT)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jun 27 10:19:01 2001 -0500
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Wed, 27 Jun 2001 10:19:01 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Zmolek, Andrew (Andrew)'" ,
        Chris Hogg
	 ,
        Jonathan Rosenberg ,
        "Mathieu, Marie-Noelle" ,
        sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Date: Wed, 27 Jun 2001 10:18:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FF1C.7D6593B0"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FF1C.7D6593B0
Content-Type: text/plain;
	charset="ISO-8859-1"

Have you considered the DCS State: draft for this mechanism?
See 
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt  
 
IMHO, I don't see a need for such a use of a Cookie. Correlating
messages to calls is not that difficult. The key thing to note, as you 
have, is that Call-ID is not necessarily useful for tying multiple call
legs together. 
 
/sean

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


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

            zmolek@avaya.com
              +1 720 444 4001


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



Hi Jonathan, 

Jonathan Rosenberg wrote: 

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

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

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

Comments? 


Regards, 

Chris Hogg 
Nortel Networks. 


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




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


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

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

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



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

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

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

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

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


------_=_NextPart_001_01C0FF1C.7D6593B0
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable




RE: [Sip] RE: [Sipping] Call and call-id






Have=20
you considered the DCS State: draft for this =
mechanism?


See=20



http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt=



 


IMHO, I don't see a need for such a use of a =
Cookie.=20
Correlating


messages to calls is not that difficult. The =
key thing=20
to note, as you 


have, is that Call-ID is not necessarily =
useful for=20
tying multiple call


legs together. 


 


/sean



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


  
I=20
  think it would be good to clarify our terminology, particularly =
since we=20
  sometimes forget SIP does not provide directly for a call with =
multiple active=20
  call legs (i.e. B2BUA is needed to rationalize each individual =
SIP call=20
  with the overall session). I propose we define =
"call" to mean the=20
  two participants in any given transaction and "session" to be some =
collection=20
  of calls associated within a given UA (note that "invited by a common =
source"=20
  is not a complete description since some or all of the invites could =
have=20
  originated outside the UA). 

  
 

  
This=20
  thread brings out several reasons why Call-ID should not be used to =
define a=20
  "session" of multiple "calls" as defined above. Mainly because of =
this, I'm=20
  preparing an I-D to address this need through the use of header=20
  extensions for cookies, which each UA can independently grant =
and accept=20
  in order to correlate call legs and potentially provide additional =
context for=20
  a given call. The alternative is vendor-specific headers and a walled =
garden=20
  approach to many features available in conventional PBXes today, and =
I don't=20
  think that's beneficial for SIP in the long run.

  
 

  

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

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

  
 

  
 

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


  

    
Hi Jonathan, 

    
Jonathan Rosenberg wrote: 

    
>Careful; I am not proposing that two call =
legs with the=20
    same Call-ID convey 
>any semantics. =
Specifically,=20
    receiving an INVITE from A, while in a call 
>with=20
    B, where the call-id in the INVITE from A equals the call-id in the =

    leg 
>with B, does NOT imply that this =
is a=20
    consultative transfer. For that, we 
>have=20
    Replaces, which lists the replaced leg explicitly. 

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

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

    
Comments? 


    
Regards, 

    
Chris Hogg 
Nortel =
Networks.=20
    


    
-----Original Message----- 
From:=20
    Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20
    
Sent: 26 June 2001 22:51 
To:=20
    'Zmolek, Andrew (Andrew)'; Jonathan Rosenberg; Mathieu, =

Marie-Noelle; sip@ietf.org 
Subject: RE: [Sip]=20
    RE: [Sipping] Call and call-id 




    
  
-----Original=20
    Message----- 
From: Zmolek, Andrew =
(Andrew) [mailto:zmolek@avaya.com] =

Sent: Tuesday, June 26, 2001 12:35 PM 
To:=20
    Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org =

Subject: RE: [Sip] RE: [Sipping] Call and call-id =



    
>> >same call-id in the 2 INVITE =
requests, is this=20
    allowed ? 
>> 
>>=20
    Well, the current spec would indicate that you shouldn't do this:=20
    
>> 
>> >The=20
    callid MUST be a globally unique identifier and MUST NOT be =
reused=20
    
for 
>> >later =
calls.=20
    
>> 
>> However, I=20
    recall some discussion at an IETF that people were using the =

    
same 
>> call-id =
across=20
    different call legs as a local identifier to correlate =

those 
>> call legs. With =
unique From=20
    tags and From fields, there really shouldn't 
be=20
    
>> a problem, so I think its OK. =
However, if=20
    we are going to allow it, the 
spec =

>> should reflect it. Comments? 
> 
>If that's the proper =
way to solve=20
    this problem, then let's put that in the 
>spec.=20
    But I'm not convinced that this alone will solve all cases, =

especially 
>when this =
correlated=20
    information needs to be presented by a call leg 
attempting 
>to join (as in =
the=20
    consultative transfer case). 

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

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



    
> It only seems to work when the =

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

    
http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-s=
ip-replaces-00.txt=20
    

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

    
-Jonathan R. 
--- =

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

    
_______________________________________________=20
    
Sip mailing list  http://www.ietf.org/ma=
ilman/listinfo/sip=20
    
This list is for NEW development of the core SIP =

    Protocol 
Use =
sip-implementors@cs.columbia.edu for=20
    questions on current sip 
Use =
sipping@ietf.org for=20
    new developments on the application of sip=20



------_=_NextPart_001_01C0FF1C.7D6593B0--

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


From sip-admin@ietf.org  Wed Jun 27 14:30:32 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08038;
	Wed, 27 Jun 2001 14:30:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21363;
	Wed, 27 Jun 2001 13:59:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21274
	for ; Wed, 27 Jun 2001 13:58:56 -0400 (EDT)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19543
	for ; Wed, 27 Jun 2001 13:58:16 -0400 (EDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id EBEE04DDE6; Wed, 27 Jun 2001 13:58:55 -0400 (EDT)
Received: from fish.research.att.com (fish.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA16207;
	Wed, 27 Jun 2001 13:58:20 -0400 (EDT)
From: William Marshall 
Received: (from wtm@localhost)
	by fish.research.att.com (SGI-8.9.3/8.8.5) id NAA97040;
	Wed, 27 Jun 2001 13:59:04 -0400 (EDT)
Date: Wed, 27 Jun 2001 13:59:04 -0400 (EDT)
Message-Id: <200106271759.NAA97040@fish.research.att.com>
Subject: RE: [Sip] RE: [Sipping] Call and call-id
To: zmolek@avaya.ccom
Cc: sean.olson@ericsson.com, chogg@nortelnetworks.com, jdrosen@dynamicsoft.com,
        Marie-Noelle.Mathieu@compaq.com, duffy@drmail.dr.avaya.com,
        ggf@drmail.dr.avaya.com, sip@ietf.org
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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

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

Bill Marshall
wtm@research.att.com

-----original messaage-----
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Date: Wed, 27 Jun 2001 10:57:08 -0600
From: "Zmolek, Andrew (Andrew)" 
To: "Sean Olson (EUS)" ,
        "Chris Hogg" ,
        "Jonathan Rosenberg" ,
        "Mathieu, Marie-Noelle" ,
        
Cc: "Boyle, Frank J (Duffy)" ,
        "Freundlich, Glen G (Glen)" 

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

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

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

--Andy

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


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


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

/sean

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


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

            zmolek@avaya.com
              +1 720 444 4001


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



Hi Jonathan, 

Jonathan Rosenberg wrote: 

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

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

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

Comments? 


Regards, 

Chris Hogg 
Nortel Networks. 


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




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


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

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

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



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

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


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

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

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



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


From sip-admin@ietf.org  Wed Jun 27 15:19:58 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09107;
	Wed, 27 Jun 2001 15:19:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24534;
	Wed, 27 Jun 2001 15:09:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24503
	for ; Wed, 27 Jun 2001 15:09:49 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01205
	for ; Wed, 27 Jun 2001 15:09:07 -0400 (EDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f5RJ9jO23772;
	Wed, 27 Jun 2001 21:09:45 +0200 (MEST)
Received: from lmf.ericsson.se (racom107115.am.ericsson.se [147.117.107.115])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id VAA01042;
	Wed, 27 Jun 2001 21:10:16 +0200 (MET DST)
Message-ID: <3B3A316B.B8166C2E@lmf.ericsson.se>
Date: Wed, 27 Jun 2001 22:18:03 +0300
From: Gonzalo Camarillo 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Sean Olson (EUS)" 
CC: "'Zmolek, Andrew (Andrew)'" ,
        Chris Hogg ,
        Jonathan Rosenberg ,
        "Mathieu, Marie-Noelle" ,
        sip@ietf.org
Subject: Re: [Sip] RE: [Sipping] Call and call-id
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

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

Note that in
http://search.ietf.org/internet-drafts/draft-ietf-sip-overlap-00.txt

we use the call-ID to correlate different INVITEs for the same call.
However, since the draft clearly states that such a mechanism is to be
used only in a controlled enviroment, I do not think we should worry
about it in this discussion.

This mail was just a clarification. I agree with what Sean said.

Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

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


From sip-admin@ietf.org  Wed Jun 27 16:31:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09945;
	Wed, 27 Jun 2001 16:31:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26949;
	Wed, 27 Jun 2001 16:20:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26920
	for ; Wed, 27 Jun 2001 16:20:21 -0400 (EDT)
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02068
	for ; Wed, 27 Jun 2001 16:19:41 -0400 (EDT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0GFL00A91V4DRT@firewall.mcit.com> for sip@ietf.org; Wed,
 27 Jun 2001 20:19:25 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0GFL00301V48EN@dgismtp01.wcomnet.com> for
 sip@ietf.org; Wed, 27 Jun 2001 20:19:24 +0000 (GMT)
Received: from wcom.com ([166.42.36.163])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0GFL00193V3XZW@dgismtp01.wcomnet.com> for sip@ietf.org; Wed,
 27 Jun 2001 20:19:10 +0000 (GMT)
Date: Wed, 27 Jun 2001 15:11:27 -0500
From: Alan Johnston 
Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-service-examples-02.txt
To: SIP List 
Message-id: <3B3A3DEF.ED5FE6A5@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en] (Win98; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <200106271103.HAA26222@ietf.org>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

This new version of the SIP Service Examples has the following changes:

   - Added Replaces header to flows involving attended transfer or call pickup.

   - Changed handling of call hold from responding to hold re-INVITE with hold SDP to
responding with normal SDP.

   - Added Contact and Referred-By headers and ref parameters to REFER  messages (hopefully
the URL escaping is correct)

   - Changed some Contacts, Routes, and Request-URIs to IP addresses.

   - Incremented o= line when SDP is updated with hold.

   - Added From tags throughout.

   - Renamed Music On Hold/Call Park call flow to Call Park and added new Music On Hold
call flow using 3pcc

Comments and suggestions are most welcome.

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

Internet-Drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Session Initiation Protocol Working Group of the IETF.
>
>         Title           : SIP Service Examples
>         Author(s)       : A. Johnston, R. Sparks, C. Cunningham,
>                           S. Donovan, K. Summers
>         Filename        : draft-ietf-sip-service-examples-02.txt
>         Pages           : 107
>         Date            : 26-Jun-01
>
> This informational document gives examples of SIP (Session Initiation
> Protocol) services.  This covers most features offered in so-called
> Centrex offerings from local exchange carriers and PBX (Private
> Branch Exchange) features.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-service-examples-02.txt
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-sip-service-examples-02.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         mailserv@ietf.org.
> In the body type:
>         "FILE /internet-drafts/draft-ietf-sip-service-examples-02.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>   ------------------------------------------------------------------------
>
>    draft-ietf-sip-service-examples-02.txtName: draft-ietf-sip-service-examples-02.txt
>                                          Type: Plain Text (text/plain)


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


From sip-admin@ietf.org  Wed Jun 27 17:39:13 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25597;
	Wed, 27 Jun 2001 17:39:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29282;
	Wed, 27 Jun 2001 17:27:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29198
	for ; Wed, 27 Jun 2001 17:27:03 -0400 (EDT)
Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16872
	for ; Wed, 27 Jun 2001 17:26:22 -0400 (EDT)
Received: from iere.net.avaya.com (localhost [127.0.0.1])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5RLQMq02031
	for ; Wed, 27 Jun 2001 17:26:22 -0400 (EDT)
Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5RLQLv02018
	for ; Wed, 27 Jun 2001 17:26:22 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FF4F.ED0D2F9C"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Date: Wed, 27 Jun 2001 15:27:11 -0600
Message-ID: 
Thread-Topic: [Sip] RE: [Sipping] Call and call-id
Thread-Index: AcD/N6oD2S+diEObR7C4NT4BvJEsGAAFZ9CA
From: "Zmolek, Andrew (Andrew)" 
To: "William Marshall" , 
Cc: , ,
        , ,
        , ,
        
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C0FF4F.ED0D2F9C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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

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

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

            zmolek@avaya.com
              +1 720 444 4001



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


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

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

Bill Marshall
wtm@research.att.com

-----original messaage-----
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Date: Wed, 27 Jun 2001 10:57:08 -0600
From: "Zmolek, Andrew (Andrew)" 
To: "Sean Olson (EUS)" ,
        "Chris Hogg" ,
        "Jonathan Rosenberg" ,
        "Mathieu, Marie-Noelle" ,
        
Cc: "Boyle, Frank J (Duffy)" ,
        "Freundlich, Glen G (Glen)" 

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

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

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

--Andy

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


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


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

/sean

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


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

            zmolek@avaya.com
              +1 720 444 4001


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



Hi Jonathan,=20

Jonathan Rosenberg wrote:=20

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

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

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

Comments?=20


Regards,=20

Chris Hogg=20
Nortel Networks.=20


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




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


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

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

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



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

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


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

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

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



_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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_01C0FF4F.ED0D2F9C
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Sip] RE: [Sipping] Call and call-id





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



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



--Andy Zmolek


    Technology & Standards =
Engineer


      CTO Standards


        Avaya =
Inc.




          &nbs=
p; zmolek@avaya.com


          &nbs=
p;   +1 720 444 4001








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


From: William Marshall [mailto:wtm@research.att.com]


Sent: Wednesday, June 27, 2001 11:59 AM


To: zmolek@avaya.ccom.avaya.com


Cc: sean.olson@ericsson.com; =
chogg@nortelnetworks.com;


jdrosen@dynamicsoft.com; =
Marie-Noelle.Mathieu@compaq.com;


duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; =
sip@ietf.org


Subject: RE: [Sip] RE: [Sipping] Call and =
call-id






State headers operate in both directions.  A UAC =
that inserts a State header


in the INVITE will see the contents returned in every =
provisional and final


response, as well as any re-INVITE initiated by the =
UAS.  A UAS that


inserts a State header into a provisional or final =
response will see


the contents returned in every re-INVITE from the =
UAC, as well as


provisional and final responses to requests initiated =
by the UAS.


The State header is documented in =
draft-ietf-sip-state-01.




Rules for handling of State headers with future =
extensions will need


to be specified in the draft defining that extension. =
In particular,


a REFER that is attempting to replace an existing =
call leg may need


the State headers from the previous call leg attached =
to the new


INVITE, along with the From/To/Call-ID.  This is =
all still to-be-defined.




Bill Marshall


wtm@research.att.com




-----original messaage-----


Subject: RE: [Sip] RE: [Sipping] Call and =
call-id


Date: Wed, 27 Jun 2001 10:57:08 -0600


From: "Zmolek, Andrew (Andrew)" =
<zmolek@avaya.com>


To: "Sean Olson (EUS)" =
<sean.olson@ericsson.com>,


        =
"Chris Hogg" <chogg@nortelnetworks.com>,


        =
"Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,


        =
"Mathieu, Marie-Noelle" =
<Marie-Noelle.Mathieu@compaq.com>,


        =
<sip@ietf.org>


Cc: "Boyle, Frank J (Duffy)" =
<duffy@drmail.dr.avaya.com>,


        =
"Freundlich, Glen G (Glen)" =
<ggf@drmail.dr.avaya.com>




Does DCS state only operate in one direction (ie.only =
from the SIP


transaction initiator)? If so, it would need to be =
extended to provide


equivalent information when two endpoints have =
hundreds or thousands of


individual call legs in hundreds of sessions and =
either end might


initiate any given SIP transaction.




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


case?




If DCS state is extensible to provide an equivalent =
session identifier


at both ends of any given call, then I agree that =
there isn't any need


for bi-directional cookies to be grantable and =
remittable by either end.


But given the current draft's focus on proxies and =
what appears to be a


unidirectional call state, I'm not sure that it's =
complete enough to


solve the whole problem. Please correct me if I've =
missed something...




--Andy




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


From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]


Sent: Wednesday, June 27, 2001 9:19 AM


To: Zmolek, Andrew (Andrew); Chris Hogg; Jonathan =
Rosenberg; Mathieu,


Marie-Noelle; sip@ietf.org


Subject: RE: [Sip] RE: [Sipping] Call and =
call-id






Have you considered the DCS State: draft for this =
mechanism?  See


http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt


<http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt&g=
t;




IMHO, I don't see a need for such a use of a Cookie. =
Correlating


messages to calls is not that difficult. The key =
thing to note, as you


have, is that Call-ID is not necessarily useful for =
tying multiple call


legs together.




/sean




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


From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com]


Sent: Wednesday, June 27, 2001 9:55 AM


To: Chris Hogg; Jonathan Rosenberg; Mathieu, =
Marie-Noelle; sip@ietf.org


Subject: RE: [Sip] RE: [Sipping] Call and =
call-id






I think it would be good to clarify our terminology, =
particularly since


we sometimes forget SIP does not provide directly for =
a call with


multiple active call legs (i.e. B2BUA is needed to =
rationalize each


individual SIP call with the overall session). I =
propose we define


"call" to mean the two participants in any =
given transaction and


"session" to be some collection of calls =
associated within a given UA


(note that "invited by a common source" is =
not a complete description


since some or all of the invites could have =
originated outside the UA). 


 


This thread brings out several reasons why Call-ID =
should not be used to


define a "session" of multiple =
"calls" as defined above. Mainly because


of this, I'm preparing an I-D to address this need =
through the use of


header extensions for cookies, which each UA can =
independently grant and


accept in order to correlate call legs and =
potentially provide


additional context for a given call. The alternative =
is vendor-specific


headers and a walled garden approach to many features =
available in


conventional PBXes today, and I don't think that's =
beneficial for SIP in


the long run.


 


--Andy Zmolek


    Technology & Standards =
Engineer


      CTO Standards


        Avaya =
Inc.




          &nbs=
p; zmolek@avaya.com


          &nbs=
p;   +1 720 444 4001






 


 


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


From: Chris Hogg [mailto:chogg@nortelnetworks.com<=
/A>]


Sent: Wednesday, June 27, 2001 4:03 AM


To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew); =
Mathieu,


Marie-Noelle; sip@ietf.org


Subject: RE: [Sip] RE: [Sipping] Call and =
call-id








Hi Jonathan, 




Jonathan Rosenberg wrote: 




>Careful; I am not proposing that two call legs =
with the same Call-ID convey 


>any semantics. Specifically, receiving an INVITE =
from A, while in a call 


>with B, where the call-id in the INVITE from A =
equals the call-id in the leg 


>with B, does NOT imply that this is a =
consultative transfer. For that, we 


>have Replaces, which lists the replaced leg =
explicitly. 




>All I am saying is that a Call-ID may be reused =
for local convenience, if 


>desired, but that it has NO semantics outside of =
the entity that selected 


>that call-id. 




Given, what you are proposing will this not mean that =
the definition of


a call needs to be altered?  The reason I ask is =
that bis-03 defines a


call as "identified by a globally unique =
callID" and "all participants


invited by a common source".  In the case =
you describe under the current


definition of a call this would mean that we would =
have two calls (under


the "all participants invited by a common =
source" rule) but with the


same callID (hence contravening the "globally =
unique callID" part).    




Comments? 






Regards, 




Chris Hogg 


Nortel Networks. 






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


From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com


<mailto:jdrosen@dynamicsoft.com> ] 


Sent: 26 June 2001 22:51 


To: 'Zmolek, Andrew (Andrew)'; Jonathan Rosenberg; =
Mathieu, 


Marie-Noelle; sip@ietf.org 


Subject: RE: [Sip] RE: [Sipping] Call and call-id =











  


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


From: Zmolek, Andrew (Andrew) [ mailto:zmolek@avaya.com


<mailto:zmolek@avaya.com> ] =



Sent: Tuesday, June 26, 2001 12:35 PM 


To: Jonathan Rosenberg; Mathieu, Marie-Noelle; =
sip@ietf.org 


Subject: RE: [Sip] RE: [Sipping] Call and call-id =







>> >same call-id in the 2 INVITE requests, is =
this allowed ? 


>> 


>> Well, the current spec would indicate that =
you shouldn't do this: 


>> 


>> >The callid MUST be a globally unique =
identifier and MUST NOT be reused for 


>> >later calls. 


>> 


>> However, I recall some discussion at an IETF =
that people were using the same


>> call-id across different call legs as a =
local identifier to correlate those 


>> call legs. With unique From tags and From =
fields, there really shouldn't be 


>> a problem, so I think its OK. However, if we =
are going to allow it, the spec


>> should reflect it. Comments? 


> 


>If that's the proper way to solve this problem, =
then let's put that in the 


>spec. But I'm not convinced that this alone will =
solve all cases, especially 


>when this correlated information needs to be =
presented by a call leg attempting 


>to join (as in the consultative transfer case). =





Careful; I am not proposing that two call legs with =
the same Call-ID convey 


any semantics. Specifically, receiving an INVITE from =
A, while in a call


with B, where the call-id in the INVITE from A equals =
the call-id in the leg 


with B, does NOT imply that this is a consultative =
transfer. For that, we 


have Replaces, which lists the replaced leg =
explicitly. 




All I am saying is that a Call-ID may be reused for =
local convenience, if 


desired, but that it has NO semantics outside of the =
entity that selected 


that call-id. 








> It only seems to work when the 


>correlating entity initiates all the calls. If =
there's a reliable way to 


>correlate an incoming call leg with an existing =
call, I'd love to hear about 


>it. 




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


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




needs updating and adoption though, if we plan to move =
forward with it. As 


you can see, its currently in the morgue. 




-Jonathan R. 


--- 


Jonathan D. Rosenberg, =
Ph.D.           &n=
bsp;    72 Eagle Rock Ave. 


Chief =
Scientist          &nbs=
p;            =
;      First Floor 


dynamicsoft         =
;            =
            East =
Hanover, NJ 07936 


jdrosen@dynamicsoft.com       =
;            =
  FAX:   (973) 952-5050 


http://www.jdrosen.net <http://www.jdrosen.net>


PHONE: (973) 952-5000 


http://www.dynamicsoft.com =
<http://www.dynamicsoft.com>&nb=
sp; 




_______________________________________________ =



Sip mailing list  http://www.ietf.org/mai=
lman/listinfo/sip


<http://www.ietf.org/mai=
lman/listinfo/sip>  


This list is for NEW development of the core SIP =
Protocol 


Use sip-implementors@cs.columbia.edu for questions on =
current sip 


Use sipping@ietf.org for new developments on the =
application of sip 








_______________________________________________


Sip mailing list  http://www.ietf.org/mai=
lman/listinfo/sip


This list is for NEW development of the core SIP =
Protocol


Use sip-implementors@cs.columbia.edu for questions on =
current sip


Use sipping@ietf.org for new developments on the =
application of sip





------_=_NextPart_001_01C0FF4F.ED0D2F9C--

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


From sip-admin@ietf.org  Wed Jun 27 20:06:08 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03717;
	Wed, 27 Jun 2001 20:06:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04594;
	Wed, 27 Jun 2001 20:00:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04555
	for ; Wed, 27 Jun 2001 20:00:19 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29149
	for ; Wed, 27 Jun 2001 19:59:38 -0400 (EDT)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA18422;
	Wed, 27 Jun 2001 20:00:14 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id UAA07820;
	Wed, 27 Jun 2001 20:00:14 -0400 (EDT)
Message-ID: <3B389067.36F7FB96@cs.columbia.edu>
Date: Tue, 26 Jun 2001 06:38:47 -0700
From: Henning Schulzrinne 
Organization: Columbia University
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Hidefumi Nakamura'" ,
        "'sip@ietf.org'" 
Subject: Re: [SIP] Congestion control
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> 1. 503 is the appropriate response to indicate congestion or any other
> resource constraints that make a server temporarily congested.
> 
> 2. A client receiving a 503 SHOULD attempt to contact an alternate server.
> 
> 3. A server should generate and/or forward a 503 upstream only if all
> requests that would reach the server cannot be serviced. This means that the
> server itself is congested, or every possible next-hop it can route to is
> congested (which is fairly unlikely but can happen in certain
> configurations).

Just in case, as I'm not sure I'm interpreting item 3 correctly:

A 503 is a statement of why the current request failed. "Past
performance is not a guarantee of future results", or some such. Thus, a
503 does not indicate that "all requests that *would* reach the server
cannot be serviced", only that the current request couldn't be serviced
due to overload. This doesn't mean that another request sent in the next
millisecond would also fail.

503 would only be returned by a forking proxy if that's the "best"
response. If one downstream server returns a 517 (imaginary) and another
a 503, a 503 is returned. Thus, it is not necessary that *all* next-hops
return 503 for a 503 to be returned. Normally, the proxy would retry
alternate servers on a fork that returned a 503, so it does mean that at
least one branch is unreachable due to congestion and that others
returned "worse" error codes.



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


From sip-admin@ietf.org  Thu Jun 28 05:00:58 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09652;
	Thu, 28 Jun 2001 05:00:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29851;
	Thu, 28 Jun 2001 04:35:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29817
	for ; Thu, 28 Jun 2001 04:35:48 -0400 (EDT)
Received: from znsgs0ja.europe.nortel.com (znsgs0ja.nortelnetworks.com [47.165.25.40])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09348
	for ; Thu, 28 Jun 2001 04:35:06 -0400 (EDT)
Received: from qnsgs000.nortel.com (znsgs016 [47.255.64.31])
	by znsgs0ja.europe.nortel.com (8.11.0/8.11.0) with ESMTP id f5S8Z8w13990
	for ; Thu, 28 Jun 2001 09:35:08 +0100 (BST)
Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com;
          Thu, 28 Jun 2001 09:34:50 +0100
Received: by znsgd00t.europe.nortel.com 
          with Internet Mail Service (5.5.2653.19) id ;
          Thu, 28 Jun 2001 09:34:22 +0100
Message-ID: <757032945337D2118E6B0000F8080CC10A468D92@zwcwd002.europe.nortel.com>
From: "Chris Hogg" 
To: "'sip@ietf.org'" 
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Date: Thu, 28 Jun 2001 09:34:20 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0FFAD.2057E470"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FFAD.2057E470
Content-Type: text/plain;
	charset="iso-8859-1"

Reposted to list due to mail problems. Apologies to anyone who receives this
twice.

Hi Jonathan, 
Jonathan Rosenberg wrote: 
>Careful; I am not proposing that two call legs with the same Call-ID convey

>any semantics. Specifically, receiving an INVITE from A, while in a call 
>with B, where the call-id in the INVITE from A equals the call-id in the
leg 
>with B, does NOT imply that this is a consultative transfer. For that, we 
>have Replaces, which lists the replaced leg explicitly. 
>All I am saying is that a Call-ID may be reused for local convenience, if 
>desired, but that it has NO semantics outside of the entity that selected 
>that call-id. 
Given, what you are proposing will this not mean that the definition of a
call needs to be altered? The reason I ask is that bis-03 defines a call as
"identified by a globally unique callID" and "all participants invited by a
common source". In the case you describe under the current definition of a
call this would mean that we would have two calls (under the "all
participants invited by a common source" rule) but with the same callID
(hence contravening the "globally unique callID" part). 

Comments? 


Regards, 

Chris Hogg 
Nortel Networks. 




------_=_NextPart_001_01C0FFAD.2057E470
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: [Sip] RE: [Sipping] Call and call-id




Reposted to list due to mail problems. Apologies to =
anyone who receives this twice.




Hi Jonathan, 

Jonathan Rosenberg wrote: 

>Careful; I am not proposing that two call legs =
with the same Call-ID convey 

>any semantics. Specifically, receiving an INVITE =
from A, while in a call 

>with B, where the call-id in the INVITE from A =
equals the call-id in the leg 

>with B, does NOT imply that this is a =
consultative transfer. For that, we 

>have Replaces, which lists the replaced leg =
explicitly. 

>All I am saying is that a Call-ID may be reused =
for local convenience, if 

>desired, but that it has NO semantics outside of =
the entity that selected 

>that call-id. 

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



Comments? 






Regards, 




Chris Hogg 

Nortel Networks. 









------_=_NextPart_001_01C0FFAD.2057E470--

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


From sip-admin@ietf.org  Thu Jun 28 05:36:42 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09902;
	Thu, 28 Jun 2001 05:36:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01651;
	Thu, 28 Jun 2001 05:30:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01596
	for ; Thu, 28 Jun 2001 05:30:10 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09835
	for ; Thu, 28 Jun 2001 05:29:28 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f5S9U7O09607;
	Thu, 28 Jun 2001 11:30:07 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.7])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5S9U5506834;
	Thu, 28 Jun 2001 12:30:05 +0300 (EET DST)
Message-ID: <3B3AF917.3F336002@lmf.ericsson.se>
Date: Thu, 28 Jun 2001 12:29:59 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Hammer 
CC: Jonathan Rosenberg ,
        "'Bob Penfield'" ,
        "'Barry Desborough'" ,
        "'Paul Kyzivat'" , sip@ietf.org,
        gonzalo.camarillo@lmf.ericsson.se
Subject: Re: [Sip] RE: reason code in BYE/CANCEL (was[Sip-implementors] another  
 problem related to multiple call l egs at UAC)
References:  <4.3.2.7.2.20010627101027.00b0a818@cia.cisco.com>
Content-Type: multipart/mixed;
 boundary="------------16FEF05BEF6357E402F6DE45"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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


Hi,

If we are going to add the Reason header, I think it now would also
would be a good idea to allow the Retry-After header in requests (BYE
and CANCEL). For example, if the called party sends a BYE because of
some internal, or whatever, reason, it may then indicate when the caller
could be able to re-establish the call.

Comments?

Regards,

Christer Holmberg
Ericsson Finland





Michael Hammer wrote:
> 
> Comment below.
> 
> At 08:55 AM 6/27/2001 +0300, Christer Holmberg wrote:
> 
> >Hi,
> >
> >Some example of codes that maybe could be useful.
> >
> >
> >403 Session-timer expired
> >
> >This would be used if the call is released when the session-timer
> >expires.
> >
> >
> >404 Another leg chosen
> >
> >This would be useful IF we allow CANCELs and pre-call-setup BYEs for
> >specific call-legs (discussion on this in another thread...)
> >
> >
> >405 Service not available
> >
> >This could be used for many purposes. One example could be some kind of
> >calling card/pre-pay call service. When the caller runs out of money, or
> >the call time limit is exceeded, the call could be terminated using this
> >Reason.
> >
> >
> >406 Client error
> >
> >This would be used if the client, for any internal reason, must
> >terminate the call. Load balancing is one example where this could be
> >used. Another example is if the call state somehow gets messed up in the
> >client, and it deciedes to release the call.
> >
> >This Reason could also be used, for the same purpose, by proxies, or
> >there could be a separate Reason value for those (407 Proxy error)
> >
> >A couple of issues, though:
> >
> >
> >Issue 1: Use existing codes
> >
> >Before we start defining a new set of codes, I DO think that we should
> >have a look at the existing response codes, and see if they (or part of
> >them) can be used for the Reason header. Then, if we define new codes,
> >they may also be used for responses.
> 
> One of the key values of the reason code is that it can be sent in forward
> requests, not just backward responses.
> 
> >Issue 2: ISUP-SIP
> >
> >I assume this COULD also affect the ISUP-SIP mapping, IF different
> >Reason header values will produce different mapping. I guess Gonzalo can
> >comment on this.
> >
> >
> >Regards,
> >
> >Christer Holmberg
> >Ericsson Finland
> >
> >
> >
> >
> >
> >Jonathan Rosenberg wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> > > > Sent: Monday, June 25, 2001 5:04 PM
> > > > To: Jonathan Rosenberg; 'Barry Desborough'; 'Paul Kyzivat'
> > > > Cc: sip@ietf.org
> > > > Subject: reason code in BYE/CANCEL (was [Sip-implementors] another
> > > > problem related to multiple call l egs at UAC)
> > > >
> > > >
> > > >
> > > > Jonathan Rosenberg wrote:
> > > > >
> > > > >
> > > > >  Moving from sip-implementors to sip since there are some
> > > > open issues and
> > > > > changes to bis in here.
> > > > >
> > > > >
> > > >
> > > > 
> > > > > Barry Desborough wrote:
> > > > >
> > > > > > I also agree that encoded reasons should be added to BYEs and
> > > > > > CANCELs such
> > > > > > that a PSDN gateway can map them to and from Q.931 cause codes.
> > > > >
> > > > > I also like these BYE reasons. This has come up countless
> > > > times. Its also
> > > > > helpful in CANCEL, to know whether a call was cancelled
> > > > because the caller
> > > > > aborted, or because some other branch picked up (the former
> > > > would generate
> > > > a
> > > > > missed call entry in a call log, whilst the other won't). I
> > > > don't think
> > > > > Warning is right, but some kind of header that conveys both a
> > > > > machine-interpretable and human-interpretable value would be good.
> > > > >
> > > > How about a "Reason" request header (or is that already
> > > > defined elswhere)
> > > > that uses the same format as the Warning header?
> > > >
> > > >         Reason        =  "Reason" ":" 1#reason-value
> > > >         reason-value  =  reason-code SP reason-agent SP reason-text
> > > >         reason-code   =  3DIGIT
> > > >         reason-agent  =  host [ ":" port ]
> > > >                           ;  the name of the server adding
> > > >                           ;  the Reason header, for use in
> > > > tracing/debugging
> > > >         reason-text   =  quoted-string
> > > >
> > > >
> > > >
> > >
> > > Reason is not used. Seems reasonable for the header name.
> > >
> > > I'm not sure the reason-agent is needed.
> > >
> > > The trick is defining the codes. A few I can think of:
> > >
> > > 400 Caller hung up
> > >
> > >   this would be in a CANCEL if the UAC hangs up before an INVITE
> > generates a
> > > final response, or in a BYE at any point later. Its the normal call
> > > termination case.
> > >
> > > 401 INVITE succeeded elsewhere
> > >
> > >   this would be in a CANCEL generated because an INVITE generated a 2xx on
> > > another branch.
> > >
> > > 402 media stream failure
> > >
> > >   this would be in a BYE that was sent because there was some failure
> > in the
> > > media streams or something like that.
> > >
> > > other suggestions?
> > >
> > > -Jonathan R.
> > >
> > > ---
> > > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > > Chief Scientist                             First Floor
> > > dynamicsoft                                 East Hanover, NJ 07936
> > > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > > http://www.dynamicsoft.com
> > >
> > > _______________________________________________
> > > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the application of sip
--------------16FEF05BEF6357E402F6DE45
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------16FEF05BEF6357E402F6DE45--


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


From sip-admin@ietf.org  Thu Jun 28 08:13:11 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13194;
	Thu, 28 Jun 2001 08:13:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06121;
	Thu, 28 Jun 2001 07:48:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06095
	for ; Thu, 28 Jun 2001 07:48:18 -0400 (EDT)
Received: from mailFA7.rediffmail.com (IDENT:qmailr@[202.54.124.152])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA12367
	for ; Thu, 28 Jun 2001 07:47:36 -0400 (EDT)
Received: (qmail 25225 invoked by uid 510); 28 Jun 2001 11:09:11 -0000
Date: 28 Jun 2001 11:09:11 -0000
Message-ID: <20010628110911.25224.qmail@mailFA7.rediffmail.com>
Received: from unknown (203.197.251.9) by rediffmail.com via HTTP; 28 Jun 2001 11:09:11 -0000
MIME-Version: 1.0
To: "christer.holmberg@lmf.ericsson.se" ,
        "mhammer@cisco.com" 
CC: "jdrosen@dynamicsoft.com" ,
        "bpenfield@acmepacket.com" ,
        "BarryD@vegastream.com" ,
        "pkyzivat@cisco.com" ,
        "sip@ietf.org" ,
        "gonzalo.camarillo@lmf.ericsson.se" 
From: "Ashhar Farhan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] RE: reason code in BYE/CANCEL (was[Sip-implementors] another  problem related to multiple call l egs at UAC)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

is the reason code meant for machine interpretation or is it meant to be informational for the end-user?

if it is meant for the machine to interpret the reason, that is to be covered by the response code itself. we may have to expand the number of response codes.
The number codes are the most efficient and unambiguous way of conveying a reason.

on the otherhand, if the reason is a message targeted at the end-user, it's place would probably be in the body of the message. if the machine is NOT interpreting the reason code, it could as well be supplied as a seperate MESSAGE.

- farhan@hotfoon.com


____________________________________________________
Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm




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


From sip-admin@ietf.org  Thu Jun 28 09:27:19 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28819;
	Thu, 28 Jun 2001 09:27:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08970;
	Thu, 28 Jun 2001 09:10:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08939
	for ; Thu, 28 Jun 2001 09:10:04 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19510
	for ; Thu, 28 Jun 2001 09:09:17 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f5SD9vO04825;
	Thu, 28 Jun 2001 15:09:57 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.7])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5SD9t516113;
	Thu, 28 Jun 2001 16:09:55 +0300 (EET DST)
Message-ID: <3B3B2C95.C28745B4@lmf.ericsson.se>
Date: Thu, 28 Jun 2001 16:09:41 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ashhar Farhan 
CC: "mhammer@cisco.com" ,
        "jdrosen@dynamicsoft.com" ,
        "bpenfield@acmepacket.com" ,
        "BarryD@vegastream.com" ,
        "pkyzivat@cisco.com" ,
        "sip@ietf.org" ,
        "gonzalo.camarillo@lmf.ericsson.se" 
References: <20010628110911.25224.qmail@mailFA7.rediffmail.com>
Content-Type: multipart/mixed;
 boundary="------------DED83A791DC6A8EC5366AE09"
Subject: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors] another  problem
 related to multiple call l egs at UAC)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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


Hi,

Since a BYE is always a BYE, no matter what the reason code will be (if
there is a reason code in the first place...), I would say it's an
implementation issue to decide which set of reason codes will trigger
extra internal actions by the server. If a reason code is not
understood/supported by the server, it will simply discard it, but still
release the call. We should remember that the Reason will be an optional
feature, so the server may not even understand them in the first place.

However, I DO think that we should specify the set of reason codes that
the Reason header will use, and WHEN, so that servers that do trigger
some kind of action really do the right thing (ie if they trigger a
message telling the user that the reason for the call release is X, then
the reason really is X).

Regards,

Christer Holmberg
Ericsson Finland



Ashhar Farhan wrote:
> 
> is the reason code meant for machine interpretation or is it meant to be informational for the end-user?
> 
> if it is meant for the machine to interpret the reason, that is to be covered by the response code itself. we may have to expand the number of response codes.
> The number codes are the most efficient and unambiguous way of conveying a reason.
> 
> on the otherhand, if the reason is a message targeted at the end-user, it's place would probably be in the body of the message. if the machine is NOT interpreting the reason code, it could as well be supplied as a seperate MESSAGE.
> 
> - farhan@hotfoon.com
> 
> ____________________________________________________
> Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm
--------------DED83A791DC6A8EC5366AE09
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------DED83A791DC6A8EC5366AE09--


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


From sip-admin@ietf.org  Thu Jun 28 09:54:13 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16534;
	Thu, 28 Jun 2001 09:54:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA09164;
	Thu, 28 Jun 2001 09:14:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA03194
	for ; Wed, 27 Jun 2001 19:27:04 -0400 (EDT)
Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06330
	for ; Wed, 27 Jun 2001 19:26:18 -0400 (EDT)
Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f5RMhWB07705
	for ; Wed, 27 Jun 2001 17:43:32 -0500 (CDT)
Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37])
	by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f5RMhRf10590
	for ; Wed, 27 Jun 2001 17:43:27 -0500 (CDT)
Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jun 27 17:43:26 2001 -0500
Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19)
	id ; Wed, 27 Jun 2001 17:43:26 -0500
Message-ID: 
From: "Sean Olson (EUS)" 
To: "'Zmolek, Andrew (Andrew)'" ,
        William Marshall
	 , zmolek@avaya.ccom.avaya.com
Cc: "Sean Olson (EUS)" , chogg@nortelnetworks.com,
        jdrosen@dynamicsoft.com, Marie-Noelle.Mathieu@compaq.com,
        duffy@bighorn.dr.avaya.com, ggf@bighorn.dr.avaya.com, sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Date: Wed, 27 Jun 2001 17:43:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0FF5A.8E78E100"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0FF5A.8E78E100
Content-Type: text/plain;
	charset="iso-8859-1"

The State: header is a SIP extension. I believe it can be used independently
of the other DCS extensions. The real issue is how widespread will the
extension be -- can you depend on "most" clients to support it. 
 
I'm not sure what you mean by "token persistence". Do you mean
a State: header that spans multiple call legs? 
 
/sean

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



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

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

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

            zmolek@avaya.com 
              +1 720 444 4001 



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


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

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

Bill Marshall 
wtm@research.att.com 

-----original messaage----- 
Subject: RE: [Sip] RE: [Sipping] Call and call-id 
Date: Wed, 27 Jun 2001 10:57:08 -0600 
From: "Zmolek, Andrew (Andrew)"  
To: "Sean Olson (EUS)" , 
        "Chris Hogg" , 
        "Jonathan Rosenberg" , 
        "Mathieu, Marie-Noelle" , 
         
Cc: "Boyle, Frank J (Duffy)" , 
        "Freundlich, Glen G (Glen)"  

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

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

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

--Andy 

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


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

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

/sean 

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


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

            zmolek@avaya.com 
              +1 720 444 4001 



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



Hi Jonathan, 

Jonathan Rosenberg wrote: 

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

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

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

Comments? 


Regards, 

Chris Hogg 
Nortel Networks. 


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




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


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

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

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



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

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

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

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

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



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


------_=_NextPart_001_01C0FF5A.8E78E100
Content-Type: text/html;
	charset="iso-8859-1"




RE: [Sip] RE: [Sipping] Call and call-id




The 
State: header is a SIP extension. I believe it can be used 
independently


of the 
other DCS extensions. The real issue is how widespread will 
the


extension be -- can you depend on "most" clients to support it. 



 


I'm 
not sure what you mean by "token persistence". Do you mean


a 
State: header that spans multiple call legs? 


 


/sean



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


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

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

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

  
            
  zmolek@avaya.com 
              
  +1 720 444 4001 



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


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

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

  
Bill Marshall 
wtm@research.att.com 

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

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

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

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

  
--Andy 

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


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

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

  
/sean 

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


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

  
            
  zmolek@avaya.com 
              
  +1 720 444 4001 


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



  
Hi Jonathan, 

  
Jonathan Rosenberg wrote: 

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

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

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

  
Comments? 


  
Regards, 

  
Chris Hogg 
Nortel Networks. 
  


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




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


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

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

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



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

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

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

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

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



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


------_=_NextPart_001_01C0FF5A.8E78E100--


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


From sip-admin@ietf.org  Thu Jun 28 11:06:29 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07684;
	Thu, 28 Jun 2001 11:06:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12894;
	Thu, 28 Jun 2001 10:40:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12861
	for ; Thu, 28 Jun 2001 10:40:54 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19027
	for ; Thu, 28 Jun 2001 10:40:10 -0400 (EDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f5SEepO18544;
	Thu, 28 Jun 2001 16:40:51 +0200 (MEST)
Received: from lmf.ericsson.se (racom107014.am.ericsson.se [147.117.107.14])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA23243;
	Thu, 28 Jun 2001 16:41:22 +0200 (MET DST)
Message-ID: <3B3B43ED.6678C462@lmf.ericsson.se>
Date: Thu, 28 Jun 2001 17:49:17 +0300
From: Gonzalo Camarillo 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ashhar Farhan 
CC: "christer.holmberg@lmf.ericsson.se" ,
        "mhammer@cisco.com" ,
        "jdrosen@dynamicsoft.com" ,
        "bpenfield@acmepacket.com" ,
        "BarryD@vegastream.com" ,
        "pkyzivat@cisco.com" ,
        "sip@ietf.org" 
References: <20010628110911.25224.qmail@mailFA7.rediffmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors] another  problem
 related to multiple call l egs at UAC)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

> on the otherhand, if the reason is a message targeted at the end-user, it's place would probably be in the body of the message. if the machine is NOT interpreting the reason code, it could as well be supplied as a seperate MESSAGE.


As I said in a previous mail, we already have a set of reason phrases
and reason codes used in responses. Since it is very likely that in 3pcc
situations the reason phrase and the status codes of a response is
mapped into the BYEs' reason phrase and status code, I would suggest to
use the same format and the same codes.

If we have to add a couple of codes (I do not think we need too many),
it is alright. However, defining brand new status codes does not sound
good to me. Let us reuse what we already have.

Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

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


From sip-admin@ietf.org  Thu Jun 28 11:11:22 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11173;
	Thu, 28 Jun 2001 11:11:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13394;
	Thu, 28 Jun 2001 10:53:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13359
	for ; Thu, 28 Jun 2001 10:53:53 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28174
	for ; Thu, 28 Jun 2001 10:53:10 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A483ACE0252; Thu, 28 Jun 2001 10:51:47 -0400
Message-ID: <010401c0ffe0$f64a5e40$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: "Christer Holmberg" 
Cc: 
References: <20010628110911.25224.qmail@mailFA7.rediffmail.com> <3B3B2C95.C28745B4@lmf.ericsson.se>
Subject: Re: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors] another  problem related to multiple call l egs at UAC)
Date: Thu, 28 Jun 2001 10:45:21 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Christer Holmberg" 
To: "Ashhar Farhan" 
Cc: ; ;
; ; ;
; 
Sent: Thursday, June 28, 2001 9:09 AM
Subject: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors] another
problem related to multiple call l egs at UAC)


>
> Hi,
>
> Since a BYE is always a BYE, no matter what the reason code will be (if
> there is a reason code in the first place...), I would say it's an
> implementation issue to decide which set of reason codes will trigger
> extra internal actions by the server. If a reason code is not
> understood/supported by the server, it will simply discard it, but still
> release the call. We should remember that the Reason will be an optional
> feature, so the server may not even understand them in the first place.

The call should always be released no matter what the reason code is. It is
up to the UA implementation what it wants to do with the information.

>
> However, I DO think that we should specify the set of reason codes that
> the Reason header will use, and WHEN, so that servers that do trigger
> some kind of action really do the right thing (ie if they trigger a
> message telling the user that the reason for the call release is X, then
> the reason really is X).

Agreed.


> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
>
> Ashhar Farhan wrote:
> >
> > is the reason code meant for machine interpretation or is it meant to be
informational for the end-user?
> >
> > if it is meant for the machine to interpret the reason, that is to be
covered by the response code itself. we may have to expand the number of
response codes.
> > The number codes are the most efficient and unambiguous way of conveying
a reason.
> >
> > on the otherhand, if the reason is a message targeted at the end-user,
it's place would probably be in the body of the message. if the machine is
NOT interpreting the reason code, it could as well be supplied as a seperate
MESSAGE.
> >
> > - farhan@hotfoon.com
> >
> > ____________________________________________________
> > Buy Feng Shui Package for Rs. 151/- only, at
http://shopping.rediff.com/shopping/fengshui_mailer.htm


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


From sip-admin@ietf.org  Thu Jun 28 11:11:44 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11391;
	Thu, 28 Jun 2001 11:11:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13225;
	Thu, 28 Jun 2001 10:50:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13196
	for ; Thu, 28 Jun 2001 10:49:59 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25421
	for ; Thu, 28 Jun 2001 10:49:15 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A3978BCF0146; Thu, 28 Jun 2001 10:47:51 -0400
Message-ID: <00f801c0ffe0$6b1e9f20$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: "Ashhar Farhan" 
Cc: 
References: <20010628110911.25224.qmail@mailFA7.rediffmail.com>
Date: Thu, 28 Jun 2001 10:41:26 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors] another  problem related to multiple call l egs at UAC)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Ashhar Farhan" 
To: ; 
Cc: ; ;
; ; ;

Sent: Thursday, June 28, 2001 7:09 AM
Subject: RE: reason code in BYE/CANCEL (was[Sip-implementors] another
problem related to multiple call l egs at UAC)


> is the reason code meant for machine interpretation or is it meant to be
informational for the end-user?
>

The reason code is meant for machine interpretation so that a UA could act
on it. The Reason header would contain both a numeric value and a textual
description.

The most likely action with BYE (if it was a SIP phone) would be to display
something on the phone.

> if it is meant for the machine to interpret the reason, that is to be
covered by the response code itself. we may have to expand the number of
response codes.

The reason code is in a request rather than a response.

> The number codes are the most efficient and unambiguous way of conveying a
reason.
>
> on the otherhand, if the reason is a message targeted at the end-user,
it's place would probably be in the body of the message. if the machine is
NOT interpreting the reason code, it could as well be supplied as a seperate
MESSAGE.
>
> - farhan@hotfoon.com
>
>
> ____________________________________________________
> Buy Feng Shui Package for Rs. 151/- only, at
http://shopping.rediff.com/shopping/fengshui_mailer.htm
>
>
>
>


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


From sip-admin@ietf.org  Thu Jun 28 11:14:14 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13036;
	Thu, 28 Jun 2001 11:14:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12676;
	Thu, 28 Jun 2001 10:33:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12647
	for ; Thu, 28 Jun 2001 10:33:53 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13951
	for ; Thu, 28 Jun 2001 10:33:06 -0400 (EDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5SEXkN28635;
	Thu, 28 Jun 2001 16:33:46 +0200 (MEST)
Received: from lmf.ericsson.se (racom107014.am.ericsson.se [147.117.107.14])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA23043;
	Thu, 28 Jun 2001 16:34:15 +0200 (MET DST)
Message-ID: <3B3B4242.851BD0D0@lmf.ericsson.se>
Date: Thu, 28 Jun 2001 17:42:10 +0300
From: Gonzalo Camarillo 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Christer Holmberg 
CC: Michael Hammer ,
        Jonathan Rosenberg ,
        "'Bob Penfield'" ,
        "'Barry Desborough'" ,
        "'Paul Kyzivat'" , sip@ietf.org
Subject: Re: [Sip] RE: reason code in BYE/CANCEL (was[Sip-implementors] another  
 problem related to multiple call l egs at UAC)
References:  <4.3.2.7.2.20010627101027.00b0a818@cia.cisco.com> <3B3AF917.3F336002@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello Christer,

The retry-after header has transaction semantics. If I receive a
retry-after in a BYE I will try to send another BYE after the timer
expires...

What you want is something with call/session semantics.

This might be implementing using REFER. We could provide in a REFER the
time when we want the request to be sent (besides the request-URI,
method, etc, which is already provided in a REFER).

Regards,

Gonzalo

Christer Holmberg wrote:
> 
> Hi,
> 
> If we are going to add the Reason header, I think it now would also
> would be a good idea to allow the Retry-After header in requests (BYE
> and CANCEL). For example, if the called party sends a BYE because of
> some internal, or whatever, reason, it may then indicate when the caller
> could be able to re-establish the call.
> 
> Comments?
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> Michael Hammer wrote:
> >
> > Comment below.
> >
> > At 08:55 AM 6/27/2001 +0300, Christer Holmberg wrote:
> >
> > >Hi,
> > >
> > >Some example of codes that maybe could be useful.
> > >
> > >
> > >403 Session-timer expired
> > >
> > >This would be used if the call is released when the session-timer
> > >expires.
> > >
> > >
> > >404 Another leg chosen
> > >
> > >This would be useful IF we allow CANCELs and pre-call-setup BYEs for
> > >specific call-legs (discussion on this in another thread...)
> > >
> > >
> > >405 Service not available
> > >
> > >This could be used for many purposes. One example could be some kind of
> > >calling card/pre-pay call service. When the caller runs out of money, or
> > >the call time limit is exceeded, the call could be terminated using this
> > >Reason.
> > >
> > >
> > >406 Client error
> > >
> > >This would be used if the client, for any internal reason, must
> > >terminate the call. Load balancing is one example where this could be
> > >used. Another example is if the call state somehow gets messed up in the
> > >client, and it deciedes to release the call.
> > >
> > >This Reason could also be used, for the same purpose, by proxies, or
> > >there could be a separate Reason value for those (407 Proxy error)
> > >
> > >A couple of issues, though:
> > >
> > >
> > >Issue 1: Use existing codes
> > >
> > >Before we start defining a new set of codes, I DO think that we should
> > >have a look at the existing response codes, and see if they (or part of
> > >them) can be used for the Reason header. Then, if we define new codes,
> > >they may also be used for responses.
> >
> > One of the key values of the reason code is that it can be sent in forward
> > requests, not just backward responses.
> >
> > >Issue 2: ISUP-SIP
> > >
> > >I assume this COULD also affect the ISUP-SIP mapping, IF different
> > >Reason header values will produce different mapping. I guess Gonzalo can
> > >comment on this.
> > >
> > >
> > >Regards,
> > >
> > >Christer Holmberg
> > >Ericsson Finland
> > >
> > >
> > >
> > >
> > >
> > >Jonathan Rosenberg wrote:
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> > > > > Sent: Monday, June 25, 2001 5:04 PM
> > > > > To: Jonathan Rosenberg; 'Barry Desborough'; 'Paul Kyzivat'
> > > > > Cc: sip@ietf.org
> > > > > Subject: reason code in BYE/CANCEL (was [Sip-implementors] another
> > > > > problem related to multiple call l egs at UAC)
> > > > >
> > > > >
> > > > >
> > > > > Jonathan Rosenberg wrote:
> > > > > >
> > > > > >
> > > > > >  Moving from sip-implementors to sip since there are some
> > > > > open issues and
> > > > > > changes to bis in here.
> > > > > >
> > > > > >
> > > > >
> > > > > 
> > > > > > Barry Desborough wrote:
> > > > > >
> > > > > > > I also agree that encoded reasons should be added to BYEs and
> > > > > > > CANCELs such
> > > > > > > that a PSDN gateway can map them to and from Q.931 cause codes.
> > > > > >
> > > > > > I also like these BYE reasons. This has come up countless
> > > > > times. Its also
> > > > > > helpful in CANCEL, to know whether a call was cancelled
> > > > > because the caller
> > > > > > aborted, or because some other branch picked up (the former
> > > > > would generate
> > > > > a
> > > > > > missed call entry in a call log, whilst the other won't). I
> > > > > don't think
> > > > > > Warning is right, but some kind of header that conveys both a
> > > > > > machine-interpretable and human-interpretable value would be good.
> > > > > >
> > > > > How about a "Reason" request header (or is that already
> > > > > defined elswhere)
> > > > > that uses the same format as the Warning header?
> > > > >
> > > > >         Reason        =  "Reason" ":" 1#reason-value
> > > > >         reason-value  =  reason-code SP reason-agent SP reason-text
> > > > >         reason-code   =  3DIGIT
> > > > >         reason-agent  =  host [ ":" port ]
> > > > >                           ;  the name of the server adding
> > > > >                           ;  the Reason header, for use in
> > > > > tracing/debugging
> > > > >         reason-text   =  quoted-string
> > > > >
> > > > >
> > > > >
> > > >
> > > > Reason is not used. Seems reasonable for the header name.
> > > >
> > > > I'm not sure the reason-agent is needed.
> > > >
> > > > The trick is defining the codes. A few I can think of:
> > > >
> > > > 400 Caller hung up
> > > >
> > > >   this would be in a CANCEL if the UAC hangs up before an INVITE
> > > generates a
> > > > final response, or in a BYE at any point later. Its the normal call
> > > > termination case.
> > > >
> > > > 401 INVITE succeeded elsewhere
> > > >
> > > >   this would be in a CANCEL generated because an INVITE generated a 2xx on
> > > > another branch.
> > > >
> > > > 402 media stream failure
> > > >
> > > >   this would be in a BYE that was sent because there was some failure
> > > in the
> > > > media streams or something like that.
> > > >
> > > > other suggestions?
> > > >
> > > > -Jonathan R.
> > > >
> > > > ---
> > > > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > > > Chief Scientist                             First Floor
> > > > dynamicsoft                                 East Hanover, NJ 07936
> > > > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > > > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > > > http://www.dynamicsoft.com
> > > >
> > > > _______________________________________________
> > > > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP Protocol
> > > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > > Use sipping@ietf.org for new developments on the application of sip

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

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


From sip-admin@ietf.org  Thu Jun 28 11:15:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14234;
	Thu, 28 Jun 2001 11:15:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14135;
	Thu, 28 Jun 2001 11:06:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14106
	for ; Thu, 28 Jun 2001 11:06:32 -0400 (EDT)
Received: from commserver.iperia.com ([63.84.167.3])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07195
	for ; Thu, 28 Jun 2001 11:05:49 -0400 (EDT)
Received: by commserver.erictest.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 11:02:49 -0400
Message-ID: <1A69639B9B6AD511812B00B0D0DE19F60A2EFD@commserver.erictest.com>
From: Gordon Ledgard 
To: "'Henning Schulzrinne'" ,
        Jonathan Rosenberg
	 
Cc: "'Hidefumi Nakamura'" ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Congestion control
Date: Thu, 28 Jun 2001 10:02:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org


Henning wrote -

>> 1. 503 is the appropriate response to indicate congestion or any other
>> resource constraints that make a server temporarily congested.
>> 
>> 2. A client receiving a 503 SHOULD attempt to contact an alternate
server.
>> 
>> 3. A server should generate and/or forward a 503 upstream only if all
>> requests that would reach the server cannot be serviced. This means that
the
>> server itself is congested, or every possible next-hop it can route to is
>> congested (which is fairly unlikely but can happen in certain
>> configurations).

>Just in case, as I'm not sure I'm interpreting item 3 correctly:

>A 503 is a statement of why the current request failed. "Past
>performance is not a guarantee of future results", or some such. Thus, a
>503 does not indicate that "all requests that *would* reach the server
>cannot be serviced", only that the current request couldn't be serviced
>due to overload. This doesn't mean that another request sent in the next
>millisecond would also fail.

>503 would only be returned by a forking proxy if that's the "best"
>response. If one downstream server returns a 517 (imaginary) and another
>a 503, a 503 is returned. Thus, it is not necessary that *all* next-hops
>return 503 for a 503 to be returned. Normally, the proxy would retry
>alternate servers on a fork that returned a 503, so it does mean that at
>least one branch is unreachable due to congestion and that others
>returned "worse" error codes.

I think item three is supposed to touch down on elements like load
balancers,
or failover control units. Picture an invite landing on a unit that
balances between several other servers, or better yet, say there was
some kind of fanout such that each node had a set of possibilities for
routing. When a 503 is returned, you are correct that the receiver of the
503 cannot know for how long the congestion will last in the sender, but
it may have to assume. A machine which is balancing requests will need
an algorithm inside it that says something to the effect of, "if a server
returns a 503 to me, I need to back off and wait X until I try again."
The choice of "X" may even need to be empirical, or calculated in an
active network to arrive at a resonable number, since the balancer cannot
know the recovery time of all the servers it might be connected to.

But the main point of item three is that the balancer's algorithm must
also have logic that says, in effect, "When I have tried all routes going
out of me, and have received 503's (or equivalents) from all of them,
I must assume that I am, and will remain, congested myself for some
period of time. So rather that keep hunting for routes out of myself
tell the caller to find another route."

Anyway... that's how I interpret it.

Gordon Ledgard

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


From sip-admin@ietf.org  Thu Jun 28 11:28:16 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22993;
	Thu, 28 Jun 2001 11:28:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14847;
	Thu, 28 Jun 2001 11:19:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14824
	for ; Thu, 28 Jun 2001 11:19:20 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16088
	for ; Thu, 28 Jun 2001 11:18:37 -0400 (EDT)
Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA21807;
	Thu, 28 Jun 2001 11:19:13 -0400 (EDT)
Message-ID: <3B3B4AF1.E0AF9383@cs.columbia.edu>
Date: Thu, 28 Jun 2001 11:19:13 -0400
From: "Henning G. Schulzrinne" 
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-2cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Gordon Ledgard 
CC: Jonathan Rosenberg ,
        "'Hidefumi Nakamura'" ,
        "'sip@ietf.org'" 
Subject: Re: [SIP] Congestion control
References: <1A69639B9B6AD511812B00B0D0DE19F60A2EFD@commserver.erictest.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

The point I was trying to make is that I see no reason to treat 503 as a
special case. I would like to avoid lots of rules and regulations for
each response code, for things that are essentially implementation
issues. We do have the Retry-After header if the server wants to pace
requests by a client, e.g., for some kind of mass calling event where it
knows that things are hopeless for the next hour. However, none of this
belongs in the spec.

Gordon Ledgard wrote:
> 
> Henning wrote -
> 
> >> 1. 503 is the appropriate response to indicate congestion or any other
> >> resource constraints that make a server temporarily congested.
> >>
> >> 2. A client receiving a 503 SHOULD attempt to contact an alternate
> server.
> >>
> >> 3. A server should generate and/or forward a 503 upstream only if all
> >> requests that would reach the server cannot be serviced. This means that
> the
> >> server itself is congested, or every possible next-hop it can route to is
> >> congested (which is fairly unlikely but can happen in certain
> >> configurations).
> 
> >Just in case, as I'm not sure I'm interpreting item 3 correctly:
> 
> >A 503 is a statement of why the current request failed. "Past
> >performance is not a guarantee of future results", or some such. Thus, a
> >503 does not indicate that "all requests that *would* reach the server
> >cannot be serviced", only that the current request couldn't be serviced
> >due to overload. This doesn't mean that another request sent in the next
> >millisecond would also fail.
> 
> >503 would only be returned by a forking proxy if that's the "best"
> >response. If one downstream server returns a 517 (imaginary) and another
> >a 503, a 503 is returned. Thus, it is not necessary that *all* next-hops
> >return 503 for a 503 to be returned. Normally, the proxy would retry
> >alternate servers on a fork that returned a 503, so it does mean that at
> >least one branch is unreachable due to congestion and that others
> >returned "worse" error codes.
> 
> I think item three is supposed to touch down on elements like load
> balancers,
> or failover control units. Picture an invite landing on a unit that
> balances between several other servers, or better yet, say there was
> some kind of fanout such that each node had a set of possibilities for
> routing. When a 503 is returned, you are correct that the receiver of the
> 503 cannot know for how long the congestion will last in the sender, but
> it may have to assume. A machine which is balancing requests will need
> an algorithm inside it that says something to the effect of, "if a server
> returns a 503 to me, I need to back off and wait X until I try again."
> The choice of "X" may even need to be empirical, or calculated in an
> active network to arrive at a resonable number, since the balancer cannot
> know the recovery time of all the servers it might be connected to.
> 
> But the main point of item three is that the balancer's algorithm must
> also have logic that says, in effect, "When I have tried all routes going
> out of me, and have received 503's (or equivalents) from all of them,
> I must assume that I am, and will remain, congested myself for some
> period of time. So rather that keep hunting for routes out of myself
> tell the caller to find another route."
> 
> Anyway... that's how I interpret it.
> 
> Gordon Ledgard

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

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


From sip-admin@ietf.org  Thu Jun 28 11:43:55 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04430;
	Thu, 28 Jun 2001 11:43:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15849;
	Thu, 28 Jun 2001 11:34:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15819
	for ; Thu, 28 Jun 2001 11:34:20 -0400 (EDT)
Received: from commserver.iperia.com ([63.84.167.3])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26953
	for ; Thu, 28 Jun 2001 11:33:38 -0400 (EDT)
Received: by commserver.erictest.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 11:32:14 -0400
Message-ID: <1A69639B9B6AD511812B00B0D0DE19F60A2F00@commserver.erictest.com>
From: Gordon Ledgard 
To: "'Henning G. Schulzrinne'" ,
        Gordon Ledgard
	 
Cc: Jonathan Rosenberg ,
        "'Hidefumi Nakamura'"
	 ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Congestion control
Date: Thu, 28 Jun 2001 11:32:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Agreed.

-----Original Message-----
From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Thursday, June 28, 2001 11:19 AM
To: Gordon Ledgard
Cc: Jonathan Rosenberg; 'Hidefumi Nakamura'; 'sip@ietf.org'
Subject: Re: [SIP] Congestion control


The point I was trying to make is that I see no reason to treat 503 as a
special case. I would like to avoid lots of rules and regulations for
each response code, for things that are essentially implementation
issues. We do have the Retry-After header if the server wants to pace
requests by a client, e.g., for some kind of mass calling event where it
knows that things are hopeless for the next hour. However, none of this
belongs in the spec.

Gordon Ledgard wrote:
> 
> Henning wrote -
> 
> >> 1. 503 is the appropriate response to indicate congestion or any other
> >> resource constraints that make a server temporarily congested.
> >>
> >> 2. A client receiving a 503 SHOULD attempt to contact an alternate
> server.
> >>
> >> 3. A server should generate and/or forward a 503 upstream only if all
> >> requests that would reach the server cannot be serviced. This means
that
> the
> >> server itself is congested, or every possible next-hop it can route to
is
> >> congested (which is fairly unlikely but can happen in certain
> >> configurations).
> 
> >Just in case, as I'm not sure I'm interpreting item 3 correctly:
> 
> >A 503 is a statement of why the current request failed. "Past
> >performance is not a guarantee of future results", or some such. Thus, a
> >503 does not indicate that "all requests that *would* reach the server
> >cannot be serviced", only that the current request couldn't be serviced
> >due to overload. This doesn't mean that another request sent in the next
> >millisecond would also fail.
> 
> >503 would only be returned by a forking proxy if that's the "best"
> >response. If one downstream server returns a 517 (imaginary) and another
> >a 503, a 503 is returned. Thus, it is not necessary that *all* next-hops
> >return 503 for a 503 to be returned. Normally, the proxy would retry
> >alternate servers on a fork that returned a 503, so it does mean that at
> >least one branch is unreachable due to congestion and that others
> >returned "worse" error codes.
> 
> I think item three is supposed to touch down on elements like load
> balancers,
> or failover control units. Picture an invite landing on a unit that
> balances between several other servers, or better yet, say there was
> some kind of fanout such that each node had a set of possibilities for
> routing. When a 503 is returned, you are correct that the receiver of the
> 503 cannot know for how long the congestion will last in the sender, but
> it may have to assume. A machine which is balancing requests will need
> an algorithm inside it that says something to the effect of, "if a server
> returns a 503 to me, I need to back off and wait X until I try again."
> The choice of "X" may even need to be empirical, or calculated in an
> active network to arrive at a resonable number, since the balancer cannot
> know the recovery time of all the servers it might be connected to.
> 
> But the main point of item three is that the balancer's algorithm must
> also have logic that says, in effect, "When I have tried all routes going
> out of me, and have received 503's (or equivalents) from all of them,
> I must assume that I am, and will remain, congested myself for some
> period of time. So rather that keep hunting for routes out of myself
> tell the caller to find another route."
> 
> Anyway... that's how I interpret it.
> 
> Gordon Ledgard

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

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


From sip-admin@ietf.org  Thu Jun 28 13:12:09 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04742;
	Thu, 28 Jun 2001 13:12:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19890;
	Thu, 28 Jun 2001 12:59:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19860
	for ; Thu, 28 Jun 2001 12:59:10 -0400 (EDT)
Received: from mailweb26.rediffmail.com (IDENT:qmailr@[203.199.83.30])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27224
	for ; Thu, 28 Jun 2001 12:58:28 -0400 (EDT)
Received: (qmail 15199 invoked by uid 510); 28 Jun 2001 17:05:13 -0000
Date: 28 Jun 2001 17:05:13 -0000
Message-ID: <20010628170513.15198.qmail@mailweb26.rediffmail.com>
Received: from unknown (210.214.208.8) by rediffmail.com via HTTP; 28 Jun 2001 17:05:13 -0000
MIME-Version: 1.0
To: "bpenfield@acmepacket.com" 
CC: "sip@ietf.org" 
From: "Ashhar Farhan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors] another  problem related to multiple call l egs at UAC)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

a message code alone is a better option rather than a text alongwith it too. the reason is internationalism.

telephony, by definition involves spanning distances and geographys and cultures. therefore, an english message explaining the reason for call rejection (like 'Needs Payment') may not make sense to an arab or a japanese. however, reason code is easily localised to local dialects and sensitivities. (in my city hyderabad, getting a message like 'you dont have money in the bank to make this call' will be considered very rude).

if the text message that goes along with a message is customisable from message to message, it will effect definitive interpretation of the reason code. on the other hand, if the text message is not adding more intelligence to the reason code, it is best to localy generate it on the UA.

as per the original rosenberg-henning vision, SIP is not concerned with presentation layer, therefore, i dont see the need for text messages. For instance, how do you interpret these text messages to a display-less device like a POTS phone?

- farhan@hotfoon.com



____________________________________________________
Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm




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


From sip-admin@ietf.org  Thu Jun 28 13:37:43 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23832;
	Thu, 28 Jun 2001 13:37:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21548;
	Thu, 28 Jun 2001 13:29:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21517
	for ; Thu, 28 Jun 2001 13:29:55 -0400 (EDT)
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17473
	for ; Thu, 28 Jun 2001 13:29:13 -0400 (EDT)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA16264; Thu, 28 Jun 2001 13:29:23 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AJM11068;
	Thu, 28 Jun 2001 13:29:15 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010628132637.00b66bb0@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 28 Jun 2001 13:31:12 -0400
To: "Ashhar Farhan" 
From: Michael Hammer 
Subject: Re: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors]
  another  problem related to multiple call l egs at UAC)
Cc: "bpenfield@acmepacket.com" ,
        "sip@ietf.org" 
In-Reply-To: <20010628170513.15198.qmail@mailweb26.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Do you mean to say that all such local-specific messages must be hard-coded 
into the end-device?  Could the protocol define a means of carrying a 
message, but leave the content to be generated by a geographically local 
proxy serving the end user?  Such a display text could be provided when the 
terminal can do such and ignored otherwise.  For POTS phone it could be 
converted to voice.  For more sophisticated terminals, it could be a 
voice-mail file.

Mike

At 05:05 PM 6/28/2001 +0000, Ashhar Farhan wrote:
>a message code alone is a better option rather than a text alongwith it 
>too. the reason is internationalism.
>
>telephony, by definition involves spanning distances and geographys and 
>cultures. therefore, an english message explaining the reason for call 
>rejection (like 'Needs Payment') may not make sense to an arab or a 
>japanese. however, reason code is easily localised to local dialects and 
>sensitivities. (in my city hyderabad, getting a message like 'you dont 
>have money in the bank to make this call' will be considered very rude).
>
>if the text message that goes along with a message is customisable from 
>message to message, it will effect definitive interpretation of the reason 
>code. on the other hand, if the text message is not adding more 
>intelligence to the reason code, it is best to localy generate it on the UA.
>
>as per the original rosenberg-henning vision, SIP is not concerned with 
>presentation layer, therefore, i dont see the need for text messages. For 
>instance, how do you interpret these text messages to a display-less 
>device like a POTS phone?
>
>- farhan@hotfoon.com
>
>
>
>____________________________________________________
>Buy Feng Shui Package for Rs. 151/- only, at 
>http://shopping.rediff.com/shopping/fengshui_mailer.htm
>
>
>
>
>_______________________________________________
>Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


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


From sip-admin@ietf.org  Thu Jun 28 14:02:07 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11605;
	Thu, 28 Jun 2001 14:02:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22637;
	Thu, 28 Jun 2001 13:57:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22607
	for ; Thu, 28 Jun 2001 13:57:04 -0400 (EDT)
Received: from mailweb19.rediffmail.com (IDENT:qmailr@[203.199.83.143])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07320
	for ; Thu, 28 Jun 2001 13:56:19 -0400 (EDT)
Received: (qmail 13254 invoked by uid 510); 28 Jun 2001 18:02:13 -0000
Date: 28 Jun 2001 18:02:13 -0000
Message-ID: <20010628180213.13253.qmail@mailweb19.rediffmail.com>
Received: from unknown (203.197.251.9) by rediffmail.com via HTTP; 28 Jun 2001 18:02:13 -0000
MIME-Version: 1.0
To: "mhammer@cisco.com" 
Subject:  Re: Re: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors] another  problem related to multiple call l egs at UAC)
CC: "bpenfield@acmepacket.com" ,
        "sip@ietf.org" 
From: "Ashhar Farhan" 
Content-ID: 
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

>Do you mean to say that all such local-specific messages must be hard-coded 
into the end-device?  

yes, but that is not a recommendation, it could also be that a service provider could translate it into an appropriate MESSAGE.

- farhan@hotfoon.com

____________________________________________________
Buy Feng Shui Package for Rs. 151/- only, at http://shopping.rediff.com/shopping/fengshui_mailer.htm




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


From sip-admin@lists.bell-labs.com  Thu Jun 28 14:33:30 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03943
	for ; Thu, 28 Jun 2001 14:33:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 643F044337; Thu, 28 Jun 2001 14:34:07 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from exmail.lboard.com (16.node.lboard.com [204.17.219.16])
	by lists.bell-labs.com (Postfix) with ESMTP id 567C044336
	for ; Thu, 28 Jun 2001 14:33:35 -0400 (EDT)
Received: by exmail.lboard.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 11:33:00 -0700
Message-ID: 
From: Subir Saha 
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] [SIP]draft-ietf-sip-state-00.txt....
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 28 Jun 2001 11:32:57 -0700

Can any one please tell me status of the  ID: draft-ietf-sip-state-00.txt?
Thanks in advance.

Subir Saha, Ph.D.
Senior Product Architect
LongBoard Inc. 

-----Original Message-----
From: Wayne Cutler [mailto:Wayne.Cutler@marconi.com]
Sent: Wednesday, June 27, 2001 1:09 AM
To: Mark Watson
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Re: Re Mapping of ISUP overlap signalling to SIP




Mark,

Yes, you're correct that my proposal does assume that the i/c GW can
identify
the o/g GW.

So, whilst not being a general case, it is still a valid scenario for a
limited
applicability.

I agree that there hasn't been a conclusion and as it stands it appears that
ETSI ISUP gets forced to work
en-bloc by default.

Regards, Wayne.








"Mark Watson"  on 26/06/2001 17:32:28
 

 

 



                                                              
                                                              
                                                              
 To:      Wayne Cutler/MAIN/MC1@MCMAIN, Gonzalo Camarillo     
                           
                                                              
 cc:      sip@lists.bell-labs.com                             
                                                              
                                                              
                                                              
 Subject: RE: [SIP] Re: Re Mapping of ISUP overlap signalling 
          to SIP                                              
                                                              







Wayne,

Your proposal presumes that the incoming PSTN/SIP gateway can identify the
outgoing SIP/PSTN gateway. If this knowledge is instead in an intermediate
SIP proxy, then the digit information will need to be in the SIP headers,
because the proxy will not examine the ISUP payload.

IMO, once the INVITE has reached the o/g SIP/PSTN gateway, it would be of
value for subsequent digits to travel in INFOs (a backwards indication that
this was allowed would be needed at this point).

But as Gonzalo says this has been discussed ad nauseum on this list, to no
clear conclusion AFAIK.

Regards,

Mark Watson
Nortel Networks



> -----Original Message-----
> From: Wayne Cutler [mailto:Wayne.Cutler@marconi.com]
> Sent: 26 June 2001 13:19
> To: Gonzalo Camarillo
> Cc: sip@lists.bell-labs.com
> Subject: [SIP] Re: Re Mapping of ISUP overlap signalling to SIP
>
>
>
>
> >Hello,
>
> >There have been millons of mails sent to the mailins list in the past
> >discussing exactly what you are proposing. Besides, this has been
> >presented in several WG meetings.
>
> >Feel free to check the archives to find more information about this.
>
> Whilst here has been a good deal of discussion on the general
> topic (over at
> least 3 threads), the vast majority
> were concerned with including the overlap digits in various
> SIP headers.
> Therefore, there hasn't been a great deal
> of discussion about making the SIP headers independent of the
> overlap digits. I
> do recall your presentation in the last
> WG meeting but that suggested sending multiple INVITEs and
> (as I recall) there
> was nothing said about the option of
> making the SIP headers independent of the overlap digits.
>
> So, for limited scenarios, I fail to see why it is
> wrong/improper to make the
> headers independent of the overlap digits. Such an
> approach is workable and  does not require any changes to the
> SIP protocol. So
> why can't it be added as another option, with a
> suitable health warning about its limited applicability?
>
> Wayne.
>
>
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
>


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


From sip-admin@ietf.org  Thu Jun 28 14:51:19 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16503;
	Thu, 28 Jun 2001 14:51:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24940;
	Thu, 28 Jun 2001 14:42:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24911
	for ; Thu, 28 Jun 2001 14:42:32 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09944
	for ; Thu, 28 Jun 2001 14:41:50 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id AA1AAED0252; Thu, 28 Jun 2001 14:40:26 -0400
Message-ID: <01d601c10000$c2f4aee0$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: "Ashhar Farhan" 
Cc: 
References: <20010628170513.15198.qmail@mailweb26.rediffmail.com>
Date: Thu, 28 Jun 2001 14:33:01 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors] another  problem related to multiple call l egs at UAC)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

All good points. The Reason header is modeled after the Warning response
header which includes both a numeric code and text. Both of these match the
format of the status line of a response. The text is just informational. The
numeric code is what SIP servers should look at and act on.

(-:bob

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

----- Original Message -----
From: "Ashhar Farhan" 
To: 
Cc: 
Sent: Thursday, June 28, 2001 1:05 PM
Subject: Re: reason code in BYE/CANCEL (was[Sip-implementors] another
problem related to multiple call l egs at UAC)


> a message code alone is a better option rather than a text alongwith it
too. the reason is internationalism.
>
> telephony, by definition involves spanning distances and geographys and
cultures. therefore, an english message explaining the reason for call
rejection (like 'Needs Payment') may not make sense to an arab or a
japanese. however, reason code is easily localised to local dialects and
sensitivities. (in my city hyderabad, getting a message like 'you dont have
money in the bank to make this call' will be considered very rude).
>
> if the text message that goes along with a message is customisable from
message to message, it will effect definitive interpretation of the reason
code. on the other hand, if the text message is not adding more intelligence
to the reason code, it is best to localy generate it on the UA.
>
> as per the original rosenberg-henning vision, SIP is not concerned with
presentation layer, therefore, i dont see the need for text messages. For
instance, how do you interpret these text messages to a display-less device
like a POTS phone?
>
> - farhan@hotfoon.com
>
>
>
> ____________________________________________________
> Buy Feng Shui Package for Rs. 151/- only, at
http://shopping.rediff.com/shopping/fengshui_mailer.htm
>
>
>
>


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


From sip-admin@lists.bell-labs.com  Thu Jun 28 14:59:30 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22353
	for ; Thu, 28 Jun 2001 14:59:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 742044433C; Thu, 28 Jun 2001 15:00:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 9A92A44336
	for ; Thu, 28 Jun 2001 14:59:53 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA00940;
	Thu, 28 Jun 2001 15:04:00 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 14:59:52 -0400
Message-ID: 
From: Rakesh Shah 
To: "'Subir Saha'" , sip@lists.bell-labs.com
Subject: RE: [SIP] [SIP]draft-ietf-sip-state-00.txt....
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 28 Jun 2001 14:59:51 -0400

Please check out http://www.softarmor.com/sipwg/ under drafts or last call
info to check on draft status. This draft is now at revision -01. It is
ready for last call.

Rakesh

-----Original Message-----
From: Subir Saha [mailto:ssaha@lboard.com]
Sent: Thursday, June 28, 2001 2:33 PM
To: sip@lists.bell-labs.com
Subject: [SIP] [SIP]draft-ietf-sip-state-00.txt....


Can any one please tell me status of the  ID: draft-ietf-sip-state-00.txt?
Thanks in advance.

Subir Saha, Ph.D.
Senior Product Architect
LongBoard Inc. 

-----Original Message-----
From: Wayne Cutler [mailto:Wayne.Cutler@marconi.com]
Sent: Wednesday, June 27, 2001 1:09 AM
To: Mark Watson
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Re: Re Mapping of ISUP overlap signalling to SIP




Mark,

Yes, you're correct that my proposal does assume that the i/c GW can
identify
the o/g GW.

So, whilst not being a general case, it is still a valid scenario for a
limited
applicability.

I agree that there hasn't been a conclusion and as it stands it appears that
ETSI ISUP gets forced to work
en-bloc by default.

Regards, Wayne.








"Mark Watson"  on 26/06/2001 17:32:28
 

 

 



                                                              
                                                              
                                                              
 To:      Wayne Cutler/MAIN/MC1@MCMAIN, Gonzalo Camarillo     
                           
                                                              
 cc:      sip@lists.bell-labs.com                             
                                                              
                                                              
                                                              
 Subject: RE: [SIP] Re: Re Mapping of ISUP overlap signalling 
          to SIP                                              
                                                              







Wayne,

Your proposal presumes that the incoming PSTN/SIP gateway can identify the
outgoing SIP/PSTN gateway. If this knowledge is instead in an intermediate
SIP proxy, then the digit information will need to be in the SIP headers,
because the proxy will not examine the ISUP payload.

IMO, once the INVITE has reached the o/g SIP/PSTN gateway, it would be of
value for subsequent digits to travel in INFOs (a backwards indication that
this was allowed would be needed at this point).

But as Gonzalo says this has been discussed ad nauseum on this list, to no
clear conclusion AFAIK.

Regards,

Mark Watson
Nortel Networks



> -----Original Message-----
> From: Wayne Cutler [mailto:Wayne.Cutler@marconi.com]
> Sent: 26 June 2001 13:19
> To: Gonzalo Camarillo
> Cc: sip@lists.bell-labs.com
> Subject: [SIP] Re: Re Mapping of ISUP overlap signalling to SIP
>
>
>
>
> >Hello,
>
> >There have been millons of mails sent to the mailins list in the past
> >discussing exactly what you are proposing. Besides, this has been
> >presented in several WG meetings.
>
> >Feel free to check the archives to find more information about this.
>
> Whilst here has been a good deal of discussion on the general
> topic (over at
> least 3 threads), the vast majority
> were concerned with including the overlap digits in various
> SIP headers.
> Therefore, there hasn't been a great deal
> of discussion about making the SIP headers independent of the
> overlap digits. I
> do recall your presentation in the last
> WG meeting but that suggested sending multiple INVITEs and
> (as I recall) there
> was nothing said about the option of
> making the SIP headers independent of the overlap digits.
>
> So, for limited scenarios, I fail to see why it is
> wrong/improper to make the
> headers independent of the overlap digits. Such an
> approach is workable and  does not require any changes to the
> SIP protocol. So
> why can't it be added as another option, with a
> suitable health warning about its limited applicability?
>
> Wayne.
>
>
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
>


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

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


From sip-admin@ietf.org  Thu Jun 28 15:00:18 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22846;
	Thu, 28 Jun 2001 15:00:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25260;
	Thu, 28 Jun 2001 14:52:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25231
	for ; Thu, 28 Jun 2001 14:52:45 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17052
	for ; Thu, 28 Jun 2001 14:52:03 -0400 (EDT)
Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5SIqbN20236;
	Thu, 28 Jun 2001 20:52:37 +0200 (MEST)
Received: from lmf.ericsson.se (racom-bo-19.bo.us.am.ericsson.se [138.85.235.249])
	by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id UAA01131;
	Thu, 28 Jun 2001 20:53:10 +0200 (MET DST)
Message-ID: <3B3B7EF0.6477BA0C@lmf.ericsson.se>
Date: Thu, 28 Jun 2001 22:01:04 +0300
From: Gonzalo Camarillo 
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org, mmusic 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Two SDP issues
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

A couple of SDP issues:

1) I recall that we discussed this issue in an IETF meeting, but I am
not aware of the result of the discussion.

Let's say that user A sends an INVITE with two m lines. One for audio
(PCM codec, for instance) and another for DTMF tones.

The receiver (user B), due to any reason, cannot send DTMF tones, but he
can receive them. Can user B add a=recvonly for that m line to the SDP
that he returns in the 200 OK?


2) If I want to stop receiving media (put a call on hold) I send an SDP
with c=0.0.0.0. However, I can still send media. In which address will I
receive RTCP? Should the other party remember my previous c line on
order to send me RTCP?

Regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

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


From sip-admin@ietf.org  Thu Jun 28 15:38:15 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19645;
	Thu, 28 Jun 2001 15:38:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26907;
	Thu, 28 Jun 2001 15:32:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26876
	for ; Thu, 28 Jun 2001 15:32:07 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14843
	for ; Thu, 28 Jun 2001 15:31:22 -0400 (EDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5SJTt426543;
	Thu, 28 Jun 2001 15:29:55 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-91.cisco.com [161.44.241.91])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ABP00437 (AUTH pkyzivat);
	Thu, 28 Jun 2001 15:31:23 -0400 (EDT)
Message-ID: <3B3B8502.20C5A087@cisco.com>
Date: Thu, 28 Jun 2001 15:26:58 -0400
From: Paul Kyzivat 
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gonzalo Camarillo 
CC: sip@ietf.org, mmusic 
Subject: Re: [Sip] Two SDP issues
References: <3B3B7EF0.6477BA0C@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Interesting questions!

In (2), assume for a moment that your suggestion to remember the
prior c= line for RTCP is adopted. Then what happens if I want to
invite on hold, or accept an invitation on hold? (I believe this
is legal, and I have from time to time seen a call sequence that
did it.)

	Paul Kyzivat
	Cisco Systems

Gonzalo Camarillo wrote:
> 
> Hello,
> 
> A couple of SDP issues:
> 
> 1) I recall that we discussed this issue in an IETF meeting, but I am
> not aware of the result of the discussion.
> 
> Let's say that user A sends an INVITE with two m lines. One for audio
> (PCM codec, for instance) and another for DTMF tones.
> 
> The receiver (user B), due to any reason, cannot send DTMF tones, but he
> can receive them. Can user B add a=recvonly for that m line to the SDP
> that he returns in the 200 OK?
> 
> 2) If I want to stop receiving media (put a call on hold) I send an SDP
> with c=0.0.0.0. However, I can still send media. In which address will I
> receive RTCP? Should the other party remember my previous c line on
> order to send me RTCP?
> 
> Regards,
> 
> Gonzalo
> --
> Gonzalo Camarillo                    Phone :   +1 212 939 71 71
> Columbia University                  Mobile:  +358 40 702 35 35
> 472 Computer Science Building        Fax   :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY 10027
> USA                              Gonzalo.Camarillo@ericsson.com
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

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


From sip-admin@ietf.org  Thu Jun 28 16:07:56 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10346;
	Thu, 28 Jun 2001 16:07:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27870;
	Thu, 28 Jun 2001 16:02:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27839
	for ; Thu, 28 Jun 2001 16:02:55 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06315
	for ; Thu, 28 Jun 2001 16:02:12 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA01838
	for ; Thu, 28 Jun 2001 16:07:01 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 28 Jun 2001 16:02:52 -0400
Message-ID: 
From: Rakesh Shah 
To: "SIPWG Mailing List (E-mail)" 
Date: Thu, 28 Jun 2001 16:02:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] NITS REVIEWER NEEDED - draft-ietf-sip-callerprefs-04.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

The subject draft is up for WGLC!

While there is a pool of volunteers available to take on the NITS Review, I
would like to open the opportunity to whomever has an interest particularly
for this draft.

Please respond to me by 3-Jul-01 if you are interested in taking on this
NITS Review. If I do not get any responses by then I will select someone off
of my volunteer list.

Don't forget, all of the information you need, including the draft itself is
available at http://www.softarmor.com/sipwg/.

Regards,

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


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


From sip-admin@ietf.org  Fri Jun 29 05:01:33 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01774;
	Fri, 29 Jun 2001 05:01:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00303;
	Fri, 29 Jun 2001 04:47:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00272
	for ; Fri, 29 Jun 2001 04:47:00 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21405
	for ; Fri, 29 Jun 2001 04:46:16 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA05764;
	Fri, 29 Jun 2001 04:51:02 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 29 Jun 2001 04:46:52 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Gonzalo Camarillo'" , sip@ietf.org,
        mmusic 
Subject: RE: [Sip] Two SDP issues
Date: Fri, 29 Jun 2001 04:46:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Thursday, June 28, 2001 3:01 PM
> To: sip@ietf.org; mmusic
> Subject: [Sip] Two SDP issues
> 
> 
> Hello,
> 
> A couple of SDP issues:
> 
> 1) I recall that we discussed this issue in an IETF meeting, but I am
> not aware of the result of the discussion.
> 
> Let's say that user A sends an INVITE with two m lines. One for audio
> (PCM codec, for instance) and another for DTMF tones.
> 
> The receiver (user B), due to any reason, cannot send DTMF 
> tones, but he
> can receive them. Can user B add a=recvonly for that m line to the SDP
> that he returns in the 200 OK?

Yes. From bis-03:

If an offered media stream is listed as sendrecv (or contains no direction
attribute, in which case it is
sendrecv by default), the corresponding stream in the answer MAY be marked
as sendonly, recvonly, or
sendrecv.


> 
> 
> 2) If I want to stop receiving media (put a call on hold) I 
> send an SDP
> with c=0.0.0.0. However, I can still send media. In which 
> address will I
> receive RTCP? Should the other party remember my previous c line on
> order to send me RTCP?

Now, this is a really good question. Remembering the old IP address is a bad
thing, I think. There may not be one, and you really want each INVITE to
contain the full state for the media streams.

At the moment, the result is that you won't get RTCP or media if you put
someone on hold, even if you are still sending media. This is not
catastrophic, but is not the right thing to do. 

There are a few options:

1. don't worry about this problem
2. define an sdp attribute that indicates the address to receive rtcp
3. define an alternate "hold" mechanism that, instead of setting the
connection IP to 0.0.0.0, simply sets the stream to sendonly and has some
additional attribute to convey "hold"

Maybe there are others. The third approach is sort-of backwards compatible,
but won't work with clients that take explicit actions as a result of
realizing that the stream is on hold.



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

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


From sip-admin@ietf.org  Fri Jun 29 05:05:42 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04675;
	Fri, 29 Jun 2001 05:05:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00747;
	Fri, 29 Jun 2001 04:59:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00720
	for ; Fri, 29 Jun 2001 04:59:36 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00016
	for ; Fri, 29 Jun 2001 04:58:51 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id FAA05852;
	Fri, 29 Jun 2001 05:03:12 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 29 Jun 2001 04:59:02 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Gonzalo Camarillo'" ,
        Ashhar Farhan
	 
Cc: christer.holmberg@lmf.ericsson.se, mhammer@cisco.com,
        Jonathan Rosenberg , bpenfield@acmepacket.com,
        BarryD@vegastream.com, pkyzivat@cisco.com, sip@ietf.org
Date: Fri, 29 Jun 2001 04:58:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [Sip] RE: reason code in BYE/CANCEL (was[Sip-implementors] another  pro
 blem  related to multiple call l egs at UAC)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Thursday, June 28, 2001 10:49 AM
> To: Ashhar Farhan
> Cc: christer.holmberg@lmf.ericsson.se; mhammer@cisco.com;
> jdrosen@dynamicsoft.com; bpenfield@acmepacket.com;
> BarryD@vegastream.com; pkyzivat@cisco.com; sip@ietf.org
> Subject: Re: reason code in BYE/CANCEL (was[Sip-implementors] another
> problem related to multiple call l egs at UAC)
> 
> 
> As I said in a previous mail, we already have a set of reason phrases
> and reason codes used in responses. Since it is very likely 
> that in 3pcc
> situations the reason phrase and the status codes of a response is
> mapped into the BYEs' reason phrase and status code, I would 
> suggest to
> use the same format and the same codes.
> 
> If we have to add a couple of codes (I do not think we need too many),
> it is alright. However, defining brand new status codes does not sound
> good to me. Let us reuse what we already have.

I think thats a reasonable starting point. Lets keep in mind that this
mechanism is not soley for 3pcc response-to-BYE conversions. It is also
helpful for indicating the reason for CANCELs as well. These reasons, which
I have indicated a few in a prior email, have no appropriate values amongst
the defined response codes.

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

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


From sip-admin@ietf.org  Fri Jun 29 05:07:14 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05706;
	Fri, 29 Jun 2001 05:07:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00601;
	Fri, 29 Jun 2001 04:56:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA00569
	for ; Fri, 29 Jun 2001 04:56:30 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27726
	for ; Fri, 29 Jun 2001 04:55:45 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id FAA05828;
	Fri, 29 Jun 2001 05:00:31 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 29 Jun 2001 04:56:22 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Ashhar Farhan'" , bpenfield@acmepacket.com
Cc: sip@ietf.org
Subject: RE: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors] an
	other  problem related to multiple call l egs at UAC)
Date: Fri, 29 Jun 2001 04:56:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Ashar,

Thanks for the reminder about international support.

There is already support in SIP for management of internationalized reason
phrases. This is done through the Accept-Language header. A truly
internationalized server would be able to generate reason phrases in the
responses by figuring out the preferred language from the Accept-Language
header in the INVITE. I doubt any server actually does that, but the
facility is built into the protocol. 

So, for the Reason header in BYE/CANCEL, the same would be done. The UAC
generating a BYE would use the Accept-Language from the 2xx to the initial
INVITE response to figure out what language to use. Same with a proxy.

Would this require storing reason phrases, hardcoded into the UA, for each
language supported? Possibly. A more creative approach is to add an http
client and then access one of the many fine translation services on the web
to translate the reason phrases into the target language as needed. Either
way is an implementation choice.

-Jonathan R.

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

> -----Original Message-----
> From: Ashhar Farhan [mailto:afarhan@rediffmail.com]
> Sent: Thursday, June 28, 2001 1:05 PM
> To: bpenfield@acmepacket.com
> Cc: sip@ietf.org
> Subject: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors]
> another problem related to multiple call l egs at UAC)
> 
> 
> a message code alone is a better option rather than a text 
> alongwith it too. the reason is internationalism.
> 
> telephony, by definition involves spanning distances and 
> geographys and cultures. therefore, an english message 
> explaining the reason for call rejection (like 'Needs 
> Payment') may not make sense to an arab or a japanese. 
> however, reason code is easily localised to local dialects 
> and sensitivities. (in my city hyderabad, getting a message 
> like 'you dont have money in the bank to make this call' will 
> be considered very rude).
> 
> if the text message that goes along with a message is 
> customisable from message to message, it will effect 
> definitive interpretation of the reason code. on the other 
> hand, if the text message is not adding more intelligence to 
> the reason code, it is best to localy generate it on the UA.
> 
> as per the original rosenberg-henning vision, SIP is not 
> concerned with presentation layer, therefore, i dont see the 
> need for text messages. For instance, how do you interpret 
> these text messages to a display-less device like a POTS phone?
> 
> - farhan@hotfoon.com
> 
> 
> 
> ____________________________________________________
> Buy Feng Shui Package for Rs. 151/- only, at 
> http://shopping.rediff.com/shopping/fengshui_mailer.htm
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

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


From sip-admin@ietf.org  Fri Jun 29 05:32:58 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23521;
	Fri, 29 Jun 2001 05:32:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01689;
	Fri, 29 Jun 2001 05:28:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01661
	for ; Fri, 29 Jun 2001 05:28:06 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19693
	for ; Fri, 29 Jun 2001 05:27:22 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id FAA05990;
	Fri, 29 Jun 2001 05:32:03 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 29 Jun 2001 05:27:54 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Henning G. Schulzrinne'" ,
        Gordon Ledgard
	 
Cc: Jonathan Rosenberg ,
        "'Hidefumi Nakamura'"
	 ,
        "'sip@ietf.org'" 
Subject: RE: [SIP] Congestion control
Date: Fri, 29 Jun 2001 05:27:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Thursday, June 28, 2001 11:19 AM
> To: Gordon Ledgard
> Cc: Jonathan Rosenberg; 'Hidefumi Nakamura'; 'sip@ietf.org'
> Subject: Re: [SIP] Congestion control
> 
> 
> The point I was trying to make is that I see no reason to 
> treat 503 as a
> special case. I would like to avoid lots of rules and regulations for
> each response code, for things that are essentially implementation
> issues. We do have the Retry-After header if the server wants to pace
> requests by a client, e.g., for some kind of mass calling 
> event where it
> knows that things are hopeless for the next hour. However, 
> none of this
> belongs in the spec.

I agree definitely as well that we want to avoid special cases. It ocurred
to me later that there aren't really problems with a 503 without
Retry-After, and that normal response processing will work. The issue with
#3 only arises when Retry-After is present, and in this case, normal
response processing may not do the right thing depending on the
interpretation of Retry-After.

Why? My interpretation of 503 w/o Retry-After is that the server is
reporting that it can't handle THIS transaction. It says nothing about any
others for any future time. So, a client that gets a 503 tries a different
server. A proxy which forked, and received 503 on all branches, is in a
situation where, for this transaction, it truly cannot process it, and so
forwarding the 503 upstream is the right thing to do.

Retry-After is a different story. Consider the case of UAC A, that sends an
INVITE to local outbound proxy B, which proxies that to proxy C. Proxy C is
running on an old 8088 with 32k of RAM. So, when it gets the INVITE, it
returns a 503 with a Retry-After of 1 day. This is forwarded by B to A. Now,
how should A interpret this response?

1. don't send any requests to proxy B for 1 day
2. don't send any requests to the user in the request URI of the original
INVITE for 1 day

If the interpretation is 1 - meaning that a retry-after in a 503 means that
the SERVER is busy - I would argue that forwarding the 503 with that
retry-after header in tact is the wrong thing to do. The right behavior
would probably be for the proxy to strip the Retry-After in the 503 before
forwarding it upstream. In other words, if 503 has a hop-by-hop semantic,
indicating to the previous server the state of the server generating the
503, then 503 with a Retry-After should never be forwarded upstream, since
its telling the previous server the state of a server two hops down, which
is not the interpretation of the 503.


If the interpretation is 2 - meaning that Retry-After in a 503 means that
the server can't handle requests for that resource, forwarding the
Retry-After upstream is just fine.

Now, we inherited 503 from HTTP, where I believe it truly did mean that the
SERVER was busy. However, the problem we are encountering with this
interpretation this wasn't an issue for http, since only origin servers ever
generated these things, and it was only origin servers that were ever the
busy elements. With proxies playing a larger role, it gets complex.

So, we have a dilemma. The interpretation of 503 meaning "the server that
sent you this is busy" is a very useful one for failover and load
distribution, but has this nasty problem with the Retry-After. The
interpretation of 503 as "the resource in the URI cannot be reached because
a server along the way is busy" is not very useful, but more compatible with
the response processing operations in proxies.

So, I think we do have an issue here that requires the spec to clearly
define the semantic of 503, and then we need to deal with any implications
of that.

-Jonathan R.



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


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


From sip-admin@ietf.org  Fri Jun 29 05:44:17 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01384;
	Fri, 29 Jun 2001 05:44:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02241;
	Fri, 29 Jun 2001 05:36:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02158
	for ; Fri, 29 Jun 2001 05:36:40 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25621
	for ; Fri, 29 Jun 2001 05:35:56 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f5T9aYN15527;
	Fri, 29 Jun 2001 11:36:35 +0200 (MEST)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.7])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f5T9aY508789;
	Fri, 29 Jun 2001 12:36:34 +0300 (EET DST)
Message-ID: <3B3C4C0C.9B9549B1@lmf.ericsson.se>
Date: Fri, 29 Jun 2001 12:36:12 +0300
From: Christer Holmberg 
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Gonzalo Camarillo'" , sip@ietf.org,
        mmusic 
Subject: Re: [Sip] Two SDP issues
References: 
Content-Type: multipart/mixed;
 boundary="------------5FD0103811D5887269D0AB62"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

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


Hi,

I agree with Jonathan that using a SDP attribute (or use existing ones),
instead of c=0.0.0.0, could be a good idea.

That would solve the RTCP issue, without having to "remember" the old
address. There are also some other issues I can think about:

1. Media security

In this case the old address would also have to be remembered, for the
case when the media is put back again, because the application has to
know if it is a new IP address, or the one that was used before the
media was put back on hold. If it is a new address, a new security
association may have to be established, while the old SA can be used
otherwise.

2. IPv6

Since IPv6 uses different addressing, so we can't use c=0.0.0.0 there.

3. ATM

An ATM bearer doesn't use IP addresses at all, so to be able to put
media on ATM on hold we need to use some other mechanism in any case.


Regards,

Christer Holmberg
Ericsson Finland






Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > Sent: Thursday, June 28, 2001 3:01 PM
> > To: sip@ietf.org; mmusic
> > Subject: [Sip] Two SDP issues
> >
> >
> > Hello,
> >
> > A couple of SDP issues:
> >
> > 1) I recall that we discussed this issue in an IETF meeting, but I am
> > not aware of the result of the discussion.
> >
> > Let's say that user A sends an INVITE with two m lines. One for audio
> > (PCM codec, for instance) and another for DTMF tones.
> >
> > The receiver (user B), due to any reason, cannot send DTMF
> > tones, but he
> > can receive them. Can user B add a=recvonly for that m line to the SDP
> > that he returns in the 200 OK?
> 
> Yes. From bis-03:
> 
> If an offered media stream is listed as sendrecv (or contains no direction
> attribute, in which case it is
> sendrecv by default), the corresponding stream in the answer MAY be marked
> as sendonly, recvonly, or
> sendrecv.
> 
> >
> >
> > 2) If I want to stop receiving media (put a call on hold) I
> > send an SDP
> > with c=0.0.0.0. However, I can still send media. In which
> > address will I
> > receive RTCP? Should the other party remember my previous c line on
> > order to send me RTCP?
> 
> Now, this is a really good question. Remembering the old IP address is a bad
> thing, I think. There may not be one, and you really want each INVITE to
> contain the full state for the media streams.
> 
> At the moment, the result is that you won't get RTCP or media if you put
> someone on hold, even if you are still sending media. This is not
> catastrophic, but is not the right thing to do.
> 
> There are a few options:
> 
> 1. don't worry about this problem
> 2. define an sdp attribute that indicates the address to receive rtcp
> 3. define an alternate "hold" mechanism that, instead of setting the
> connection IP to 0.0.0.0, simply sets the stream to sendonly and has some
> additional attribute to convey "hold"
> 
> Maybe there are others. The third approach is sort-of backwards compatible,
> but won't work with clients that take explicit actions as a result of
> realizing that the stream is on hold.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
--------------5FD0103811D5887269D0AB62
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------5FD0103811D5887269D0AB62--


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


From sip-admin@ietf.org  Fri Jun 29 07:06:52 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28224;
	Fri, 29 Jun 2001 07:06:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04352;
	Fri, 29 Jun 2001 06:57:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04320
	for ; Fri, 29 Jun 2001 06:57:31 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21238;
	Fri, 29 Jun 2001 06:56:47 -0400 (EDT)
Message-Id: <200106291056.GAA21238@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 29 Jun 2001 06:56:46 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-call-flows-05.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Working Group of the IETF.

	Title		: SIP Call Flow Examples
	Author(s)	: A. Johnston, S. Donovan, R. Sparks, 
                          C. Cunningham, D. Willis, J. Rosenberg,
                          K. Summers, H. Schulzrinne
	Filename	: draft-ietf-sip-call-flows-05.txt
	Pages		: 220
	Date		: 28-Jun-01
	
This informational document gives examples of SIP (Session Initiation
Protocol) call flows for IP telephony.  Elements in these call flows
include SIP User Agents and Clients, SIP Proxy and Redirect Servers,
and Gateways to the PSTN (Public Switch Telephone Network).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-call-flows-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-call-flows-05.txt".

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


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

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-call-flows-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-call-flows-05.txt

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

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

--OtherAccess--

--NextPart--



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


From sip-admin@ietf.org  Fri Jun 29 10:09:26 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29644;
	Fri, 29 Jun 2001 10:09:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10669;
	Fri, 29 Jun 2001 09:54:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10637
	for ; Fri, 29 Jun 2001 09:54:48 -0400 (EDT)
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19799
	for ; Fri, 29 Jun 2001 09:54:05 -0400 (EDT)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA13051; Fri, 29 Jun 2001 09:54:10 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AJN05708;
	Fri, 29 Jun 2001 09:54:08 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010629095511.00b01330@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 29 Jun 2001 09:56:13 -0400
To: Jonathan Rosenberg 
From: Michael Hammer 
Subject: RE: [Sip] Two SDP issues
Cc: "'Gonzalo Camarillo'" , sip@ietf.org,
        mmusic 
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

At 04:46 AM 6/29/2001 -0400, Jonathan Rosenberg wrote:


>
>
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > Sent: Thursday, June 28, 2001 3:01 PM
> > To: sip@ietf.org; mmusic
> > Subject: [Sip] Two SDP issues
> >
> >
> > Hello,
> >
> > A couple of SDP issues:
> >
> > 1) I recall that we discussed this issue in an IETF meeting, but I am
> > not aware of the result of the discussion.
> >
> > Let's say that user A sends an INVITE with two m lines. One for audio
> > (PCM codec, for instance) and another for DTMF tones.
> >
> > The receiver (user B), due to any reason, cannot send DTMF
> > tones, but he
> > can receive them. Can user B add a=recvonly for that m line to the SDP
> > that he returns in the 200 OK?
>
>Yes. From bis-03:
>
>If an offered media stream is listed as sendrecv (or contains no direction
>attribute, in which case it is
>sendrecv by default), the corresponding stream in the answer MAY be marked
>as sendonly, recvonly, or
>sendrecv.
>
>
> >
> >
> > 2) If I want to stop receiving media (put a call on hold) I
> > send an SDP
> > with c=0.0.0.0. However, I can still send media. In which
> > address will I
> > receive RTCP? Should the other party remember my previous c line on
> > order to send me RTCP?
>
>Now, this is a really good question. Remembering the old IP address is a bad
>thing, I think. There may not be one, and you really want each INVITE to
>contain the full state for the media streams.
>
>At the moment, the result is that you won't get RTCP or media if you put
>someone on hold, even if you are still sending media. This is not
>catastrophic, but is not the right thing to do.
>
>There are a few options:
>
>1. don't worry about this problem
>2. define an sdp attribute that indicates the address to receive rtcp
>3. define an alternate "hold" mechanism that, instead of setting the
>connection IP to 0.0.0.0, simply sets the stream to sendonly and has some
>additional attribute to convey "hold"
>
>Maybe there are others. The third approach is sort-of backwards compatible,
>but won't work with clients that take explicit actions as a result of
>realizing that the stream is on hold.
>

Could you kill two birds with one stone by defining a fourth option to the 
sendonly, receiveonly, sendreceive:  neithersendnorreceive?



>-Jonathan R.
>---
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com
>
>_______________________________________________
>Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


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


From sip-admin@ietf.org  Fri Jun 29 10:10:08 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00073;
	Fri, 29 Jun 2001 10:10:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10757;
	Fri, 29 Jun 2001 09:56:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10726
	for ; Fri, 29 Jun 2001 09:56:44 -0400 (EDT)
Received: from commserver.iperia.com ([63.84.167.3])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21085
	for ; Fri, 29 Jun 2001 09:56:02 -0400 (EDT)
Received: by commserver.erictest.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 29 Jun 2001 09:54:32 -0400
Message-ID: <1A69639B9B6AD511812B00B0D0DE19F60A2F11@commserver.erictest.com>
From: Gordon Ledgard 
To: "'Jonathan Rosenberg'" ,
        "'Henning G. Schulzrinne'" ,
        "'Hidefumi Nakamura'"
	 ,
        "'sip@ietf.org'" 
Cc: Gordon Ledgard 
Subject: RE: [SIP] Congestion control
Date: Fri, 29 Jun 2001 09:54:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org


Jonathan wrote - 

> Henning wrote -
>> The point I was trying to make is that I see no reason to 
>> treat 503 as a
>> special case. I would like to avoid lots of rules and regulations for
>> each response code, for things that are essentially implementation
>> issues. We do have the Retry-After header if the server wants to pace
>> requests by a client, e.g., for some kind of mass calling 
>> event where it
>> knows that things are hopeless for the next hour. However, 
>> none of this
>> belongs in the spec.
>
>I agree definitely as well that we want to avoid special cases. It ocurred
>to me later that there aren't really problems with a 503 without
>Retry-After, and that normal response processing will work. The issue with
>#3 only arises when Retry-After is present, and in this case, normal
>response processing may not do the right thing depending on the
>interpretation of Retry-After.

>Why? My interpretation of 503 w/o Retry-After is that the server is
>reporting that it can't handle THIS transaction. It says nothing about any
>others for any future time. So, a client that gets a 503 tries a different
>server. A proxy which forked, and received 503 on all branches, is in a
>situation where, for this transaction, it truly cannot process it, and so
>forwarding the 503 upstream is the right thing to do.

>Retry-After is a different story. Consider the case of UAC A, that sends an
>INVITE to local outbound proxy B, which proxies that to proxy C. Proxy C is
>running on an old 8088 with 32k of RAM. So, when it gets the INVITE, it
>returns a 503 with a Retry-After of 1 day. This is forwarded by B to A.
Now,
>how should A interpret this response?

>1. don't send any requests to proxy B for 1 day
>2. don't send any requests to the user in the request URI of the original
>INVITE for 1 day

>If the interpretation is 1 - meaning that a retry-after in a 503 means that
>the SERVER is busy - I would argue that forwarding the 503 with that
>retry-after header in tact is the wrong thing to do. The right behavior
>would probably be for the proxy to strip the Retry-After in the 503 before
>forwarding it upstream. In other words, if 503 has a hop-by-hop semantic,
>indicating to the previous server the state of the server generating the
>503, then 503 with a Retry-After should never be forwarded upstream, since
>its telling the previous server the state of a server two hops down, which
>is not the interpretation of the 503.
>
>
>If the interpretation is 2 - meaning that Retry-After in a 503 means that
>the server can't handle requests for that resource, forwarding the
>Retry-After upstream is just fine.
>
>Now, we inherited 503 from HTTP, where I believe it truly did mean that the
>SERVER was busy. However, the problem we are encountering with this
>interpretation this wasn't an issue for http, since only origin servers
ever
>generated these things, and it was only origin servers that were ever the
>busy elements. With proxies playing a larger role, it gets complex.
>
>So, we have a dilemma. The interpretation of 503 meaning "the server that
>sent you this is busy" is a very useful one for failover and load
>distribution, but has this nasty problem with the Retry-After. The
>interpretation of 503 as "the resource in the URI cannot be reached because
>a server along the way is busy" is not very useful, but more compatible
with
>the response processing operations in proxies.
>
>So, I think we do have an issue here that requires the spec to clearly
>define the semantic of 503, and then we need to deal with any implications
>of that.
>
>-Jonathan R.



Interesting dilemma. I'd say that if we treated 503's as in case 2,
we would be left searching for a new way to describe individual
hops in the network being busy. If we treat 503's as in case 1,
we handle both situations of the endpoint being busy, or a hop
being busy, and there should be no issue. Then we must interpret
Retry-After on a hop-by-hop case, like you say Jonathan, and
strip them off (or replace the timer) upstream.

I think that works.

Gordon R. Ledgard
IPeria, Inc.
(781) 993-3540

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


From sip-admin@ietf.org  Fri Jun 29 10:29:23 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12183;
	Fri, 29 Jun 2001 10:29:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11284;
	Fri, 29 Jun 2001 10:03:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11248
	for ; Fri, 29 Jun 2001 10:03:46 -0400 (EDT)
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25696
	for ; Fri, 29 Jun 2001 10:02:59 -0400 (EDT)
Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16])
	by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5TE1S427281;
	Fri, 29 Jun 2001 10:01:28 -0400 (EDT)
Received: from cisco.com (dhcp-161-44-241-91.cisco.com [161.44.241.91])
	by cannon.cisco.com (Mirapoint)
	with ESMTP id ABR00008 (AUTH pkyzivat);
	Fri, 29 Jun 2001 10:02:55 -0400 (EDT)
Message-ID: <3B3C8982.33B81804@cisco.com>
Date: Fri, 29 Jun 2001 09:58:26 -0400
From: Paul Kyzivat 
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christer Holmberg 
CC: Jonathan Rosenberg ,
        "'Gonzalo Camarillo'" ,
        sip@ietf.org, mmusic 
Subject: Re: [Sip] Two SDP issues
References:  <3B3C4C0C.9B9549B1@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Since this seems to be turning into a discussion of problems with the
existing means of representing Hold, let me add one more:

The c=0.0.0.0 mechanism for specifying hold doesn't work right for
connection oriented media (the comedia I-P.) In reality it is another
manifestation of the problem here with RTCP.

Seems to me that if we were in a sendrecv session and I want to put you
on hold I should send SDP containing a:sendonly. If you receive that and
are happy with it then you should return a:recvonly. With some kinds of
transports it may be possible to also specify c=0.0.0.0 in order to free
up my transport resources for some other purpose, but that varies from
case to case.

The situation is a little more complicated if the session is already
oneway and the receiver wants to go on hold. I haven't worked that out
yet.

	Paul Kyzivat
	Cisco Systems

Christer Holmberg wrote:
> 
> Hi,
> 
> I agree with Jonathan that using a SDP attribute (or use existing ones),
> instead of c=0.0.0.0, could be a good idea.
> 
> That would solve the RTCP issue, without having to "remember" the old
> address. There are also some other issues I can think about:
> 
> 1. Media security
> 
> In this case the old address would also have to be remembered, for the
> case when the media is put back again, because the application has to
> know if it is a new IP address, or the one that was used before the
> media was put back on hold. If it is a new address, a new security
> association may have to be established, while the old SA can be used
> otherwise.
> 
> 2. IPv6
> 
> Since IPv6 uses different addressing, so we can't use c=0.0.0.0 there.
> 
> 3. ATM
> 
> An ATM bearer doesn't use IP addresses at all, so to be able to put
> media on ATM on hold we need to use some other mechanism in any case.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> Jonathan Rosenberg wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > > Sent: Thursday, June 28, 2001 3:01 PM
> > > To: sip@ietf.org; mmusic
> > > Subject: [Sip] Two SDP issues
> > >
> > >
> > > Hello,
> > >
> > > A couple of SDP issues:
> > >
> > > 1) I recall that we discussed this issue in an IETF meeting, but I am
> > > not aware of the result of the discussion.
> > >
> > > Let's say that user A sends an INVITE with two m lines. One for audio
> > > (PCM codec, for instance) and another for DTMF tones.
> > >
> > > The receiver (user B), due to any reason, cannot send DTMF
> > > tones, but he
> > > can receive them. Can user B add a=recvonly for that m line to the SDP
> > > that he returns in the 200 OK?
> >
> > Yes. From bis-03:
> >
> > If an offered media stream is listed as sendrecv (or contains no direction
> > attribute, in which case it is
> > sendrecv by default), the corresponding stream in the answer MAY be marked
> > as sendonly, recvonly, or
> > sendrecv.
> >
> > >
> > >
> > > 2) If I want to stop receiving media (put a call on hold) I
> > > send an SDP
> > > with c=0.0.0.0. However, I can still send media. In which
> > > address will I
> > > receive RTCP? Should the other party remember my previous c line on
> > > order to send me RTCP?
> >
> > Now, this is a really good question. Remembering the old IP address is a bad
> > thing, I think. There may not be one, and you really want each INVITE to
> > contain the full state for the media streams.
> >
> > At the moment, the result is that you won't get RTCP or media if you put
> > someone on hold, even if you are still sending media. This is not
> > catastrophic, but is not the right thing to do.
> >
> > There are a few options:
> >
> > 1. don't worry about this problem
> > 2. define an sdp attribute that indicates the address to receive rtcp
> > 3. define an alternate "hold" mechanism that, instead of setting the
> > connection IP to 0.0.0.0, simply sets the stream to sendonly and has some
> > additional attribute to convey "hold"
> >
> > Maybe there are others. The third approach is sort-of backwards compatible,
> > but won't work with clients that take explicit actions as a result of
> > realizing that the stream is on hold.
> >
> > -Jonathan R.
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip

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


From sip-admin@ietf.org  Fri Jun 29 10:37:30 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17332;
	Fri, 29 Jun 2001 10:37:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11852;
	Fri, 29 Jun 2001 10:17:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11823
	for ; Fri, 29 Jun 2001 10:17:32 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04182
	for ; Fri, 29 Jun 2001 10:16:48 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA07874;
	Fri, 29 Jun 2001 10:21:28 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 29 Jun 2001 10:17:18 -0400
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F314A938@DYN-TX-EXCH-001.dynamicsoft.com>
From: Robert Sparks 
To: "'Itamar Gilad'" , "'SIP list'" 
Subject: RE: [Sip] Consecutive REFERs
Date: Fri, 29 Jun 2001 10:17:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org


> -----Original Message-----
> From: Itamar Gilad [mailto:ItamarG@radvision.com]
> Sent: Tuesday, June 26, 2001 3:06 AM
> To: 'SIP list'
> Subject: [Sip] Consecutive REFERs
> 
> 
> Below are a couple of questions regarding REFER scenarios and 
> appropriate
> response code usage. I'm sorry if this has been asked before.
> 
> 1) A sends a REFER to B directing it to call C.  B sets up a 
> call with C
> successfully.  Now A sends another (new) REFER to B directing 
> it to contact
> D.  B wants to reject this REFER on the grounds that it 
> currently can't take
> additional calls.  Is 486 the appropriate response?

If the UA has asked the user at B to make the decision, or
was configured to do so, you could use a 603. If the agent
is making the decision, a 486 is reasonable. This is the
similar to the decision your agent would need to make if
a REFER showed up outside a call context from D while B 
was talking to C.

> 
> 2) Same as A, but this time the second REFER directs B to 
> call C again.  B
> wants to reject this on the grounds that it already has a 
> call-leg setup
> with C.  What's the response code B should use here?

If B holds to that policy, 486 isn't insane (treating it
as an example of case 1). This is not much different from
the case that a REFER to C shows up out of band from
somewhere while B is already in a call with C.

>  
> Thanks,
> 
> Itamar Gilad
> RADVISION
> itamarg@radvision.com               24 Raul Wallenberg St.
> tel: +972 3 7659938                 Building D
> cel: +972 56 429938                 Tel-Aviv 69719
> fax: +972 3 6472637                 Israel
> 
> 
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

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


From sip-admin@ietf.org  Fri Jun 29 10:41:37 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19989;
	Fri, 29 Jun 2001 10:41:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12639;
	Fri, 29 Jun 2001 10:32:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12603
	for ; Fri, 29 Jun 2001 10:32:54 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13954
	for ; Fri, 29 Jun 2001 10:32:11 -0400 (EDT)
Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA25708
	for ; Fri, 29 Jun 2001 10:32:52 -0400 (EDT)
Message-ID: <3B3C9194.CD108377@cs.columbia.edu>
Date: Fri, 29 Jun 2001 10:32:52 -0400
From: "Henning G. Schulzrinne" 
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-2cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] sip media type
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

The REFER draft lists the type for responses as application/sip instead
of message/sip. Given that http is under the message media type,
shouldn't sip be there, too?
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

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


From sip-admin@ietf.org  Fri Jun 29 10:42:16 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20404;
	Fri, 29 Jun 2001 10:42:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12573;
	Fri, 29 Jun 2001 10:31:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12546
	for ; Fri, 29 Jun 2001 10:31:56 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13306
	for ; Fri, 29 Jun 2001 10:31:13 -0400 (EDT)
Received: from cs.columbia.edu (IDENT:hgs@metroliner.cs.columbia.edu [128.59.19.252])
	by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA25682
	for ; Fri, 29 Jun 2001 10:31:55 -0400 (EDT)
Message-ID: <3B3C915A.CD367B8C@cs.columbia.edu>
Date: Fri, 29 Jun 2001 10:31:54 -0400
From: "Henning G. Schulzrinne" 
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-2cucs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] REFER failures
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

One issue that has come up in implementing REFER is that the failure
indication is not quite as unambiguous as I'd like. Currently, it is
hard to distinguish whether the referred call failed or whether the
target of the REFER couldn't or wouldn't execute the REFER, if this
failure isn't immediate. Typical example: the recipient of the REFER
will probably get a pop-up window asking whether it actually wants to
make that call. However, a final response to the REFER needs to be
returned immediately, so only NOTIFY can be used to indicate that the
REFER failed later, e.g., because the REFER recipient refused to act on
the REFER.

We can fake this by including the status response of the REFER recipient
in the NOTIFY body (e.g., 603), but that's ambiguous as to who declined.
One solution is that the NOTIFY always includes the full SIP response,
so that it's clear what this refers to. For late failures of the REFER
(rather than the request triggered by it), it would be the final
response that would have been sent, e.g.,

SIP/2.0 603 Refused
From: sender of REFER
To: recipient of REFER
Call-ID: of original REFER
CSeq: something REFER


Whether it makes sense to use 202 as the final response in this case is
another, more secondary question.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

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


From sip-admin@ietf.org  Fri Jun 29 10:52:30 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26846;
	Fri, 29 Jun 2001 10:52:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10541;
	Fri, 29 Jun 2001 09:51:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10510
	for ; Fri, 29 Jun 2001 09:51:23 -0400 (EDT)
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17560
	for ; Fri, 29 Jun 2001 09:50:40 -0400 (EDT)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA12969; Fri, 29 Jun 2001 09:50:47 -0400 (EDT)
Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-82.cisco.com [161.44.87.82])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AJN05674;
	Fri, 29 Jun 2001 09:50:46 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010629094958.00b057c8@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 29 Jun 2001 09:52:51 -0400
To: Jonathan Rosenberg 
From: Michael Hammer 
Subject: RE: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors]
  an other  problem related to multiple call l egs at UAC)
Cc: "'Ashhar Farhan'" , bpenfield@acmepacket.com,
        sip@ietf.org
In-Reply-To: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

At 04:56 AM 6/29/2001 -0400, Jonathan Rosenberg wrote:
>Ashar,
>
>Thanks for the reminder about international support.
>
>There is already support in SIP for management of internationalized reason
>phrases. This is done through the Accept-Language header. A truly
>internationalized server would be able to generate reason phrases in the
>responses by figuring out the preferred language from the Accept-Language
>header in the INVITE. I doubt any server actually does that, but the
>facility is built into the protocol.
>
>So, for the Reason header in BYE/CANCEL, the same would be done. The UAC
>generating a BYE would use the Accept-Language from the 2xx to the initial
>INVITE response to figure out what language to use. Same with a proxy.
>
>Would this require storing reason phrases, hardcoded into the UA, for each
>language supported? Possibly. A more creative approach is to add an http
>client and then access one of the many fine translation services on the web
>to translate the reason phrases into the target language as needed. Either
>way is an implementation choice.

And to complete the picture, you are saying that the responsibility for 
using http to access the translation service and return the correct local 
display belongs to the UA and not a proxy, therefore, no protocol element 
is needed to convey that information to the UA other than the code 
number?  Or did I misread this?


>-Jonathan R.
>
>---
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com
>
>
> > -----Original Message-----
> > From: Ashhar Farhan [mailto:afarhan@rediffmail.com]
> > Sent: Thursday, June 28, 2001 1:05 PM
> > To: bpenfield@acmepacket.com
> > Cc: sip@ietf.org
> > Subject: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors]
> > another problem related to multiple call l egs at UAC)
> >
> >
> > a message code alone is a better option rather than a text
> > alongwith it too. the reason is internationalism.
> >
> > telephony, by definition involves spanning distances and
> > geographys and cultures. therefore, an english message
> > explaining the reason for call rejection (like 'Needs
> > Payment') may not make sense to an arab or a japanese.
> > however, reason code is easily localised to local dialects
> > and sensitivities. (in my city hyderabad, getting a message
> > like 'you dont have money in the bank to make this call' will
> > be considered very rude).
> >
> > if the text message that goes along with a message is
> > customisable from message to message, it will effect
> > definitive interpretation of the reason code. on the other
> > hand, if the text message is not adding more intelligence to
> > the reason code, it is best to localy generate it on the UA.
> >
> > as per the original rosenberg-henning vision, SIP is not
> > concerned with presentation layer, therefore, i dont see the
> > need for text messages. For instance, how do you interpret
> > these text messages to a display-less device like a POTS phone?
> >
> > - farhan@hotfoon.com
> >
> >
> >
> > ____________________________________________________
> > Buy Feng Shui Package for Rs. 151/- only, at
> > http://shopping.rediff.com/shopping/fengshui_mailer.htm
> >
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >
>
>_______________________________________________
>Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


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


From sip-admin@ietf.org  Fri Jun 29 11:46:49 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15607;
	Fri, 29 Jun 2001 11:46:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14432;
	Fri, 29 Jun 2001 11:27:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14403
	for ; Fri, 29 Jun 2001 11:27:48 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14997
	for ; Fri, 29 Jun 2001 11:27:05 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id ADF565680144; Fri, 29 Jun 2001 11:25:41 -0400
Message-ID: <006801c100ad$d1fc4e40$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: "Henning G. Schulzrinne" , 
References: <3B3C915A.CD367B8C@cs.columbia.edu>
Subject: Re: [Sip] REFER failures
Date: Fri, 29 Jun 2001 11:11:47 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Henning G. Schulzrinne" 
To: 
Sent: Friday, June 29, 2001 10:31 AM
Subject: [Sip] REFER failures


> One issue that has come up in implementing REFER is that the failure
> indication is not quite as unambiguous as I'd like. Currently, it is
> hard to distinguish whether the referred call failed or whether the
> target of the REFER couldn't or wouldn't execute the REFER, if this
> failure isn't immediate. Typical example: the recipient of the REFER
> will probably get a pop-up window asking whether it actually wants to
> make that call. However, a final response to the REFER needs to be
> returned immediately, so only NOTIFY can be used to indicate that the
> REFER failed later, e.g., because the REFER recipient refused to act on
> the REFER.
>
> We can fake this by including the status response of the REFER recipient
> in the NOTIFY body (e.g., 603), but that's ambiguous as to who declined.
> One solution is that the NOTIFY always includes the full SIP response,
> so that it's clear what this refers to. For late failures of the REFER
> (rather than the request triggered by it), it would be the final
> response that would have been sent, e.g.,
>
> SIP/2.0 603 Refused
> From: sender of REFER
> To: recipient of REFER
> Call-ID: of original REFER
> CSeq: something REFER
>

We've been discussing the idea of a Reason header in BYE and CANCEL
requests. Would that be useful in a NOTIFY request to convey the "603
Refused"?

>
> Whether it makes sense to use 202 as the final response in this case is
> another, more secondary question.
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>
> _______________________________________________
> Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>


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


From sip-admin@ietf.org  Fri Jun 29 14:14:15 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21697;
	Fri, 29 Jun 2001 14:14:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19976;
	Fri, 29 Jun 2001 13:57:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19923
	for ; Fri, 29 Jun 2001 13:57:57 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20957;
	Fri, 29 Jun 2001 13:57:14 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA10972;
	Fri, 29 Jun 2001 14:02:04 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 29 Jun 2001 13:57:54 -0400
Message-ID: 
From: Rakesh Shah 
To: "SIPWG Mailing List (E-mail)" ,
        "SIPWG Mailing List (E-mail 2)" 
Date: Fri, 29 Jun 2001 13:57:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Sip] LAST CALL REVIEWERS NEEDED - draft-ietf-sip-call-flows-05.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

The subject draft is up for WGLC!

While there is a pool of volunteers available to take on the Last Call
Review, I would like to open the opportunity to whomever has an interest in
this particular draft.

Please respond to me by 5-Jul-01 if you are interested in taking on this
Last Call Review. If I do not get any responses by the above date, I will
select three people off of my volunteer list.

Don't forget, all of the information you need, including the draft itself is
available at http://www.softarmor.com/sipping/.

Regards,

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


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


From sip-admin@lists.bell-labs.com  Fri Jun 29 15:01:31 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23037
	for ; Fri, 29 Jun 2001 15:01:30 -0400 (EDT)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3219D44341; Fri, 29 Jun 2001 15:02:08 -0400 (EDT)
Delivered-To: sip@lists.bell-labs.com
Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101])
	by lists.bell-labs.com (Postfix) with ESMTP id 1C4D544336
	for ; Fri, 29 Jun 2001 15:01:25 -0400 (EDT)
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21385
	for ; Fri, 29 Jun 2001 15:00:35 -0400 (EDT)
Received: from bighorn.dr.avaya.com (h135-9-1-59.avaya.com [135.9.1.59])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with SMTP id PAA21350
	for ; Fri, 29 Jun 2001 15:00:34 -0400 (EDT)
Received: from avaya.com by bighorn.dr.avaya.com (SMI-8.6/EMS-1.5 sol2)
	id NAA03546; Fri, 29 Jun 2001 13:01:23 -0600
Message-ID: <3B3CD087.7673029D@avaya.com>
From: Chandra Ravipati 
Reply-To: ravipati@avaya.com
Organization: Avaya
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
References: <3B33455C.A01A4E4E@lab.ntt.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] SIP Message segmentation problem over TCP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: , 
List-Id: IETF SIP Mailing List 
List-Unsubscribe: , 
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 29 Jun 2001 13:01:27 -0600
Content-Transfer-Encoding: 7bit


Hi,

I want to know how others are dealing with message segmentation for TCP. 

Do people use TPKT? or use Content-length: ?

Using "content-length" is very inefficient and very protocol specific. 
Why can't we use TPKT?


Thanks in advance for your participation in this discussion.
Chandra Ravipati.

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


From sip-admin@ietf.org  Fri Jun 29 15:20:46 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23635;
	Fri, 29 Jun 2001 15:20:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22853;
	Fri, 29 Jun 2001 15:11:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22824
	for ; Fri, 29 Jun 2001 15:11:13 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23356
	for ; Fri, 29 Jun 2001 15:10:28 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA12172;
	Fri, 29 Jun 2001 15:15:18 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 29 Jun 2001 15:11:09 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Itamar Gilad'" , "'SIP list'" 
Subject: RE: [Sip] Consecutive REFERs
Date: Fri, 29 Jun 2001 15:11:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Itamar Gilad [mailto:ItamarG@radvision.com]
> Sent: Tuesday, June 26, 2001 4:06 AM
> To: 'SIP list'
> Subject: [Sip] Consecutive REFERs
> 
> 
> Below are a couple of questions regarding REFER scenarios and 
> appropriate
> response code usage. I'm sorry if this has been asked before.
> 
> 1) A sends a REFER to B directing it to call C.  B sets up a 
> call with C
> successfully.  Now A sends another (new) REFER to B directing 
> it to contact
> D.  B wants to reject this REFER on the grounds that it 
> currently can't take
> additional calls.  Is 486 the appropriate response?
> 
> 2) Same as A, but this time the second REFER directs B to 
> call C again.  B
> wants to reject this on the grounds that it already has a 
> call-leg setup
> with C.  What's the response code B should use here?

I'm actually curious why you ask. THe response code really shouldn't matter
unless you were planning to define logic at A that did something special
depending on the response code. Was that the case?


-Jonathan R.

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

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


From sip-admin@ietf.org  Fri Jun 29 15:28:00 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23775;
	Fri, 29 Jun 2001 15:28:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22663;
	Fri, 29 Jun 2001 15:06:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22632
	for ; Fri, 29 Jun 2001 15:06:20 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23238
	for ; Fri, 29 Jun 2001 15:05:36 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA12104;
	Fri, 29 Jun 2001 15:10:19 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 29 Jun 2001 15:06:09 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'ravipati@avaya.com'" ,
        "'sip@ietf.org'"
	 
Subject: RE: [SIP] SIP Message segmentation problem over TCP
Date: Fri, 29 Jun 2001 15:06:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

Content-Length is the defined mechanism. Its not that hard and has been used
for SIP, plus many other somewhat useful protocols, like HTTP. 

-Jonathan R.

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

> -----Original Message-----
> From: Chandra Ravipati [mailto:ravipati@avaya.com]
> Sent: Friday, June 29, 2001 3:01 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] SIP Message segmentation problem over TCP
> 
> 
> 
> Hi,
> 
> I want to know how others are dealing with message 
> segmentation for TCP. 
> 
> Do people use TPKT? or use Content-length: ?
> 
> Using "content-length" is very inefficient and very protocol 
> specific. 
> Why can't we use TPKT?
> 
> 
> Thanks in advance for your participation in this discussion.
> Chandra Ravipati.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementor's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to 
> sip-implementors-request@cs.columbia.edu with "subscribe" in the body.
> 

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


From sip-admin@ietf.org  Fri Jun 29 15:39:42 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24057;
	Fri, 29 Jun 2001 15:39:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23761;
	Fri, 29 Jun 2001 15:38:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23735
	for ; Fri, 29 Jun 2001 15:38:02 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23989
	for ; Fri, 29 Jun 2001 15:37:18 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA12474;
	Fri, 29 Jun 2001 15:42:00 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 29 Jun 2001 15:37:51 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Michael Hammer'" ,
        Jonathan Rosenberg
	 
Cc: "'Ashhar Farhan'" , bpenfield@acmepacket.com,
        sip@ietf.org
Subject: RE: [Sip] Re: reason code in BYE/CANCEL (was[Sip-implementors] an
	 other  problem related to multiple call l egs at UAC)
Date: Fri, 29 Jun 2001 15:37:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Michael Hammer [mailto:mhammer@cisco.com]
> Sent: Friday, June 29, 2001 9:53 AM
> To: Jonathan Rosenberg
> Cc: 'Ashhar Farhan'; bpenfield@acmepacket.com; sip@ietf.org
> Subject: RE: [Sip] Re: reason code in BYE/CANCEL 
> (was[Sip-implementors]
> an other problem related to multiple call l egs at UAC)
> 
> 
> At 04:56 AM 6/29/2001 -0400, Jonathan Rosenberg wrote:
> >Ashar,
> >
> >Thanks for the reminder about international support.
> >
> >There is already support in SIP for management of 
> internationalized reason
> >phrases. This is done through the Accept-Language header. A truly
> >internationalized server would be able to generate reason 
> phrases in the
> >responses by figuring out the preferred language from the 
> Accept-Language
> >header in the INVITE. I doubt any server actually does that, but the
> >facility is built into the protocol.
> >
> >So, for the Reason header in BYE/CANCEL, the same would be 
> done. The UAC
> >generating a BYE would use the Accept-Language from the 2xx 
> to the initial
> >INVITE response to figure out what language to use. Same 
> with a proxy.
> >
> >Would this require storing reason phrases, hardcoded into 
> the UA, for each
> >language supported? Possibly. A more creative approach is to 
> add an http
> >client and then access one of the many fine translation 
> services on the web
> >to translate the reason phrases into the target language as 
> needed. Either
> >way is an implementation choice.
> 
> And to complete the picture, you are saying that the 
> responsibility for 
> using http to access the translation service and return the 
> correct local 
> display belongs to the UA and not a proxy, 

Yes. The entity sending the message should make the reason phrases in the
language of the recipient. This is not the job of the proxy.

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


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


From sip-admin@ietf.org  Fri Jun 29 15:45:20 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24156;
	Fri, 29 Jun 2001 15:45:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23696;
	Fri, 29 Jun 2001 15:36:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23664
	for ; Fri, 29 Jun 2001 15:36:01 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23905
	for ; Fri, 29 Jun 2001 15:35:17 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA12440;
	Fri, 29 Jun 2001 15:40:01 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 29 Jun 2001 15:35:51 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Paul Kyzivat'" ,
        Christer Holmberg
	 
Cc: Jonathan Rosenberg ,
        "'Gonzalo Camarillo'"
	 ,
        sip@ietf.org, mmusic
	 
Subject: RE: [Sip] Two SDP issues
Date: Fri, 29 Jun 2001 15:35:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



 

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Friday, June 29, 2001 9:58 AM
> To: Christer Holmberg
> Cc: Jonathan Rosenberg; 'Gonzalo Camarillo'; sip@ietf.org; mmusic
> Subject: Re: [Sip] Two SDP issues
> 
> 
> Since this seems to be turning into a discussion of problems with the
> existing means of representing Hold, let me add one more:
> 
> The c=0.0.0.0 mechanism for specifying hold doesn't work right for
> connection oriented media (the comedia I-P.) In reality it is another
> manifestation of the problem here with RTCP.

Right, good point.

> 
> Seems to me that if we were in a sendrecv session and I want 
> to put you
> on hold I should send SDP containing a:sendonly. If you 
> receive that and
> are happy with it then you should return a:recvonly. With 
> some kinds of
> transports it may be possible to also specify c=0.0.0.0 in 
> order to free
> up my transport resources for some other purpose, but that varies from
> case to case.
> 
> The situation is a little more complicated if the session is already
> oneway and the receiver wants to go on hold. I haven't worked that out
> yet.

I think that you need to have a hold attribute in addition to the sendonly
attribute since, as you say, the session may already be one way.

If we could ignore backwards compatibility, my preferred approach would be
to have an a=held attribute. If you want to put the stream on hold, you
re-INVITE with the sendonly attribute and add the a=held attribute to that
media. But, thats not going to be backwards compatible.

The only backwards compatible approach is to set the connection IP to
0.0.0.0, but include a held attribute that contains the actual IP address to
use:

a=hold 1.2.3.4

This will cause all the problems to be fixed when both sides support the new
attribute. When the answerer doesn't, you end up falling back to the current
hold mechanism. Ugly, and not my preference, but I see no other viable
alternative without sacrificing backwards compatibility.

-Jonathan R.

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


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


From sip-admin@ietf.org  Fri Jun 29 16:03:48 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24553;
	Fri, 29 Jun 2001 16:03:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24163;
	Fri, 29 Jun 2001 15:55:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24129
	for ; Fri, 29 Jun 2001 15:55:11 -0400 (EDT)
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24378
	for ; Fri, 29 Jun 2001 15:54:26 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA12699;
	Fri, 29 Jun 2001 15:58:42 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id ; Fri, 29 Jun 2001 15:54:33 -0400
Message-ID: 
From: Jonathan Rosenberg 
To: "'Chris Hogg'" ,
        Jonathan Rosenberg
	 ,
        "'Zmolek, Andrew (Andrew)'"
	 ,
        "Mathieu, Marie-Noelle"
	 ,
        sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id
Date: Fri, 29 Jun 2001 15:54:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org



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


Hi Jonathan, 
Jonathan Rosenberg wrote: 
>>Careful; I am not proposing that two call legs with the same Call-ID
convey 
>>any semantics. Specifically, receiving an INVITE from A, while in a call 
>>with B, where the call-id in the INVITE from A equals the call-id in the
leg 
>>with B, does NOT imply that this is a consultative transfer. For that, we 
>>have Replaces, which lists the replaced leg explicitly. 
>>All I am saying is that a Call-ID may be reused for local convenience, if 
>>desired, but that it has NO semantics outside of the entity that selected 
>>that call-id. 
>Given, what you are proposing will this not mean that the definition of a
call 
>needs to be altered?  The reason I ask is that bis-03 defines a call as 
>"identified by a globally unique callID" and "all participants invited by a

>common source".  In the case you describe under the current definition of a

>call this would mean that we would have two calls (under the "all
participants 
>invited by a common source" rule) but with the same callID (hence
contravening 
>the "globally unique callID" part).    

Well, there are a lot of issues, and this is just one. Thinking about this
more, I think its going to be a slippery slope to change what we've had
specified till now, which is that the call-id is globally unique. So, I'm
not so sure anymore that this reuse is a good idea. Unfortunately, there are
some cases where people are reusing call-id in order to perform some kind of
correlations. I think that will ultimately result in inconsistent behaviors
and unusual errors. SIPs "identifier" computations - call legs, calls,
transactions - are already complex enough. Lets not muddy those waters with
further inconsistencies.

So, I would rather say lets be explicit. Call-ID retains its current
definition. It identifies a call, which is, as the current definition
states, the set of participants invited to a session by a common source. We
will need to more formally define that, but I think the basic meaning is
clear. Now, some of the things people are doing that break this are:

1. As Gonzalo indicated, overlap reuses call-id. I think thats not such a
good idea. Lets be explicit. If they need some extra header to correlate
those things, so be it.

2. For a while, we were using the call-id to provide a way to indicate, for
attended transfer, that the incoming call replaced the existing call. I
think there is consensus not to do this, and to rather use Replaces, which
makes it explicit. Thats good.

3. I think some people might be reusing call-ids as conference identifiers.
That should stop as well. draft-rosenberg-sip-conferencing-models has
defined more appropriate mecahnisms for conference 

Comments? 

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-admin@ietf.org  Fri Jun 29 17:52:36 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25997;
	Fri, 29 Jun 2001 17:52:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27479;
	Fri, 29 Jun 2001 17:47:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27449
	for ; Fri, 29 Jun 2001 17:47:42 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25911
	for ; Fri, 29 Jun 2001 17:46:58 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-6.05) id A6F910801A6; Fri, 29 Jun 2001 17:45:29 -0400
Message-ID: <00a001c100e5$25b03420$2300000a@acmepacket.com>
From: "Bob Penfield" 
To: "Jonathan Rosenberg" ,
        "'Chris Hogg'" ,
        "'Zmolek, Andrew \(Andrew\)'" ,
        "Mathieu, Marie-Noelle" ,
        
References: 
Subject: Re: [Sip] RE: [Sipping] Call and call-id
Date: Fri, 29 Jun 2001 17:47:49 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> So, I would rather say lets be explicit. Call-ID retains its current
> definition. It identifies a call, which is, as the current definition
> states, the set of participants invited to a session by a common source.
We
> will need to more formally define that, but I think the basic meaning is
> clear. Now, some of the things people are doing that break this are:
>
> 1. As Gonzalo indicated, overlap reuses call-id. I think thats not such a
> good idea. Lets be explicit. If they need some extra header to correlate
> those things, so be it.

I think overlap's reuse of call-id meets the "set of participants invited to
a session by a common source" definition since the originating gateway is
the "common source". Or does "set of participants invited" mean only those
endpoints that received a singular initial invite that was forked?


_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-admin@ietf.org  Fri Jun 29 18:16:49 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26350;
	Fri, 29 Jun 2001 18:16:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28282;
	Fri, 29 Jun 2001 18:11:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28194
	for ; Fri, 29 Jun 2001 18:11:23 -0400 (EDT)
Received: from iere.net.avaya.com (iere.net.avaya.com [198.152.12.101])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26200
	for ; Fri, 29 Jun 2001 18:10:39 -0400 (EDT)
Received: from iere.net.avaya.com (localhost [127.0.0.1])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5TMAeY03243
	for ; Fri, 29 Jun 2001 18:10:40 -0400 (EDT)
Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16])
	by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id f5TMAeR03226
	for ; Fri, 29 Jun 2001 18:10:40 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C100E8.727C5C90"
Subject: RE: [Sip] RE: [Sipping] Call and call-id
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Date: Fri, 29 Jun 2001 16:11:29 -0600
Message-ID: 
Thread-Topic: [Sip] RE: [Sipping] Call and call-id
Thread-Index: AcD/2kC6ndpxnCGCRVm0/PTNWvhdnQAAQU+w
From: "Zmolek, Andrew (Andrew)" 
To: "Sean Olson (EUS)" ,
        "William Marshall" ,
        "Zmolek, Andrew (Andrew)" 
Cc: , ,
        , ,
        , 
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------_=_NextPart_001_01C100E8.727C5C90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Would the re-use of a state header as a means of tying together multiple
call legs cause problems with anything in the state draft as written? By
persistence, I'm thinking more about using the token to re-establish
some value-added context of a session terminated perhaps even days
earlier, but even without that concept, I need any cookie replacement to
not preclude token use across multiple call legs.
=20
--Andy

-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Wednesday, June 27, 2001 4:43 PM
To: Zmolek, Andrew (Andrew); William Marshall;
zmolek@avaya.ccom.avaya.com
Cc: Sean Olson (EUS); chogg@nortelnetworks.com; jdrosen@dynamicsoft.com;
Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com;
ggf@bighorn.dr.avaya.com; sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id


The State: header is a SIP extension. I believe it can be used
independently
of the other DCS extensions. The real issue is how widespread will the
extension be -- can you depend on "most" clients to support it.=20
=20
I'm not sure what you mean by "token persistence". Do you mean
a State: header that spans multiple call legs?=20
=20
/sean

-----Original Message-----
From: Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com]
Sent: Wednesday, June 27, 2001 4:27 PM
To: William Marshall; zmolek@avaya.ccom.avaya.com
Cc: sean.olson@ericsson.com; chogg@nortelnetworks.com;
jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com;
duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org
Subject: RE: [Sip] RE: [Sipping] Call and call-id



Sounds like the State header may accomplish what we are considering with
cookies; there may be no need to re-invent this. How tightly coupled is
the State header and the DCS call model?  In other words, to support the
State header will a device have to fully conform to DCS? Or is this
required only to generate state?=20

Moreover, how problematic would the introduction of token persistence be
to the State header? Would this cause problems with DCS implementation?
Another worry: If the State header and DCS are joined at the hip, then
this might be too much for simple implementations to swallow even if our
own products were to comply. How much support does this proposal have in
the community right now?

--Andy Zmolek=20
    Technology & Standards Engineer=20
      CTO Standards=20
        Avaya Inc.=20

            zmolek@avaya.com=20
              +1 720 444 4001=20



-----Original Message-----=20
From: William Marshall [ mailto:wtm@research.att.com
 ]=20
Sent: Wednesday, June 27, 2001 11:59 AM=20
To: zmolek@avaya.ccom.avaya.com=20
Cc: sean.olson@ericsson.com; chogg@nortelnetworks.com;=20
jdrosen@dynamicsoft.com; Marie-Noelle.Mathieu@compaq.com;=20
duffy@bighorn.dr.avaya.com; ggf@bighorn.dr.avaya.com; sip@ietf.org=20
Subject: RE: [Sip] RE: [Sipping] Call and call-id=20


State headers operate in both directions.  A UAC that inserts a State
header=20
in the INVITE will see the contents returned in every provisional and
final=20
response, as well as any re-INVITE initiated by the UAS.  A UAS that=20
inserts a State header into a provisional or final response will see=20
the contents returned in every re-INVITE from the UAC, as well as=20
provisional and final responses to requests initiated by the UAS.=20
The State header is documented in draft-ietf-sip-state-01.=20

Rules for handling of State headers with future extensions will need=20
to be specified in the draft defining that extension. In particular,=20
a REFER that is attempting to replace an existing call leg may need=20
the State headers from the previous call leg attached to the new=20
INVITE, along with the From/To/Call-ID.  This is all still
to-be-defined.=20

Bill Marshall=20
wtm@research.att.com=20

-----original messaage-----=20
Subject: RE: [Sip] RE: [Sipping] Call and call-id=20
Date: Wed, 27 Jun 2001 10:57:08 -0600=20
From: "Zmolek, Andrew (Andrew)" =20
To: "Sean Olson (EUS)" ,=20
        "Chris Hogg" ,=20
        "Jonathan Rosenberg" ,=20
        "Mathieu, Marie-Noelle" ,=20
        =20
Cc: "Boyle, Frank J (Duffy)" ,=20
        "Freundlich, Glen G (Glen)" =20

Does DCS state only operate in one direction (ie.only from the SIP=20
transaction initiator)? If so, it would need to be extended to provide=20
equivalent information when two endpoints have hundreds or thousands of=20
individual call legs in hundreds of sessions and either end might=20
initiate any given SIP transaction.=20

Also, what are the rules for passing DCS state with respect in the REFER

case?=20

If DCS state is extensible to provide an equivalent session identifier=20
at both ends of any given call, then I agree that there isn't any need=20
for bi-directional cookies to be grantable and remittable by either end.

But given the current draft's focus on proxies and what appears to be a=20
unidirectional call state, I'm not sure that it's complete enough to=20
solve the whole problem. Please correct me if I've missed something...=20

--Andy=20

-----Original Message-----=20
From: Sean Olson (EUS) [ mailto:sean.olson@ericsson.com
 ]=20
Sent: Wednesday, June 27, 2001 9:19 AM=20
To: Zmolek, Andrew (Andrew); Chris Hogg; Jonathan Rosenberg; Mathieu,=20
Marie-Noelle; sip@ietf.org=20
Subject: RE: [Sip] RE: [Sipping] Call and call-id=20


Have you considered the DCS State: draft for this mechanism?  See=20
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt
 =20
< http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt
 >=20

IMHO, I don't see a need for such a use of a Cookie. Correlating=20
messages to calls is not that difficult. The key thing to note, as you=20
have, is that Call-ID is not necessarily useful for tying multiple call=20
legs together.=20

/sean=20

-----Original Message-----=20
From: Zmolek, Andrew (Andrew) [ mailto:zmolek@avaya.com
 ]=20
Sent: Wednesday, June 27, 2001 9:55 AM=20
To: Chris Hogg; Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org=20
Subject: RE: [Sip] RE: [Sipping] Call and call-id=20


I think it would be good to clarify our terminology, particularly since=20
we sometimes forget SIP does not provide directly for a call with=20
multiple active call legs (i.e. B2BUA is needed to rationalize each=20
individual SIP call with the overall session). I propose we define=20
"call" to mean the two participants in any given transaction and=20
"session" to be some collection of calls associated within a given UA=20
(note that "invited by a common source" is not a complete description=20
since some or all of the invites could have originated outside the UA).=20
 =20
This thread brings out several reasons why Call-ID should not be used to

define a "session" of multiple "calls" as defined above. Mainly because=20
of this, I'm preparing an I-D to address this need through the use of=20
header extensions for cookies, which each UA can independently grant and

accept in order to correlate call legs and potentially provide=20
additional context for a given call. The alternative is vendor-specific=20
headers and a walled garden approach to many features available in=20
conventional PBXes today, and I don't think that's beneficial for SIP in

the long run.=20
 =20
--Andy Zmolek=20
    Technology & Standards Engineer=20
      CTO Standards=20
        Avaya Inc.=20

            zmolek@avaya.com=20
              +1 720 444 4001=20



 =20
 -----Original Message-----=20
From: Chris Hogg [ mailto:chogg@nortelnetworks.com
 ]=20
Sent: Wednesday, June 27, 2001 4:03 AM=20
To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew); Mathieu,=20
Marie-Noelle; sip@ietf.org=20
Subject: RE: [Sip] RE: [Sipping] Call and call-id=20



Hi Jonathan,=20

Jonathan Rosenberg wrote:=20

>Careful; I am not proposing that two call legs with the same Call-ID
convey=20
>any semantics. Specifically, receiving an INVITE from A, while in a
call=20
>with B, where the call-id in the INVITE from A equals the call-id in
the leg=20
>with B, does NOT imply that this is a consultative transfer. For that,
we=20
>have Replaces, which lists the replaced leg explicitly.=20

>All I am saying is that a Call-ID may be reused for local convenience,
if=20
>desired, but that it has NO semantics outside of the entity that
selected=20
>that call-id.=20

Given, what you are proposing will this not mean that the definition of=20
a call needs to be altered?  The reason I ask is that bis-03 defines a=20
call as "identified by a globally unique callID" and "all participants=20
invited by a common source".  In the case you describe under the current

definition of a call this would mean that we would have two calls (under

the "all participants invited by a common source" rule) but with the=20
same callID (hence contravening the "globally unique callID" part).   =20

Comments?=20


Regards,=20

Chris Hogg=20
Nortel Networks.=20


-----Original Message-----=20
From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com
 =20
< mailto:jdrosen@dynamicsoft.com  > ]=20
Sent: 26 June 2001 22:51=20
To: 'Zmolek, Andrew (Andrew)'; Jonathan Rosenberg; Mathieu,=20
Marie-Noelle; sip@ietf.org=20
Subject: RE: [Sip] RE: [Sipping] Call and call-id=20




 =20
-----Original Message-----=20
From: Zmolek, Andrew (Andrew) [ mailto:zmolek@avaya.com
 =20
< mailto:zmolek@avaya.com  > ]=20
Sent: Tuesday, June 26, 2001 12:35 PM=20
To: Jonathan Rosenberg; Mathieu, Marie-Noelle; sip@ietf.org=20
Subject: RE: [Sip] RE: [Sipping] Call and call-id=20


>> >same call-id in the 2 INVITE requests, is this allowed ?=20
>>=20
>> Well, the current spec would indicate that you shouldn't do this:=20
>>=20
>> >The callid MUST be a globally unique identifier and MUST NOT be
reused for=20
>> >later calls.=20
>>=20
>> However, I recall some discussion at an IETF that people were using
the same=20
>> call-id across different call legs as a local identifier to correlate
those=20
>> call legs. With unique From tags and From fields, there really
shouldn't be=20
>> a problem, so I think its OK. However, if we are going to allow it,
the spec=20
>> should reflect it. Comments?=20
>=20
>If that's the proper way to solve this problem, then let's put that in
the=20
>spec. But I'm not convinced that this alone will solve all cases,
especially=20
>when this correlated information needs to be presented by a call leg
attempting=20
>to join (as in the consultative transfer case).=20

Careful; I am not proposing that two call legs with the same Call-ID
convey=20
any semantics. Specifically, receiving an INVITE from A, while in a call

with B, where the call-id in the INVITE from A equals the call-id in the
leg=20
with B, does NOT imply that this is a consultative transfer. For that,
we=20
have Replaces, which lists the replaced leg explicitly.=20

All I am saying is that a Call-ID may be reused for local convenience,
if=20
desired, but that it has NO semantics outside of the entity that
selected=20
that call-id.=20



> It only seems to work when the=20
>correlating entity initiates all the calls. If there's a reliable way
to=20
>correlate an incoming call leg with an existing call, I'd love to hear
about=20
>it.=20

http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00
.txt
 =20
<
http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip-replaces-00
.txt
 >=20

needs updating and adoption though, if we plan to move forward with it.
As=20
you can see, its currently in the morgue.=20

-Jonathan R.=20
---=20
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.=20
Chief Scientist                             First Floor=20
dynamicsoft                                 East Hanover, NJ 07936=20
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050=20
http://www.jdrosen.net   <
http://www.jdrosen.net  >=20
PHONE: (973) 952-5000=20
http://www.dynamicsoft.com   <
http://www.dynamicsoft.com  > =20

_______________________________________________=20
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
 =20
< http://www.ietf.org/mailman/listinfo/sip
 > =20
This list is for NEW development of the core SIP Protocol=20
Use sip-implementors@cs.columbia.edu for questions on current sip=20
Use sipping@ietf.org for new developments on the application of sip=20



_______________________________________________=20
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
 =20
This list is for NEW development of the core SIP Protocol=20
Use sip-implementors@cs.columbia.edu for questions on current sip=20
Use sipping@ietf.org for new developments on the application of sip=20


------_=_NextPart_001_01C100E8.727C5C90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




RE: [Sip] RE: [Sipping] Call and call-id




Would=20
the re-use of a state header as a means of tying together multiple =
call=20
legs cause problems with anything in the state draft as written? By =
persistence,=20
I'm thinking more about using the token to re-establish some value-added =
context=20
of a session terminated perhaps even days earlier, but even without that =

concept, I need any cookie replacement to not preclude token use across =
multiple=20
call legs.


 


--Andy



  
-----Original Message-----
From: Sean Olson (EUS)=20
  [mailto:sean.olson@ericsson.com]
Sent: Wednesday, June 27, =
2001 4:43=20
  PM
To: Zmolek, Andrew (Andrew); William Marshall;=20
  zmolek@avaya.ccom.avaya.com
Cc: Sean Olson (EUS);=20
  chogg@nortelnetworks.com; jdrosen@dynamicsoft.com;=20
  Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com;=20
  ggf@bighorn.dr.avaya.com; sip@ietf.org
Subject: RE: [Sip] =
RE:=20
  [Sipping] Call and call-id


  
The=20
  State: header is a SIP extension. I believe it can be used=20
  independently

  
of=20
  the other DCS extensions. The real issue is how widespread will=20
  the

  
extension be -- can you depend on "most" clients to support =
it.=20
  

  
 

  
I'm=20
  not sure what you mean by "token persistence". Do you =
mean

  
a=20
  State: header that spans multiple call legs? 

  
 

  
/sean

  

    
-----Original Message-----
From: Zmolek, Andrew =
(Andrew)=20
    [mailto:zmolek@avaya.com]
Sent: Wednesday, June 27, 2001 =
4:27=20
    PM
To: William Marshall; =
zmolek@avaya.ccom.avaya.com
Cc:=20
    sean.olson@ericsson.com; chogg@nortelnetworks.com; =
jdrosen@dynamicsoft.com;=20
    Marie-Noelle.Mathieu@compaq.com; duffy@bighorn.dr.avaya.com;=20
    ggf@bighorn.dr.avaya.com; sip@ietf.org
Subject: RE: [Sip] =
RE:=20
    [Sipping] Call and call-id


    
Sounds like the State header may accomplish what =
we are=20
    considering with cookies; there may be no need to re-invent this. =
How=20
    tightly coupled is the State header and the DCS call model?  In =
other=20
    words, to support the State header will a device have to fully =
conform to=20
    DCS? Or is this required only to generate state? 

    
Moreover, how problematic would the introduction =
of token=20
    persistence be to the State header? Would this cause problems with =
DCS=20
    implementation? Another worry: If the State header and DCS are =
joined at the=20
    hip, then this might be too much for simple implementations to =
swallow even=20
    if our own products were to comply. How much support does this =
proposal have=20
    in the community right now?

    
--Andy Zmolek 
   =20
    Technology & Standards Engineer 
      CTO Standards =

        Avaya =
Inc. 

    
          &nbs=
p;=20
    zmolek@avaya.com 
          &nbs=
p;  =20
    +1 720 444 4001 



    
-----Original Message----- 
From:=20
    William Marshall [mailto:wtm@research.att.com]=20
    
Sent: Wednesday, June 27, 2001 11:59 AM =

To: zmolek@avaya.ccom.avaya.com 
Cc:=20
    sean.olson@ericsson.com; chogg@nortelnetworks.com; 
jdrosen@dynamicsoft.com; =
Marie-Noelle.Mathieu@compaq.com;=20
    
duffy@bighorn.dr.avaya.com; =
ggf@bighorn.dr.avaya.com;=20
    sip@ietf.org 
Subject: RE: [Sip] RE: =
[Sipping] Call=20
    and call-id 


    
State headers operate in both directions.  A =
UAC that=20
    inserts a State header 
in the INVITE will =
see the=20
    contents returned in every provisional and final 
response, as well as any re-INVITE initiated by the =
UAS.  A UAS=20
    that 
inserts a State header into a =
provisional or=20
    final response will see 
the contents =
returned in=20
    every re-INVITE from the UAC, as well as 
provisional=20
    and final responses to requests initiated by the UAS. =

The State header is documented in =
draft-ietf-sip-state-01.=20


    
Rules for handling of State headers with future =
extensions=20
    will need 
to be specified in the draft =
defining that=20
    extension. In particular, 
a REFER that is =
attempting=20
    to replace an existing call leg may need 
the State=20
    headers from the previous call leg attached to the new =

INVITE, along with the From/To/Call-ID.  This is all =
still=20
    to-be-defined. 

    
Bill Marshall 
wtm@research.att.com 

    
-----original messaage----- 
Subject:=20
    RE: [Sip] RE: [Sipping] Call and call-id 
Date: Wed,=20
    27 Jun 2001 10:57:08 -0600 
From: "Zmolek, =
Andrew=20
    (Andrew)" <zmolek@avaya.com> 
To: =
"Sean Olson=20
    (EUS)" <sean.olson@ericsson.com>, 
        "Chris Hogg"=20
    <chogg@nortelnetworks.com>, 
        "Jonathan =
Rosenberg"=20
    <jdrosen@dynamicsoft.com>, 
        "Mathieu, =
Marie-Noelle"=20
    <Marie-Noelle.Mathieu@compaq.com>, 
       =20
    <sip@ietf.org> 
Cc: "Boyle, Frank J =
(Duffy)"=20
    <duffy@drmail.dr.avaya.com>, 
        "Freundlich, =
Glen G=20
    (Glen)" <ggf@drmail.dr.avaya.com> 

    
Does DCS state only operate in one direction =
(ie.only from=20
    the SIP 
transaction initiator)? If so, it =
would need=20
    to be extended to provide 
equivalent =
information=20
    when two endpoints have hundreds or thousands of 
individual call legs in hundreds of sessions and either end =

    might 
initiate any given SIP =
transaction.=20


    
Also, what are the rules for passing DCS state =
with respect=20
    in the REFER 
case? 

    
If DCS state is extensible to provide an =
equivalent session=20
    identifier 
at both ends of any given call, =
then I=20
    agree that there isn't any need 
for =
bi-directional=20
    cookies to be grantable and remittable by either end. =

But given the current draft's focus on proxies and what =
appears to be=20
    a 
unidirectional call state, I'm not sure =
that it's=20
    complete enough to 
solve the whole =
problem. Please=20
    correct me if I've missed something... 

    
--Andy 

    
-----Original Message----- 
From:=20
    Sean Olson (EUS) [mailto:sean.olson@ericsson.com]=20
    
Sent: Wednesday, June 27, 2001 9:19 AM =

To: Zmolek, Andrew (Andrew); Chris Hogg; Jonathan =
Rosenberg;=20
    Mathieu, 
Marie-Noelle; sip@ietf.org =

Subject: RE: [Sip] RE: [Sipping] Call and call-id =



    
Have you considered the DCS State: draft for this=20
    mechanism?  See 
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt=20
    
<http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-state-01.txt&g=
t;=20
    

    
IMHO, I don't see a need for such a use of a =
Cookie.=20
    Correlating 
messages to calls is not that =
difficult.=20
    The key thing to note, as you 
have, is =
that Call-ID=20
    is not necessarily useful for tying multiple call 
legs together. 

    
/sean 

    
-----Original Message----- 
From:=20
    Zmolek, Andrew (Andrew) [mailto:zmolek@avaya.com] =

Sent: Wednesday, June 27, 2001 9:55 AM 
To:=20
    Chris Hogg; Jonathan Rosenberg; Mathieu, Marie-Noelle; =
sip@ietf.org=20
    
Subject: RE: [Sip] RE: [Sipping] Call and =
call-id=20
    


    
I think it would be good to clarify our =
terminology,=20
    particularly since 
we sometimes forget SIP =
does not=20
    provide directly for a call with 
multiple =
active=20
    call legs (i.e. B2BUA is needed to rationalize each 
individual SIP call with the overall session). I propose we =

    define 
"call" to mean the two participants =
in any=20
    given transaction and 
"session" to be some =

    collection of calls associated within a given UA 
(note that "invited by a common source" is not a complete=20
    description 
since some or all of the =
invites could=20
    have originated outside the UA). 
 =20
    
This thread brings out several reasons why =
Call-ID should=20
    not be used to 
define a "session" of =
multiple=20
    "calls" as defined above. Mainly because 
of this,=20
    I'm preparing an I-D to address this need through the use of=20
    
header extensions for cookies, which each UA can=20
    independently grant and 
accept in order to =
correlate=20
    call legs and potentially provide 
additional context=20
    for a given call. The alternative is vendor-specific =

headers and a walled garden approach to many features =
available=20
    in 
conventional PBXes today, and I don't =
think=20
    that's beneficial for SIP in 
the long =
run.=20
    
  
--Andy =
Zmolek=20
    
    Technology & Standards=20
    Engineer 
      =
CTO=20
    Standards 
       =20
    Avaya Inc. 

    
          &nbs=
p;=20
    zmolek@avaya.com 
          &nbs=
p;  =20
    +1 720 444 4001 


    

  
 -----Original Message----- 
From: Chris=20
    Hogg [mailto:chogg@nortelnetworks.com<=
/A>]=20
    
Sent: Wednesday, June 27, 2001 4:03 AM =

To: 'Jonathan Rosenberg'; Zmolek, Andrew (Andrew); =
Mathieu,=20
    
Marie-Noelle; sip@ietf.org 
Subject:=20
    RE: [Sip] RE: [Sipping] Call and call-id 



    
Hi Jonathan, 

    
Jonathan Rosenberg wrote: 

    
>Careful; I am not proposing that two call legs =
with the=20
    same Call-ID convey 
>any semantics. =
Specifically,=20
    receiving an INVITE from A, while in a call 
>with=20
    B, where the call-id in the INVITE from A equals the call-id in the =
leg=20
    
>with B, does NOT imply that this is a=20
    consultative transfer. For that, we 
>have=20
    Replaces, which lists the replaced leg explicitly. 

    
>All I am saying is that a Call-ID may be =
reused for=20
    local convenience, if 
>desired, but =
that it has=20
    NO semantics outside of the entity that selected 
>that call-id. 

    
Given, what you are proposing will this not mean =
that the=20
    definition of 
a call needs to be =
altered?  The=20
    reason I ask is that bis-03 defines a 
call =
as=20
    "identified by a globally unique callID" and "all =
participants=20
    
invited by a common source".  In the case =
you describe=20
    under the current 
definition of a call =
this would=20
    mean that we would have two calls (under 
the "all=20
    participants invited by a common source" rule) but with the =

same callID (hence contravening the "globally unique =
callID"=20
    part).    

    
Comments? 


    
Regards, 

    
Chris Hogg 
Nortel =
Networks.=20
    


    
-----Original Message----- 
From:=20
    Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com=20
    
<mailto:jdrosen@dynamicsoft.com>=20
    ] 
Sent: 26 June 2001 22:51 =

To: 'Zmolek, Andrew (Andrew)'; Jonathan Rosenberg; Mathieu, =

    
Marie-Noelle; sip@ietf.org =

Subject: RE: [Sip] RE: [Sipping] Call and call-id=20
    




    
  
-----Original =
Message-----=20
    
From: Zmolek, Andrew (Andrew) [ mailto:zmolek@avaya.com =

<mailto:zmolek@avaya.com>=20
    ] 
Sent: Tuesday, June 26, 2001 12:35 PM=20
    
To: Jonathan Rosenberg; Mathieu, =
Marie-Noelle;=20
    sip@ietf.org 
Subject: RE: [Sip] RE: =
[Sipping] Call=20
    and call-id 


    
>> >same call-id in the 2 INVITE =
requests, is this=20
    allowed ? 
>> 
>>=20
    Well, the current spec would indicate that you shouldn't do this:=20
    
>> 
>> >The=20
    callid MUST be a globally unique identifier and MUST NOT be reused =
for=20
    
>> >later calls. 
>> 
>> However, I =
recall some=20
    discussion at an IETF that people were using the same =

>> call-id across different call legs as a local =
identifier to=20
    correlate those 
>> call legs. With =
unique From=20
    tags and From fields, there really shouldn't be 
>> a problem, so I think its OK. However, if we are =
going to=20
    allow it, the spec 
>> should reflect =
it.=20
    Comments? 
> 
>If that's=20
    the proper way to solve this problem, then let's put that in the=20
    
>spec. But I'm not convinced that this =
alone will=20
    solve all cases, especially 
>when this =
correlated=20
    information needs to be presented by a call leg attempting =

>to join (as in the consultative transfer case). =


    
Careful; I am not proposing that two call legs =
with the same=20
    Call-ID convey 
any semantics. =
Specifically,=20
    receiving an INVITE from A, while in a call 
with B,=20
    where the call-id in the INVITE from A equals the call-id in the leg =

    
with B, does NOT imply that this is a =
consultative=20
    transfer. For that, we 
have Replaces, =
which lists=20
    the replaced leg explicitly. 

    
All I am saying is that a Call-ID may be reused =
for local=20
    convenience, if 
desired, but that it has =
NO=20
    semantics outside of the entity that selected 
that=20
    call-id. 



    
> It only seems to work when the =

>correlating entity initiates all the calls. If there's =
a reliable=20
    way to 
>correlate an incoming call leg =
with an=20
    existing call, I'd love to hear about 
>it.=20
    

    
http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip=
-replaces-00.txt=20
    
<http://www.softarmor.com/sipwg/drafts/morgue/draft-biggs-sip=
-replaces-00.txt>=20
    

    
needs updating and adoption though, if we plan to =
move=20
    forward with it. As 
you can see, its =
currently in=20
    the morgue. 

    
-Jonathan R. 
--- =

Jonathan D. Rosenberg,=20
    =
Ph.D.           &n=
bsp;   =20
    72 Eagle Rock Ave. 
Chief=20
    =
Scientist          &nbs=
p;            =
;     =20
    First Floor 
dynamicsoft         =
;            =
           =20
    East Hanover, NJ 07936 
jdrosen@dynamicsoft.com       =
;            =
 =20
    FAX:   (973) 952-5050 
http://www.jdrosen.net <http://www.jdrosen.net>=20
    
PHONE: (973) 952-5000 
http://www.dynamicsoft.com =
<http://www.dynamicsoft.com>&nb=
sp;=20
    

    
_______________________________________________=20
    
Sip mailing list  http://www.ietf.org/mai=
lman/listinfo/sip=20
    
<http://www.ietf.org/mai=
lman/listinfo/sip> =20
    
This list is for NEW development of the =
core SIP=20
    Protocol 
Use =
sip-implementors@cs.columbia.edu for=20
    questions on current sip 
Use =
sipping@ietf.org for=20
    new developments on the application of sip 



    
_______________________________________________=20
    
Sip mailing list  http://www.ietf.org/mai=
lman/listinfo/sip=20
    
This list is for NEW development of the core SIP=20
    Protocol 
Use =
sip-implementors@cs.columbia.edu for=20
    questions on current sip 
Use =
sipping@ietf.org for=20
    new developments on the application of sip=20



------_=_NextPart_001_01C100E8.727C5C90--

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


From sip-admin@ietf.org  Sat Jun 30 11:26:00 2001
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23260;
	Sat, 30 Jun 2001 11:25:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01708;
	Sat, 30 Jun 2001 11:12:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01683
	for ; Sat, 30 Jun 2001 11:12:11 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23173
	for ; Sat, 30 Jun 2001 11:11:28 -0400 (EDT)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA29098;
	Sat, 30 Jun 2001 11:12:10 -0400 (EDT)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id LAA11973;
	Sat, 30 Jun 2001 11:11:52 -0400 (EDT)
Message-ID: <3B3DEBE7.B126FA7F@cs.columbia.edu>
Date: Sat, 30 Jun 2001 11:10:31 -0400
From: Henning Schulzrinne 
X-Mailer: Mozilla 4.77 [en]C-CCK-MCD BA45DSL  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg 
CC: "'Henning G. Schulzrinne'" ,
        Gordon Ledgard ,
        "'Hidefumi Nakamura'" ,
        "'sip@ietf.org'" 
Subject: Re: [SIP] Congestion control
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol 
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> I agree definitely as well that we want to avoid special cases. It ocurred
> to me later that there aren't really problems with a 503 without
> Retry-After, and that normal response processing will work. The issue with
> #3 only arises when Retry-After is present, and in this case, normal
> response processing may not do the right thing depending on the
> interpretation of Retry-After.
> 

In general, I doubt that 503 with Retry-After will be used frequently,
whatever the precise definition. In almost all cases, overloads will be
temporary and unpredictable, so inserting Retry-After automatically is
going to be difficult. Given that UAs are not likely to automatically
retry and probably shouldn't unless the interval is very short (you
don't really want your phone to automatically and autonomously redial at
2 am the next morning, when the server is free again), the use for call
gapping is probably marginal.

Thus, given its limited applicability, anything that complicates the use
of 503/Retry-After is going to make sure that nobody implements it.

> Why? My interpretation of 503 w/o Retry-After is that the server is
> reporting that it can't handle THIS transaction. It says nothing about any
> others for any future time. So, a client that gets a 503 tries a different
> server. A proxy which forked, and received 503 on all branches, is in a
> situation where, for this transaction, it truly cannot process it, and so
> forwarding the 503 upstream is the right thing to do.

Which gets interesting if it randomly picks one, as the Retry-After will
be a random selection among the branches. It is not even clear what the
right behavior should be here, since one could argue that it should be
the longest interval (to make sure I can reach the user at all forks) or
the shortest (first chance to succeed).

> 
> Retry-After is a different story. Consider the case of UAC A, that sends an
> INVITE to local outbound proxy B, which proxies that to proxy C. Proxy C is
> running on an old 8088 with 32k of RAM. So, when it gets the INVITE, it
> returns a 503 with a Retry-After of 1 day. This is forwarded by B to A. Now,
> how should A interpret this response?
> 
> 1. don't send any requests to proxy B for 1 day
> 2. don't send any requests to the user in the request URI of the original
> INVITE for 1 day
> 
> If the interpretation is 1 - meaning that a retry-after in a 503 means that
> the SERVER is busy - I would argue that forwarding the 503 with that
> retry-after header in tact is the wrong thing to do. The right behavior
> would probably be for the proxy to strip the Retry-After in the 503 before
> forwarding it upstream. In other words, if 503 has a hop-by-hop semantic,
> indicating to the previous server the state of the server generating the
> 503, then 503 with a Retry-After should never be forwarded upstream, since
> its telling the previous server the state of a server two hops down, which
> is not the interpretation of the 503.
> 
> If the interpretation is 2 - meaning that Retry-After in a 503 means that
> the server can't handle requests for that resource, forwarding the
> Retry-After upstream is just fine.
> 
> Now, we inherited 503 from HTTP, where I believe it truly did mean that the
> SERVER was busy. However, the problem we are encountering with this
> interpretation this wasn't an issue for http, since only origin servers ever
> generated these things, and it was only origin servers that were ever the
> busy elements. With proxies playing a larger role, it gets complex.
> 
> So, we have a dilemma. The interpretation of 503 meaning "the server that
> sent you this is busy" is a very useful one for failover and load
> distribution, but has this nasty problem with the Retry-After. The
> interpretation of 503 as "the resource in the URI cannot be reached because
> a server along the way is busy" is not very useful, but more compatible with
> the response processing operations in proxies.
> 
> So, I think we do have an issue here that requires the spec to clearly
> define the semantic of 503, and then we need to deal with any implications
> of that.
> 

With reasonable load-balancing, 503/Retry-After should only occur if the
system is down for maintenance. 503 without Retry-After can occur due to
temporary load spikes. If somebody can keep a server up during
maintenance so that it can still say "503", it would be a better
implementation to have it redirect calls blindly to a fellow server.
Hardly more complicated.

Given the merging issue, I would suggest that taking the minimum
Retry-After value is probably the most information-conserving approach.
This would only occur if all servers failed with either 503 or some
higher 5xx code. Since other 5xx codes could conceivably also use the
Retry-After header, this seems like a generic mechanism. However, I
would treat the Retry-After value as a hint, indicating some notion of
the likelihood of success for future requests, rather than an outright
prohibition against sending a request earlier. In other words, if I see
a response to retry after a day, I won't be too surprised if it still
doesn't work two hours later (and may avoid calling tech support). If I
really need to make the call, this won't and shouldn't deter me.

In any event, a server should probably be able to do just about anything
with the Retry-After header (drop it, pick minimum value, pick random
503 response to forward), given its hint nature.

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip