From mailnull@www1.ietf.org Tue Apr 1 00:35:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13952 for ; Tue, 1 Apr 2003 00:35:08 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h315vR219515 for sipping-archive@odin.ietf.org; Tue, 1 Apr 2003 00:57:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h315vRK19512 for ; Tue, 1 Apr 2003 00:57:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13930 for ; Tue, 1 Apr 2003 00:33:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h315u3K19478; Tue, 1 Apr 2003 00:56:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h315skK19425 for ; Tue, 1 Apr 2003 00:54:46 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13892 for ; Tue, 1 Apr 2003 00:30:39 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h315X2UE015523; Tue, 1 Apr 2003 07:33:03 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A49FA7A; Tue, 1 Apr 2003 07:33:03 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h315X2pn003099; Tue, 1 Apr 2003 08:33:02 +0300 (EET DST) Message-ID: <3E89248E.A4CF6816@lmf.ericsson.se> Date: Tue, 01 Apr 2003 08:33:02 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois Audet CC: "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" Subject: Re: [Sipping] New version of the early media draft References: <2F1FC1DEA077D5119FAD00508BCFD6D20787D68D@zsc3c030.us.nortel.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Francois, you must play the media you get because of the 200 OK-RTP race condition. Therefore, your proposal of sending a 180 response saying "I will send you media, but do not play it", will cause media clipping when the 200 OK arrives later than the first RTP packets. I would like people to note that this problem is unsolvable as long as SIP and RTP follow different paths (as it is the case). Therefore, no matter how many flags we define, the 200 OK-RTP race condition will force us to listen to the media path in order to avoid media clipping. Gonzalo Francois Audet wrote: > > > -----Original Message----- > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > Sent: Saturday, March 29, 2003 07:43 > > To: sipping@ietf.org > > Subject: Re: [Sipping] New version of the early media draft > > > > BTW, I do support your position that no additional indication > > of the presence or absence of early media is required in SIP > > signaling. If UAC receives media, it should play it. > > This is actually the biggest problem I personnally have with the > assumptions on early > media. > > I do not think that this rule of "play media when you receive it" is > implementable > generally, but only in a few very selected cases. > > There are a number of scenarios that I think are problematic: > > 1 - 180 with SDP > > If a 180 is sent with an SDP (for the purpose of telling the far end > what > codec is picked), the called UA the shouldn't be sending silence in > RTP because, according to the current rules, the calling UA would stop > the > locally generated ringing to play the silence packet. (Doing some > heavy duty > DSP parsing to detect if the media is silence or not seems hardly > efficient, > nor reliable). > > A side effect of this is that if there is a NAT/Firewall involved, it > is quite > possible that the binding will expire and the address in the SDP will > be invalid > or the media will be blocked upon answer. > > If an indication was present to indicate if the in-band media was > meant to be > replacing the locally generated tone, we wouldn't have this problem > (i.e., one > could send packets in-band to keep the binding alive). > > > 2 - Sequential calling > > In a sequential calling scenario such as call call forwarding no > answer (section 2.8 > of the SIP services examples Internet Draft). Suppose the following: > > Alice Proxy User B1 User B2 > | | | | > | INVITE F1 | | | > |--------------->| INVITE F2 | | > |(100 Trying) F3 |------------->| | > |<---------------|183 ProgressF4| | SDP > is included with 183 > | 183 Progress F5|<-------------| | > |<---------------| | | > | Both way RTP Established | | > In-band |<=============================>| | > ringing | Request Timeout | > | | | | > | | CANCEL F6 | | > | |------------->| | > | | 200 OK F7 | | > | |<-------------| | > | | 487 F8 | | > | |<-------------| | > | | ACK F9 | | > | |------------->| | > | | | INVITE F10 | > | |--------------------------------->| > | | | 180 Ringing F11 | > | 180 Ringing F12|<---------------------------------| > |<---------------| | | > > The problem with this scenario is that presumably, upon receipt of > 180, > the UA needs to figure out somehow that it should be playing the > locally > generated alerting. This would imply that upon receipt of the 180, the > calling > UA would start a timer and wait until it expires to play the locally > generate > tone. Since ringing is composed of tone-silence-tone, the timer will > have to be > relatively long. While the UA can detect that the 180 is a different > dialog than > the 183, it can not know for sure that the first dialog had been > cancelled > because it could be forking: it has to rely on the media. > > While this is technically feasible, it imposes a big unecessary burden > on > the client, especially if it is a thin client. On a "decomposed" > architecture > (like a stimulus MGCP phone), it makes for pretty nasty signalling, if > possible > at all. > > PS: I'm not saying that the in-band media is necessarily useful in > this scenario. I'm > just pointing out the difficulties of the "play media when received" > mantra. > > 3 - Forking > > As expected, this is the worst. > > Alice Proxy User B1 User B2 > | | | | > | INVITE F1 | | | > |--------------->| INVITE F2 | | > |(100 Trying) F3 |------------->| | > |<---------------|183 ProgressF4| | SDP > is included with 183 > | 183 Progress F5|<-------------| | > |<---------------| | | > | Both way RTP Established | | > In-band |<=============================>| | > ringing | | | | > | | | INVITE F10 | > | |--------------------------------->| > | | | 180 Ringing F11 | > Locally | 180 Ringing F12|<---------------------------------| > generated |<---------------| | 200 OK F13 | > ringing | |<---------------------------------| > > There are of course multiple permutations, such as 2 183s, 2 180s, 1 > 183 followed > by a 180, or 1 180 followed by a 183. And then there might be more > than 2 UAs being > forked-to, so the problem can be really bad. > > There is no way to associate a specific RTP stream with a specific > dialog. The current > draft hints that one UA could randomly play one stream and mute the > others (which will be > very troublesome if the other UA doesn't support UPDATE). This is not > satisfactory and > would result in garbage being played to the user. For this reason, I > believe that the only > reasonable approach in this scenario is to let the 180 override the > 183s (if there is > a 180) and ignore all media. This will of course result that there > might be some level of > clipping on answer (I have yet to see a network where this is a > problem). If there is no > 180, one could play one of the random stream (although I don't think > it is particulary > useful), or play some default "progress" tone that would indicate to > the user that the > call is forked. > > One of the reason I think the 180 indication is more useful than the > 183-with-in-band- > media is that if the in-band from the 183 is saying "This number has > been disconnected, > please hangup" and then a 200 OK comes back (for the 180) wich > connects the call, the user > will be very disoriented (realistically, he will probably have hung-up > anyways). The other > way around (playing the local ringback) will at least keep the user > on-line in case somebody > does answer. The point is that since we can't associate a particular > media stream with > the SIP signalling, we can't just "play the media" when there is > multiple dialogs. > > Many people seem to think that "this is forking, it is trouble, don't > use it, bla bla bla". > Unfortunately, it is extremely useful. Also, it happens all the time > today when parallel > calling is done (different names exists for it, including "multiple > appearances", or > "parallel hunt groups"). If SIP can not properly ring multiple agents > in a pool in parallel, > it won't be terribly useful. > > The only alternative is to wait for the 200 OK to connect media. > Despite the claims of > this introducing clipping on answer, I haven't seen this to be a > problem on existing VoIP > systems (i.e., the time it takes the human to answer is longer than > the interval during > which there could be clipping). > > One added difficulty is that from the calling UA's perspective, we > can't distinguish easily > between case 2 and 3. > > --------- > > My conclusion is that when there are multiple dialogs, we can not > honor media at the > calling UA and have to rely on the SIP provisional responses > exclusively. This goes against > the "play media as soon as you receive it" principle. > > Also, since parallel calling (i.e., forking) is extremely common in > call centers and > within enterprises, it greatly limits the applicability of early > media, or indeed ringing > 2 phones in a private residence. My personal opinion is that it is > really limited to TDM > gateway interworking, and only when there is no forking involved or > multiple dialog > involved. > > Again, I don't believe that the "in-band alerting" indication > necessarily solves this (although > it does help in a few cases). I'm just pointing out that the play > in-band RTP even if 180 is > received is not generally a good idea. The reason I am sending this > email in the context > of this discussion on the in-band ringing indication is that this idea > that playing in-band > media automatically helps keeps on re-surfacing. > > François Audet -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 1 01:50:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15022 for ; Tue, 1 Apr 2003 01:50:01 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h317Dbt02111 for sipping-archive@odin.ietf.org; Tue, 1 Apr 2003 02:13:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h317DbK02108 for ; Tue, 1 Apr 2003 02:13:37 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15015 for ; Tue, 1 Apr 2003 01:49:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h317CbK01532; Tue, 1 Apr 2003 02:12:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h317BkK00910 for ; Tue, 1 Apr 2003 02:11:46 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14933 for ; Tue, 1 Apr 2003 01:47:39 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 31 Mar 2003 22:50:04 -0800 Received: from 194.126.4.207 by lw11fd.law11.hotmail.msn.com with HTTP; Tue, 01 Apr 2003 06:50:04 GMT X-Originating-IP: [194.126.4.207] X-Originating-Email: [simon_issa79@hotmail.com] From: "simon issa" To: sipping@ietf.org Date: Tue, 01 Apr 2003 06:50:04 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Apr 2003 06:50:04.0634 (UTC) FILETIME=[ECD9F3A0:01C2F81A] Subject: [Sipping] sip/simple Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , hii, i am a 5th year telecom engineering undergraduate, and i have chosen my project to be on sip/simple_instant_messaging,but unfortunately i haven't find a good book dealing with this issue. So I'd like to have ,if i may, tutorials about the Instant Messaging with SIP,SIMPLE. Thanks in advance . Yours Sincerely.... _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 1 02:31:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27704 for ; Tue, 1 Apr 2003 02:31:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h317skQ05590 for sipping-archive@odin.ietf.org; Tue, 1 Apr 2003 02:54:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h317skK05587 for ; Tue, 1 Apr 2003 02:54:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27686 for ; Tue, 1 Apr 2003 02:30:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h317oaK05351; Tue, 1 Apr 2003 02:50:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h317noK05306 for ; Tue, 1 Apr 2003 02:49:50 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27542 for ; Tue, 1 Apr 2003 02:25:41 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h317S6UE017186; Tue, 1 Apr 2003 09:28:06 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4KM2NS; Tue, 1 Apr 2003 09:28:02 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h317S2pn010202; Tue, 1 Apr 2003 10:28:02 +0300 (EET DST) Message-ID: <3E893F81.3080509@lmf.ericsson.se> Date: Tue, 01 Apr 2003 10:28:01 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: sipping@ietf.org, Jon Peterson , Mark Watson Subject: Re: [Sipping] Early media; a summary after the IETF References: <0449D80A0E9B614A83FA9031B07E8D3B257940@stntexch2.va.neustar.com> <000e01c2f609$d5730a20$2300000a@BPenfield> <3E87EEC4.1F974505@lmf.ericsson.se> <3E8858AB.80401@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom, yes, this was mentioned in the meeting. In any event, it is important that H.248 supports this type of message (generate ringback until media arrives), since it is needed regardless of any new flags or extensions that we could come up with. It would be good if somebody could work on that. Thanks, Gonzalo Tom Taylor wrote: > Your charts do not reflect an important difference between MGCP and > Megaco/H.248. In MGCP, it is possible to tell the MG to automatically > terminate application of ringing tone upon detection of incoming media. > In Megaco/H.248, the media event is detected on one termination, but the > ringing tone is being applied to another. This means that the MG has to > report media detection to the MGC, and then the MGC has to request that > ringing tone application be stopped. It has occurred to me upon > reflection that there might be a way around this, but for the moment > that is the case. > > Gonzalo Camarillo wrote: > >> Folks, >> >> here you have a summary of what happened in the IETF regarding early >> media. >> >> We planned to have an ad-hoc meeting, but since we managed to get more >> meeting time than expected for this issue and some of the persons >> involved in the mailing list discussions were not available for an >> ad-hoc meeting (some of them were not even in San Francisco), we did not >> finally have the ad-hoc. >> >> Regarding the discussions during the second SIPPING session, the main >> input was slide number 3 of >> >> http://www.softarmor.com/sipping/meets/ietf56/slides/Gonzalo-sipping-early-media.ppt >> >> >> That slide does not discuss the encoding issue. It focuses on the >> requirements or the gains that adding a SIP "there is media coming" (or >> "don't generate local ringback") indication would bring. >> >> The conclusion of that slide is that a message with "generate local >> ringback until media arrives" should be provided by the protocol (e.g., >> MGCP or H.248) between the MG and the MGC **REGARDLESS** of whether or >> not we create a "there is media coming" flag. >> >> Therefore, assuming that the MG is in accept-media state as soon as the >> INVITE is sent, the only gain that a "there is media coming" would bring >> would be saving one message from the MGC to the MG every time a 180 with >> a flag is received. The gain is zero for 180 responses without the flag. >> >> The question is: are people after this optimization (saving of one >> message in some circumstances) or there is somebody with something else >> in mind? >> >> >> In any event, the conclusion of the meeting was that I will be gathering >> use cases where a "there is media coming" flag would be useful. Please, >> send any use case you have in mind and I will compile them in a >> document. We hope that such a document help us figure out which >> requirement is missing. >> >> We also may organize a conference call in some weeks to further discuss >> the issue, if needed. >> >> Thanks, >> >> Gonzalo >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 1 02:58:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28179 for ; Tue, 1 Apr 2003 02:58:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h318MVS07508 for sipping-archive@odin.ietf.org; Tue, 1 Apr 2003 03:22:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h318MVK07505 for ; Tue, 1 Apr 2003 03:22:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28157 for ; Tue, 1 Apr 2003 02:58:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h318IOK07313; Tue, 1 Apr 2003 03:18:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h318HAK07246 for ; Tue, 1 Apr 2003 03:17:10 -0500 Received: from smail.alcatel.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28094 for ; Tue, 1 Apr 2003 02:53:00 -0500 (EST) From: David.Rio@alcatel.fr Received: from frmail28.netfr.alcatel.fr (frmail28.netfr.alcatel.fr [155.132.251.28]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id h317tIoI011633 for ; Tue, 1 Apr 2003 09:55:18 +0200 Received: from alcatel.fr ([159.217.209.70]) by frmail28.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2003040109551633:1576 ; Tue, 1 Apr 2003 09:55:16 +0200 Message-ID: <3E894514.8000602@alcatel.fr> Date: Tue, 01 Apr 2003 09:51:48 +0200 User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr, en MIME-Version: 1.0 To: sipping@ietf.org X-MIMETrack: Itemize by SMTP Server on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/01/2003 09:55:16, Serialize by Router on FRMAIL28/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/01/2003 09:55:18, Serialize complete at 04/01/2003 09:55:18 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Virus-Scanned: by amavisd-new Content-Transfer-Encoding: 7bit Subject: [Sipping] Comments on 'early media draft' and 'netann draft' Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello all At present, there are TWO 'concurrent' drafts that are dealing with early media treatments. I can hardly understand why there are still 2 drafts ; they shoud be merged. Or at least a part of Eric's document should be moved to Gonzalo document. - The first from Gonzalo is describing from a general point of view how early media buffers should be played ; without considering why those RTP buffers should be submitted. It is a good approach I think ; more specially from the point of view of UAC who do not have to take care of why it is receiving those RTP buffers. There is a major discussion around this draft on what priority should be given to local ringback and RTP buffers when 180 message has been received while the distant UAS is already streaming RTP buffers. Several points to consider : * the 180 message is 'RINGING'. We do not have to change its meaning. It is the message that must make the remote UAC to ring. Either by playing tone, either by showing a popup, ... We do not have to presume how the user will be alerted. * Prority should not be given to incoming early RTP buffers unless clearly specified by the remote. It is the default behaviour implemented my most SIP terminals. SIP and RTP streams are two different links and we have to synchronize them. An UAS will receive an INVITE with an offered SDP, send a 180, initiates a RTP stream using the offered SDP, prepare the answered SDP and send a 200 response. => The remote UAC must give priority to local ringback until it is notify to give other priorities (200, 183,...). The 183 message is clearly available 'to convey information about the progress of the call that is not otherwise classified'. To notify the remote UAC that it should give priority to early RTP buffers we have to override default behaviour by sending a 183 message. Here, the content of this message could be discussed but probably we should use the content of the SDP to change priorities maybe using 'sendonly', 'recvonly' parameters... If the remote terminal supports it, of course a PrAck message should be asked. Except this discussion point, I approve this document. - The second draft is from Eric. He is focusing on a specific use case. Eric is describing how a proxy or a b2b application server should forward an INVITE to a media server, adding some parameters to ask him to run media treatments. Such media treatments could be played before call establishment or after. The proxy approach is so easy to implement that is why I think it must be supported by the solution. But when you will want to extend this mechanism to make your media server to report DTMF interactivity for example, the application server will have to be in b2b mode. I approve Eric's document. But several comments : * Parameters that describe the announcement to be played are submitted as request URI private parameters. The behaviour of SIP proxies whith those parameters is not clear : some of them forward those parameters ; others remove them (e.g. SER). A clear position from the WG is needed. If the proxy should not forward them, then those parameters should be submitted somewhere else. * 487 code. There is really a need for a such call flow : early media treatment and hang up by a media server without sending 200 OK. It is a normal scenario and in now way an existing ERROR code should be submitted to the UAC. Then, we have to provide a solution. The 487 code seemed a good solution but RFC 3261 says that it should be used only after a BYE or CANCEL request. Then it should be extended maybe but what about existing B2B proxies and SIP terminals ? On the other hand, Eric reported that 'we do not want to break meaningful forking proxies' ; I agree with this position. => We have to find a concensus on this open point. - I made some quick tests of early media with two very used SIP softphone : eStara and Ubiquity. None support PrAck message. * eStara can play early media without problem. It can receive a 183 message with a SDP. Then it plays the incoming RTP buffers. But (of course) it does not support the 487 response and does not detect the call has been hang up. This illustrate the problem raised earlier of the support of the 487 message in this state of existing equipments state machine. * Ubiquity does not support at all early media. Impossible to make it playing early RTP buffers. -- David Rio Alcatel CIT - Rennes ASD France 33 2 99 87 47 18 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 1 06:00:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03691 for ; Tue, 1 Apr 2003 06:00:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31BNwV19277 for sipping-archive@odin.ietf.org; Tue, 1 Apr 2003 06:23:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31BNwK19274 for ; Tue, 1 Apr 2003 06:23:58 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03673 for ; Tue, 1 Apr 2003 05:59:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31BMxK19230; Tue, 1 Apr 2003 06:22:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31BLKK19190 for ; Tue, 1 Apr 2003 06:21:20 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03607 for ; Tue, 1 Apr 2003 05:57:05 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h31AxUrs011982; Tue, 1 Apr 2003 12:59:30 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4R2AAC; Tue, 1 Apr 2003 12:59:31 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h31AxVpn024636; Tue, 1 Apr 2003 13:59:31 +0300 (EET DST) Message-ID: <3E897111.8020204@lmf.ericsson.se> Date: Tue, 01 Apr 2003 13:59:29 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: sipping@ietf.org Subject: Re: [Sipping] Comments to draft-ietf-sipping-aaa-reqs-02 WGLC References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9019451E1@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Aki, thanks for the detailed comments. I have added most of them to the draft. They will appear in the next revision of the draft, which will include all the comments received during the currently ongoing WGLC. Gonzalo aki.niemi@nokia.com wrote: > Hi, > > Here are a few comments/suggestions: > > - Ch 1.1 on Terminology > * Accounting has a very nice definition in RFC 2975, suggestion is > to use that, or the one from Diameter base protocol. > * Home AAA server definition is confusing. > * Online/offline accounting definitions might also benefit from RFC 2975 > definition on real time accounting. > * The last four definitions could also be copied from RFC 3261 > > - Ch 2, first paragraph; the motivational text doesn't seem really assuring and > begs the question "If a requirement isn't intended to be supported, why > list it?" Perhaps just say that different deployment scenarios may have > a different set of requirements, e.g., a subset of the requirements listed > in the chapter. > > - Ch 2.1.5., I think I understand what is meant here, but the sentence could > be clearer about what it means for a SIP entity to "have" a user. Does it imply > an administration type relationship, like say a registrar or a presence agent? > > - Ch 2.2.2, This should probably be split into two separate requirements. I think > the first sentence is about authentication between the SIP server and > AAA server, whereas the latter talks about authentication schemes > supported by the SIP-AAA interface. I.e., authentication between the UA and > the SIP server. > > - Ch 2.3.1, The note about CANCEL below the requirment may well be true, but the > last sentence contradicts with requirement 2.2.1. After all, if the CANCEL > can't be authenticated, there's no way to determine that the sender is the > one who originally generated the request to be cancelled. > > - Ch 2.3.3, Seems that Req 2.3.2 already at least partly covers this requirement. > Also, may I suggest that the user profile example be separated > from the text describing the requirement, perhaps as a note or a separate > paragraph. > > - Ch 2.3.4, similar to de-authorization, there should also be a requirement about > re-authorization. This would be useful in tasks that require refreshes, such > as registrations and subscriptions. > > - Ch 2.4, first paragraph; I think much of the motivational text could well be > omitted if the term "accounting" had been properly defined in Ch 1.1. > > - Ch 2.4.1, This seems like a good thing, but it's hard to really understand what > is required. Is it that accounting information is granular? I can imagine this > to be useful not only in session duration but also in other services. > > - Ch 2.4.2 and 2.4.3, I don't quite understand the meaning of "direct bearing on". > I'm sure there's a better term to describe the relationship. Perhaps "link" or > "correlation"? > > - Ch 2.4.5, I believe this is a general requirement, and not only relevant to > charging. > > - Ch 2.4.6, This requirement again talks about charging when I don't think it > needs to. > > - Ch 2.4.10, Suggestion is to separate the example from the requirement text. > Also, the example seems to also talk about authorization based on real-time > accounting data - perhaps a requirement for the Authorization section? > > Cheers, > Aki > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 1 07:34:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07923 for ; Tue, 1 Apr 2003 07:34:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31CwWX25388 for sipping-archive@odin.ietf.org; Tue, 1 Apr 2003 07:58:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31CwVK25385 for ; Tue, 1 Apr 2003 07:58:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07898 for ; Tue, 1 Apr 2003 07:34:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31CvhK25345; Tue, 1 Apr 2003 07:57:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31CueK25305 for ; Tue, 1 Apr 2003 07:56:40 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07872 for ; Tue, 1 Apr 2003 07:32:23 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h31CYlUE027911; Tue, 1 Apr 2003 14:34:48 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A49JKKA; Tue, 1 Apr 2003 14:34:48 +0200 Received: from lmf.ericsson.se (vrrch2-177147.am.ericsson.se [138.85.177.147]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h31CYjpn000733; Tue, 1 Apr 2003 15:34:45 +0300 (EET DST) Message-ID: <3E89876C.35B6C590@lmf.ericsson.se> Date: Tue, 01 Apr 2003 15:34:52 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Francois Audet , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" Subject: Re: [Sipping] New version of the early media draft References: <2F1FC1DEA077D5119FAD00508BCFD6D20787D68D@zsc3c030.us.nortel.com> <3E89248E.A4CF6816@lmf.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Forking is always going to a problem, and that is part of the issues I have on the "must play all media you receive" stuff. In forking cases a UAC may use whatever local policy to decide which media stream will be played to the user. Of course, the UAC may mix all streams together, and there will be a risk the user will only hear a mess, but that is local policy, and should not be required behaviour. Also, like I said earlier, there are cases where a UAC may not be able, or may not want to, play media before it receives a remote SDP for that stream. I think we should at least have an early dialog established before we put media handling requirements on the nodes - then we can discuss about how UAS makes decissions related to local ringback etc. So, therefore I think it is important for a UAS to send his SDP as soon as possible - NO MATTER if it's sent in 180 or 183, and NO MATTER if he actually intends to send early media or not (even if the UAS is not going to send any media before 200 OK, the UAC would still need the SDP before that, to establish an early dialog, to prevent clipping). Just my thoughts... Regards, Christer Holmberg Ericsson Finland Gonzalo Camarillo wrote: > Francois, > > you must play the media you get because of the 200 OK-RTP race > condition. Therefore, your proposal of sending a 180 response saying "I > will send you media, but do not play it", will cause media clipping when > the 200 OK arrives later than the first RTP packets. > > I would like people to note that this problem is unsolvable as long as > SIP and RTP follow different paths (as it is the case). Therefore, no > matter how many flags we define, the 200 OK-RTP race condition will > force us to listen to the media path in order to avoid media clipping. > > Gonzalo > > Francois Audet wrote: > > > > > -----Original Message----- > > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > > Sent: Saturday, March 29, 2003 07:43 > > > To: sipping@ietf.org > > > Subject: Re: [Sipping] New version of the early media draft > > > > > > BTW, I do support your position that no additional indication > > > of the presence or absence of early media is required in SIP > > > signaling. If UAC receives media, it should play it. > > > > This is actually the biggest problem I personnally have with the > > assumptions on early > > media. > > > > I do not think that this rule of "play media when you receive it" is > > implementable > > generally, but only in a few very selected cases. > > > > There are a number of scenarios that I think are problematic: > > > > 1 - 180 with SDP > > > > If a 180 is sent with an SDP (for the purpose of telling the far end > > what > > codec is picked), the called UA the shouldn't be sending silence in > > RTP because, according to the current rules, the calling UA would stop > > the > > locally generated ringing to play the silence packet. (Doing some > > heavy duty > > DSP parsing to detect if the media is silence or not seems hardly > > efficient, > > nor reliable). > > > > A side effect of this is that if there is a NAT/Firewall involved, it > > is quite > > possible that the binding will expire and the address in the SDP will > > be invalid > > or the media will be blocked upon answer. > > > > If an indication was present to indicate if the in-band media was > > meant to be > > replacing the locally generated tone, we wouldn't have this problem > > (i.e., one > > could send packets in-band to keep the binding alive). > > > > > > 2 - Sequential calling > > > > In a sequential calling scenario such as call call forwarding no > > answer (section 2.8 > > of the SIP services examples Internet Draft). Suppose the following: > > > > Alice Proxy User B1 User B2 > > | | | | > > | INVITE F1 | | | > > |--------------->| INVITE F2 | | > > |(100 Trying) F3 |------------->| | > > |<---------------|183 ProgressF4| | SDP > > is included with 183 > > | 183 Progress F5|<-------------| | > > |<---------------| | | > > | Both way RTP Established | | > > In-band |<=============================>| | > > ringing | Request Timeout | > > | | | | > > | | CANCEL F6 | | > > | |------------->| | > > | | 200 OK F7 | | > > | |<-------------| | > > | | 487 F8 | | > > | |<-------------| | > > | | ACK F9 | | > > | |------------->| | > > | | | INVITE F10 | > > | |--------------------------------->| > > | | | 180 Ringing F11 | > > | 180 Ringing F12|<---------------------------------| > > |<---------------| | | > > > > The problem with this scenario is that presumably, upon receipt of > > 180, > > the UA needs to figure out somehow that it should be playing the > > locally > > generated alerting. This would imply that upon receipt of the 180, the > > calling > > UA would start a timer and wait until it expires to play the locally > > generate > > tone. Since ringing is composed of tone-silence-tone, the timer will > > have to be > > relatively long. While the UA can detect that the 180 is a different > > dialog than > > the 183, it can not know for sure that the first dialog had been > > cancelled > > because it could be forking: it has to rely on the media. > > > > While this is technically feasible, it imposes a big unecessary burden > > on > > the client, especially if it is a thin client. On a "decomposed" > > architecture > > (like a stimulus MGCP phone), it makes for pretty nasty signalling, if > > possible > > at all. > > > > PS: I'm not saying that the in-band media is necessarily useful in > > this scenario. I'm > > just pointing out the difficulties of the "play media when received" > > mantra. > > > > 3 - Forking > > > > As expected, this is the worst. > > > > Alice Proxy User B1 User B2 > > | | | | > > | INVITE F1 | | | > > |--------------->| INVITE F2 | | > > |(100 Trying) F3 |------------->| | > > |<---------------|183 ProgressF4| | SDP > > is included with 183 > > | 183 Progress F5|<-------------| | > > |<---------------| | | > > | Both way RTP Established | | > > In-band |<=============================>| | > > ringing | | | | > > | | | INVITE F10 | > > | |--------------------------------->| > > | | | 180 Ringing F11 | > > Locally | 180 Ringing F12|<---------------------------------| > > generated |<---------------| | 200 OK F13 | > > ringing | |<---------------------------------| > > > > There are of course multiple permutations, such as 2 183s, 2 180s, 1 > > 183 followed > > by a 180, or 1 180 followed by a 183. And then there might be more > > than 2 UAs being > > forked-to, so the problem can be really bad. > > > > There is no way to associate a specific RTP stream with a specific > > dialog. The current > > draft hints that one UA could randomly play one stream and mute the > > others (which will be > > very troublesome if the other UA doesn't support UPDATE). This is not > > satisfactory and > > would result in garbage being played to the user. For this reason, I > > believe that the only > > reasonable approach in this scenario is to let the 180 override the > > 183s (if there is > > a 180) and ignore all media. This will of course result that there > > might be some level of > > clipping on answer (I have yet to see a network where this is a > > problem). If there is no > > 180, one could play one of the random stream (although I don't think > > it is particulary > > useful), or play some default "progress" tone that would indicate to > > the user that the > > call is forked. > > > > One of the reason I think the 180 indication is more useful than the > > 183-with-in-band- > > media is that if the in-band from the 183 is saying "This number has > > been disconnected, > > please hangup" and then a 200 OK comes back (for the 180) wich > > connects the call, the user > > will be very disoriented (realistically, he will probably have hung-up > > anyways). The other > > way around (playing the local ringback) will at least keep the user > > on-line in case somebody > > does answer. The point is that since we can't associate a particular > > media stream with > > the SIP signalling, we can't just "play the media" when there is > > multiple dialogs. > > > > Many people seem to think that "this is forking, it is trouble, don't > > use it, bla bla bla". > > Unfortunately, it is extremely useful. Also, it happens all the time > > today when parallel > > calling is done (different names exists for it, including "multiple > > appearances", or > > "parallel hunt groups"). If SIP can not properly ring multiple agents > > in a pool in parallel, > > it won't be terribly useful. > > > > The only alternative is to wait for the 200 OK to connect media. > > Despite the claims of > > this introducing clipping on answer, I haven't seen this to be a > > problem on existing VoIP > > systems (i.e., the time it takes the human to answer is longer than > > the interval during > > which there could be clipping). > > > > One added difficulty is that from the calling UA's perspective, we > > can't distinguish easily > > between case 2 and 3. > > > > --------- > > > > My conclusion is that when there are multiple dialogs, we can not > > honor media at the > > calling UA and have to rely on the SIP provisional responses > > exclusively. This goes against > > the "play media as soon as you receive it" principle. > > > > Also, since parallel calling (i.e., forking) is extremely common in > > call centers and > > within enterprises, it greatly limits the applicability of early > > media, or indeed ringing > > 2 phones in a private residence. My personal opinion is that it is > > really limited to TDM > > gateway interworking, and only when there is no forking involved or > > multiple dialog > > involved. > > > > Again, I don't believe that the "in-band alerting" indication > > necessarily solves this (although > > it does help in a few cases). I'm just pointing out that the play > > in-band RTP even if 180 is > > received is not generally a good idea. The reason I am sending this > > email in the context > > of this discussion on the in-band ringing indication is that this idea > > that playing in-band > > media automatically helps keeps on re-surfacing. > > > > François Audet > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 1 08:45:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10416 for ; Tue, 1 Apr 2003 08:45:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31E8kx02656 for sipping-archive@odin.ietf.org; Tue, 1 Apr 2003 09:08:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31E8kK02653 for ; Tue, 1 Apr 2003 09:08:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10348 for ; Tue, 1 Apr 2003 08:44:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31E7lK02610; Tue, 1 Apr 2003 09:07:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31E63K00605 for ; Tue, 1 Apr 2003 09:06:03 -0500 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 IAA10113; Tue, 1 Apr 2003 08:41:45 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.5) with ESMTP id h31DggN17061; Tue, 1 Apr 2003 16:42:42 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 1 Apr 2003 16:44:11 +0300 Received: from daebh002.NOE.Nokia.com ([172.18.242.232]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 16:44:09 +0300 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 1 Apr 2003 07:44:05 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Tue, 1 Apr 2003 07:44:03 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcL0Oh0S9278a4G2TwGrlMF2MA/VLAAjOLXAAAxkv+AA1e7EEA== To: Cc: , X-OriginalArrivalTime: 01 Apr 2003 13:44:05.0524 (UTC) FILETIME=[C32CF540:01C2F854] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h31E63K00611 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Robert, > I don't think it is a problem with SigComp multiplexing, but > more like a SIP internal issue. What if there is a TCP stream > of SIP messages and the Content-Length header is missing or > false? They will screw up the same way with or without > SigComp. Since TCP is a reliable transport, this only happens for a mis-behaved SIP sender. But that is not the "multiplexing" problem I mentioned below, which happens even "during normal functioning" (see below). > During normal functioning both SIP and SigComp > provide their own flow separation mechanism and they work just fine. I don't think so. That is what I intended to show by the example, i.e. the issue to "multiplex uncompressed application messages and SigComp messages on the same port". One solution, as I mentioned before, is to require sigcomp receiver has the ability to parse uncompressed application messages and detect the end. (Of course, I saw Carsten's email and I need understand his point of view, which says there is no such "multiplexing" and it is not possible and necessary.) BR, Zhigang _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 1 09:44:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14909 for ; Tue, 1 Apr 2003 09:44:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31F8Ex23745 for sipping-archive@odin.ietf.org; Tue, 1 Apr 2003 10:08:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31F8EK23742 for ; Tue, 1 Apr 2003 10:08:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14890 for ; Tue, 1 Apr 2003 09:43:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31F7KK23306; Tue, 1 Apr 2003 10:07:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31F6BK22046 for ; Tue, 1 Apr 2003 10:06:11 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14677 for ; Tue, 1 Apr 2003 09:41:54 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h31EhD904174; Tue, 1 Apr 2003 08:43:13 -0600 Subject: RE: Apology for RE: [Sipping] A WinXP patch From: Ben Campbell To: Dean Willis Cc: "'Cullen Jennings'" , sipping@ietf.org In-Reply-To: <000d01c2f7b8$8b3143e0$fe0c0c42@txdwillis> References: <000d01c2f7b8$8b3143e0$fe0c0c42@txdwillis> Content-Type: text/plain Message-Id: <1049208142.5746.6.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 01 Apr 2003 08:42:22 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Nothing that couldn't be solved with s/mime ;-) On Mon, 2003-03-31 at 13:05, Dean Willis wrote: > network asserted From:? > > haha > > -- > Dean > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Cullen Jennings > Sent: Thursday, March 27, 2003 1:12 PM > To: sipping@ietf.org > Subject: Apology for RE: [Sipping] A WinXP patch > > > I did not sent any patches - certainly not to XP :-) Cullen > (the guy with the fluffy hair) > -----Original Message----- > From: sipping-admin@ietf.org > [mailto:sipping-admin@ietf.org]On Behalf Of fluffy > Sent: Wednesday, March 26, 2003 3:50 PM > To: sipping@ietf.org > Subject: [Sipping] A WinXP patch > > > This is a WinXP patch > I expect you would like it. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 1 10:56:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23121 for ; Tue, 1 Apr 2003 10:56:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31GKIQ16086 for sipping-archive@odin.ietf.org; Tue, 1 Apr 2003 11:20:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31GKIK16083 for ; Tue, 1 Apr 2003 11:20:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23109 for ; Tue, 1 Apr 2003 10:55:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31GJOK15913; Tue, 1 Apr 2003 11:19:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31GHkK15513 for ; Tue, 1 Apr 2003 11:17:46 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22906 for ; Tue, 1 Apr 2003 10:53:26 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31Ftju01065; Tue, 1 Apr 2003 07:55:45 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 07:55:31 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20787D9D7@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Gonzalo Camarillo'" Cc: "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" Subject: RE: [Sipping] New version of the early media draft Date: Tue, 1 Apr 2003 07:55:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F867.1D867068" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2F867.1D867068 Content-Type: text/plain Gonzallo, Just a clarification. I am not proposing that we generally do NOT play the media if received when a 180 was sent. Indeed we should play it when possible. I am saying that if there are multiple dialogs (as when there is forking), and at least one of the forks wants to play early media, we can not play it and have to wait until answer. The numerous reasons were described in my past email. There is no forks, or when all the forks are NOT using early media, we could play the media (that seems to suggest discouraging allowing sending early media with 180, or at least to have the magic flag discussed earlier). Finally, I don't think the allege "race" condition is a real problem. I've seen many implementations where multiple sets are ringing, and there is no perceivable clipping. There are things that can be done at the UI level to minimize that risk. If there was perceivable clipping, then SIP wouldn't support call centers, and simultaneous of multiple lines when one of them does early media. That would be unacceptable. > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Monday, March 31, 2003 21:33 > To: Audet, Francois [SC100:4K02:EXCH] > Cc: 'Bob Penfield'; 'sipping@ietf.org'; 'Jon PETERSON > (Jon.Peterson@neustar.com)'; 'Christer Holmberg' > Subject: Re: [Sipping] New version of the early media draft > > > Francois, > > you must play the media you get because of the 200 OK-RTP > race condition. Therefore, your proposal of sending a 180 > response saying "I will send you media, but do not play it", > will cause media clipping when the 200 OK arrives later than > the first RTP packets. > > I would like people to note that this problem is unsolvable > as long as SIP and RTP follow different paths (as it is the > case). Therefore, no matter how many flags we define, the 200 > OK-RTP race condition will force us to listen to the media > path in order to avoid media clipping. > > Gonzalo ------_=_NextPart_001_01C2F867.1D867068 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] New version of the early media draft

Gonzallo,

Just a clarification. I am not proposing that we = generally do NOT play the media
if received when a 180 was sent. Indeed we should = play it when possible.

I am saying that if there are multiple dialogs (as = when there is forking), and
at least one of the forks wants to play early media, = we can not play it and have
to wait until answer. The numerous reasons were = described in my past email. There
is no forks, or when all the forks are NOT using = early media, we could play the
media (that seems to suggest discouraging allowing = sending early media with 180,
or at least to have the magic flag discussed = earlier).

Finally, I don't think the allege "race" = condition is a real problem. I've seen
many implementations where multiple sets are = ringing, and there is no perceivable
clipping. There are things that can be done at the = UI level to minimize that risk.

If there was perceivable clipping, then SIP wouldn't = support call centers, and
simultaneous of multiple lines when one of them does = early media. That would be
unacceptable.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: Monday, March 31, 2003 21:33
> To: Audet, Francois [SC100:4K02:EXCH]
> Cc: 'Bob Penfield'; 'sipping@ietf.org'; 'Jon = PETERSON
> (Jon.Peterson@neustar.com)'; 'Christer = Holmberg'
> Subject: Re: [Sipping] New version of the early = media draft
>
>
> Francois,
>
> you must play the media you get because of the = 200 OK-RTP
> race condition. Therefore, your proposal of = sending a 180
> response saying "I will send you media, = but do not play it",
> will cause media clipping when the 200 OK = arrives later than
> the first RTP packets.
>
> I would like people to note that this problem = is unsolvable
> as long as SIP and RTP follow different paths = (as it is the
> case). Therefore, no matter how many flags we = define, the 200
> OK-RTP race condition will force us to listen = to the media
> path in order to avoid media clipping.
>
> Gonzalo

------_=_NextPart_001_01C2F867.1D867068-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 1 17:30:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18606 for ; Tue, 1 Apr 2003 17:30:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31MsJd27834 for sipping-archive@odin.ietf.org; Tue, 1 Apr 2003 17:54:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MsIK27831 for ; Tue, 1 Apr 2003 17:54:18 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18601 for ; Tue, 1 Apr 2003 17:29:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MrHK27791; Tue, 1 Apr 2003 17:53:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31MpiK27708 for ; Tue, 1 Apr 2003 17:51:44 -0500 Received: from zcars04f.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18543 for ; Tue, 1 Apr 2003 17:27:17 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h31MTZP21047; Tue, 1 Apr 2003 17:29:35 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDFDB0Q0; Tue, 1 Apr 2003 17:29:36 -0500 Received: from nortelnetworks.com (acart1bt.ca.nortel.com [47.129.129.36]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWL62; Tue, 1 Apr 2003 17:29:35 -0500 Message-ID: <3E8A12CE.7070204@nortelnetworks.com> Date: Tue, 01 Apr 2003 17:29:34 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Gonzalo Camarillo CC: "Francois Audet" , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" Subject: Re: [Sipping] New version of the early media draft References: <2F1FC1DEA077D5119FAD00508BCFD6D20787D68D@zsc3c030.us.nortel.com> <3E89248E.A4CF6816@lmf.ericsson.se> In-Reply-To: <3E89248E.A4CF6816@lmf.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit But Francois stated clearly that the 200 OK-RTP race condition is not a problem in real-life networks. Gonzalo Camarillo wrote: > Francois, > > you must play the media you get because of the 200 OK-RTP race > condition. Therefore, your proposal of sending a 180 response saying "I > will send you media, but do not play it", will cause media clipping when > the 200 OK arrives later than the first RTP packets. > > I would like people to note that this problem is unsolvable as long as > SIP and RTP follow different paths (as it is the case). Therefore, no > matter how many flags we define, the 200 OK-RTP race condition will > force us to listen to the media path in order to avoid media clipping. > > Gonzalo > > > > Francois Audet wrote: > ... >> >>The only alternative is to wait for the 200 OK to connect media. >>Despite the claims of >>this introducing clipping on answer, I haven't seen this to be a >>problem on existing VoIP >>systems (i.e., the time it takes the human to answer is longer than >>the interval during >>which there could be clipping). >> ... >> >>François Audet > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 1 20:08:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23927 for ; Tue, 1 Apr 2003 20:08:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h321Wax05865 for sipping-archive@odin.ietf.org; Tue, 1 Apr 2003 20:32:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321WaK05862 for ; Tue, 1 Apr 2003 20:32:36 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23918 for ; Tue, 1 Apr 2003 20:08:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321VWK05826; Tue, 1 Apr 2003 20:31:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321UDK05745 for ; Tue, 1 Apr 2003 20:30:13 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23849 for ; Tue, 1 Apr 2003 20:05:41 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h32182u24358; Tue, 1 Apr 2003 17:08:03 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 17:07:47 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2078F1046@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Christer Holmberg'" , "'Gonzalo Camarillo'" Cc: "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" Subject: RE: [Sipping] New version of the early media draft Date: Tue, 1 Apr 2003 17:07:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F8B4.469E07DE" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2F8B4.469E07DE Content-Type: text/plain > Forking is always going to a problem, and that is part of the > issues I have on the "must play all media you receive" stuff. > In forking cases a UAC may use whatever local policy to > decide which media stream will be played to the user. Of > course, the UAC may mix all streams together, and there will > be a risk the user will only hear a mess, but that is local > policy, and should not be required behaviour. Agreed 100%. > Also, like I said earlier, there are cases where a UAC may > not be able, or may not want to, play media before it > receives a remote SDP for that stream. I think we should at > least have an early dialog established before we put media > handling requirements on the nodes - then we can discuss > about how UAS makes decissions related to local ringback etc. Again, agree completely. > So, therefore I think it is important for a UAS to send his > SDP as soon as possible - NO MATTER if it's sent in 180 or > 183, and NO MATTER if he actually intends to send early media > or not (even if the UAS is not going to send any media before > 200 OK, the UAC would still need the SDP before that, to > establish an early dialog, to prevent clipping). Key work is "as soon as possible". In many cases, you may not know before the call is answered where the media should be sent, and have to send the SDP in the 200 OK. But if you know it beforehand, you should definitively send it as soon as possible. If sent in 18X, the SDP would be useful to the caller if there is no multiple dialog. If there is multiple dialogs, then you have the "local policy" stuff of your first paragraph. I'm fine with this. The reason this is a mess is that there is no sure way to associate the incoming RTP media with a specific dialog, so it makes it extremely difficult for the UA to make a good decision. ------_=_NextPart_001_01C2F8B4.469E07DE Content-Type: text/html RE: [Sipping] New version of the early media draft

> Forking is always going to a problem, and that is part of the
> issues I have on the "must play all media you receive" stuff.
> In forking cases a UAC may use whatever local policy to
> decide which media stream will be played to the user. Of
> course, the UAC may mix all streams together, and there will
> be a risk the user will only hear a mess, but that is local
> policy, and should not be required behaviour.

Agreed 100%.

> Also, like I said earlier, there are cases where a UAC may
> not be able, or may not want to, play media before it
> receives a remote SDP for that stream. I think we should at
> least have an early dialog established before we put media
> handling requirements on the nodes - then we can discuss
> about how UAS makes decissions related to local ringback etc.

Again, agree completely.

> So, therefore I think it is important for a UAS to send his
> SDP as soon as possible - NO MATTER if it's sent in 180 or
> 183, and NO MATTER if he actually intends to send early media
> or not (even if the UAS is not going to send any media before
> 200 OK, the UAC would still need the SDP before that, to
> establish an early dialog, to prevent clipping).

Key work is "as soon as possible". In many cases, you may not know
before the call is answered where the media should be sent, and
have to send the SDP in the 200 OK. But if you know it beforehand, you
should definitively send it as soon as possible.

If sent in 18X, the SDP would be useful to the caller if there is no
multiple dialog. If there is multiple dialogs, then you have the "local
policy" stuff of your first paragraph. I'm fine with this. The reason
this is a mess is that there is no sure way to associate the incoming
RTP media with a specific dialog, so it makes it extremely difficult
for the UA to make a good decision.

------_=_NextPart_001_01C2F8B4.469E07DE-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 1 20:12:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24005 for ; Tue, 1 Apr 2003 20:12:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h321auZ06023 for sipping-archive@odin.ietf.org; Tue, 1 Apr 2003 20:36:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321auK06020 for ; Tue, 1 Apr 2003 20:36:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23983 for ; Tue, 1 Apr 2003 20:12:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321a8K05995; Tue, 1 Apr 2003 20:36:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h321ZQK05956 for ; Tue, 1 Apr 2003 20:35:26 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23969 for ; Tue, 1 Apr 2003 20:10:55 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h321DIo08116; Tue, 1 Apr 2003 19:13:19 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 1 Apr 2003 17:13:18 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2078F105D@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Tom Taylor'" , "'Gonzalo Camarillo'" Cc: "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" Subject: RE: [Sipping] New version of the early media draft Date: Tue, 1 Apr 2003 17:13:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F8B5.0B92CAB6" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2F8B5.0B92CAB6 Content-Type: text/plain It may be a problem if you have a large number of slow proxies, but then you will also have problems with calls to multiple terminations. I am not sure that we are doing the right thing by trying to optimize this solution for circuit-switch interworking, to the expense of useful SIP functionality. Jon has often said that pure SIP implementations should not use early media for in-band ringing. (I agree). But the way we are designing these procedures, any forked endpoint can send inband ringing with early media and effectively supercede the SIP-level call progress indications that the other forked endpoints are sending. I don't think it is a good idea. > -----Original Message----- > From: Tom Taylor [mailto:taylor@nortelnetworks.com] > Sent: Tuesday, April 01, 2003 14:30 > To: Gonzalo Camarillo > Cc: Audet, Francois [SC100:4K02:EXCH]; 'Bob Penfield'; > 'sipping@ietf.org'; 'Jon PETERSON > (Jon.Peterson@neustar.com)'; 'Christer Holmberg' > Subject: Re: [Sipping] New version of the early media draft > > > But Francois stated clearly that the 200 OK-RTP race > condition is not a problem in > real-life networks. ------_=_NextPart_001_01C2F8B5.0B92CAB6 Content-Type: text/html RE: [Sipping] New version of the early media draft

It may be a problem if you have a large number of slow proxies, but then you
will also have problems with calls to multiple terminations.

I am not sure that we are doing the right thing by trying to optimize
this solution for circuit-switch interworking, to the expense of
useful SIP functionality.

Jon has often said that pure SIP implementations should not use
early media for in-band ringing. (I agree).

But the way we are designing these procedures, any forked endpoint can send
inband ringing with early media and effectively supercede the SIP-level call progress
indications that the other forked endpoints are sending. I don't think it is
a good idea.


> -----Original Message-----
> From: Tom Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Tuesday, April 01, 2003 14:30
> To: Gonzalo Camarillo
> Cc: Audet, Francois [SC100:4K02:EXCH]; 'Bob Penfield';
> 'sipping@ietf.org'; 'Jon PETERSON
> (Jon.Peterson@neustar.com)'; 'Christer Holmberg'
> Subject: Re: [Sipping] New version of the early media draft
>
>
> But Francois stated clearly that the 200 OK-RTP race
> condition is not a problem in
> real-life networks.

------_=_NextPart_001_01C2F8B5.0B92CAB6-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 1 21:28:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25721 for ; Tue, 1 Apr 2003 21:28:43 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h322qjg11446 for sipping-archive@odin.ietf.org; Tue, 1 Apr 2003 21:52:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h322qjK11443 for ; Tue, 1 Apr 2003 21:52:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25709 for ; Tue, 1 Apr 2003 21:28:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h322pYK11354; Tue, 1 Apr 2003 21:51:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h322o9K11290 for ; Tue, 1 Apr 2003 21:50:09 -0500 Received: from zoe.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25634 for ; Tue, 1 Apr 2003 21:25:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] netann Open Issue #1: Media on Hold Date: Tue, 1 Apr 2003 21:30:14 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F62C9@zoe.office.snowshore.com> Thread-Topic: [Sipping] netann Open Issue #1: Media on Hold Thread-Index: AcL3cPzkX2mzaqanSXWYywbfBtXUZQBTpLKQ From: "Eric Burger" To: "Gonzalo Camarillo" Cc: "Sipping (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h322o9K11291 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit There is no opportunity to put early media on hold. The INVITE transaction has not completed yet. > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Monday, March 31, 2003 5:31 AM > To: Eric Burger > Cc: Sipping (E-mail) > Subject: Re: [Sipping] netann Open Issue #1: Media on Hold > > > Eric, > > > Note that hold is not an issue for early media: it is not > possible to put early media on hold. > > Why is it different for early media than for regular media? > You can put > any type of media on hold... what did you have in mind? > > Gonzalo > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 2 01:12:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00999 for ; Wed, 2 Apr 2003 01:12:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h326avK26259 for sipping-archive@odin.ietf.org; Wed, 2 Apr 2003 01:36:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h326avK26256 for ; Wed, 2 Apr 2003 01:36:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00988 for ; Wed, 2 Apr 2003 01:12:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h326ZnK26215; Wed, 2 Apr 2003 01:35:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h326YXK26155 for ; Wed, 2 Apr 2003 01:34:33 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00947 for ; Wed, 2 Apr 2003 01:09:56 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h326CLUE020589; Wed, 2 Apr 2003 08:12:22 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A46P840; Wed, 2 Apr 2003 08:12:22 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h326CLAv021503; Wed, 2 Apr 2003 09:12:21 +0300 (EET DST) Message-ID: <3E8A7F44.1020508@lmf.ericsson.se> Date: Wed, 02 Apr 2003 09:12:20 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: Francois Audet , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" Subject: Re: [Sipping] New version of the early media draft References: <2F1FC1DEA077D5119FAD00508BCFD6D20787D68D@zsc3c030.us.nortel.com> <3E89248E.A4CF6816@lmf.ericsson.se> <3E8A12CE.7070204@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit First of all, I do not understand why people continue discussing things like early media with forking whose problems are already well discussed and documented in the draft and nobody so far has been able to come up with a single use case where the proposed flag would be useful... I would ask people to focus on the problem in hand (i.e., the flag), and stop discussing about already resolved issues. > But Francois stated clearly that the 200 OK-RTP race condition is not a > problem in real-life networks. This is an amazing statement. Let's say that we both are in Australia with a RTT between us of 10 ms. This is the RTT that RTP will see. Now, our home proxies in Finland and in the US record-route because they are providing some kind of service. Now, please explain me how a SIP message travelling from Australia to Finland, to the US and back to Australia can arrive roughly at the same time as the RTP packet sent directly between the terminals... Statements like "media clipping is not a problem" or "the RTP-200 OK race condition does not really exist" make me think that the only reason for creating a flag is networks that work a la ISUP (i.e., tighly coupling between signalling and media)... and we agreed in San Francisco that that was out of scope. Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 2 01:25:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01173 for ; Wed, 2 Apr 2003 01:25:03 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h326n9V27553 for sipping-archive@odin.ietf.org; Wed, 2 Apr 2003 01:49:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h326n9K27550 for ; Wed, 2 Apr 2003 01:49:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01159 for ; Wed, 2 Apr 2003 01:24:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h326mGK27524; Wed, 2 Apr 2003 01:48:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h326l8K27467 for ; Wed, 2 Apr 2003 01:47:08 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01143 for ; Wed, 2 Apr 2003 01:22:30 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h326OvUE023082; Wed, 2 Apr 2003 08:24:57 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A46P007; Wed, 2 Apr 2003 08:24:58 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h326OvAv022114; Wed, 2 Apr 2003 09:24:57 +0300 (EET DST) Message-ID: <3E8A8238.2040002@lmf.ericsson.se> Date: Wed, 02 Apr 2003 09:24:56 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: "Sipping (E-mail)" Subject: Re: [Sipping] netann Open Issue #1: Media on Hold References: <4A3384433CE2AB46A63468CB207E209D4F62C9@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit What keeps you from using UPDATE? Gonzalo Eric Burger wrote: > There is no opportunity to put early media on hold. The INVITE transaction has not completed yet. > > >>-----Original Message----- >>From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] >>Sent: Monday, March 31, 2003 5:31 AM >>To: Eric Burger >>Cc: Sipping (E-mail) >>Subject: Re: [Sipping] netann Open Issue #1: Media on Hold >> >> >>Eric, >> >> >>>Note that hold is not an issue for early media: it is not >> >>possible to put early media on hold. >> >>Why is it different for early media than for regular media? >>You can put >>any type of media on hold... what did you have in mind? >> >>Gonzalo > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 2 06:26:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03892 for ; Wed, 2 Apr 2003 06:26:48 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32Bp0l29786 for sipping-archive@odin.ietf.org; Wed, 2 Apr 2003 06:51:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32Bp0K29783 for ; Wed, 2 Apr 2003 06:51:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03851 for ; Wed, 2 Apr 2003 06:26:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32BoEK29730; Wed, 2 Apr 2003 06:50:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2VIWeK05944 for ; Mon, 31 Mar 2003 13:32:40 -0500 Received: from post.webmailer.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17316 for ; Mon, 31 Mar 2003 13:08:46 -0500 (EST) Received: from raggy (p3E9BAA51.dip.t-dialin.net [62.155.170.81]) by post.webmailer.de (8.12.8/8.8.7) with ESMTP id h2VIB6O4024500; Mon, 31 Mar 2003 20:11:07 +0200 (MEST) From: "Christian Stredicke" To: "'Cullen Jennings'" Cc: Subject: AW: [Sipping] AW: AW: "Strict Routing", "Loose Routing", "No Routing"! Date: Mon, 31 Mar 2003 20:11:10 +0200 Organization: snom technology AG Message-ID: <001301c2f7b0$e9109cc0$2d00a8c0@raggy> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2VIWeK05945 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Yes that's the problem we are facing every day: Calling your "neighbour" in the same NAT. Maybe I should write a draft about this which explains the why, how, and so on. Maybe this should be renamed to "NAT routing" -- sounds less revolutionary:-) BTW I think that it is not a replacement of lr - its just another routing information. I now think a Route could look like this: Route: Route: The nr=nat indicates that this part of the route has to be handled according to the "nat" scheme. Other schemes might follow. Christian > -----Ursprüngliche Nachricht----- > Von: Cullen Jennings [mailto:fluffy@cisco.com] > Gesendet: Montag, 31. März 2003 18:23 > An: Christian Stredicke > Cc: sipping@ietf.org > Betreff: RE: [Sipping] AW: AW: "Strict Routing", "Loose Routing", "No > Routing"! > > > Consider the case where there are three NATs calls A B and C. Both A and B > are behind C. This is typical where C is a ISP and A and B are home nats. > Two phones behind A and B both think their pubic address is the address on > the outside of C. > > I'm not sure I understand what you are proposing but I suspect it might > not > work in this case. > > Cullen > > > -----Original Message----- > > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org]On Behalf Of > > Christian Stredicke > > Sent: Monday, March 24, 2003 12:49 AM > > To: 'Jonathan Rosenberg' > > Cc: 'Rohan Mahy'; sipping@ietf.org; 'Jörgen Björkner'; 'Robert Sparks' > > Subject: [Sipping] AW: AW: "Strict Routing", "Loose Routing", "No > > Routing"! > > > > > > Jonathan, > > > > ok I elaborate a little bit as the history might not be known to > > everybody. > > > > (1) I am talking about the SIP messages here only; RTP is a separate > > issue. > > > > Again, I would like to stress I am not trying to reinvent routing (I > > think that would be too late and inappropriate anyway). I would just > > like to propose a backward-compatible way of expressing that non-SIP > > aware equipment is involved in the message forwarding process that needs > > to be taken care of. There is a need for this as we are moving on making > > the addresses found by STUN usable between the different vendors. > > > > (2) The problem is that depending on the context a request must be send > > to one of several possible addresses. In the case of NAT you are right, > > this is typically a problem when the two user agents are in the same NAT > > and the NAT gateway does not properly forward the messages coming from > > the private side sent to the public address of the other phone. This is > > my private concern as this is the most critical case we are facing in > > day-to-day life now. > > > > (3) I proposed using alternative addresses in the contact like > > > > "sip:62.12.34.56:6546;srcadr=192.168.0.123:5060" > > > > but that did not find too much acceptance with the persons that I talked > > to. The alternative proposal is including the route in the contact like > > > > "sip:192.168.0.123:5060?Route=sip:62.12.34.56:6546" or so, > > > > but this has the disadvantage that equipment which does not support the > > route header will not be able to send the packet properly (and apart > > from that I have some problems understanding how the route header should > > be merged with a maybe existing route). > > > > (4) What I propose now is using the routing mechanism we all know from > > SIP with a modification (backward compatible). For registrations, the > > path header has already been proposed and the record-route is part of > > the RFC. > > > > Lets make an example: The UA is in a private network and has the above > > private address and public address association. So it will send the > > following REGISTER message: > > > > REGISTER sip:bla.com SIP/2.0 > > Path: > > Contact: > > ... > > > > The registrar will save both the path and the contact. So a INVITE that > > is forwarded to the user agent then will go along the path: > > > > INVITE sip:192.168.0.123:5060 SIP/2.0 > > Route: > > > > Because the user agent can deal with the "no routing", it will remove > > the top route entry (it contains the nr) and then process the packet. > > Here, it will probably start ringing. > > > > If the user agents sends a message and the topmost route entry contains > > the nr flag, it skips that route if the IP address is the same as the IP > > address that is has stored as its public IP address. This is surely a > > pragmatic first step to solving the problem of finding the right > > destination in a NAT. However, it can be extended to using STUN probes > > first and so on (for example in multi-tier NAT). > > > > (5) The nice thing about the nr idea is that existing equipment does not > > have to be changed. That means especially the existing proxies in the > > public internet can deal perfectly with "no routers". If equipment > > supports the nr flag, it will also see the packets with the nr flag and > > process them accordingly. Meaning that nr is fully backward compatible. > > > > > > I hope this clarifies the idea a little bit more. > > > > > > Christian > > -- > > Dr.-Ing. Christian Stredicke > > sip:cs@snom.com > > > > > > > -----Ursprüngliche Nachricht----- > > > Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Gesendet: Montag, 24. März 2003 11:55 > > > An: Christian Stredicke > > > Cc: 'Rohan Mahy'; sipping@ietf.org; 'Jörgen Björkner'; 'Robert Sparks' > > > Betreff: Re: AW: "Strict Routing", "Loose Routing", "No Routing"! > > > > > > Christian, > > > > > > I cannot really follow your email, and do not understand the problem > > > here. Perhaps you are referring to the case where A calls B, both > > behind > > > the same NAT, with a proxy on the public Internet. If the proxy doesnt > > > record route, a contact in the INVITE from A that contains an address > > > allocated via upnp will not be useful to B. There is an equivalent > > case > > > for RTP. > > > > > > There are only two solutions for this, I believe: > > > > > > 1. the proxy always record routes. But, how does it know that it needs > > > to do so? > > > > > > 2. apply the ICE principles to SIP signaling. This would involve > > > inclusion of *both* the public and private addresses in the Contact > > > header of the INVITE, and so the recipient uses the one that works. > > > Contact in INVITE only allows one URI (pity), so we would need to hack > > > around to get that to work. There are ways. > > > > > > I think most folk do approach 1. Its problem is that the proxy has to > > > know to record route. > > > > > > Approach 2 is in line with the ICE philosophy in that it would always > > > work, without requiring apriori topology knowledge as case 1 assumes. > > > > > > Anyway, moving to sipping since this is an important issue. > > > > > > -Jonathan R. > > > > > > Christian Stredicke wrote: > > > > Rohan, > > > > > > > > that is surely going into the right direction! > > > > > > > > I think it clearly points out the need to transport more than one > > > > address in the SDP. > > > > > > > > However, it does not seem to solve the problem for requests that > > don’t > > > > have SDP attachments (like MESSAGE). There is a difference in SIP > > > > routing and RTP routing. I think the draft addresses the RTP routing > > > > problem. For SIP routing, I think we still need a way for > > formulating > > > > that non SIP-aware equipment is involved in the routing process. > > > > > > > > Again, in my perception, SIP deals with *routes* (user agent client, > > > > number of routers with loose/strict/no routing and the user agent > > > > server). Every router has a defined behaviour (SIP aware called > > > > "proxies" and non SIP-aware called "NAT"). We know that the > > different > > > > types of proxies need different treatment and I begin to realize > > that > > > > NAT routers need a different treatment as well. > > > > > > > > The good news is that "no-routers" can be treated backward > > compatible. > > > > If the routing element behind the no-router fixes the SIP routing > > > > information everything should run fine. It is also the element > > behind > > > > the no-router that inserts this information. > > > > > > > > Anyway, having a STUN server on board of every SIP network element > > > > (UA/proxy) is probably a good idea for whatever comes. As you know, > > we > > > > did this already half a year on our proxy! > > > > > > > > Best, > > > > > > > > > > > > Christian > > > > > > > > > > > >>-----Ursprüngliche Nachricht----- > > > >>Von: Rohan Mahy [mailto:rohan@cisco.com] > > > >>Gesendet: Samstag, 22. März 2003 05:57 > > > >>An: Christian Stredicke > > > >>Cc: sip-implementors@cs.columbia.edu; 'Jörgen Björkner'; 'Robert > > > > > > > > Sparks' > > > > > > > >>Betreff: Re: "Strict Routing", "Loose Routing", "No Routing"! > > > >> > > > >>Hi Christian, > > > >> > > > >>Have you seen Jonathan Rosenberg's "ICE" proposal which we discussed > > > > > > > > in > > > > > > > >>SIPPING? How do you think these would relate. > > > >> > > > >>thanks, > > > >>-rohan > > > >> > > > >> > > > >>On Monday, March 17, 2003, at 09:17 PM, Christian Stredicke wrote: > > > >> > > > >> > > > >>>Hello again, > > > >>> > > > >>>while we have now loose routers and strict routers it seems that a > > > >> > > > > new > > > > > > > >>>type occurs on the horizon: The "no router"! > > > >>> > > > >>>This is for example the case when using NAT forwarding (e.g. with > > > >> > > > > STUN > > > > > > > >>>or UPnP). The router is not at all aware of SIP and does not > > > >> > > > > manipulate > > > > > > > >>>the packet at all. However, the router is too dumb to forward a > > > >> > > > > packet > > > > > > > >>>if it is coming from the wrong direction. This is the case with > > most > > > >> > > > > of > > > > > > > >>>the DSL routers today. > > > >>> > > > >>>May I propose to use a ";nr" flag in a URI to indicate that the > > > >> > > > > router > > > > > > > >>>does not do any SIP changing at all? > > > >>> > > > >>>User Agents that are able to deal with "no routers" would then > > > >> > > > > register > > > > > > > >>>with the following packet: > > > >>> > > > >>>REGISTER sip:bla.com SIP/2.0 > > > >>>Path: > > > >>>Contact: > > > >>>... > > > >>> > > > >>>When it receives a message this could look like this: > > > >>> > > > >>>INVITE sip:62.12.245.32:54456;nr=1 SIP/2.0 > > > >>>Route: > > > >>>... > > > >>> > > > >>>SIP/2.0 200 Wonderful > > > >>>Record-Route: > > > >>>Contact: > > > >>>... > > > >>> > > > >>>The nr parameter could easily indicate that the previous router did > > > >> > > > > not > > > > > > > >>>change the packet at all and that the next entity has to fix this > > > >>>before > > > >>>processing the message. Alternatively, the router sending the > > packet > > > >>>could fix the route before sending it. > > > >>> > > > >>>What do you think? Is this really necessary? Just omit the nr > > > >> > > > > parameter > > > > > > > >>>and conclude implicitly? How else should we deal with routers that > > > >> > > > > are > > > > > > > >>>not SIP-aware? I don’t like the route encoding in the header > > > >>>(sip:abc?route=def) as it raises many questions about how to merge > > > >> > > > > this > > > > > > > >>>with other existing routes. > > > >>> > > > >>>Unfortunately, omitting the private address is no solution, as > > > >> > > > > devices > > > > > > > >>>in the same subnet have to bypass the "no router". Many DSL routers > > > >> > > > > are > > > > > > > >>>not able to send packets from private address via the public > > address > > > >> > > > > to > > > > > > > >>>the other private address. > > > >>> > > > >>>Cheers, > > > >>> > > > >>> > > > >>>Christian > > > >>>-- > > > >>>Dr. Christian Stredicke > > > >>>sip:cs@snom.com > > > >>> > > > >> > > > > > > > > > > > > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Scientist Parsippany, NJ 07054-2711 > > > dynamicsoft > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 2 07:54:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07394 for ; Wed, 2 Apr 2003 07:54:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32DIiG03899 for sipping-archive@odin.ietf.org; Wed, 2 Apr 2003 08:18:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32DIhK03896 for ; Wed, 2 Apr 2003 08:18:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07391 for ; Wed, 2 Apr 2003 07:53:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32DHkK03853; Wed, 2 Apr 2003 08:17:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32DGvK03808 for ; Wed, 2 Apr 2003 08:16:57 -0500 Received: from usjk1002.kddi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07362 for ; Wed, 2 Apr 2003 07:52:10 -0500 (EST) Received: from usjk1005.kddi.com (usjk1005 [10.96.2.2]) by usjk1002.kddi.com (3.7W-030228132558) with ESMTP id VAA17105; Wed, 2 Apr 2003 21:54:35 +0900 (JST) Received: from usjk1009.kddi.com (localhost [127.0.0.1]) by usjk1005.kddi.com (3.7W-021210104931) with ESMTP id VAA00078; Wed, 2 Apr 2003 21:54:35 +0900 (JST) Received: from KDDI-0003PC0281.kddi.com ([133.128.137.10]) by usjk1009.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20030402125439.ZBGL1046.usjk1009.kddi.com@KDDI-0003PC0281.kddi.com>; Wed, 2 Apr 2003 21:54:39 +0900 To: sipping@ietf.org Subject: Prepared to receive media bu not to play (was Re: [Sipping] New version of the early media draft) From: Takuya Sawada References: <2F1FC1DEA077D5119FAD00508BCFD6D20787D68D@zsc3c030.us.nortel.com> <3E89248E.A4CF6816@lmf.ericsson.se> In-Reply-To: <3E89248E.A4CF6816@lmf.ericsson.se> Message-Id: <200304022154.EGD31058.TBBE-VBXU@kddi.com> X-Mailer: Winbiff [Version 2.41] X-Accept-Language: ja,en Date: Wed, 2 Apr 2003 21:54:29 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This may be irrelevant to the matter on this thread, media flag, but let me clarify one thing. RFC3264 reads that once the offerer has sent the offer, it MUST be prepared to receive media. I do not take this statement as "it MUST play media". To receive media is one thing and to play media can be another thing. In my understanding, to recieve media means not to respond with ICMP error, to initialize sequence number, to adjust jitter buffer, to calculate statistics, to send RTCP, etc. Once it receives media, it can play out media but I think this is essentially the matter of application and its policy. There is a use case that it should not play the early media: Considering PSTN to SIP endpoint call flow, if PSTN gateway play out the media from SIP endpoint before the call is answered, network operator will face the risks that its PSTN resources are consumed by unanswered but meaningful backward voice usage. On the other hand, network operator will have media clipping problem unless it palys early media. You must choose media clipping or risk of the theft of PSTN resource. I think this is the decision of network policy, not of the protocol. Am I correct? I really want PSTN gateways implementation to be configurable on whether to play out the early media or not, hopefully depending on whether the peer is trusted or not. By the way, regarding the media flag, I agree with Gonzalo. Regards, Takuya > Francois, > > you must play the media you get because of the 200 OK-RTP race > condition. Therefore, your proposal of sending a 180 response saying "I > will send you media, but do not play it", will cause media clipping when > the 200 OK arrives later than the first RTP packets. > > I would like people to note that this problem is unsolvable as long as > SIP and RTP follow different paths (as it is the case). Therefore, no > matter how many flags we define, the 200 OK-RTP race condition will > force us to listen to the media path in order to avoid media clipping. > > Gonzalo > > > > Francois Audet wrote: > > > > > -----Original Message----- > > > From: Bob Penfield [mailto:bpenfield@acmepacket.com] > > > Sent: Saturday, March 29, 2003 07:43 > > > To: sipping@ietf.org > > > Subject: Re: [Sipping] New version of the early media draft > > > > > > BTW, I do support your position that no additional indication > > > of the presence or absence of early media is required in SIP > > > signaling. If UAC receives media, it should play it. > > > > This is actually the biggest problem I personnally have with the > > assumptions on early > > media. > > > > I do not think that this rule of "play media when you receive it" is > > implementable > > generally, but only in a few very selected cases. > > > > There are a number of scenarios that I think are problematic: > > > > 1 - 180 with SDP > > > > If a 180 is sent with an SDP (for the purpose of telling the far end > > what > > codec is picked), the called UA the shouldn't be sending silence in > > RTP because, according to the current rules, the calling UA would stop > > the > > locally generated ringing to play the silence packet. (Doing some > > heavy duty > > DSP parsing to detect if the media is silence or not seems hardly > > efficient, > > nor reliable). > > > > A side effect of this is that if there is a NAT/Firewall involved, it > > is quite > > possible that the binding will expire and the address in the SDP will > > be invalid > > or the media will be blocked upon answer. > > > > If an indication was present to indicate if the in-band media was > > meant to be > > replacing the locally generated tone, we wouldn't have this problem > > (i.e., one > > could send packets in-band to keep the binding alive). > > > > > > 2 - Sequential calling > > > > In a sequential calling scenario such as call call forwarding no > > answer (section 2.8 > > of the SIP services examples Internet Draft). Suppose the following: > > > > Alice Proxy User B1 User B2 > > | | | | > > | INVITE F1 | | | > > |--------------->| INVITE F2 | | > > |(100 Trying) F3 |------------->| | > > |<---------------|183 ProgressF4| | SDP > > is included with 183 > > | 183 Progress F5|<-------------| | > > |<---------------| | | > > | Both way RTP Established | | > > In-band |<=============================>| | > > ringing | Request Timeout | > > | | | | > > | | CANCEL F6 | | > > | |------------->| | > > | | 200 OK F7 | | > > | |<-------------| | > > | | 487 F8 | | > > | |<-------------| | > > | | ACK F9 | | > > | |------------->| | > > | | | INVITE F10 | > > | |--------------------------------->| > > | | | 180 Ringing F11 | > > | 180 Ringing F12|<---------------------------------| > > |<---------------| | | > > > > The problem with this scenario is that presumably, upon receipt of > > 180, > > the UA needs to figure out somehow that it should be playing the > > locally > > generated alerting. This would imply that upon receipt of the 180, the > > calling > > UA would start a timer and wait until it expires to play the locally > > generate > > tone. Since ringing is composed of tone-silence-tone, the timer will > > have to be > > relatively long. While the UA can detect that the 180 is a different > > dialog than > > the 183, it can not know for sure that the first dialog had been > > cancelled > > because it could be forking: it has to rely on the media. > > > > While this is technically feasible, it imposes a big unecessary burden > > on > > the client, especially if it is a thin client. On a "decomposed" > > architecture > > (like a stimulus MGCP phone), it makes for pretty nasty signalling, if > > possible > > at all. > > > > PS: I'm not saying that the in-band media is necessarily useful in > > this scenario. I'm > > just pointing out the difficulties of the "play media when received" > > mantra. > > > > 3 - Forking > > > > As expected, this is the worst. > > > > Alice Proxy User B1 User B2 > > | | | | > > | INVITE F1 | | | > > |--------------->| INVITE F2 | | > > |(100 Trying) F3 |------------->| | > > |<---------------|183 ProgressF4| | SDP > > is included with 183 > > | 183 Progress F5|<-------------| | > > |<---------------| | | > > | Both way RTP Established | | > > In-band |<=============================>| | > > ringing | | | | > > | | | INVITE F10 | > > | |--------------------------------->| > > | | | 180 Ringing F11 | > > Locally | 180 Ringing F12|<---------------------------------| > > generated |<---------------| | 200 OK F13 | > > ringing | |<---------------------------------| > > > > There are of course multiple permutations, such as 2 183s, 2 180s, 1 > > 183 followed > > by a 180, or 1 180 followed by a 183. And then there might be more > > than 2 UAs being > > forked-to, so the problem can be really bad. > > > > There is no way to associate a specific RTP stream with a specific > > dialog. The current > > draft hints that one UA could randomly play one stream and mute the > > others (which will be > > very troublesome if the other UA doesn't support UPDATE). This is not > > satisfactory and > > would result in garbage being played to the user. For this reason, I > > believe that the only > > reasonable approach in this scenario is to let the 180 override the > > 183s (if there is > > a 180) and ignore all media. This will of course result that there > > might be some level of > > clipping on answer (I have yet to see a network where this is a > > problem). If there is no > > 180, one could play one of the random stream (although I don't think > > it is particulary > > useful), or play some default "progress" tone that would indicate to > > the user that the > > call is forked. > > > > One of the reason I think the 180 indication is more useful than the > > 183-with-in-band- > > media is that if the in-band from the 183 is saying "This number has > > been disconnected, > > please hangup" and then a 200 OK comes back (for the 180) wich > > connects the call, the user > > will be very disoriented (realistically, he will probably have hung-up > > anyways). The other > > way around (playing the local ringback) will at least keep the user > > on-line in case somebody > > does answer. The point is that since we can't associate a particular > > media stream with > > the SIP signalling, we can't just "play the media" when there is > > multiple dialogs. > > > > Many people seem to think that "this is forking, it is trouble, don't > > use it, bla bla bla". > > Unfortunately, it is extremely useful. Also, it happens all the time > > today when parallel > > calling is done (different names exists for it, including "multiple > > appearances", or > > "parallel hunt groups"). If SIP can not properly ring multiple agents > > in a pool in parallel, > > it won't be terribly useful. > > > > The only alternative is to wait for the 200 OK to connect media. > > Despite the claims of > > this introducing clipping on answer, I haven't seen this to be a > > problem on existing VoIP > > systems (i.e., the time it takes the human to answer is longer than > > the interval during > > which there could be clipping). > > > > One added difficulty is that from the calling UA's perspective, we > > can't distinguish easily > > between case 2 and 3. > > > > --------- > > > > My conclusion is that when there are multiple dialogs, we can not > > honor media at the > > calling UA and have to rely on the SIP provisional responses > > exclusively. This goes against > > the "play media as soon as you receive it" principle. > > > > Also, since parallel calling (i.e., forking) is extremely common in > > call centers and > > within enterprises, it greatly limits the applicability of early > > media, or indeed ringing > > 2 phones in a private residence. My personal opinion is that it is > > really limited to TDM > > gateway interworking, and only when there is no forking involved or > > multiple dialog > > involved. > > > > Again, I don't believe that the "in-band alerting" indication > > necessarily solves this (although > > it does help in a few cases). I'm just pointing out that the play > > in-band RTP even if 180 is > > received is not generally a good idea. The reason I am sending this > > email in the context > > of this discussion on the in-band ringing indication is that this idea > > that playing in-band > > media automatically helps keeps on re-surfacing. > > > > Fran$BmP(Bis Audet > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP -------- Takuya Sawada KDDI Corporation (KDDI) KDDI Bldg. 2-3-2 Nishishinjuku Shinjuku-ku, Tokyo 163-8003, Japan Tel: +81-3-3347-7406 Fax: +81-3-3347-7418 tu-sawada@kddi.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 2 09:54:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11192 for ; Wed, 2 Apr 2003 09:54:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32FJ6b14426 for sipping-archive@odin.ietf.org; Wed, 2 Apr 2003 10:19:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32FJ6K14423 for ; Wed, 2 Apr 2003 10:19:06 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11170 for ; Wed, 2 Apr 2003 09:54:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32FIHK14375; Wed, 2 Apr 2003 10:18:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32FHcK14343 for ; Wed, 2 Apr 2003 10:17:38 -0500 Received: from zcars04e.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11121 for ; Wed, 2 Apr 2003 09:52:49 -0500 (EST) Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h32Et8W09218; Wed, 2 Apr 2003 09:55:08 -0500 (EST) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDFDDMV3; Wed, 2 Apr 2003 09:55:09 -0500 Received: from nortelnetworks.com (acart1dt.ca.nortel.com [47.129.129.102]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G7ZYWMBB; Wed, 2 Apr 2003 09:55:08 -0500 Message-ID: <3E8AF9CC.10401@nortelnetworks.com> Date: Wed, 02 Apr 2003 09:55:08 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Gonzalo Camarillo CC: "Francois Audet" , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" Subject: Re: [Sipping] New version of the early media draft References: <2F1FC1DEA077D5119FAD00508BCFD6D20787D68D@zsc3c030.us.nortel.com> <3E89248E.A4CF6816@lmf.ericsson.se> <3E8A12CE.7070204@nortelnetworks.com> <3E8A7F44.1020508@lmf.ericsson.se> In-Reply-To: <3E8A7F44.1020508@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Your difference in geography represents all of 100 ms, if I remember the formula correctly. I suspect codec delays often come to more than that. In any event, there is a human delay between the off-hook or equivalent and the "Hello". Leaving that aside, the normal method of engineering grade of service is to allow for unacceptable results in a small percentage of cases rather than aiming for perfection -- the latter costs too much. I suspect your round-the-world proxy chain for near-neighbours would amount to a small percentage of all calls. Conclusion: Gonzalo Camarillo wrote: > First of all, I do not understand why people continue discussing things > like early media with forking whose problems are already well discussed > and documented in the draft and nobody so far has been able to come up > with a single use case where the proposed flag would be useful... I > would ask people to focus on the problem in hand (i.e., the flag), and > stop discussing about already resolved issues. > >> But Francois stated clearly that the 200 OK-RTP race condition is not >> a problem in real-life networks. > > > This is an amazing statement. Let's say that we both are in Australia > with a RTT between us of 10 ms. This is the RTT that RTP will see. Now, > our home proxies in Finland and in the US record-route because they are > providing some kind of service. > > Now, please explain me how a SIP message travelling from Australia to > Finland, to the US and back to Australia can arrive roughly at the same > time as the RTP packet sent directly between the terminals... > > Statements like "media clipping is not a problem" or "the RTP-200 OK > race condition does not really exist" make me think that the only reason > for creating a flag is networks that work a la ISUP (i.e., tighly > coupling between signalling and media)... and we agreed in San Francisco > that that was out of scope. > > Gonzalo > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 2 19:46:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19258 for ; Wed, 2 Apr 2003 19:46:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h330m4v06603 for sipping-archive@odin.ietf.org; Wed, 2 Apr 2003 19:48:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h330m4K06600 for ; Wed, 2 Apr 2003 19:48:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19235 for ; Wed, 2 Apr 2003 19:45:32 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h330l3K06566; Wed, 2 Apr 2003 19:47:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h330jEK06449 for ; Wed, 2 Apr 2003 19:45:14 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19148 for ; Wed, 2 Apr 2003 19:42:42 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h330j5o07638; Wed, 2 Apr 2003 18:45:06 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2FGBT4AB>; Wed, 2 Apr 2003 16:45:05 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20794E863@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Gonzalo Camarillo'" , "Tom-PT Taylor" Cc: "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" , "Mark Watson" Subject: RE: [Sipping] New version of the early media draft Date: Wed, 2 Apr 2003 16:45:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F97A.439F39B0" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2F97A.439F39B0 Content-Type: text/plain > First of all, I do not understand why people continue > discussing things > like early media with forking whose problems are already well > discussed > and documented in the draft and nobody so far has been able > to come up > with a single use case where the proposed flag would be useful... I > would ask people to focus on the problem in hand (i.e., the > flag), and > stop discussing about already resolved issues. The problem is that the multiple dialog problem and early media problem (as in forking for example) has NOT been solved. Worst, using the current unworkable solution as a basis to make our decisions on the flag issue will not result in a good solution. The current solution for forking in the draft is for the UAC to pick a random media stream (based on signaling, thus the dialog, not media, because there is no means to correlate dialog and media stream) and mute the others by sending UPDATEs to the far end. This is not an acceptable solution. Random non-redictable behavior is not acceptable to end-users. Furthemore, this is not robust at all because if the called UA does not support UPDATE, multiple streams will be received and there will be no way for the UAC receiving it to pick the proper one. (If there was a way to correlate an RTP stream to the dialog that generate it, it would be easier) This leaves the client with 3 choices: 1) Pick a random media stream (which it will not be able to correlate with a specific dialog unless it is lucky with educated guesses). 2) Mix media streams together. 3) Provide alternative local treatment based on the provisional responses received. This could be You are right that the flag probably doesn't help with this problem. I'll leave it to others to defend the flag idea. I'm OK with current draft, as long as we do not ADD any more dependency on the "play media when you receive it" principle to address the flag prolem, and as long as we improve the section on forking. It seems to me that if forking is used we CAN NOT use early media for in-band ringing (we could do early media for clipping avoidance). Perhaps we need a "forked" indication in INVITE telling the far-end not to send early media... And to make it bullet proof a forked indication in the 100 Trying (when forking) to tell the UAC making the call that "weird stuff" is going to happen and that proper treatment should be used not to confused the user. ------_=_NextPart_001_01C2F97A.439F39B0 Content-Type: text/html RE: [Sipping] New version of the early media draft

> First of all, I do not understand why people continue
> discussing things
> like early media with forking whose problems are already well
> discussed
> and documented in the draft and nobody so far has been able
> to come up
> with a single use case where the proposed flag would be useful... I
> would ask people to focus on the problem in hand (i.e., the
> flag), and
> stop discussing about already resolved issues.

The problem is that the multiple dialog problem and early media problem (as in forking
for example) has NOT been solved. Worst, using the current unworkable solution as a basis
to make our decisions on the flag issue will not result in a good solution.

The current solution for forking in the draft is for the UAC to pick a random media
stream (based on signaling, thus the dialog, not media, because there is no means to correlate
dialog and media stream) and mute the others by sending UPDATEs to the far end. This is
not an acceptable solution. Random non-redictable behavior is not acceptable to end-users.
Furthemore, this is not robust at all because if the called UA does not support UPDATE,
multiple streams will be received and there will be no way for the UAC receiving it
to pick the proper one. (If there was a way to correlate an RTP stream to the dialog that
generate it, it would be easier)

This leaves the client with 3 choices:
1) Pick a random media stream (which it will not be able to correlate with a specific dialog
   unless it is lucky with educated guesses).
2) Mix media streams together.
3) Provide alternative local treatment based on the provisional responses received. This
   could be
 
You are right that the flag probably doesn't help with this problem. I'll leave it
to others to defend the flag idea.

I'm OK with current draft, as long as we do not ADD any more dependency on the "play
media when you receive it" principle to address the flag prolem, and as long as we improve
the section on forking. It seems to me that if forking is used we CAN NOT use early media for
in-band ringing (we could do early media for clipping avoidance). Perhaps we need a
"forked" indication in INVITE telling the far-end not to send early media... And to make
it bullet proof a forked indication in the 100 Trying (when forking) to tell the UAC making the
call that "weird stuff" is going to happen and that proper treatment should be used not
to confused the user.

------_=_NextPart_001_01C2F97A.439F39B0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 2 21:27:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21564 for ; Wed, 2 Apr 2003 21:27:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h332Ttb13732 for sipping-archive@odin.ietf.org; Wed, 2 Apr 2003 21:29:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h332TtK13729 for ; Wed, 2 Apr 2003 21:29:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21561 for ; Wed, 2 Apr 2003 21:27:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h332ScK13701; Wed, 2 Apr 2003 21:28:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h332RWK13640 for ; Wed, 2 Apr 2003 21:27:32 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21507 for ; Wed, 2 Apr 2003 21:24:56 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h332RJM05945; Wed, 2 Apr 2003 18:27:19 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2FGBTXM7>; Wed, 2 Apr 2003 18:27:19 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D20794E99B@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Tom Taylor'" , "'Gonzalo Camarillo'" Cc: "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" Subject: RE: [Sipping] New version of the early media draft Date: Wed, 2 Apr 2003 18:27:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F988.8B65FAA0" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2F988.8B65FAA0 Content-Type: text/plain > Gonzalo Camarillo wrote: > > Now, please explain me how a SIP message travelling from > Australia to > > Finland, to the US and back to Australia can arrive roughly > at the same > > time as the RTP packet sent directly between the terminals... Will there be clipping of RTP packets? Almost certainly. Will there be lost of useful human speech? It depends: probably not. This is where UI design comes into place. On a standard phone, you need a certain amount of time to pick-up the handset, bring it to your hear and mouth and answer. In that case, that time-lag needs to be shorter than the time it takes for the 200 OK to be generated, transmitted and received at the far end. This makes it very important that your SIP software be fast enought (on the set, and in the proxies). I am not too concerned about this case, because the bring-the-headset-to-your-head built-in answer delay should provide a sufficient buffer. On a UI where there is no handset to move, like a PC with a speaker and microphone, or a handsfree, the UI should provide some sort of built-in feedback that the "answer" command was accepted. On a "soft-client" the GUI should make it clear when the call is answered. I am just saying that since we have to engineer our UAC so that it can deal effectively with multiple dialogues (such as when forking) without being too confusing to the user, we have to put mechanisms in place to minimize the clipping problem. Our current procedure means that "legacy" gateways, when they do the "bad" thing of sending early media for ringing, will also override the nice native SIP devices as far as which early media is played when forking. You'll get worst clipping if the nice SIP terminal answers because the UAC receiving the media will have to CANCEL the INVITE to the legacy gateway that is still ringing to get it to stop sending RTP. Not only do you get the clipping you were talking about, but you also get additional clipping resulting from the time it takes to clear the INVITE that is still ringing, and you need for the calling UAC to somehow (based on a timer) decice that the first media stream can be replaced by the second. I'm talking about this case: Alice Forking Proxy User User User B1 B2 B3 | | | | | | INVITE F1 | | | | |--------------->| INVITE F2 | | | | |------------->| | | | | INVITE F3 | | | |-------------------->| | | | INVITE F4 | | | |--------------------------->| | 100 Trying F5 | | | | |<---------------|183 Progress | | | | |<-------------| | | Play=====|<======Early media=============| | | ... | 183 Progress | | | | |<---------------| | | | | | 183 Progress | | | | |<--------------------| | Blocked|X======"Drinnnngg"====================| | | 183 Progress | | | | |<---------------| 180 Ringing F10 | | 180 F11 |<---------------------------| Blocked|<==============="Hello"======================| |<---------------| 200 OK F12 | | 200 OK F13 |<---------------------------| |<---------------| | | | | | CANCEL 14 | | | | |------------->|(i) | | | | 200 OK F15 | | | (ii)| |<-------------| | | Play=====|<======Early media====================| | | | 487 F16 | | | | |<-------------| | | | | ACK F17 | | | | |------------->| | | (i) B1 stops sending media (ii) Alice starts timer to detect stopped media (i.e., not normal silence) has to decide to now play media from B3 after being sufficiently confident that the other B1 stream is stopped. Potentially big clipping. On the idea of putting your proxy in Finland when you work in Australia... Seems to me that while you *can* do this, it is certainly not the best engineering practice if you are trying to maximize the responsiveness of the system. SIP is not changing the laws of physics. Lastly, people have different expectations from a phone service depending on factors such as distance. If they know the far end is overseas for example, they are not as annoyed by a long call setup delay and expect lesser voice quality than if they are phoning their cubicule neighbor. If you make calls from cubicule-to-cubicule behave like they went from Australia to Finland and back, you should get braced for complaints. ------_=_NextPart_001_01C2F988.8B65FAA0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] New version of the early media draft

> Gonzalo Camarillo wrote:
> > Now, please explain me how a SIP message = travelling from
> Australia to
> > Finland, to the US and back to Australia = can arrive roughly
> at the same
> > time as the RTP packet sent directly = between the terminals...

Will there be clipping of RTP packets? Almost = certainly.

Will there be lost of useful human speech? It = depends: probably not.

This is where UI design comes into place. On a = standard phone, you need
a certain amount of time to pick-up the handset, = bring it to your hear
and mouth and answer. In that case, that time-lag = needs to be shorter than the
time it takes for the 200 OK to be generated, = transmitted and received
at the far end. This makes it very important that = your SIP software
be fast enought (on the set, and in the proxies). I = am not too concerned about
this case, because the = bring-the-headset-to-your-head built-in answer delay should
provide a sufficient buffer.

On a UI where there is no handset to move, like a PC = with a speaker and microphone,
or a handsfree, the UI should provide some sort of = built-in feedback that the "answer"
command was accepted. On a "soft-client" = the GUI should make it clear when the call
is answered.

I am just saying that since we have to engineer our = UAC so that it can deal
effectively with multiple dialogues (such as when = forking) without being too
confusing to the user, we have to put mechanisms in = place to minimize the
clipping problem.

Our current procedure means that "legacy" = gateways, when they do the "bad" thing
of sending early media for ringing, will also = override the nice native SIP devices
as far as which early media is played when forking. = You'll get worst clipping if
the nice SIP terminal answers because the UAC = receiving the media will have to CANCEL
the INVITE to the legacy gateway that is still = ringing to get it to stop sending RTP.
Not only do you get the clipping you were talking = about, but you also get additional
clipping resulting from the time it takes to clear = the INVITE that is still ringing,
and you need for the calling UAC to somehow (based = on a timer) decice that the
first media stream can be replaced by the second. =

I'm talking about this case:

          = Alice      Forking = Proxy       User   = User   User
          &nb= sp;           &nb= sp;           &nb= sp;       B1     = B2     B3
          = |            = ;    = |            = ;  |      |      = |
          = |    INVITE F1   = |            = ;  |      |      = |
          = |--------------->|   INVITE F2  = |      |      = |
          = |            = ;    |------------->|      = |      |
          = |            = ;    |       INVITE = F3     |      |
          = |            = ;    = |-------------------->|      |
          = |            = ;    = |          INVITE F4  = |      |
          = |            = ;    |--------------------------->|
          | 100 = Trying F5  = |            = ;  |      |      = |
          = |<---------------|183 Progress  |      = |      |
          = |            = ;    |<-------------|      = |      |
 Play=3D=3D=3D=3D=3D|<=3D=3D=3D=3D=3D=3DEarly = media=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|    &nb= sp; |      |
   ...    | 183 = Progress   = |            = ;  |      |      = |
          = |<---------------|        &nb= sp;     |      = |      |
          = |            = ;    | 183 Progress |      = |      |
          = |            = ;    = |<--------------------|      |
   = Blocked|X=3D=3D=3D=3D=3D=3D"Drinnnngg"=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|      = |
         = ; | 183 Progress   = |            = ;  |      |      = |
          = |<---------------|         = 180 Ringing F10    |
          = |     180 F11    = |<---------------------------|
   = Blocked|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D"Hello&quo= t;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|
          = |<---------------|        &nb= sp;   200 OK F12      |
          = |   200 OK F13   = |<---------------------------|
          = |<---------------|        &nb= sp;     |      = |      |
          = |            = ;    |   CANCEL 14  = |      |      = |
          = |            = ;    |------------->|(i)   = |      |
          = |            = ;    |  200 OK F15  = |      |      = |
      = (ii)|           &= nbsp;    = |<-------------|      = |      |
 Play=3D=3D=3D=3D=3D|<=3D=3D=3D=3D=3D=3DEarly = media=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| =      |
          = |            = ;    |    487 F16   = |      |      = |
          = |            = ;    |<-------------|      = |      |
          = |            = ;    |    ACK F17   = |      |      = |
          = |            = ;    |------------->|      = |      |
(i)  B1 stops sending media
(ii) Alice starts timer to detect stopped media = (i.e., not normal silence)
     has to decide to now play = media from B3 after being sufficiently confident
     that the other B1 stream is = stopped. Potentially big clipping.

On the idea of putting your proxy in Finland when you = work in Australia...
Seems to me that while you *can* do this, it is certa= inly not the
best engineering practice if you are trying to = maximize the responsiveness
of the system. SIP is not changing the laws of = physics.

Lastly, people have different expectations from a = phone service depending on
factors such as distance. If they know the far end = is overseas for example,
they are not as annoyed by a long call setup delay = and expect lesser voice
quality than if they are phoning their cubicule = neighbor. If you make calls
from cubicule-to-cubicule behave like they went from = Australia to Finland
and back, you should get braced for = complaints.

------_=_NextPart_001_01C2F988.8B65FAA0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 00:55:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25498 for ; Thu, 3 Apr 2003 00:55:15 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h335vLq29871 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 00:57:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h335vLK29868 for ; Thu, 3 Apr 2003 00:57:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25481 for ; Thu, 3 Apr 2003 00:54:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h335uRK29808; Thu, 3 Apr 2003 00:56:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h335tjK29770 for ; Thu, 3 Apr 2003 00:55:45 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25460 for ; Thu, 3 Apr 2003 00:53:08 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h335tXI3023269; Thu, 3 Apr 2003 07:55:33 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A495CV0; Thu, 3 Apr 2003 07:55:34 +0200 Received: from lmf.ericsson.se ([131.160.31.93]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h335tXAv007497; Thu, 3 Apr 2003 08:55:33 +0300 (EET DST) Message-ID: <3E8BCCD4.7D84CB04@lmf.ericsson.se> Date: Thu, 03 Apr 2003 08:55:32 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Taylor CC: Gonzalo Camarillo , Francois Audet , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" Subject: Re: [Sipping] New version of the early media draft References: <2F1FC1DEA077D5119FAD00508BCFD6D20787D68D@zsc3c030.us.nortel.com> <3E89248E.A4CF6816@lmf.ericsson.se> <3E8A12CE.7070204@nortelnetworks.com> <3E8A7F44.1020508@lmf.ericsson.se> <3E8AF9CC.10401@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Some small notes... First, please remember that in split architectures we talk about the time it takes for the 200 OK to reach the MGC, PLUS the time it takes for the possible MODIFY/MDCX to reach the MG. Now, I don't know if that makes any real difference to the issue. There may still be enough time before the "Hello" actually reaches the MG, but just to let you know... Second, with mobile phone kind of devices, and/or hands-free kind of devices, the time between the off-hook and the "Hello" is probably shorter than with "normal" phones, where you actually have to lift the hook, and place it towards your ear before you start to speak. Again, don't know if it makes any difference to the issue, but still... Third, the 200 race condition does not always mean we will have clipping. I am still against the "play everything you receive" stuff, but if we have established an early dialog with the same device which will send the 200, there probably will be no clipping (it of course depends on if there is local ringback etc). In forking scenarios, however, there may be clipping, since we may have established the early dialog with another device, and do not play media received from the device which finally sends 200 first (again, I may NOT be mixing everything I recieve from every leg, even if the spec says I should play everything...). Fourth, the note about the difference in receiving, and actually playing, media was "interesting". But, I still think there should be no requirements on media handling before the early dialog is actually established. Of course, one MAY still play and handle whatever media he receives, without knowing if it actually comes from some of the SIP devices he's trying to call, but everybody may not want to do that - due to a number of reasons. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 01:17:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25759 for ; Thu, 3 Apr 2003 01:17:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h336Jgx31456 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 01:19:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h336JgK31453 for ; Thu, 3 Apr 2003 01:19:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25756 for ; Thu, 3 Apr 2003 01:17:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h336HKK31376; Thu, 3 Apr 2003 01:17:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h336GqK31347 for ; Thu, 3 Apr 2003 01:16:52 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25719 for ; Thu, 3 Apr 2003 01:14:14 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h336GfI3027438; Thu, 3 Apr 2003 08:16:41 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4952QG; Thu, 3 Apr 2003 08:16:42 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h336GfAv008789; Thu, 3 Apr 2003 09:16:41 +0300 (EET DST) Message-ID: <3E8BD1C8.60203@lmf.ericsson.se> Date: Thu, 03 Apr 2003 09:16:40 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'sipping@ietf.org'" References: <475FF955A05DD411980D00508B6D5FB00439EC69@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: Some comments on draft-camarillo-sipping-early-media-01.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Keith, > Some fairly minor comments that need to be applied to this document > if it progresses with the current text in any of these areas. thanks for your comments. I will add them to the next revision of the draft. > A question over and above these comments - is the intent of this work > to result in a standards track document or an information document? > Which of those will affect whether some of the standard clauses are > needed or not. My original idea was to develop an informational document, but it may be better to make it a BCP document. However, it may turn out that we need to define something that is not already defined (e.g., the famous flag). In that case, we could define whatever in a different standards track document or define it here and make it a Proposed. Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 01:29:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25897 for ; Thu, 3 Apr 2003 01:29:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h336VtL32131 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 01:31:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h336VsK32128 for ; Thu, 3 Apr 2003 01:31:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25889 for ; Thu, 3 Apr 2003 01:29:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h336THK32014; Thu, 3 Apr 2003 01:29:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h336Q5K31841 for ; Thu, 3 Apr 2003 01:26:05 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25855 for ; Thu, 3 Apr 2003 01:23:26 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h336PrI3029325; Thu, 3 Apr 2003 08:25:53 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A465QV4; Thu, 3 Apr 2003 08:25:54 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h336PsAv009349; Thu, 3 Apr 2003 09:25:54 +0300 (EET DST) Message-ID: <3E8BD3F1.3060909@lmf.ericsson.se> Date: Thu, 03 Apr 2003 09:25:53 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: "Drage, Keith (Keith)" , "'sipping@ietf.org'" Subject: Re: [Sipping] Some comments on draft-camarillo-sipping-early-media-01.txt References: <5.1.1.6.0.20030313150038.024d36f0@pop.mcit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alan, inline Alan Johnston wrote: > At 08:30 PM 3/13/2003 +0000, Drage, Keith (Keith) wrote: > > > >> 10) Section 3, 1st paragraph, not a comment that requires fixing, >> but we have a dependency to the Join draft which will need to be >> finished before or at the same time as this draft. >> >> 11) Section 3, 1st paragraph, Amend final sentence to read "... by >> sending a new INVITE request to the URI it received in the Join header >> field." > > > This entire section is quite confusing. I think that Gonzalo does not > mean to reference the Join header field - it has no application in this > example. I think he means to reference the To-Join header field > proposed by Jonathan in the original call package > (http://www.softarmor.com/sipping/drafts/morgue/draft-rosenberg-sip-call-package-00.txt). > > > Also, the reference 5 cited in this section is the Application > Interaction Framework which again has no bearing on this idea of > separate dialogs for regular and early media. Perhaps the Application > Component Architecture document was the intended reference? > The idea (which was originally proposed by Jon), is to make the UAS establish early media with the UAC in the same way as an application server in the path would do it. Therefore, the idea is to reference the work of the application interaction design team. That's why we reference the draft below: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-app-interaction-framework-00.txt Regarding the Join header, the draft above says: However, the INVITE from the caller indicated that the device is capable of acting as a focus. How did it do that? It did so by indicating support for the SIP Join extension [11] which allows a UA to request to be conferenced into an existing dialog. As such, both app1 and app2, acting as a pure UAC, generate an INVITE towards this focus, with a Join header requesting to be added to a conference which includes the original dialog. The result is two additional dialogs, dialog A and dialog B respectively, which join the original dialog in their connection to a focus co-resident with the caller. Reference [11] in that draft is: [11] R. Mahy and D. Petrie, "The session initiation protocol (sip) join header," Internet Draft, Internet Engineering Task Force, Oct. 2002. Work in progress. Once we resolve other issues related to early media, we intend to align this section with the application interactions work, but with this summary I believe it is clear what we are trying to do. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 04:56:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11832 for ; Thu, 3 Apr 2003 04:56:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h339x4327866 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 04:59:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339x4K27862 for ; Thu, 3 Apr 2003 04:59:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11807 for ; Thu, 3 Apr 2003 04:56:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339rHK27606; Thu, 3 Apr 2003 04:53:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339mdK27329 for ; Thu, 3 Apr 2003 04:48:39 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11649 for ; Thu, 3 Apr 2003 04:45:55 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h339mNI3024879; Thu, 3 Apr 2003 11:48:23 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4K945R; Thu, 3 Apr 2003 11:48:24 +0200 Received: from lmf.ericsson.se ([131.160.31.93]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h339mOAv022510; Thu, 3 Apr 2003 12:48:24 +0300 (EET DST) Message-ID: <3E8C0367.105FC0D4@lmf.ericsson.se> Date: Thu, 03 Apr 2003 12:48:23 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Taylor CC: Gonzalo Camarillo , sipping@ietf.org, Jon Peterson , Mark Watson Subject: Re: [Sipping] Early media; a summary after the IETF References: <0449D80A0E9B614A83FA9031B07E8D3B257940@stntexch2.va.neustar.com> <000e01c2f609$d5730a20$2300000a@BPenfield> <3E87EEC4.1F974505@lmf.ericsson.se> <3E8858AB.80401@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, In Q.1950 there is a package called "Basic Call Progress Tones Generator with Directionality", which maybe could be used for this. It allows you to specify the direction of the tone, so basically you could play it on the RTP termination, but with the direction towards TDM termination. Now, the RTP detection and the ringback tone generation would take place on the same termination. There could maybe be issues with this solution, depending on the Context model, but that's another issue... Regards, Christer Holmberg Ericsson Finland Tom Taylor wrote: > Your charts do not reflect an important difference between MGCP and Megaco/H.248. > In MGCP, it is possible to tell the MG to automatically terminate application of > ringing tone upon detection of incoming media. In Megaco/H.248, the media event is > detected on one termination, but the ringing tone is being applied to another. This > means that the MG has to report media detection to the MGC, and then the MGC has to > request that ringing tone application be stopped. It has occurred to me upon > reflection that there might be a way around this, but for the moment that is the case. > > Gonzalo Camarillo wrote: > > Folks, > > > > here you have a summary of what happened in the IETF regarding early > > media. > > > > We planned to have an ad-hoc meeting, but since we managed to get more > > meeting time than expected for this issue and some of the persons > > involved in the mailing list discussions were not available for an > > ad-hoc meeting (some of them were not even in San Francisco), we did not > > finally have the ad-hoc. > > > > Regarding the discussions during the second SIPPING session, the main > > input was slide number 3 of > > > > http://www.softarmor.com/sipping/meets/ietf56/slides/Gonzalo-sipping-early-media.ppt > > > > That slide does not discuss the encoding issue. It focuses on the > > requirements or the gains that adding a SIP "there is media coming" (or > > "don't generate local ringback") indication would bring. > > > > The conclusion of that slide is that a message with "generate local > > ringback until media arrives" should be provided by the protocol (e.g., > > MGCP or H.248) between the MG and the MGC **REGARDLESS** of whether or > > not we create a "there is media coming" flag. > > > > Therefore, assuming that the MG is in accept-media state as soon as the > > INVITE is sent, the only gain that a "there is media coming" would bring > > would be saving one message from the MGC to the MG every time a 180 with > > a flag is received. The gain is zero for 180 responses without the flag. > > > > The question is: are people after this optimization (saving of one > > message in some circumstances) or there is somebody with something else > > in mind? > > > > > > In any event, the conclusion of the meeting was that I will be gathering > > use cases where a "there is media coming" flag would be useful. Please, > > send any use case you have in mind and I will compile them in a > > document. We hope that such a document help us figure out which > > requirement is missing. > > > > We also may organize a conference call in some weeks to further discuss > > the issue, if needed. > > > > Thanks, > > > > Gonzalo > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 04:58:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11938 for ; Thu, 3 Apr 2003 04:58:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33A0xn28024 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 05:00:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33A0xK28021 for ; Thu, 3 Apr 2003 05:00:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11908 for ; Thu, 3 Apr 2003 04:58:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339t9K27709; Thu, 3 Apr 2003 04:55:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h339pgK27495 for ; Thu, 3 Apr 2003 04:51:42 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11704 for ; Thu, 3 Apr 2003 04:48:58 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h339pMBd010451; Thu, 3 Apr 2003 04:51:22 -0500 (EST) Message-ID: <3E8C0411.6070809@dynamicsoft.com> Date: Thu, 03 Apr 2003 04:51:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: Pascal.Jalet@alcatel.fr, sipping@ietf.org Subject: Re: [Sipping] Proxy behavior with request URI parameters References: <4.3.2.7.2.20030314161140.03fb4e28@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If the proxy owns the domain in the request URI, then it is responsible for interpreting any parameters associated with that URI. As per the spec, if there are ones it doesnt understand, it should ignore them. But, the process of URI translation won't preserve those URI parameters or pass them forward. If, however, the proxy doesn't own the domain in the request URI, it will use the URI to look up in DNS where to send the request (as specified in rfc3263). In this case, it needs to interpet the URI, and as per the spec, will ignore parameters it doesnt understand. However, this proxy is not doing any translation or request URI rewriting, and therefore, would not change the URI, and thus not strip any parameters it doesnt understand. -Jonathan R. Michael Hammer wrote: > Pascal, > > My understanding has always been that for forward compatibility reasons, > the parameters get passed forward, else an older proxy would tend to > break any new SIP parameters defined later. > > Mike > > > At 06:18 PM 3/13/2003 +0100, Pascal.Jalet@alcatel.fr wrote: > >> Dear sipping members, >> >> What must be a proxy behaviour when it receives a SIP request >> with request-URI parameters that it doesn't undertstand. >> In RFC 3261, It is said that "SIP elements MUST silently ignore >> any uri-parameters that they do not understand". >> >> Does it mean: >> that the proxy removes the uri-parameters when constructing the >> forwarded request. >> that the proxy copies transparently the unknown uri-parameters >> in the >> request-URI of the >> forwarded request. >> >> thanks for your help >> >> Pascal >> >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 05:09:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12304 for ; Thu, 3 Apr 2003 05:09:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33ABiD29641 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 05:11:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33ABiK29638 for ; Thu, 3 Apr 2003 05:11:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12269 for ; Thu, 3 Apr 2003 05:08:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33A88K29158; Thu, 3 Apr 2003 05:08:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33A4UK28177 for ; Thu, 3 Apr 2003 05:04:30 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12001 for ; Thu, 3 Apr 2003 05:01:45 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h33A4ERs009677; Thu, 3 Apr 2003 12:04:14 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A467VV9; Thu, 3 Apr 2003 12:04:15 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h33A4EAv023589; Thu, 3 Apr 2003 13:04:15 +0300 (EET DST) Message-ID: <3E8C071C.6010402@lmf.ericsson.se> Date: Thu, 03 Apr 2003 13:04:12 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: Tom Taylor , sipping@ietf.org, Jon Peterson , Mark Watson Subject: Re: [Sipping] Early media; a summary after the IETF References: <0449D80A0E9B614A83FA9031B07E8D3B257940@stntexch2.va.neustar.com> <000e01c2f609$d5730a20$2300000a@BPenfield> <3E87EEC4.1F974505@lmf.ericsson.se> <3E8858AB.80401@nortelnetworks.com> <3E8C0367.105FC0D4@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Christer. This is something that is needed, so it is great that H.248 supports it. Gonzalo Christer Holmberg wrote: > Hi, > > In Q.1950 there is a package called "Basic Call Progress Tones Generator with > Directionality", which maybe could be used for this. It allows you to specify the > direction of the tone, so basically you could play it on the RTP termination, but with the > direction towards TDM termination. Now, the RTP detection and the ringback tone generation > would take place on the same termination. > > There could maybe be issues with this solution, depending on the Context model, but that's > another issue... > > Regards, > > Christer Holmberg > Ericsson Finland > > > Tom Taylor wrote: > > >>Your charts do not reflect an important difference between MGCP and Megaco/H.248. >>In MGCP, it is possible to tell the MG to automatically terminate application of >>ringing tone upon detection of incoming media. In Megaco/H.248, the media event is >>detected on one termination, but the ringing tone is being applied to another. This >>means that the MG has to report media detection to the MGC, and then the MGC has to >>request that ringing tone application be stopped. It has occurred to me upon >>reflection that there might be a way around this, but for the moment that is the case. >> >>Gonzalo Camarillo wrote: >> >>>Folks, >>> >>>here you have a summary of what happened in the IETF regarding early >>>media. >>> >>>We planned to have an ad-hoc meeting, but since we managed to get more >>>meeting time than expected for this issue and some of the persons >>>involved in the mailing list discussions were not available for an >>>ad-hoc meeting (some of them were not even in San Francisco), we did not >>>finally have the ad-hoc. >>> >>>Regarding the discussions during the second SIPPING session, the main >>>input was slide number 3 of >>> >>>http://www.softarmor.com/sipping/meets/ietf56/slides/Gonzalo-sipping-early-media.ppt >>> >>>That slide does not discuss the encoding issue. It focuses on the >>>requirements or the gains that adding a SIP "there is media coming" (or >>>"don't generate local ringback") indication would bring. >>> >>>The conclusion of that slide is that a message with "generate local >>>ringback until media arrives" should be provided by the protocol (e.g., >>>MGCP or H.248) between the MG and the MGC **REGARDLESS** of whether or >>>not we create a "there is media coming" flag. >>> >>>Therefore, assuming that the MG is in accept-media state as soon as the >>>INVITE is sent, the only gain that a "there is media coming" would bring >>>would be saving one message from the MGC to the MG every time a 180 with >>>a flag is received. The gain is zero for 180 responses without the flag. >>> >>>The question is: are people after this optimization (saving of one >>>message in some circumstances) or there is somebody with something else >>>in mind? >>> >>> >>>In any event, the conclusion of the meeting was that I will be gathering >>>use cases where a "there is media coming" flag would be useful. Please, >>>send any use case you have in mind and I will compile them in a >>>document. We hope that such a document help us figure out which >>>requirement is missing. >>> >>>We also may organize a conference call in some weeks to further discuss >>>the issue, if needed. >>> >>>Thanks, >>> >>>Gonzalo >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the application of SIP >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sip@ietf.org for new developments of core SIP >>> >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 05:15:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12434 for ; Thu, 3 Apr 2003 05:15:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33AHpx30040 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 05:17:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AHpK30037 for ; Thu, 3 Apr 2003 05:17:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12428 for ; Thu, 3 Apr 2003 05:15:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AC5K29770; Thu, 3 Apr 2003 05:12:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33ABuK29675 for ; Thu, 3 Apr 2003 05:11:56 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12287 for ; Thu, 3 Apr 2003 05:09:12 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h33ABeI3000705; Thu, 3 Apr 2003 12:11:40 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A497PN7; Thu, 3 Apr 2003 12:11:41 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h33ABeAv024113; Thu, 3 Apr 2003 13:11:40 +0300 (EET DST) Message-ID: <3E8C08DA.5030201@lmf.ericsson.se> Date: Thu, 03 Apr 2003 13:11:38 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Taylor CC: Francois Audet , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" Subject: Re: [Sipping] New version of the early media draft References: <2F1FC1DEA077D5119FAD00508BCFD6D20787D68D@zsc3c030.us.nortel.com> <3E89248E.A4CF6816@lmf.ericsson.se> <3E8A12CE.7070204@nortelnetworks.com> <3E8A7F44.1020508@lmf.ericsson.se> <3E8AF9CC.10401@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom, it is not as simple as that. Your 100 ms are the transmission delay in optimal conditions. In the real world you will have to add queuing delay in the routers and processing delay in the SIP nodes. And that is not all. Let's say that some proxies have to perform DNS look-ups when sending the response (sometimes you need to). You can add one or two seconds to the final figure... In general, since signalling and media traverse different paths, their RTTs are not related. The network conditions in one path may have nothing to do witht he network conditions in the other. Gonzalo Tom Taylor wrote: > Your difference in geography represents all of 100 ms, if I remember the > formula correctly. I suspect codec delays often come to more than > that. In any event, there is a human delay between the off-hook or > equivalent and the "Hello". > > Leaving that aside, the normal method of engineering grade of service is > to allow for unacceptable results in a small percentage of cases rather > than aiming for perfection -- the latter costs too much. I suspect your > round-the-world proxy chain for near-neighbours would amount to a small > percentage of all calls. > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 05:22:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12577 for ; Thu, 3 Apr 2003 05:22:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33AOw930458 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 05:24:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AOvK30454 for ; Thu, 3 Apr 2003 05:24:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12567 for ; Thu, 3 Apr 2003 05:22:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AJ7K30125; Thu, 3 Apr 2003 05:19:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33AIlK30082 for ; Thu, 3 Apr 2003 05:18:47 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12449 for ; Thu, 3 Apr 2003 05:16:02 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h33AITRs013979; Thu, 3 Apr 2003 12:18:29 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4K97PN; Thu, 3 Apr 2003 12:18:30 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h33AIUAv024568; Thu, 3 Apr 2003 13:18:30 +0300 (EET DST) Message-ID: <3E8C0A73.7000906@lmf.ericsson.se> Date: Thu, 03 Apr 2003 13:18:27 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet CC: Tom-PT Taylor , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" , Mark Watson Subject: Re: [Sipping] New version of the early media draft References: <2F1FC1DEA077D5119FAD00508BCFD6D20794E863@zsc3c030.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Francois, you are missing the point of the draft. The draft explains what happens when you use early media within the dialog are forking occurs. That is, you have a lot of problems. The aim of the draft is to describe these problems and to describe things that a UAC may do without extending the protocol. We do that because you have to interact with existing UASs that will send you media this way. You cannot upgrade the already installed base. But we do not want to extend the protocol to provide a solution for this gateway model. We recommend that new systems use the application server model. In this model, we will provide solutions and extend the protocol should that be needed. Gonzalo Francois Audet wrote: > > First of all, I do not understand why people continue > > discussing things > > like early media with forking whose problems are already well > > discussed > > and documented in the draft and nobody so far has been able > > to come up > > with a single use case where the proposed flag would be useful... I > > would ask people to focus on the problem in hand (i.e., the > > flag), and > > stop discussing about already resolved issues. > > The problem is that the multiple dialog problem and early media problem > (as in forking > for example) has NOT been solved. Worst, using the current unworkable > solution as a basis > to make our decisions on the flag issue will not result in a good solution. > > The current solution for forking in the draft is for the UAC to pick a > random media > stream (based on signaling, thus the dialog, not media, because there is > no means to correlate > dialog and media stream) and mute the others by sending UPDATEs to the > far end. This is > not an acceptable solution. Random non-redictable behavior is not > acceptable to end-users. > Furthemore, this is not robust at all because if the called UA does not > support UPDATE, > multiple streams will be received and there will be no way for the UAC > receiving it > to pick the proper one. (If there was a way to correlate an RTP stream > to the dialog that > generate it, it would be easier) > > This leaves the client with 3 choices: > 1) Pick a random media stream (which it will not be able to correlate > with a specific dialog > unless it is lucky with educated guesses). > 2) Mix media streams together. > 3) Provide alternative local treatment based on the provisional > responses received. This > could be > > You are right that the flag probably doesn't help with this problem. > I'll leave it > to others to defend the flag idea. > > I'm OK with current draft, as long as we do not ADD any more dependency > on the "play > media when you receive it" principle to address the flag prolem, and as > long as we improve > the section on forking. It seems to me that if forking is used we CAN > NOT use early media for > in-band ringing (we could do early media for clipping avoidance). > Perhaps we need a > "forked" indication in INVITE telling the far-end not to send early > media... And to make > it bullet proof a forked indication in the 100 Trying (when forking) to > tell the UAC making the > call that "weird stuff" is going to happen and that proper treatment > should be used not > to confused the user. > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 07:21:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17266 for ; Thu, 3 Apr 2003 07:21:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33CNkf08154 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 07:23:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CNkK08151 for ; Thu, 3 Apr 2003 07:23:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17256 for ; Thu, 3 Apr 2003 07:20:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CL7K08009; Thu, 3 Apr 2003 07:21:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CKBK07937 for ; Thu, 3 Apr 2003 07:20:11 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17066 for ; Thu, 3 Apr 2003 07:17:23 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33CJmU15963; Thu, 3 Apr 2003 13:19:48 +0100 (BST) Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HG1MJNRV; Thu, 3 Apr 2003 13:19:33 +0100 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Apr 2003 13:19:09 +0100 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'Gonzalo Camarillo'" , "Tom-PT Taylor" Cc: sipping@ietf.org, Jon Peterson Subject: RE: [Sipping] Early media; a summary after the IETF Date: Thu, 3 Apr 2003 13:19:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F9DB.39C4B242" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2F9DB.39C4B242 Content-Type: text/plain; charset="iso-8859-1" Gonzalo, all, This addition to H.248 would certainly help with this problem, and indeed addresses one of the reasons why I argued this flag was necessary. Note that the mail from Christer suggests a way forward, but this is not completely supported in H.248 yet. Obviously, this solution can 'work', but I am still not sure it is a good design. My other point, which seems not to have been captured in Gonzalo's slides (although I don't know if it was discussed at the meeting), was that as a general principle, the status of the media stream should be visible at the signalling layer. This is the case in all the other call/session control protocols that I know of. The current status of SIP seems to be that whether there is media present or not is indicated only at the RTP layer, by the physical presence or otherwise of RTP packets. This creates the problem that deliberate absence of media is indistinguishable at the UAC from an error case in which media has been blocked due to some network issue/NAT problem etc. At the very least this makes debugging more difficult. In addition, since this is the principle which has been adopted by so many other call/session control protocols, then a gateway interworking from one of these to SIP will not have the information necessary to simply map to indications in appropriate backwards signalling messages. For example in mapping a SIP 180 to a Q.SIG or Q.931 ALERTING, I am forced to always provide in-band media (ringtone or media received from the UAS) and indicate this in the ALERTING/Q.931, whereas if I had an indication at the SIP layer I could take advantage of this to indicate no in-band media in the ALERTING (in some cases) and save myself on tone generation. Finally, if I want to secure the implicit indication of media then I need to secure the RTP stream itself (which is not otherwise required in all applications). To secure a SIP-layer indication I have all the SIP-layer security stuff available. I am not arguing that these examples alone justify such an indication, but rather that as a general principle this information should be signalled explicitly in SIP, not implicitly by the presence of RTP packets. I accept that the SIPPING meeting was not convinced that enough examples/use-cases had been presented to justify the indication, and if this remains the case then I guess nothing will be agreed. But as I feel these all stem from a more general principle, I think over time we will continue to see more examples emerge. ...Mark > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 01 April 2003 08:28 > To: Taylor, Tom-PT [CAR:5N00:EXCH] > Cc: sipping@ietf.org; Jon Peterson; Watson, Mark [MOP:EP10:EXCH] > Subject: Re: [Sipping] Early media; a summary after the IETF > > > Tom, > > yes, this was mentioned in the meeting. > > In any event, it is important that H.248 supports this type > of message > (generate ringback until media arrives), since it is needed > regardless > of any new flags or extensions that we could come up with. It > would be > good if somebody could work on that. > > Thanks, > > Gonzalo > > Tom Taylor wrote: > > Your charts do not reflect an important difference between MGCP and > > Megaco/H.248. In MGCP, it is possible to tell the MG to > automatically > > terminate application of ringing tone upon detection of > incoming media. > > In Megaco/H.248, the media event is detected on one > termination, but the > > ringing tone is being applied to another. This means that > the MG has to > > report media detection to the MGC, and then the MGC has to > request that > > ringing tone application be stopped. It has occurred to me upon > > reflection that there might be a way around this, but for > the moment > > that is the case. > > > > Gonzalo Camarillo wrote: > > > >> Folks, > >> > >> here you have a summary of what happened in the IETF > regarding early > >> media. > >> > >> We planned to have an ad-hoc meeting, but since we managed > to get more > >> meeting time than expected for this issue and some of the persons > >> involved in the mailing list discussions were not available for an > >> ad-hoc meeting (some of them were not even in San > Francisco), we did not > >> finally have the ad-hoc. > >> > >> Regarding the discussions during the second SIPPING > session, the main > >> input was slide number 3 of > >> > >> http://www.softarmor.com/sipping/meets/ietf56/slides/Gonzalo-sipping-early-m edia.ppt >> >> >> That slide does not discuss the encoding issue. It focuses on the >> requirements or the gains that adding a SIP "there is media coming" (or >> "don't generate local ringback") indication would bring. >> >> The conclusion of that slide is that a message with "generate local >> ringback until media arrives" should be provided by the protocol (e.g., >> MGCP or H.248) between the MG and the MGC **REGARDLESS** of whether or >> not we create a "there is media coming" flag. >> >> Therefore, assuming that the MG is in accept-media state as soon as the >> INVITE is sent, the only gain that a "there is media coming" would bring >> would be saving one message from the MGC to the MG every time a 180 with >> a flag is received. The gain is zero for 180 responses without the flag. >> >> The question is: are people after this optimization (saving of one >> message in some circumstances) or there is somebody with something else >> in mind? >> >> >> In any event, the conclusion of the meeting was that I will be gathering >> use cases where a "there is media coming" flag would be useful. Please, >> send any use case you have in mind and I will compile them in a >> document. We hope that such a document help us figure out which >> requirement is missing. >> >> We also may organize a conference call in some weeks to further discuss >> the issue, if needed. >> >> Thanks, >> >> Gonzalo >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP >> > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C2F9DB.39C4B242 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] Early media; a summary after the IETF

Gonzalo, all,

This addition to H.248 would certainly help with this = problem, and indeed addresses one of the reasons why I argued this flag = was necessary. Note that the mail from Christer suggests a way forward, = but this is not completely supported in H.248 yet.

Obviously, this solution can 'work', but I am still = not sure it is a good design.

My other point, which seems not to have been captured = in Gonzalo's slides (although I don't know if it was discussed at the = meeting), was that as a general principle, the status of the media = stream should be visible at the signalling layer. This is the case in = all the other call/session control protocols that I know of.

The current status of SIP seems to be that whether = there is media present or not is indicated only at the RTP layer, by = the physical presence or otherwise of RTP packets.

This creates the problem that deliberate absence of = media is indistinguishable at the UAC from an error case in which media = has been blocked due to some network issue/NAT problem etc. At the very = least this makes debugging more difficult.

In addition, since this is the principle which has = been adopted by so many other call/session control protocols, then a = gateway interworking from one of these to SIP will not have the = information necessary to simply map to indications in appropriate = backwards signalling messages. For example in mapping a SIP 180 to a = Q.SIG or Q.931 ALERTING, I am forced to always provide in-band media = (ringtone or media received from the UAS) and indicate this in the = ALERTING/Q.931, whereas if I had an indication at the SIP layer I could = take advantage of this to indicate no in-band media in the ALERTING (in = some cases) and save myself on tone generation.

Finally, if I want to secure the implicit indication = of media then I need to secure the RTP stream itself (which is not = otherwise required in all applications). To secure a SIP-layer = indication I have all the SIP-layer security stuff = available.

I am not arguing that these examples alone justify = such an indication, but rather that as a general principle this = information should be signalled explicitly in SIP, not implicitly by = the presence of RTP packets.

I accept that the SIPPING meeting was not convinced = that enough examples/use-cases had been presented to justify the = indication, and if this remains the case then I guess nothing will be = agreed. But as I feel these all stem from a more general principle, I = think over time we will continue to see more examples = emerge.

...Mark

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: 01 April 2003 08:28
> To: Taylor, Tom-PT [CAR:5N00:EXCH]
> Cc: sipping@ietf.org; Jon Peterson; Watson, = Mark [MOP:EP10:EXCH]
> Subject: Re: [Sipping] Early media; a summary = after the IETF
>
>
> Tom,
>
> yes, this was mentioned in the meeting.
>
> In any event, it is important that H.248 = supports this type
> of message
> (generate ringback until media arrives), since = it is needed
> regardless
> of any new flags or extensions that we could = come up with. It
> would be
> good if somebody could work on that.
>
> Thanks,
>
> Gonzalo
>
> Tom Taylor wrote:
> > Your charts do not reflect an important = difference between MGCP and
> > Megaco/H.248. In MGCP, it is possible to = tell the MG to
> automatically
> > terminate application of ringing tone upon = detection of
> incoming media. 
> > In Megaco/H.248, the media event is = detected on one
> termination, but the
> > ringing tone is being applied to = another.  This means that
> the MG has to
> > report media detection to the MGC, and = then the MGC has to
> request that
> > ringing tone application be stopped.  = It has occurred to me upon
> > reflection that there might be a way = around this, but for
> the moment
> > that is the case.
> >
> > Gonzalo Camarillo wrote:
> >
> >> Folks,
> >>
> >> here you have a summary of what = happened in the IETF
> regarding early
> >> media.
> >>
> >> We planned to have an ad-hoc meeting, = but since we managed
> to get more
> >> meeting time than expected for this = issue and some of the persons
> >> involved in the mailing list = discussions were not available for an
> >> ad-hoc meeting (some of them were not = even in San
> Francisco), we did not
> >> finally have the ad-hoc.
> >>
> >> Regarding the discussions during the = second SIPPING
> session, the main
> >> input was slide number 3 of
> >>
> >>
http://www.softarmor.com/sipping/meets/ietf56/slides/G= onzalo-sipping-early-media.ppt
>>
>>
>> That slide does not discuss the encoding = issue. It focuses on the
>> requirements or the gains that adding a SIP = "there is media coming" (or
>> "don't generate local ringback") = indication would bring.
>>
>> The conclusion of that slide is that a = message with "generate local
>> ringback until media arrives" should = be provided by the protocol (e.g.,
>> MGCP or H.248) between the MG and the MGC = **REGARDLESS** of whether or
>> not we create a "there is media = coming" flag.
>>
>> Therefore, assuming that the MG is in = accept-media state as soon as the
>> INVITE is sent, the only gain that a = "there is media coming" would bring
>> would be saving one message from the MGC to = the MG every time a 180 with
>> a flag is received. The gain is zero for = 180 responses without the flag.
>>
>> The question is: are people after this = optimization (saving of one
>> message in some circumstances) or there is = somebody with something else
>> in mind?
>>
>>
>> In any event, the conclusion of the meeting = was that I will be gathering
>> use cases where a "there is media = coming" flag would be useful. Please,
>> send any use case you have in mind and I = will compile them in a
>> document. We hope that such a document help = us figure out which
>> requirement is missing.
>>
>> We also may organize a conference call in = some weeks to further discuss
>> the issue, if needed.
>>
>> Thanks,
>>
>> Gonzalo
>> = _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the = application of SIP
>> Use sip-implementors@cs.columbia.edu for = questions on current sip
>> Use sip@ietf.org for new developments of = core SIP
>>
>
> = _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the = application of SIP
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sip@ietf.org for new developments of core = SIP

------_=_NextPart_001_01C2F9DB.39C4B242-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 07:48:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18037 for ; Thu, 3 Apr 2003 07:48:49 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33Cp4310702 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 07:51:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33Cp4K10699 for ; Thu, 3 Apr 2003 07:51:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17999 for ; Thu, 3 Apr 2003 07:48:17 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CoTK10646; Thu, 3 Apr 2003 07:50:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33CnxK10570 for ; Thu, 3 Apr 2003 07:49:59 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17924 for ; Thu, 3 Apr 2003 07:47:12 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h33CneI3014475; Thu, 3 Apr 2003 14:49:40 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A469KGS; Thu, 3 Apr 2003 14:49:40 +0200 Received: from lmf.ericsson.se ([131.160.31.93]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h33CnfAv004661; Thu, 3 Apr 2003 15:49:41 +0300 (EET DST) Message-ID: <3E8C2DE3.312ED2BB@lmf.ericsson.se> Date: Thu, 03 Apr 2003 15:49:40 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "'Gonzalo Camarillo'" , Tom-PT Taylor , sipping@ietf.org, Jon Peterson Subject: Re: [Sipping] Early media; a summary after the IETF References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Mark, Just a short question: what do you mean "is not completely supported in H.248 yet"? It's a package, which has been standardized, so from that point of view I think it as "supported" as anything else... Or, did I missunderstand you? I would also like to hear your arguments why/what you don't think is good design? The fact that in H.248 an event can stop a signal, or what? I do agree, which I also mentioned in the mail, that there may be some issues. Those, however, are more related to the Context model. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 08:29:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19284 for ; Thu, 3 Apr 2003 08:29:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33DW7Q13566 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 08:32:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33DW7K13563 for ; Thu, 3 Apr 2003 08:32:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19280 for ; Thu, 3 Apr 2003 08:29:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33DVNK13529; Thu, 3 Apr 2003 08:31:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33DUtK13469 for ; Thu, 3 Apr 2003 08:30:55 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19236 for ; Thu, 3 Apr 2003 08:28:07 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (europem01.nt.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33DUVU29441; Thu, 3 Apr 2003 14:30:31 +0100 (BST) Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HG1MJWHK; Thu, 3 Apr 2003 14:30:31 +0100 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Apr 2003 14:30:15 +0100 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'Christer Holmberg'" Cc: "'Gonzalo Camarillo'" , "Tom-PT Taylor" , sipping@ietf.org, Jon Peterson Subject: RE: [Sipping] Early media; a summary after the IETF Date: Thu, 3 Apr 2003 14:30:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F9E4.E14D8990" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2F9E4.E14D8990 Content-Type: text/plain; charset="iso-8859-1" Christer, I meant the part that allows you to ask the termination to 'play a tone until you get incoming media, then play that' - or perhaps I've missed something and that is already possible too ? It is the use of RTP packets themselves as an implicit indication that there is early inband media, compared to defining an explicit signalling indication that I think is a bad design. If you only have the former, implicit, indication available, then I see nothing wrong with your proposal wrt H.248. ...Mark > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: 03 April 2003 13:50 > To: Watson, Mark [MOP:EP10:EXCH] > Cc: 'Gonzalo Camarillo'; Taylor, Tom-PT [CAR:5N00:EXCH]; > sipping@ietf.org; Jon Peterson > Subject: Re: [Sipping] Early media; a summary after the IETF > > > > Hi Mark, > > Just a short question: what do you mean "is not completely > supported in > H.248 yet"? It's a package, which has been standardized, so from that > point of view I think it as "supported" as anything else... > > Or, did I missunderstand you? > > I would also like to hear your arguments why/what you don't think is > good design? The fact that in H.248 an event can stop a > signal, or what? > > I do agree, which I also mentioned in the mail, that there may be some > issues. Those, however, are more related to the Context model. > > Regards, > > Christer Holmberg > Ericsson Finland > > > ------_=_NextPart_001_01C2F9E4.E14D8990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] Early media; a summary after the IETF

Christer,

I meant the part that allows you to ask the = termination to 'play a tone until you get incoming media, then play = that' - or perhaps I've missed something and that is already possible = too ?

It is the use of RTP packets themselves as an = implicit indication that there is early inband media, compared to = defining an explicit signalling indication that I think is a bad = design. If you only have the former, implicit, indication available, = then I see nothing wrong with your proposal wrt H.248.

...Mark

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: 03 April 2003 13:50
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: 'Gonzalo Camarillo'; Taylor, Tom-PT = [CAR:5N00:EXCH];
> sipping@ietf.org; Jon Peterson
> Subject: Re: [Sipping] Early media; a summary = after the IETF
>
>
>
> Hi Mark,
>
> Just a short question: what do you mean = "is not completely
> supported in
> H.248 yet"? It's a package, which has been = standardized, so from that
> point of view I think it as = "supported" as anything else...
>
> Or, did I missunderstand you?
>
> I would also like to hear your arguments = why/what you don't think is
> good design? The fact that in H.248 an event = can stop a
> signal, or what?
>
> I do agree, which I also mentioned in the mail, = that there may be some
> issues. Those, however, are more related to the = Context model.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
>

------_=_NextPart_001_01C2F9E4.E14D8990-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 09:27:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20932 for ; Thu, 3 Apr 2003 09:27:23 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33ETew18403 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 09:29:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33ETeK18400 for ; Thu, 3 Apr 2003 09:29:40 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20927 for ; Thu, 3 Apr 2003 09:26:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33EShK18302; Thu, 3 Apr 2003 09:28:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33EPTK18083 for ; Thu, 3 Apr 2003 09:25:29 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20756; Thu, 3 Apr 2003 09:22:39 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33EOx502036; Thu, 3 Apr 2003 15:24:59 +0100 (BST) Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HG1MJ8RW; Thu, 3 Apr 2003 15:25:00 +0100 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Apr 2003 15:23:59 +0100 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'zhigang.c.liu@nokia.com'" , Robert.Sugar@nokia.com Cc: rohc@ietf.org, sipping@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Thu, 3 Apr 2003 15:23:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F9EC.A5F4BAB4" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2F9EC.A5F4BAB4 Content-Type: text/plain; charset="iso-8859-1" Zhigang, If I understand the solution described by Robert correctly, then the problem you describe below does not arise. Your problem seems to assume that demultiplexing of compressed and uncompressed messages will be done before the SIP parser is invoked, based on the 11111xxx delimiter. My understanding is that messages are passed directly to the SIP parser. This software must be aware that SIGCOMP may be used, and checks the first octet of the input stream. If this is 11111xxx then it uses the sigcomp delimeter OxFFFF to find the end of the compressed message, and then sends it to the decompressor. If the first octets is not 11111xxx then it just starts parsing as normal. The only assumption is that the SIP parser has its own way of recognising the end of an uncompressed message. Regards...Mark > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: 01 April 2003 14:44 > To: Robert.Sugar@nokia.com > Cc: rohc@ietf.org; sipping@ietf.org > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > messages > > > Robert, > > > I don't think it is a problem with SigComp multiplexing, but > > more like a SIP internal issue. What if there is a TCP stream > > of SIP messages and the Content-Length header is missing or > > false? They will screw up the same way with or without > > SigComp. > > Since TCP is a reliable transport, this only happens for a > mis-behaved SIP sender. But that is not the "multiplexing" problem > I mentioned below, which happens even "during normal functioning" > (see below). > > > During normal functioning both SIP and SigComp > > provide their own flow separation mechanism and they work just fine. > > I don't think so. That is what I intended to show by the example, > i.e. the issue to "multiplex uncompressed application messages and > SigComp messages on the same port". One solution, as I mentioned > before, is to require sigcomp receiver has the ability to parse > uncompressed application messages and detect the end. > > (Of course, I saw Carsten's email and I need understand his > point of view, which says there is no such "multiplexing" and > it is not possible and necessary.) > > BR, > Zhigang > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > ------_=_NextPart_001_01C2F9EC.A5F4BAB4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = messages

Zhigang,

If I understand the solution described by Robert = correctly, then the problem you describe below does not arise. Your = problem seems to assume that demultiplexing of compressed and = uncompressed messages will be done before the SIP parser is invoked, = based on the 11111xxx delimiter.

My understanding is that messages are passed directly = to the SIP parser. This software must be aware that SIGCOMP may be = used, and checks the first octet of the input stream. If this is = 11111xxx then it uses the sigcomp delimeter OxFFFF to find the end of = the compressed message, and then sends it to the decompressor. If the = first octets is not 11111xxx then it just starts parsing as = normal.

The only assumption is that the SIP parser has its = own way of recognising the end of an uncompressed message.

Regards...Mark

> -----Original Message-----
> From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> Sent: 01 April 2003 14:44
> To: Robert.Sugar@nokia.com
> Cc: rohc@ietf.org; sipping@ietf.org
> Subject: RE: [rohc] RE: [Sipping] SIGCOMP and = large binary content SIP
> messages
>
>
> Robert,
>
> >  I don't think it is a problem with = SigComp multiplexing, but
> > more like a SIP internal issue. What if = there is a TCP stream
> > of SIP messages and the Content-Length = header is missing or
> > false? They will screw up the same way = with or without
> > SigComp.
>
> Since TCP is a reliable transport, this only = happens for a
> mis-behaved SIP sender. But that is not the = "multiplexing" problem
> I mentioned below, which happens even = "during normal functioning"
> (see below).
>
> > During normal functioning both SIP and = SigComp
> > provide their own flow separation = mechanism and they work just fine.
>
> I don't think so. That is what I intended to = show by the example,
> i.e. the issue to "multiplex uncompressed = application messages and
> SigComp messages on the same port". One = solution, as I mentioned
> before, is to require sigcomp receiver has the = ability to parse
> uncompressed application messages and detect = the end.
>
> (Of course, I saw Carsten's email and I need = understand his
> point of view, which says there is no such = "multiplexing" and
> it is not possible and necessary.)
>
> BR,
> Zhigang
> = _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the = application of SIP
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sip@ietf.org for new developments of core = SIP
>

------_=_NextPart_001_01C2F9EC.A5F4BAB4-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 09:37:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21424 for ; Thu, 3 Apr 2003 09:37:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33Ee4020126 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 09:40:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33Ee4K20123 for ; Thu, 3 Apr 2003 09:40:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21413 for ; Thu, 3 Apr 2003 09:37:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33EcHK19910; Thu, 3 Apr 2003 09:38:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33EbbK19746 for ; Thu, 3 Apr 2003 09:37:37 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21302; Thu, 3 Apr 2003 09:34:44 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (europem01.nt.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33Eaf503664; Thu, 3 Apr 2003 15:36:41 +0100 (BST) Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HG1MJ0P2; Thu, 3 Apr 2003 15:36:42 +0100 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Apr 2003 15:35:32 +0100 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'Price, Richard'" , "'zhigang.c.liu@nokia.com'" , cabo@tzi.org, Lars-Erik.Jonsson@epl.ericsson.se Cc: rohc@ietf.org, sipping@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Thu, 3 Apr 2003 15:35:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F9EE.466598D2" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2F9EE.466598D2 Content-Type: text/plain; charset="iso-8859-1" Richard, all, The issue I would like to see addressed is as follows: The text part of SIP/SDP is obviously highly compressible using very simple algorithms which refer back to previous parts of the message/earlier messages. In fact, subsequent messages in a SIP dialog seem to consist almost entirely of repeated text from previous messages. So, it seems important to me that large binary content in SIP messages does not destroy state that will be useful in compressing subsequent messages. In a wireless environment, the principle advantage of compression is reduction in the time taken to actually send the message over the wireless link (this may even be more important than the overall reduction in signalling bandwidth). Now if the message contains large binary content, then of course we are 'out of luck' on the message transfer time stakes, but this shouldn't affect subsequent messages. I believe we should document recommendations to SIGCOMP compressor designers to ensure this aspect is not overlooked (although it is not immediately clear to me how the compressor (being unaware of the SIP message structure) might achieve this.) Is this something that would be appropriate to item 4 below ? Regards...Mark > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: 26 March 2003 13:58 > To: 'zhigang.c.liu@nokia.com'; cabo@tzi.org; > Lars-Erik.Jonsson@epl.ericsson.se > Cc: rohc@ietf.org; sipping@ietf.org > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > mes sages > > > Hi, > > I think that the issue with SigComp and large binary > content SIP messages is part of a more general issue - > namely that before using SigComp to compress a particular > application we need to standardise the following: > > 1. Mechanism for SigComp discovery > 2. Resources offered by SigComp > 3. How to delimit messages > 4. When to save state > > Currently the SIPPING WG has provided RFCs for 1 and 2, > but not for 3 and 4. It would be useful to get a draft > out for these ASAP, as it would clarify several issues on > how to get SigComp working with SIP (including the issue > with large binary content SIP messages). > > > Unless someone objects, I'll submit it in ROHC. > > I think that any WG draft should be a product of the > SIPPING WG, because the proposed solution for delimiting > SigComp messages will need to take into account the > behaviour of SIP itself (or we won't be able to multiplex > SigComp and SIP messages on the same port). However, it > would be good to get the ROHC WG involved in generating > the draft as well! > > Regards, > > Richard > > P.S. For anyone who's interested, the mechanisms that > particular applications need to provide before they can > use SigComp are as follows... > > ------------------------------------------------------ > > 1. Mechanism for SigComp discovery > > - How does the application know when to use SigComp? > > For SIP this issue is already sorted (RFC 3486). > > ------------------------------------------------------ > > 2. Resources offered by SigComp > > - Does the application need to offer more than the > minimum amount of resources? > > - Does the application need any extra state (e.g. > a static dictionary)? > > For SIP we've already got a static dictionary (RFC 3485). > However, we haven't currently discussed how much memory > should be provided in a SigComp implementation for SIP. > If we don't specify a value then SigComp defaults to the > minimum possible (2K), which is rather tight for some of > the more generously sized SIP messages! > > ------------------------------------------------------ > > 3. How to delimit messages > > - How does the application distinguish between > SigComp messages and uncompressed messages? > > - Is the application allowed to use "continuous mode"? > > This is the issue that's been raised for large binary > content SIP messages. If we want to send a mix of > uncompressed and SigComp messages within the same TCP > connection, how do we delimit the end of one message and > the start of another? > > A related issue is how to handle very large SIP messages > (> 64K). SigComp is able to compress large SIP messages > by using "continuous mode", where the message boundaries > are ignored completely and the application data is just > transmitted as a stream. However, this mode of operation > raises some additional security issues, so it's up to the > SIPPING WG to decide whether or not to use it in SigComp > for SIP. > > ------------------------------------------------------ > > 4. When to save state > > - How much security is needed in order to save state? > > - Which messages belong to each state "compartment"? > > - How long should the application keep state? > > This is quite an important issue that doesn't seem to > have been discussed in the SIPPING WG. It's up to the > application whether or not to let SigComp save state, > and for interoperability it's important to have at > least a general idea of how long to keep saved state, > when to reject state due to insufficient security etc. > > ------------------------------------------------------ > > > -----Original Message----- > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > Sent: Tuesday, March 25, 2003 6:00 PM > > To: cabo@tzi.org; Lars-Erik.Jonsson@epl.ericsson.se > > Cc: rohc@ietf.org; sipping@ietf.org > > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary > content SIP > > messages > > > > > > Hi Carsten and Lars-Erik, > > > > I've volunteered to submit a personal draft on this issue. From > > ROHC WG chairs' point of view, do you think this is the way > > to proceed? > > > > Of course, I understood during the IETF56 that Carsten had some > > doubts on whether this is indeed an issue. My email below explained > > the issue a bit. I don't know if it's clear. Either way, we > > can continue discuss this in ROHC mailing list > > > http://www1.ietf.org/mail-archive/working-groups/sipping/curre > nt/msg04115.html > > > > BR, > > Zhigang > > > > > -----Original Message----- > > > From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > Sent: March 13, 2003 9:55 AM > > > To: Gonzalo.Camarillo@lmf.ericsson.se > > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > > > mwatson@nortelnetworks.com; sipping@ietf.org; rohc@ietf.org > > > Subject: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP > > > messages > > > > > > > > > I agree. How to handling binary content is a generic issue for any > > > application messages. What I have in mind is to give generic > > > descriptions/requirements (mainly on the SigComp receiver > parsing part), > > > then touch on SIP (perhaps RTSP too) as a particular example. > > > > > > Unless someone objects, I'll submit it in ROHC. > > > > > > Zhigang > > > > > > > > > > -----Original Message----- > > > > From: ext Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: March 13, 2003 5:36 AM > > > > To: Liu Zhigang.C (NRC/Dallas) > > > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki); > > > > mwatson@nortelnetworks.com; sipping@ietf.org > > > > Subject: Re: [Sipping] SIGCOMP and large binary content > SIP messages > > > > > > > > > > > > Zhigang, > > > > > > > > you can submit that draft to ROHC. SIPPING can review > it afterwards. > > > > IMO, the competence needed to generate this draft can > be found more > > > > easily in ROHC than in SIPPING. > > > > > > > > Besides, you could use SigComp to compress RTSP > messages, for instance > > > > And RTSP is not handle by SIPPING either. > > > > > > > > Gonzalo > > > > > > > > zhigang.c.liu@nokia.com wrote: > > > > > > > > > > Yes, that is also what I had in mind for SIP. But my > point is that > > > > > a SigComp receiver now needs to have some knowledge > about application > > > > > message format and do parsing to determine the end of > an uncompressed > > > > > message. This is something new (or at least > unspecified) in RFC 3320 > > > > > and needs to be spelled out in a new (standard track) > RFC. The document > > > > > will be short, but I think it's needed for interoperability. > > > > > > > > > > I'll write up an I-D and submit it after IETF 56. But > I'd like to know > > > > > if folks in SIPPING think it should be done here or in ROHC. > > > > > > > > > > Zhigang > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > > > > > > Sent: March 11, 2003 9:03 PM > > > > > > To: Liu Zhigang.C (NRC/Dallas); Adam Roach; Isomaki Markus > > > > > > (NRC/Helsinki); mwatson@nortelnetworks.com; sipping@ietf.org > > > > > > Subject: RE: [Sipping] SIGCOMP and large binary > content SIP messages > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: zhigang.c.liu@nokia.com > [mailto:zhigang.c.liu@nokia.com] > > > > > > > > > > > > > > Having binary content in SIP messages may have > two impacts on > > > > > > > SigComp: > > > > > > > > > > > > > > a) multiplexing of uncompressed messages with > SigComp messages on the > > > > > > > same port. > > > > > > ... > > > > > > > For a), it is only an issue for SigComp/TCP, not > SigComp/UDP (where one > > > > > > > SigComp message maps to one UDP packet). Adam's > point 1 and 2 are related > > > > > > > to this. As to point 1, I think the SigComp > receiver still needs to know > > > > > > > (somehow) the end of an uncompressed message, or > at least the end of the > > > > > > > binary part of each SIP messages. Otherwise, a > bit pattern 11111 in > > > > > > > the binary part will be mistaken by SigComp as > the beginning of a SigComp > > > > > > > message. As to point 2, I would add that the > delimiter 0xFFFF can appear > > > > > > > at the both the beginning and the end of a > SigComp message. So, the > > > > > > > receiver needs to have the same parsing logic > just mentioned for bit pattern > > > > > > > 11111. > > > > > > > > > > > > This isn't any more of an issue than it is without > SigComp. SIP > > > > > > messages provide their own framing, and SigComp > messages do the > > > > > > same. They can be trivially mixed on the same stream: > > > > > > > > > > > > 1. Peek at the first byte waiting in the stream. > > > > > > > > > > > > 2. If it is 0xf8 or higher, the next message in the > stream is > > > > > > a SigComp message. The message continues until a > 0xFFFF is > > > > > > encountered in the stream. > > > > > > > > > > > > 3. Otherwise, the next message in the stream is a > SIP message. > > > > > > Read the stream until a CR/LF/CR/LF is encountered. Parse > > > > > > the headers, and then read the number of bytes specified > > > > > > in the "Content-Length" header. > > > > > > > > > > > > 4. Return to step 1. > > > > > > > > > > > > /a > > > > > > > > > > > _______________________________________________ > > > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > > This list is for NEW development of the application of SIP > > > > Use sip-implementors@cs.columbia.edu for questions on > current sip > > > > Use sip@ietf.org for new developments of core SIP > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > _______________________________________________ > > Rohc mailing list > > Rohc@ietf.org > > https://www1.ietf.org/mailman/listinfo/rohc > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > ------_=_NextPart_001_01C2F9EE.466598D2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = mes sages

Richard, all,

The issue I would like to see addressed is as = follows:

The text part of SIP/SDP is obviously highly = compressible using very simple algorithms which refer back to previous = parts of the message/earlier messages. In fact, subsequent messages in = a SIP dialog seem to consist almost entirely of repeated text from = previous messages.

So, it seems important to me that large binary = content in SIP messages does not destroy state that will be useful in = compressing subsequent messages.

In a wireless environment, the principle advantage of = compression is reduction in the time taken to actually send the message = over the wireless link (this may even be more important than the = overall reduction in signalling bandwidth).

Now if the message contains large binary content, = then of course we are 'out of luck' on the message transfer time = stakes, but this shouldn't affect subsequent messages.

I believe we should document recommendations to = SIGCOMP compressor designers to ensure this aspect is not overlooked = (although it is not immediately clear to me how the compressor (being = unaware of the SIP message structure) might achieve this.)

Is this something that would be appropriate to item 4 = below ?

Regards...Mark

> -----Original Message-----
> From: Price, Richard [mailto:richard.price@roke.co.uk= ]
> Sent: 26 March 2003 13:58
> To: 'zhigang.c.liu@nokia.com'; = cabo@tzi.org;
> Lars-Erik.Jonsson@epl.ericsson.se
> Cc: rohc@ietf.org; sipping@ietf.org
> Subject: RE: [rohc] RE: [Sipping] SIGCOMP and = large binary content SIP
> mes sages
>
>
> Hi,
>
> I think that the issue with SigComp and large = binary
> content SIP messages is part of a more general = issue -
> namely that before using SigComp to compress a = particular
> application we need to standardise the = following:
>
> 1. Mechanism for SigComp discovery
> 2. Resources offered by SigComp
> 3. How to delimit messages
> 4. When to save state
>
> Currently the SIPPING WG has provided RFCs for = 1 and 2,
> but not for 3 and 4. It would be useful to get = a draft
> out for these ASAP, as it would clarify several = issues on
> how to get SigComp working with SIP (including = the issue
> with large binary content SIP messages).
>
> > Unless someone objects, I'll submit it in = ROHC.
>
> I think that any WG draft should be a product = of the
> SIPPING WG, because the proposed solution for = delimiting
> SigComp messages will need to take into account = the
> behaviour of SIP itself (or we won't be able to = multiplex
> SigComp and SIP messages on the same port). = However, it
> would be good to get the ROHC WG involved in = generating
> the draft as well!
>
> Regards,
>
> Richard
>
> P.S. For anyone who's interested, the = mechanisms that
> particular applications need to provide before = they can
> use SigComp are as follows...
>
> = ------------------------------------------------------
>
> 1. Mechanism for SigComp discovery
>
>    - How does the application = know when to use SigComp?
>
> For SIP this issue is already sorted (RFC = 3486).
>
> = ------------------------------------------------------
>
> 2. Resources offered by SigComp
>
>    - Does the application need = to offer more than the
>      minimum amount of = resources?
>
>    - Does the application need = any extra state (e.g.
>      a static = dictionary)?
>
> For SIP we've already got a static dictionary = (RFC 3485).
> However, we haven't currently discussed how = much memory
> should be provided in a SigComp implementation = for SIP.
> If we don't specify a value then SigComp = defaults to the
> minimum possible (2K), which is rather tight = for some of
> the more generously sized SIP messages!
>
> = ------------------------------------------------------
>
> 3. How to delimit messages
>
>    - How does the application = distinguish between
>      SigComp messages = and uncompressed messages?
>
>    - Is the application allowed = to use "continuous mode"?
>
> This is the issue that's been raised for large = binary
> content SIP messages. If we want to send a mix = of
> uncompressed and SigComp messages within the = same TCP
> connection, how do we delimit the end of one = message and
> the start of another?
>
> A related issue is how to handle very large SIP = messages
> (> 64K). SigComp is able to compress large = SIP messages
> by using "continuous mode", where the = message boundaries
> are ignored completely and the application data = is just
> transmitted as a stream. However, this mode of = operation
> raises some additional security issues, so it's = up to the
> SIPPING WG to decide whether or not to use it = in SigComp
> for SIP.
>
> = ------------------------------------------------------
>
> 4. When to save state
>
>    - How much security is needed = in order to save state?
>
>    - Which messages belong to = each state "compartment"?
>
>    - How long should the = application keep state?
>
> This is quite an important issue that doesn't = seem to
> have been discussed in the SIPPING WG. It's up = to the
> application whether or not to let SigComp save = state,
> and for interoperability it's important to have = at
> least a general idea of how long to keep saved = state,
> when to reject state due to insufficient = security etc.
>
> = ------------------------------------------------------
>
> > -----Original Message-----
> > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> > Sent: Tuesday, March 25, 2003 6:00 = PM
> > To: cabo@tzi.org; = Lars-Erik.Jonsson@epl.ericsson.se
> > Cc: rohc@ietf.org; sipping@ietf.org
> > Subject: RE: [rohc] RE: [Sipping] SIGCOMP = and large binary
> content SIP
> > messages
> >
> >
> > Hi Carsten and Lars-Erik,
> >
> > I've volunteered to submit a personal = draft on this issue. From
> > ROHC WG chairs' point of view, do you = think this is the way
> > to proceed?
> >
> > Of course, I understood during the IETF56 = that Carsten had some
> > doubts on whether this is indeed an issue. = My email below explained
> > the issue a bit. I don't know if it's = clear. Either way, we
> > can continue discuss this in ROHC mailing = list
> >
> http://www1.ietf.org/mail-archive/working-groups/sippi= ng/curre
> nt/msg04115.html
> >
> > BR,
> > Zhigang
> >
> > > -----Original Message-----
> > > From: ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]
> > > Sent: March 13, 2003 9:55 AM
> > > To: = Gonzalo.Camarillo@lmf.ericsson.se
> > > Cc: adam@dynamicsoft.com; Isomaki = Markus (NRC/Helsinki);
> > > mwatson@nortelnetworks.com; = sipping@ietf.org; rohc@ietf.org
> > > Subject: [rohc] RE: [Sipping] SIGCOMP = and large binary content SIP
> > > messages
> > >
> > >
> > > I agree. How to handling binary = content is a generic issue for any
> > > application messages. What I have in = mind is to give generic
> > > descriptions/requirements (mainly on = the SigComp receiver
> parsing part),
> > > then touch on SIP (perhaps RTSP too) = as a particular example.
> > >
> > > Unless someone objects, I'll submit = it in ROHC.
> > >
> > > Zhigang
> > >
> > >
> > > > -----Original = Message-----
> > > > From: ext Gonzalo Camarillo =
> [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > > Sent: March 13, 2003 5:36 = AM
> > > > To: Liu Zhigang.C = (NRC/Dallas)
> > > > Cc: adam@dynamicsoft.com; = Isomaki Markus (NRC/Helsinki);
> > > > mwatson@nortelnetworks.com; = sipping@ietf.org
> > > > Subject: Re: [Sipping] SIGCOMP = and large binary content
> SIP messages
> > > >
> > > >
> > > > Zhigang,
> > > >
> > > > you can submit that draft to = ROHC. SIPPING can review
> it afterwards.
> > > > IMO, the competence needed to = generate this draft can
> be found more
> > > > easily in ROHC than in = SIPPING.
> > > >
> > > > Besides, you could use SigComp = to compress RTSP
> messages, for instance
> > > > And RTSP is not handle by = SIPPING either.
> > > >
> > > > Gonzalo
> > > >
> > > > zhigang.c.liu@nokia.com = wrote:
> > > > >
> > > > > Yes, that is also what I = had in mind for SIP. But my
> point is that
> > > > > a SigComp receiver now = needs to have some knowledge
> about application
> > > > > message format and do = parsing to determine the end of
> an uncompressed
> > > > > message. This is something = new (or at least
> unspecified) in RFC 3320
> > > > > and needs to be spelled out = in a new (standard track)
> RFC. The document
> > > > > will be short, but I think = it's needed for interoperability.
> > > > >
> > > > > I'll write up an I-D and = submit it after IETF 56. But
> I'd like to know
> > > > > if folks in SIPPING think = it should be done here or in ROHC.
> > > > >
> > > > > Zhigang
> > > > >
> > > > > > -----Original = Message-----
> > > > > > From: ext Adam Roach = [mailto:adam@dynamicsoft.com]
> > > > > > Sent: March 11, 2003 = 9:03 PM
> > > > > > To: Liu Zhigang.C = (NRC/Dallas); Adam Roach; Isomaki Markus
> > > > > > (NRC/Helsinki); = mwatson@nortelnetworks.com; sipping@ietf.org
> > > > > > Subject: RE: [Sipping] = SIGCOMP and large binary
> content SIP messages
> > > > > >
> > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: = zhigang.c.liu@nokia.com
> [mailto:zhigang.c.liu@nokia.com]
> > > > > > >
> > > > > > > Having binary = content in SIP messages may have
> two impacts on
> > > > > > > SigComp:
> > > > > > >
> > > > > > > a) multiplexing = of uncompressed messages with
> SigComp messages on the
> > > > > > > same port.
> > > > > > ...
> > > > > > > For a), it is = only an issue for SigComp/TCP, not
> SigComp/UDP (where one
> > > > > > > SigComp message = maps to one UDP packet). Adam's
> point 1 and 2 are related
> > > > > > > to this. As to = point 1, I think the SigComp
> receiver still needs to know
> > > > > > > (somehow) the end = of an uncompressed message, or
> at least the end of the
> > > > > > > binary part of = each SIP messages. Otherwise, a
> bit pattern 11111 in
> > > > > > > the binary part = will be mistaken by SigComp as
> the beginning of a SigComp
> > > > > > > message. As to = point 2, I would add that the
> delimiter 0xFFFF can appear
> > > > > > > at the both the = beginning and the end of a
> SigComp message. So, the
> > > > > > > receiver needs to = have the same parsing logic
> just mentioned for bit pattern
> > > > > > > 11111.
> > > > > >
> > > > > > This isn't any more of = an issue than it is without
> SigComp. SIP
> > > > > > messages provide their = own framing, and SigComp
> messages do the
> > > > > > same. They can be = trivially mixed on the same stream:
> > > > > >
> > > > > > 1. Peek at the first = byte waiting in the stream.
> > > > > >
> > > > > > 2. If it is 0xf8 or = higher, the next message in the
> stream is
> > > > > >    a = SigComp message. The message continues until a
> 0xFFFF is
> > > > > >    = encountered in the stream.
> > > > > >
> > > > > > 3. Otherwise, the next = message in the stream is a
> SIP message.
> > > > > >    Read = the stream until a CR/LF/CR/LF is encountered. Parse
> > > > > >    the = headers, and then read the number of bytes specified
> > > > > >    in = the "Content-Length" header.
> > > > > >
> > > > > > 4. Return to step = 1.
> > > > > >
> > > > > > /a
> > > > > >
> > > > > = _______________________________________________
> > > > > Sipping mailing list =
> https://www1.ietf.org/mailman/listinfo/sipping
> > > > This list is for NEW development = of the application of SIP
> > > > Use = sip-implementors@cs.columbia.edu for questions on
> current sip
> > > > Use sip@ietf.org for new = developments of core SIP
> > >
> > > --
> > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > >
> > = _______________________________________________
> > Rohc mailing list
> > Rohc@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rohc=
> > = _______________________________________________
> > Rohc mailing list
> > Rohc@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rohc=
> >
> = _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the = application of SIP
> Use sip-implementors@cs.columbia.edu for = questions on current sip
> Use sip@ietf.org for new developments of core = SIP
>

------_=_NextPart_001_01C2F9EE.466598D2-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 11:34:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28594 for ; Thu, 3 Apr 2003 11:34:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33Gauu31510 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 11:36:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33GauK31507 for ; Thu, 3 Apr 2003 11:36:56 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28585 for ; Thu, 3 Apr 2003 11:34:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33GWUK31190; Thu, 3 Apr 2003 11:32:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33GVPK31131 for ; Thu, 3 Apr 2003 11:31:25 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28297 for ; Thu, 3 Apr 2003 11:28:33 -0500 (EST) Received: from cia.cisco.com (IDENT:mirapoint@cia.cisco.com [161.44.85.200]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h33GV0do023457; Thu, 3 Apr 2003 11:31:00 -0500 (EST) Received: from mhammer-w2k02.cisco.com (dhcp-64-100-224-237.cisco.com [64.100.224.237]) by cia.cisco.com (Mirapoint) with ESMTP id ABT57469; Thu, 3 Apr 2003 11:21:05 -0500 (EST) Message-Id: <4.3.2.7.2.20030403102839.00b44170@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Apr 2003 11:30:56 -0500 To: Gonzalo Camarillo From: Michael Hammer Subject: Re: [Sipping] New version of the early media draft Cc: Francois Audet , Tom-PT Taylor , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" , Mark Watson In-Reply-To: <3E8C0A73.7000906@lmf.ericsson.se> References: <2F1FC1DEA077D5119FAD00508BCFD6D20794E863@zsc3c030.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Gonzalo, Would it be possible to have an early media convention that contains the following elements: 1) the receiving end indicates in signaling that it intends to send early media 2) the receiving end includes SDP in hold state and does not send media at first 3) the caller responds to one receiver's inband indicator (or not) with an UPDATE putting that receiver in send state 4) the receiving end responds to UPDATE and begins sending of RTP with media. This resolves the forking case, tells the caller which device intends inband media, and allows the caller with possibly user in the loop to decide which to listen to. See the following: A Forking Proxy User User User B1 B2 B3 | | | | | | INVITE F1 | | | | |--------------->| | | | | 100 Trying F2 | | | | |<---------------| INVITE F3 | | | | |------------->| | | | | INVITE F4 | | | |-------------------->| | | | INVITE F5 | | | |--------------------------->| | | 183 inband F6| | | | 183 inband F7 |<-------------| | | |<---------------| | | | | | 183 inband F8| | | | 183 inband F9 |<--------------------| | |<---------------| | | | | UPDATE send F10| | | | |--------------->| UPDATE send F11 | | | |-------------------->| | | | ACK send F12 | | | | ACK send F13 |<--------------------| | |<---------------| | | | Play<=====|<======Early media====================| | | | 180 inband F14 | | | 180 inband F15 |<---------------------------| |<---------------| CANCEL F16 | | | | |------------->|media | | | | 200 OK F17 |stops | | | |<-------------| | | | | 487 F18 | | | | |<-------------| | | | | ACK F19 | | | | |------------->| | | | UPDATE send F20| | | | |--------------->| UPDATE send F21 | | | |--------------------------->| | | ACK send F22 | | | | ACK send F23 |<---------------------------| |<---------------| | | | Play<=====|<==============="Hello"======================| | | 200 OK F24 | | 200 OK F25 |<---------------------------| |<---------------| | | | | ACK send F26 | | | | |--------------->| ACK send F27 | | | | |--------------------------->| | | | | | Am I missing anything here? The key is to stop guessing and make it more deterministic. If you don't like this, don't use the inband indicator, and fall back to the current state of problems. Mike At 01:18 PM 4/3/2003 +0300, Gonzalo Camarillo wrote: >Francois, > >you are missing the point of the draft. The draft explains what happens >when you use early media within the dialog are forking occurs. That is, >you have a lot of problems. > >The aim of the draft is to describe these problems and to describe things >that a UAC may do without extending the protocol. We do that because you >have to interact with existing UASs that will send you media this way. You >cannot upgrade the already installed base. > >But we do not want to extend the protocol to provide a solution for this >gateway model. We recommend that new systems use the application server >model. In this model, we will provide solutions and extend the protocol >should that be needed. > >Gonzalo > >Francois Audet wrote: >> > First of all, I do not understand why people continue >> > discussing things >> > like early media with forking whose problems are already well >> > discussed >> > and documented in the draft and nobody so far has been able >> > to come up >> > with a single use case where the proposed flag would be useful... I >> > would ask people to focus on the problem in hand (i.e., the >> > flag), and >> > stop discussing about already resolved issues. >>The problem is that the multiple dialog problem and early media problem >>(as in forking >>for example) has NOT been solved. Worst, using the current unworkable >>solution as a basis >>to make our decisions on the flag issue will not result in a good solution. >>The current solution for forking in the draft is for the UAC to pick a >>random media >>stream (based on signaling, thus the dialog, not media, because there is >>no means to correlate >>dialog and media stream) and mute the others by sending UPDATEs to the >>far end. This is >>not an acceptable solution. Random non-redictable behavior is not >>acceptable to end-users. >>Furthemore, this is not robust at all because if the called UA does not >>support UPDATE, >>multiple streams will be received and there will be no way for the UAC >>receiving it >>to pick the proper one. (If there was a way to correlate an RTP stream to >>the dialog that >>generate it, it would be easier) >>This leaves the client with 3 choices: >>1) Pick a random media stream (which it will not be able to correlate >>with a specific dialog >> unless it is lucky with educated guesses). >>2) Mix media streams together. >>3) Provide alternative local treatment based on the provisional responses >>received. This >> could be >> >>You are right that the flag probably doesn't help with this problem. I'll >>leave it >>to others to defend the flag idea. >>I'm OK with current draft, as long as we do not ADD any more dependency >>on the "play >>media when you receive it" principle to address the flag prolem, and as >>long as we improve >>the section on forking. It seems to me that if forking is used we CAN NOT >>use early media for >>in-band ringing (we could do early media for clipping avoidance). Perhaps >>we need a >>"forked" indication in INVITE telling the far-end not to send early >>media... And to make >>it bullet proof a forked indication in the 100 Trying (when forking) to >>tell the UAC making the >>call that "weird stuff" is going to happen and that proper treatment >>should be used not >>to confused the user. > > >-- >Gonzalo Camarillo Phone : +358 9 299 33 71 >Oy L M Ericsson Ab Mobile: +358 40 702 35 35 >Telecom R&D Fax : +358 9 299 30 52 >FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com >Finland http://www.hut.fi/~gonzalo > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 12:32:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02479 for ; Thu, 3 Apr 2003 12:32:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33HYlU05500 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 12:34:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33HYlK05497 for ; Thu, 3 Apr 2003 12:34:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02392 for ; Thu, 3 Apr 2003 12:31:54 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33HUlK05196; Thu, 3 Apr 2003 12:30:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33HTvK05090 for ; Thu, 3 Apr 2003 12:29:57 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01618; Thu, 3 Apr 2003 12:27:02 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33HTWH26358; Thu, 3 Apr 2003 11:29:32 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Apr 2003 11:29:27 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 11:29:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FA06.9112EBC2" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Thu, 3 Apr 2003 11:29:23 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcL57NkjhdknIYmwRTKBF5JK5rjYiQADhltA To: , Cc: , X-OriginalArrivalTime: 03 Apr 2003 17:29:24.0404 (UTC) FILETIME=[91E1D740:01C2FA06] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2FA06.9112EBC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mark, =20 The problem I raised is how "to multiplex uncompressed application = messages and SigComp messages on the same port" when application = messages start with UTF-8 encoded text but contain binary data. For the = problem itself, I don't assume where the demultiplexing is done (that = goes to the solution space, see below). My point is that it needs to be = done somewhere at the receiving endpoint (which by definition, is "one = instance of an application, a SigComp layer, and a transport layer"). =20 Now, the solutions: =20 - One is to let decompressor dispatcher do the demultiplexing (I won't = repeat how it can be done), which means all bytes received on a port = must go through SigComp layer first. This follows the SigComp = architecture in RFC 3320. It makes the layering more clean, i.e., = (de)compression and (de)multiplexing is handled completely by SigComp = layer. The drawback is a bit redundancy in the sense that the = decompressor dispatcher performs some parsing that the application layer = will later do again.=20 =20 - The other one is to let the application do the demultiplexing as you = described below. That means all received data must go through = application first. =20 In my view, either one will work and the choice is a local = implementation issue (although the latter is not described in RFC 3320). = The difference boils down to where do put the demultiplexing function. = It's a matter of preference of SW coding. However, what is NOT an = implementation issue is that - looking at transport layer - a receiving = endpoint must expect it may receive uncompressed messages interspersed = with SigComp messages on the same port and demultiplex them using either = of the above approaches (or any other working solutions). This needs to = be spelled out in a document. =20 BR, Zhigang =20 -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: April 03, 2003 8:24 AM To: Liu Zhigang.C (NRC/Dallas); Sugar Robert (NET/Budapest) Cc: rohc@ietf.org; sipping@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = messages Zhigang,=20 If I understand the solution described by Robert correctly, then the = problem you describe below does not arise. Your problem seems to assume = that demultiplexing of compressed and uncompressed messages will be done = before the SIP parser is invoked, based on the 11111xxx delimiter. My understanding is that messages are passed directly to the SIP parser. = This software must be aware that SIGCOMP may be used, and checks the = first octet of the input stream. If this is 11111xxx then it uses the = sigcomp delimeter OxFFFF to find the end of the compressed message, and = then sends it to the decompressor. If the first octets is not 11111xxx = then it just starts parsing as normal. The only assumption is that the SIP parser has its own way of = recognising the end of an uncompressed message.=20 Regards...Mark=20 > -----Original Message-----=20 > From: zhigang.c.liu@nokia.com [ mailto:zhigang.c.liu@nokia.com]=20 > Sent: 01 April 2003 14:44=20 > To: Robert.Sugar@nokia.com=20 > Cc: rohc@ietf.org; sipping@ietf.org=20 > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = > messages=20 >=20 >=20 > Robert,=20 >=20 > > I don't think it is a problem with SigComp multiplexing, but=20 > > more like a SIP internal issue. What if there is a TCP stream=20 > > of SIP messages and the Content-Length header is missing or=20 > > false? They will screw up the same way with or without=20 > > SigComp.=20 >=20 > Since TCP is a reliable transport, this only happens for a=20 > mis-behaved SIP sender. But that is not the "multiplexing" problem=20 > I mentioned below, which happens even "during normal functioning"=20 > (see below).=20 >=20 > > During normal functioning both SIP and SigComp=20 > > provide their own flow separation mechanism and they work just fine. = >=20 > I don't think so. That is what I intended to show by the example,=20 > i.e. the issue to "multiplex uncompressed application messages and=20 > SigComp messages on the same port". One solution, as I mentioned=20 > before, is to require sigcomp receiver has the ability to parse=20 > uncompressed application messages and detect the end.=20 >=20 > (Of course, I saw Carsten's email and I need understand his=20 > point of view, which says there is no such "multiplexing" and=20 > it is not possible and necessary.)=20 >=20 > BR,=20 > Zhigang=20 > _______________________________________________=20 > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping=20 > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sip@ietf.org for new developments of core SIP=20 >=20 ------_=_NextPart_001_01C2FA06.9112EBC2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = messages
Mark,
 
The=20 problem I raised is how "to multiplex uncompressed application messages = and=20 SigComp messages on the same port" when application messages start with=20 UTF-8 encoded text but contain binary data. For the problem = itself, I=20 don't assume where the demultiplexing is done (that goes to the solution = space,=20 see below). My point is that it needs to be done somewhere at the = receiving=20 endpoint (which by definition, is "one instance of an application, a = SigComp=20 layer, and a transport layer").
 
Now, the = solutions:
 
-=20 One is to let decompressor dispatcher do the=20 demultiplexing (I won't repeat how it can be done), which means all = bytes=20 received on a port must go through SigComp layer first. This follows the = SigComp=20 architecture in RFC 3320. It makes the layering more clean, = i.e.,=20 (de)compression and (de)multiplexing is handled completely by SigComp = layer. The=20 drawback is a bit redundancy in the sense that the decompressor = dispatcher=20 performs some parsing that the application layer will later do again.=20
 
- The=20 other one is to let the application do the demultiplexing as you = described=20 below. That means all received data must go through = application=20 first.
 
In my=20 view, either one will work and the choice is a=20 local implementation issue (although the latter is not described in = RFC=20 3320). The difference boils down to where do put the demultiplexing = function. It's a matter of preference of SW coding.=20 However, what is NOT an = implementation issue is=20 that - looking at transport layer - a receiving endpoint = must=20 expect it may receive uncompressed messages interspersed with SigComp = messages=20 on the same port and demultiplex them using either of the above = approaches (or=20 any other working solutions). This needs to be spelled out in a=20 document.
 
BR,
Zhigang
 
-----Original Message-----
From: ext Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: April 03, 2003 = 8:24=20 AM
To: Liu Zhigang.C (NRC/Dallas); Sugar Robert=20 (NET/Budapest)
Cc: rohc@ietf.org;=20 sipping@ietf.org
Subject: RE: [rohc] RE: [Sipping] SIGCOMP = and large=20 binary content SIP messages

Zhigang,

If I understand the solution described by Robert = correctly,=20 then the problem you describe below does not arise. Your problem seems = to=20 assume that demultiplexing of compressed and uncompressed messages = will be=20 done before the SIP parser is invoked, based on the 11111xxx=20 delimiter.

My understanding is that messages are passed = directly to the=20 SIP parser. This software must be aware that SIGCOMP may be used, and = checks=20 the first octet of the input stream. If this is 11111xxx then it uses = the=20 sigcomp delimeter OxFFFF to find the end of the compressed message, = and then=20 sends it to the decompressor. If the first octets is not 11111xxx then = it just=20 starts parsing as normal.

The only assumption is that the SIP parser has its = own way of=20 recognising the end of an uncompressed message.

Regards...Mark

> -----Original Message-----
>=20 From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]=20
> Sent: 01 April 2003 14:44
>=20 To: Robert.Sugar@nokia.com
> Cc: = rohc@ietf.org;=20 sipping@ietf.org
> Subject: RE: [rohc] = RE:=20 [Sipping] SIGCOMP and large binary content SIP
>=20 messages
>
> =
> Robert,
>=20
> >  I don't think it is a = problem with=20 SigComp multiplexing, but
> > more = like a SIP=20 internal issue. What if there is a TCP stream
>=20 > of SIP messages and the Content-Length header is missing or=20
> > false? They will screw up the same = way with=20 or without
> > SigComp. =
>
> Since TCP is a reliable = transport,=20 this only happens for a
> mis-behaved SIP = sender.=20 But that is not the "multiplexing" problem
> I=20 mentioned below, which happens even "during normal functioning"=20
> (see below).
>=20
> > During normal functioning both SIP = and=20 SigComp
> > provide their own flow = separation=20 mechanism and they work just fine.
>=20
> I don't think so. That is what I = intended to show=20 by the example,
> i.e. the issue to = "multiplex=20 uncompressed application messages and
> = SigComp=20 messages on the same port". One solution, as I mentioned =
> before, is to require sigcomp receiver has the ability = to=20 parse
> uncompressed application messages = and=20 detect the end.
>
> (Of=20 course, I saw Carsten's email and I need understand his =
> point of view, which says there is no such = "multiplexing"=20 and
> it is not possible and = necessary.)=20
>
> BR, =
> Zhigang
>=20 _______________________________________________
>=20 Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping= =20
> This list is for NEW development of the = application of=20 SIP
> Use = sip-implementors@cs.columbia.edu for=20 questions on current sip
> Use = sip@ietf.org for new=20 developments of core SIP
>=20

------_=_NextPart_001_01C2FA06.9112EBC2-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 13:39:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06167 for ; Thu, 3 Apr 2003 13:39:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33Ifhk14263 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 13:41:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33IfhK14260 for ; Thu, 3 Apr 2003 13:41:43 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06132 for ; Thu, 3 Apr 2003 13:38:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33IeRK14181; Thu, 3 Apr 2003 13:40:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33IdJK14018 for ; Thu, 3 Apr 2003 13:39:19 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06027 for ; Thu, 3 Apr 2003 13:36:25 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33Icls04633; Thu, 3 Apr 2003 10:38:48 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2FGB4YWB>; Thu, 3 Apr 2003 10:38:32 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2079A73EC@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Christer Holmberg'" , "Tom-PT Taylor" Cc: "'Gonzalo Camarillo'" , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" Subject: RE: [Sipping] New version of the early media draft Date: Thu, 3 Apr 2003 10:38:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FA10.39823310" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FA10.39823310 Content-Type: text/plain I am in 100% agreement with your email. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, April 02, 2003 21:56 > To: Taylor, Tom-PT [CAR:5N00:EXCH] > Cc: Gonzalo Camarillo; Audet, Francois [SC100:4K02:EXCH]; > 'Bob Penfield'; 'sipping@ietf.org'; 'Jon PETERSON > (Jon.Peterson@neustar.com)' > Subject: Re: [Sipping] New version of the early media draft > > > > Hi, > > Some small notes... > > First, please remember that in split architectures we talk > about the time it takes for the 200 OK to reach the MGC, PLUS > the time it takes for the possible MODIFY/MDCX to reach the MG. > > Now, I don't know if that makes any real difference to the > issue. There may still be enough time before the "Hello" > actually reaches the MG, but just to let you know... > > Second, with mobile phone kind of devices, and/or hands-free > kind of devices, the time between the off-hook and the > "Hello" is probably shorter than with "normal" phones, where > you actually have to lift the hook, and place it towards your > ear before you start to speak. Again, don't know if it makes > any difference to the issue, but still... > > Third, the 200 race condition does not always mean we will > have clipping. I am still against the "play everything you > receive" stuff, but if we have established an early dialog > with the same device which will send the 200, there probably > will be no clipping (it of course depends on if there is > local ringback etc). In forking scenarios, however, there may > be clipping, since we may have established the early dialog > with another device, and do not play media received from the > device which finally sends 200 first (again, I may NOT be > mixing everything I recieve from every leg, even if the spec > says I should play everything...). > > Fourth, the note about the difference in receiving, and > actually playing, media was "interesting". But, I still think > there should be no requirements on media handling before the > early dialog is actually established. Of course, one MAY > still play and handle whatever media he receives, without > knowing if it actually comes from some of the SIP devices > he's trying to call, but everybody may not want to do that - > due to a number of reasons. > > Regards, > > Christer Holmberg > Ericsson Finland > > > ------_=_NextPart_001_01C2FA10.39823310 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] New version of the early media draft

I am in 100% agreement with your email.

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: Wednesday, April 02, 2003 21:56
> To: Taylor, Tom-PT [CAR:5N00:EXCH]
> Cc: Gonzalo Camarillo; Audet, Francois = [SC100:4K02:EXCH];
> 'Bob Penfield'; 'sipping@ietf.org'; 'Jon = PETERSON
> (Jon.Peterson@neustar.com)'
> Subject: Re: [Sipping] New version of the early = media draft
>
>
>
> Hi,
>
> Some small notes...
>
> First, please remember that in split = architectures we talk
> about the time it takes for the 200 OK to reach = the MGC, PLUS
> the time it takes for the possible MODIFY/MDCX = to reach the MG.
>
> Now, I don't know if that makes any real = difference to the
> issue. There may still be enough time before = the "Hello"
> actually reaches the MG, but just to let you = know...
>
> Second, with mobile phone kind of devices, = and/or hands-free
> kind of devices, the time between the off-hook = and the
> "Hello" is probably shorter than with = "normal" phones, where
> you actually have to lift the hook, and place = it towards your
> ear before you start to speak. Again, don't = know if it makes
> any difference to the issue,  but = still...
>
> Third, the 200 race condition does not always = mean we will
> have clipping. I am still against the = "play everything you
> receive" stuff, but if we have established = an early dialog
> with the same device which will send the 200, = there probably
> will be no clipping (it of course depends on if = there is
> local ringback etc). In forking scenarios, = however, there may
> be clipping, since we may have established the = early dialog
> with another device, and do not play media = received from the
> device which finally sends 200 first (again, I = may NOT be
> mixing everything I recieve from every leg, = even if the spec
> says I should play everything...).
>
> Fourth, the note about the difference in = receiving, and
> actually playing, media was = "interesting". But, I still think
> there should be no requirements on media = handling before the
> early dialog is actually established. Of = course, one MAY
> still play and handle whatever media he = receives, without
> knowing if it actually comes from some of the = SIP devices
> he's trying to call, but everybody may not want = to do that -
> due to a number of reasons.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
>

------_=_NextPart_001_01C2FA10.39823310-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 15:20:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11596 for ; Thu, 3 Apr 2003 15:20:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33KMrm25344 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 15:22:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KMrK25341 for ; Thu, 3 Apr 2003 15:22:53 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11585 for ; Thu, 3 Apr 2003 15:19:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KLuK25270; Thu, 3 Apr 2003 15:21:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KKFK25104 for ; Thu, 3 Apr 2003 15:20:15 -0500 Received: from mgw-dax2.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11353; Thu, 3 Apr 2003 15:17:19 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33KJlH28176; Thu, 3 Apr 2003 14:19:47 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Apr 2003 14:19:47 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 12:19:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Thu, 3 Apr 2003 14:19:31 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcL6DB4VislM+eMARAWuaGikcQTswwAC3c+g To: , Cc: X-OriginalArrivalTime: 03 Apr 2003 20:19:33.0719 (UTC) FILETIME=[571BAE70:01C2FA1E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33KKFK25106 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > The mechanism in > SigComp is not there to allow multiplexing of SigComp > messages and raw messages within the same connection, > but only to identify whether the connection uses > SigComp or not. If by "multiplex uncompressed application messages and SigComp messages on the same port" RFC 3320 does not mean what I thought it meant, I'd propose to add mutltiplexing (in the true meaning) capability as an extension to RFC 3320. For details and arguments, please see my previous email: http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01423.html BR, Zhigang _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 16:17:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14499 for ; Thu, 3 Apr 2003 16:17:45 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33LKB731185 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 16:20:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LKBK31182 for ; Thu, 3 Apr 2003 16:20:11 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14470 for ; Thu, 3 Apr 2003 16:17:14 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LJVK31091; Thu, 3 Apr 2003 16:19:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LIaK31003 for ; Thu, 3 Apr 2003 16:18:36 -0500 Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14307 for ; Thu, 3 Apr 2003 16:15:38 -0500 (EST) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HCS00201DTGEM@siemenscomms.co.uk> for sipping@ietf.org; Thu, 03 Apr 2003 22:17:40 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HCS001H3DTFYQ@siemenscomms.co.uk> for sipping@ietf.org; Thu, 03 Apr 2003 22:17:39 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 03 Apr 2003 22:18:07 +0100 Content-return: allowed Date: Thu, 03 Apr 2003 22:18:25 +0100 From: "Elwell, John" To: sipping@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="Boundary_(ID_KdGDBBkos1OxyhwrlkpDpg)" Subject: [Sipping] Impact on SIP of transfer in QSIG network Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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. --Boundary_(ID_KdGDBBkos1OxyhwrlkpDpg) Content-type: text/plain Content-Transfer-Encoding: 7BIT There has been some discussion in the past on this list concerning the situation where call transfer takes place in a QSIG network and the impact of this on a party in a SIP network. The outcome was inconclusive, and talking to a couple of you at IETF56 I found that the original problem had not been explained too well. I attempt below to set out the problem and potential solutions. The problem: A transferor in a QSIG network transfers a call and EITHER the transferee OR the transfer target is a SIP UA. Prior to transfer there is a call linking the SIP UA via a gateway with the QSIG transferor. After transfer there is a call linking the SIP UA via the same gateway with the third party. If no SIP action is taken, the original dialog will remain in place between the SIP UA and the gateway. Note that SIP REFER is not involved - the equivalent takes place within the QSIG network. The problem with this is that the SIP UA receives no information about the change of partner in the conversation. In particular, if the SIP UA originally received the identity of the original partner by means of asserted or authenticated identity from the gateway, that information will no longer be valid and needs to be updated. Potential solutions: 1. Do nothing. This has a significant disadvantage that information sent to the SIP UA at dialog establishment time is not updated. 2. Change the From or To header (depending on direction of dialog) leaving the tag unchanged. This has all the disadvantages of relying on From/To for identity at dialog establishment time. It is unsatisfactory if the SIP UA had previously obtained its identify from another source (e.g., P-Asserted-Identity) rather than From/To. 3. Send Re-INVITE with new asserted or authenticated ID to SIP UA, but no change of session parameters. I believe this may be a misuse of Re-INVITE and it is unclear how UAs would react. 4. Send UPDATE with new asserted ID. Same remarks as above. 5. Send INVITE (new dialog) with Replaces header and Required header (Replaces required). This would be rejected by a UA that does not support the Replaces header. 6. Send INFO with new identity information (e.g, P-Asserted-Identity). I don't need to mention the concerns about INFO that have been expressed in the past. I would welcome comments on the above and any new proposals. John Elwell (john.elwell@siemens.com) --Boundary_(ID_KdGDBBkos1OxyhwrlkpDpg) Content-type: text/html Content-Transfer-Encoding: 7BIT Impact on SIP of transfer in QSIG network

There has been some discussion in the past on this list concerning the situation where call transfer takes place in a QSIG network and the impact of this on a party in a SIP network. The outcome was inconclusive, and talking to a couple of you at IETF56 I found that the original problem had not been explained too well. I attempt below to set out the problem and potential solutions.

The problem:

A transferor in a QSIG network transfers a call and EITHER the transferee OR the transfer target is a SIP UA. Prior to transfer there is a call linking the SIP UA via a gateway with the QSIG transferor. After transfer there is a call linking the SIP UA via the same gateway with the third party. If no SIP action is taken, the original dialog will remain in place between the SIP UA and the gateway. Note that SIP REFER is not involved - the equivalent takes place within the QSIG network.

The problem with this is that the SIP UA receives no information about the change of partner in the conversation. In particular, if the SIP UA originally received the identity of the original partner by means of asserted or authenticated identity from the gateway, that information will no longer be valid and needs to be updated.

Potential solutions:

1. Do nothing. This has a significant disadvantage that information sent to the SIP UA at dialog establishment time is not updated.

2. Change the From or To header (depending on direction of dialog) leaving the tag unchanged. This has all the disadvantages of relying on From/To for identity at dialog establishment time. It is unsatisfactory if the SIP UA had previously obtained its identify from another source (e.g., P-Asserted-Identity) rather than From/To.

3. Send Re-INVITE with new asserted or authenticated ID to SIP UA, but no change of session parameters. I believe this may be a misuse of Re-INVITE and it is unclear how UAs would react.

4. Send UPDATE with new asserted ID. Same remarks as above.

5. Send INVITE (new dialog) with Replaces header and Required header (Replaces required). This would be rejected by a UA that does not support the Replaces header.

6. Send INFO with new identity information (e.g, P-Asserted-Identity). I don't need to mention the concerns about INFO that have been expressed in the past.

I would welcome comments on the above and any new proposals.

John Elwell (john.elwell@siemens.com)

--Boundary_(ID_KdGDBBkos1OxyhwrlkpDpg)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 16:57:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16308 for ; Thu, 3 Apr 2003 16:57:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33Lxq702541 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 16:59:52 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LxpK02538 for ; Thu, 3 Apr 2003 16:59:51 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16158 for ; Thu, 3 Apr 2003 16:56:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LwlK02409; Thu, 3 Apr 2003 16:58:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33LvQK02249 for ; Thu, 3 Apr 2003 16:57:26 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16043; Thu, 3 Apr 2003 16:54:27 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33Lv3Z28728; Thu, 3 Apr 2003 15:57:03 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Apr 2003 15:56:56 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 15:56:56 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Date: Thu, 3 Apr 2003 15:56:54 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP messages Thread-Index: AcL1fk3vswgjGlylR6KGvyjVp1H/TwEn+5mQ To: , , Cc: , X-OriginalArrivalTime: 03 Apr 2003 21:56:56.0416 (UTC) FILETIME=[F1A07E00:01C2FA2B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h33LvQK02251 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Richard, > Regarding point a), I don't see how this can be done without > talking about specific protocols. I agree if you mean the exact logic (see below). But what I had in mind for a) is a generic or abstract logic as follows: 0. Endpoint B informs endpoint A that it supports SigComp AND multiplexing of uncompressed message and SigComp message on a TCP connection. This should be part of the SigComp discovery. 1. Endpoint B reads in one byte. 2. If the first 5 MSB of the byte is 11111. this is the beginning of a SigComp message or a SigComp message delimiter (0xFFFF). Endpoint B enters "SigComp parsing mode" and processes byte stream according to SigComp until it encounters END-MESSAGE instruction or Sigcomp delimiter. When that happens, go to 1. 3. Else, this is the beginning of an uncompressed message. Endpoint B enters "uncompressed parsing mode" and parses the byte stream according to the delimiting scheme of the application messages. When reaching the end of application message, go to 1. Note: it is assumed that uncompressed application messages start with UTF-8 encoded character. Otherwise, the logic does not work. Note: the sigcomp can deliver the bytes to application layer either as they are arriving or at the end of the application message. Note: this abstract demultiplexing logic can be either done at SigComp layer (decompressor dispatcher) or at application layer. That is a choice of local implementation. Now, back to your comment. I certainly agree with you that detecting end of application message in Step 3 depends on a particular application protocol. But other than that, the rest is pretty generic. We can consider the above as the abstract logic that will be "instantiated" when binding SigComp to a particular application. > Regarding point b), it might be good to have some recommendations > on how to implement an efficient compressor for messages with > binary content. Yes. > A suitable home for these would be the SigComp > User Guide, which already talks about the various different > compressors that can be used in conjunction with SigComp. OK. I don't mind where it ends up as long as the issue finds a home. I can provide some text. BR, Zhigang _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 17:49:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17900 for ; Thu, 3 Apr 2003 17:49:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33Mpje07570 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 17:51:45 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33MpjK07567 for ; Thu, 3 Apr 2003 17:51:45 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17888 for ; Thu, 3 Apr 2003 17:48:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33MocK07529; Thu, 3 Apr 2003 17:50:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33MnRK07434 for ; Thu, 3 Apr 2003 17:49:27 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17848 for ; Thu, 3 Apr 2003 17:46:26 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33Mmim22110; Thu, 3 Apr 2003 14:48:44 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2FGBVN5H>; Thu, 3 Apr 2003 14:48:45 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2079A7B13@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Michael Hammer'" , "'Gonzalo Camarillo'" Cc: "Tom-PT Taylor" , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" , "Mark Watson" Subject: RE: [Sipping] New version of the early media draft Date: Thu, 3 Apr 2003 14:48:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FA33.2A6C53F6" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FA33.2A6C53F6 Content-Type: text/plain > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Thursday, April 03, 2003 08:31 > To: Gonzalo Camarillo > Cc: Audet, Francois [SC100:4K02:EXCH]; Taylor, Tom-PT > [CAR:5N00:EXCH]; 'Bob Penfield'; 'sipping@ietf.org'; 'Jon > PETERSON (Jon.Peterson@neustar.com)'; 'Christer Holmberg'; > Watson, Mark [MOP:EP10:EXCH] > Subject: Re: [Sipping] New version of the early media draft > > > Gonzalo, > > Would it be possible to have an early media convention that > contains the > following elements: > > 1) the receiving end indicates in signaling that it intends > to send early media > 2) the receiving end includes SDP in hold state and does not > send media at > first > 3) the caller responds to one receiver's inband indicator (or > not) with an > UPDATE putting that receiver in send state > 4) the receiving end responds to UPDATE and begins sending of > RTP with media. You are right: we need to get rid of the randomness. How do the terminating end know that they should answer in the hold state? Would it apply all the time (which seems to me to be a drastic change from current implemenations), or only when there is forking? If it is only when there is forking, it could either work as one of the following: (1) somehow the called party would have to know that the call is forked (which would be my prefered solution). I guess there would need to be some forking indication added to the INVITE by the forking proxy. This is similar to what I was hinting at, but you're proposal is cleaner because it relies on signaling for muting the media. (2) the forking proxy would have to modify the SDP in the INVITE to put the media on hold (i.e., sendonly or inactive). Of course, this means it wouldn't be a proxy anymore but a B2BUA, which is not very desireable.... If we don't do anything about this problem, the only alternative for implementors of forking proxies will be to make them B2BUAs. Now we don't want this, do we? Gonzallo, in response to your email: yes I totally get the point that forking introduces some difficulties. But what we currently have in the draft for forking makes it a lot worst. It needs to be fixed. If we can't do it all in this document (because it requires some additions to SIP), then it may be that we need some other internet draft specifically on forking. That's finewith me. I just don't think we should encourage anybody to "pick a random stream" as per the current draft. ------_=_NextPart_001_01C2FA33.2A6C53F6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] New version of the early media draft

> -----Original Message-----
> From: Michael Hammer [mailto:mhammer@cisco.com]
> Sent: Thursday, April 03, 2003 08:31
> To: Gonzalo Camarillo
> Cc: Audet, Francois [SC100:4K02:EXCH]; Taylor, = Tom-PT
> [CAR:5N00:EXCH]; 'Bob Penfield'; = 'sipping@ietf.org'; 'Jon
> PETERSON (Jon.Peterson@neustar.com)'; 'Christer = Holmberg';
> Watson, Mark [MOP:EP10:EXCH]
> Subject: Re: [Sipping] New version of the early = media draft
>
>
> Gonzalo,
>
> Would it be possible to have an early media = convention that
> contains the
> following elements:
>
> 1) the receiving end indicates in signaling = that it intends
> to send early media
> 2) the receiving end includes SDP in hold state = and does not
> send media at
> first
> 3) the caller responds to one receiver's inband = indicator (or
> not) with an
> UPDATE putting that receiver in send = state
> 4) the receiving end responds to UPDATE and = begins sending of
> RTP with media.

You are right: we need to get rid of the randomness. =

How do the terminating end know that they should = answer in the hold state? Would it apply all the time (which seems to = me to be a drastic change from current implemenations), or only when = there is forking?

If it is only when there is forking, it could either = work as one of the following:
(1) somehow the called party would have to know that = the call is
    forked (which would be my = prefered solution). I guess there
    would need to be some forking = indication added to the INVITE by
    the forking proxy. This is = similar to what I was hinting at,
    but you're proposal is cleaner = because it relies on signaling
    for muting the media.
(2) the forking proxy would have to modify the SDP = in the INVITE to
    put the media on hold (i.e., = sendonly or inactive). Of course,
    this means it wouldn't be a proxy = anymore but a B2BUA, which
    is not very desireable....

If we don't do anything about this problem, the only = alternative for
implementors of forking proxies will be to make them = B2BUAs.
Now we don't want this, do we?

Gonzallo, in response to your email: yes I totally = get the point that forking
introduces some difficulties. But what we currently = have in the draft for forking
makes it a lot worst. It needs to be fixed. If we = can't do it all in this document
(because it requires some additions to SIP), then it = may be that we need some other
internet draft specifically on forking. That's = finewith me. I just don't think we
should encourage anybody to "pick a random = stream" as per the current draft.

------_=_NextPart_001_01C2FA33.2A6C53F6-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 18:19:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19765 for ; Thu, 3 Apr 2003 18:19:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33NLlV09993 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 18:21:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33NLkK09990 for ; Thu, 3 Apr 2003 18:21:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19757 for ; Thu, 3 Apr 2003 18:18:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33NKtK09947; Thu, 3 Apr 2003 18:20:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33NJNK09837 for ; Thu, 3 Apr 2003 18:19:23 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19674 for ; Thu, 3 Apr 2003 18:16:22 -0500 (EST) Received: from cia.cisco.com (IDENT:mirapoint@cia.cisco.com [161.44.85.200]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h33NImdo006391; Thu, 3 Apr 2003 18:18:49 -0500 (EST) Received: from mhammer-w2k02.cisco.com (hrn2-dhcp-161-44-87-251.cisco.com [161.44.87.251]) by cia.cisco.com (Mirapoint) with ESMTP id ABT63201; Thu, 3 Apr 2003 18:08:54 -0500 (EST) Message-Id: <4.3.2.7.2.20030403180741.04059eb0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Apr 2003 18:17:45 -0500 To: "Francois Audet" From: Michael Hammer Subject: RE: [Sipping] New version of the early media draft Cc: "'Gonzalo Camarillo'" , "Tom-PT Taylor" , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" , "Mark Watson" In-Reply-To: <2F1FC1DEA077D5119FAD00508BCFD6D2079A7B13@zsc3c030.us.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , At 02:48 PM 4/3/2003 -0800, Francois Audet wrote: > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Thursday, April 03, 2003 08:31 > > To: Gonzalo Camarillo > > Cc: Audet, Francois [SC100:4K02:EXCH]; Taylor, Tom-PT > > [CAR:5N00:EXCH]; 'Bob Penfield'; 'sipping@ietf.org'; 'Jon > > PETERSON (Jon.Peterson@neustar.com)'; 'Christer Holmberg'; > > Watson, Mark [MOP:EP10:EXCH] > > Subject: Re: [Sipping] New version of the early media draft > > > > > > Gonzalo, > > > > Would it be possible to have an early media convention that > > contains the > > following elements: > > > > 1) the receiving end indicates in signaling that it intends > > to send early media > > 2) the receiving end includes SDP in hold state and does not > > send media at > > first > > 3) the caller responds to one receiver's inband indicator (or > > not) with an > > UPDATE putting that receiver in send state > > 4) the receiving end responds to UPDATE and begins sending of > > RTP with media. > >You are right: we need to get rid of the randomness. > >How do the terminating end know that they should answer in the hold state? >Would it apply all the time (which seems to me to be a drastic change from >current implemenations), or only when there is forking? > >If it is only when there is forking, it could either work as one of the >following: >(1) somehow the called party would have to know that the call is > forked (which would be my prefered solution). I guess there > would need to be some forking indication added to the INVITE by > the forking proxy. This is similar to what I was hinting at, > but you're proposal is cleaner because it relies on signaling > for muting the media. >(2) the forking proxy would have to modify the SDP in the INVITE to > put the media on hold (i.e., sendonly or inactive). Of course, > this means it wouldn't be a proxy anymore but a B2BUA, which > is not very desireable.... I would avoid (2) as this is not always possible (secured SDP) or desirable. Your forking indicator suggestion could be the trigger for the behavior I defined, thus distinguishing it from the current ambiguous "normal" behavior. (media may/may not be in the RTP) I just thought that if the intent is to use the RTP to signal that media needs to be played, something other than the "normal" response should inform the client that could then say "go ahead". Mike >If we don't do anything about this problem, the only alternative for >implementors of forking proxies will be to make them B2BUAs. >Now we don't want this, do we? > >Gonzallo, in response to your email: yes I totally get the point that forking >introduces some difficulties. But what we currently have in the draft for >forking >makes it a lot worst. It needs to be fixed. If we can't do it all in this >document >(because it requires some additions to SIP), then it may be that we need >some other >internet draft specifically on forking. That's finewith me. I just don't >think we >should encourage anybody to "pick a random stream" as per the current draft. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 18:23:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19863 for ; Thu, 3 Apr 2003 18:23:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33NQKj10204 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 18:26:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33NQKK10199 for ; Thu, 3 Apr 2003 18:26:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19855 for ; Thu, 3 Apr 2003 18:23:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33NP6K10148; Thu, 3 Apr 2003 18:25:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33NOGK10102 for ; Thu, 3 Apr 2003 18:24:16 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19818 for ; Thu, 3 Apr 2003 18:21:15 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h33NNY816428; Thu, 3 Apr 2003 17:23:34 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2FGBVRDT>; Thu, 3 Apr 2003 15:23:35 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2079A7BD9@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Michael Hammer'" Cc: "'Gonzalo Camarillo'" , "Tom-PT Taylor" , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" , "Mark Watson" Subject: RE: [Sipping] New version of the early media draft Date: Thu, 3 Apr 2003 15:23:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FA38.06C3643A" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FA38.06C3643A Content-Type: text/plain > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > >(1) somehow the called party would have to know that the call is > > forked (which would be my prefered solution). I guess there > > would need to be some forking indication added to the INVITE by > > the forking proxy. This is similar to what I was hinting at, > > but you're proposal is cleaner because it relies on signaling > > for muting the media. > >(2) the forking proxy would have to modify the SDP in the INVITE to > > put the media on hold (i.e., sendonly or inactive). Of course, > > this means it wouldn't be a proxy anymore but a B2BUA, which > > is not very desireable.... > > I would avoid (2) as this is not always possible (secured SDP) or > desirable. Your forking indicator suggestion could be the > trigger for the > behavior I defined, thus distinguishing it from the current ambiguous > "normal" behavior. (media may/may not be in the RTP) I just > thought that > if the intent is to use the RTP to signal that media needs to > be played, > something other than the "normal" response should inform the > client that > could then say "go ahead". Agreed. I think we need a forking indication. ------_=_NextPart_001_01C2FA38.06C3643A Content-Type: text/html RE: [Sipping] New version of the early media draft

> -----Original Message-----
> From: Michael Hammer [mailto:mhammer@cisco.com]
> >(1) somehow the called party would have to know that the call is
> >     forked (which would be my prefered solution). I guess there
> >     would need to be some forking indication added to the INVITE by
> >     the forking proxy. This is similar to what I was hinting at,
> >     but you're proposal is cleaner because it relies on signaling
> >     for muting the media.
> >(2) the forking proxy would have to modify the SDP in the INVITE to
> >     put the media on hold (i.e., sendonly or inactive). Of course,
> >     this means it wouldn't be a proxy anymore but a B2BUA, which
> >     is not very desireable....
>
> I would avoid (2) as this is not always possible (secured SDP) or
> desirable.  Your forking indicator suggestion could be the
> trigger for the
> behavior I defined, thus distinguishing it from the current ambiguous
> "normal" behavior.  (media may/may not be in the RTP)  I just
> thought that
> if the intent is to use the RTP to signal that media needs to
> be played,
> something other than the "normal" response should inform the
> client that
> could then say "go ahead".

Agreed. I think we need a forking indication.

------_=_NextPart_001_01C2FA38.06C3643A-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 19:30:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21224 for ; Thu, 3 Apr 2003 19:30:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h340We714870 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 19:32:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h340WdK14867 for ; Thu, 3 Apr 2003 19:32:39 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21217 for ; Thu, 3 Apr 2003 19:29:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h340VZK14831; Thu, 3 Apr 2003 19:31:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h340UlK14794 for ; Thu, 3 Apr 2003 19:30:47 -0500 Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21165 for ; Thu, 3 Apr 2003 19:27:47 -0500 (EST) Received: from tate (host13.brodsoft.com [66.160.10.13] (may be forged)) by broadsoft.com (8.12.6p2) id h340UFNx039991; Thu, 3 Apr 2003 19:30:15 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network Date: Thu, 3 Apr 2003 19:33:40 -0500 Message-ID: <001001c2fa41$d7b1fee0$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: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > The problem with this is that the SIP UA > receives no information about the change > of partner in the conversation. In particular, > if the SIP UA originally received the identity > of the original partner by means of asserted > or authenticated identity from the gateway, > that information will no longer be valid and > needs to be updated. > > Potential solutions: > > 4. Send UPDATE with new asserted ID. Solution 4 is valid although it potentially has not been explicitly documented. Using UPDATE or a re-INVITE with a new display-name is potentially also valid. RFC 3311 documents that UPDATE can be used to update most any header that is valid during an invite dialog. The session timer draft is using UPDATE to update the Session-Expires. RFC 3311 uses UPDATE to update the body, Contact, Allow, Call-Info, etcetera. (See section 8.) Unfortunately RFC 3311 did not define a header to help identify which headers are trying to be updated. If it did, it might be easier to communicate which things should be updated and which things were successfully updated. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 3 20:06:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21786 for ; Thu, 3 Apr 2003 20:06:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3418lh17591 for sipping-archive@odin.ietf.org; Thu, 3 Apr 2003 20:08:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3418lK17588 for ; Thu, 3 Apr 2003 20:08:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21778 for ; Thu, 3 Apr 2003 20:05:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3417tK17566; Thu, 3 Apr 2003 20:07:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3416PK16748 for ; Thu, 3 Apr 2003 20:06:25 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21741 for ; Thu, 3 Apr 2003 20:03:23 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3415lm02746; Thu, 3 Apr 2003 17:05:48 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2FGBVWWX>; Thu, 3 Apr 2003 17:05:47 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D2079A7DCC@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Elwell, John'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network Date: Thu, 3 Apr 2003 17:05:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FA46.4EB2AD24" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FA46.4EB2AD24 Content-Type: text/plain > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > > 5. Send INVITE (new dialog) with Replaces header and Required header (Replaces required). > This would be rejected by a UA that does not support the Replaces header. My take is that this is exactly what the Replaces header was intented to do (it even mentions the attended transfer case). It is up to the transferor to decide if the Required header should be included or not. It it is included, it means that the transferor prefers that the transfer fails than not updating the other party's information. If not included, it means that it is willing to tolerate the fact that the identity may not be updated (this happens today in traditional PBXs if there is no protocol to update the calling line identity and the call is locally bridged). ------_=_NextPart_001_01C2FA46.4EB2AD24 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] Impact on SIP of transfer in QSIG network

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]
>
> 5. Send INVITE (new dialog) with Replaces = header and Required header (Replaces required). > This would be = rejected by a UA that does not support the Replaces header.

My take is that this is exactly what the Replaces = header was intented to do (it even
mentions the attended transfer case).

It is up to the transferor to decide if the Required = header should be included or not.

It it is included, it means that the transferor = prefers that the transfer fails than
not updating the other party's information.

If not included, it means that it is willing to = tolerate the fact that the identity
may not be updated (this happens today in = traditional PBXs if there is no protocol
to update the calling line identity and the call is = locally bridged).

------_=_NextPart_001_01C2FA46.4EB2AD24-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 01:04:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26931 for ; Fri, 4 Apr 2003 01:04:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3466ww03627 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 01:06:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3466vK03624 for ; Fri, 4 Apr 2003 01:06:57 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26921 for ; Fri, 4 Apr 2003 01:03:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3465YK03582; Fri, 4 Apr 2003 01:05:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3464OK03503 for ; Fri, 4 Apr 2003 01:04:24 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26889 for ; Fri, 4 Apr 2003 01:01:14 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3463eRs025413; Fri, 4 Apr 2003 08:03:40 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4012H5; Fri, 4 Apr 2003 08:03:41 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3463dAv024638; Fri, 4 Apr 2003 09:03:39 +0300 (EET DST) Message-ID: <3E8D203B.3070405@lmf.ericsson.se> Date: Fri, 04 Apr 2003 09:03:39 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: Francois Audet , Tom-PT Taylor , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" , Mark Watson Subject: Re: [Sipping] New version of the early media draft References: <2F1FC1DEA077D5119FAD00508BCFD6D20794E863@zsc3c030.us.nortel.com> <4.3.2.7.2.20030403102839.00b44170@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael, fetch the draft below: http://www.ietf.org/internet-drafts/draft-camarillo-sipping-early-media-01.txt Read Section 2.3; this section explains that the gateway model produces undesirable results when forking is present. Therefore, you SHOULD NOT use this model. However, there are some situations when the gateway cannot distinguish between early and regular media. In that situation, even knowing that there may be problems if forking occurs, the gateway has no other choice than using the gateway model. Therefore, even if you had an indication telling the gateway that the call forked, the gateway DOES NOT HAVE ANY OTHER CHOICE. But what happens if your system does have a choice and can actually distinguish between early and regular media? Go on and read Section 3. It provides a mechanism that, if you look at the end result, is equivalent to yours. Therefore, I assume that you will be happy with that mechanism. Why do we use that mechanism (reverse INVITE) instead of your mechanism or UPDATEs with an extra stream with an "early media" label (documented in the draft as well)? It is explained in the last pargraph of Section 3. " An alternative model would consist of adding a new stream labeled as "early media" to the original session between the UAC and the UAS using an UPDATE, instead of establishing a new session. We have chosen to establish a new session to be coherent with the mechanism used by application servers that are NOT co-located with the UAS. This way, the UAS uses the same mechanism as any other application server in the network to interact with the UAC." Hope this helps, Gonzalo Michael Hammer wrote: > Gonzalo, > > Would it be possible to have an early media convention that contains the > following elements: > > 1) the receiving end indicates in signaling that it intends to send > early media > 2) the receiving end includes SDP in hold state and does not send media > at first > 3) the caller responds to one receiver's inband indicator (or not) with > an UPDATE putting that receiver in send state > 4) the receiving end responds to UPDATE and begins sending of RTP with > media. > > This resolves the forking case, tells the caller which device intends > inband media, and allows the caller with possibly user in the loop to > decide which to listen to. > > See the following: > > A Forking Proxy User User User > B1 B2 B3 > | | | | | > | INVITE F1 | | | | > |--------------->| | | | > | 100 Trying F2 | | | | > |<---------------| INVITE F3 | | | > | |------------->| | | > | | INVITE F4 | | > | |-------------------->| | > | | INVITE F5 | | > | |--------------------------->| > | | 183 inband F6| | | > | 183 inband F7 |<-------------| | | > |<---------------| | | | > | | 183 inband F8| | | > | 183 inband F9 |<--------------------| | > |<---------------| | | | > | UPDATE send F10| | | | > |--------------->| UPDATE send F11 | | > | |-------------------->| | > | | ACK send F12 | | | > | ACK send F13 |<--------------------| | > |<---------------| | | | > Play<=====|<======Early media====================| | > | | 180 inband F14 | | > | 180 inband F15 |<---------------------------| > |<---------------| CANCEL F16 | | | > | |------------->|media | | > | | 200 OK F17 |stops | | > | |<-------------| | | > | | 487 F18 | | | > | |<-------------| | | > | | ACK F19 | | | > | |------------->| | | > | UPDATE send F20| | | | > |--------------->| UPDATE send F21 | | > | |--------------------------->| > | | ACK send F22 | | | > | ACK send F23 |<---------------------------| > |<---------------| | | | > Play<=====|<==============="Hello"======================| > | | 200 OK F24 | > | 200 OK F25 |<---------------------------| > |<---------------| | | | > | ACK send F26 | | | | > |--------------->| ACK send F27 | | | > | |--------------------------->| > | | | | | > > Am I missing anything here? > The key is to stop guessing and make it more deterministic. > > If you don't like this, don't use the inband indicator, and fall back to > the current state of problems. > > Mike > > > At 01:18 PM 4/3/2003 +0300, Gonzalo Camarillo wrote: > >> Francois, >> >> you are missing the point of the draft. The draft explains what >> happens when you use early media within the dialog are forking occurs. >> That is, you have a lot of problems. >> >> The aim of the draft is to describe these problems and to describe >> things that a UAC may do without extending the protocol. We do that >> because you have to interact with existing UASs that will send you >> media this way. You cannot upgrade the already installed base. >> >> But we do not want to extend the protocol to provide a solution for >> this gateway model. We recommend that new systems use the application >> server model. In this model, we will provide solutions and extend the >> protocol should that be needed. >> >> Gonzalo >> >> Francois Audet wrote: >> >>> > First of all, I do not understand why people continue >>> > discussing things >>> > like early media with forking whose problems are already well >>> > discussed >>> > and documented in the draft and nobody so far has been able >>> > to come up >>> > with a single use case where the proposed flag would be useful... I >>> > would ask people to focus on the problem in hand (i.e., the >>> > flag), and >>> > stop discussing about already resolved issues. >>> The problem is that the multiple dialog problem and early media >>> problem (as in forking >>> for example) has NOT been solved. Worst, using the current unworkable >>> solution as a basis >>> to make our decisions on the flag issue will not result in a good >>> solution. >>> The current solution for forking in the draft is for the UAC to pick >>> a random media >>> stream (based on signaling, thus the dialog, not media, because there >>> is no means to correlate >>> dialog and media stream) and mute the others by sending UPDATEs to >>> the far end. This is >>> not an acceptable solution. Random non-redictable behavior is not >>> acceptable to end-users. >>> Furthemore, this is not robust at all because if the called UA does >>> not support UPDATE, >>> multiple streams will be received and there will be no way for the >>> UAC receiving it >>> to pick the proper one. (If there was a way to correlate an RTP >>> stream to the dialog that >>> generate it, it would be easier) >>> This leaves the client with 3 choices: >>> 1) Pick a random media stream (which it will not be able to correlate >>> with a specific dialog >>> unless it is lucky with educated guesses). >>> 2) Mix media streams together. >>> 3) Provide alternative local treatment based on the provisional >>> responses received. This >>> could be >>> >>> You are right that the flag probably doesn't help with this problem. >>> I'll leave it >>> to others to defend the flag idea. >>> I'm OK with current draft, as long as we do not ADD any more >>> dependency on the "play >>> media when you receive it" principle to address the flag prolem, and >>> as long as we improve >>> the section on forking. It seems to me that if forking is used we CAN >>> NOT use early media for >>> in-band ringing (we could do early media for clipping avoidance). >>> Perhaps we need a >>> "forked" indication in INVITE telling the far-end not to send early >>> media... And to make >>> it bullet proof a forked indication in the 100 Trying (when forking) >>> to tell the UAC making the >>> call that "weird stuff" is going to happen and that proper treatment >>> should be used not >>> to confused the user. >> >> >> >> -- >> Gonzalo Camarillo Phone : +358 9 299 33 71 >> Oy L M Ericsson Ab Mobile: +358 40 702 35 35 >> Telecom R&D Fax : +358 9 299 30 52 >> FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com >> Finland http://www.hut.fi/~gonzalo >> >> _______________________________________________ >> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >> This list is for NEW development of the application of SIP >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sip@ietf.org for new developments of core SIP > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 01:47:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27650 for ; Fri, 4 Apr 2003 01:47:56 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h346oXe06805 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 01:50:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h346oXK06802 for ; Fri, 4 Apr 2003 01:50:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27641 for ; Fri, 4 Apr 2003 01:47:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h346nTK06747; Fri, 4 Apr 2003 01:49:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h346mRK06675 for ; Fri, 4 Apr 2003 01:48:27 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27595 for ; Fri, 4 Apr 2003 01:45:17 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h346ljI3016304; Fri, 4 Apr 2003 08:47:45 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4R9V51; Fri, 4 Apr 2003 08:47:46 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h346ljAv027226; Fri, 4 Apr 2003 09:47:45 +0300 (EET DST) Message-ID: <3E8D2A90.30407@lmf.ericsson.se> Date: Fri, 04 Apr 2003 09:47:44 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takuya Sawada CC: sipping@ietf.org Subject: Re: Prepared to receive media bu not to play (was Re: [Sipping] New version of the early media draft) References: <2F1FC1DEA077D5119FAD00508BCFD6D20787D68D@zsc3c030.us.nortel.com> <3E89248E.A4CF6816@lmf.ericsson.se> <200304022154.EGD31058.TBBE-VBXU@kddi.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Takuya, yes, you are correct. Gonzalo Takuya Sawada wrote: > This may be irrelevant to the matter on this thread, media flag, > but let me clarify one thing. > > RFC3264 reads that once the offerer has sent the offer, it MUST be prepared > to receive media. I do not take this statement as "it MUST play media". > To receive media is one thing and to play media can be another thing. > In my understanding, to recieve media means not to respond with ICMP error, > to initialize sequence number, to adjust jitter buffer, to calculate > statistics, to send RTCP, etc. Once it receives media, it can play out > media but I think this is essentially the matter of application and its policy. > > There is a use case that it should not play the early media: > Considering PSTN to SIP endpoint call flow, if PSTN gateway play out > the media from SIP endpoint before the call is answered, network > operator will face the risks that its PSTN resources are consumed by > unanswered but meaningful backward voice usage. On the other hand, > network operator will have media clipping problem unless it palys early media. > You must choose media clipping or risk of the theft of PSTN resource. > I think this is the decision of network policy, not of the protocol. > Am I correct? > > I really want PSTN gateways implementation to be configurable on whether > to play out the early media or not, hopefully depending on whether the > peer is trusted or not. > > By the way, regarding the media flag, I agree with Gonzalo. > > Regards, > Takuya > > > >>Francois, >> >>you must play the media you get because of the 200 OK-RTP race >>condition. Therefore, your proposal of sending a 180 response saying "I >>will send you media, but do not play it", will cause media clipping when >>the 200 OK arrives later than the first RTP packets. >> >>I would like people to note that this problem is unsolvable as long as >>SIP and RTP follow different paths (as it is the case). Therefore, no >>matter how many flags we define, the 200 OK-RTP race condition will >>force us to listen to the media path in order to avoid media clipping. >> >>Gonzalo >> >> >> >>Francois Audet wrote: >> >>>>-----Original Message----- >>>>From: Bob Penfield [mailto:bpenfield@acmepacket.com] >>>>Sent: Saturday, March 29, 2003 07:43 >>>>To: sipping@ietf.org >>>>Subject: Re: [Sipping] New version of the early media draft >>>> >>>>BTW, I do support your position that no additional indication >>>>of the presence or absence of early media is required in SIP >>>>signaling. If UAC receives media, it should play it. >>> >>>This is actually the biggest problem I personnally have with the >>>assumptions on early >>>media. >>> >>>I do not think that this rule of "play media when you receive it" is >>>implementable >>>generally, but only in a few very selected cases. >>> >>>There are a number of scenarios that I think are problematic: >>> >>>1 - 180 with SDP >>> >>>If a 180 is sent with an SDP (for the purpose of telling the far end >>>what >>>codec is picked), the called UA the shouldn't be sending silence in >>>RTP because, according to the current rules, the calling UA would stop >>>the >>>locally generated ringing to play the silence packet. (Doing some >>>heavy duty >>>DSP parsing to detect if the media is silence or not seems hardly >>>efficient, >>>nor reliable). >>> >>>A side effect of this is that if there is a NAT/Firewall involved, it >>>is quite >>>possible that the binding will expire and the address in the SDP will >>>be invalid >>>or the media will be blocked upon answer. >>> >>>If an indication was present to indicate if the in-band media was >>>meant to be >>>replacing the locally generated tone, we wouldn't have this problem >>>(i.e., one >>>could send packets in-band to keep the binding alive). >>> >>> >>>2 - Sequential calling >>> >>>In a sequential calling scenario such as call call forwarding no >>>answer (section 2.8 >>>of the SIP services examples Internet Draft). Suppose the following: >>> >>> Alice Proxy User B1 User B2 >>> | | | | >>> | INVITE F1 | | | >>> |--------------->| INVITE F2 | | >>> |(100 Trying) F3 |------------->| | >>> |<---------------|183 ProgressF4| | SDP >>>is included with 183 >>> | 183 Progress F5|<-------------| | >>> |<---------------| | | >>> | Both way RTP Established | | >>>In-band |<=============================>| | >>>ringing | Request Timeout | >>> | | | | >>> | | CANCEL F6 | | >>> | |------------->| | >>> | | 200 OK F7 | | >>> | |<-------------| | >>> | | 487 F8 | | >>> | |<-------------| | >>> | | ACK F9 | | >>> | |------------->| | >>> | | | INVITE F10 | >>> | |--------------------------------->| >>> | | | 180 Ringing F11 | >>> | 180 Ringing F12|<---------------------------------| >>> |<---------------| | | >>> >>>The problem with this scenario is that presumably, upon receipt of >>>180, >>>the UA needs to figure out somehow that it should be playing the >>>locally >>>generated alerting. This would imply that upon receipt of the 180, the >>>calling >>>UA would start a timer and wait until it expires to play the locally >>>generate >>>tone. Since ringing is composed of tone-silence-tone, the timer will >>>have to be >>>relatively long. While the UA can detect that the 180 is a different >>>dialog than >>>the 183, it can not know for sure that the first dialog had been >>>cancelled >>>because it could be forking: it has to rely on the media. >>> >>>While this is technically feasible, it imposes a big unecessary burden >>>on >>>the client, especially if it is a thin client. On a "decomposed" >>>architecture >>>(like a stimulus MGCP phone), it makes for pretty nasty signalling, if >>>possible >>>at all. >>> >>>PS: I'm not saying that the in-band media is necessarily useful in >>>this scenario. I'm >>>just pointing out the difficulties of the "play media when received" >>>mantra. >>> >>>3 - Forking >>> >>>As expected, this is the worst. >>> >>> Alice Proxy User B1 User B2 >>> | | | | >>> | INVITE F1 | | | >>> |--------------->| INVITE F2 | | >>> |(100 Trying) F3 |------------->| | >>> |<---------------|183 ProgressF4| | SDP >>>is included with 183 >>> | 183 Progress F5|<-------------| | >>> |<---------------| | | >>> | Both way RTP Established | | >>>In-band |<=============================>| | >>>ringing | | | | >>> | | | INVITE F10 | >>> | |--------------------------------->| >>> | | | 180 Ringing F11 | >>>Locally | 180 Ringing F12|<---------------------------------| >>>generated |<---------------| | 200 OK F13 | >>>ringing | |<---------------------------------| >>> >>>There are of course multiple permutations, such as 2 183s, 2 180s, 1 >>>183 followed >>>by a 180, or 1 180 followed by a 183. And then there might be more >>>than 2 UAs being >>>forked-to, so the problem can be really bad. >>> >>>There is no way to associate a specific RTP stream with a specific >>>dialog. The current >>>draft hints that one UA could randomly play one stream and mute the >>>others (which will be >>>very troublesome if the other UA doesn't support UPDATE). This is not >>>satisfactory and >>>would result in garbage being played to the user. For this reason, I >>>believe that the only >>>reasonable approach in this scenario is to let the 180 override the >>>183s (if there is >>>a 180) and ignore all media. This will of course result that there >>>might be some level of >>>clipping on answer (I have yet to see a network where this is a >>>problem). If there is no >>>180, one could play one of the random stream (although I don't think >>>it is particulary >>>useful), or play some default "progress" tone that would indicate to >>>the user that the >>>call is forked. >>> >>>One of the reason I think the 180 indication is more useful than the >>>183-with-in-band- >>>media is that if the in-band from the 183 is saying "This number has >>>been disconnected, >>>please hangup" and then a 200 OK comes back (for the 180) wich >>>connects the call, the user >>>will be very disoriented (realistically, he will probably have hung-up >>>anyways). The other >>>way around (playing the local ringback) will at least keep the user >>>on-line in case somebody >>>does answer. The point is that since we can't associate a particular >>>media stream with >>>the SIP signalling, we can't just "play the media" when there is >>>multiple dialogs. >>> >>>Many people seem to think that "this is forking, it is trouble, don't >>>use it, bla bla bla". >>>Unfortunately, it is extremely useful. Also, it happens all the time >>>today when parallel >>>calling is done (different names exists for it, including "multiple >>>appearances", or >>>"parallel hunt groups"). If SIP can not properly ring multiple agents >>>in a pool in parallel, >>>it won't be terribly useful. >>> >>>The only alternative is to wait for the 200 OK to connect media. >>>Despite the claims of >>>this introducing clipping on answer, I haven't seen this to be a >>>problem on existing VoIP >>>systems (i.e., the time it takes the human to answer is longer than >>>the interval during >>>which there could be clipping). >>> >>>One added difficulty is that from the calling UA's perspective, we >>>can't distinguish easily >>>between case 2 and 3. >>> >>>--------- >>> >>>My conclusion is that when there are multiple dialogs, we can not >>>honor media at the >>>calling UA and have to rely on the SIP provisional responses >>>exclusively. This goes against >>>the "play media as soon as you receive it" principle. >>> >>>Also, since parallel calling (i.e., forking) is extremely common in >>>call centers and >>>within enterprises, it greatly limits the applicability of early >>>media, or indeed ringing >>>2 phones in a private residence. My personal opinion is that it is >>>really limited to TDM >>>gateway interworking, and only when there is no forking involved or >>>multiple dialog >>>involved. >>> >>>Again, I don't believe that the "in-band alerting" indication >>>necessarily solves this (although >>>it does help in a few cases). I'm just pointing out that the play >>>in-band RTP even if 180 is >>>received is not generally a good idea. The reason I am sending this >>>email in the context >>>of this discussion on the in-band ringing indication is that this idea >>>that playing in-band >>>media automatically helps keeps on re-surfacing. >>> >>>Fran$BmP(Bis Audet >> >>-- >>Gonzalo Camarillo Phone : +358 9 299 33 71 >>Oy L M Ericsson Ab Mobile: +358 40 702 35 35 >>Telecom R&D Fax : +358 9 299 30 52 >>FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com >>Finland http://www.hut.fi/~gonzalo >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP > > > > -------- > Takuya Sawada > KDDI Corporation (KDDI) > KDDI Bldg. 2-3-2 Nishishinjuku Shinjuku-ku, > Tokyo 163-8003, Japan > Tel: +81-3-3347-7406 > Fax: +81-3-3347-7418 > tu-sawada@kddi.com > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 01:58:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27816 for ; Fri, 4 Apr 2003 01:58:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34711207249 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 02:01:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34711K07246 for ; Fri, 4 Apr 2003 02:01:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27813 for ; Fri, 4 Apr 2003 01:57:52 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3470BK07193; Fri, 4 Apr 2003 02:00:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h346xoK07122 for ; Fri, 4 Apr 2003 01:59:50 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27777 for ; Fri, 4 Apr 2003 01:56:41 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h346x9I3019326; Fri, 4 Apr 2003 08:59:09 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4LFV3R; Fri, 4 Apr 2003 08:59:10 +0200 Received: from lmf.ericsson.se ([131.160.31.93]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h346x9Av027837; Fri, 4 Apr 2003 09:59:09 +0300 (EET DST) Message-ID: <3E8D2D3E.A7B370A3@lmf.ericsson.se> Date: Fri, 04 Apr 2003 09:59:10 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson CC: "'Gonzalo Camarillo'" , Tom-PT Taylor , sipping@ietf.org, Jon Peterson Subject: Re: [Sipping] Early media; a summary after the IETF References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > >I meant the part that allows you to ask the termination to 'play a > tone until you get incoming media, then play that' - or perhaps I've > missed something and that is already possible too >? My understanding of H.248 is that it is possible to do so, as long as it happens on the same termination. > >It is the use of RTP packets themselves as an implicit indication > that there is early inband media, compared to defining an explicit > signalling indication that I think is a bad design. If >you only have > the former, implicit, indication available, then I see nothing wrong > with your proposal wrt H.248. I think it is important to notice that the "H.248 solution" above may not work very well in networks where we have early media. The reasons is that the MG really doesn't know if the media is early or not (if the "final" media reaches the MG before the 200 OK). So, in a forking scenario it would have to accept and forward all media, which again may lead to media mixing. So, one would have to assume that there is NO early media, and that the RTP packet detected actually comes from the node which has answered the call and sent 200 OK. IF we have early media, and we don't want media mixing, I guess we still have to wait for 200 OK before we forward media. But, then we again have the risk of media clipping, since we may have forwarded media from another early leg (to avoid clipping), or we haven't forwarded any media at all... Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 04:37:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12370 for ; Fri, 4 Apr 2003 04:37:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h349eHi29719 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 04:40:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h349eHK29716 for ; Fri, 4 Apr 2003 04:40:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12237 for ; Fri, 4 Apr 2003 04:37:03 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h349dYK29630; Fri, 4 Apr 2003 04:39:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h349cDK29577 for ; Fri, 4 Apr 2003 04:38:13 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12165 for ; Fri, 4 Apr 2003 04:35:00 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h349bTI3005096; Fri, 4 Apr 2003 11:37:29 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A47GNXB; Fri, 4 Apr 2003 11:37:29 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h349bSAv007906; Fri, 4 Apr 2003 12:37:29 +0300 (EET DST) Message-ID: <3E8D5257.6070807@lmf.ericsson.se> Date: Fri, 04 Apr 2003 12:37:27 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Watson CC: Tom-PT Taylor , sipping@ietf.org, Jon Peterson Subject: Re: [Sipping] Early media; a summary after the IETF References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark, > My other point, which seems not to have been captured in Gonzalo's > slides (although I don't know if it was discussed at the meeting), was > that as a general principle, the status of the media stream should be > visible at the signalling layer. This is the case in all the other > call/session control protocols that I know of. I do not buy the argument "since others did it, let's do it". I'd rather analyze if what they did is applicable or not to our particular problem. More inline. > The current status of SIP seems to be that whether there is media > present or not is indicated only at the RTP layer, by the physical > presence or otherwise of RTP packets. We have already discussed this in the past. In the first version of the draft, I discussed that SDP provided only the status of the media tools at the end points (i.e., the media tools are on and off). I proposed to enhance this indications to convery situations like "media tool on, but I will not be sending media for the time being". after analyzing it, we all agreed that more granularity was not needed. > This creates the problem that deliberate absence of media is > indistinguishable at the UAC from an error case in which media has been > blocked due to some network issue/NAT problem etc. At the very least > this makes debugging more difficult. You have RTCP. The sending side will always know whether there is an error. What you are proposing does not actually help debugging. Let's say my SIP phone sends you a signalling message saying "I will be sending media", but I remain silent in front of my microphone... now you will think that there is an error in the network, when everything is perfectly normal. > In addition, since this is the principle which has been adopted by so > many other call/session control protocols, then a gateway interworking > from one of these to SIP will not have the information necessary to > simply map to indications in appropriate backwards signalling messages. > For example in mapping a SIP 180 to a Q.SIG or Q.931 ALERTING, I am > forced to always provide in-band media (ringtone or media received from > the UAS) and indicate this in the ALERTING/Q.931, whereas if I had an > indication at the SIP layer I could take advantage of this to indicate > no in-band media in the ALERTING (in some cases) and save myself on tone > generation. As far as I know, Q.931 lets you send ALERTING with no indication, but I do not know any example where the network uses this message. Where is this used? In any event, you will have the RTP-200 OK race condition. Therefore, if you do what you are saying (ALERTING + no indication), you will have media clipping. > Finally, if I want to secure the implicit indication of media then I > need to secure the RTP stream itself (which is not otherwise required in > all applications). To secure a SIP-layer indication I have all the > SIP-layer security stuff available. I do not understand what you are saying here. If we do not have a flag, it does not matter whether or not you secure SIP, nobody will know anything about the media path. If you have the flag, you have to secure SIP. Otherwise you coule leak this information (which I do not think it is very sensitive, but anyway)... therefore, the only thing the addition of the flag could do is worsen the situation... never improve it. > I am not arguing that these examples alone justify such an indication, > but rather that as a general principle this information should be > signalled explicitly in SIP, not implicitly by the presence of RTP packets. > > I accept that the SIPPING meeting was not convinced that enough > examples/use-cases had been presented to justify the indication, and if > this remains the case then I guess nothing will be agreed. But as I feel > these all stem from a more general principle, I think over time we will > continue to see more examples emerge. I would like to know if the only reason you want such a flag is because you "fell" that it is the right thing to do (definitively an acceptable position) or if you have a use case where you *actually* need such a flag. The only use case I have been able to think of so far is the saving of a signalling message from the MGC to the MG in the situation previously described... but I would like to know if people have more use cases. The only extra use case that people have come up with is the network scenario where RTP-200 OK race conditions are not considered important. That is, they are ignored. In that case, signalling will drive the MG. People working with that type of network have already what they want: the SDP direction attribute. Therefore, if that is the requirement people are after, it is already solved. They have their flag *already*. And if people are thinking of another scenario(s), please speak up. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 05:31:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13340 for ; Fri, 4 Apr 2003 05:31:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34AYAL32214 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 05:34:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34AYAK32211 for ; Fri, 4 Apr 2003 05:34:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13312 for ; Fri, 4 Apr 2003 05:30:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34AXQK32160; Fri, 4 Apr 2003 05:33:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34AWfK32125 for ; Fri, 4 Apr 2003 05:32:41 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13287 for ; Fri, 4 Apr 2003 05:29:28 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h34AVtRs016516; Fri, 4 Apr 2003 12:31:55 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4SAXDK; Fri, 4 Apr 2003 12:31:55 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h34AVtAv011334; Fri, 4 Apr 2003 13:31:55 +0300 (EET DST) Message-ID: <3E8D5F19.8@lmf.ericsson.se> Date: Fri, 04 Apr 2003 13:31:53 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: sipping@ietf.org, Rohan Mahy Subject: Re: [Sipping] Questions on connect-reuse References: <3E802C1F.6EF210E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christer, > Q1. > > Why is the reason the "alias" parameter is put in the Via header? Isn't > the Via used for response routing only? Wouldn't it fit better as a > header (or URI) parameter used in the Contact- and Record-Route headers > instead? The alias parameter is meaningful between a SIP entity and its next hop (hop-by-hop) when they have a connection. You cannot tell a server two hops away to reuse the existing connection you have with it, because you do not have any existing connection. The top-most Via is always from the previous hop. This is not true for Contact or Record-Route entries. > Q2: > > Assume I make a SRV lookup, and I get a list with different server > addresses. > > Now, for one of the returned addresses I have an existing TCP connection > which I could use. But, I also receive another address, which has higher > priority. So, which has higher priority: an existing connection, or the > priority identifier in the SRV response? One may argue this is an > implementation/local policy/whatever issue, but I think it would be a > good idea to mention it in the textt. If alias is used properly, I would assume that the client would place a host name in the Via entry with the alias parameter. This way, the other SIP entity will not even perform the DNS lookup. It will have the exisintg TCP connection indexed using the host name. > Q3: > > Assume I send an INVITE to an emphemeral port (the TCP connection was > established by the remote party), and I receive one or more provisional > responses, or a non-2xx responses. Then, the TCP connection goes down, > so I have to establish a new one, to send the CANCEL or ACK. Now, since > the remote party most likely isn't listening to the emphemeral port I > will have to send the CANCEL/ACK to the port I originally got in the SRV > lookup (or from configuration). I think it would be a good idea to also > mention this case, since RFC3261 says that CANCEL and non-2xx ACKs MUST > be sent to the same address, and port, as the INVITE. Good point. We will have to clarify this in the revision of RFC 3261. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 05:37:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13459 for ; Fri, 4 Apr 2003 05:37:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34Adxh00689 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 05:39:59 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34AdxK00686 for ; Fri, 4 Apr 2003 05:39:59 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13449 for ; Fri, 4 Apr 2003 05:36:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Ad5K00648; Fri, 4 Apr 2003 05:39:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34AcCK00618 for ; Fri, 4 Apr 2003 05:38:12 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13411 for ; Fri, 4 Apr 2003 05:34:56 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (znsgy0k8.europe.nortel.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34AbM315380; Fri, 4 Apr 2003 11:37:22 +0100 (BST) Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HG1MML52; Fri, 4 Apr 2003 11:37:22 +0100 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Apr 2003 11:37:08 +0100 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'Gonzalo Camarillo'" Cc: "Tom-PT Taylor" , sipping@ietf.org, Jon Peterson Subject: RE: [Sipping] Early media; a summary after the IETF Date: Fri, 4 Apr 2003 11:37:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FA96.231E2CF6" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FA96.231E2CF6 Content-Type: text/plain; charset="iso-8859-1" Hi Gonzalo, Responses inline... > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 04 April 2003 10:37 > To: Watson, Mark [MOP:EP10:EXCH] > Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; sipping@ietf.org; Jon Peterson > Subject: Re: [Sipping] Early media; a summary after the IETF > > > Mark, > > > My other point, which seems not to have been captured in Gonzalo's > > slides (although I don't know if it was discussed at the > meeting), was > > that as a general principle, the status of the media stream > should be > > visible at the signalling layer. This is the case in all the other > > call/session control protocols that I know of. > > I do not buy the argument "since others did it, let's do it". That's not my argument. My argument is that looking at the architecture of the system and what is appropriate to each layer, I think that this kind of functional indication is appropriate to the signalling layer, not the media layer. I just point out that other similar systems have come to the same conclusion. I'm happy to consider any achitectural arguments you have to the contrary, but noone has presented any yet. > I'd rather > analyze if what they did is applicable or not to our > particular problem. > More inline. > > > The current status of SIP seems to be that whether there is media > > present or not is indicated only at the RTP layer, by the physical > > presence or otherwise of RTP packets. > > We have already discussed this in the past. In the first > version of the > draft, I discussed that SDP provided only the status of the > media tools > at the end points (i.e., the media tools are on and off). I > proposed to > enhance this indications to convery situations like "media > tool on, but > I will not be sending media for the time being". after > analyzing it, we > all agreed that more granularity was not needed. > I am not sure that the principle was addressed in that debate, just that the particular proposal of using SDP status values for this was not agreed. > > This creates the problem that deliberate absence of media is > > indistinguishable at the UAC from an error case in which > media has been > > blocked due to some network issue/NAT problem etc. At the > very least > > this makes debugging more difficult. > > You have RTCP. The sending side will always know whether there is an > error. What you are proposing does not actually help debugging. Let's > say my SIP phone sends you a signalling message saying "I will be > sending media", but I remain silent in front of my > microphone... now you > will think that there is an error in the network, when everything is > perfectly normal. Well, RTCP is optional. The fact that there may not be RTP packets when in fact the sender is intending to send media (it just happens to be silent) surely argues that using the presence/absence of RTP to indicate the media status is even more unreliable! > > > In addition, since this is the principle which has been > adopted by so > > many other call/session control protocols, then a gateway > interworking > > from one of these to SIP will not have the information necessary to > > simply map to indications in appropriate backwards > signalling messages. > > For example in mapping a SIP 180 to a Q.SIG or Q.931 ALERTING, I am > > forced to always provide in-band media (ringtone or media > received from > > the UAS) and indicate this in the ALERTING/Q.931, whereas > if I had an > > indication at the SIP layer I could take advantage of this > to indicate > > no in-band media in the ALERTING (in some cases) and save > myself on tone > > generation. > > As far as I know, Q.931 lets you send ALERTING with no > indication, but I > do not know any example where the network uses this message. Where is > this used? > You can probably get a clearer example from Q.SIG, but at least in Q.931 the ALERTING will be sent with no Progress Indicator #1 or #8 in the case of an end-to-end ISDN call (which can still be speech or 3.1kHz audio). This means there is no in-band media & the user will not be connected to the backwards media path. See Q.931 5.1.2 & Q.699. According to Q.699 this can even happen on an ISDN to non-ISDN call, though I'm not sure I believe this is used. If I have no early media on the SIP side & the call is from an ISDN terminal then I could send an ALERTING with no in-band media. But only if I *know* there will be no in-band media. I guess on receipt of some RTP I can send a PROGRESS with PI#8, but this is my point about mixing layers. > In any event, you will have the RTP-200 OK race condition. > Therefore, if > you do what you are saying (ALERTING + no indication), you will have > media clipping. > Yes, but also I think there are scenarios in which policy dictates that there should be no backwards media allowed before answer (e.g. when the UAS is 'untrusted' in some sense), answer being the point at which the caller is willing to start paying. You have to live with (or mitigate) clipping in these cases anyway. > > Finally, if I want to secure the implicit indication of > media then I > > need to secure the RTP stream itself (which is not > otherwise required in > > all applications). To secure a SIP-layer indication I have all the > > SIP-layer security stuff available. > > I do not understand what you are saying here. If we do not > have a flag, > it does not matter whether or not you secure SIP, nobody will know > anything about the media path. If you have the flag, you have > to secure > SIP. Otherwise you coule leak this information (which I do > not think it > is very sensitive, but anyway)... therefore, the only thing > the addition > of the flag could do is worsen the situation... never improve it. > I meant integrity, not confidentiality. If I want to secure the integrity of the existing 'implicit' indication at the media layer, I need to secure the media, which I might not otherwise need to do. If I want to secure the integrity of a SIP-layer indication, I need to secure SIP, which I am likely to do sooner than securing the media itself in many cases. You basically bring forward the requirement to secure the RTP stream - some people might argue this is a good thing. > > > I am not arguing that these examples alone justify such an > indication, > > but rather that as a general principle this information should be > > signalled explicitly in SIP, not implicitly by the presence > of RTP packets. > > > > I accept that the SIPPING meeting was not convinced that enough > > examples/use-cases had been presented to justify the > indication, and if > > this remains the case then I guess nothing will be agreed. > But as I feel > > these all stem from a more general principle, I think over > time we will > > continue to see more examples emerge. > > I would like to know if the only reason you want such a flag > is because > you "fell" that it is the right thing to do (definitively an > acceptable > position) or if you have a use case where you *actually* need > such a flag. > Well, both. The existance of an H.248 solution takes away one of the 'actual needs' and the Q.SIG/Q.931 case above, though valid, is not of earth-shattering importance, so I guess I am now arguing more from an 'in principle' position. > The only use case I have been able to think of so far is the > saving of a > signalling message from the MGC to the MG in the situation previously > described... but I would like to know if people have more use cases. > > > The only extra use case that people have come up with is the network > scenario where RTP-200 OK race conditions are not considered > important. > That is, they are ignored. In that case, signalling will drive the MG. > > People working with that type of network have already what they want: > the SDP direction attribute. Therefore, if that is the requirement > people are after, it is already solved. They have their flag > *already*. > Well, no, because a normal SIP UAS which does not generate early media will not set the media stream to 'inactive' to indicate this. > And if people are thinking of another scenario(s), please speak up. > > Thanks, > > Gonzalo > > ------_=_NextPart_001_01C2FA96.231E2CF6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] Early media; a summary after the IETF

Hi Gonzalo,

Responses inline...

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: 04 April 2003 10:37
> To: Watson, Mark [MOP:EP10:EXCH]
> Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; = sipping@ietf.org; Jon Peterson
> Subject: Re: [Sipping] Early media; a summary = after the IETF
>
>
> Mark,
>
> > My other point, which seems not to have = been captured in Gonzalo's
> > slides (although I don't know if it was = discussed at the
> meeting), was
> > that as a general principle, the status of = the media stream
> should be
> > visible at the signalling layer. This is = the case in all the other
> > call/session control protocols that I know = of.
>
> I do not buy the argument "since others = did it, let's do it".

That's not my argument. My argument is that looking = at the architecture of the system and what is appropriate to each = layer, I think that this kind of functional indication is appropriate = to the signalling layer, not the media layer. I just point out that = other similar systems have come to the same conclusion.

I'm happy to consider any achitectural arguments you = have to the contrary, but noone has presented any yet.

> I'd rather
> analyze if what they did is applicable or not = to our
> particular problem.
> More inline.
>
> > The current status of SIP seems to be that = whether there is media
> > present or not is indicated only at the = RTP layer, by the physical
> > presence or otherwise of RTP = packets.
>
> We have already discussed this in the past. In = the first
> version of the
> draft, I discussed that SDP provided only the = status of the
> media tools
> at the end points (i.e., the media tools are on = and off). I
> proposed to
> enhance this indications to convery situations = like "media
> tool on, but
> I will not be sending media for the time = being". after
> analyzing it, we
> all agreed that more granularity was not = needed.
>

I am not sure that the principle was addressed in = that debate, just that the particular proposal of using SDP status = values for this was not agreed.

> > This creates the problem that deliberate = absence of media is
> > indistinguishable at the UAC from an error = case in which
> media has been
> > blocked due to some network issue/NAT = problem etc. At the
> very least
> > this makes debugging more = difficult.
>
> You have RTCP. The sending side will always = know whether there is an
> error. What you are proposing does not actually = help debugging. Let's
> say my SIP phone sends you a signalling message = saying "I will be
> sending media", but I remain silent in = front of my
> microphone... now you
> will think that there is an error in the = network, when everything is
> perfectly normal.

Well, RTCP is optional. The fact that there may not = be RTP packets when in fact the sender is intending to send media (it = just happens to be silent) surely argues that using the = presence/absence of RTP to indicate the media status is even more = unreliable!

>
> > In addition, since this is the principle = which has been
> adopted by so
> > many other call/session control protocols, = then a gateway
> interworking
> > from one of these to SIP will not have the = information necessary to
> > simply map to indications in appropriate = backwards
> signalling messages.
> > For example in mapping a SIP 180 to a = Q.SIG or Q.931 ALERTING, I am
> > forced to always provide in-band media = (ringtone or media
> received from
> > the UAS) and indicate this in the = ALERTING/Q.931, whereas
> if I had an
> > indication at the SIP layer I could take = advantage of this
> to indicate
> > no in-band media in the ALERTING (in some = cases) and save
> myself on tone
> > generation.
>
> As far as I know, Q.931 lets you send ALERTING = with no
> indication, but I
> do not know any example where the network uses = this message. Where is
> this used?
>

You can probably get a clearer example from Q.SIG, = but at least in Q.931 the ALERTING will be sent with no Progress = Indicator #1 or #8 in the case of an end-to-end ISDN call (which can = still be speech or 3.1kHz audio). This means there is no in-band media = & the user will not be connected to the backwards media path. See = Q.931 5.1.2 & Q.699. According to Q.699 this can even happen on an = ISDN to non-ISDN call, though I'm not sure I believe this is = used.

If I have no early media on the SIP side & the = call is from an ISDN terminal then I could send an ALERTING with no = in-band media. But only if I *know* there will be no in-band media. I = guess on receipt of some RTP I can send a PROGRESS with PI#8, but this = is my point about mixing layers.

> In any event, you will have the RTP-200 OK race = condition.
> Therefore, if
> you do what you are saying (ALERTING + no = indication), you will have
> media clipping.
>

Yes, but also I think there are scenarios in which = policy dictates that there should be no backwards media allowed before = answer (e.g. when the UAS is 'untrusted' in some sense), answer being = the point at which the caller is willing to start paying. You have to = live with (or mitigate) clipping in these cases anyway.

> > Finally, if I want to secure the implicit = indication of
> media then I
> > need to secure the RTP stream itself = (which is not
> otherwise required in
> > all applications). To secure a SIP-layer = indication I have all the
> > SIP-layer security stuff available.
>
> I do not understand what you are saying here. = If we do not
> have a flag,
> it does not matter whether or not you secure = SIP, nobody will know
> anything about the media path. If you have the = flag, you have
> to secure
> SIP. Otherwise you coule leak this information = (which I do
> not think it
> is very sensitive, but anyway)... therefore, = the only thing
> the addition
> of the flag could do is worsen the situation... = never improve it.
>

I meant integrity, not confidentiality. If I want to = secure the integrity of the existing 'implicit' indication at the media = layer, I need to secure the media, which I might not otherwise need to = do. If I want to secure the integrity of a SIP-layer indication, I need = to secure SIP, which I am likely to do sooner than securing the media = itself in many cases. You basically bring forward the requirement to = secure the RTP stream - some people might argue this is a good = thing.

>
> > I am not arguing that these examples alone = justify such an
> indication,
> > but rather that as a general principle = this information should be
> > signalled explicitly in SIP, not = implicitly by the presence
> of RTP packets.
> >
> > I accept that the SIPPING meeting was not = convinced that enough
> > examples/use-cases had been presented to = justify the
> indication, and if
> > this remains the case then I guess nothing = will be agreed.
> But as I feel
> > these all stem from a more general = principle, I think over
> time we will
> > continue to see more examples = emerge.
>
> I would like to know if the only reason you = want such a flag
> is because
> you "fell" that it is the right thing = to do (definitively an
> acceptable
> position) or if you have a use case where you = *actually* need
> such a flag.
>

Well, both. The existance of an H.248 solution takes = away one of the 'actual needs' and the Q.SIG/Q.931 case above, though = valid, is not of earth-shattering importance, so I guess I am now = arguing more from an 'in principle' position.

> The only use case I have been able to think of = so far is the
> saving of a
> signalling message from the MGC to the MG in = the situation previously
> described... but I would like to know if people = have more use cases.
>
>
> The only extra use case that people have come = up with is the network
> scenario where RTP-200 OK race conditions are = not considered
> important.
> That is, they are ignored. In that case, = signalling will drive the MG.
>
> People working with that type of network have = already what they want:
> the SDP direction attribute. Therefore, if that = is the requirement
> people are after, it is already solved. They = have their flag
> *already*.
>

Well, no, because a normal SIP UAS which does not = generate early media will not set the media stream to 'inactive' to = indicate this.

> And if people are thinking of another = scenario(s), please speak up.
>
> Thanks,
>
> Gonzalo
>
>

------_=_NextPart_001_01C2FA96.231E2CF6-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 07:01:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17525 for ; Fri, 4 Apr 2003 07:01:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34C4LL08639 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 07:04:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34C4LK08636 for ; Fri, 4 Apr 2003 07:04:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17522 for ; Fri, 4 Apr 2003 07:01:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34C0KK08334; Fri, 4 Apr 2003 07:00:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34BxDK08004 for ; Fri, 4 Apr 2003 06:59:13 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17216 for ; Fri, 4 Apr 2003 06:55:48 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h34BwHRs014753; Fri, 4 Apr 2003 13:58:17 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A40HP0M; Fri, 4 Apr 2003 13:58:18 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h34BwIAv017118; Fri, 4 Apr 2003 14:58:18 +0300 (EET DST) Message-ID: <3E8D7357.4020308@lmf.ericsson.se> Date: Fri, 04 Apr 2003 14:58:15 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Watson CC: Tom-PT Taylor , sipping@ietf.org, Jon Peterson References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Early media; philosophical discussion Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Mark, Mark wrote: > so I guess I am now arguing more from an > 'in principle' position. Good. Given that there are no use cases, let's discuss "philosophically" in which layer the presence or absence of media should be signalled; signalling or media level. The discussion could be formulated as follows: At the signalling level (SIP/SDP), we already have the SDP direction attributes, that tell the status (on/off) of the media tools. When the media tools are on (e.g., sendrecv stream), we do not know whether there really is media flowing between both ends. Should we detect the presence of media on the media layer (RTP) or signal it on the signalling layer (SIP)? I claim that we do not need further information (in addition to on/off) in the signalling layer. My initial arguments are: o When the signalling layer says that there will be media, everything works fine. However, when the signalling layer says that there will NOT be media, it is not reliable. Since the next signalling message saying that media will resume may arrive later than the actual (resumed) media packets, either you perform media detection at the media layer *anyway* or have media clipping. This seems to indicate that the media layer is the proper place to detect presence or absence of media, since half of the time you end up doing it there even with a signalling-layer indication. o The rules of protocol design say that a protocol can be considered good when you cannot get rid of anything else (KISS) as long as the protocol provides the expected functionality. That is, protocol design consists of removing useless features rather than adding them. In our case, we can get rid (by not creating it) of the flag while providing the same level of functionality and requiring a very similar processing power and badwidth consumption. Why would we want to add something that does not bring any visible gain? Cheers, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 07:19:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18893 for ; Fri, 4 Apr 2003 07:19:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34CLsw10416 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 07:21:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34CLlK10413 for ; Fri, 4 Apr 2003 07:21:47 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18846 for ; Fri, 4 Apr 2003 07:18:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34CKbK10352; Fri, 4 Apr 2003 07:20:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34CJmK10263 for ; Fri, 4 Apr 2003 07:19:48 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18643 for ; Fri, 4 Apr 2003 07:16:28 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h34CIvRs021601; Fri, 4 Apr 2003 14:18:57 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A40HW37; Fri, 4 Apr 2003 14:18:58 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h34CIwAv018551; Fri, 4 Apr 2003 15:18:58 +0300 (EET DST) Message-ID: <3E8D782F.4040508@lmf.ericsson.se> Date: Fri, 04 Apr 2003 15:18:55 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David.Rio@alcatel.fr CC: sipping@ietf.org, Eric Burger Subject: Re: [Sipping] Comments on 'early media draft' and 'netann draft' References: <3E894514.8000602@alcatel.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit David, In the SIPPING meeting we in fact said that both drafts had to be aligned. However, after further analysis, we have some to the conclusion that alignment is not needed. The reason is that Eric's draft does not describe how to generate early media. It focuses on how a proxy can instruct a media server to play media (in this case early) using SIP. I commented that way of doing things in a separate note some days ago, by the way. Hope this clarifies things, Gonzalo David.Rio@alcatel.fr wrote: > Hello all > > At present, there are TWO 'concurrent' drafts that are dealing with > early media treatments. > I can hardly understand why there are still 2 drafts ; they shoud be > merged. > Or at least a part of Eric's document should be moved to Gonzalo document. > > - The first from Gonzalo is describing from a general point of view how > early media buffers > should be played ; without considering why those RTP buffers should be > submitted. > It is a good approach I think ; more specially from the point of view of > UAC who do not have > to take care of why it is receiving those RTP buffers. > > There is a major discussion around this draft on what priority should be > given to local ringback > and RTP buffers when 180 message has been received while the distant UAS > is already > streaming RTP buffers. > Several points to consider : > * the 180 message is 'RINGING'. We do not have to change its meaning. It > is the message that > must make the remote UAC to ring. Either by playing tone, either by > showing a popup, ... > We do not have to presume how the user will be alerted. > > * Prority should not be given to incoming early RTP buffers unless > clearly specified by the remote. > It is the default behaviour implemented my most SIP terminals. > SIP and RTP streams are two different links and we have to synchronize > them. An UAS will > receive an INVITE with an offered SDP, send a 180, initiates a RTP > stream using the offered SDP, > prepare the answered SDP and send a 200 response. > => The remote UAC must give priority to local ringback until it is > notify to give other priorities (200, 183,...). > > The 183 message is clearly available 'to convey information about the > progress of the call that is not > otherwise classified'. To notify the remote UAC that it should give > priority to early RTP buffers we > have to override default behaviour by sending a 183 message. Here, the > content of this message > could be discussed but probably we should use the content of the SDP to > change priorities > maybe using 'sendonly', 'recvonly' parameters... > If the remote terminal supports it, of course a PrAck message should be > asked. > > Except this discussion point, I approve this document. > > > - The second draft is from Eric. He is focusing on a specific use case. > Eric is describing how a proxy or a b2b application server should > forward an > INVITE to a media server, adding some parameters to ask him to run media > treatments. Such media treatments could be played before call establishment > or after. > The proxy approach is so easy to implement that is why I think it must > be supported > by the solution. > But when you will want to extend this mechanism to make your media > server to report > DTMF interactivity for example, the application server will have to be > in b2b mode. > > I approve Eric's document. > But several comments : > > * Parameters that describe the announcement to be played are submitted > as request URI > private parameters. The behaviour of SIP proxies whith those parameters > is not clear : > some of them forward those parameters ; others remove them (e.g. SER). A > clear position from the > WG is needed. If the proxy should not forward them, then those > parameters should be submitted > somewhere else. > > * 487 code. There is really a need for a such call flow : early media > treatment and hang up by > a media server without sending 200 OK. It is a normal scenario and in > now way an existing > ERROR code should be submitted to the UAC. Then, we have to provide a > solution. > The 487 code seemed a good solution but RFC 3261 says that it should be > used only after > a BYE or CANCEL request. Then it should be extended maybe but what about > existing B2B proxies > and SIP terminals ? > On the other hand, Eric reported that 'we do not want to break > meaningful forking proxies' ; I > agree with this position. > => We have to find a concensus on this open point. > > > - I made some quick tests of early media with two very used SIP > softphone : eStara and Ubiquity. > None support PrAck message. > > * eStara can play early media without problem. It can receive a 183 > message with a SDP. > Then it plays the incoming RTP buffers. > But (of course) it does not support the 487 response and does not detect > the call has been > hang up. This illustrate the problem raised earlier of the support of > the 487 message in this > state of existing equipments state machine. > > * Ubiquity does not support at all early media. Impossible to make it > playing early RTP buffers. > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 07:28:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19530 for ; Fri, 4 Apr 2003 07:28:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34CVB410853 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 07:31:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34CVAK10849 for ; Fri, 4 Apr 2003 07:31:10 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19497 for ; Fri, 4 Apr 2003 07:27:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34CUBK10790; Fri, 4 Apr 2003 07:30:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34CTIK10724 for ; Fri, 4 Apr 2003 07:29:18 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19353 for ; Fri, 4 Apr 2003 07:26:00 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h34CSVI3025055; Fri, 4 Apr 2003 14:28:31 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A40HZHL; Fri, 4 Apr 2003 14:28:31 +0200 Received: from lmf.ericsson.se ([131.160.31.93]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h34CSWAv019075; Fri, 4 Apr 2003 15:28:32 +0300 (EET DST) Message-ID: <3E8D7A75.2E680279@lmf.ericsson.se> Date: Fri, 04 Apr 2003 15:28:37 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Mark Watson , Tom-PT Taylor , sipping@ietf.org, Jon Peterson Subject: Re: [Sipping] Early media; philosophical discussion References: <3E8D7357.4020308@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > Mark wrote: > > so I guess I am now arguing more from an > > 'in principle' position. > > Good. Given that there are no use cases, let's discuss "philosophically" > in which layer the presence or absence of media should be signalled; > signalling or media level. > > The discussion could be formulated as follows: > > At the signalling level (SIP/SDP), we already have the SDP direction > attributes, that tell the status (on/off) of the media tools. When the > media tools are on (e.g., sendrecv stream), we do not know whether there > really is media flowing between both ends. Should we detect the presence > of media on the media layer (RTP) or signal it on the signalling layer > (SIP)? > > I claim that we do not need further information (in addition to on/off) > in the signalling layer. In this case I think my arguement that we should establish an early dialog before we are required to accept (at least before we are required to play) any media is even stronger. If we receive an answer, with the direction set to eg "sendrecv", we KNOW that node MAY send early media. But, we don't know anything about the remote node (we don't even know who it is) at the moment we send the INVITE, and there are reasons we don't want to be required to play media received from who know where. I know it was said that receiving and playing media are two separate issues, and that 3261 basically only requires us to only receive media (Gonzalo confirmed that in another mail, I think), but my point is that it would give nodes a reason to send their SDP as soon as possible - at least if they intend to send early media, but also if they don't intend to (to avoid media clipping if they send the remote SDP together with 200 OK). At the previous SIPit I had some talks with Rohan about the sending of SDP. 3261 currently says that if there is no SDP in the INVITE, one MUST be sent in the first reliable response. However, IF there is a SDP in the INVITE, there is currently no requirement when the answer SDP shall be sent - as long as it is sent before, or together with, the 200 OK. Now, there are cases where a UAS eg simply can't send an SDP in the first reliable provisional response, which it is required to do if there was no SDP in the INVITE. So, instead of having these MUSTs I think it would be much better to say that "a UAS should send its SDP as soon as possible". Of course we still have the issue related to forking, media mixing etc, but I don't think we can solve that (I really don't like the idea of sending lots of pre-session UPDATEs, because that will cause other kind of race conditions), but if we recommend SIP nodes to not send early media (PSTN gateways will of course often do it) in the first place that may not be a really big problem in real-life networks. Regards, Christer Holmberg Ericsson Finland > My initial arguments are: > > o When the signalling layer says that there will be media, everything > works fine. However, when the signalling layer says that there will NOT > be media, it is not reliable. Since the next signalling message saying > that media will resume may arrive later than the actual (resumed) media > packets, either you perform media detection at the media layer *anyway* > or have media clipping. This seems to indicate that the media layer is > the proper place to detect presence or absence of media, since half of > the time you end up doing it there even with a signalling-layer indication. > > o The rules of protocol design say that a protocol can be considered > good when you cannot get rid of anything else (KISS) as long as the > protocol provides the expected functionality. That is, protocol design > consists of removing useless features rather than adding them. In our > case, we can get rid (by not creating it) of the flag while providing > the same level of functionality and requiring a very similar processing > power and badwidth consumption. Why would we want to add something that > does not bring any visible gain? > > Cheers, > > Gonzalo > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 07:58:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20531 for ; Fri, 4 Apr 2003 07:58:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34D14D13046 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 08:01:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34D14K13043 for ; Fri, 4 Apr 2003 08:01:04 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20483 for ; Fri, 4 Apr 2003 07:57:46 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34D06K12900; Fri, 4 Apr 2003 08:00:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Cw0K12746 for ; Fri, 4 Apr 2003 07:58:00 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20363 for ; Fri, 4 Apr 2003 07:54:43 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h34CvCRs003863; Fri, 4 Apr 2003 14:57:12 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4SB867; Fri, 4 Apr 2003 14:57:12 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h34CvCAv020864; Fri, 4 Apr 2003 15:57:12 +0300 (EET DST) Message-ID: <3E8D8125.10801@lmf.ericsson.se> Date: Fri, 04 Apr 2003 15:57:09 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: Mark Watson , Tom-PT Taylor , sipping@ietf.org, Jon Peterson Subject: Re: [Sipping] Early media; philosophical discussion References: <3E8D7357.4020308@lmf.ericsson.se> <3E8D7A75.2E680279@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christer, if you need to get the remote SDP before acepting any media, you should use preconditions. You can define a new precondition type and use the framework defined in RFC 3312. If you do not use preconditions, the UAS is free to send a 200 OK without any previous provisional response, as you know. In any event, the draft says that systems sending early media using the gateway model send a provisional response with the SDP. If you want to make that recommendation even more explicit, let me know. Anyway, this is not very much related to the "in-principle" discussion at hand. Gonzalo Christer Holmberg wrote: > Hi, > > >>Mark wrote: >> > so I guess I am now arguing more from an >> > 'in principle' position. >> >>Good. Given that there are no use cases, let's discuss "philosophically" >>in which layer the presence or absence of media should be signalled; >>signalling or media level. >> >>The discussion could be formulated as follows: >> >>At the signalling level (SIP/SDP), we already have the SDP direction >>attributes, that tell the status (on/off) of the media tools. When the >>media tools are on (e.g., sendrecv stream), we do not know whether there >>really is media flowing between both ends. Should we detect the presence >>of media on the media layer (RTP) or signal it on the signalling layer >>(SIP)? >> >>I claim that we do not need further information (in addition to on/off) >>in the signalling layer. > > > In this case I think my arguement that we should establish an early dialog > before we are required to accept (at least before we are required to play) any > media is even stronger. If we receive an answer, with the direction set to eg > "sendrecv", we KNOW that node MAY send early media. But, we don't know anything > about the remote node (we don't even know who it is) at the moment we send the > INVITE, and there are reasons we don't want to be required to play media > received from who know where. > > I know it was said that receiving and playing media are two separate issues, > and that 3261 basically only requires us to only receive media (Gonzalo > confirmed that in another mail, I think), but my point is that it would give > nodes a reason to send their SDP as soon as possible - at least if they intend > to send early media, but also if they don't intend to (to avoid media clipping > if they send the remote SDP together with 200 OK). At the previous SIPit I had > some talks with Rohan about the sending of SDP. 3261 currently says that if > there is no SDP in the INVITE, one MUST be sent in the first reliable response. > However, IF there is a SDP in the INVITE, there is currently no requirement > when the answer SDP shall be sent - as long as it is sent before, or together > with, the 200 OK. Now, there are cases where a UAS eg simply can't send an SDP > in the first reliable provisional response, which it is required to do if there > was no SDP in the INVITE. So, instead of having these MUSTs I think it would be > much better to say that "a UAS should send its SDP as soon as possible". > > Of course we still have the issue related to forking, media mixing etc, but I > don't think we can solve that (I really don't like the idea of sending lots of > pre-session UPDATEs, because that will cause other kind of race conditions), > but if we recommend SIP nodes to not send early media (PSTN gateways will of > course often do it) in the first place that may not be a really big problem in > real-life networks. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > >>My initial arguments are: >> >>o When the signalling layer says that there will be media, everything >>works fine. However, when the signalling layer says that there will NOT >>be media, it is not reliable. Since the next signalling message saying >>that media will resume may arrive later than the actual (resumed) media >>packets, either you perform media detection at the media layer *anyway* >>or have media clipping. This seems to indicate that the media layer is >>the proper place to detect presence or absence of media, since half of >>the time you end up doing it there even with a signalling-layer indication. >> >>o The rules of protocol design say that a protocol can be considered >>good when you cannot get rid of anything else (KISS) as long as the >>protocol provides the expected functionality. That is, protocol design >>consists of removing useless features rather than adding them. In our >>case, we can get rid (by not creating it) of the flag while providing >>the same level of functionality and requiring a very similar processing >>power and badwidth consumption. Why would we want to add something that >>does not bring any visible gain? >> >>Cheers, >> >>Gonzalo >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 08:06:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20873 for ; Fri, 4 Apr 2003 08:06:28 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34D9DD14290 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 08:09:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34D9DK14287 for ; Fri, 4 Apr 2003 08:09:13 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20868 for ; Fri, 4 Apr 2003 08:05:56 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34D8EK14198; Fri, 4 Apr 2003 08:08:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34D5UK13354 for ; Fri, 4 Apr 2003 08:05:30 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20800 for ; Fri, 4 Apr 2003 08:02:14 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h34D4gRs006093; Fri, 4 Apr 2003 15:04:42 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A472NX1; Fri, 4 Apr 2003 15:04:43 +0200 Received: from lmf.ericsson.se ([131.160.31.93]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h34D4hAv021263; Fri, 4 Apr 2003 16:04:43 +0300 (EET DST) Message-ID: <3E8D82F0.A3FDADD1@lmf.ericsson.se> Date: Fri, 04 Apr 2003 16:04:48 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Mark Watson , Tom-PT Taylor , sipping@ietf.org, Jon Peterson Subject: Re: [Sipping] Early media; philosophical discussion References: <3E8D7357.4020308@lmf.ericsson.se> <3E8D7A75.2E680279@lmf.ericsson.se> <3E8D8125.10801@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > if you need to get the remote SDP before acepting any media, you should > use preconditions. You can define a new precondition type and use the > framework defined in RFC 3312. So, the "on/off" thing is only from a UAC point of view? > If you do not use preconditions, the UAS is free to send a 200 OK > without any previous provisional response, as you know. Of course. I was only talking about recommendations (and, from my experience I would say that most terminals mostly do send one or more 18x responses). > In any event, the draft says that systems sending early media using the > gateway model send a provisional response with the SDP. If you want to > make that recommendation even more explicit, let me know. Well, it's so not about which model is used (the UAS probably doesn't know which model the UAC uses, anyway), but more general SIP behaviour recommendation. > Anyway, this is not very much related to the "in-principle" discussion > at hand. Sorry :) I should have put it in a separate mail, but since it was related to the "on/off" issue (at least I though so) I decided to put it in the same mail. Regards, Christer Holmberg Ericsson Finland > > > Gonzalo > > Christer Holmberg wrote: > > Hi, > > > > > >>Mark wrote: > >> > so I guess I am now arguing more from an > >> > 'in principle' position. > >> > >>Good. Given that there are no use cases, let's discuss "philosophically" > >>in which layer the presence or absence of media should be signalled; > >>signalling or media level. > >> > >>The discussion could be formulated as follows: > >> > >>At the signalling level (SIP/SDP), we already have the SDP direction > >>attributes, that tell the status (on/off) of the media tools. When the > >>media tools are on (e.g., sendrecv stream), we do not know whether there > >>really is media flowing between both ends. Should we detect the presence > >>of media on the media layer (RTP) or signal it on the signalling layer > >>(SIP)? > >> > >>I claim that we do not need further information (in addition to on/off) > >>in the signalling layer. > > > > > > In this case I think my arguement that we should establish an early dialog > > before we are required to accept (at least before we are required to play) any > > media is even stronger. If we receive an answer, with the direction set to eg > > "sendrecv", we KNOW that node MAY send early media. But, we don't know anything > > about the remote node (we don't even know who it is) at the moment we send the > > INVITE, and there are reasons we don't want to be required to play media > > received from who know where. > > > > I know it was said that receiving and playing media are two separate issues, > > and that 3261 basically only requires us to only receive media (Gonzalo > > confirmed that in another mail, I think), but my point is that it would give > > nodes a reason to send their SDP as soon as possible - at least if they intend > > to send early media, but also if they don't intend to (to avoid media clipping > > if they send the remote SDP together with 200 OK). At the previous SIPit I had > > some talks with Rohan about the sending of SDP. 3261 currently says that if > > there is no SDP in the INVITE, one MUST be sent in the first reliable response. > > However, IF there is a SDP in the INVITE, there is currently no requirement > > when the answer SDP shall be sent - as long as it is sent before, or together > > with, the 200 OK. Now, there are cases where a UAS eg simply can't send an SDP > > in the first reliable provisional response, which it is required to do if there > > was no SDP in the INVITE. So, instead of having these MUSTs I think it would be > > much better to say that "a UAS should send its SDP as soon as possible". > > > > Of course we still have the issue related to forking, media mixing etc, but I > > don't think we can solve that (I really don't like the idea of sending lots of > > pre-session UPDATEs, because that will cause other kind of race conditions), > > but if we recommend SIP nodes to not send early media (PSTN gateways will of > > course often do it) in the first place that may not be a really big problem in > > real-life networks. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > > > > > > >>My initial arguments are: > >> > >>o When the signalling layer says that there will be media, everything > >>works fine. However, when the signalling layer says that there will NOT > >>be media, it is not reliable. Since the next signalling message saying > >>that media will resume may arrive later than the actual (resumed) media > >>packets, either you perform media detection at the media layer *anyway* > >>or have media clipping. This seems to indicate that the media layer is > >>the proper place to detect presence or absence of media, since half of > >>the time you end up doing it there even with a signalling-layer indication. > >> > >>o The rules of protocol design say that a protocol can be considered > >>good when you cannot get rid of anything else (KISS) as long as the > >>protocol provides the expected functionality. That is, protocol design > >>consists of removing useless features rather than adding them. In our > >>case, we can get rid (by not creating it) of the flag while providing > >>the same level of functionality and requiring a very similar processing > >>power and badwidth consumption. Why would we want to add something that > >>does not bring any visible gain? > >> > >>Cheers, > >> > >>Gonzalo > >> > >>_______________________________________________ > >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >>This list is for NEW development of the application of SIP > >>Use sip-implementors@cs.columbia.edu for questions on current sip > >>Use sip@ietf.org for new developments of core SIP > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 09:00:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22098 for ; Fri, 4 Apr 2003 09:00:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34E38P17488 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 09:03:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34E37K17485 for ; Fri, 4 Apr 2003 09:03:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22073 for ; Fri, 4 Apr 2003 08:59:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34E1JK17322; Fri, 4 Apr 2003 09:01:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34E0PK17274 for ; Fri, 4 Apr 2003 09:00:25 -0500 Received: from znsgs01r.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22018 for ; Fri, 4 Apr 2003 08:57:06 -0500 (EST) Received: from znsgy0k8.europe.nortel.com (europem01.nt.com [47.165.24.67]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34DxV328107; Fri, 4 Apr 2003 14:59:31 +0100 (BST) Received: from zwcwc012.europe.nortel.com ([47.160.46.124]) by znsgy0k8.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HG1MN1RK; Fri, 4 Apr 2003 14:59:31 +0100 Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Apr 2003 14:58:23 +0100 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: "'Gonzalo Camarillo'" Cc: "Tom-PT Taylor" , sipping@ietf.org, Jon Peterson Subject: RE: [Sipping] Early media; philosophical discussion Date: Fri, 4 Apr 2003 14:58:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FAB2.3F7DF13A" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FAB2.3F7DF13A Content-Type: text/plain; charset="iso-8859-1" Gonzalo, Inline... Gonzalo wrote: > Hi Mark, > > Mark wrote: > > so I guess I am now arguing more from an > > 'in principle' position. > > Good. Given that there are no use cases, let's discuss > "philosophically" > in which layer the presence or absence of media should be signalled; > signalling or media level. > I did not say there were no use cases. You're selectively quoting me. Nice try though :-) I'll admit that the use-case I described (Q.SIG/Q.931 interworking) might not be sufficiently important on its own to motivate this indication - that doesn't mean there are no use-cases. But I believe the principle should lead us to expect more use-cases to be identified in future. > The discussion could be formulated as follows: > > At the signalling level (SIP/SDP), we already have the SDP direction > attributes, that tell the status (on/off) of the media tools. > When the > media tools are on (e.g., sendrecv stream), we do not know > whether there > really is media flowing between both ends. Should we detect > the presence > of media on the media layer (RTP) or signal it on the > signalling layer > (SIP)? > Well, perhaps we *are* repeating the discussion on sendrecv/inactive. I must say it is not entirely clear to me what it means for a stream to be in sendrecv mode but for there to be no media being sent i.e. there is no implementation-independent definition of what these 'media tools' are and what it means for them to be 'on' or 'off'. We can only presume that 'on' means that the device is in some sense 'ready' to send or receive. But what does it mean to the UAC that the UAS is 'ready' to send media ? How is this different for the UAC from the state where the UAS is 'not ready' to send media ? What is important is whether media is actually being sent - this information is not available at the signalling layer. > I claim that we do not need further information (in addition > to on/off) > in the signalling layer. My initial arguments are: > > o When the signalling layer says that there will be media, everything > works fine. However, when the signalling layer says that > there will NOT > be media, it is not reliable. Since the next signalling > message saying > that media will resume may arrive later than the actual > (resumed) media > packets, either you perform media detection at the media > layer *anyway* > or have media clipping. This seems to indicate that the media > layer is > the proper place to detect presence or absence of media, > since half of > the time you end up doing it there even with a > signalling-layer indication. > This is not an architectural argument, but a treatment of the specific issue of media clipping. Your description makes assumptions which, conveniently, lead to the conclusion that the indication is not needed. For example the assumption that local policy allows media to be played indepedently of the session state. This assumption is not fundamental to SIP - I think whether media should be played or not at any given time is a local issue for the UA. > o The rules of protocol design say that a protocol can be considered > good when you cannot get rid of anything else (KISS) as long as the > protocol provides the expected functionality. That is, > protocol design > consists of removing useless features rather than adding them. In our > case, we can get rid (by not creating it) of the flag while providing > the same level of functionality and requiring a very similar > processing > power and badwidth consumption. Why would we want to add > something that > does not bring any visible gain? > Well, obviously, if I thought there was no gain at all I wouldn't be advocating it. I'm not just trying to waste everyone's time. I agree that this indication is available at the media layer in the form of RTP packet arrival (btw, we are assuming it will be available at the media layer in all cases, whereas SIP is supposed to be agnostic about what the media layer, described by the SDP, is/does - I'm not saying I have an example in which this indication is not available, but it is not inconceivable that there could be no difference at the media layer between "no media being sent" and "media being sent, but happens to be 'silent'" in some sense - 'silent' could mean many things in the context of media other than voice/audio). All you've argued above is that 'this is available at the media layer and so would be redundant if added to the signalling layer as well', but this is only true with some assumptions about the communication available between media and signalling layers and assumptions that the communication at media and signalling layers have similar properties in terms of security, reliability etc. ...Mark > Cheers, > > Gonzalo > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > ------_=_NextPart_001_01C2FAB2.3F7DF13A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] Early media; philosophical discussion

Gonzalo,

Inline...

Gonzalo wrote:
> Hi Mark,
>
> Mark wrote:
>  > so I guess I am now arguing more = from an
>  > 'in principle' position.
>
> Good. Given that there are no use cases, let's = discuss
> "philosophically"
> in which layer the presence or absence of media = should be signalled;
> signalling or media level.
>

I did not say there were no use cases. You're = selectively quoting me. Nice try though :-)

I'll admit that the use-case I described (Q.SIG/Q.931 = interworking) might not be sufficiently important on its own to = motivate this indication - that doesn't mean there are no use-cases. = But I believe the principle should lead us to expect more use-cases to = be identified in future.

> The discussion could be formulated as = follows:
>
> At the signalling level (SIP/SDP), we already = have the SDP direction
> attributes, that tell the status (on/off) of = the media tools.
> When the
> media tools are on (e.g., sendrecv stream), we = do not know
> whether there
> really is media flowing between both ends. = Should we detect
> the presence
> of media on the media layer (RTP) or signal it = on the
> signalling layer
> (SIP)?
>

Well, perhaps we *are* repeating the discussion on = sendrecv/inactive. I must say it is not entirely clear to me what it = means for a stream to be in sendrecv mode but for there to be no media = being sent i.e. there is no implementation-independent definition of = what these 'media tools' are and what it means for them to be 'on' or = 'off'. We can only presume that 'on' means that the device is in some = sense 'ready' to send or receive. But what does it mean to the UAC that = the UAS is 'ready' to send media ? How is this different for the UAC = from the state where the UAS is 'not ready' to send media ?

What is important is whether media is actually being = sent - this information is not available at the signalling = layer.


> I claim that we do not need further information = (in addition
> to on/off)
> in the signalling layer. My initial arguments = are:
>
> o When the signalling layer says that there = will be media, everything
> works fine. However, when the signalling layer = says that
> there will NOT
> be media, it is not reliable. Since the next = signalling
> message saying
> that media will resume may arrive later than = the actual
> (resumed) media
> packets, either you perform media detection at = the media
> layer *anyway*
> or have media clipping. This seems to indicate = that the media
> layer is
> the proper place to detect presence or absence = of media,
> since half of
> the time you end up doing it there even with a =
> signalling-layer indication.
>

This is not an architectural argument, but a = treatment of the specific issue of media clipping. Your description = makes assumptions which, conveniently, lead to the conclusion that the = indication is not needed. For example the assumption that local policy = allows media to be played indepedently of the session state. This = assumption is not fundamental to SIP - I think whether media should be = played or not at any given time is a local issue for the UA.

> o The rules of protocol design say that a = protocol can be considered
> good when you cannot get rid of anything else = (KISS) as long as the
> protocol provides the expected functionality. = That is,
> protocol design
> consists of removing useless features rather = than adding them. In our
> case, we can get rid (by not creating it) of = the flag while providing
> the same level of functionality and requiring a = very similar
> processing
> power and badwidth consumption. Why would we = want to add
> something that
> does not bring any visible gain?
>

Well, obviously, if I thought there was no gain at = all I wouldn't be advocating it. I'm not just trying to waste = everyone's time.

I agree that this indication is available at the = media layer in the form of RTP packet arrival (btw, we are assuming it = will be available at the media layer in all cases, whereas SIP is = supposed to be agnostic about what the media layer, described by the = SDP, is/does - I'm not saying I have an example in which this = indication is not available, but it is not inconceivable that there = could be no difference at the media layer between "no media being = sent" and "media being sent, but happens to be 'silent'" = in some sense - 'silent' could mean many things in the context of media = other than voice/audio).

All you've argued above is that 'this is available at = the media layer and so would be redundant if added to the signalling = layer as well', but this is only true with some assumptions about the = communication available between media and signalling layers and = assumptions that the communication at media and signalling layers have = similar properties in terms of security, reliability etc.

...Mark


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

------_=_NextPart_001_01C2FAB2.3F7DF13A-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 12:18:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29811 for ; Fri, 4 Apr 2003 12:18:21 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34HLCF00857 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 12:21:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34HLC800854 for ; Fri, 4 Apr 2003 12:21:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29790 for ; Fri, 4 Apr 2003 12:17:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34HKN800806; Fri, 4 Apr 2003 12:20:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34HHM800609 for ; Fri, 4 Apr 2003 12:17:22 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29692 for ; Fri, 4 Apr 2003 12:14:00 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34HGOv20720; Fri, 4 Apr 2003 11:16:24 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2FGBWWG6>; Fri, 4 Apr 2003 09:16:23 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D207A0491D@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Gonzalo Camarillo'" , "Mark Watson" Cc: "Tom-PT Taylor" , "'sipping@ietf.org'" , "'Jon Peterson'" Subject: RE: [Sipping] Early media; a summary after the IETF Date: Fri, 4 Apr 2003 09:16:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FACD.EAE928C6" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FACD.EAE928C6 Content-Type: text/plain > As far as I know, Q.931 lets you send ALERTING with no > indication, but I > do not know any example where the network uses this message. Where is > this used? ALERTING with no indication means that there is no in-band alerting. ALERTING with Progress indicator 1 or 8 means that there is in-band tones. Of course you CAN override it with locally generated tones if you want. If you provide in-band tones, you have to included the progress indicator. ------_=_NextPart_001_01C2FACD.EAE928C6 Content-Type: text/html RE: [Sipping] Early media; a summary after the IETF

> As far as I know, Q.931 lets you send ALERTING with no
> indication, but I
> do not know any example where the network uses this message. Where is
> this used?

ALERTING with no indication means that there is no in-band alerting.

ALERTING with Progress indicator 1 or 8 means that there is in-band tones.
Of course you CAN override it with locally generated tones if you want. If
you provide in-band tones, you have to included the progress indicator.

------_=_NextPart_001_01C2FACD.EAE928C6-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 12:37:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00519 for ; Fri, 4 Apr 2003 12:37:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34He0C02683 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 12:40:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34He0802680 for ; Fri, 4 Apr 2003 12:40:00 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00505 for ; Fri, 4 Apr 2003 12:36:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34HdB802617; Fri, 4 Apr 2003 12:39:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Han801755 for ; Fri, 4 Apr 2003 12:36:49 -0500 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00397 for ; Fri, 4 Apr 2003 12:33:26 -0500 (EST) Received: from cia.cisco.com (IDENT:mirapoint@cia.cisco.com [161.44.85.200]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h34HZrdo026287; Fri, 4 Apr 2003 12:35:54 -0500 (EST) Received: from mhammer-w2k02.cisco.com (dhcp-64-100-224-237.cisco.com [64.100.224.237]) by cia.cisco.com (Mirapoint) with ESMTP id ABT70154; Fri, 4 Apr 2003 12:25:54 -0500 (EST) Message-Id: <4.3.2.7.2.20030404112904.04849988@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 04 Apr 2003 12:35:46 -0500 To: Gonzalo Camarillo From: Michael Hammer Subject: Re: [Sipping] New version of the early media draft Cc: Francois Audet , Tom-PT Taylor , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" , Mark Watson In-Reply-To: <3E8D203B.3070405@lmf.ericsson.se> References: <2F1FC1DEA077D5119FAD00508BCFD6D20794E863@zsc3c030.us.nortel.com> <4.3.2.7.2.20030403102839.00b44170@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Gonzalo, I had already read this once, but went back and read more closely to be sure. You define what you refer to as the "gateway model", but as near as I can tell, the gateway model is simply the Offer-Answer model. If not, you need to explain what the difference is. Section 2 does an excellent job of describing the various problems. From pp. 7-8: The gateway model is, therefore, acceptable in situations where the UA cannot distinguish between early media and regular media. A PSTN gateway is an example of this type of situation. The PSTN gateway receives media from the PSTN over a circuit, and sends it to the IP network. The gateway is not aware of the contents of the media, and it does not exactly know when the transition from early to regular media takes place. From the PSTN perspective, the circuit is a continuous source of media. Did you mean to say that the gateway model is NOT acceptable? Let me see if I understand Section 3 correctly: UAC sends INVITE with JOIN URI, which could be forked. UAS (which could be PSTN GW) sends 180 Ringing with SDP Answer. UAS sends INVITE to JOIN URI with SDP Offer. UAS withholds sending RTP on first INVITE early session. UAC receives one or more 180 Ringing with SDP Answer. UAC receives one or more INVITE with SDP Offer. UAC has one or more early sessions, but no RTP streams arriving. UAC may display one or more "ringing" indications. UAC may play locally generated ringing (ringback) tone. UAC may select one JOIN INVITE and respond with 200 OK with SDP Answer. It would also stop playing local ringback. UAC sends 182 Queued to other secondary INVITES. UAS (1) receives 200 OK with SDP Answer and begins sending secondary RTP stream based on TDM stream. UAC plays received RTP on secondary session. UAS (first) generates 200 OK to initial INVITE. Forking proxy CANCELS other primary INVITEs. For UAS already playing secondary media: UAS diverts media from TDM media from secondary session to already established primary session. For UAS not playing secondary media: UAS starts playing out TDM media to primary RTP stream. UAC seeing RTP packets on primary RTP stream switches from any secondary RTP play-out to primary play-out. UAC sends BYE to selected secondary dialog. UAC sends final response code (4XX) to queued secondary dialog requests. UAC receives 200 OK and sends ACK for primary INVITE. Did I miss anything? Now, this solves the media clipping problem and the forking problem, which as you say is equivalent to the case I presented. But, it doesn't solve the missing ringback problem (which may not be a problem for phones with visual displays). If the signaling is quick, the UAC could accept and play the secondary RTP stream containing dead air and suppress local ringback. The only solutions I see so far are: 1) Require GWs to use of silence suppression and require UACs to not use silence suppression RTP to over-ride local ringing tone. 2) The GW or the switch before the GW to be configured to always generate in-band local ringing tone and override any in-band announcements/tones from the destination switch. Editorial nit: Shouldn't 2.1.1 be at the same level as 2.1 and 2.2 as there are three issues to address? (Note there is not 2.1.2) Mike At 09:03 AM 4/4/2003 +0300, Gonzalo Camarillo wrote: >Michael, > >fetch the draft below: >http://www.ietf.org/internet-drafts/draft-camarillo-sipping-early-media-01.txt > >Read Section 2.3; this section explains that the gateway model produces >undesirable results when forking is present. Therefore, you SHOULD NOT use >this model. However, there are some situations when the gateway cannot >distinguish between early and regular media. In that situation, even >knowing that there may be problems if forking occurs, the gateway has no >other choice than using the gateway model. Therefore, even if you had an >indication telling the gateway that the call forked, the gateway DOES NOT >HAVE ANY OTHER CHOICE. > >But what happens if your system does have a choice and can actually >distinguish between early and regular media? Go on and read Section 3. It >provides a mechanism that, if you look at the end result, is equivalent to >yours. Therefore, I assume that you will be happy with that mechanism. > >Why do we use that mechanism (reverse INVITE) instead of your mechanism or >UPDATEs with an extra stream with an "early media" label (documented in >the draft as well)? It is explained in the last pargraph of Section 3. > >" An alternative model would consist of adding a new stream > labeled as "early media" to the original session between > the UAC and the UAS using an UPDATE, instead of > establishing a new session. We have chosen to establish a > new session to be coherent with the mechanism used by > application servers that are NOT co-located with the UAS. > This way, the UAS uses the same mechanism as any other > application server in the network to interact with the UAC." > > >Hope this helps, > >Gonzalo > > > >Michael Hammer wrote: >>Gonzalo, >>Would it be possible to have an early media convention that contains the >>following elements: >>1) the receiving end indicates in signaling that it intends to send early >>media >>2) the receiving end includes SDP in hold state and does not send media >>at first >>3) the caller responds to one receiver's inband indicator (or not) with >>an UPDATE putting that receiver in send state >>4) the receiving end responds to UPDATE and begins sending of RTP with media. >>This resolves the forking case, tells the caller which device intends >>inband media, and allows the caller with possibly user in the loop to >>decide which to listen to. >>See the following: >> A Forking Proxy User User User >> B1 B2 B3 >> | | | | | >> | INVITE F1 | | | | >> |--------------->| | | | >> | 100 Trying F2 | | | | >> |<---------------| INVITE F3 | | | >> | |------------->| | | >> | | INVITE F4 | | >> | |-------------------->| | >> | | INVITE F5 | | >> | |--------------------------->| >> | | 183 inband F6| | | >> | 183 inband F7 |<-------------| | | >> |<---------------| | | | >> | | 183 inband F8| | | >> | 183 inband F9 |<--------------------| | >> |<---------------| | | | >> | UPDATE send F10| | | | >> |--------------->| UPDATE send F11 | | >> | |-------------------->| | >> | | ACK send F12 | | | >> | ACK send F13 |<--------------------| | >> |<---------------| | | | >>Play<=====|<======Early media====================| | >> | | 180 inband F14 | | >> | 180 inband F15 |<---------------------------| >> |<---------------| CANCEL F16 | | | >> | |------------->|media | | >> | | 200 OK F17 |stops | | >> | |<-------------| | | >> | | 487 F18 | | | >> | |<-------------| | | >> | | ACK F19 | | | >> | |------------->| | | >> | UPDATE send F20| | | | >> |--------------->| UPDATE send F21 | | >> | |--------------------------->| >> | | ACK send F22 | | | >> | ACK send F23 |<---------------------------| >> |<---------------| | | | >>Play<=====|<==============="Hello"======================| >> | | 200 OK F24 | >> | 200 OK F25 |<---------------------------| >> |<---------------| | | | >> | ACK send F26 | | | | >> |--------------->| ACK send F27 | | | >> | |--------------------------->| >> | | | | | >>Am I missing anything here? >>The key is to stop guessing and make it more deterministic. >>If you don't like this, don't use the inband indicator, and fall back to >>the current state of problems. >>Mike >> >>At 01:18 PM 4/3/2003 +0300, Gonzalo Camarillo wrote: >> >>>Francois, >>> >>>you are missing the point of the draft. The draft explains what happens >>>when you use early media within the dialog are forking occurs. That is, >>>you have a lot of problems. >>> >>>The aim of the draft is to describe these problems and to describe >>>things that a UAC may do without extending the protocol. We do that >>>because you have to interact with existing UASs that will send you media >>>this way. You cannot upgrade the already installed base. >>> >>>But we do not want to extend the protocol to provide a solution for this >>>gateway model. We recommend that new systems use the application server >>>model. In this model, we will provide solutions and extend the protocol >>>should that be needed. >>> >>>Gonzalo >>> >>>Francois Audet wrote: >>> >>>> > First of all, I do not understand why people continue >>>> > discussing things >>>> > like early media with forking whose problems are already well >>>> > discussed >>>> > and documented in the draft and nobody so far has been able >>>> > to come up >>>> > with a single use case where the proposed flag would be useful... I >>>> > would ask people to focus on the problem in hand (i.e., the >>>> > flag), and >>>> > stop discussing about already resolved issues. >>>>The problem is that the multiple dialog problem and early media problem >>>>(as in forking >>>>for example) has NOT been solved. Worst, using the current unworkable >>>>solution as a basis >>>>to make our decisions on the flag issue will not result in a good solution. >>>>The current solution for forking in the draft is for the UAC to pick a >>>>random media >>>>stream (based on signaling, thus the dialog, not media, because there >>>>is no means to correlate >>>>dialog and media stream) and mute the others by sending UPDATEs to the >>>>far end. This is >>>>not an acceptable solution. Random non-redictable behavior is not >>>>acceptable to end-users. >>>>Furthemore, this is not robust at all because if the called UA does not >>>>support UPDATE, >>>>multiple streams will be received and there will be no way for the UAC >>>>receiving it >>>>to pick the proper one. (If there was a way to correlate an RTP stream >>>>to the dialog that >>>>generate it, it would be easier) >>>>This leaves the client with 3 choices: >>>>1) Pick a random media stream (which it will not be able to correlate >>>>with a specific dialog >>>> unless it is lucky with educated guesses). >>>>2) Mix media streams together. >>>>3) Provide alternative local treatment based on the provisional >>>>responses received. This >>>> could be >>>> >>>>You are right that the flag probably doesn't help with this problem. >>>>I'll leave it >>>>to others to defend the flag idea. >>>>I'm OK with current draft, as long as we do not ADD any more dependency >>>>on the "play >>>>media when you receive it" principle to address the flag prolem, and as >>>>long as we improve >>>>the section on forking. It seems to me that if forking is used we CAN >>>>NOT use early media for >>>>in-band ringing (we could do early media for clipping avoidance). >>>>Perhaps we need a >>>>"forked" indication in INVITE telling the far-end not to send early >>>>media... And to make >>>>it bullet proof a forked indication in the 100 Trying (when forking) to >>>>tell the UAC making the >>>>call that "weird stuff" is going to happen and that proper treatment >>>>should be used not >>>>to confused the user. >>> >>> >>> >>>-- >>>Gonzalo Camarillo Phone : +358 9 299 33 71 >>>Oy L M Ericsson Ab Mobile: +358 40 702 35 35 >>>Telecom R&D Fax : +358 9 299 30 52 >>>FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com >>>Finland http://www.hut.fi/~gonzalo >>> >>>_______________________________________________ >>>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>>This list is for NEW development of the application of SIP >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sip@ietf.org for new developments of core SIP > > >-- >Gonzalo Camarillo Phone : +358 9 299 33 71 >Oy L M Ericsson Ab Mobile: +358 40 702 35 35 >Telecom R&D Fax : +358 9 299 30 52 >FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com >Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 12:40:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00669 for ; Fri, 4 Apr 2003 12:40:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34Hhk802892 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 12:43:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Hhk802889 for ; Fri, 4 Apr 2003 12:43:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00657 for ; Fri, 4 Apr 2003 12:40:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Hh6802859; Fri, 4 Apr 2003 12:43:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Hee802751 for ; Fri, 4 Apr 2003 12:40:40 -0500 Received: from mailgate.siemenscomms.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00541 for ; Fri, 4 Apr 2003 12:37:17 -0500 (EST) Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HCT00401YDJLH@siemenscomms.co.uk> for sipping@ietf.org; Fri, 04 Apr 2003 18:39:19 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HCT0049NYDJDE@siemenscomms.co.uk>; Fri, 04 Apr 2003 18:39:19 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 04 Apr 2003 18:39:47 +0100 Content-return: allowed Date: Fri, 04 Apr 2003 18:40:01 +0100 From: "Elwell, John" Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network To: Francois Audet , "'sipping@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="Boundary_(ID_TCvyD+ZJGYfE4Cy4NQuP2w)" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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. --Boundary_(ID_TCvyD+ZJGYfE4Cy4NQuP2w) Content-type: text/plain Content-Transfer-Encoding: 7BIT Francois, In-line John (john.elwell@siemens.com ) -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: 04 April 2003 02:06 To: 'Elwell, John'; 'sipping@ietf.org' Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com ] > > 5. Send INVITE (new dialog) with Replaces header and Required header (Replaces required). > This would be rejected by a UA that does not support the Replaces header. My take is that this is exactly what the Replaces header was intented to do (it even mentions the attended transfer case). It is up to the transferor to decide if the Required header should be included or not. It it is included, it means that the transferor prefers that the transfer fails than not updating the other party's information. [JRE] The transfer has already taken place in the QSIG network, and therefore there is no way of making it fail. The gateway is just trying to report to the SIP UA the fact that transfer has occurred. The point of the Required header is to prevent the new INVITE being treated as a new call rather than a replacement for the existing call. If not included, it means that it is willing to tolerate the fact that the identity may not be updated (this happens today in traditional PBXs if there is no protocol to update the calling line identity and the call is locally bridged). [JRE] If Required is not included a UA that does not support Replaces will treat the INVITE request as a new dialog and take some undesirable action, e.g., making it wait on busy. Therefore I think Required is essential. --Boundary_(ID_TCvyD+ZJGYfE4Cy4NQuP2w) Content-type: text/html Content-Transfer-Encoding: 7BIT Message
Francois,
 
In-line
 

-----Original Message-----
From: Francois Audet [mailto:audet@nortelnetworks.com]
Sent: 04 April 2003 02:06
To: 'Elwell, John'; 'sipping@ietf.org'
Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network


> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]
>
> 5. Send INVITE (new dialog) with Replaces header and Required header (Replaces required). > This would be rejected by a UA that does not support the Replaces header.

My take is that this is exactly what the Replaces header was intented to do (it even
mentions the attended transfer case).

It is up to the transferor to decide if the Required header should be included or not.

It it is included, it means that the transferor prefers that the transfer fails than
not updating the other party's information.
[JRE] The transfer has already taken place in the QSIG network, and therefore there is no way of making it fail. The gateway is just trying to report to the SIP UA the fact that transfer has occurred. The point of the Required header is to prevent the new INVITE being treated as a new call rather than a replacement for the existing call.

If not included, it means that it is willing to tolerate the fact that the identity
may not be updated (this happens today in traditional PBXs if there is no protocol
to update the calling line identity and the call is locally bridged).
[JRE] If Required is not included a UA that does not support Replaces will treat the INVITE request as a new dialog and take some undesirable action, e.g., making it wait on busy. Therefore I think Required is essential. 

--Boundary_(ID_TCvyD+ZJGYfE4Cy4NQuP2w)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 13:01:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01305 for ; Fri, 4 Apr 2003 13:01:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34I4JO04088 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 13:04:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34I4J804085 for ; Fri, 4 Apr 2003 13:04:19 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01291 for ; Fri, 4 Apr 2003 13:00:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34I3Y804011; Fri, 4 Apr 2003 13:03:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34I02803779 for ; Fri, 4 Apr 2003 13:00:02 -0500 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01171 for ; Fri, 4 Apr 2003 12:56:38 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34Hx4R17610; Fri, 4 Apr 2003 09:59:05 -0800 (PST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2FGBWZFA>; Fri, 4 Apr 2003 09:59:04 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D207A04A7A@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Elwell, John'" , "'sipping@ietf.org'" Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network Date: Fri, 4 Apr 2003 09:59:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FAD3.E188E4E6" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FAD3.E188E4E6 Content-Type: text/plain Thanks. Agreed. -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: Friday, April 04, 2003 09:40 To: Audet, Francois [SC100:4K02:EXCH]; 'sipping@ietf.org' Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network Francois, In-line John (john.elwell@siemens.com ) -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: 04 April 2003 02:06 To: 'Elwell, John'; 'sipping@ietf.org' Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com ] > > 5. Send INVITE (new dialog) with Replaces header and Required header (Replaces required). > This would be rejected by a UA that does not support the Replaces header. My take is that this is exactly what the Replaces header was intented to do (it even mentions the attended transfer case). It is up to the transferor to decide if the Required header should be included or not. It it is included, it means that the transferor prefers that the transfer fails than not updating the other party's information. [JRE] The transfer has already taken place in the QSIG network, and therefore there is no way of making it fail. The gateway is just trying to report to the SIP UA the fact that transfer has occurred. The point of the Required header is to prevent the new INVITE being treated as a new call rather than a replacement for the existing call. If not included, it means that it is willing to tolerate the fact that the identity may not be updated (this happens today in traditional PBXs if there is no protocol to update the calling line identity and the call is locally bridged). [JRE] If Required is not included a UA that does not support Replaces will treat the INVITE request as a new dialog and take some undesirable action, e.g., making it wait on busy. Therefore I think Required is essential. ------_=_NextPart_001_01C2FAD3.E188E4E6 Content-Type: text/html Message
Thanks. Agreed.
-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Friday, April 04, 2003 09:40
To: Audet, Francois [SC100:4K02:EXCH]; 'sipping@ietf.org'
Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network

Francois,
 
In-line
 

-----Original Message-----
From: Francois Audet [mailto:audet@nortelnetworks.com]
Sent: 04 April 2003 02:06
To: 'Elwell, John'; 'sipping@ietf.org'
Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network


> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]
>
> 5. Send INVITE (new dialog) with Replaces header and Required header (Replaces required). > This would be rejected by a UA that does not support the Replaces header.

My take is that this is exactly what the Replaces header was intented to do (it even
mentions the attended transfer case).

It is up to the transferor to decide if the Required header should be included or not.

It it is included, it means that the transferor prefers that the transfer fails than
not updating the other party's information.
[JRE] The transfer has already taken place in the QSIG network, and therefore there is no way of making it fail. The gateway is just trying to report to the SIP UA the fact that transfer has occurred. The point of the Required header is to prevent the new INVITE being treated as a new call rather than a replacement for the existing call.

If not included, it means that it is willing to tolerate the fact that the identity
may not be updated (this happens today in traditional PBXs if there is no protocol
to update the calling line identity and the call is locally bridged).
[JRE] If Required is not included a UA that does not support Replaces will treat the INVITE request as a new dialog and take some undesirable action, e.g., making it wait on busy. Therefore I think Required is essential. 

------_=_NextPart_001_01C2FAD3.E188E4E6-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 14:43:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04531 for ; Fri, 4 Apr 2003 14:43:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34JkiE12815 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 14:46:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Jki812812 for ; Fri, 4 Apr 2003 14:46:44 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04514 for ; Fri, 4 Apr 2003 14:43:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34JjU812722; Fri, 4 Apr 2003 14:45:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34Jgg812598 for ; Fri, 4 Apr 2003 14:42:42 -0500 Received: from dgesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04418 for ; Fri, 4 Apr 2003 14:39:18 -0500 (EST) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA) with ESMTP id <0HCU0074U3YPQC@firewall.wcom.com> for sipping@ietf.org; Fri, 04 Apr 2003 19:40:01 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HCU006013XYU2@pmismtp01.wcomnet.com>; Fri, 04 Apr 2003 19:40:01 +0000 (GMT) Received: from xs578v3521.wcom.com ([166.50.131.25]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HCU004LL3YKX1@pmismtp01.wcomnet.com>; Fri, 04 Apr 2003 19:39:58 +0000 (GMT) Date: Fri, 04 Apr 2003 13:39:56 -0600 From: Alan Johnston Subject: Re: [Sipping] Some comments on draft-camarillo-sipping-early-media-01.txt In-reply-to: <3E8BD3F1.3060909@lmf.ericsson.se> X-Sender: Alan.Johnston@pop.mcit.com To: Gonzalo Camarillo Cc: "Drage, Keith (Keith)" , "'sipping@ietf.org'" Message-id: <5.1.1.6.0.20030404133259.01ab8390@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <5.1.1.6.0.20030313150038.024d36f0@pop.mcit.com> Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Gonzalo, Thanks for replying to my comments. After I had sent my reply I had also found the use of Join in the app interaction framework and I meant to post comments about that draft as well. I think the use of Join in that draft is also not a good idea. I haven't come to a final conclusion yet, but I suspect that the Replaces primitive is much closer to a better fit than Join, especially in the app interaction where no media mixing is ever involved. Turning every call placed into a conference call but without any media mixing seems very, very odd. I will continue to think through these scenarios and post more on both drafts soon. Also, I'm not sure it is a good idea to align the application interaction framework (which deals with stimulus signaling and markup delivery) with early media, as they are such different things. I Thanks, Alan Johnston WorldCom sip:alan@digitalari.com At 11:25 AM 4/3/2003 +0300, Gonzalo Camarillo wrote: >Alan, > >inline > >Alan Johnston wrote: >>At 08:30 PM 3/13/2003 +0000, Drage, Keith (Keith) wrote: >> >> >>>10) Section 3, 1st paragraph, not a comment that requires fixing, >>>but we have a dependency to the Join draft which will need to be >>>finished before or at the same time as this draft. >>> >>>11) Section 3, 1st paragraph, Amend final sentence to read "... by >>>sending a new INVITE request to the URI it received in the Join header field." >> >>This entire section is quite confusing. I think that Gonzalo does not >>mean to reference the Join header field - it has no application in this >>example. I think he means to reference the To-Join header field proposed >>by Jonathan in the original call package >>(http://www.softarmor.com/sipping/drafts/morgue/draft-rosenberg-sip-call-package-00.txt). >> >>Also, the reference 5 cited in this section is the Application >>Interaction Framework which again has no bearing on this idea of separate >>dialogs for regular and early media. Perhaps the Application Component >>Architecture document was the intended reference? > >The idea (which was originally proposed by Jon), is to make the UAS >establish early media with the UAC in the same way as an application >server in the path would do it. Therefore, the idea is to reference the >work of the application interaction design team. That's why we reference >the draft below: > >http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-app-interaction-framework-00.txt > >Regarding the Join header, the draft above says: > >However, the INVITE from the caller > indicated that the device is capable of acting as a focus. How did it > do that? It did so by indicating support for the SIP Join extension > [11] which allows a UA to request to be conferenced into an existing > dialog. As such, both app1 and app2, acting as a pure UAC, generate > an INVITE towards this focus, with a Join header requesting to be > added to a conference which includes the original dialog. The result > is two additional dialogs, dialog A and dialog B respectively, which > join the original dialog in their connection to a focus co-resident > with the caller. > > >Reference [11] in that draft is: > >[11] R. Mahy and D. Petrie, "The session initiation protocol (sip) > join header," Internet Draft, Internet Engineering Task Force, Oct. > 2002. Work in progress. > > >Once we resolve other issues related to early media, we intend to align >this section with the application interactions work, but with this summary >I believe it is clear what we are trying to do. > >Thanks, > >Gonzalo > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 4 15:13:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06548 for ; Fri, 4 Apr 2003 15:13:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34KG7d15204 for sipping-archive@odin.ietf.org; Fri, 4 Apr 2003 15:16:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34KG7815201 for ; Fri, 4 Apr 2003 15:16:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06491 for ; Fri, 4 Apr 2003 15:12:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34KFL815162; Fri, 4 Apr 2003 15:15:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34KCl815018 for ; Fri, 4 Apr 2003 15:12:47 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05989 for ; Fri, 4 Apr 2003 15:09:22 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34KBmv05505; Fri, 4 Apr 2003 14:11:48 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2FGBXDH2>; Fri, 4 Apr 2003 12:11:48 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D207A04E3F@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Christer Holmberg'" , "'Gonzalo Camarillo'" Cc: "Mark Watson" , "Tom-PT Taylor" , "'sipping@ietf.org'" , "'Jon Peterson'" Subject: RE: [Sipping] Early media; philosophical discussion Date: Fri, 4 Apr 2003 12:11:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FAE6.6C0FD356" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FAE6.6C0FD356 Content-Type: text/plain > Of course we still have the issue related to forking, media > mixing etc, but I don't think we can solve that (I really > don't like the idea of sending lots of pre-session UPDATEs, > because that will cause other kind of race conditions), but > if we recommend SIP nodes to not send early media (PSTN > gateways will of course often do it) in the first place that > may not be a really big problem in real-life networks. I think we need more than a recommendation. We need a way to tell the far-end NOT to send early media (because of forking for example). This indication can not be at the SDP level, and it should be something that a proxy (such as a forking proxy) could add to the INVITE. The case that worries me most is forking where early media can not work properly (I think everybody agrees on this). This is why I was suggesting that a forking indication would suffice. But we could instead have some sort of explicit no-early media indication. Again, the problem is that forking to a PSTN gateway will happen, and if that gateway does not know not to send early media, we have a problem. ------_=_NextPart_001_01C2FAE6.6C0FD356 Content-Type: text/html RE: [Sipping] Early media; philosophical discussion

> Of course we still have the issue related to forking, media
> mixing etc, but I don't think we can solve that (I really
> don't like the idea of sending lots of pre-session UPDATEs,
> because that will cause other kind of race conditions), but
> if we recommend SIP nodes to not send early media (PSTN
> gateways will of course often do it) in the first place that
> may not be a really big problem in real-life networks.

I think we need more than a recommendation.  We need a way to tell
the far-end NOT to send early media (because of forking
for example). This indication can not be at the SDP level, and it
should be something that a proxy (such as a forking proxy) could
add to the INVITE.

The case that worries me most is forking where early media can not
work properly (I think everybody agrees on this). This is why I
was suggesting that a forking indication would suffice. But we
could instead have some sort of explicit no-early media indication.

Again, the problem is that forking to a PSTN gateway will happen,
and if that gateway does not know not to send early media, we have
a problem.

------_=_NextPart_001_01C2FAE6.6C0FD356-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Apr 5 01:08:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19272 for ; Sat, 5 Apr 2003 01:08:07 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h356BEE25303 for sipping-archive@odin.ietf.org; Sat, 5 Apr 2003 01:11:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h356BE825300 for ; Sat, 5 Apr 2003 01:11:14 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19255 for ; Sat, 5 Apr 2003 01:07:34 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h356AJ825212; Sat, 5 Apr 2003 01:10:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3566I824248 for ; Sat, 5 Apr 2003 01:06:18 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19197 for ; Sat, 5 Apr 2003 01:02:38 -0500 (EST) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3564SRs015141; Sat, 5 Apr 2003 08:04:28 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A40NVHV; Sat, 5 Apr 2003 08:04:28 +0200 Received: from lmf.ericsson.se (sealwa04-233.sw.ericsson.se [130.100.249.233]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3564LAv008557; Sat, 5 Apr 2003 09:04:22 +0300 (EET DST) Message-ID: <3E8E71E0.3030007@lmf.ericsson.se> Date: Sat, 05 Apr 2003 09:04:16 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet CC: "'Michael Hammer'" , Tom-PT Taylor , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" , Mark Watson Subject: Re: [Sipping] New version of the early media draft References: <2F1FC1DEA077D5119FAD00508BCFD6D207A04E21@zsc3c030.us.nortel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As I said in a separate note, the idea is not use the mechanism that the application interaction design team develops. Since all the UACs would eventually like to be able to interact with whatever is in the network (e.g., introduce a pin number so that your call can proceed), this will be a widespread feature. Gonzalo Francois Audet wrote: > Gonzallo, doesn't the mechanism in section 3 imply that the UAC sending the > initial INVITE needs to know beforehand that this Application Server model > will be used and therefore it would amount to requiring all SIP UAC to > always include the join header???? > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Thursday, April 03, 2003 22:04 > > To: Michael Hammer > > Cc: Audet, Francois [SC100:4K02:EXCH]; Taylor, Tom-PT > > [CAR:5N00:EXCH]; 'Bob Penfield'; 'sipping@ietf.org'; 'Jon > > PETERSON (Jon.Peterson@neustar.com)'; 'Christer Holmberg'; > > Watson, Mark [MOP:EP10:EXCH] > > Subject: Re: [Sipping] New version of the early media draft > > > > > > Michael, > > > > fetch the draft below: > > http://www.ietf.org/internet-drafts/draft-camarillo-sipping-ea > > rly-media-01.txt > > > > Read Section 2.3; this section explains that the gateway > > model produces > > undesirable results when forking is present. Therefore, you > > SHOULD NOT > > use this model. However, there are some situations when the gateway > > cannot distinguish between early and regular media. In that > > situation, > > even knowing that there may be problems if forking occurs, > > the gateway > > has no other choice than using the gateway model. Therefore, > > even if you > > had an indication telling the gateway that the call forked, > > the gateway > > DOES NOT HAVE ANY OTHER CHOICE. > > > > But what happens if your system does have a choice and can actually > > distinguish between early and regular media? Go on and read > > Section 3. > > It provides a mechanism that, if you look at the end result, is > > equivalent to yours. Therefore, I assume that you will be happy with > > that mechanism. > > > > Why do we use that mechanism (reverse INVITE) instead of your > > mechanism > > or UPDATEs with an extra stream with an "early media" label > > (documented > > in the draft as well)? It is explained in the last pargraph > > of Section 3. > > > > " An alternative model would consist of adding a new stream > > labeled as "early media" to the original session between > > the UAC and the UAS using an UPDATE, instead of > > establishing a new session. We have chosen to establish a > > new session to be coherent with the mechanism used by > > application servers that are NOT co-located with the UAS. > > This way, the UAS uses the same mechanism as any other > > application server in the network to interact with the UAC." > > > > > > Hope this helps, > > > > Gonzalo > > > > > > > > Michael Hammer wrote: > > > Gonzalo, > > > > > > Would it be possible to have an early media convention that > > contains > > > the > > > following elements: > > > > > > 1) the receiving end indicates in signaling that it intends to send > > > early media > > > 2) the receiving end includes SDP in hold state and does > > not send media > > > at first > > > 3) the caller responds to one receiver's inband indicator > > (or not) with > > > an UPDATE putting that receiver in send state > > > 4) the receiving end responds to UPDATE and begins sending > > of RTP with > > > media. > > > > > > This resolves the forking case, tells the caller which > > device intends > > > inband media, and allows the caller with possibly user in > > the loop to > > > decide which to listen to. > > > > > > See the following: > > > > > > A Forking Proxy User User User > > > B1 B2 B3 > > > | | | | | > > > | INVITE F1 | | | | > > > |--------------->| | | | > > > | 100 Trying F2 | | | | > > > |<---------------| INVITE F3 | | | > > > | |------------->| | | > > > | | INVITE F4 | | > > > | |-------------------->| | > > > | | INVITE F5 | | > > > | |--------------------------->| > > > | | 183 inband F6| | | > > > | 183 inband F7 |<-------------| | | > > > |<---------------| | | | > > > | | 183 inband F8| | | > > > | 183 inband F9 |<--------------------| | > > > |<---------------| | | | > > > | UPDATE send F10| | | | > > > |--------------->| UPDATE send F11 | | > > > | |-------------------->| | > > > | | ACK send F12 | | | > > > | ACK send F13 |<--------------------| | > > > |<---------------| | | | > > > Play<=====|<======Early media====================| | > > > | | 180 inband F14 | | > > > | 180 inband F15 |<---------------------------| > > > |<---------------| CANCEL F16 | | | > > > | |------------->|media | | > > > | | 200 OK F17 |stops | | > > > | |<-------------| | | > > > | | 487 F18 | | | > > > | |<-------------| | | > > > | | ACK F19 | | | > > > | |------------->| | | > > > | UPDATE send F20| | | | > > > |--------------->| UPDATE send F21 | | > > > | |--------------------------->| > > > | | ACK send F22 | | | > > > | ACK send F23 |<---------------------------| > > > |<---------------| | | | > > > Play<=====|<==============="Hello"======================| > > > | | 200 OK F24 | > > > | 200 OK F25 |<---------------------------| > > > |<---------------| | | | > > > | ACK send F26 | | | | > > > |--------------->| ACK send F27 | | | > > > | |--------------------------->| > > > | | | | | > > > > > > Am I missing anything here? > > > The key is to stop guessing and make it more deterministic. > > > > > > If you don't like this, don't use the inband indicator, and > > fall back > > > to > > > the current state of problems. > > > > > > Mike > > > > > > > > > At 01:18 PM 4/3/2003 +0300, Gonzalo Camarillo wrote: > > > > > >> Francois, > > >> > > >> you are missing the point of the draft. The draft explains what > > >> happens when you use early media within the dialog are > > forking occurs. > > >> That is, you have a lot of problems. > > >> > > >> The aim of the draft is to describe these problems and to describe > > >> things that a UAC may do without extending the protocol. > > We do that > > >> because you have to interact with existing UASs that will send you > > >> media this way. You cannot upgrade the already installed base. > > >> > > >> But we do not want to extend the protocol to provide a solution for > > >> this gateway model. We recommend that new systems use the > > application > > >> server model. In this model, we will provide solutions and > > extend the > > >> protocol should that be needed. > > >> > > >> Gonzalo > > >> > > >> Francois Audet wrote: > > >> > > >>> > First of all, I do not understand why people continue > > >>> > discussing things > > >>> > like early media with forking whose problems are > > already well > > > >>> discussed > and documented in the draft and nobody so > > far has been > > >>> able > to come up > > >>> > with a single use case where the proposed flag would > > be useful... I > > >>> > would ask people to focus on the problem in hand (i.e., the > > >>> > flag), and > > >>> > stop discussing about already resolved issues. > > >>> The problem is that the multiple dialog problem and early media > > >>> problem (as in forking > > >>> for example) has NOT been solved. Worst, using the > > current unworkable > > >>> solution as a basis > > >>> to make our decisions on the flag issue will not result in a good > > >>> solution. > > >>> The current solution for forking in the draft is for the > > UAC to pick > > >>> a random media > > >>> stream (based on signaling, thus the dialog, not media, > > because there > > >>> is no means to correlate > > >>> dialog and media stream) and mute the others by sending > > UPDATEs to > > >>> the far end. This is > > >>> not an acceptable solution. Random non-redictable behavior is not > > >>> acceptable to end-users. > > >>> Furthemore, this is not robust at all because if the > > called UA does > > >>> not support UPDATE, > > >>> multiple streams will be received and there will be no > > way for the > > >>> UAC receiving it > > >>> to pick the proper one. (If there was a way to correlate an RTP > > >>> stream to the dialog that > > >>> generate it, it would be easier) > > >>> This leaves the client with 3 choices: > > >>> 1) Pick a random media stream (which it will not be able > > to correlate > > >>> with a specific dialog > > >>> unless it is lucky with educated guesses). > > >>> 2) Mix media streams together. > > >>> 3) Provide alternative local treatment based on the provisional > > >>> responses received. This > > >>> could be > > >>> > > >>> You are right that the flag probably doesn't help with > > this problem. > > >>> I'll leave it > > >>> to others to defend the flag idea. > > >>> I'm OK with current draft, as long as we do not ADD any more > > >>> dependency on the "play > > >>> media when you receive it" principle to address the flag > > prolem, and > > >>> as long as we improve > > >>> the section on forking. It seems to me that if forking is > > used we CAN > > >>> NOT use early media for > > >>> in-band ringing (we could do early media for clipping avoidance). > > >>> Perhaps we need a > > >>> "forked" indication in INVITE telling the far-end not to > > send early > > >>> media... And to make > > >>> it bullet proof a forked indication in the 100 Trying > > (when forking) > > >>> to tell the UAC making the > > >>> call that "weird stuff" is going to happen and that > > proper treatment > > >>> should be used not > > >>> to confused the user. > > >> > > >> > > >> > > >> -- > > >> Gonzalo Camarillo Phone : +358 9 299 33 71 > > >> Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > >> Telecom R&D Fax : +358 9 299 30 52 > > >> FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > >> Finland http://www.hut.fi/~gonzalo > > >> > > >> _______________________________________________ > > >> Sipping mailing list > > https://www1.ietf.org/mailman/listinfo/sipping > > >> This list > > is for NEW development of the application of SIP Use > > >> sip-implementors@cs.columbia.edu for questions on current sip Use > > >> sip@ietf.org for new developments of core SIP > > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Apr 5 01:10:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19350 for ; Sat, 5 Apr 2003 01:10:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h356DVv25378 for sipping-archive@odin.ietf.org; Sat, 5 Apr 2003 01:13:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h356DV825375 for ; Sat, 5 Apr 2003 01:13:31 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19325 for ; Sat, 5 Apr 2003 01:09:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h356D4825363; Sat, 5 Apr 2003 01:13:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h356Al825236 for ; Sat, 5 Apr 2003 01:10:47 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19245 for ; Sat, 5 Apr 2003 01:07:09 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3569dI3012407; Sat, 5 Apr 2003 08:09:39 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4LNNZF; Sat, 5 Apr 2003 08:09:40 +0200 Received: from lmf.ericsson.se (sealwa04-233.sw.ericsson.se [130.100.249.233]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3569bAv008719; Sat, 5 Apr 2003 09:09:38 +0300 (EET DST) Message-ID: <3E8E731C.3020505@lmf.ericsson.se> Date: Sat, 05 Apr 2003 09:09:32 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: "Drage, Keith (Keith)" , "'sipping@ietf.org'" Subject: Re: [Sipping] Some comments on draft-camarillo-sipping-early-media-01.txt References: <5.1.1.6.0.20030313150038.024d36f0@pop.mcit.com> <5.1.1.6.0.20030404133259.01ab8390@pop.mcit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alan, > Also, I'm not sure it is a good idea to align the application > interaction framework (which deals with stimulus signaling and markup > delivery) with early media, as they are such different things. I I believe it is alright to align them, since early media can be bi-directional as well, and may involve interactions with the UAC. This way, if the UAS sends early media to the UAC in order to interact, it uses the same mechanism as if it sends media only to say "the user is being alterter". Thanks for your comments, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Apr 5 01:17:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19546 for ; Sat, 5 Apr 2003 01:17:36 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h356Kg325759 for sipping-archive@odin.ietf.org; Sat, 5 Apr 2003 01:20:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h356Kg825756 for ; Sat, 5 Apr 2003 01:20:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19540 for ; Sat, 5 Apr 2003 01:17:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h356K5825728; Sat, 5 Apr 2003 01:20:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h356HM825574 for ; Sat, 5 Apr 2003 01:17:22 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19448 for ; Sat, 5 Apr 2003 01:13:43 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h356GEI3013151; Sat, 5 Apr 2003 08:16:14 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4SGDAN; Sat, 5 Apr 2003 08:16:14 +0200 Received: from lmf.ericsson.se (sealwa04-233.sw.ericsson.se [130.100.249.233]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h356GAAv009182; Sat, 5 Apr 2003 09:16:11 +0300 (EET DST) Message-ID: <3E8E74A5.2000200@lmf.ericsson.se> Date: Sat, 05 Apr 2003 09:16:05 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet CC: "'Christer Holmberg'" , Mark Watson , Tom-PT Taylor , "'sipping@ietf.org'" , "'Jon Peterson'" Subject: Re: [Sipping] Early media; philosophical discussion References: <2F1FC1DEA077D5119FAD00508BCFD6D207A04E3F@zsc3c030.us.nortel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Francois, I have already answered this one in another note (I believe I sent it yesterday). The gateway model is appropriate when the UAS is not the one "generating" the early media. This means that, a gateway cannot know whether the early media is optional or not. A gateway does not know whether the early media it is receiving from the circuit-switched part is optional or is essential to the call. Therefore, even if this gateway receives an indication from in the INVITE saying that the requested forked, the gateway CANNOT DO ANYTHING. It needs to send the media anyway. However, a pure SIP UAS knows that what it is about to generate is a message that says "Thanks for calling Francois, please wait". Therefore, it sends a separate INVITE (application server model), which the UAC can refuse if it is already overloaded with other stuff. Therefore, a "has forked" indication buys you NOTHING here. Gonzalo Francois Audet wrote: > > > Of course we still have the issue related to forking, media > > mixing etc, but I don't think we can solve that (I really > > don't like the idea of sending lots of pre-session UPDATEs, > > because that will cause other kind of race conditions), but > > if we recommend SIP nodes to not send early media (PSTN > > gateways will of course often do it) in the first place that > > may not be a really big problem in real-life networks. > > I think we need more than a recommendation. We need a way to tell > the far-end NOT to send early media (because of forking > for example). This indication can not be at the SDP level, and it > should be something that a proxy (such as a forking proxy) could > add to the INVITE. > > The case that worries me most is forking where early media can not > work properly (I think everybody agrees on this). This is why I > was suggesting that a forking indication would suffice. But we > could instead have some sort of explicit no-early media indication. > > Again, the problem is that forking to a PSTN gateway will happen, > and if that gateway does not know not to send early media, we have > a problem. > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Apr 5 01:26:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19680 for ; Sat, 5 Apr 2003 01:26:40 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h356SoT26052 for sipping-archive@odin.ietf.org; Sat, 5 Apr 2003 01:28:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h356So826049 for ; Sat, 5 Apr 2003 01:28:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19658 for ; Sat, 5 Apr 2003 01:25:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h356SG826037; Sat, 5 Apr 2003 01:28:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h356Pv825956 for ; Sat, 5 Apr 2003 01:25:57 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19622 for ; Sat, 5 Apr 2003 01:22:18 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h356OQRs017617; Sat, 5 Apr 2003 08:24:26 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4LNP3T; Sat, 5 Apr 2003 08:24:27 +0200 Received: from lmf.ericsson.se (sealwa04-233.sw.ericsson.se [130.100.249.233]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h356OLAv009394; Sat, 5 Apr 2003 09:24:22 +0300 (EET DST) Message-ID: <3E8E7690.9080304@lmf.ericsson.se> Date: Sat, 05 Apr 2003 09:24:16 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: Francois Audet , Tom-PT Taylor , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" , Mark Watson Subject: Re: [Sipping] New version of the early media draft References: <2F1FC1DEA077D5119FAD00508BCFD6D20794E863@zsc3c030.us.nortel.com> <4.3.2.7.2.20030403102839.00b44170@cia.cisco.com> <4.3.2.7.2.20030404112904.04849988@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael, > You define what you refer to as the "gateway model", but as near as I > can tell, the gateway model is simply the Offer-Answer model. If not, > you need to explain what the difference is. Yes, the gateway model, as explained in the draft, consists of using the offer/answer model **WITHIN** the dialgo established by the original INVITE transaction. > > Section 2 does an excellent job of describing the various problems. > > From pp. 7-8: > > The gateway model is, therefore, acceptable in situations where the > UA cannot distinguish between early media and regular media. A PSTN > gateway is an example of this type of situation. The PSTN gateway > receives media from the PSTN over a circuit, and sends it to the IP > network. The gateway is not aware of the contents of the media, and > it does not exactly know when the transition from early to regular > media takes place. From the PSTN perspective, the circuit is a > continuous source of media. > > Did you mean to say that the gateway model is NOT acceptable? Yes, it means that a UAS (which can be eventually a gateway) can use the gateway model only under centain circumstances (see the note I have just sent responding to Francois' mail). > Let me see if I understand Section 3 correctly: > The idea is that you send an INVITE in the reverse direction, and you will send early media using that dialog. This way, the UAC has the possibility of refusing this dialog. > Now, this solves the media clipping problem and the forking problem, > which as you say is equivalent to the case I presented. Yes. > But, it doesn't solve the missing ringback problem (which may not be a > problem for phones with visual displays). If the signaling is quick, > the UAC could accept and play the secondary RTP stream containing dead > air and suppress local ringback. If you use the application server model, you would never generate dead air in the dialog established with reverse INVITE. And systems using the application server model in that way are not going to send dead air in the dialog established with the original INVITE either. But you are right that an explicit recommendation would be nice. Thanks for the comments, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Apr 5 19:39:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18960 for ; Sat, 5 Apr 2003 19:39:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h360gsN00333 for sipping-archive@odin.ietf.org; Sat, 5 Apr 2003 19:42:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h360gs800330 for ; Sat, 5 Apr 2003 19:42:54 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18956 for ; Sat, 5 Apr 2003 19:38:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h360gA800315; Sat, 5 Apr 2003 19:42:10 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h360c5832673 for ; Sat, 5 Apr 2003 19:38:05 -0500 Received: from hoemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18923 for ; Sat, 5 Apr 2003 19:34:05 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h360aZH09857 for ; Sat, 5 Apr 2003 19:36:35 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Apr 2003 01:36:34 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0081DB718@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Gonzalo Camarillo , Mark Watson Cc: Tom-PT Taylor , sipping@ietf.org, Jon Peterson Subject: RE: [Sipping] Early media; a summary after the IETF Date: Sun, 6 Apr 2003 01:36:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , See below And yes I do remember hot, sweaty conference rooms in Geneva in 1986 and 1987 when this was all worked through. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 04 April 2003 10:37 > To: Mark Watson > Cc: Tom-PT Taylor; sipping@ietf.org; Jon Peterson > Subject: Re: [Sipping] Early media; a summary after the IETF > > > As far as I know, Q.931 lets you send ALERTING with no > indication, but I > do not know any example where the network uses this message. Where is > this used? > It depends which side of the network you are on. ISDN assumes that all ALERTING messages are accompanied by appropriate tone/announcement - at least for those "media types" where it is appropriate, e.g. voice, and in general it is even provided on 64kbit/s. This is generated by the destination local exchange, and possibly destination PBX as well. Therefore on the destination Q.931 interface, there is no in-band tone. On the originating Q.931 i/f there is always an in-band tone/announcement. In the absence of progress indicator #1, the phone has the freedom to generate either a local ringing tone, or to provide the tone that is available in-band. The progress indicator #1 does not indicate the presence of such a tone or announcement, rather it indicates that one should listen to it and not generate a local ringing tone. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sun Apr 6 01:45:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22982 for ; Sun, 6 Apr 2003 01:45:13 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h366mo017766 for sipping-archive@odin.ietf.org; Sun, 6 Apr 2003 01:48:50 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h366mo817763 for ; Sun, 6 Apr 2003 01:48:50 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22971 for ; Sun, 6 Apr 2003 01:44:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h366mG817710; Sun, 6 Apr 2003 01:48:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h366i5817599 for ; Sun, 6 Apr 2003 01:44:05 -0500 Received: from telesoft.indts.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22877 for ; Sun, 6 Apr 2003 01:39:55 -0500 (EST) Received: from indts_fs.indts.com (indts_fs.indts.com [201.64.64.29]) by telesoft.indts.com (8.11.6/8.11.6) with ESMTP id h366UsI07182 for ; Sun, 6 Apr 2003 12:00:54 +0530 Received: by INDTS_FS with Internet Mail Service (5.5.2650.21) id ; Sun, 6 Apr 2003 12:12:21 +0530 Message-ID: From: Nitin Kumar To: "'sipping@ietf.org'" Date: Sun, 6 Apr 2003 12:12:14 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] 486/603 Response issue in Proxy server Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , hi Folks, Would like to get some clue on following issue. I am using "SIP express Router" as my proxy server to test our SIP user agents. Now if one UA(lets say party A) sends INVITE to other UA (lets say party B) via proxy server, we are finding that any non-2xx response (like 486 busy, 603 decline) received by proxy server from party B is not forwarded to party A. Moreover proxy server is also sending valid ACK to non-2xx response to party B. A PS (SIP express router) B | | | |----------INVITE------------>| | | |----------INVITE------------>| |<---------100 trying---------| | | |<---------100 trying---------| | | | | |<---------180 trying---------| |<---------180 trying---------| | | | | | |<---------603 decline--------| | 603 not forwarded | | | |------------ACK------------->| | | | | | | | | | any idea what may be the reason? In case of successful call everything works fine. will appreciate some clue from sip experts. regards, -nitin _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sun Apr 6 22:23:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12144 for ; Sun, 6 Apr 2003 22:23:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h372Rce21158 for sipping-archive@odin.ietf.org; Sun, 6 Apr 2003 22:27:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h372Rc821155 for ; Sun, 6 Apr 2003 22:27:38 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12130 for ; Sun, 6 Apr 2003 22:23:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h372QX821090; Sun, 6 Apr 2003 22:26:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h372Ox821035 for ; Sun, 6 Apr 2003 22:24:59 -0400 Received: from pmesmtp02.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12086 for ; Sun, 6 Apr 2003 22:20:26 -0400 (EDT) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA ) with ESMTP id <0HCY00D3XBYBF7@firewall.wcom.com> for sipping@ietf.org; Mon, 07 Apr 2003 02:22:59 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HCY00201BY5R0@pmismtp02.wcomnet.com>; Mon, 07 Apr 2003 02:22:59 +0000 (GMT) Received: from xs578v3521.wcom.com ([166.50.97.132]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HCY0022MBY5E1@pmismtp02.wcomnet.com>; Mon, 07 Apr 2003 02:22:56 +0000 (GMT) Date: Sun, 06 Apr 2003 21:22:53 -0500 From: Alan Johnston X-Sender: Alan.Johnston@pop.mcit.com To: sipping@ietf.org Message-id: <5.1.1.6.0.20030406211253.01d4fcb8@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed Subject: [Sipping] New Versions of Call Flows I-Ds Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , All, I've just submitted new versions of the basic and PSTN call flows documents. The updates are mainly minor wording changes based on IESG feedback. However, I have added a new flow in the PSTN Call Flows showing ENUM in Section 2.4. I would greatly appreciate if the working group could look over that flow (which I have reproduced below for your convenience...) Until they are available in the archives, the documents are available at: http://ee.wustl.edu/~alan/draft-ietf-sipping-basic-call-flows-02.txt http://ee.wustl.edu/~alan/draft-ietf-sipping-pstn-call-flows-02.txt Thanks, Alan Johnston WorldCom sip:alan@digitalari.com - - - - - (View with a fixed width font such as Courier) 2.4 Successful SIP to SIP using ENUM Query Alice DNS Server Proxy 3 Bob | | | | | ENUM Query F1 | | | |--------------->| | | | Response F2 | | | |<---------------| | | | INVITE F3 | | |-------------------------------->| INVITE F4 | | 100 F5 |--------------->| |<--------------------------------| 180 F6 | | 180 F7 |<---------------| |<--------------------------------| | | | 200 F8 | | 200 F9 |<---------------| |<--------------------------------| | | ACK F10 | | |-------------------------------->| ACK F11 | | |--------------->| | Both Way RTP Media | |<================================================>| | | BYE F12 | | BYE F13 |<---------------| |<--------------------------------| | | 200 F14 | | |-------------------------------->| 200 F15 | | |--------------->| | | | In this scenario, Alice places a call to Bob by dialing Bob's telephone number (9725552222). Alice's UA converts the phone number to an E.164 number (+19725552222) performs an ENUM query [10] on the E.164 number (2.2.2.2.5.5.5.2.7.9.1.e164.arpa) which returns a NAPTR record containing a SIP AOR URI for Bob (sip:+19725552222@b.example.com). As a result, Alice's UA sends an INVITE and the call completes over IP bypassing the PSTN. The call is terminated when Bob sends a BYE message. Message Details F1 ENUM Query Alice -> DNS Server 2.2.2.2.5.5.5.2.7.9.1.e164.arpa F2 ENUM NAPTR Set DNS Server -> Alice $ORIGIN 2.2.2.2.5.5.5.2.7.9.1.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:+19725552222@b.example.com!". F3 INVITE Alice -> Proxy 3 INVITE sip:+19725552222@b.example.com SIP/2.0 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: ;tag=9fxced76sl To: Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 INVITE Contact: Content-Type: application/sdp Content-Length: 154 v=0 o=alice 2890844526 2890844526 IN IP4 client.a.example.com s=- c=IN IP4 client.a.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F4 INVITE Proxy 3 -> Bob INVITE sip:+19725552222@client.b.example.com SIP/2.0 Via: SIP/2.0/UDP ss3.b.example.com:5060;branch=z9hG4bK721e418c4.1 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Max-Forwards: 69 Record-Route: From: ;tag=9fxced76sl To: Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 INVITE Contact: Content-Type: application/sdp Content-Length: 154 v=0 o=UserA 2890844526 2890844526 IN IP4 client.a.example.com s=- c=IN IP4 client.a.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F5 100 Trying Proxy 3 -> Alice SIP/2.0 100 Trying Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: ;tag=9fxced76sl To: Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 INVITE Content-Length: 0 F6 180 Ringing B -> Proxy 3 SIP/2.0 180 Ringing Via: SIP/2.0/UDP ss3.b.example.com:5060;branch=z9hG4bK721e418c4.1 ;received=192.0.2.233 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: From: ;tag=9fxced76sl To: ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 INVITE Contact: Content-Length: 0 F7 180 Ringing Proxy 3 -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: From: ;tag=9fxced76sl To: ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 INVITE Contact: Content-Length: 0 F8 200 OK Bob -> Proxy 3 SIP/2.0 200 OK Via: SIP/2.0/UDP ss3.b.example.com:5060;branch=z9hG4bK721e418c4.1 ;received=192.0.2.233 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: From: ;tag=9fxced76sl To: ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=bob 2890844527 2890844527 IN IP4 client.b.example.com s=- c=IN IP4 client.b.example.com t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F9 200 OK Proxy -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 Record-Route: From: ;tag=9fxced76sl To: ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 INVITE Contact: Content-Type: application/sdp Content-Length: 151 v=0 o=bob 2890844527 2890844527 IN IP4 client.b.example.com s=- c=IN IP4 192.0.2.100 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F10 ACK Alice -> Proxy 3 ACK sip:+19725552222@client.b.example.com SIP/2.0 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bq9 Max-Forwards: 70 Route: From: ;tag=9fxced76sl To: ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 ACK Content-Length: 0 F11 ACK Proxy 3 -> Bob ACK sip:+19725552222@client.b.example.com SIP/2.0 Via: SIP/2.0/UDP ss3.b.example.com:5060;branch=z9hG4bK721e418c4.1 Via: SIP/2.0/UDP client.a.example.com:5060;branch=z9hG4bK74bq9 ;received=192.0.2.101 Max-Forwards: 69 From: ;tag=9fxced76sl To: ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 2 ACK Content-Type: application/sdp Content-Length: 0 /* RTP streams are established between A and B*/ /* User B Hangs Up with User A. */ F12 BYE Bob -> Proxy 3 BYE sip:+13145551111@client.a.example.com SIP/2.0 Via: SIP/2.0/UDP client.b.example.com:5060;branch=z9hG4bKfgaw2 Max-Forwards: 70 Route: From: ;tag=314159 To: ;tag=9fxced76sl Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 BYE Content-Length: 0 F13 BYE Proxy 3 -> Alice BYE sip:+13145551111@client.a.example.com SIP/2.0 Via: SIP/2.0/UDP ss3.b.example.com:5060;branch=z9hG4bK721e418c4.1 ;received=192.0.2.100 Via: SIP/2.0/UDP client.b.example.com:5060;branch=z9hG4bKfgaw2 Max-Forwards: 69 From: ;tag=314159 To: ;tag=9fxced76sl Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 BYE Content-Length: 0 F14 200 OK Alice -> Proxy 3 SIP/2.0 200 OK Via: SIP/2.0/UDP ss3.b.example.com:5060;branch=z9hG4bK721e418c4.1 ;received=192.0.2.233 Via: SIP/2.0/UDP client.b.example.com:5060;branch=z9hG4bKfgaw2 ;received=192.0.2.100 From: ;tag=314159 To: ;tag=9fxced76sl Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 BYE Content-Length: 0 F15 200 OK Proxy 3 -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP client.b.example.com:5060;branch=z9hG4bKfgaw2 ;received=192.0.2.100 From: ;tag=314159 To: ;tag=9fxced76sl Call-ID: 2xTb9vxSit55XU7p8@a.example.com CSeq: 1 BYE Content-Length: 0 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 7 01:34:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17601 for ; Mon, 7 Apr 2003 01:34:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h375cbs32276 for sipping-archive@odin.ietf.org; Mon, 7 Apr 2003 01:38:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h375cb832273 for ; Mon, 7 Apr 2003 01:38:37 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17571 for ; Mon, 7 Apr 2003 01:34:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h375ba832250; Mon, 7 Apr 2003 01:37:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h375ZU831361 for ; Mon, 7 Apr 2003 01:35:30 -0400 Received: from sj-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17494 for ; Mon, 7 Apr 2003 01:30:56 -0400 (EDT) Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h375XOph027984; Sun, 6 Apr 2003 22:33:24 -0700 (PDT) Received: from [192.168.1.101] (rtp-vpn1-441.cisco.com [10.82.225.185]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEX87861; Sun, 6 Apr 2003 22:40:44 -0700 (PDT) Date: Sun, 06 Apr 2003 22:33:21 -0700 From: Cary FitzGerald To: Mark Watson , "'Gonzalo Camarillo'" cc: Tom-PT Taylor , sipping@ietf.org, Jon Peterson Subject: RE: [Sipping] Early media; a summary after the IETF Message-ID: <167243563.1049668401@[192.168.1.101]> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Can you point out where in RFC1889/1890 RTCP is described as optional? RTCP has a number of uses; this is one. Cary. >> You have RTCP. The sending side will always know whether there is >> an error. What you are proposing does not actually help >> debugging. Let's say my SIP phone sends you a signalling message >> saying "I will be sending media", but I remain silent in front of >> my >> microphone... now you >> will think that there is an error in the network, when everything >> is perfectly normal. > > Well, RTCP is optional. The fact that there may not be RTP packets > when in fact the sender is intending to send media (it just happens > to be silent) surely argues that using the presence/absence of RTP > to indicate the media status is even more unreliable! _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 7 01:51:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18583 for ; Mon, 7 Apr 2003 01:51:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h375trF00495 for sipping-archive@odin.ietf.org; Mon, 7 Apr 2003 01:55:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h375tr800492 for ; Mon, 7 Apr 2003 01:55:53 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18560 for ; Mon, 7 Apr 2003 01:51:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h375tC800439; Mon, 7 Apr 2003 01:55:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h375sD800337 for ; Mon, 7 Apr 2003 01:54:13 -0400 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18494 for ; Mon, 7 Apr 2003 01:49:37 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h375q5Rs005069; Mon, 7 Apr 2003 07:52:05 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A47XS22; Mon, 7 Apr 2003 07:52:02 +0200 Received: from lmf.ericsson.se ([131.160.31.93]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h375pwAv017350; Mon, 7 Apr 2003 08:51:58 +0300 (EET DST) Message-ID: <3E9111FD.993C2F93@lmf.ericsson.se> Date: Mon, 07 Apr 2003 08:51:57 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sipping@ietf.org, Rohan Mahy Subject: Re: [Sipping] Questions on connect-reuse References: <3E802C1F.6EF210E@lmf.ericsson.se> <3E8D5F19.8@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Gonzalo, Thanks for the reply! Comments inline. > >Q1. > > > >Why is the reason the "alias" parameter is put in the Via header? Isn't > >the Via used for response routing only? Wouldn't it fit better as a > >header (or URI) parameter used in the Contact- and Record-Route headers > >instead? > > The alias parameter is meaningful between a SIP entity and its next hop > (hop-by-hop) when they have a connection. You cannot tell a server two > hops away to reuse the existing connection you have with it, because you > do not have any existing connection. > > The top-most Via is always from the previous hop. This is not true for > Contact or Record-Route entries. [CHH] Via is used for responses, and assuming response messages are always sent on the same connection where the request came from I am not really sure it's needed for that (of course, the alias data MAY also be in the Via, if needed). The main idea of the "extended" (Rohan's draft) connect-reuse function, as I have understood, is to be able to reuse the connection for all messages, in BOTH directions, during the whole session. So, for that you need to have the alias data also in the route information, so that a node can send a request (in the "backward direction" of the call). And, requests are sent using the route data. > >Q2: > > > >Assume I make a SRV lookup, and I get a list with different server > >addresses. > > > >Now, for one of the returned addresses I have an existing TCP connection > >which I could use. But, I also receive another address, which has higher > >priority. So, which has higher priority: an existing connection, or the > >priority identifier in the SRV response? One may argue this is an > >implementation/local policy/whatever issue, but I think it would be a > >good idea to mention it in the textt. > > If alias is used properly, I would assume that the client would place a > host name in the Via entry with the alias parameter. This way, the other > SIP entity will not even perform the DNS lookup. It will have the > exisintg TCP connection indexed using the host name. [CHH] Like I said, the data is also needed in the route information. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 7 03:16:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05091 for ; Mon, 7 Apr 2003 03:16:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h377KQl17325 for sipping-archive@odin.ietf.org; Mon, 7 Apr 2003 03:20:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h377KP817322 for ; Mon, 7 Apr 2003 03:20:25 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05086 for ; Mon, 7 Apr 2003 03:15:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h377JP817256; Mon, 7 Apr 2003 03:19:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h377Hj817221 for ; Mon, 7 Apr 2003 03:17:45 -0400 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05030 for ; Mon, 7 Apr 2003 03:13:06 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h377FbRs029358; Mon, 7 Apr 2003 09:15:38 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4SPM6G; Mon, 7 Apr 2003 09:15:38 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h377FcAv023346; Mon, 7 Apr 2003 10:15:38 +0300 (EET DST) Message-ID: <3E912599.3000606@lmf.ericsson.se> Date: Mon, 07 Apr 2003 10:15:37 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Watson CC: Tom-PT Taylor , sipping@ietf.org, Jon Peterson Subject: Re: [Sipping] Early media; philosophical discussion References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Mark, you are commenting my arguments, but not refuting them or providing compelling arguments in favor of placing that indication in the SIP layer instead. > This is not an architectural argument, but a treatment of the specific > issue of media clipping. I will try to re-phrase the argument so that it is clearer. I believe I might know what your "in-principle" concern comes from. SIP signalling, because of its nature (loosely coupled with the media) cannot be used to signal things that take place in real-time in the media path (e.g., sudden resume of the media traffic). SIP is not suitable for that because you cannot be sure whether or not your signalling message will reach the remote end before the event in the media path (e.g., arrival of media) happens. That much to argue that SIP is not the proper place for a "there is media coming" indication. Now, you said that you "feel" that such an indication belong to the signalling plane (explicit), rather than to the media plane (implicit)... and I agree with you on this. I believe that the confusion comes from the fact that when SIP is used to establish RTP/UDP sessions, there is only one signalling layer (i.e., SIP/SDP). But this is not true in general. Generally speaking, you want to have two layers of signalling. One is SIP/SDP. It is useful for things like locating the remote user, rendezvous, etc... SIP is supposed to provide the remote end with all the information it needs to establish the session. The second signalling layer takes care of establishing the actual session using the information that SIP/SDP have provided. This signalling layer does not exist in RTP/UDP, but it does in TCP (three-way handshake). And if you take SCTP, for instance, you will see that it has much more functionality than in TCP. It deals with fail-over, multihoming, multistreaming, etc... Therefore, what you want is something like DCCP, that adds a layer of control to RTP. If we think that in addition to knowing the state of the media tools (SIP/SDP), it is useful to know whether or not the other end intends to send media in order to drive GUIs, we could send this requirement to the DCCP folks. Conclusion: the indication you are asking for architecturaly belongs to the signalling plane, but not to SIP. It belongs to a protocol that is tighly coupled with the media stream. Mark, am I starting to understand your "in-principle" concerns or am I still far away from that ;o) Gonzalo Mark Watson wrote: > Gonzalo, > > Inline... > > Gonzalo wrote: > > Hi Mark, > > > > Mark wrote: > > > so I guess I am now arguing more from an > > > 'in principle' position. > > > > Good. Given that there are no use cases, let's discuss > > "philosophically" > > in which layer the presence or absence of media should be signalled; > > signalling or media level. > > > > I did not say there were no use cases. You're selectively quoting me. > Nice try though :-) > > I'll admit that the use-case I described (Q.SIG/Q.931 interworking) > might not be sufficiently important on its own to motivate this > indication - that doesn't mean there are no use-cases. But I believe the > principle should lead us to expect more use-cases to be identified in > future. > > > The discussion could be formulated as follows: > > > > At the signalling level (SIP/SDP), we already have the SDP direction > > attributes, that tell the status (on/off) of the media tools. > > When the > > media tools are on (e.g., sendrecv stream), we do not know > > whether there > > really is media flowing between both ends. Should we detect > > the presence > > of media on the media layer (RTP) or signal it on the > > signalling layer > > (SIP)? > > > > Well, perhaps we *are* repeating the discussion on sendrecv/inactive. I > must say it is not entirely clear to me what it means for a stream to be > in sendrecv mode but for there to be no media being sent i.e. there is > no implementation-independent definition of what these 'media tools' are > and what it means for them to be 'on' or 'off'. We can only presume that > 'on' means that the device is in some sense 'ready' to send or receive. > But what does it mean to the UAC that the UAS is 'ready' to send media ? > How is this different for the UAC from the state where the UAS is 'not > ready' to send media ? > > What is important is whether media is actually being sent - this > information is not available at the signalling layer. > > > > I claim that we do not need further information (in addition > > to on/off) > > in the signalling layer. My initial arguments are: > > > > o When the signalling layer says that there will be media, everything > > works fine. However, when the signalling layer says that > > there will NOT > > be media, it is not reliable. Since the next signalling > > message saying > > that media will resume may arrive later than the actual > > (resumed) media > > packets, either you perform media detection at the media > > layer *anyway* > > or have media clipping. This seems to indicate that the media > > layer is > > the proper place to detect presence or absence of media, > > since half of > > the time you end up doing it there even with a > > signalling-layer indication. > > > > This is not an architectural argument, but a treatment of the specific > issue of media clipping. Your description makes assumptions which, > conveniently, lead to the conclusion that the indication is not needed. > For example the assumption that local policy allows media to be played > indepedently of the session state. This assumption is not fundamental to > SIP - I think whether media should be played or not at any given time is > a local issue for the UA. > > > o The rules of protocol design say that a protocol can be considered > > good when you cannot get rid of anything else (KISS) as long as the > > protocol provides the expected functionality. That is, > > protocol design > > consists of removing useless features rather than adding them. In our > > case, we can get rid (by not creating it) of the flag while providing > > the same level of functionality and requiring a very similar > > processing > > power and badwidth consumption. Why would we want to add > > something that > > does not bring any visible gain? > > > > Well, obviously, if I thought there was no gain at all I wouldn't be > advocating it. I'm not just trying to waste everyone's time. > > I agree that this indication is available at the media layer in the form > of RTP packet arrival (btw, we are assuming it will be available at the > media layer in all cases, whereas SIP is supposed to be agnostic about > what the media layer, described by the SDP, is/does - I'm not saying I > have an example in which this indication is not available, but it is not > inconceivable that there could be no difference at the media layer > between "no media being sent" and "media being sent, but happens to be > 'silent'" in some sense - 'silent' could mean many things in the context > of media other than voice/audio). > > All you've argued above is that 'this is available at the media layer > and so would be redundant if added to the signalling layer as well', but > this is only true with some assumptions about the communication > available between media and signalling layers and assumptions that the > communication at media and signalling layers have similar properties in > terms of security, reliability etc. > > ...Mark > > > > Cheers, > > > > Gonzalo > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 7 03:39:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06348 for ; Mon, 7 Apr 2003 03:39:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h377hnH18887 for sipping-archive@odin.ietf.org; Mon, 7 Apr 2003 03:43:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h377hm818884 for ; Mon, 7 Apr 2003 03:43:48 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06314 for ; Mon, 7 Apr 2003 03:39:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h377hB818851; Mon, 7 Apr 2003 03:43:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h377g5818787 for ; Mon, 7 Apr 2003 03:42:05 -0400 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06126 for ; Mon, 7 Apr 2003 03:37:27 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h377dwRs007594; Mon, 7 Apr 2003 09:39:58 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A40Y0GF; Mon, 7 Apr 2003 09:39:56 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h377dtAv024837; Mon, 7 Apr 2003 10:39:55 +0300 (EET DST) Message-ID: <3E912B4A.5070505@lmf.ericsson.se> Date: Mon, 07 Apr 2003 10:39:54 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: Mark Watson , Tom-PT Taylor , sipping@ietf.org, Jon Peterson Subject: Q.931 question WAS Re: [Sipping] Early media; a summary after the IETF References: <475FF955A05DD411980D00508B6D5FB0081DB718@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Keith, > In the absence of progress indicator #1, the phone has the freedom to > generate either a local ringing tone, or to provide the tone that is > available in-band. > > The progress indicator #1 does not indicate the presence of such a > tone or announcement, rather it indicates that one should listen to > it and not generate a local ringing tone. Do you know of any particular example of a phone that generates its own local ringing tone? As far as I know, not even GSM phones do that. Thanks, Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 7 03:52:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07300 for ; Mon, 7 Apr 2003 03:52:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h377usJ19921 for sipping-archive@odin.ietf.org; Mon, 7 Apr 2003 03:56:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h377us819918 for ; Mon, 7 Apr 2003 03:56:54 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07248 for ; Mon, 7 Apr 2003 03:52:16 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h377r5819599; Mon, 7 Apr 2003 03:53:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h377pb819309 for ; Mon, 7 Apr 2003 03:51:37 -0400 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06826 for ; Mon, 7 Apr 2003 03:46:58 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h377nSRs010656; Mon, 7 Apr 2003 09:49:28 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4SPWNB; Mon, 7 Apr 2003 09:49:28 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h377nSAv025658; Mon, 7 Apr 2003 10:49:28 +0300 (EET DST) Message-ID: <3E912D87.4070309@lmf.ericsson.se> Date: Mon, 07 Apr 2003 10:49:27 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: sipping@ietf.org, Rohan Mahy Subject: Re: [Sipping] Questions on connect-reuse References: <3E802C1F.6EF210E@lmf.ericsson.se> <3E8D5F19.8@lmf.ericsson.se> <3E9111FD.993C2F93@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christer, the client wants the server to create an alias even if the server never sends requests back to the client within this dialog. The server may send requests that belong to different dialogs, for instance. Therefore, you argument in favor of Route loses its stregth. In addition to that, having that information in the Via header field is quite good from the processing point of view. When you receive a request, you parse the Via header field to add a received parameter, for instance... it seems like a good time for creating the alias. Gonzalo Christer Holmberg wrote: > Hi Gonzalo, > > Thanks for the reply! Comments inline. > > >>>Q1. >>> >>>Why is the reason the "alias" parameter is put in the Via header? Isn't >>>the Via used for response routing only? Wouldn't it fit better as a >>>header (or URI) parameter used in the Contact- and Record-Route headers >>>instead? >> >>The alias parameter is meaningful between a SIP entity and its next hop >>(hop-by-hop) when they have a connection. You cannot tell a server two >>hops away to reuse the existing connection you have with it, because you >>do not have any existing connection. >> >>The top-most Via is always from the previous hop. This is not true for >>Contact or Record-Route entries. > > > [CHH] Via is used for responses, and assuming response messages are always > sent on the same connection where the request came from I am not really sure > it's needed for that (of course, the alias data MAY also be in the Via, if > needed). > > The main idea of the "extended" (Rohan's draft) connect-reuse function, as I > have understood, is to be able to reuse the connection for all messages, in > BOTH directions, during the whole session. So, for that you need to have the > alias data also in the route information, so that a node can send a request > (in the "backward direction" of the call). And, requests are sent using the > route data. > > >>>Q2: >>> >>>Assume I make a SRV lookup, and I get a list with different server >>>addresses. >>> >>>Now, for one of the returned addresses I have an existing TCP connection >>>which I could use. But, I also receive another address, which has higher >>>priority. So, which has higher priority: an existing connection, or the >>>priority identifier in the SRV response? One may argue this is an >>>implementation/local policy/whatever issue, but I think it would be a >>>good idea to mention it in the textt. >> >>If alias is used properly, I would assume that the client would place a >>host name in the Via entry with the alias parameter. This way, the other >>SIP entity will not even perform the DNS lookup. It will have the >>exisintg TCP connection indexed using the host name. > > > [CHH] Like I said, the data is also needed in the route information. > > Regards, > > Christer Holmberg > Ericsson Finland > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 7 03:59:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07678 for ; Mon, 7 Apr 2003 03:59:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3783EO20559 for sipping-archive@odin.ietf.org; Mon, 7 Apr 2003 04:03:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3783D820556 for ; Mon, 7 Apr 2003 04:03:13 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07659 for ; Mon, 7 Apr 2003 03:58:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h377u9819890; Mon, 7 Apr 2003 03:56:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h377tF819833 for ; Mon, 7 Apr 2003 03:55:15 -0400 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07128 for ; Mon, 7 Apr 2003 03:50:36 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h377r5I3009093; Mon, 7 Apr 2003 09:53:05 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A40ZD7H; Mon, 7 Apr 2003 09:53:06 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h377r5Av025876; Mon, 7 Apr 2003 10:53:06 +0300 (EET DST) Message-ID: <3E912E60.1000804@lmf.ericsson.se> Date: Mon, 07 Apr 2003 10:53:04 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cary FitzGerald CC: Mark Watson , Tom-PT Taylor , sipping@ietf.org, Jon Peterson Subject: RTCP question WAS Re: [Sipping] Early media; a summary after the IETF References: <167243563.1049668401@[192.168.1.101]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, RTCP is mandatory, and it MUST be sent. RTCP is useful to perform inter-media synchronization, to monitor the quality of the transmission and to elaborate statistics. Further RTCP discussions can take place in MMUSIC, if needed. Gonzalo Cary FitzGerald wrote: > Can you point out where in RFC1889/1890 RTCP is described as optional? > RTCP has a number of uses; this is one. > > Cary. > >>> You have RTCP. The sending side will always know whether there is >>> an error. What you are proposing does not actually help >>> debugging. Let's say my SIP phone sends you a signalling message >>> saying "I will be sending media", but I remain silent in front of >>> my >>> microphone... now you >>> will think that there is an error in the network, when everything >>> is perfectly normal. >> >> >> Well, RTCP is optional. The fact that there may not be RTP packets >> when in fact the sender is intending to send media (it just happens >> to be silent) surely argues that using the presence/absence of RTP >> to indicate the media status is even more unreliable! > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 7 05:10:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12069 for ; Mon, 7 Apr 2003 05:10:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h379EOe26214 for sipping-archive@odin.ietf.org; Mon, 7 Apr 2003 05:14:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h379EO826211 for ; Mon, 7 Apr 2003 05:14:24 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12001 for ; Mon, 7 Apr 2003 05:09:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h379Dl826185; Mon, 7 Apr 2003 05:13:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h379Cf826128 for ; Mon, 7 Apr 2003 05:12:41 -0400 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11973 for ; Mon, 7 Apr 2003 05:08:00 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h379AVRs012012; Mon, 7 Apr 2003 11:10:31 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4LZNYR; Mon, 7 Apr 2003 11:10:32 +0200 Received: from lmf.ericsson.se ([131.160.31.93]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h379AWAv001789; Mon, 7 Apr 2003 12:10:32 +0300 (EET DST) Message-ID: <3E914087.E152F307@lmf.ericsson.se> Date: Mon, 07 Apr 2003 12:10:31 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sipping@ietf.org, Rohan Mahy Subject: Re: [Sipping] Questions on connect-reuse References: <3E802C1F.6EF210E@lmf.ericsson.se> <3E8D5F19.8@lmf.ericsson.se> <3E9111FD.993C2F93@lmf.ericsson.se> <3E912D87.4070309@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > the client wants the server to create an alias even if the server never > sends requests back to the client within this dialog. The server may > send requests that belong to different dialogs, for instance. Therefore, > you argument in favor of Route loses its stregth. > > In addition to that, having that information in the Via header field is > quite good from the processing point of view. When you receive a > request, you parse the Via header field to add a received parameter, for > instance... it seems like a good time for creating the alias. True. Another question: Assume the connection goes down between two servers. Now, both create a new connection at the same time, so we will have two connections between the servers (this scenario is what the connect-reuse extension is supposed to avoid). Now, is this something we should accept as something which can happen? I don't think we can say that one of the servers to close one of the connections, because we don't know which server would do it, and we don't know which connection it would close... And, since there are now two connections between the node, is there any priority on which should be used when a request is sent: the connection (which our server created) to the "real" port (which would be used if there was no existing connection) of the other server, or the connection (created by the remote server) to the emphemeral port of the other server? Another question: RFC3261 basically talks about re-use of connections in one direction. Also, RFC3261 doesn't say (I appologise if it does and I missed it) anything about port overriding ("use the connection even if the port of your lookup is different") which the connect-reuse draft says. So, I would just like to confirm that it means that a RFC3261 node, NOT supporting the connect-reuse extension, should send requests to whatever port is has recieved, no matter if a connection already exists to the same IP address, but another port? Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 7 17:25:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06464 for ; Mon, 7 Apr 2003 17:25:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37LUL314859 for sipping-archive@odin.ietf.org; Mon, 7 Apr 2003 17:30:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37LUL814856 for ; Mon, 7 Apr 2003 17:30:21 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06405 for ; Mon, 7 Apr 2003 17:25:26 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37LTJ814791; Mon, 7 Apr 2003 17:29:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37LRV814724 for ; Mon, 7 Apr 2003 17:27:31 -0400 Received: from rtp-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06324 for ; Mon, 7 Apr 2003 17:22:36 -0400 (EDT) Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h37LP7do028082; Mon, 7 Apr 2003 17:25:08 -0400 (EDT) Received: from cisco.com ([161.44.79.220]) by cannon.cisco.com (Mirapoint) with ESMTP id ABG85288; Mon, 7 Apr 2003 17:33:51 -0400 (EDT) Message-ID: <3E91ECB2.8030101@cisco.com> Date: Mon, 07 Apr 2003 17:25:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston CC: sipping@ietf.org Subject: Re: [Sipping] New Versions of Call Flows I-Ds References: <5.1.1.6.0.20030406211253.01d4fcb8@pop.mcit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alan Johnston wrote: > All, > > I've just submitted new versions of the basic and PSTN call flows > documents. The updates are mainly minor wording changes based on IESG > feedback. > > However, I have added a new flow in the PSTN Call Flows showing ENUM in > Section 2.4. I would greatly appreciate if the working group could look > over that flow (which I have reproduced below for your convenience...) Alan, I have one question about this flow. You have the INVITE containing To: which is the chosen result from the ENUM lookup. My feeling is that this address should be used as the request uri, but that the To uri would be better as . The reason is that what the user requested was just the telephone number, not that specific routing of the number through b.example.com. While the mechanics of ENUM are different, this transformation is logically similar to a redirection. Normally a redirection changes the request uri, but leaves To: unchanged. So in this case, I think using a tel: in the To header would more accurately reflect what is going on. An example of when this might matter is if bob didn't answer the call and it was then forwarded to charlie. Charlie's phone could be smart enough to identify calls that aren't addressed To charlie, and pop up a display indicating the intended destination. If the To: is a tel: uri, then it can be formatted nicely as a phone number. If the number is a sip uri, then the phone will likely have to present it that way, which isn't very user friendly. Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 7 20:41:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12326 for ; Mon, 7 Apr 2003 20:41:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h380k9Z27807 for sipping-archive@odin.ietf.org; Mon, 7 Apr 2003 20:46:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h380k9827804 for ; Mon, 7 Apr 2003 20:46:09 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12300 for ; Mon, 7 Apr 2003 20:41:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h380jS827781; Mon, 7 Apr 2003 20:45:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h380iU827741 for ; Mon, 7 Apr 2003 20:44:30 -0400 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12278 for ; Mon, 7 Apr 2003 20:39:31 -0400 (EDT) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h380fp015858; Mon, 7 Apr 2003 19:41:51 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2J0VSXYN>; Mon, 7 Apr 2003 17:41:51 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D207ADD9FD@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Gonzalo Camarillo'" Cc: "'Michael Hammer'" , "Tom-PT Taylor" , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" , "Mark Watson" Subject: RE: [Sipping] New version of the early media draft Date: Mon, 7 Apr 2003 17:41:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FD67.A1A38624" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FD67.A1A38624 Content-Type: text/plain So your answer is that every SIP implemenation out there would need to include a join header in every INVITE they send if they want to be able to receive early media using the application server approach? This would apply even when there is no application server doing early media, because the endpoint doesn't know in advance. This seems to me to be very not backward compatible. Especially if forking forces the use of this procedure. > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Friday, April 04, 2003 22:04 > To: Audet, Francois [SC100:4K02:EXCH] > Cc: 'Michael Hammer'; Taylor, Tom-PT [CAR:5N00:EXCH]; 'Bob > Penfield'; 'sipping@ietf.org'; 'Jon PETERSON > (Jon.Peterson@neustar.com)'; 'Christer Holmberg'; Watson, > Mark [MOP:EP10:EXCH] > Subject: Re: [Sipping] New version of the early media draft > > > As I said in a separate note, the idea is not use the > mechanism that the > application interaction design team develops. Since all the > UACs would > eventually like to be able to interact with whatever is in > the network > (e.g., introduce a pin number so that your call can proceed), > this will > be a widespread feature. ------_=_NextPart_001_01C2FD67.A1A38624 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] New version of the early media draft

So your answer is that every SIP implemenation out = there would need to
include a join header in every INVITE they send if = they want to be able to
receive early media using the application server = approach? This
would apply even when there is no application server = doing early media,
because the endpoint doesn't know in advance.

This seems to me to be very not backward compatible. = Especially if
forking forces the use of this procedure.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: Friday, April 04, 2003 22:04
> To: Audet, Francois [SC100:4K02:EXCH]
> Cc: 'Michael Hammer'; Taylor, Tom-PT = [CAR:5N00:EXCH]; 'Bob
> Penfield'; 'sipping@ietf.org'; 'Jon PETERSON =
> (Jon.Peterson@neustar.com)'; 'Christer = Holmberg'; Watson,
> Mark [MOP:EP10:EXCH]
> Subject: Re: [Sipping] New version of the early = media draft
>
>
> As I said in a separate note, the idea is not = use the
> mechanism that the
> application interaction design team develops. = Since all the
> UACs would
> eventually like to be able to interact with = whatever is in
> the network
> (e.g., introduce a pin number so that your call = can proceed),
> this will
> be a widespread feature.

------_=_NextPart_001_01C2FD67.A1A38624-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 7 20:57:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12707 for ; Mon, 7 Apr 2003 20:57:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3811tm28270 for sipping-archive@odin.ietf.org; Mon, 7 Apr 2003 21:01:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3811t828267 for ; Mon, 7 Apr 2003 21:01:55 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12698 for ; Mon, 7 Apr 2003 20:56:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3811F828234; Mon, 7 Apr 2003 21:01:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3810m828201 for ; Mon, 7 Apr 2003 21:00:48 -0400 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12680 for ; Mon, 7 Apr 2003 20:55:49 -0400 (EDT) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h380wEj12753; Mon, 7 Apr 2003 17:58:14 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2J0VSYWL>; Mon, 7 Apr 2003 17:58:14 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D207ADDA3B@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Gonzalo Camarillo'" Cc: "'Christer Holmberg'" , "Mark Watson" , "Tom-PT Taylor" , "'sipping@ietf.org'" , "'Jon Peterson'" Subject: RE: [Sipping] Early media; philosophical discussion Date: Mon, 7 Apr 2003 17:58:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FD69.EABDFF0E" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FD69.EABDFF0E Content-Type: text/plain What I am proposing is that there should be a mechanism in the INVITE to tell the gateway NOT to provide early media (at least for ringing). This would solve a lot of problems including the forking problem. I don't see why this would be difficult to do. There is no such thing as early ringing media that is essential to the call when forking occurs because the endpoint receiving it will not be able to play it. The gateway would do one of the following upon receiving the no-early-ringing indication: 1 - Not send early ringing if it knows he difference between early ringing and early media-to-avoid-clipping. This is possible only in certain cases, for example when the gateway itself is providing the ringing (for example if the gateway is a PBX or Public Exchange and the call terminates to a phone on the switch). This method when applicable, is preferred because it will avoid any possibility of clipping the "hello". 2 - Not send any early media at all. This is when the gateway does not know the difference between early ringing and early media-to-avoid-clipping (for example, when the media is provide by another circuit-switch upstream, when there is tandeming over the PSTN). The gateway will only "cut-through" when the connection indication is received. Note that there is a possibility of clipping part of the "hello" under certain circumstances (as we discussed earlier): however, this possibility would happen anyways since there is no way for the receiver to distinguish between various overlapping streams. And yes, for the Native SIP (non-gateway) early media, we could use your application server model. I agree on that (although it would be nice if we didn't need to include the join header in all calls, and if somehow the application server could handle it). > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Friday, April 04, 2003 22:16 > To: Audet, Francois [SC100:4K02:EXCH] > Cc: 'Christer Holmberg'; Watson, Mark [MOP:EP10:EXCH]; > Taylor, Tom-PT [CAR:5N00:EXCH]; 'sipping@ietf.org'; 'Jon Peterson' > Subject: Re: [Sipping] Early media; philosophical discussion > > > Francois, > > I have already answered this one in another note (I believe I sent it > yesterday). The gateway model is appropriate when the UAS is > not the one > "generating" the early media. This means that, a gateway cannot know > whether the early media is optional or not. A gateway does not know > whether the early media it is receiving from the > circuit-switched part > is optional or is essential to the call. Therefore, even if > this gateway > receives an indication from in the INVITE saying that the requested > forked, the gateway CANNOT DO ANYTHING. It needs to send the > media anyway. > > However, a pure SIP UAS knows that what it is about to generate is a > message that says "Thanks for calling Francois, please wait". > Therefore, > it sends a separate INVITE (application server model), which > the UAC can > refuse if it is already overloaded with other stuff. ------_=_NextPart_001_01C2FD69.EABDFF0E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] Early media; philosophical discussion

What I am proposing is that there should be a = mechanism in the INVITE to tell the
gateway NOT to provide early media (at least for = ringing). This would solve a lot of
problems including the forking problem.

I don't see why this would be difficult to do. There = is no such thing as
early ringing media that is essential to the call = when forking occurs because
the endpoint receiving it will not be able to play = it.

The gateway would do one of the following upon = receiving the no-early-ringing
indication:

1 - Not send early ringing if it knows he difference = between early ringing
    and early = media-to-avoid-clipping. This is possible only in certain cases,
    for example when the gateway = itself is providing the ringing (for example
    if the gateway is a PBX or Public = Exchange and the call terminates to a
    phone on the switch). This method = when applicable, is preferred because
    it will avoid any possibility of = clipping the "hello".

2 - Not send any early media at all. This is when the = gateway does not know
    the difference between early = ringing and early media-to-avoid-clipping
    (for example, when the media is = provide by another circuit-switch upstream,
    when there is tandeming over the = PSTN). The gateway will only "cut-through"
    when the connection indication is = received. Note that there is a possibility
    of clipping part of the = "hello" under certain circumstances (as we discussed
    earlier): however, this = possibility would happen anyways since there is no
    way for the receiver to = distinguish between various overlapping streams.


And yes, for the Native SIP (non-gateway) early = media, we could use your application
server model. I agree on that (although it would be = nice if we didn't need to include
the join header in all calls, and if somehow the = application server could handle it).

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: Friday, April 04, 2003 22:16
> To: Audet, Francois [SC100:4K02:EXCH]
> Cc: 'Christer Holmberg'; Watson, Mark = [MOP:EP10:EXCH];
> Taylor, Tom-PT [CAR:5N00:EXCH]; = 'sipping@ietf.org'; 'Jon Peterson'
> Subject: Re: [Sipping] Early media; = philosophical discussion
>
>
> Francois,
>
> I have already answered this one in another = note (I believe I sent it
> yesterday). The gateway model is appropriate = when the UAS is
> not the one
> "generating" the early media. This = means that, a gateway cannot know
> whether the early media is optional or not. A = gateway does not know
> whether the early media it is receiving from = the
> circuit-switched part
> is optional or is essential to the call. = Therefore, even if
> this gateway
> receives an indication from in the INVITE = saying that the requested
> forked, the gateway CANNOT DO ANYTHING. It = needs to send the
> media anyway.
>
> However, a pure SIP UAS knows that what it is = about to generate is a
> message that says "Thanks for calling = Francois, please wait".
> Therefore,
> it sends a separate INVITE (application server = model), which
> the UAC can
> refuse if it is already overloaded with other = stuff.

------_=_NextPart_001_01C2FD69.EABDFF0E-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 7 21:12:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12996 for ; Mon, 7 Apr 2003 21:12:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h381Gwm29608 for sipping-archive@odin.ietf.org; Mon, 7 Apr 2003 21:16:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h381Gv829605 for ; Mon, 7 Apr 2003 21:16:57 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12976 for ; Mon, 7 Apr 2003 21:11:57 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h381GA829574; Mon, 7 Apr 2003 21:16:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h381Fs829544 for ; Mon, 7 Apr 2003 21:15:54 -0400 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12960 for ; Mon, 7 Apr 2003 21:10:54 -0400 (EDT) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h381DLj14604; Mon, 7 Apr 2003 18:13:21 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2J0VSZ13>; Mon, 7 Apr 2003 18:13:06 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D207ADDA64@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Gonzalo Camarillo'" , "'Drage, Keith (Keith)'" Cc: "Mark Watson" , "Tom-PT Taylor" , "'sipping@ietf.org'" , "'Jon Peterson'" Subject: RE: Q.931 question WAS Re: [Sipping] Early media; a summary after the IETF Date: Mon, 7 Apr 2003 18:13:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FD6C.013F2FEE" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FD6C.013F2FEE Content-Type: text/plain > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Monday, April 07, 2003 00:40 > To: Drage, Keith (Keith) > Cc: Watson, Mark [MOP:EP10:EXCH]; Taylor, Tom-PT > [CAR:5N00:EXCH]; sipping@ietf.org; Jon Peterson > Subject: Q.931 question WAS Re: [Sipping] Early media; a > summary after the IETF > > > Keith, > > > In the absence of progress indicator #1, the phone has the > freedom to > generate either a local ringing tone, or to > provide the tone that is > available in-band. > > The > progress indicator #1 does not indicate the presence of such > a > tone or announcement, rather it indicates that one > should listen to > it and not generate a local ringing tone. > > Do you know of any particular example of a phone that > generates its own > local ringing tone? As far as I know, not even GSM phones do that. Gonzallo, this is what typically happens: - PBX receives an ALERTING message with no Progress indicator (and no PI where sent before the ALERTING in other messages such as PROGRESS). - PBX then connects the phone to a LOCAL tone generator and provides the tone inband to the phone. - There is no in-band media on the trunk. Now, it would be perfectly legal for the PBX to tell the phone to provide its own tone (this would assume a phone that has the capability to do so). I don't know if any digital (not IP) phone does this, but it is possible. Finally, in the same scenario, substitute an IP phone to the digital phone, controlled with a proprietary protocol or something like MEGACO/MGCP. In that case, the PBX would normally instruct the phone to play its own ringing tone. I can garantee you that this happens all the time. So yes, IP phones (at least) can generate their own inband tones. ------_=_NextPart_001_01C2FD6C.013F2FEE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Q.931 question WAS Re: [Sipping] Early media; a summary = after the IETF

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: Monday, April 07, 2003 00:40
> To: Drage, Keith (Keith)
> Cc: Watson, Mark [MOP:EP10:EXCH]; Taylor, = Tom-PT
> [CAR:5N00:EXCH]; sipping@ietf.org; Jon = Peterson
> Subject: Q.931 question WAS Re: [Sipping] Early = media; a
> summary after the IETF
>
>
> Keith,
>
>  > In the absence of progress indicator = #1, the phone has the
> freedom to  > generate either a local = ringing tone, or to
> provide the tone that is  > available = in-band.  >  > The
> progress indicator #1 does not indicate the = presence of such
> a  > tone or announcement, rather it = indicates that one
> should listen to  > it and not generate = a local ringing tone.
>
> Do you know of any particular example of a = phone that
> generates its own
> local ringing tone? As far as I know, not even = GSM phones do that.

Gonzallo, this is what typically happens:
- PBX receives an ALERTING message with no Progress = indicator (and no PI where
  sent before the ALERTING in other messages = such as PROGRESS).
- PBX then connects the phone to a LOCAL tone = generator and provides the tone
  inband to the phone.
- There is no in-band media on the trunk.

Now, it would be perfectly legal for the PBX to tell = the phone to provide its
own tone (this would assume a phone that has the = capability to do so). I
don't know if any digital (not IP) phone does this, = but it is possible.

Finally, in the same scenario, substitute an IP phone = to the digital phone,
controlled with a proprietary protocol or something = like MEGACO/MGCP. In that
case, the PBX would normally instruct the phone to = play its own ringing tone.
I can garantee you that this happens all the = time.

So yes, IP phones (at least) can generate their own = inband tones.

------_=_NextPart_001_01C2FD6C.013F2FEE-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 7 21:34:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13463 for ; Mon, 7 Apr 2003 21:34:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h381ct831214 for sipping-archive@odin.ietf.org; Mon, 7 Apr 2003 21:38:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h381ct831211 for ; Mon, 7 Apr 2003 21:38:55 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13439 for ; Mon, 7 Apr 2003 21:33:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h381cL831172; Mon, 7 Apr 2003 21:38:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h381YO830219 for ; Mon, 7 Apr 2003 21:34:24 -0400 Received: from pmesmtp01.wcom.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13378 for ; Mon, 7 Apr 2003 21:29:24 -0400 (EDT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HD000JAN48JZC@firewall.wcom.com> for sipping@ietf.org; Tue, 08 Apr 2003 01:31:31 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HD00080148I4W@pmismtp01.wcomnet.com>; Tue, 08 Apr 2003 01:31:31 +0000 (GMT) Received: from xs578v3521.wcom.com ([166.50.97.242]) by pmismtp01.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HD00054C48GVX@pmismtp01.wcomnet.com>; Tue, 08 Apr 2003 01:31:30 +0000 (GMT) Date: Mon, 07 Apr 2003 20:31:28 -0500 From: Alan Johnston Subject: Re: [Sipping] New Versions of Call Flows I-Ds In-reply-to: <3E91ECB2.8030101@cisco.com> X-Sender: Alan.Johnston@pop.mcit.com To: Paul Kyzivat Cc: sipping@ietf.org Message-id: <5.1.1.6.0.20030407202815.020d6ea0@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed References: <5.1.1.6.0.20030406211253.01d4fcb8@pop.mcit.com> Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Paul, Thanks very much for your review of the flow. I agree with you that making the To URI a tel shows the "redirection" that is taking place using ENUM more clearly. This change could be made elsewhere in the document but unlike this case, it doesn't add much value or clarity. I'll go ahead and make the change to this flow unless someone thinks this is a bad idea. Thanks, Alan Johnston WorldCom sip:alan@digitalari.com At 05:25 PM 4/7/2003 -0400, Paul Kyzivat wrote: >Alan Johnston wrote: >>All, >>I've just submitted new versions of the basic and PSTN call flows >>documents. The updates are mainly minor wording changes based on IESG >>feedback. >>However, I have added a new flow in the PSTN Call Flows showing ENUM in >>Section 2.4. I would greatly appreciate if the working group could look >>over that flow (which I have reproduced below for your convenience...) > >Alan, > >I have one question about this flow. You have the INVITE containing > > To: > >which is the chosen result from the ENUM lookup. My feeling is that this >address should be used as the request uri, but that the To uri would be >better as . > >The reason is that what the user requested was just the telephone number, >not that specific routing of the number through b.example.com. While the >mechanics of ENUM are different, this transformation is logically similar >to a redirection. Normally a redirection changes the request uri, but >leaves To: unchanged. So in this case, I think using a tel: in the To >header would more accurately reflect what is going on. > >An example of when this might matter is if bob didn't answer the call and >it was then forwarded to charlie. Charlie's phone could be smart enough to >identify calls that aren't addressed To charlie, and pop up a display >indicating the intended destination. If the To: is a tel: uri, then it can >be formatted nicely as a phone number. If the number is a sip uri, then >the phone will likely have to present it that way, which isn't very user >friendly. > > Paul _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 00:01:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16088 for ; Tue, 8 Apr 2003 00:01:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38465o06580 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 00:06:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38465806577 for ; Tue, 8 Apr 2003 00:06:05 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16083 for ; Tue, 8 Apr 2003 00:01:01 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3845N806564; Tue, 8 Apr 2003 00:05:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3841Z806441 for ; Tue, 8 Apr 2003 00:01:35 -0400 Received: from peoplemail.com.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15969 for ; Mon, 7 Apr 2003 23:55:56 -0400 (EDT) From: moonclimber@peoplemail.com.cn Received: from peoplemail.com.cn([127.0.0.1]) by peoplemail.com.cn(JetMail 2.5.3.0) with SMTP id jm43e92629c; Tue, 8 Apr 2003 03:56:57 -0000 Content-Type: text/plain Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: Date: Tue, 8 Apr 2003 11:56:54 +0800 (CST) To: sipping@ietf.org X-Priority: 3 Content-Transfer-Encoding: 8bit Subject: [Sipping] Some comments on draft service-examples Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi all, 1) I think this is a error: Call Pickup service , in the message "F3 SUBSCRIBE", the method name of SUBSCRIBE should be "SUBSCRIBE" , not "INVITE". 2) I have read draft-ietf-sipping-dialog-package-01, I can not find an attribute named remote-uri in ELEMENT dialog, while in service-examples, it shows: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Where is the defination of the attribute remote-uri ? Have I missing something? early 3) Why "F14 NOTIFY" request will receive a response 481? As I know, the subscription created by F3 SUBSCRIBE does not terminated until F14 receives. So , I think "Carol" will give "Bob" a response "200 OK" to "F14 NOTIFY". Is it wrong? Thanks to clarify me. ------------------------------------------------------------------ ȨÍþµ÷ÖÆ ÐÂÎÅ¿ì²Í£»ÓÑÇ黥¶¯ ¶ÌÐÅ´«Çé¡£ »¶Ó­Ôì·ÃÈËÃñÍø¶ÌÐÅƵµÀ£ºhttp://sms.people.com.cn _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 02:13:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29423 for ; Tue, 8 Apr 2003 02:13:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h386HdI25341 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 02:17:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h386Hd825338 for ; Tue, 8 Apr 2003 02:17:39 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29363 for ; Tue, 8 Apr 2003 02:12:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h386Dq825155; Tue, 8 Apr 2003 02:13:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h386C5823994 for ; Tue, 8 Apr 2003 02:12:05 -0400 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25450 for ; Tue, 8 Apr 2003 02:07:00 -0400 (EDT) Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3869RI3024518; Tue, 8 Apr 2003 08:09:27 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4SX573; Tue, 8 Apr 2003 08:09:24 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3869MAv007179; Tue, 8 Apr 2003 09:09:22 +0300 (EET DST) Message-ID: <3E926791.3090300@lmf.ericsson.se> Date: Tue, 08 Apr 2003 09:09:22 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet CC: "'Michael Hammer'" , Tom-PT Taylor , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" , Mark Watson Subject: Re: [Sipping] New version of the early media draft References: <2F1FC1DEA077D5119FAD00508BCFD6D207ADD9FD@zsc3c030.us.nortel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Francois, the backwards compatibility issue you are talking about (current SIP UAs do not implement Join header) does not seem to be a big problem for early media specifically. If your UA does not implement it, you will not be able to interact with any application server that uses that framework. Therefore, when the UAS is acting as an application server for the call (interacting with the caller using early media), it makes sense that it is not possible either. And if the UAS intended to send optional early media, it is not a big deal that it cannot be sent, because it was optional. Therefore, you should raise the backwards compatibility issue in the application interaction design team. We are just referencing their stuff. Thanks, Gonzalo Francois Audet wrote: > So your answer is that every SIP implemenation out there would need to > include a join header in every INVITE they send if they want to be able to > receive early media using the application server approach? This > would apply even when there is no application server doing early media, > because the endpoint doesn't know in advance. > > This seems to me to be very not backward compatible. Especially if > forking forces the use of this procedure. > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Friday, April 04, 2003 22:04 > > To: Audet, Francois [SC100:4K02:EXCH] > > Cc: 'Michael Hammer'; Taylor, Tom-PT [CAR:5N00:EXCH]; 'Bob > > Penfield'; 'sipping@ietf.org'; 'Jon PETERSON > > (Jon.Peterson@neustar.com)'; 'Christer Holmberg'; Watson, > > Mark [MOP:EP10:EXCH] > > Subject: Re: [Sipping] New version of the early media draft > > > > > > As I said in a separate note, the idea is not use the > > mechanism that the > > application interaction design team develops. Since all the > > UACs would > > eventually like to be able to interact with whatever is in > > the network > > (e.g., introduce a pin number so that your call can proceed), > > this will > > be a widespread feature. > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 02:13:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29471 for ; Tue, 8 Apr 2003 02:13:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h386I0625368 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 02:18:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h386I0825365 for ; Tue, 8 Apr 2003 02:18:00 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29399 for ; Tue, 8 Apr 2003 02:12:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h386E4825208; Tue, 8 Apr 2003 02:14:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h386Ds825157 for ; Tue, 8 Apr 2003 02:13:55 -0400 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27300 for ; Tue, 8 Apr 2003 02:08:49 -0400 (EDT) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h386BKRs026129; Tue, 8 Apr 2003 08:11:21 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2Q1ZDYJQ; Tue, 8 Apr 2003 08:11:21 +0200 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.31.93]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h386BLAv007481; Tue, 8 Apr 2003 09:11:21 +0300 (EET DST) Message-ID: <3E92680A.353388A6@lmf.ericsson.se> Date: Tue, 08 Apr 2003 09:11:22 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois Audet CC: "'Gonzalo Camarillo'" , Mark Watson , Tom-PT Taylor , "'sipping@ietf.org'" , "'Jon Peterson'" Subject: Re: [Sipping] Early media; philosophical discussion References: <2F1FC1DEA077D5119FAD00508BCFD6D207ADDA3B@zsc3c030.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Just to clairfy your proposal: Since the UAC gateway most likely doesn't know if an INVITE is going to be forked, I assume it would ALWAYS insert this "don't-send-early-media" flag in the INVITE, right? Now, if the UAS is also a gateway (trunking scenario) it would very often not send early media, because it doesn't know the difference you described. So, in this case the early media from one PSTN network would not be sent to the other PSTN network. Or, did I missunderstand your mail? Regards, Christer Holmberg Ericsson Finland Francois Audet wrote: > > > What I am proposing is that there should be a mechanism in the INVITE > to tell the > gateway NOT to provide early media (at least for ringing). This would > solve a lot of > problems including the forking problem. > > I don't see why this would be difficult to do. There is no such thing > as > early ringing media that is essential to the call when forking occurs > because > the endpoint receiving it will not be able to play it. > > The gateway would do one of the following upon receiving the > no-early-ringing > indication: > > 1 - Not send early ringing if it knows he difference between early > ringing > and early media-to-avoid-clipping. This is possible only in > certain cases, > for example when the gateway itself is providing the ringing (for > example > if the gateway is a PBX or Public Exchange and the call terminates > to a > phone on the switch). This method when applicable, is preferred > because > it will avoid any possibility of clipping the "hello". > > 2 - Not send any early media at all. This is when the gateway does not > know > the difference between early ringing and early > media-to-avoid-clipping > (for example, when the media is provide by another circuit-switch > upstream, > when there is tandeming over the PSTN). The gateway will only > "cut-through" > when the connection indication is received. Note that there is a > possibility > of clipping part of the "hello" under certain circumstances (as we > discussed > earlier): however, this possibility would happen anyways since > there is no > way for the receiver to distinguish between various overlapping > streams. > > And yes, for the Native SIP (non-gateway) early media, we could use > your application > server model. I agree on that (although it would be nice if we didn't > need to include > the join header in all calls, and if somehow the application server > could handle it). > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Friday, April 04, 2003 22:16 > > To: Audet, Francois [SC100:4K02:EXCH] > > Cc: 'Christer Holmberg'; Watson, Mark [MOP:EP10:EXCH]; > > Taylor, Tom-PT [CAR:5N00:EXCH]; 'sipping@ietf.org'; 'Jon Peterson' > > Subject: Re: [Sipping] Early media; philosophical discussion > > > > > > Francois, > > > > I have already answered this one in another note (I believe I sent > it > > yesterday). The gateway model is appropriate when the UAS is > > not the one > > "generating" the early media. This means that, a gateway cannot know > > > whether the early media is optional or not. A gateway does not know > > whether the early media it is receiving from the > > circuit-switched part > > is optional or is essential to the call. Therefore, even if > > this gateway > > receives an indication from in the INVITE saying that the requested > > forked, the gateway CANNOT DO ANYTHING. It needs to send the > > media anyway. > > > > However, a pure SIP UAS knows that what it is about to generate is a > > > message that says "Thanks for calling Francois, please wait". > > Therefore, > > it sends a separate INVITE (application server model), which > > the UAC can > > refuse if it is already overloaded with other stuff. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 06:36:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05265 for ; Tue, 8 Apr 2003 06:36:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38AfRS11940 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 06:41:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38AfR811937 for ; Tue, 8 Apr 2003 06:41:27 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05250 for ; Tue, 8 Apr 2003 06:36:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Aek811916; Tue, 8 Apr 2003 06:40:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Abd811761 for ; Tue, 8 Apr 2003 06:37:39 -0400 Received: from auemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05090 for ; Tue, 8 Apr 2003 06:32:27 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h38AYxa09157 for ; Tue, 8 Apr 2003 06:34:59 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Apr 2003 11:34:58 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB0081DBA5C@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Francois Audet , "'Gonzalo Camarillo'" , Mark Watson Cc: Tom-PT Taylor , "'sipping@ietf.org'" , "'Jon Peterson'" Subject: RE: [Sipping] Early media; a summary after the IETF Date: Tue, 8 Apr 2003 11:34:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FDBA.7E2F436A" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FDBA.7E2F436A Content-Type: text/plain As I indicated in another message, this is not strictly true. It depends whether you are sitting at the originating or destination interface. At the originating interface, calls are always accompanied with in-band media. The progress indicator #1 indicates whether it is "essential" or not. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: 04 April 2003 18:16 To: 'Gonzalo Camarillo'; Mark Watson Cc: Tom-PT Taylor; 'sipping@ietf.org'; 'Jon Peterson' Subject: RE: [Sipping] Early media; a summary after the IETF > As far as I know, Q.931 lets you send ALERTING with no > indication, but I > do not know any example where the network uses this message. Where is > this used? ALERTING with no indication means that there is no in-band alerting. ALERTING with Progress indicator 1 or 8 means that there is in-band tones. Of course you CAN override it with locally generated tones if you want. If you provide in-band tones, you have to included the progress indicator. ------_=_NextPart_001_01C2FDBA.7E2F436A Content-Type: text/html RE: [Sipping] Early media; a summary after the IETF
As I indicated in another message, this is not strictly true. It depends whether you are sitting at the originating or destination interface.
 
At the originating interface, calls are always accompanied with in-band media. The progress indicator #1 indicates whether it is "essential" or not.
 
Keith
 

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com

-----Original Message-----
From: Francois Audet [mailto:audet@nortelnetworks.com]
Sent: 04 April 2003 18:16
To: 'Gonzalo Camarillo'; Mark Watson
Cc: Tom-PT Taylor; 'sipping@ietf.org'; 'Jon Peterson'
Subject: RE: [Sipping] Early media; a summary after the IETF

> As far as I know, Q.931 lets you send ALERTING with no
> indication, but I
> do not know any example where the network uses this message. Where is
> this used?

ALERTING with no indication means that there is no in-band alerting.

ALERTING with Progress indicator 1 or 8 means that there is in-band tones.
Of course you CAN override it with locally generated tones if you want. If
you provide in-band tones, you have to included the progress indicator.

------_=_NextPart_001_01C2FDBA.7E2F436A-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 08:43:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08525 for ; Tue, 8 Apr 2003 08:43:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38Cm6K21724 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 08:48:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Cm6821721 for ; Tue, 8 Apr 2003 08:48:06 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08503 for ; Tue, 8 Apr 2003 08:42:54 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38ClV821610; Tue, 8 Apr 2003 08:47:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38CjX821491 for ; Tue, 8 Apr 2003 08:45:33 -0400 Received: from relay3.clb.oleane.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08417 for ; Tue, 8 Apr 2003 08:40:19 -0400 (EDT) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by relay3.clb.oleane.net with SMTP id h38CgoBr001716 for ; Tue, 8 Apr 2003 14:42:51 +0200 Message-ID: <007a01c2fdcc$98f453e0$0601a8c0@oleane.com> From: "Peter Lewis" To: Date: Tue, 8 Apr 2003 14:44:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0077_01C2FDDD.5C30D8A0" 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 Subject: [Sipping] International SIP 2004: call for contributions Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0077_01C2FDDD.5C30D8A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable International SIP 2004 will take place in Paris on January 20 to 23. The = 2003 edition clearly recaptured the interest of the VoIP community (the = number of delegates grew more than 30%). . What will the NextGen Network for End-to-end SIP applications be: The = Internet, Managed IP Networks (MIPNET) Federation, Both?=20 . SIP B2BUA - Good or Evil?=20 . Security for Service Providers: Protecting service infrastructure = against DoS attacks, QoS problems: Discovery, Isolation, Actions=20 Top specialists will examine these issues along with many others in = depth.=20 A call for contributions is online at: =20 http://www.upperside.fr/sip2004/sip2004intro.htm ------=_NextPart_000_0077_01C2FDDD.5C30D8A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
International SIP 2004 will take place = in Paris on=20 January 20 to 23. The 2003 edition = clearly=20 recaptured the interest of the VoIP community (the number of delegates = grew more=20 than 30%).
• What will=20 the NextGen Network for End-to-end SIP applications be: = The Internet,=20 Managed IP Networks (MIPNET) Federation, Both?
• SIP B2BUA - Good or Evil? =
• Security for Service Providers: = Protecting service=20 infrastructure against  DoS attacks, QoS problems: Discovery,=20 Isolation, Actions

Top specialists will examine these issues = along with=20 many others in depth.

A call for contributions is online=20 at:
 
http://www.uppe= rside.fr/sip2004/sip2004intro.htm
------=_NextPart_000_0077_01C2FDDD.5C30D8A0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 08:51:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08733 for ; Tue, 8 Apr 2003 08:51:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38Ctkt22066 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 08:55:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Ctk822063 for ; Tue, 8 Apr 2003 08:55:46 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08724 for ; Tue, 8 Apr 2003 08:50:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38CtA822037; Tue, 8 Apr 2003 08:55:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38CsA821979 for ; Tue, 8 Apr 2003 08:54:10 -0400 Received: from mail-blue.research.att.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08695 for ; Tue, 8 Apr 2003 08:48:56 -0400 (EDT) Received: by mail-blue.research.att.com (Postfix, from userid 612) id 9F74BB7C2D; Tue, 8 Apr 2003 08:56:34 -0400 (EDT) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mail-blue.research.att.com (Postfix) with ESMTP id 88C46B7C18 for ; Tue, 8 Apr 2003 08:56:33 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h38CohVq007345; Tue, 8 Apr 2003 08:50:43 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id IAA11849; Tue, 8 Apr 2003 08:50:48 -0400 (EDT) Date: Tue, 8 Apr 2003 08:50:48 -0400 (EDT) Message-Id: <200304081250.IAA11849@fish.research.att.com> To: audet@nortelnetworks.com Cc: sipping@ietf.org Subject: Re: [Sipping] Early media; philosophical discussion X-Spam-Status: No, hits=-116.3 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT, USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Francois Audet wrote: > What I am proposing is that there should be a mechanism in the INVITE to tell the > gateway NOT to provide early media (at least for ringing). This would solve a lot of > problems including the forking problem. Use RFC3312 If the UAC doesn't want to deal with the potential of a forked request, and/or wants to add an indication in the INVITE that says "don't send early media" -- there is such a thing defined aleady. Just use the mechanism in rfc3312 for peconditions. The UAC then _knows_ every endpoint that received the forked request, because it has established a dialog with all of them and exchanged SDP with all of them. And if it doesn't want media, "a=inactive" will do that. This seems far better than defining a new flag in the INVITE. Ans just a general comment on forking and media. Consider the INVITE is forked to two destinations that both answer at about the same time, and both send 200-OK responses, and both start sending media simultaneously with sending the 200-OK responses. Due to the established race condition between media and the signaling response, it is possible (if not likely) that the two media streams will arrive at the UAC before the proxy straightens out the multiple answers and sends a CANCEL (and possibly a BYE) to one of them. So the UAC already deals with this worste-possible-case of forked early media. Guessing correctly 50% of the time is probably the best that can reasonably be done. Bill Marshall wtm@research.att.com -----original message----- From: "Francois Audet" Subject: RE: [Sipping] Early media; philosophical discussion Date: Mon, 7 Apr 2003 17:58:07 -0700 What I am proposing is that there should be a mechanism in the INVITE to tell the gateway NOT to provide early media (at least for ringing). This would solve a lot of problems including the forking problem. I don't see why this would be difficult to do. There is no such thing as early ringing media that is essential to the call when forking occurs because the endpoint receiving it will not be able to play it. The gateway would do one of the following upon receiving the no-early-ringing indication: 1 - Not send early ringing if it knows he difference between early ringing and early media-to-avoid-clipping. This is possible only in certain cases, for example when the gateway itself is providing the ringing (for example if the gateway is a PBX or Public Exchange and the call terminates to a phone on the switch). This method when applicable, is preferred because it will avoid any possibility of clipping the "hello". 2 - Not send any early media at all. This is when the gateway does not know the difference between early ringing and early media-to-avoid-clipping (for example, when the media is provide by another circuit-switch upstream, when there is tandeming over the PSTN). The gateway will only "cut-through" when the connection indication is received. Note that there is a possibility of clipping part of the "hello" under certain circumstances (as we discussed earlier): however, this possibility would happen anyways since there is no way for the receiver to distinguish between various overlapping streams. And yes, for the Native SIP (non-gateway) early media, we could use your application server model. I agree on that (although it would be nice if we didn't need to include the join header in all calls, and if somehow the application server could handle it). > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Friday, April 04, 2003 22:16 > To: Audet, Francois [SC100:4K02:EXCH] > Cc: 'Christer Holmberg'; Watson, Mark [MOP:EP10:EXCH]; > Taylor, Tom-PT [CAR:5N00:EXCH]; 'sipping@ietf.org'; 'Jon Peterson' > Subject: Re: [Sipping] Early media; philosophical discussion > > > Francois, > > I have already answered this one in another note (I believe I sent it > yesterday). The gateway model is appropriate when the UAS is > not the one > "generating" the early media. This means that, a gateway cannot know > whether the early media is optional or not. A gateway does not know > whether the early media it is receiving from the > circuit-switched part > is optional or is essential to the call. Therefore, even if > this gateway > receives an indication from in the INVITE saying that the requested > forked, the gateway CANNOT DO ANYTHING. It needs to send the > media anyway. > > However, a pure SIP UAS knows that what it is about to generate is a > message that says "Thanks for calling Francois, please wait". > Therefore, > it sends a separate INVITE (application server model), which > the UAC can > refuse if it is already overloaded with other stuff. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 10:03:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10500 for ; Tue, 8 Apr 2003 10:03:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38E8OJ28214 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 10:08:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38E8O828211 for ; Tue, 8 Apr 2003 10:08:24 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10448 for ; Tue, 8 Apr 2003 10:03:09 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38E7c828174; Tue, 8 Apr 2003 10:07:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38E5q827234 for ; Tue, 8 Apr 2003 10:05:52 -0400 Received: from tomts11-srv.bellnexxia.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10361 for ; Tue, 8 Apr 2003 10:00:37 -0400 (EDT) Received: from Shulin ([199.243.90.234]) by tomts11-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030408140310.TJKM18485.tomts11-srv.bellnexxia.net@Shulin> for ; Tue, 8 Apr 2003 10:03:10 -0400 From: "Shu-Lin CHen" To: Date: Tue, 8 Apr 2003 10:03:10 -0400 Message-ID: <000401c2fdd7$9680bad0$390aa8c0@blueslicemtl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Sipping] selection among UDP, TCP and TLS Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi: When a proxy server needs to send a SIP msg to another proxy server, based on what criteria does it select a protocol among UDP/TCP/TLS? Thanks. shu-lin _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 10:16:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12465 for ; Tue, 8 Apr 2003 10:16:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38EL2x28890 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 10:21:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38EL2828881 for ; Tue, 8 Apr 2003 10:21:02 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12373 for ; Tue, 8 Apr 2003 10:15:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38EKQ828805; Tue, 8 Apr 2003 10:20:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38EAr828305 for ; Tue, 8 Apr 2003 10:10:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11046; Tue, 8 Apr 2003 10:05:38 -0400 (EDT) Message-Id: <200304081405.KAA11046@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 08 Apr 2003 10:05:38 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-pstn-call-flows-02.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Session Initiation Protocol PSTN Call Flows Author(s) : A. Johnston, S. Donovan Filename : draft-ietf-sipping-pstn-call-flows-02.txt Pages : 1123 Date : 2003-4-7 This document contains best current practice examples of Session Initiation Protocol (SIP) call flows showing interworking with the Public Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-pstn-call-flows-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sipping-pstn-call-flows-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-sipping-pstn-call-flows-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: <2003-4-7125333.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-pstn-call-flows-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-pstn-call-flows-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-7125333.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 11:05:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12466 for ; Tue, 8 Apr 2003 10:16:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38EL2V28882 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 10:21:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38EL2828873 for ; Tue, 8 Apr 2003 10:21:02 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12374 for ; Tue, 8 Apr 2003 10:15:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38EKO828785; Tue, 8 Apr 2003 10:20:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38EAn828301 for ; Tue, 8 Apr 2003 10:10:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11026; Tue, 8 Apr 2003 10:05:34 -0400 (EDT) Message-Id: <200304081405.KAA11026@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 08 Apr 2003 10:05:34 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-basic-call-flows-02.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Session Initiation Protocol Basic Call Flow Examples Author(s) : A. Johnston Filename : draft-ietf-sipping-basic-call-flows-02.txt Pages : 97 Date : 2003-4-7 This informational document gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-basic-call-flows-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sipping-basic-call-flows-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-sipping-basic-call-flows-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: <2003-4-7125323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-basic-call-flows-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-basic-call-flows-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-7125323.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 14:12:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24550 for ; Tue, 8 Apr 2003 14:12:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38IHlB16743 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 14:17:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IHl816740 for ; Tue, 8 Apr 2003 14:17:47 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24527 for ; Tue, 8 Apr 2003 14:12:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IGe816698; Tue, 8 Apr 2003 14:16:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IEp816596 for ; Tue, 8 Apr 2003 14:14:51 -0400 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24398 for ; Tue, 8 Apr 2003 14:09:32 -0400 (EDT) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h38IBxb22119; Tue, 8 Apr 2003 13:11:59 -0500 (CDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2R1BGZL6>; Tue, 8 Apr 2003 11:11:59 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D207ADE3B2@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Christer Holmberg'" Cc: "'Gonzalo Camarillo'" , "Mark Watson" , "Tom-PT Taylor" , "'sipping@ietf.org'" , "'Jon Peterson'" , "'William Marshall'" Subject: RE: [Sipping] Early media; philosophical discussion Date: Tue, 8 Apr 2003 11:11:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FDFA.58C85CD4" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FDFA.58C85CD4 Content-Type: text/plain > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Just to clairfy your proposal: > > Since the UAC gateway most likely doesn't know if an INVITE > is going to be forked, I assume it would ALWAYS insert this > "don't-send-early-media" flag in the INVITE, right? Now, if > the UAS is also a gateway (trunking > scenario) it would very often not send early media, because > it doesn't know the difference you described. So, in this > case the early media from one PSTN network would not be sent > to the other PSTN network. > > Or, did I missunderstand your mail? Almost. I'm saying that the UAC would NOT include the don't-send-early-media- for-ringing flag in the INVITE. They'd be no change on the UAC, and that's why it is backward compatible. A forking proxy would normally include the don't-send-early-media-for-ringing flag in the INVITE. This is why this indication can NOT be at the SDP level because the proxies can't touch it. Bill, if for whatever reason, the UAC does not want early media, than it would indeed use RFC 3312. But the proxy can certainly not use it. ------_=_NextPart_001_01C2FDFA.58C85CD4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] Early media; philosophical discussion

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]

> Just to clairfy your proposal:
>
> Since the UAC gateway most likely doesn't know = if an INVITE
> is going to be forked, I assume it would ALWAYS = insert this
> "don't-send-early-media" flag in the = INVITE, right? Now, if
> the UAS is also a gateway (trunking
> scenario) it would very often not send early = media, because
> it doesn't know the difference you described. = So, in this
> case the early media from one PSTN network = would not be sent
> to the other PSTN network.
>
> Or, did I missunderstand your mail?

Almost. I'm saying that the UAC would NOT include the = don't-send-early-media-
for-ringing flag in the INVITE. They'd be no change = on the UAC, and that's why
it is backward compatible.

A forking proxy would normally include the = don't-send-early-media-for-ringing flag
in the INVITE.

This is why this indication can NOT be at the SDP = level because the proxies can't
touch it. Bill, if for whatever reason, the UAC does = not want early media, than
it would indeed use RFC 3312. But the proxy can = certainly not use it.

------_=_NextPart_001_01C2FDFA.58C85CD4-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 14:16:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24687 for ; Tue, 8 Apr 2003 14:16:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38ILUm16955 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 14:21:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38ILU816951 for ; Tue, 8 Apr 2003 14:21:30 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24659 for ; Tue, 8 Apr 2003 14:16:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IKi816869; Tue, 8 Apr 2003 14:20:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IJ3816787 for ; Tue, 8 Apr 2003 14:19:03 -0400 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24577 for ; Tue, 8 Apr 2003 14:13:43 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h38IG8Rs029298; Tue, 8 Apr 2003 20:16:08 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2Q16H4J1; Tue, 8 Apr 2003 20:16:09 +0200 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h38IG5Av021996; Tue, 8 Apr 2003 21:16:06 +0300 (EET DST) Message-ID: <3E9311E4.C127B0B@lmf.ericsson.se> Date: Tue, 08 Apr 2003 21:16:04 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois Audet CC: "'Gonzalo Camarillo'" , Mark Watson , Tom-PT Taylor , "'sipping@ietf.org'" , "'Jon Peterson'" , "'William Marshall'" Subject: Re: [Sipping] Early media; philosophical discussion References: <2F1FC1DEA077D5119FAD00508BCFD6D207ADE3B2@zsc3c030.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > >Just to clairfy your proposal: > > > >Since the UAC gateway most likely doesn't know if an INVITE > >is going to be forked, I assume it would ALWAYS insert this > >"don't-send-early-media" flag in the INVITE, right? Now, if > >the UAS is also a gateway (trunking > >scenario) it would very often not send early media, because > >it doesn't know the difference you described. So, in this > >case the early media from one PSTN network would not be sent > >to the other PSTN network. > > > >Or, did I missunderstand your mail? > > Almost. I'm saying that the UAC would NOT include the > don't-send-early-media- > for-ringing flag in the INVITE. They'd be no change on the UAC, and > that's why > it is backward compatible. > > A forking proxy would normally include the > don't-send-early-media-for-ringing flag > in the INVITE. Well, if the INVITE reaches another gateway the result would still be the same. Early media from the remote PSTN network would not be forwarded, and would not reach the UAC gateway and the PSTN network behind it. Regards, Christer Holmberg Ericsson Finland > > > This is why this indication can NOT be at the SDP level because the > proxies can't > touch it. Bill, if for whatever reason, the UAC does not want early > media, than > it would indeed use RFC 3312. But the proxy can certainly not use it. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 14:22:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24885 for ; Tue, 8 Apr 2003 14:22:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38IRIx17318 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 14:27:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IRI817315 for ; Tue, 8 Apr 2003 14:27:18 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24874 for ; Tue, 8 Apr 2003 14:21:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IQk817272; Tue, 8 Apr 2003 14:26:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IP5817196 for ; Tue, 8 Apr 2003 14:25:05 -0400 Received: from zsc3s004.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24810 for ; Tue, 8 Apr 2003 14:19:45 -0400 (EDT) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h38IMDM04944; Tue, 8 Apr 2003 11:22:13 -0700 (PDT) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2R1BG5QT>; Tue, 8 Apr 2003 11:21:43 -0700 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D207ADE415@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Christer Holmberg'" Cc: "'Gonzalo Camarillo'" , "Mark Watson" , "Tom-PT Taylor" , "'sipping@ietf.org'" , "'Jon Peterson'" , "'William Marshall'" Subject: RE: [Sipping] Early media; philosophical discussion Date: Tue, 8 Apr 2003 11:21:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FDFB.B5332322" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FDFB.B5332322 Content-Type: text/plain > Well, if the INVITE reaches another gateway the result would > still be the same. Early media from the remote PSTN network > would not be forwarded, and would not reach the UAC gateway > and the PSTN network behind it. Exactly: that's what we want. The point is that with forking, in-band ringing is not useful because it is completely arbitrary. You have to rely on in-band indications. The UAC will then receive a bunch of 180s/183s (with no media) and decide how to deal with it. If the UAC is a gateway, it will have to generate whatever tone it feels appropriate. Gateways have to support this today because there is never any garantee of in-band tones being provided by the far-end. This means absolutely NO modifications to UACs, be them gateways or native SIP endpoints. It only means modifications to: 1) Forking proxies 2) UAS gateways providing early media for ringing ------_=_NextPart_001_01C2FDFB.B5332322 Content-Type: text/html RE: [Sipping] Early media; philosophical discussion

> Well, if the INVITE reaches another gateway the result would
> still be the same. Early media from the remote PSTN network
> would not be forwarded, and would not reach the UAC gateway
> and the PSTN network behind it.

Exactly: that's what we want.

The point is that with forking, in-band ringing is not useful because
it is completely arbitrary. You have to rely on in-band indications.
The UAC will then receive a bunch of 180s/183s (with no media) and decide
how to deal with it. If the UAC is a gateway, it will have to generate
whatever tone it feels appropriate. Gateways have to support this today
because there is never any garantee of in-band tones being provided by the
far-end.

This means absolutely NO modifications to UACs, be them gateways or native
SIP endpoints.

It only means modifications to:
1) Forking proxies
2) UAS gateways providing early media for ringing

------_=_NextPart_001_01C2FDFB.B5332322-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 18:09:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05167 for ; Tue, 8 Apr 2003 18:09:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38MEjf04180 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 18:14:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MEj804176 for ; Tue, 8 Apr 2003 18:14:45 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05124 for ; Tue, 8 Apr 2003 18:09:19 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38ME2804145; Tue, 8 Apr 2003 18:14:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MCx804066 for ; Tue, 8 Apr 2003 18:13:00 -0400 Received: from webshield.office.snowshore.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04887 for ; Tue, 8 Apr 2003 18:07:31 -0400 (EDT) Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 29658; Tue, 08 Apr 2003 18:12:48 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] conf: comments on draft-even-sipping-media-policy-requirements-00 Date: Tue, 8 Apr 2003 18:12:10 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F62FC@zoe.office.snowshore.com> Thread-Topic: [Sipping] conf: comments on draft-even-sipping-media-policy-requirements-00 Thread-Index: AcLxM93uo6VBwJpYTEm/wnPbOnhWTAM1KeMQ From: "Eric Burger" To: "Even, Roni" Cc: "Sipping (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h38MD0804067 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Inline. > -----Original Message From: Even, Roni [mailto:roni.even@polycom.co.il] [snip] > > Section 8.1: > > What on Earth is LastLoudest? What is the "audio mix set > > before the current one"? Over what time period? Is this > > continuous? How often does it get updated? > The Lastloudest is the loudest speaker in the previous mix, > this operation > is to buffer the loudest speaker when a new speaker becomes > the loudest. It > is used for example in video conferencing to create a > conference that is > showing to every one the loudest speaker and the loudest > speaker will see > the previous loudest speaker. As for the rate of change of > active speaker, > the conferencing bridges are using some parameters that > specify the minimum > time that some has to be loudest before becoming the loudest > speaker (also > known as cough delay - so that clearing your throat will not cause a > switch), the other parameter is minimum time that active > speaker is viewed > before a switch can occur. Do be sure to include this clarifying statement in the document, including the 14 or so parameters needed for the algorithm :-) > > Does Not(Qualifier) result in a set? E.g., in a conference > > with more than 2 participants, Not(LastLoudest) results in > > more than one stream. > > > That is true, but in the example we had 4 input streams that > were the result > from the mixer. three of them had the loudest speaker as a > contributor and > only one did not. I will clarify the text Right. To me it looks like all of the operators are on sets, not scalar values. If this is so, I would state it outright. I can guarantee that implementers that are not familiar with set arithmetic will assume the results of all of the operations is a single stream. > > Section 8.3: > > What is the use case for LoudestSpeaker(N), where N != 1? I > > would offer that if the use case is, "I will construct a mix > > of the three loudest talkers by doing > An example is Not (LoudestSpeaker(2)) - will select the > stream that does not > include the second loudest speaker as a contributing source. I understand the algebra. I don't understand the "why". What would one use with the stream that doesn't include the 2nd loudest speaker? Is there a real expectation that people would construct "send Mix(LoudestSpeaker(1),LoudestSpeaker(2),LoudestSpeaker(3)) - LoudestSpeaker(2) to Destination(LoudestSpeaker(2)"? > > Mix(LoudestSpeaker(1),LoudestSpeaker(2),LoudestSpeaker(3))", > > you will have exactly zero implementations. That is very > > hard to do. Moreover, I don't know anyone that is interested > > in, "Please play for me the 6th loudest speaker." > > This is more important for video. If I am using a tiled > display I want the > video of loudest speaker in sub-window1, the video from the > second loudest > speaker in sub window 2 and so on. Would there EVER be a different mapping? That is, would one EVER associate one audio stream with a DIFFERENT video stream? [snip] _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 18:28:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06398 for ; Tue, 8 Apr 2003 18:28:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38MX3K05345 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 18:33:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MX3805342 for ; Tue, 8 Apr 2003 18:33:03 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06371 for ; Tue, 8 Apr 2003 18:27:37 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MVl805259; Tue, 8 Apr 2003 18:31:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MUf805189 for ; Tue, 8 Apr 2003 18:30:41 -0400 Received: from broadsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06265 for ; Tue, 8 Apr 2003 18:25:16 -0400 (EDT) Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.6p2) id h38MRnKA026230; Tue, 8 Apr 2003 18:27:49 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sipping] selection among UDP, TCP and TLS Date: Tue, 8 Apr 2003 18:31:17 -0400 Message-ID: <002001c2fe1e$92f85f20$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: <000401c2fdd7$9680bad0$390aa8c0@blueslicemtl> Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > When a proxy server needs to send a SIP msg > to another proxy server, based on what criteria > does it select a protocol among UDP/TCP/TLS? The basic answer is that it does a DNS query for NAPTR records if it has not already been limited based upon transport, address, or port. More detailed answers can be found in RFC 3263 and RFC 3261. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 8 18:45:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07041 for ; Tue, 8 Apr 2003 18:45:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38Mo0v07127 for sipping-archive@odin.ietf.org; Tue, 8 Apr 2003 18:50:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38Mo0807124 for ; Tue, 8 Apr 2003 18:50:00 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07031 for ; Tue, 8 Apr 2003 18:44:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MnC807070; Tue, 8 Apr 2003 18:49:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38MlD807011 for ; Tue, 8 Apr 2003 18:47:13 -0400 Received: from sj-core-5.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06952 for ; Tue, 8 Apr 2003 18:41:45 -0400 (EDT) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h38MhlGO017390; Tue, 8 Apr 2003 15:43:47 -0700 (PDT) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFX95362; Tue, 8 Apr 2003 15:42:21 -0700 (PDT) Date: Tue, 8 Apr 2003 15:44:08 -0700 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'Jonathan Rosenberg'" , , =?ISO-8859-1?Q?"'J=F6rgen_Bj=F6rkner'"?= , "'Robert Sparks'" To: "Christian Stredicke" From: Rohan Mahy In-Reply-To: <004a01c2f1e2$7bca17a0$6e7c6aca@raggy> Message-Id: <9BC6560C-6A13-11D7-B7CF-0003938AF740@cisco.com> X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h38MlD807012 Subject: [Sipping] Re: AW: AW: "Strict Routing", "Loose Routing", "No Routing"! Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Sorry for the delay. This mail got lost for in my Drafts folder inline... On Monday, March 24, 2003, at 12:48 AM, Christian Stredicke wrote: > Jonathan, > > ok I elaborate a little bit as the history might not be known to > everybody. > > (1) I am talking about the SIP messages here only; RTP is a separate > issue. > > Again, I would like to stress I am not trying to reinvent routing (I > think that would be too late and inappropriate anyway). I would just > like to propose a backward-compatible way of expressing that non-SIP > aware equipment is involved in the message forwarding process that > needs > to be taken care of. There is a need for this as we are moving on > making > the addresses found by STUN usable between the different vendors. > > (2) The problem is that depending on the context a request must be send > to one of several possible addresses. In the case of NAT you are right, > this is typically a problem when the two user agents are in the same > NAT > and the NAT gateway does not properly forward the messages coming from > the private side sent to the public address of the other phone. This is > my private concern as this is the most critical case we are facing in > day-to-day life now. > > (3) I proposed using alternative addresses in the contact like > > "sip:62.12.34.56:6546;srcadr=192.168.0.123:5060" > > but that did not find too much acceptance with the persons that I > talked > to. The alternative proposal is including the route in the contact like > > "sip:192.168.0.123:5060?Route=sip:62.12.34.56:6546" or so, > > but this has the disadvantage that equipment which does not support the > route header will not be able to send the packet properly (and apart > from that I have some problems understanding how the route header > should > be merged with a maybe existing route). there are really two cases here. for no modifications to the client, there are no proposed solutions. if we are making modifications to the client, this seems like the smallest change to me. The existing language in 3261 describes how to do the merging in an implicit way. If you want to make it more explicit that is fine. (The pre-loaded Route is appended to the default route-set is on the other side. > (4) What I propose now is using the routing mechanism we all know from > SIP with a modification (backward compatible). For registrations, the > path header has already been proposed and the record-route is part of > the RFC. > > Lets make an example: The UA is in a private network and has the above > private address and public address association. So it will send the > following REGISTER message: > > REGISTER sip:bla.com SIP/2.0 > Path: > Contact: > ... > > The registrar will save both the path and the contact. So a INVITE that > is forwarded to the user agent then will go along the path: > > INVITE sip:192.168.0.123:5060 SIP/2.0 > Route: > > Because the user agent can deal with the "no routing", it will remove > the top route entry (it contains the nr) and then process the packet. > Here, it will probably start ringing. > > If the user agents sends a message and the topmost route entry contains > the nr flag, it skips that route if the IP address is the same as the > IP > address that is has stored as its public IP address. This is surely a > pragmatic first step to solving the problem of finding the right > destination in a NAT. However, it can be extended to using STUN probes > first and so on (for example in multi-tier NAT). you don't need to do this, because you can use STUN to figure out if your address is valid in the public context. > (5) The nice thing about the nr idea is that existing equipment does > not > have to be changed. That means especially the existing proxies in the > public internet can deal perfectly with "no routers". If equipment > supports the nr flag, it will also see the packets with the nr flag and > process them accordingly. Meaning that nr is fully backward compatible. well, you are requiring new functionality on proxies instead of making the end-systems deal with basic health and hygiene. somebody has to do the work, but i prefer if it is the user agents. thanks, -rohan > I hope this clarifies the idea a little bit more. > > > Christian > -- > Dr.-Ing. Christian Stredicke > sip:cs@snom.com > > >> -----Ursprüngliche Nachricht----- >> Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >> Gesendet: Montag, 24. März 2003 11:55 >> An: Christian Stredicke >> Cc: 'Rohan Mahy'; sipping@ietf.org; 'Jörgen Björkner'; 'Robert Sparks' >> Betreff: Re: AW: "Strict Routing", "Loose Routing", "No Routing"! >> >> Christian, >> >> I cannot really follow your email, and do not understand the problem >> here. Perhaps you are referring to the case where A calls B, both > behind >> the same NAT, with a proxy on the public Internet. If the proxy doesnt >> record route, a contact in the INVITE from A that contains an address >> allocated via upnp will not be useful to B. There is an equivalent > case >> for RTP. >> >> There are only two solutions for this, I believe: >> >> 1. the proxy always record routes. But, how does it know that it needs >> to do so? >> >> 2. apply the ICE principles to SIP signaling. This would involve >> inclusion of *both* the public and private addresses in the Contact >> header of the INVITE, and so the recipient uses the one that works. >> Contact in INVITE only allows one URI (pity), so we would need to hack >> around to get that to work. There are ways. >> >> I think most folk do approach 1. Its problem is that the proxy has to >> know to record route. >> >> Approach 2 is in line with the ICE philosophy in that it would always >> work, without requiring apriori topology knowledge as case 1 assumes. >> >> Anyway, moving to sipping since this is an important issue. >> >> -Jonathan R. >> >> Christian Stredicke wrote: >>> Rohan, >>> >>> that is surely going into the right direction! >>> >>> I think it clearly points out the need to transport more than one >>> address in the SDP. >>> >>> However, it does not seem to solve the problem for requests that > don’t >>> have SDP attachments (like MESSAGE). There is a difference in SIP >>> routing and RTP routing. I think the draft addresses the RTP routing >>> problem. For SIP routing, I think we still need a way for > formulating >>> that non SIP-aware equipment is involved in the routing process. >>> >>> Again, in my perception, SIP deals with *routes* (user agent client, >>> number of routers with loose/strict/no routing and the user agent >>> server). Every router has a defined behaviour (SIP aware called >>> "proxies" and non SIP-aware called "NAT"). We know that the > different >>> types of proxies need different treatment and I begin to realize > that >>> NAT routers need a different treatment as well. >>> >>> The good news is that "no-routers" can be treated backward > compatible. >>> If the routing element behind the no-router fixes the SIP routing >>> information everything should run fine. It is also the element > behind >>> the no-router that inserts this information. >>> >>> Anyway, having a STUN server on board of every SIP network element >>> (UA/proxy) is probably a good idea for whatever comes. As you know, > we >>> did this already half a year on our proxy! >>> >>> Best, >>> >>> >>> Christian >>> >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Rohan Mahy [mailto:rohan@cisco.com] >>>> Gesendet: Samstag, 22. März 2003 05:57 >>>> An: Christian Stredicke >>>> Cc: sip-implementors@cs.columbia.edu; 'Jörgen Björkner'; 'Robert >>> >>> Sparks' >>> >>>> Betreff: Re: "Strict Routing", "Loose Routing", "No Routing"! >>>> >>>> Hi Christian, >>>> >>>> Have you seen Jonathan Rosenberg's "ICE" proposal which we discussed >>> >>> in >>> >>>> SIPPING? How do you think these would relate. >>>> >>>> thanks, >>>> -rohan >>>> >>>> >>>> On Monday, March 17, 2003, at 09:17 PM, Christian Stredicke wrote: >>>> >>>> >>>>> Hello again, >>>>> >>>>> while we have now loose routers and strict routers it seems that a >>>> >>> new >>> >>>>> type occurs on the horizon: The "no router"! >>>>> >>>>> This is for example the case when using NAT forwarding (e.g. with >>>> >>> STUN >>> >>>>> or UPnP). The router is not at all aware of SIP and does not >>>> >>> manipulate >>> >>>>> the packet at all. However, the router is too dumb to forward a >>>> >>> packet >>> >>>>> if it is coming from the wrong direction. This is the case with > most >>>> >>> of >>> >>>>> the DSL routers today. >>>>> >>>>> May I propose to use a ";nr" flag in a URI to indicate that the >>>> >>> router >>> >>>>> does not do any SIP changing at all? >>>>> >>>>> User Agents that are able to deal with "no routers" would then >>>> >>> register >>> >>>>> with the following packet: >>>>> >>>>> REGISTER sip:bla.com SIP/2.0 >>>>> Path: >>>>> Contact: >>>>> ... >>>>> >>>>> When it receives a message this could look like this: >>>>> >>>>> INVITE sip:62.12.245.32:54456;nr=1 SIP/2.0 >>>>> Route: >>>>> ... >>>>> >>>>> SIP/2.0 200 Wonderful >>>>> Record-Route: >>>>> Contact: >>>>> ... >>>>> >>>>> The nr parameter could easily indicate that the previous router did >>>> >>> not >>> >>>>> change the packet at all and that the next entity has to fix this >>>>> before >>>>> processing the message. Alternatively, the router sending the > packet >>>>> could fix the route before sending it. >>>>> >>>>> What do you think? Is this really necessary? Just omit the nr >>>> >>> parameter >>> >>>>> and conclude implicitly? How else should we deal with routers that >>>> >>> are >>> >>>>> not SIP-aware? I don’t like the route encoding in the header >>>>> (sip:abc?route=def) as it raises many questions about how to merge >>>> >>> this >>> >>>>> with other existing routes. >>>>> >>>>> Unfortunately, omitting the private address is no solution, as >>>> >>> devices >>> >>>>> in the same subnet have to bypass the "no router". Many DSL routers >>>> >>> are >>> >>>>> not able to send packets from private address via the public > address >>>> >>> to >>> >>>>> the other private address. >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> Christian >>>>> -- >>>>> Dr. Christian Stredicke >>>>> sip:cs@snom.com >>>>> >>>> >>> >>> >> >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Chief Scientist Parsippany, NJ 07054-2711 >> dynamicsoft >> jdrosen@dynamicsoft.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.dynamicsoft.com > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 10 03:40:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10527 for ; Thu, 10 Apr 2003 03:40:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A7kJA17366 for sipping-archive@odin.ietf.org; Thu, 10 Apr 2003 03:46:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7kI817363 for ; Thu, 10 Apr 2003 03:46:18 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10498 for ; Thu, 10 Apr 2003 03:40:07 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7ip817261; Thu, 10 Apr 2003 03:44:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3409DK13871 for ; Thu, 3 Apr 2003 19:09:13 -0500 Received: from mgw-dax1.ext.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20873; Thu, 3 Apr 2003 19:05:58 -0500 (EST) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3408LZ14978; Thu, 3 Apr 2003 18:08:21 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 3 Apr 2003 18:08:14 -0600 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 3 Apr 2003 16:08:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FA3E.4846DC7C" Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Thu, 3 Apr 2003 18:08:12 -0600 Message-ID: Thread-Topic: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Thread-Index: AcL577PGmAoo5ePvQKe+pm53Lf8dWgAPhCQw To: , , , Cc: , X-OriginalArrivalTime: 04 Apr 2003 00:08:13.0792 (UTC) FILETIME=[48E8AE00:01C2FA3E] Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2FA3E.4846DC7C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mark, =20 This is exactly the concern I have regarding the SigComp performance = implication. I see this as a question of *what* states to create. More = precisely, a compressor should create only "useful" state(s) from the = text part(s) of a message while avoiding creating "garbage" state(s) = from the binary part(s).=20 =20 (Of course, it's possible that the binary part may also repeat across = messages and thus become useful. But I wouldn't go there for = simplicity.) =20 So, how can a compressor achieve that? Below are ideas I can think of. = If they are correct, I can compile more "formal" text to be added to the = SigComp user guide. =20 There are two steps involved. First, the compressor needs to know if = current message to be compressed contain binary parts, and if yes, where = they are located in the message. Second, the compressor needs to make = sure it can selectively create states on the decompressor side. =20 For the first step, the best thing can happen is that the application = (SIP in this case) gives hint to sigcomp compressor. This is possible, = since it is a matter of local interface between application and sigcomp = layer within the same endpoint. Otherwise (i.e. no help from = application), the compressor has to figure it out by itself. In general, = this seems to be a difficult problem to solve (if possible at all). But = there are a few simple and practical approaches one can consider. =20 For example, the compressor can check the compression ratio after = compressing the message. If it is close to 1, that is a hint that the = current message probably contains large binary content. The compressor = can choose not to create any state from current message. However, the = compressor may miss a small text segment in the message that turns out = being repeated later in the subsequent messages. The positive side is = that at least the compressor can avoid creating "garbage states".=20 =20 Another factor to make a compressor's (or rather implementer's) life = easier: we can assume that application messages have two parts, namely, = a UTF-8 encoded part at the beginning followed by a binary part. (Note = this is the case at least for SIP.) Then, the compressor can identify = the UTF-8 part (by parsing) and use it to create state. This also has a = good side-effect: compressor can avoid compressing the remaining binary = part.=20 =20 Now to the second step: creating state on decompressor side. One issue I = see is the limitation of decompression memory. On the decompressor side, = the large binary content may overwrite text content previously stored in = the ring/history buffer (part of the UDVM buffer). One solution is that = the compressor should "segment" one large application message into = multiple sigcomp messages, so that one of them contains only text data. = This avoids the overwriting problem. (Note: I don't think this works for = SigComp over UDP. But on the other hand, large SIP messages must be = carried over TCP, not UDP.) =20 BR, Zhigang =20 -----Original Message----- From: ext Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: April 03, 2003 8:35 AM To: 'Price, Richard'; Liu Zhigang.C (NRC/Dallas); cabo@tzi.org; = Lars-Erik.Jonsson@epl.ericsson.se Cc: rohc@ietf.org; sipping@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = mes sages Richard, all,=20 The issue I would like to see addressed is as follows:=20 The text part of SIP/SDP is obviously highly compressible using very = simple algorithms which refer back to previous parts of the = message/earlier messages. In fact, subsequent messages in a SIP dialog = seem to consist almost entirely of repeated text from previous messages. So, it seems important to me that large binary content in SIP messages = does not destroy state that will be useful in compressing subsequent = messages. In a wireless environment, the principle advantage of compression is = reduction in the time taken to actually send the message over the = wireless link (this may even be more important than the overall = reduction in signalling bandwidth). Now if the message contains large binary content, then of course we are = 'out of luck' on the message transfer time stakes, but this shouldn't = affect subsequent messages. I believe we should document recommendations to SIGCOMP compressor = designers to ensure this aspect is not overlooked (although it is not = immediately clear to me how the compressor (being unaware of the SIP = message structure) might achieve this.) Is this something that would be appropriate to item 4 below ?=20 Regards...Mark=20 > -----Original Message-----=20 > From: Price, Richard [ mailto:richard.price@roke.co.uk]=20 > Sent: 26 March 2003 13:58=20 > To: 'zhigang.c.liu@nokia.com'; cabo@tzi.org;=20 > Lars-Erik.Jonsson@epl.ericsson.se=20 > Cc: rohc@ietf.org; sipping@ietf.org=20 > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = > mes sages=20 >=20 >=20 > Hi,=20 >=20 > I think that the issue with SigComp and large binary=20 > content SIP messages is part of a more general issue -=20 > namely that before using SigComp to compress a particular=20 > application we need to standardise the following:=20 >=20 > 1. Mechanism for SigComp discovery=20 > 2. Resources offered by SigComp=20 > 3. How to delimit messages=20 > 4. When to save state=20 >=20 > Currently the SIPPING WG has provided RFCs for 1 and 2,=20 > but not for 3 and 4. It would be useful to get a draft=20 > out for these ASAP, as it would clarify several issues on=20 > how to get SigComp working with SIP (including the issue=20 > with large binary content SIP messages).=20 >=20 > > Unless someone objects, I'll submit it in ROHC.=20 >=20 > I think that any WG draft should be a product of the=20 > SIPPING WG, because the proposed solution for delimiting=20 > SigComp messages will need to take into account the=20 > behaviour of SIP itself (or we won't be able to multiplex=20 > SigComp and SIP messages on the same port). However, it=20 > would be good to get the ROHC WG involved in generating=20 > the draft as well!=20 >=20 > Regards,=20 >=20 > Richard=20 >=20 > P.S. For anyone who's interested, the mechanisms that=20 > particular applications need to provide before they can=20 > use SigComp are as follows...=20 >=20 > ------------------------------------------------------=20 >=20 > 1. Mechanism for SigComp discovery=20 >=20 > - How does the application know when to use SigComp?=20 >=20 > For SIP this issue is already sorted (RFC 3486).=20 >=20 > ------------------------------------------------------=20 >=20 > 2. Resources offered by SigComp=20 >=20 > - Does the application need to offer more than the=20 > minimum amount of resources?=20 >=20 > - Does the application need any extra state (e.g.=20 > a static dictionary)?=20 >=20 > For SIP we've already got a static dictionary (RFC 3485).=20 > However, we haven't currently discussed how much memory=20 > should be provided in a SigComp implementation for SIP.=20 > If we don't specify a value then SigComp defaults to the=20 > minimum possible (2K), which is rather tight for some of=20 > the more generously sized SIP messages!=20 >=20 > ------------------------------------------------------=20 >=20 > 3. How to delimit messages=20 >=20 > - How does the application distinguish between=20 > SigComp messages and uncompressed messages?=20 >=20 > - Is the application allowed to use "continuous mode"?=20 >=20 > This is the issue that's been raised for large binary=20 > content SIP messages. If we want to send a mix of=20 > uncompressed and SigComp messages within the same TCP=20 > connection, how do we delimit the end of one message and=20 > the start of another?=20 >=20 > A related issue is how to handle very large SIP messages=20 > (> 64K). SigComp is able to compress large SIP messages=20 > by using "continuous mode", where the message boundaries=20 > are ignored completely and the application data is just=20 > transmitted as a stream. However, this mode of operation=20 > raises some additional security issues, so it's up to the=20 > SIPPING WG to decide whether or not to use it in SigComp=20 > for SIP.=20 >=20 > ------------------------------------------------------=20 >=20 > 4. When to save state=20 >=20 > - How much security is needed in order to save state?=20 >=20 > - Which messages belong to each state "compartment"?=20 >=20 > - How long should the application keep state?=20 >=20 > This is quite an important issue that doesn't seem to=20 > have been discussed in the SIPPING WG. It's up to the=20 > application whether or not to let SigComp save state,=20 > and for interoperability it's important to have at=20 > least a general idea of how long to keep saved state,=20 > when to reject state due to insufficient security etc.=20 >=20 > ------------------------------------------------------=20 >=20 > > -----Original Message-----=20 > > From: zhigang.c.liu@nokia.com [ mailto:zhigang.c.liu@nokia.com]=20 > > Sent: Tuesday, March 25, 2003 6:00 PM=20 > > To: cabo@tzi.org; Lars-Erik.Jonsson@epl.ericsson.se=20 > > Cc: rohc@ietf.org; sipping@ietf.org=20 > > Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary=20 > content SIP=20 > > messages=20 > >=20 > >=20 > > Hi Carsten and Lars-Erik,=20 > >=20 > > I've volunteered to submit a personal draft on this issue. From=20 > > ROHC WG chairs' point of view, do you think this is the way=20 > > to proceed?=20 > >=20 > > Of course, I understood during the IETF56 that Carsten had some=20 > > doubts on whether this is indeed an issue. My email below explained=20 > > the issue a bit. I don't know if it's clear. Either way, we=20 > > can continue discuss this in ROHC mailing list=20 > >=20 > http://www1.ietf.org/mail-archive/working-groups/sipping/curre=20 > nt/msg04115.html=20 > >=20 > > BR,=20 > > Zhigang=20 > >=20 > > > -----Original Message-----=20 > > > From: ext zhigang.c.liu@nokia.com [ = mailto:zhigang.c.liu@nokia.com]=20 > > > Sent: March 13, 2003 9:55 AM=20 > > > To: Gonzalo.Camarillo@lmf.ericsson.se=20 > > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki);=20 > > > mwatson@nortelnetworks.com; sipping@ietf.org; rohc@ietf.org=20 > > > Subject: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP = > > > messages=20 > > >=20 > > >=20 > > > I agree. How to handling binary content is a generic issue for any = > > > application messages. What I have in mind is to give generic=20 > > > descriptions/requirements (mainly on the SigComp receiver=20 > parsing part),=20 > > > then touch on SIP (perhaps RTSP too) as a particular example.=20 > > >=20 > > > Unless someone objects, I'll submit it in ROHC.=20 > > >=20 > > > Zhigang=20 > > >=20 > > >=20 > > > > -----Original Message-----=20 > > > > From: ext Gonzalo Camarillo=20 > [ mailto:Gonzalo.Camarillo@lmf.ericsson.se]=20 > > > > Sent: March 13, 2003 5:36 AM=20 > > > > To: Liu Zhigang.C (NRC/Dallas)=20 > > > > Cc: adam@dynamicsoft.com; Isomaki Markus (NRC/Helsinki);=20 > > > > mwatson@nortelnetworks.com; sipping@ietf.org=20 > > > > Subject: Re: [Sipping] SIGCOMP and large binary content=20 > SIP messages=20 > > > >=20 > > > >=20 > > > > Zhigang,=20 > > > >=20 > > > > you can submit that draft to ROHC. SIPPING can review=20 > it afterwards.=20 > > > > IMO, the competence needed to generate this draft can=20 > be found more=20 > > > > easily in ROHC than in SIPPING.=20 > > > >=20 > > > > Besides, you could use SigComp to compress RTSP=20 > messages, for instance=20 > > > > And RTSP is not handle by SIPPING either.=20 > > > >=20 > > > > Gonzalo=20 > > > >=20 > > > > zhigang.c.liu@nokia.com wrote:=20 > > > > >=20 > > > > > Yes, that is also what I had in mind for SIP. But my=20 > point is that=20 > > > > > a SigComp receiver now needs to have some knowledge=20 > about application=20 > > > > > message format and do parsing to determine the end of=20 > an uncompressed=20 > > > > > message. This is something new (or at least=20 > unspecified) in RFC 3320=20 > > > > > and needs to be spelled out in a new (standard track)=20 > RFC. The document=20 > > > > > will be short, but I think it's needed for interoperability.=20 > > > > >=20 > > > > > I'll write up an I-D and submit it after IETF 56. But=20 > I'd like to know=20 > > > > > if folks in SIPPING think it should be done here or in ROHC.=20 > > > > >=20 > > > > > Zhigang=20 > > > > >=20 > > > > > > -----Original Message-----=20 > > > > > > From: ext Adam Roach [ mailto:adam@dynamicsoft.com]=20 > > > > > > Sent: March 11, 2003 9:03 PM=20 > > > > > > To: Liu Zhigang.C (NRC/Dallas); Adam Roach; Isomaki Markus=20 > > > > > > (NRC/Helsinki); mwatson@nortelnetworks.com; sipping@ietf.org = > > > > > > Subject: RE: [Sipping] SIGCOMP and large binary=20 > content SIP messages=20 > > > > > >=20 > > > > > >=20 > > > > > > > -----Original Message-----=20 > > > > > > > From: zhigang.c.liu@nokia.com=20 > [ mailto:zhigang.c.liu@nokia.com]=20 > > > > > > >=20 > > > > > > > Having binary content in SIP messages may have=20 > two impacts on=20 > > > > > > > SigComp:=20 > > > > > > >=20 > > > > > > > a) multiplexing of uncompressed messages with=20 > SigComp messages on the=20 > > > > > > > same port.=20 > > > > > > ...=20 > > > > > > > For a), it is only an issue for SigComp/TCP, not=20 > SigComp/UDP (where one=20 > > > > > > > SigComp message maps to one UDP packet). Adam's=20 > point 1 and 2 are related=20 > > > > > > > to this. As to point 1, I think the SigComp=20 > receiver still needs to know=20 > > > > > > > (somehow) the end of an uncompressed message, or=20 > at least the end of the=20 > > > > > > > binary part of each SIP messages. Otherwise, a=20 > bit pattern 11111 in=20 > > > > > > > the binary part will be mistaken by SigComp as=20 > the beginning of a SigComp=20 > > > > > > > message. As to point 2, I would add that the=20 > delimiter 0xFFFF can appear=20 > > > > > > > at the both the beginning and the end of a=20 > SigComp message. So, the=20 > > > > > > > receiver needs to have the same parsing logic=20 > just mentioned for bit pattern=20 > > > > > > > 11111.=20 > > > > > >=20 > > > > > > This isn't any more of an issue than it is without=20 > SigComp. SIP=20 > > > > > > messages provide their own framing, and SigComp=20 > messages do the=20 > > > > > > same. They can be trivially mixed on the same stream:=20 > > > > > >=20 > > > > > > 1. Peek at the first byte waiting in the stream.=20 > > > > > >=20 > > > > > > 2. If it is 0xf8 or higher, the next message in the=20 > stream is=20 > > > > > > a SigComp message. The message continues until a=20 > 0xFFFF is=20 > > > > > > encountered in the stream.=20 > > > > > >=20 > > > > > > 3. Otherwise, the next message in the stream is a=20 > SIP message.=20 > > > > > > Read the stream until a CR/LF/CR/LF is encountered. Parse = > > > > > > the headers, and then read the number of bytes specified=20 > > > > > > in the "Content-Length" header.=20 > > > > > >=20 > > > > > > 4. Return to step 1.=20 > > > > > >=20 > > > > > > /a=20 > > > > > >=20 > > > > > _______________________________________________=20 > > > > > Sipping mailing list=20 > https://www1.ietf.org/mailman/listinfo/sipping=20 > > > > This list is for NEW development of the application of SIP=20 > > > > Use sip-implementors@cs.columbia.edu for questions on=20 > current sip=20 > > > > Use sip@ietf.org for new developments of core SIP=20 > > >=20 > > > --=20 > > > Gonzalo Camarillo Phone : +358 9 299 33 71=20 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35=20 > > > Telecom R&D Fax : +358 9 299 30 52=20 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com=20 > > > Finland http://www.hut.fi/~gonzalo=20 > > >=20 > > _______________________________________________=20 > > Rohc mailing list=20 > > Rohc@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/rohc=20 > > _______________________________________________=20 > > Rohc mailing list=20 > > Rohc@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/rohc=20 > >=20 > _______________________________________________=20 > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping=20 > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current sip=20 > Use sip@ietf.org for new developments of core SIP=20 >=20 ------_=_NextPart_001_01C2FA3E.4846DC7C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes = sages
Mark,
 
This=20 is exactly the concern I have regarding the SigComp performance = implication. I=20 see this as a question of *what* states to create. More precisely, a = compressor=20 should create only "useful" state(s) from the text part(s) of a message = while=20 avoiding creating "garbage" state(s) from the binary part(s).=20
 
(Of=20 course, it's possible that the binary part may also repeat = across=20 messages and thus become useful. But I wouldn't go there for=20 simplicity.)
 
So,=20 how can a compressor achieve that? Below are ideas I can = think=20 of. If they are correct, I can compile more "formal" text to be added to = the=20 SigComp user guide.
 
There=20 are two steps involved. First, the compressor needs to know if = current=20 message to be compressed contain binary parts, and if yes, where they = are=20 located in the message. Second, the compressor needs to make sure it can = selectively create states on the decompressor side.
 
For=20 the first step, the best thing can happen is that = the application (SIP=20 in this case) gives hint to sigcomp compressor. This is possible, = since it=20 is a matter of local interface between application and sigcomp = layer within=20 the same endpoint. Otherwise (i.e. no help from application), the = compressor=20 has to figure it out by itself. In general, this seems to be a difficult = problem=20 to solve (if possible at all). But there are a few simple and practical=20 approaches one can consider.
 
For=20 example, the compressor can check the compression ratio after = compressing the=20 message. If it is close to 1, that is a hint that the current = message=20 probably contains large binary content. The compressor can choose not to = create=20 any state from current message. However, the compressor may miss a small = text=20 segment in the message that turns out being repeated later in the = subsequent=20 messages. The positive side is that at least the compressor can avoid = creating=20 "garbage states".
 
Another factor to make a compressor's (or rather = implementer's) life=20 easier: we can assume that application messages have two = parts,=20 namely, a UTF-8 encoded part at the beginning followed by a binary part. = (Note=20 this is the case at least for SIP.) Then, the compressor can identify = the UTF-8=20 part (by parsing) and use it to create state. This also = has a=20 good side-effect: compressor can avoid compressing the = remaining=20 binary part.
 
Now to=20 the second step: creating state on decompressor side. One issue I see is = the=20 limitation of decompression memory. On the decompressor side, the large = binary=20 content may overwrite text content previously stored in the ring/history = buffer=20 (part of the UDVM buffer). One solution is that the compressor = should=20 "segment" one large application message into multiple sigcomp messages, = so that=20 one of them contains only text data. This avoids the overwriting = problem.=20 (Note: I don't think this works for SigComp over UDP. But on = the other=20 hand, large SIP messages must be carried over TCP, not = UDP.)
 
BR,
Zhigang
 
-----Original Message-----
From: ext Mark Watson=20 [mailto:mwatson@nortelnetworks.com]
Sent: April 03, 2003 = 8:35=20 AM
To: 'Price, Richard'; Liu Zhigang.C (NRC/Dallas); = cabo@tzi.org;=20 Lars-Erik.Jonsson@epl.ericsson.se
Cc: rohc@ietf.org;=20 sipping@ietf.org
Subject: RE: [rohc] RE: [Sipping] SIGCOMP = and large=20 binary content SIP mes sages

Richard, all,

The issue I would like to see addressed is as = follows:=20

The text part of SIP/SDP is obviously highly = compressible=20 using very simple algorithms which refer back to previous parts of the = message/earlier messages. In fact, subsequent messages in a SIP dialog = seem to=20 consist almost entirely of repeated text from previous = messages.

So, it seems important to me that large binary = content in SIP=20 messages does not destroy state that will be useful in compressing = subsequent=20 messages.

In a wireless environment, the principle advantage = of=20 compression is reduction in the time taken to actually send the = message over=20 the wireless link (this may even be more important than the overall = reduction=20 in signalling bandwidth).

Now if the message contains large binary content, = then of=20 course we are 'out of luck' on the message transfer time stakes, but = this=20 shouldn't affect subsequent messages.

I believe we should document recommendations to = SIGCOMP=20 compressor designers to ensure this aspect is not overlooked (although = it is=20 not immediately clear to me how the compressor (being unaware of the = SIP=20 message structure) might achieve this.)

Is this something that would be appropriate to item = 4 below=20 ?

Regards...Mark

> -----Original Message-----
>=20 From: Price, Richard [mailto:richard.price@roke.co.uk<= /A>]=20
> Sent: 26 March 2003 13:58
>=20 To: 'zhigang.c.liu@nokia.com'; cabo@tzi.org;
>=20 Lars-Erik.Jonsson@epl.ericsson.se
> Cc:=20 rohc@ietf.org; sipping@ietf.org
> = Subject: RE:=20 [rohc] RE: [Sipping] SIGCOMP and large binary content SIP =
> mes sages
> =
>
> Hi,
>=20
> I think that the issue with SigComp and = large=20 binary
> content SIP messages is part of = a more=20 general issue -
> namely that before = using SigComp=20 to compress a particular
> application we = need to=20 standardise the following:
> =
> 1. Mechanism for SigComp discovery
> 2.=20 Resources offered by SigComp
> 3. How to = delimit=20 messages
> 4. When to save state =
>
> Currently the SIPPING WG = has provided=20 RFCs for 1 and 2,
> but not for 3 and 4. = It would=20 be useful to get a draft
> out for these = ASAP, as=20 it would clarify several issues on
> how = to get=20 SigComp working with SIP (including the issue
>=20 with large binary content SIP messages).
>=20
> > Unless someone objects, I'll = submit it in=20 ROHC.
>
> I = think that=20 any WG draft should be a product of the
> = SIPPING=20 WG, because the proposed solution for delimiting
>=20 SigComp messages will need to take into account the
> behaviour of SIP itself (or we won't be able to = multiplex=20
> SigComp and SIP messages on the same port). = However,=20 it
> would be good to get the ROHC WG = involved in=20 generating
> the draft as well! =
>
> Regards,
>=20
> Richard
>=20
> P.S. For anyone who's interested, the = mechanisms=20 that
> particular applications need to = provide=20 before they can
> use SigComp are as=20 follows...
>
>=20 ------------------------------------------------------ =
>
> 1. Mechanism for SigComp=20 discovery
>
>    - How does the application know when = to use=20 SigComp?
>
> = For SIP=20 this issue is already sorted (RFC 3486).
>=20
>=20 ------------------------------------------------------ =
>
> 2. Resources offered by=20 SigComp
>
>    - Does the application need to offer = more than=20 the
>      = minimum amount=20 of resources?
>
>    - Does the application need any extra = state=20 (e.g.
>      a = static=20 dictionary)?
>
> For SIP=20 we've already got a static dictionary (RFC 3485).
>=20 However, we haven't currently discussed how much memory =
> should be provided in a SigComp implementation for = SIP.=20
> If we don't specify a value then SigComp = defaults to=20 the
> minimum possible (2K), which is = rather tight=20 for some of
> the more generously sized = SIP=20 messages!
>
>=20 ------------------------------------------------------ =
>
> 3. How to delimit = messages=20
>
>    - How=20 does the application distinguish between
>      SigComp messages and = uncompressed=20 messages?
>
>    - Is the application allowed to use = "continuous=20 mode"?
>
> = This is the=20 issue that's been raised for large binary
> content=20 SIP messages. If we want to send a mix of
>=20 uncompressed and SigComp messages within the same TCP
> connection, how do we delimit the end of one message = and=20
> the start of another?
>=20
> A related issue is how to handle very = large SIP=20 messages
> (> 64K). SigComp is able to = compress=20 large SIP messages
> by using "continuous = mode",=20 where the message boundaries
> are = ignored=20 completely and the application data is just
>=20 transmitted as a stream. However, this mode of operation =
> raises some additional security issues, so it's up to = the=20
> SIPPING WG to decide whether or not to use it = in=20 SigComp
> for SIP.
>=20
>=20 ------------------------------------------------------ =
>
> 4. When to save = state=20
>
>    - How=20 much security is needed in order to save state?
>=20
>    - Which messages = belong to each=20 state "compartment"?
>
>    - How long should the application keep = state?
>
> = This is quite=20 an important issue that doesn't seem to
> = have been=20 discussed in the SIPPING WG. It's up to the
>=20 application whether or not to let SigComp save state,
> and for interoperability it's important to have = at=20
> least a general idea of how long to keep saved = state,
> when to reject state due to = insufficient=20 security etc.
>
>=20 ------------------------------------------------------ =
>
> > -----Original=20 Message-----
> > From: = zhigang.c.liu@nokia.com=20 [mailto:zhigang.c.liu@nokia.com]=20
> > Sent: Tuesday, March 25, 2003 6:00 = PM=20
> > To: cabo@tzi.org;=20 Lars-Erik.Jonsson@epl.ericsson.se
> > = Cc:=20 rohc@ietf.org; sipping@ietf.org
> > = Subject: RE:=20 [rohc] RE: [Sipping] SIGCOMP and large binary
>=20 content SIP
> > messages =
> >
> > =
> > Hi Carsten and Lars-Erik,
> >=20
> > I've volunteered to submit a = personal draft=20 on this issue. From
> > ROHC WG = chairs' point of=20 view, do you think this is the way
> > = to=20 proceed?
> >
> >=20 Of course, I understood during the IETF56 that Carsten had some =
> > doubts on whether this is indeed an = issue. My email=20 below explained
> > the issue a bit. I = don't=20 know if it's clear. Either way, we
> > = can=20 continue discuss this in ROHC mailing list
> >=20
> http://www1.ietf.org/mail-archive/working-groups/sipping/= curre=20
> nt/msg04115.html
> >=20
> > BR,
> = >=20 Zhigang
> >
> >=20 > -----Original Message-----
> > = > From:=20 ext zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com]=20
> > > Sent: March 13, 2003 9:55 AM =
> > > To: Gonzalo.Camarillo@lmf.ericsson.se =
> > > Cc: adam@dynamicsoft.com; Isomaki Markus=20 (NRC/Helsinki);
> > >=20 mwatson@nortelnetworks.com; sipping@ietf.org; rohc@ietf.org =
> > > Subject: [rohc] RE: [Sipping] SIGCOMP and = large binary=20 content SIP
> > > messages =
> > >
> > > =
> > > I agree. How to handling binary content is a = generic=20 issue for any
> > > application = messages.=20 What I have in mind is to give generic
> = > >=20 descriptions/requirements (mainly on the SigComp receiver =
> parsing part),
> > > = then touch=20 on SIP (perhaps RTSP too) as a particular example.
> > >
> > > = Unless someone=20 objects, I'll submit it in ROHC.
> > = >=20
> > > Zhigang
>=20 > >
> > >
>=20 > > > -----Original Message-----
> >=20 > > From: ext Gonzalo Camarillo
> = [mailto:Gonzalo.Camarill= o@lmf.ericsson.se]=20
> > > > Sent: March 13, 2003 5:36 = AM=20
> > > > To: Liu Zhigang.C = (NRC/Dallas)=20
> > > > Cc: adam@dynamicsoft.com; = Isomaki Markus=20 (NRC/Helsinki);
> > > >=20 mwatson@nortelnetworks.com; sipping@ietf.org
> >=20 > > Subject: Re: [Sipping] SIGCOMP and large binary content=20
> SIP messages
> >=20 > >
> > > > =
> > > > Zhigang,
> = > >=20 >
> > > > you can submit that = draft to=20 ROHC. SIPPING can review
> it = afterwards.=20
> > > > IMO, the competence needed to = generate=20 this draft can
> be found more =
> > > > easily in ROHC than in SIPPING. =
> > > >
> > > = >=20 Besides, you could use SigComp to compress RTSP
>=20 messages, for instance
> > > > = And RTSP is=20 not handle by SIPPING either.
> > > = >=20
> > > > Gonzalo
> > > >
> > > = >=20 zhigang.c.liu@nokia.com wrote:
> > = > >=20 >
> > > > > Yes, that is = also what I=20 had in mind for SIP. But my
> point is = that=20
> > > > > a SigComp receiver now = needs to have=20 some knowledge
> about application =
> > > > > message format and do parsing to = determine the=20 end of
> an uncompressed
> > > > > message. This is something new (or = at least=20
> unspecified) in RFC 3320 =
> > > > > and needs to be spelled out in a new = (standard=20 track)
> RFC. The document =
> > > > > will be short, but I think it's = needed for=20 interoperability.
> > > > >=20
> > > > > I'll write up an = I-D and=20 submit it after IETF 56. But
> I'd like = to=20 know
> > > > > if folks in = SIPPING=20 think it should be done here or in ROHC.
> >=20 > > >
> > > > > = Zhigang=20
> > > > >
> >=20 > > > > -----Original Message-----
>=20 > > > > > From: ext Adam Roach [mailto:adam@dynamicsoft.com]=20
> > > > > > Sent: March 11, 2003 = 9:03=20 PM
> > > > > > To: Liu = Zhigang.C=20 (NRC/Dallas); Adam Roach; Isomaki Markus
> >=20 > > > > (NRC/Helsinki); mwatson@nortelnetworks.com;=20 sipping@ietf.org
> > > > > = >=20 Subject: RE: [Sipping] SIGCOMP and large binary
>=20 content SIP messages
> > > > = >=20 >
> > > > > > =
> > > > > > > -----Original = Message-----=20
> > > > > > > From:=20 zhigang.c.liu@nokia.com
> [mailto:zhigang.c.liu@nokia.com]=20
> > > > > > >
> > > > > > > Having binary content in = SIP=20 messages may have
> two impacts on =
> > > > > > > SigComp:
> > > > > > >
> >=20 > > > > > a) multiplexing of uncompressed messages with =
> SigComp messages on the =
> > > > > > > same port. =
> > > > > > ...
> >=20 > > > > > For a), it is only an issue for SigComp/TCP, = not=20
> SigComp/UDP (where one
> > > > > > > SigComp message maps to = one UDP=20 packet). Adam's
> point 1 and 2 are = related=20
> > > > > > > to this. As to = point 1, I=20 think the SigComp
> receiver still needs = to=20 know
> > > > > > > = (somehow) the=20 end of an uncompressed message, or
> at = least the=20 end of the
> > > > > > = > binary=20 part of each SIP messages. Otherwise, a
> = bit=20 pattern 11111 in
> > > > > = > >=20 the binary part will be mistaken by SigComp as
>=20 the beginning of a SigComp
> > > = > >=20 > > message. As to point 2, I would add that the =
> delimiter 0xFFFF can appear
> > >=20 > > > > at the both the beginning and the end of a=20
> SigComp message. So, the =
> > > > > > > receiver needs to have the = same=20 parsing logic
> just mentioned for bit=20 pattern
> > > > > > >=20 11111.
> > > > > > =
> > > > > > This isn't any more of an issue = than it=20 is without
> SigComp. SIP =
> > > > > > messages provide their own = framing, and=20 SigComp
> messages do the =
> > > > > > same. They can be trivially = mixed on the=20 same stream:
> > > > > = >=20
> > > > > > 1. Peek at the first = byte=20 waiting in the stream.
> > > > = >=20 >
> > > > > > 2. If it = is 0xf8 or=20 higher, the next message in the
> stream = is=20
> > > > > >    a = SigComp=20 message. The message continues until a
> = 0xFFFF=20 is
> > > > > = >   =20 encountered in the stream.
> > > = > >=20 >
> > > > > > 3. = Otherwise, the=20 next message in the stream is a
> SIP=20 message.
> > > > >=20 >    Read the stream until a CR/LF/CR/LF is = encountered.=20 Parse
> > > > > = >   =20 the headers, and then read the number of bytes specified =
> > > > > >    in the = "Content-Length"=20 header.
> > > > > > =
> > > > > > 4. Return to step 1. =
> > > > > >
> = > >=20 > > > /a
> > > > > = >=20
> > > > >=20 _______________________________________________
>=20 > > > > Sipping mailing list
> https://www1.ietf.org/mailman/listinfo/sipping= =20
> > > > This list is for NEW = development of the=20 application of SIP
> > > > Use=20 sip-implementors@cs.columbia.edu for questions on
>=20 current sip
> > > > Use = sip@ietf.org for=20 new developments of core SIP
> > >=20
> > > --
> >=20 > Gonzalo Camarillo         = Phone=20 :  +358  9 299 33 71
> > = > Oy L M=20 Ericsson Ab        Mobile:  = +358 40=20 702 35 35
> > > Telecom=20 = R&D           =    =20 Fax   :  +358  9 299 30 52
>=20 > > FIN-02420=20 Jorvas          Email = : =20 Gonzalo.Camarillo@ericsson.com
> > = >=20 = Finland           =        =20 http://www.hut.fi/~gonzalo
> >=20 >
> >=20 _______________________________________________
>=20 > Rohc mailing list
> > = Rohc@ietf.org=20
> > https://www1.ietf.org/mailman/listinfo/rohc =
> > = _______________________________________________=20
> > Rohc mailing list
> >=20 Rohc@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rohc =
> >
>=20 _______________________________________________
>=20 Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping= =20
> This list is for NEW development of the = application of=20 SIP
> Use = sip-implementors@cs.columbia.edu for=20 questions on current sip
> Use = sip@ietf.org for new=20 developments of core SIP
>=20

------_=_NextPart_001_01C2FA3E.4846DC7C-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 10 03:40:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10541 for ; Thu, 10 Apr 2003 03:40:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A7kL617382 for sipping-archive@odin.ietf.org; Thu, 10 Apr 2003 03:46:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7kL817379 for ; Thu, 10 Apr 2003 03:46:21 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10511 for ; Thu, 10 Apr 2003 03:40:12 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7jR817301; Thu, 10 Apr 2003 03:45:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34K8B814831 for ; Fri, 4 Apr 2003 15:08:11 -0500 Received: from zrc2s0jx.nortelnetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05432 for ; Fri, 4 Apr 2003 15:04:43 -0500 (EST) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h34K6fv04660; Fri, 4 Apr 2003 14:06:41 -0600 (CST) Received: by zsc3c028.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2FGBXCYK>; Fri, 4 Apr 2003 12:06:41 -0800 Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D207A04E21@zsc3c030.us.nortel.com> From: "Francois Audet" To: "'Gonzalo Camarillo'" , "'Michael Hammer'" Cc: "Tom-PT Taylor" , "'Bob Penfield'" , "'sipping@ietf.org'" , "'Jon PETERSON (Jon.Peterson@neustar.com)'" , "'Christer Holmberg'" , "Mark Watson" Subject: RE: [Sipping] New version of the early media draft Date: Fri, 4 Apr 2003 12:06:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FAE5.B4A5ABAA" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FAE5.B4A5ABAA Content-Type: text/plain Gonzallo, doesn't the mechanism in section 3 imply that the UAC sending the initial INVITE needs to know beforehand that this Application Server model will be used and therefore it would amount to requiring all SIP UAC to always include the join header???? > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, April 03, 2003 22:04 > To: Michael Hammer > Cc: Audet, Francois [SC100:4K02:EXCH]; Taylor, Tom-PT > [CAR:5N00:EXCH]; 'Bob Penfield'; 'sipping@ietf.org'; 'Jon > PETERSON (Jon.Peterson@neustar.com)'; 'Christer Holmberg'; > Watson, Mark [MOP:EP10:EXCH] > Subject: Re: [Sipping] New version of the early media draft > > > Michael, > > fetch the draft below: > http://www.ietf.org/internet-drafts/draft-camarillo-sipping-ea > rly-media-01.txt > > Read Section 2.3; this section explains that the gateway > model produces > undesirable results when forking is present. Therefore, you > SHOULD NOT > use this model. However, there are some situations when the gateway > cannot distinguish between early and regular media. In that > situation, > even knowing that there may be problems if forking occurs, > the gateway > has no other choice than using the gateway model. Therefore, > even if you > had an indication telling the gateway that the call forked, > the gateway > DOES NOT HAVE ANY OTHER CHOICE. > > But what happens if your system does have a choice and can actually > distinguish between early and regular media? Go on and read > Section 3. > It provides a mechanism that, if you look at the end result, is > equivalent to yours. Therefore, I assume that you will be happy with > that mechanism. > > Why do we use that mechanism (reverse INVITE) instead of your > mechanism > or UPDATEs with an extra stream with an "early media" label > (documented > in the draft as well)? It is explained in the last pargraph > of Section 3. > > " An alternative model would consist of adding a new stream > labeled as "early media" to the original session between > the UAC and the UAS using an UPDATE, instead of > establishing a new session. We have chosen to establish a > new session to be coherent with the mechanism used by > application servers that are NOT co-located with the UAS. > This way, the UAS uses the same mechanism as any other > application server in the network to interact with the UAC." > > > Hope this helps, > > Gonzalo > > > > Michael Hammer wrote: > > Gonzalo, > > > > Would it be possible to have an early media convention that > contains > > the > > following elements: > > > > 1) the receiving end indicates in signaling that it intends to send > > early media > > 2) the receiving end includes SDP in hold state and does > not send media > > at first > > 3) the caller responds to one receiver's inband indicator > (or not) with > > an UPDATE putting that receiver in send state > > 4) the receiving end responds to UPDATE and begins sending > of RTP with > > media. > > > > This resolves the forking case, tells the caller which > device intends > > inband media, and allows the caller with possibly user in > the loop to > > decide which to listen to. > > > > See the following: > > > > A Forking Proxy User User User > > B1 B2 B3 > > | | | | | > > | INVITE F1 | | | | > > |--------------->| | | | > > | 100 Trying F2 | | | | > > |<---------------| INVITE F3 | | | > > | |------------->| | | > > | | INVITE F4 | | > > | |-------------------->| | > > | | INVITE F5 | | > > | |--------------------------->| > > | | 183 inband F6| | | > > | 183 inband F7 |<-------------| | | > > |<---------------| | | | > > | | 183 inband F8| | | > > | 183 inband F9 |<--------------------| | > > |<---------------| | | | > > | UPDATE send F10| | | | > > |--------------->| UPDATE send F11 | | > > | |-------------------->| | > > | | ACK send F12 | | | > > | ACK send F13 |<--------------------| | > > |<---------------| | | | > > Play<=====|<======Early media====================| | > > | | 180 inband F14 | | > > | 180 inband F15 |<---------------------------| > > |<---------------| CANCEL F16 | | | > > | |------------->|media | | > > | | 200 OK F17 |stops | | > > | |<-------------| | | > > | | 487 F18 | | | > > | |<-------------| | | > > | | ACK F19 | | | > > | |------------->| | | > > | UPDATE send F20| | | | > > |--------------->| UPDATE send F21 | | > > | |--------------------------->| > > | | ACK send F22 | | | > > | ACK send F23 |<---------------------------| > > |<---------------| | | | > > Play<=====|<==============="Hello"======================| > > | | 200 OK F24 | > > | 200 OK F25 |<---------------------------| > > |<---------------| | | | > > | ACK send F26 | | | | > > |--------------->| ACK send F27 | | | > > | |--------------------------->| > > | | | | | > > > > Am I missing anything here? > > The key is to stop guessing and make it more deterministic. > > > > If you don't like this, don't use the inband indicator, and > fall back > > to > > the current state of problems. > > > > Mike > > > > > > At 01:18 PM 4/3/2003 +0300, Gonzalo Camarillo wrote: > > > >> Francois, > >> > >> you are missing the point of the draft. The draft explains what > >> happens when you use early media within the dialog are > forking occurs. > >> That is, you have a lot of problems. > >> > >> The aim of the draft is to describe these problems and to describe > >> things that a UAC may do without extending the protocol. > We do that > >> because you have to interact with existing UASs that will send you > >> media this way. You cannot upgrade the already installed base. > >> > >> But we do not want to extend the protocol to provide a solution for > >> this gateway model. We recommend that new systems use the > application > >> server model. In this model, we will provide solutions and > extend the > >> protocol should that be needed. > >> > >> Gonzalo > >> > >> Francois Audet wrote: > >> > >>> > First of all, I do not understand why people continue > >>> > discussing things > >>> > like early media with forking whose problems are > already well > > >>> discussed > and documented in the draft and nobody so > far has been > >>> able > to come up > >>> > with a single use case where the proposed flag would > be useful... I > >>> > would ask people to focus on the problem in hand (i.e., the > >>> > flag), and > >>> > stop discussing about already resolved issues. > >>> The problem is that the multiple dialog problem and early media > >>> problem (as in forking > >>> for example) has NOT been solved. Worst, using the > current unworkable > >>> solution as a basis > >>> to make our decisions on the flag issue will not result in a good > >>> solution. > >>> The current solution for forking in the draft is for the > UAC to pick > >>> a random media > >>> stream (based on signaling, thus the dialog, not media, > because there > >>> is no means to correlate > >>> dialog and media stream) and mute the others by sending > UPDATEs to > >>> the far end. This is > >>> not an acceptable solution. Random non-redictable behavior is not > >>> acceptable to end-users. > >>> Furthemore, this is not robust at all because if the > called UA does > >>> not support UPDATE, > >>> multiple streams will be received and there will be no > way for the > >>> UAC receiving it > >>> to pick the proper one. (If there was a way to correlate an RTP > >>> stream to the dialog that > >>> generate it, it would be easier) > >>> This leaves the client with 3 choices: > >>> 1) Pick a random media stream (which it will not be able > to correlate > >>> with a specific dialog > >>> unless it is lucky with educated guesses). > >>> 2) Mix media streams together. > >>> 3) Provide alternative local treatment based on the provisional > >>> responses received. This > >>> could be > >>> > >>> You are right that the flag probably doesn't help with > this problem. > >>> I'll leave it > >>> to others to defend the flag idea. > >>> I'm OK with current draft, as long as we do not ADD any more > >>> dependency on the "play > >>> media when you receive it" principle to address the flag > prolem, and > >>> as long as we improve > >>> the section on forking. It seems to me that if forking is > used we CAN > >>> NOT use early media for > >>> in-band ringing (we could do early media for clipping avoidance). > >>> Perhaps we need a > >>> "forked" indication in INVITE telling the far-end not to > send early > >>> media... And to make > >>> it bullet proof a forked indication in the 100 Trying > (when forking) > >>> to tell the UAC making the > >>> call that "weird stuff" is going to happen and that > proper treatment > >>> should be used not > >>> to confused the user. > >> > >> > >> > >> -- > >> Gonzalo Camarillo Phone : +358 9 299 33 71 > >> Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > >> Telecom R&D Fax : +358 9 299 30 52 > >> FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > >> Finland http://www.hut.fi/~gonzalo > >> > >> _______________________________________________ > >> Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > >> This list > is for NEW development of the application of SIP Use > >> sip-implementors@cs.columbia.edu for questions on current sip Use > >> sip@ietf.org for new developments of core SIP > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > ------_=_NextPart_001_01C2FAE5.B4A5ABAA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sipping] New version of the early media draft

Gonzallo, doesn't the mechanism in section 3 imply = that the UAC sending the
initial INVITE needs to know beforehand that this = Application Server model
will be used and therefore it would amount to = requiring all SIP UAC to
always include the join header????

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: Thursday, April 03, 2003 22:04
> To: Michael Hammer
> Cc: Audet, Francois [SC100:4K02:EXCH]; Taylor, = Tom-PT
> [CAR:5N00:EXCH]; 'Bob Penfield'; = 'sipping@ietf.org'; 'Jon
> PETERSON (Jon.Peterson@neustar.com)'; 'Christer = Holmberg';
> Watson, Mark [MOP:EP10:EXCH]
> Subject: Re: [Sipping] New version of the early = media draft
>
>
> Michael,
>
> fetch the draft below:
> http://www.ietf.org/internet-drafts/draft-camarillo-si= pping-ea
> rly-media-01.txt
>
> Read Section 2.3; this section explains that = the gateway
> model produces
> undesirable results when forking is present. = Therefore, you
> SHOULD NOT
> use this model. However, there are some = situations when the gateway
> cannot distinguish between early and regular = media. In that
> situation,
> even knowing that there may be problems if = forking occurs,
> the gateway
> has no other choice than using the gateway = model. Therefore,
> even if you
> had an indication telling the gateway that the = call forked,
> the gateway
> DOES NOT HAVE ANY OTHER CHOICE.
>
> But what happens if your system does have a = choice and can actually
> distinguish between early and regular media? Go = on and read
> Section 3.
> It provides a mechanism that, if you look at = the end result, is
> equivalent to yours. Therefore, I assume that = you will be happy with
> that mechanism.
>
> Why do we use that mechanism (reverse INVITE) = instead of your
> mechanism
> or UPDATEs with an extra stream with an = "early media" label
> (documented
> in the draft as well)? It is explained in the = last pargraph
> of Section 3.
>
> "     An alternative = model would consist of adding a new stream
>          = labeled as "early media" to the original session = between
>          the = UAC and the UAS using an UPDATE, instead of
>          = establishing a new session. We have chosen to establish a
>          new = session to be coherent with the mechanism used by
>          = application servers that are NOT co-located with the UAS.
>          = This way, the UAS uses the same mechanism as any other
>          = application server in the network to interact with the = UAC."
>
>
> Hope this helps,
>
> Gonzalo
>
>
>
> Michael Hammer wrote:
> > Gonzalo,
> >
> > Would it be possible to have an early = media convention that
> contains
> > the
> > following elements:
> >
> > 1) the receiving end indicates in = signaling that it intends to send
> > early media
> > 2) the receiving end includes SDP in hold = state and does
> not send media
> > at first
> > 3) the caller responds to one receiver's = inband indicator
> (or not) with
> > an UPDATE putting that receiver in send = state
> > 4) the receiving end responds to UPDATE = and begins sending
> of RTP with
> > media.
> >
> > This resolves the forking case, tells the = caller which
> device intends
> > inband media, and allows the caller with = possibly user in
> the loop to
> > decide which to listen to.
> >
> > See the following:
> >
> = >           = A          Forking = Proxy       User   User  = User
> = >           &n= bsp;           &n= bsp;           &n= bsp;       B1     = B2     B3
> = >           = |            = ;    = |            = ;  |      |     = |
> = >           = |    INVITE F1   = |            = ;  |      |     = |
> = >           = |--------------->|        &nb= sp;     |      = |     |
> = >           | 100 = Trying F2  = |            = ;  |      |     = |
> = >           = |<---------------|   INVITE F3  = |      |     |
> = >           = |            = ;    |------------->|      = |     |
> = >           = |            = ;    |       INVITE = F4     |      |
> = >           = |            = ;    = |-------------------->|      |
> = >           = |            = ;    = |          INVITE F5  = |      |
> = >           = |            = ;    |--------------------------->|
> = >           = |            = ;    | 183 inband F6|      = |      |
> = >           | 183 = inband F7  |<-------------|      = |     |
> = >           = |<---------------|        &nb= sp;     |      = |     |
> = >           = |            = ;    | 183 inband F8|      = |     |
> = >           | 183 = inband F9  = |<--------------------|      |
> = >           = |<---------------|        &nb= sp;     |      = |      |
> = >           | = UPDATE send = F10|           &n= bsp;  |      = |      |
> = >           = |--------------->| UPDATE send F11     = |      |
> >       &n= bsp;   = |            = ;    = |-------------------->|      |
> = >           = |            = ;    | ACK send F12 |      = |      |
> = >           | ACK = send F13   = |<--------------------|      |
> = >           = |<---------------|        &nb= sp;     |      = |      |
> > = Play<=3D=3D=3D=3D=3D|<=3D=3D=3D=3D=3D=3DEarly = media=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| =     |
> = >           = |            = ;    | 180 inband F14      = |      |
> = >           | 180 = inband F15 |<---------------------------|
> = >           = |<---------------|  CANCEL F16  = |      |      = |
> = >           = |            = ;    |------------->|media = |      |
> = >           = |            = ;    |  200 OK F17  |stops = |     |
> = >           = |            = ;    |<-------------|      = |     |
> = >           = |            = ;    |    487 F18   = |      |     |
> = >           = |            = ;    |<-------------|      = |     |
> = >           = |            = ;    |    ACK F19   = |      |     |
> = >           = |            = ;    |------------->|      = |     |
> = >           | = UPDATE send = F20|           &n= bsp;  |      = |      |
> = >           = |--------------->| UPDATE send F21     = |      |
> = >           = |            = ;    |--------------------------->|
> = >           = |            = ;    | ACK send F22 |      = |      |
> = >           | ACK = send F23   |<---------------------------|
> = >           = |<---------------|        &nb= sp;     |      = |      |
> > = Play<=3D=3D=3D=3D=3D|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= "Hello"=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D|
> = >           = |            = ;    = |            200 = OK F24      |
> = >           = |   200 OK F25   = |<---------------------------|
> = >           = |<---------------|        &nb= sp;     |      = |     |
> = >           | ACK = send F26   = |            = ;  |      |      = |
> = >           = |--------------->| ACK send F27 |      = |      |
> = >           = |            = ;    |--------------------------->|
> = >           = |            = ;    = |            = ;  |      |      = |
> >
> > Am I missing anything here?
> > The key is to stop guessing and make it = more deterministic.
> >
> > If you don't like this, don't use the = inband indicator, and
> fall back
> > to
> > the current state of problems.
> >
> > Mike
> >
> >
> > At 01:18 PM 4/3/2003 +0300, Gonzalo = Camarillo wrote:
> >
> >> Francois,
> >>
> >> you are missing the point of the = draft. The draft explains what
> >> happens when you use early media = within the dialog are
> forking occurs.
> >> That is, you have a lot of = problems.
> >>
> >> The aim of the draft is to describe = these problems and to describe
> >> things that a UAC may do without = extending the protocol.
> We do that
> >> because you have to interact with = existing UASs that will send you
> >> media this way. You cannot upgrade the = already installed base.
> >>
> >> But we do not want to extend the = protocol to provide a solution for
> >> this gateway model. We recommend that = new systems use the
> application
> >> server model. In this model, we will = provide solutions and
> extend the
> >> protocol should that be needed.
> >>
> >> Gonzalo
> >>
> >> Francois Audet wrote:
> >>
> >>>  > First of all, I do not = understand why people continue
> >>>  > discussing = things
> >>>  > like early media with = forking whose problems are
> already well  >
> >>> discussed  > and = documented in the draft and nobody so
> far has been
> >>> able  > to come up
> >>>  > with a single use case = where the proposed flag would
> be useful... I
> >>>  > would ask people to = focus on the problem in hand (i.e., the
> >>>  > flag), and
> >>>  > stop discussing about = already resolved issues.
> >>> The problem is that the multiple = dialog problem and early media
> >>> problem (as in forking
> >>> for example) has NOT been solved. = Worst, using the
> current unworkable
> >>> solution as a basis
> >>> to make our decisions on the flag = issue will not result in a good
> >>> solution.
> >>> The current solution for forking = in the draft is for the
> UAC to pick
> >>> a random media
> >>> stream (based on signaling, thus = the dialog, not media,
> because there
> >>> is no means to correlate
> >>> dialog and media stream) and mute = the others by sending
> UPDATEs to
> >>> the far end. This is
> >>> not an acceptable solution. Random = non-redictable behavior is not
> >>> acceptable to end-users.
> >>> Furthemore, this is not robust at = all because if the
> called UA does
> >>> not support UPDATE,
> >>> multiple streams will be received = and there will be no
> way for the
> >>> UAC receiving it
> >>> to pick the proper one. (If there = was a way to correlate an RTP
> >>> stream to the dialog that
> >>> generate it, it would be = easier)
> >>> This leaves the client with 3 = choices:
> >>> 1) Pick a random media stream = (which it will not be able
> to correlate
> >>> with a specific dialog
> >>>    unless it is = lucky with educated guesses).
> >>> 2) Mix media streams = together.
> >>> 3) Provide alternative local = treatment based on the provisional
> >>> responses received. This
> >>>    could be
> >>>
> >>> You are right that the flag = probably doesn't help with
> this problem.
> >>> I'll leave it
> >>> to others to defend the flag = idea.
> >>> I'm OK with current draft, as long = as we do not ADD any more
> >>> dependency on the = "play
> >>> media when you receive it" = principle to address the flag
> prolem, and
> >>> as long as we improve
> >>> the section on forking. It seems = to me that if forking is
> used we CAN
> >>> NOT use early media for
> >>> in-band ringing (we could do early = media for clipping avoidance).
> >>> Perhaps we need a
> >>> "forked" indication in = INVITE telling the far-end not to
> send early
> >>> media... And to make
> >>> it bullet proof a forked = indication in the 100 Trying
> (when forking)
> >>> to tell the UAC making the
> >>> call that "weird stuff" = is going to happen and that
> proper treatment
> >>> should be used not
> >>> to confused the user.
> >>
> >>
> >>
> >> --
> >> Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> >> Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> >> Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> >> FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> >> = Finland           = ;        http://www.hut.fi/~gonzalo
> >>
> >> = _______________________________________________
> >> Sipping mailing list 
> https://www1.ietf.org/mailman/listinfo/sipping
> >> This list
> is for NEW development of the application of = SIP Use
> >> sip-implementors@cs.columbia.edu for = questions on current sip Use
> >> sip@ietf.org for new developments of = core SIP
> >
>
>
> --
> Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> = Finland           = ;        http://www.hut.fi/~gonzalo
>
>

------_=_NextPart_001_01C2FAE5.B4A5ABAA-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 10 03:41:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10564 for ; Thu, 10 Apr 2003 03:41:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A7kYS17398 for sipping-archive@odin.ietf.org; Thu, 10 Apr 2003 03:46:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7kY817395 for ; Thu, 10 Apr 2003 03:46:34 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10521 for ; Thu, 10 Apr 2003 03:40:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7k6817351; Thu, 10 Apr 2003 03:46:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h35H0O807722 for ; Sat, 5 Apr 2003 12:00:24 -0500 Received: from telesoft.indts.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10840; Sat, 5 Apr 2003 11:56:30 -0500 (EST) Received: from indts_fs.indts.com (indts_fs.indts.com [201.64.64.29]) by telesoft.indts.com (8.11.6/8.11.6) with ESMTP id h35GlPI06343; Sat, 5 Apr 2003 22:17:25 +0530 Received: by INDTS_FS with Internet Mail Service (5.5.2650.21) id ; Sat, 5 Apr 2003 22:28:46 +0530 Message-ID: From: Nitin Kumar Date: Sat, 5 Apr 2003 22:28:43 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] 486/603 Response issue in Proxy server Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , hi Folks, Would like to get some clue on following issue. I am using "SIP express Router" as my proxy server to test our SIP user agents. Now if one UA(lets say party A) sends INVITE to other UA (lets say party B) via proxy server, we are finding that any non-2xx response (like 486 busy, 603 decline) received by proxy server from party B is not forwarded to party A. Moreover proxy server is also sending valid ACK to non-2xx response to party B. A PS (SIP express router) B | | | |----------INVITE------------>| | | |----------INVITE------------>| |<---------100 trying---------| | | |<---------100 trying---------| | | | | |<---------180 trying---------| |<---------180 trying---------| | | | | | |<---------603 decline--------| | 603 not forwarded | | | |------------ACK------------->| | | | | | | | | | any idea what may be the reason? In case of successful call everything works fine. will appreciate some clue from sip experts. regards, -nitin _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 10 03:41:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10615 for ; Thu, 10 Apr 2003 03:41:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A7lGt17459 for sipping-archive@odin.ietf.org; Thu, 10 Apr 2003 03:47:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7lG817456 for ; Thu, 10 Apr 2003 03:47:16 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10582 for ; Thu, 10 Apr 2003 03:41:11 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7kj817423; Thu, 10 Apr 2003 03:46:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37GTd824646 for ; Mon, 7 Apr 2003 12:29:39 -0400 Received: from rsys002a.roke.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25632; Mon, 7 Apr 2003 12:24:46 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Apr 2003 17:27:17 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED41804A0F20F@rsys002a.roke.co.uk> From: "Price, Richard" To: "'zhigang.c.liu@nokia.com'" , cabo@tzi.org, Lars-Erik.Jonsson@epl.ericsson.se Cc: rohc@ietf.org, sipping@ietf.org Subject: RE: [rohc] RE: [Sipping] SIGCOMP and large binary content SIP mes sages Date: Mon, 7 Apr 2003 17:27:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , > > Regarding point a), I don't see how this can be done without > > talking about specific protocols. > > I agree if you mean the exact logic (see below). But what I had in > mind for a) is a generic or abstract logic as follows: > > 0. Endpoint B informs endpoint A that it supports SigComp AND > multiplexing of uncompressed message and SigComp message on > a TCP connection. This should be part of the SigComp discovery. > > 1. Endpoint B reads in one byte. > > 2. If the first 5 MSB of the byte is 11111. this is the beginning > of a SigComp message or a SigComp message delimiter (0xFFFF). > Endpoint B enters "SigComp parsing mode" and processes byte stream > according to SigComp until it encounters END-MESSAGE instruction > or Sigcomp delimiter. When that happens, go to 1. > > 3. Else, this is the beginning of an uncompressed message. Endpoint > B enters "uncompressed parsing mode" and parses the byte stream > according to the delimiting scheme of the application messages. > When reaching the end of application message, go to 1. > > Now, back to your comment. I certainly agree with you that detecting > end of application message in Step 3 depends on a particular application > protocol. But other than that, the rest is pretty generic. We can > consider the above as the abstract logic that will be "instantiated" > when binding SigComp to a particular application. Hi Zhigang, Both of Step 1 and Step 2 are already documented in the SigComp RFC. If Step 3 never arises then Endpoint B can decompress the entire stream without any problem, using the delimiting scheme from RFC 3320. Step 0 and Step 3 are not defined in RFC 3320, but this is ok because both steps are 100% application-specific. If the endpoint ever reaches Step 3 then there are at least four ways that it could proceed: i) Always fail (i.e. no multiplexing allowed at all). ii) Fail unless it's the very first byte of the stream. This is just enough to allow application and SigComp streams to be multiplexed on the same port, but not enough to multiplex messages on the same stream. iii) Use SigComp-style delimiters for everything (i.e. for both the application and the SigComp messages). iv) Let the application decide where the message ends and when to hand the parsing back to SigComp. It's up to particular applications to decide which strategy is the most appropriate - currently I haven't seen a convincing reason why we need anything more complex than ii) for the case of SIP. Regards, Richard _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 10 03:42:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10669 for ; Thu, 10 Apr 2003 03:42:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3A7lvm17607 for sipping-archive@odin.ietf.org; Thu, 10 Apr 2003 03:47:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7lu817604 for ; Thu, 10 Apr 2003 03:47:57 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10634 for ; Thu, 10 Apr 2003 03:41:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3A7lK817482; Thu, 10 Apr 2003 03:47:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39ABI831252 for ; Wed, 9 Apr 2003 06:11:18 -0400 Received: from mail.tssg.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19932; Wed, 9 Apr 2003 06:04:27 -0400 (EDT) Received: from boolard (unknown [10.37.1.56]) by mail.tssg.org (Postfix) with SMTP id 93C6818179; Wed, 9 Apr 2003 10:42:51 +0000 (GMT) From: "Shane McCormack" To: "Sip@Ietf. Org" Cc: "Sipping@Ietf. Org" Date: Wed, 9 Apr 2003 10:55:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01C2FE86.8BB0FCA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Sipping] Geopriv and SIP current state Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0085_01C2FE86.8BB0FCA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Could somebody please let me know how spatial location information will be requested and returned using SIP. Will it be a new header in all messages or can SUBSCRIBE messages request NOTIFY of geo location. Also what format will this take, will it be similar to the presence XML format? Any help would be much appreciated. Regards Shane McCormack Research Assistant, TSSG, Confederation House, Waterford Business Park, Cork Road, Waterford, Co. Waterford. Phone: +353 51 302927 Fax: +353 51 302901 Mobile: +353 87 9955505 http://www.tssg.org MSN: mccormackshane@hotmail.com ------=_NextPart_000_0085_01C2FE86.8BB0FCA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
Could = somebody=20 please let me know how spatial location information will be requested = and=20 returned using SIP. Will it be a new header in all messages or can = SUBSCRIBE=20 messages request NOTIFY of geo location. Also what format will this = take, will=20 it be similar to the presence XML format? Any help would be much=20 appreciated.
 
Regards
 

Shane=20 McCormack

Research = Assistant,
TSSG, = Confederation=20 House, =
Waterford = Business=20 Park, Cork Road,=20
Waterford, Co.=20 Waterford.

Phone:=20 +353 51 302927     Fax: +353 51 302901=20
Mobile:=20 +353 87 9955505=20
http://www.tssg.org =
MSN:=20 mccormackshane@hotmail.com= =20

 

 
------=_NextPart_000_0085_01C2FE86.8BB0FCA0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 10 09:15:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19143 for ; Thu, 10 Apr 2003 09:15:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ADKqj09558 for sipping-archive@odin.ietf.org; Thu, 10 Apr 2003 09:20:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ADKq809551 for ; Thu, 10 Apr 2003 09:20:52 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19111 for ; Thu, 10 Apr 2003 09:14:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ADKC809515; Thu, 10 Apr 2003 09:20:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ADIu809386 for ; Thu, 10 Apr 2003 09:18:56 -0400 Received: from il-tlv-smtpout2.icomverse.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19066; Thu, 10 Apr 2003 09:12:43 -0400 (EDT) Received: from il-tlv-mbdg1.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id h3ADEuQ26089; Thu, 10 Apr 2003 16:14:57 +0300 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id ; Thu, 10 Apr 2003 16:15:04 +0300 Message-ID: <32B823C1CD4FD5119C0D0002A560F78E091FF412@ismail3.comverse.com> From: Fuxbruner Amihay To: "'sdonovan@dynamicsoft.com'" , "'jdrosen@dynamicsoft.com'" , sip-implementors@cs.columbia.edu, sip@ietf.org, sipping@ietf.org Cc: Isaac Dudy Date: Thu, 10 Apr 2003 16:15:03 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2FF63.32313108" Subject: [Sipping] Session timer - Supported header question Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C2FF63.32313108 Content-Type: text/plain; charset="windows-1255" Hello all, The session timer draft (draft-ietf-sip-session-timer-10.txt) section 7.1 says: " A UAC which supports the session timer extension defined here MUST include a Supported header field in each request (except ACK), listing the option tag "timer" [1]. It MUST do so even if the UAC is not requesting usage of the session timer for this session." Is this requirement reasonable?? Isn't it enough to send Supported header in the initial request?? Thanks for your answer in advance. Amihay Fuxbruner Comverse ------_=_NextPart_001_01C2FF63.32313108 Content-Type: text/html; charset="windows-1255" Session timer - Supported header question

Hello all,

The session timer draft (draft-ietf-sip-session-timer-10.txt) section 7.1 says:

"  A UAC which supports the session timer extension defined here MUST
   include a Supported header field in each request (except ACK),
   listing the option tag "timer" [1]. It MUST do so even if the UAC is
   not requesting usage of the session timer for this session."

Is this requirement reasonable??
Isn't it enough to send Supported header in the initial request??

Thanks for your answer in advance.

Amihay Fuxbruner
Comverse

------_=_NextPart_001_01C2FF63.32313108-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 10 13:52:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28014 for ; Thu, 10 Apr 2003 13:52:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AHwAJ30920 for sipping-archive@odin.ietf.org; Thu, 10 Apr 2003 13:58:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHwA830917 for ; Thu, 10 Apr 2003 13:58:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27969 for ; Thu, 10 Apr 2003 13:51:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193fxC-00034Y-00 for sipping-web-archive@ietf.org; Thu, 10 Apr 2003 13:35:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 193fxC-00034V-00 for sipping-web-archive@ietf.org; Thu, 10 Apr 2003 13:35:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHv9830825; Thu, 10 Apr 2003 13:57:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AHtl830744 for ; Thu, 10 Apr 2003 13:55:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27859 for ; Thu, 10 Apr 2003 13:49:29 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193fuu-00032v-00 for sipping@ietf.org; Thu, 10 Apr 2003 13:32:52 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 193fut-00032j-00 for sipping@ietf.org; Thu, 10 Apr 2003 13:32:51 -0400 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h3AHoaOg016817 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 10 Apr 2003 12:51:32 -0500 From: "Dean Willis" To: "'Shane McCormack'" Cc: "'Sipping@Ietf. Org'" Subject: RE: [Sipping] Geopriv and SIP current state Date: Thu, 10 Apr 2003 12:49:59 -0500 Message-ID: <003d01c2ff89$bcf2daf0$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01C2FF5F.D41CD2F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_003E_01C2FF5F.D41CD2F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I think that geolocation information could reasonably be included in presence documents and correspondingly delivered in presence = notifications as being developed in SIMPLE. It would probably NOT be appropriat, as a general solution, to include geoloc (as a header or otherwise) in every message as the overhead of protecting that content could become = enormous. =20 Requesting "just geoloc" when subscribing to someone's presence would perhaps be implemented using the filtering mechanisms currently being discussed in SIMPLE and SIPPING. =20 The actual format of geoloc data has not yet been determined. I = anticipate using the location format deliverable of the GEOPRIV working group. =20 -- Dean =20 -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf = Of Shane McCormack Sent: Wednesday, April 09, 2003 4:56 AM To: Sip@Ietf. Org Cc: Sipping@Ietf. Org Subject: [Sipping] Geopriv and SIP current state Hi, Could somebody please let me know how spatial location information will = be requested and returned using SIP. Will it be a new header in all = messages or can SUBSCRIBE messages request NOTIFY of geo location. Also what format = will this take, will it be similar to the presence XML format? Any help would = be much appreciated. =20 Regards =20 Shane McCormack Research Assistant, TSSG, Confederation House,=20 Waterford Business Park, Cork Road,=20 Waterford, Co. Waterford.=20 Phone: +353 51 302927 Fax: +353 51 302901=20 Mobile: +353 87 9955505=20 http://www.tssg.org=20 MSN: mccormackshane@hotmail.com=20 =20 =20 ------=_NextPart_000_003E_01C2FF5F.D41CD2F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
I think that geolocation information could reasonably be = included in=20 presence documents and correspondingly delivered in presence = notifications as=20 being developed in SIMPLE. It would probably NOT be appropriat, as a = general=20 solution, to include geoloc (as a header or otherwise) in every message = as the=20 overhead of protecting that content could become = enormous.
 
Requesting "just geoloc" when subscribing to someone's presence = would=20 perhaps be implemented using the filtering mechanisms currently being = discussed=20 in SIMPLE and SIPPING.
 
The=20 actual format of geoloc data has not yet been determined. I = anticipate=20 using the location format deliverable of the GEOPRIV working=20 group.
 
--
Dean
 
-----Original Message-----
From:=20 sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of = Shane McCormack
Sent: Wednesday, April 09, 2003 4:56=20 AM
To: Sip@Ietf. Org
Cc: Sipping@Ietf.=20 Org
Subject: [Sipping] Geopriv and SIP current=20 state

Hi,
Could somebody=20 please let me know how spatial location information will be requested = and=20 returned using SIP. Will it be a new header in all messages or can = SUBSCRIBE=20 messages request NOTIFY of geo location. Also what format will this = take, will=20 it be similar to the presence XML format? Any help would be much=20 appreciated.
 
Regards
 

Shane=20 McCormack

Research=20 Assistant,
TSSG, Confederation=20 House, =
Waterford Business=20 Park, Cork Road,=20
Waterford, Co.=20 Waterford. =

Phone:=20 +353 51 302927     Fax: +353 51 302901=20
Mobile:=20 +353 87 9955505=20
http://www.tssg.org=20
MSN:=20 mccormackshane@hotmail.com= =20

 

 
------=_NextPart_000_003E_01C2FF5F.D41CD2F0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 10 14:06:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28743 for ; Thu, 10 Apr 2003 14:06:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AIBpH00369 for sipping-archive@odin.ietf.org; Thu, 10 Apr 2003 14:11:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AIBp800366 for ; Thu, 10 Apr 2003 14:11:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28709 for ; Thu, 10 Apr 2003 14:05:32 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193gAR-0003DL-00 for sipping-web-archive@ietf.org; Thu, 10 Apr 2003 13:48:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 193gAQ-0003DI-00 for sipping-web-archive@ietf.org; Thu, 10 Apr 2003 13:48:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AIB9832737; Thu, 10 Apr 2003 14:11:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AI8v832608 for ; Thu, 10 Apr 2003 14:08:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28585 for ; Thu, 10 Apr 2003 14:02:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193g7d-0003C2-00 for sipping@ietf.org; Thu, 10 Apr 2003 13:46:01 -0400 Received: from dewberry.cc.columbia.edu ([128.59.59.68] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 193g7d-0003Bz-00 for sipping@ietf.org; Thu, 10 Apr 2003 13:46:01 -0400 Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h3AI5AEo008983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 10 Apr 2003 14:05:13 -0400 (EDT) Message-ID: <3E95B260.20700@cs.columbia.edu> Date: Thu, 10 Apr 2003 14:05:20 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "'Shane McCormack'" , "'Sipping@Ietf. Org'" Subject: Re: [Sipping] Geopriv and SIP current state References: <003d01c2ff89$bcf2daf0$ee036e3f@txdwillis> In-Reply-To: <003d01c2ff89$bcf2daf0$ee036e3f@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon and I are (will be...) working on a draft for geopriv on the SIMPLE aspect. As is noted in Jon's current simple-for-geopriv draft, SIMPLE offers many of the mechanisms that are needed to satisfy the geopriv privacy requirements. Dean Willis wrote: > > I think that geolocation information could reasonably be included in > presence documents and correspondingly delivered in presence > notifications as being developed in SIMPLE. It would probably NOT be > appropriat, as a general solution, to include geoloc (as a header or > otherwise) in every message as the overhead of protecting that content > could become enormous. > > Requesting "just geoloc" when subscribing to someone's presence would > perhaps be implemented using the filtering mechanisms currently being > discussed in SIMPLE and SIPPING. > > The actual format of geoloc data has not yet been determined. I > anticipate using the location format deliverable of the GEOPRIV working > group. > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 10 20:19:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12961 for ; Thu, 10 Apr 2003 20:19:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3B0PjN28148 for sipping-archive@odin.ietf.org; Thu, 10 Apr 2003 20:25:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B0Pj828145 for ; Thu, 10 Apr 2003 20:25:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12928 for ; Thu, 10 Apr 2003 20:19:19 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193m09-0005Wh-00 for sipping-web-archive@ietf.org; Thu, 10 Apr 2003 20:02:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 193m09-0005We-00 for sipping-web-archive@ietf.org; Thu, 10 Apr 2003 20:02:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B0KC827944; Thu, 10 Apr 2003 20:20:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B0GQ827826 for ; Thu, 10 Apr 2003 20:16:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12726; Thu, 10 Apr 2003 20:10:00 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193lr8-0005Ta-00; Thu, 10 Apr 2003 19:53:22 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 193lr7-0005TX-00; Thu, 10 Apr 2003 19:53:22 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3B0CYk20739; Thu, 10 Apr 2003 17:12:34 -0700 (PDT) Message-Id: <200304110012.h3B0CYk20739@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, sip@ietf.org, sipping@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 10 Apr 2003 17:12:28 -0700 Subject: [Sipping] RFC 3515 on The Session Initiation Protocol (SIP) Refer Method Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3515 Title: The Session Initiation Protocol (SIP) Refer Method Author(s): R. Sparks Status: Standards Track Date: April 2003 Mailbox: rsparks@dynamicsoft.com Pages: 23 Characters: 47788 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-refer-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3515.txt This document defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the the refer event package and the Refer-To request header. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030410171102.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3515 --OtherAccess Content-Type: Message/External-body; name="rfc3515.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030410171102.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 11 05:43:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05130 for ; Fri, 11 Apr 2003 05:43:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3B9nIn10871 for sipping-archive@odin.ietf.org; Fri, 11 Apr 2003 05:49:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B9nI810868 for ; Fri, 11 Apr 2003 05:49:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05112 for ; Fri, 11 Apr 2003 05:42:42 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193unK-0000XV-00 for sipping-web-archive@ietf.org; Fri, 11 Apr 2003 05:26:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 193unK-0000XS-00 for sipping-web-archive@ietf.org; Fri, 11 Apr 2003 05:26:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B9d2810514; Fri, 11 Apr 2003 05:39:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3B9bI810165 for ; Fri, 11 Apr 2003 05:37:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04927 for ; Fri, 11 Apr 2003 05:30:42 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193ubj-0000Ur-00 for sipping@ietf.org; Fri, 11 Apr 2003 05:14:03 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 193ubi-0000Uo-00 for sipping@ietf.org; Fri, 11 Apr 2003 05:14:02 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3B9XDI3012853; Fri, 11 Apr 2003 11:33:13 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2VALT87Z; Fri, 11 Apr 2003 11:33:14 +0200 Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3B9XEAv009787; Fri, 11 Apr 2003 12:33:14 +0300 (EET DST) Message-ID: <3E968BD7.5080209@lmf.ericsson.se> Date: Fri, 11 Apr 2003 12:33:11 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping CC: Christer Holmberg , Rohan Mahy Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Connection re-use Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, In the connection re-use draft: http://www.ietf.org/internet-drafts/draft-ietf-sipping-connect-reuse-reqs-00.txt when a server gets a request with an alias parameter in the topmost Via entry, it creates a binding between the sent-by in this Via entry and the connection the request came from. sent-by = host [ COLON port ] The sent-by parameter can be, for instance, proxy1.ericsson.com. This FQDN will be the one that proxy1.ericsson.com inserts in the Record-Route. This way, requests sent in the opposite direction *within the same dialog* will re-use the same connection. However, requests that belog to different dialogs will not probably be addressed to proxy1.ericsson.com. They will probably be addressed to ericsson.com instead. Then, if you perform an SRV lookup on ericsson.com you will get: proxy1.ericsson.com proxy2.ericsson.com If the SRV algorithm used to choose a particular server yields proxy2, there would be two connections instead of one. And this was what we were trying to avoid. A possible solution for this would be to make proxies check whether they have a connection for all the resutls of an SRV lookup. If they have an existing connetion, they use that connection (i.e., they do not use the SRV algorithm to choose one). Opinions? Gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 11 07:46:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07741 for ; Fri, 11 Apr 2003 07:46:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BBqiv18819 for sipping-archive@odin.ietf.org; Fri, 11 Apr 2003 07:52:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BBqi818816 for ; Fri, 11 Apr 2003 07:52:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07724 for ; Fri, 11 Apr 2003 07:46:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193wik-00018u-00 for sipping-web-archive@ietf.org; Fri, 11 Apr 2003 07:29:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 193wij-00018r-00 for sipping-web-archive@ietf.org; Fri, 11 Apr 2003 07:29:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BBpl818761; Fri, 11 Apr 2003 07:51:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BBop818671 for ; Fri, 11 Apr 2003 07:50:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07652; Fri, 11 Apr 2003 07:44:11 -0400 (EDT) Message-Id: <200304111144.HAA07652@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 11 Apr 2003 07:44:10 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-qsig2sip-01.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Interworking between SIP and QSIG Author(s) : J. Elwell et al. Filename : draft-ietf-sipping-qsig2sip-01.txt Pages : 54 Date : 2003-4-10 This document specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application- layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying and terminating circuit-switched calls, in particular telephone calls, within Private Integrated Services Networks (PISNs). QSIG is specified in a number of ECMA Standards and published also as ISO/IEC standards. As the support of telephony within corporate networks evolves from circuit-switched technology to Internet technology, the two technologies will co-exist in many networks for a period, perhaps several years. Therefore there is a need to be able to establish, modify and terminate sessions involving a participant in the SIP network and a participant in the QSIG network. Such calls are supported by gateways that perform interworking between SIP and QSIG. This document is a product of the authors' activities in ECMA (www.ecma.ch) on interoperability of QSIG with IP networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-qsig2sip-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sipping-qsig2sip-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-qsig2sip-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-10160035.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-qsig2sip-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-qsig2sip-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-10160035.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 11 11:07:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16665 for ; Fri, 11 Apr 2003 11:07:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3BFDPr01703 for sipping-archive@odin.ietf.org; Fri, 11 Apr 2003 11:13:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BFDP801700 for ; Fri, 11 Apr 2003 11:13:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16657 for ; Fri, 11 Apr 2003 11:06:42 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193zqs-000354-00 for sipping-web-archive@ietf.org; Fri, 11 Apr 2003 10:50:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 193zqs-000351-00 for sipping-web-archive@ietf.org; Fri, 11 Apr 2003 10:50:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BF34800443; Fri, 11 Apr 2003 11:03:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3BF1F800379 for ; Fri, 11 Apr 2003 11:01:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16333 for ; Fri, 11 Apr 2003 10:54:33 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193zf7-00031h-00 for sipping@ietf.org; Fri, 11 Apr 2003 10:37:53 -0400 Received: from web41509.mail.yahoo.com ([66.218.93.92]) by ietf-mx with smtp (Exim 4.12) id 193zf6-00031U-00 for sipping@ietf.org; Fri, 11 Apr 2003 10:37:52 -0400 Message-ID: <20030411145636.49880.qmail@web41509.mail.yahoo.com> Received: from [131.107.3.78] by web41509.mail.yahoo.com via HTTP; Fri, 11 Apr 2003 07:56:36 PDT Date: Fri, 11 Apr 2003 07:56:36 -0700 (PDT) From: Sean Olson Subject: Re: [Sipping] Connection re-use To: Gonzalo Camarillo , sipping Cc: Christer Holmberg , Rohan Mahy In-Reply-To: <3E968BD7.5080209@lmf.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Connection re-use across SRV queries seems to be potentially brittle. Especially if you have a chance to "updgrade" from a lower priority server to a higher priority one. But this seems more a implementation concern than an issue with the re-use draft. --- Gonzalo Camarillo wrote: > Hi, > > In the connection re-use draft: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-connect-reuse-reqs-00.txt > > when a server gets a request with an alias parameter > in the topmost Via > entry, it creates a binding between the sent-by in > this Via entry and > the connection the request came from. > > sent-by = host [ COLON port ] > > The sent-by parameter can be, for instance, > proxy1.ericsson.com. This > FQDN will be the one that proxy1.ericsson.com > inserts in the > Record-Route. This way, requests sent in the > opposite direction *within > the same dialog* will re-use the same connection. > > However, requests that belog to different dialogs > will not probably be > addressed to proxy1.ericsson.com. They will probably > be addressed to > ericsson.com instead. > > Then, if you perform an SRV lookup on ericsson.com > you will get: > proxy1.ericsson.com > proxy2.ericsson.com > > If the SRV algorithm used to choose a particular > server yields proxy2, > there would be two connections instead of one. And > this was what we were > trying to avoid. > > > A possible solution for this would be to make > proxies check whether they > have a connection for all the resutls of an SRV > lookup. If they have an > existing connetion, they use that connection (i.e., > they do not use the > SRV algorithm to choose one). > > Opinions? > > Gonzalo > > _______________________________________________ > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application > of SIP > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sip@ietf.org for new developments of core SIP __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Apr 12 11:16:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29403 for ; Sat, 12 Apr 2003 11:16:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3CFNL204214 for sipping-archive@odin.ietf.org; Sat, 12 Apr 2003 11:23:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CFNL804211 for ; Sat, 12 Apr 2003 11:23:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29400 for ; Sat, 12 Apr 2003 11:16:07 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194MmA-0001Zv-00 for sipping-web-archive@ietf.org; Sat, 12 Apr 2003 11:18:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194MmA-0001Zr-00 for sipping-web-archive@ietf.org; Sat, 12 Apr 2003 11:18:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CFMX804194; Sat, 12 Apr 2003 11:22:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CFKc804161 for ; Sat, 12 Apr 2003 11:20:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29379 for ; Sat, 12 Apr 2003 11:13:24 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194MjY-0001ZV-00 for sipping@ietf.org; Sat, 12 Apr 2003 11:16:00 -0400 Received: from node18-83-151-216.pghconnect.com ([216.151.83.18] helo=01mail.PghMail.com) by ietf-mx with esmtp (Exim 4.12) id 194MjT-0001ZS-00 for sipping@ietf.org; Sat, 12 Apr 2003 11:15:55 -0400 Received: from Ifueys (unverified [63.113.39.168]) by 01mail.PghMail.com (Vircom SMTPRS 5.3.232) with SMTP id for ; Sat, 12 Apr 2003 11:15:56 -0400 Date: Sat, 12 Apr 2003 11:15:56 -0400 Message-ID: From: mwatson To: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=CX49Vi8y7923j1m60E629mq179KEK04 Subject: [Sipping] EDIT THE IMG URLS BELOW FOR DEFAULT AD Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --CX49Vi8y7923j1m60E629mq179KEK04 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) gif is of type executable and is removed. Please contact your network administrator for further information. --------------------------------------------------------- --CX49Vi8y7923j1m60E629mq179KEK04 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --CX49Vi8y7923j1m60E629mq179KEK04 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) gif is removed from here because it is of type executable --------------------------------------------------------- --CX49Vi8y7923j1m60E629mq179KEK04 Content-Type: application/octet-stream; name=pug[1].jpg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAMCAgICAgMCAgIDAwMDBAYEBAQEBAgGBgUGCQgK CgkICQkKDA8MCgsOCwkJDRENDg8QEBEQCgwSExIQEw8QEBD/2wBDAQMDAwQDBAgEBAgQCwkL EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBD/wgAR CAAcABYDASIAAhEBAxEB/8QAGQAAAgMBAAAAAAAAAAAAAAAAAAYBAgcF/8QAFgEBAQEAAAAA AAAAAAAAAAAAAgMF/9oADAMBAAIQAxAAAAF5T7cvB2tYEQhaNQXlxGg3E3//xAAaEAADAQAD AAAAAAAAAAAAAAADBAUCAQYV/9oACAEBAAEFAuymIYIk67L8Ojl9EgheQbsb4d7niicAgzrF tpFRxWPLSVp2Jq5N+OJPiKgBYf8A/8QAGhEAAgMBAQAAAAAAAAAAAAAAAQIAAxESIf/aAAgB AwEBPwF2BOtBaVGNPK9GStBzP//EABwRAAIDAAMBAAAAAAAAAAAAAAECAAMREiEx8P/aAAgB AgEBPwFEIGL8YaQx1fJ3bh2WOeU//8QAKxAAAgIBAgQEBgMAAAAAAAAAAQIDBBEAEgUTIUEi M2FxBhQjJEOhgaLh/9oACAEBAAY/Ao+HUJB81PJtUbse+dWeFOJfs4WaNi/QlvK69M9/TKnS MTiRfC4z31a+II7RS/XtbuYR5eDt2+xVv3qxxNLUay2IViGa5CdMldvr4mPfVBaVgymWu/Mm H5SCp3f2P61dS8z8uCQOKgfCucEbyNNRs10eBxtKdv8ANW+Ho/PSuMRnJ+mpOdn8aS2pkimX pzIm2toLUt3IQR1CTkad03M8hy7u2Sdf/8QAGxABAQADAQEBAAAAAAAAAAAAAREAITFBUWH/ 2gAIAQEAAT8hWaEHQdSNgFVnDCpl1wtpPGUgwMC4HVKDTzKgSB29LTe6Kl/GEbhSBvC7rYQ3 kCWBjAhJr1e1WRWZ4ycz4LbLBJ8VGZT0kkjyTx4myaxfICE+g+p8+73QowYJk9KZFn8LZzmb Npwf9V7n/9oADAMBAAIAAwAAABC3503/xAAbEQEAAwEAAwAAAAAAAAAAAAABABEhMVGBof/a AAgBAwEBPxDW5e5XN+3CBaQVUN9fN+oAYT//xAAcEQACAgIDAAAAAAAAAAAAAAABEQAhMVGB obH/2gAIAQIBAT8QNVlVYOnSxDA9n7CANhYGlzDisz//xAAaEAEBAQEBAQEAAAAAAAAAAAAB EQAhMUFx/9oACAEBAAE/EL/BZgEARoCREFJu+OreexQ7cJNRtM+3xSenpzEC0UlXDbe4N9IX y9WvloBOw1AzvBqgjRImTRZK65N6X7OOahCKBoMmyYZ8SoFAgUIOsyaD39pRVaLUPTl1IgE9 OI9N4PgqSUKcGZkHiJ7XrL93/9=9 --CX49Vi8y7923j1m60E629mq179KEK04-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sat Apr 12 21:31:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09217 for ; Sat, 12 Apr 2003 21:31:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3D1ceW05619 for sipping-archive@odin.ietf.org; Sat, 12 Apr 2003 21:38:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D1ce805616 for ; Sat, 12 Apr 2003 21:38:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09205 for ; Sat, 12 Apr 2003 21:31:15 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194WNR-0003JA-00 for sipping-web-archive@ietf.org; Sat, 12 Apr 2003 21:33:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194WNR-0003J7-00 for sipping-web-archive@ietf.org; Sat, 12 Apr 2003 21:33:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D1bB805169; Sat, 12 Apr 2003 21:37:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D1YW804674 for ; Sat, 12 Apr 2003 21:34:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09152 for ; Sat, 12 Apr 2003 21:27:07 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194WJR-0003IU-00 for sipping@ietf.org; Sat, 12 Apr 2003 21:29:41 -0400 Received: from [206.176.144.210] (helo=kevlar.softarmor.com) by ietf-mx with esmtp (Exim 4.12) id 194WJP-0003I8-00 for sipping@ietf.org; Sat, 12 Apr 2003 21:29:40 -0400 Received: from softarmor.com (kevlar.softarmor.com [127.0.0.1]) by kevlar.softarmor.com (8.12.8/8.12.8) with ESMTP id h3D1T61Q009760 for ; Sat, 12 Apr 2003 20:29:06 -0500 Message-ID: <3E98BD62.2080704@softarmor.com> Date: Sat, 12 Apr 2003 20:29:06 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by kevlar.softarmor.com id h3D1T61Q009760 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3D1YW804675 Subject: [Sipping] Draft Minutes, SIPPING WG, IETF 56 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3D1bB805169 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3D1ce805616 Content-Transfer-Encoding: 8bit draft minuets are posted at: http://www.softarmor.com/sipping/meets/ietf56/notes/minutes.html text follows Draft Minutes, SIPPING Working Group. IETF 56 edited by Dean Willis Session 1, Monday March 1700, 1930-2200 Scribe: Vijay Gurbani, Mary Barnes Chat coordinator: Al with the Hat Chairs called meeting to order. Agenda agreed as: 1930 Agenda Bash 1935 Status -- Chairs Call Control Issues 1945 Service Examples, Alan Johnston draft-ietf-sipping-service-examples-04.txt 1955 Call Control -- Transfer, Allan Johnston draft-ietf-sipping-cc-transfer-01.txt 2005 Caller Preferences Use cases, Jonathan Rosenberg draft-rosenberg-sipping-callerprefs-usecases-00.txt NAT and Policy Issues 2015 Persistent Connection Management Requirements, Vijay K. Gurbani draft-jain-sipping-persistent-conn-reqs-00.txt draft-ietf-sipping-connect-reuse-reqs-00.txt 2035 SIP Network Address Translation, Jonathan Rosenberg draft-ietf-sipping-nat-scenarios-00.txt draft-rosenberg-sipping-ice-00.txt 2045 Session Policy Requiments, Jonathan Rosenberg draft-rosenberg-sipping-session-policy-00.txt 2055 URI Leasing, Jonathan Rosenberg draft-rosenberg-sipping-lease-00.txt Design Teams 2105 SIP Conferencing Design Team, Alan Johnston Web Page for the Design Team 2135 Application Server Interaction Design Team, Jonathan Rosenberg Web Page for the Design Team 2140 Transcoding Design Team, Gonzalo Camarillo Web Page for the Design Team 2145 Emergency Calls Design Team, Jon Peterson Web Page for the Design Team 2150 Limiting Notifications Rate, Aki Niemi draft-niemi-sipping-event-throttle-reqs-01.txt 2200 Wrap Topic: Service Examples, Alan Johnston Moving well. Author wishes to add some text discussing how to implement some servcies and discussing trade-offs and expects that draft will be complete before next meeting Topic: cc-transfer, Alan Johnston Slides presented, included in proceedings. This version had few changes: added a section on use of Referred-By header. Added selected message details. Added many more call flows on attended transfer and unattended transfer. Added a security consideration section. No known open issues with the I-D. Group polled on readiness for WGLC: No objections noted. Audience asked if there was any overlap or dependency on globally-routable contact URI work. Author belives there is currently no dependency, but that if the GRURI work completes, it would be nice to reference it from this draft. Topic: Status report: Chairs Slides presented, included in proceedings. We have 3 RFCs which have been published, considering the amount of work we had on our plate. 2 on IESG queue; bunch of individual I-D. 3 in here that are ready for WGLC. A lot of work is blocked on other stuff -- call control, ICE, work going on in midcom, etc. Note chairs believe that formal expert review is not required for all individual drafts. Current policy is to announce the draft to the list, and ask the participantst to verify that the draft does not conflict with WG efforts. Under the current process, we do a formal expert review for P-headers or when asked to do so by IESG/ADs. It may be useful for us to split things into smaller groups -- some I-Ds document usage of SIP, others talk about services (cc-conferening, cc-transfer). It may be appropriate to let some of this work proceed without supervision of the WG. We may end up doing this in Vienna in order to get up to speed. Will like to get comments on the mailing list or after session on if this is okay. Topic: Caller-Preferences Use Cases, Jonathan Rosenberg Slides presented, included in proceedings. Poll: Useful, interest in accepting as WG document? Strong consensus recorded. AD suggested that these use cases be packaged with CallerPrefs drafts. Topic: ICE, Jonathan Rosenberg Slides presented, included in proceedings. Provides general methodology for using address-fixing protocols to get SIP through NAT. Question: What is the impact if some sort of underlying mobility function causes node address changes? Does ICE resolve? Ans: Unknown, but we think it should work if the frequency of address changes is lower than 1/RTT. Question: Does having STUN server on every node open up the network to denial-of-service attacks on NAT translation? Ans: No -- at least, no more than port-scanning already would. Poll: Who read: fairly large number. Question: Muxing STUN and media -- is that required? What is the implication of demux? Ans: It seems to be feasible to use magic-cookies in the TUN level to work it out. Comment: This DOES require widespread deployment to be useful, can we get that? Ans: If it works, people will implement it. Question: What are implications if only one end supports? Ans: We fall back to what we have now. Question: IS it easier to fix the NAT than to fix the SIP? Ans. Debatable. There's a lot of $39 NAT boxes out there. Poll: How many people would be interested in implementing? (several) Will one volunteer to write the preconditions (document things like like SDP changes, requirements in SIPPING) Yes-- Cullen Jennings. Poll: Would you like this work to be documented in SIPPING, along with fallback to previous modes? Ans: Loud response, a few dissenters. Proposal: Cullen to work on preconditions, Jonathan to work on furthering ICE draft, WG to request authorization to pursue as WG effort. Topic: Session Policy Requirements, Jonathan Rosenberg Slides presented, included in proceedings. Slides presented reviewed scenarios. Poll: Do we want to work on this? Brian Rosen reports that he really needs this for dealing with 6Mb/s streams and managing admissions policy dynamically. Another comment made that this approach could obviate the need for some B2BUAs. Comment that we should add requirements to do this without "new headers" and it shoud work with e2e encryption (req #1 in presentation). Poll: who thinks we should take this work on as a baseline for requirements? Strong consensus reported, none opposed. What happens when a service provider wants to insist on some aspects of a session (media flows through a realy, video not be used, etc.) So far this has been done with SDP modification. Well known problems: does not work with data encryption, requires proxies to have knowledge of session descriptions, proxy complexity increases, ... Solution: 3GPP does this -- they use 488 as a response code to list codecs which are acceptable. This has some drawbacks as well. Do we want to work on this problem? That is the real issue for us to decide now. Many people approached the mic and agreed to the requirements being valid. Gonzalo took a hum level on taking the requirements as base for the work going forward. Hum level indicated interest. Topic: URI Leasing, Jonathan Rosenberg Slides presented, included in proceedings. Material introduced from slides. Question: This allows for temporally scoped URIs. Can we give an example of where this would be useful? Ans. Assume a conference call running over a set time. Discussion that current document may be a bit complex in this area. The word "temporal" is probably misapplied in this context and the author would like to withdraw it. This all comes down to embedded route headers vs. a lease-and-preference model. Perhaps we need to step up a level and ask what the top-level requirements really are? The draft proposes three explicit. There may be also "without hiding state in the domain name" and some others. Comment: Leasing seems to imply temporal scoping. Huh? Long discussion . . . Comment: It seems that all of the given requirements could be met by relaxing a single restriction in 3261. Conclusion: More list discussion on requirements needed. Topic: App Interaction Design Team, Jonathan Rosenberg Slides presented, included in proceedings. Minimal activity since last meeting. We should develop use cases illustrating the requirements. Jonathan Rosenberg requested that proposed use cases be sent to him via email. Topic: Persistent Connections, Vijay Gurbani Slides presented included in proceedings. Basics presented. Discussion ensued. Question: What is the requirement difference between signaled persistence and simply configuring persistence? Assertion: Reuse is only important in the client-server case. Assertion: This sounds like my kids discussing bedtime. There is really only reason to close a TCP connection -- to recover resources. Therefore, the interesting thing, is not how do connections come up, but figuring out which connection to kill if we need to kill one. Assertion: the mechanism here is equivalent to "just doing the right thing" with TCP, so we should fix it operationally, not by changing the protocol. Poll: Should we change the SIP spec to encourage leaving TCP connections open unless they need to be closed? Strong consensus reported. Proposed that we do minimal bug fixes in SIP, and do a separate document with an operational focus on "how to" reuse TCP, initially as a discussion and possibly leading into a BCP. No objections noted. Vijay Gurbani may volunteer to lead on a usage document. Topic: Conferencing Design Team, Alan Johnstson Requirements, Framework, and Call Control ready for WG adoption. Conference Policy is splitting into two and should be ready shortly. Media policies work requirements progressing, work on policy manipulation is ongoing, and the policy work needs a new home. MMUSIC is not going to adopt this in their new charter. Question: This policy work is related to data manipulation in SIMPLE, can we combine it? Ans: Probably not. One is data manipulation, the other is policy RPC. Open issues recapped in slides. Discussion of absolute vs. relative time in focus. Why not have absolute time? Ans. Simplifies timeing coordination on focus. Comment: We do have requirements for realtime transitional controls for things like camera-follows-speaker. SOAP and ACAP don't combine to meet this requirement. Ans: This is for more persistent policy, not floor-control. Floor-control remains a media problem. Poll: Do we wish to, as proposed, adopt the requirements, framework, and call control drafts as wg efforts? Strong consensus, no objections. Question: Is discovery in-scope? It could be a furball. Request: Make focus migration happen sooner rather than later. This will be required for three-way to more-way migrations. This is also important from a fault recovery standpoint. The call-control is easy, just a REFER series, but handling the policy migration is more interesting. Discussion: Policy group needs working group home. Rohan: mmusic will NOT be chartered to do this; so it is either us or a new BOF. Will work it out with the ADs later. We have not been told that we have to stop working on this. Open issues: conference policy protocol, floor control, notifications. Proposed: Adopt Reqs, framework, and call control I-Ds as WG documents. Poll taken, and strong consensus reported. Open reqs: discovery, focus role migration, cascading and camera control. Topic: Hearing impaired media transcoding, Gonzalo Camarillo Work proceeding, no surprises. Author reports little progresssince last IETF and believes that now that we have media policy I-D and session policy reqs, we will make more progress for the next IETF. Topic: Emergency calling design team, Jon Peterson Work proceeding, will try to have face-to-face meeting here. Two cases -- regular 911 calls, and PSAP access-link replacement. Can we divide these two cases so that there is something available for "today's PSTN PSAP"? Topic: Event Throttling Requirements, Aki Niemi Notification rate limiting is the "common factor" among most of the event filtering discussions. Issues: Is the model accurate and appropriate? Do we need both the leaky bucket and the strict throttle? Is it ok to leave handling of quarantined notifications out of scope? Is this work useful? Discussion: It may be important to have a different throttling mechanism for "aggregated/filtered" notifications than for simply prioritized or decimated notifications. The current work does not really consider notification volume/size, just counts. Discussion about the difference between quarantine and gating/throttling functions. One can define a five-token multibucket scenario that's fairly complete. Is this too complicated to be practical? Volutneers to review reqs -- Jonathan, David Oran, and Tomn Taylor volunttered. Poll for adoption: none opposed. Question: Is there standardization required to be able to rate limit? Event Throttle Requirements, Aki Niemi Aki went through the model and the requirements (see slides). Issues: Is the model accurate and appropriate? Do we need both leaky-bucket and the strict throttle models, or is only one of them enough? Observation from floor: Quarantining and throttling are not the same thing. One introduces delay the other control rates. Rohan: Jonathan, Dave Oran and Dean will review the I-D and the WG will receive an update from them before this becomes a WG document. Session 2, Wednesday March 19, 1530-1730: Scribes: Paul Kyzivat, Vijay Gurbani Chat coordinator: Brian Rosen Session called to-order by chairs. Agenda agreed as follows: 1530 Agenda Bash Security Related Issues 1535 Role-based Authorization Requirements, Jon Peterson draft-peterson-sipping-role-authz-00.txt 1545 Request History, Mary Barnes draft-ietf-sipping-req-history-02.txt draft-barnes-sipping-history-info-02.txt Operations 1605 SIP Endpoint Service Charging Requirements, Wolfgang Beck draft-beck-sipping-svc-charging-req-01.txt 1615 SIP User Agent Configuration - Dan Petrie draft-ietf-sipping-config-framework-00.txt 1625 Issues in Dual Stack Environments, Hakan Persson draft-persson-sipping-sip-issues-dual-stack-00.txt 1635 SIP-AAA Requirements, Gonzalo Camarillo draft-ietf-sipping-aaa-req-02.txt Media Related Issues 1645 Early Media, Gonzalo Camarillo draft-camarillo-sipping-early-media-01.txt 1710 Network Announcements, Eric Burger draft-burger-sipping-netann-05.txt 1720 Considerations on the IPREP Requirements, Jon Peterson draft-peterson-sipping-ieprep-00.txt 1730 Wrap Topic: Role-Based Authentication, Jon Peterson Slides introduce concept. Question: Can you show some use cases? Assume two previously unassociated carriers in a federation wish to exchange calls. One carrier issues an authorization object, which the caller hands to the other carrier, allowing the call to proceed. Other examples followed. Discussion from floor: Are we proposing replacing identity with roles? Jon responded that this could encompass identity, but maybe not. suggested from floor that we add more in doc explaining relationship between identity and roles, agreed to by author. Request: Somebody asked for more use cases. Was also concerned whether all stated requirements were self consistent. Observation from floor: Jiri Kuthan suggested that this was a replacement/alternative for network asserted identity. Observation from floor: Somebody suggested that Role wasn’t exactly the right term to use. Topic: Request History Rqmts and Solution, Mary Barnes Slides presented, included in proceedings. Mary Barnes presented current status of both documents. Both requirements and solution have had two new versions since last meeting, now up to -02. Mary explained changes. Of note - separating out security requirements, to separate document. Remaining open issue is security, which is work-in-progress, which a seperate security solution draft expected soon. Consensus that requirements document is roughly complete and should be referred to SIP WG for action. Chairs need to refer to AD for approval. Topic: SIP Endpoint Service Charging Requirements, Wolfgang Beck Slides presented included in proceedings. Introduces requirements and a model for third-party trust assignment with SIP. Possibly combinable with role-based-authorization. Proposal: this should be two drafts, one around charging and another about advice-of-charge. Comment: this seems to be limited to a fixedSIP architecture as currently written. Comment: the evaluation of the requirements presented in the draft would be greatly aided by the inclusion of use cases. Comment: reading the document indicates a specific business model in-mind. Work here should be network agnostic and not make assumptions about who is paying (like caller always pays) etc. Question from chairs: Are we interested in trying to gather requirements to support an endpoint based charging model (i.e., not billing from intermediaries). Consensus that we would like to see the work more completely illustrated, including use cases, before considering its utility. Topic: Config Framework, Dan Petrie Slides presented included in proceedings. Open Question: Should HTTPS be a SHOULD or MUST strength reequirement: Ans. MUST implement, SHOULD use. Open Question: Is HTTPish preferred to LDAP or ACAP? Open Question: Is this related to NETCONF work? Discussion: There are issues here that cannot be fixed with HTTPS pixie dust. You need a separate mechanism of top of HTTPS to verify the identity of the node requesting configuration. Of course, this needs to be configured in. So there is a bootstrapping problem. Open question: device identity parameters: User-agent header? New header? No decision made. Open question: How to indicate profile type? Accept-header or event header parameter or request-URI? Comment: this is the same problem as SIMPLE's buddy list management and should use the same mechanism. Further discussion taken to the list. Dan Petrie presented. Identified changes from prior version. (draft-petrie-sipping-config-framework-00) There were comments about strength of use for HTTPS for content indirection in here. General sentiment seemed to be that HTTPS should be MUST implement, SHOULD use. Other protocols other than http/https are also possible. Henning Schulzrinne said https isn’t enough. Said there were both confidentiality issues as well as way to ensure the client gets the right data. In absence of client cert, which you can’t assume during config, presents difficult problems – how to bootstrap. Dan acknowledged this problem, and said he has already proposed to do work to deal with that. Further discussion went on. Rohan asked that this go to list. Dan requested input on list for where device identification should go – in User-Agent header or somewhere else. Discussion of profile type – where to indicate in subscription. Jonathan Rosenberg thought you could subscribe to a different request uri for each kind of thing. Rohan Mahy disagreed. Was sent to the list for discussion. Jonathan suggested this is similar to SIMPLE problem regarding buddylists, and the two works should be synchronized. Topic: Dual-Stack Issues, Hakan Persson Slides introduce problem and recaps several solutions. The "contact" problem seems to be addressable in part by dual-interfaced record-route and in part by ICE. The document will be revisited by the author exlporing usage of these techniques and, if the solution is satisfactory, can become a usage document illustrating the solution to the problems it has already raised. Topic: AAA Req, Gonzalo Camarillo Slides presented included in proceedings. Currently in WGLC. Poll: Any issues that have been missed? No new issues. Attendees encouraged to follw WGLC. Topic: Early Media, Gonzalo Camarillo Slides presented included in proceedings. Open issues: There appear to be three ringback states from ISUP, and only two codes (180, 183) available in SIP. Not all protagonists are present and the author proposes to hold a conference call for resolution. Debate ensued anyhow, trying to capture essence of the issue. Francois, Flemming, Rohan, others agreed to send use cases illustrating the issues they need solved. Poll: should we add a flag? No clear consensus Topic: Network Announcements, Eric Burger Slides presented included in proceedings. Open Issue: Media on Hold? What does a media server do when it gets put on hold? This seems to be application specific, not a SIP protocol problem. Open Issue: 409 Result code proposal? Suggestion from audience Can we TRY not to use things that are used in HTTP to mean something different? Sugggestion: Could we use a standard response code and a Reason field? Conversation deferred to list with emphasis on 6xx vs 4xx debate. Open Issue: Multiple Media Streams:? What do do then, to play multiple things? Eric asserted this isn’t an issue if the target uri is a composite object. He wanted to know if that is the predominant use case. And if not, how would the multiple streams be synced? Brian Rosen wondered why it isn’t good enough to pick one stream. Confusion reigns, deferred to list. Open issue: IS everything in this draft consistent with WG usage? We need to be sure we're aligned with conferencing and early media work? Author asked to work with Alan Johnston on conferencing alignment, and Gonzalo Camarillo on early media. Topic: IEPREP Considerations, Jon Peterson SIPPING asked to provide formal response to the IEPREP considerations, widely discussed on mailing list. Open Issue: SHOULD we address this here? As there is already work in SIP on the priority header? Should we do it here? Discussion: Jon Peterson presented. Said this work was in response to requests by area directors for comments on RFC3478. This is Jon’s private attempt at comments, based on some discussion on list. Jon raised privacy issues. Henning said there are fundamental tradeoffs between privacy and proxies, and that therefore it is necessary to offer endpoint with options for either. Keith Drage asserted that either there is an error in the IEPREP requirements that ought to be fixed there, or else it should be dealt with by SIP in responding to the requirements, so there is no need for SIPPING draft in this instance. Allison Mankin agreed, said the area directors could deal with this aspect now, and don’t need any more input. Rohan observed that SIP already adopted a mechanism that relates to this. : Meeting concluded. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sun Apr 13 04:54:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26058 for ; Sun, 13 Apr 2003 04:54:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3D91GT11285 for sipping-archive@odin.ietf.org; Sun, 13 Apr 2003 05:01:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D91G811282 for ; Sun, 13 Apr 2003 05:01:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26048 for ; Sun, 13 Apr 2003 04:53:41 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194dHb-0004kf-00 for sipping-web-archive@ietf.org; Sun, 13 Apr 2003 04:56:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194dHb-0004kc-00 for sipping-web-archive@ietf.org; Sun, 13 Apr 2003 04:56:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D901811223; Sun, 13 Apr 2003 05:00:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3D8wS811165 for ; Sun, 13 Apr 2003 04:58:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26021 for ; Sun, 13 Apr 2003 04:50:53 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194dEt-0004kA-00 for sipping@ietf.org; Sun, 13 Apr 2003 04:53:27 -0400 Received: from [194.185.97.41] (helo=gsp01-c07d1.vodafone.it) by ietf-mx with esmtp (Exim 4.12) id 194dEt-0004k2-00 for sipping@ietf.org; Sun, 13 Apr 2003 04:53:27 -0400 Received: from loretosapc (127.0.0.1) by gsp01-c07d1.vodafone.it (NPlex 5.1.046) id 3E6FBCC800004D50; Sun, 13 Apr 2003 10:52:58 +0200 X-CNS-Auth: Message-ID: <000301c3019a$91d0d6c0$74690b3e@loretosapc> From: "sal" To: "Gonzalo Camarillo" , "sipping" Cc: "Christer Holmberg" , "Rohan Mahy" , References: <3E968BD7.5080209@lmf.ericsson.se> Subject: Re: [Sipping] Connection re-use Date: Sun, 13 Apr 2003 10:56:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I'm note sure, but some SRV algorithm tries making a load balancing between the different "proxies" in the cluster. If we do not use the SRV algorithm, but we use always the same proxy (that one has an existing connection) ... maybe we risk to stress this one, while the other proxies are unloaded ! In this way we'll shift the stress in the application level , isn'it ? so I am not agree with Sean when he says "Connection re-use across SRV queries seems to be potentially brittle." Sal ----- Original Message ----- From: "Gonzalo Camarillo" To: "sipping" Cc: "Christer Holmberg" ; "Rohan Mahy" Sent: Friday, April 11, 2003 11:33 AM Subject: [Sipping] Connection re-use > Hi, > > In the connection re-use draft: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-connect-reuse-reqs-00 .txt > > when a server gets a request with an alias parameter in the topmost Via > entry, it creates a binding between the sent-by in this Via entry and > the connection the request came from. > > sent-by = host [ COLON port ] > > The sent-by parameter can be, for instance, proxy1.ericsson.com. This > FQDN will be the one that proxy1.ericsson.com inserts in the > Record-Route. This way, requests sent in the opposite direction *within > the same dialog* will re-use the same connection. > > However, requests that belog to different dialogs will not probably be > addressed to proxy1.ericsson.com. They will probably be addressed to > ericsson.com instead. > > Then, if you perform an SRV lookup on ericsson.com you will get: > proxy1.ericsson.com > proxy2.ericsson.com > > If the SRV algorithm used to choose a particular server yields proxy2, > there would be two connections instead of one. And this was what we were > trying to avoid. > > > A possible solution for this would be to make proxies check whether they > have a connection for all the resutls of an SRV lookup. If they have an > existing connetion, they use that connection (i.e., they do not use the > SRV algorithm to choose one). > > Opinions? > Gonzalo > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sun Apr 13 13:45:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02585 for ; Sun, 13 Apr 2003 13:45:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3DHr7q05454 for sipping-archive@odin.ietf.org; Sun, 13 Apr 2003 13:53:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DHr7805451 for ; Sun, 13 Apr 2003 13:53:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02582 for ; Sun, 13 Apr 2003 13:45:23 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194la7-0005qm-00 for sipping-web-archive@ietf.org; Sun, 13 Apr 2003 13:47:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194la7-0005qi-00 for sipping-web-archive@ietf.org; Sun, 13 Apr 2003 13:47:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DHq6805401; Sun, 13 Apr 2003 13:52:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DHkk805247 for ; Sun, 13 Apr 2003 13:46:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02519 for ; Sun, 13 Apr 2003 13:39:02 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194lTz-0005q3-00 for sipping@ietf.org; Sun, 13 Apr 2003 13:41:35 -0400 Received: from smtp015.mail.yahoo.com ([216.136.173.59]) by ietf-mx with smtp (Exim 4.12) id 194lTy-0005q0-00 for sipping@ietf.org; Sun, 13 Apr 2003 13:41:34 -0400 Received: from 12-235-146-159.client.attbi.com (HELO cranberry) (seancolson@12.235.146.159 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Apr 2003 17:41:37 -0000 Reply-To: From: "Sean Olson" To: "'sal'" , "'Gonzalo Camarillo'" , "'sipping'" Cc: "'Christer Holmberg'" , "'Rohan Mahy'" Subject: RE: [Sipping] Connection re-use Date: Sun, 13 Apr 2003 10:41:40 -0700 Message-ID: <000501c301e3$f14f5ce0$6501a8c0@cranberry> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <000301c3019a$91d0d6c0$74690b3e@loretosapc> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3DHkl805248 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Actually, this was exactly the point I was trying to make. We SHOULD change proxies based on the SRV algorithm and re-use the connection when you connect to the same proxy. But again, I think this is an implementation specific thing. There may be good reasons in some topologies and with some implementations not to change the proxy that you connect to. -----Original Message----- From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of sal Sent: Sunday, April 13, 2003 1:56 AM To: Gonzalo Camarillo; sipping Cc: Christer Holmberg; Rohan Mahy; seancolson@yahoo.com Subject: Re: [Sipping] Connection re-use Hi all, I'm note sure, but some SRV algorithm tries making a load balancing between the different "proxies" in the cluster. If we do not use the SRV algorithm, but we use always the same proxy (that one has an existing connection) ... maybe we risk to stress this one, while the other proxies are unloaded ! In this way we'll shift the stress in the application level , isn'it ? so I am not agree with Sean when he says "Connection re-use across SRV queries seems to be potentially brittle." Sal ----- Original Message ----- From: "Gonzalo Camarillo" To: "sipping" Cc: "Christer Holmberg" ; "Rohan Mahy" Sent: Friday, April 11, 2003 11:33 AM Subject: [Sipping] Connection re-use > Hi, > > In the connection re-use draft: > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-connect-reuse-reqs-00 .txt > > when a server gets a request with an alias parameter in the topmost > Via entry, it creates a binding between the sent-by in this Via entry > and the connection the request came from. > > sent-by = host [ COLON port ] > > The sent-by parameter can be, for instance, proxy1.ericsson.com. This > FQDN will be the one that proxy1.ericsson.com inserts in the > Record-Route. This way, requests sent in the opposite direction > *within the same dialog* will re-use the same connection. > > However, requests that belog to different dialogs will not probably be > addressed to proxy1.ericsson.com. They will probably be addressed to > ericsson.com instead. > > Then, if you perform an SRV lookup on ericsson.com you will get: > proxy1.ericsson.com proxy2.ericsson.com > > If the SRV algorithm used to choose a particular server yields proxy2, > there would be two connections instead of one. And this was what we > were trying to avoid. > > > A possible solution for this would be to make proxies check whether > they have a connection for all the resutls of an SRV lookup. If they > have an existing connetion, they use that connection (i.e., they do > not use the SRV algorithm to choose one). > > Opinions? > Gonzalo > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 14 02:15:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24806 for ; Mon, 14 Apr 2003 02:15:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3E6NTK24597 for sipping-archive@odin.ietf.org; Mon, 14 Apr 2003 02:23:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6NS824594 for ; Mon, 14 Apr 2003 02:23:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24759 for ; Mon, 14 Apr 2003 02:15:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194xI0-0007dt-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 02:18:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194xI0-0007dq-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 02:18:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6MY824566; Mon, 14 Apr 2003 02:22:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6LN824526 for ; Mon, 14 Apr 2003 02:21:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24568 for ; Mon, 14 Apr 2003 02:13:23 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194xFz-0007dI-00 for sipping@ietf.org; Mon, 14 Apr 2003 02:15:55 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 194xFy-0007dF-00 for sipping@ietf.org; Mon, 14 Apr 2003 02:15:55 -0400 Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.12.9/8.12.9) with ESMTP id h3E6EYtP015650; Mon, 14 Apr 2003 01:14:59 -0500 (CDT) Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by mr6.exu.ericsson.se (8.12.9/8.12.9) with ESMTP id h3E6EXsS015664; Mon, 14 Apr 2003 01:14:34 -0500 (CDT) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.19]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id CV71NKKP; Mon, 14 Apr 2003 01:14:34 -0500 Message-ID: <3E9A51C8.9030406@lmf.ericsson.se> Date: Mon, 14 Apr 2003 09:14:32 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seancolson@yahoo.com CC: "'sal'" , "'sipping'" , "'Christer Holmberg'" , "'Rohan Mahy'" Subject: Re: [Sipping] Connection re-use References: <000501c301e3$f14f5ce0$6501a8c0@cranberry> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My point is that this is something that we have to discuss and *document * in the draft. I can see advantages in both approaches: 1) sending everything to the same proxy in the cluster, 2) having N connections open at the same time to all the proxies in the cluster. It depends on the type of load balancing you want to perform: transaction based or (proxy-to-proxy) relationship based. Gonzalo Sean Olson wrote: > Actually, this was exactly the point I was trying to make. We SHOULD change > proxies based on the SRV algorithm > and re-use the connection when you connect to the same proxy. But again, I > think this is an implementation specific > thing. There may be good reasons in some topologies and with some > implementations not to change the proxy that you > connect to. > > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] On Behalf Of > sal > Sent: Sunday, April 13, 2003 1:56 AM > To: Gonzalo Camarillo; sipping > Cc: Christer Holmberg; Rohan Mahy; seancolson@yahoo.com > Subject: Re: [Sipping] Connection re-use > > > Hi all, > > > I'm note sure, but some SRV algorithm tries making a load balancing between > the different "proxies" in the cluster. > > If we do not use the SRV algorithm, but we use always the same proxy (that > one has an existing connection) ... maybe we risk to stress this one, while > the other proxies are unloaded ! > > In this way we'll shift the stress in the application level , isn'it ? > > so I am not agree with Sean when he says > "Connection re-use across SRV queries seems to be > potentially brittle." > > Sal > > ----- Original Message ----- > From: "Gonzalo Camarillo" > To: "sipping" > Cc: "Christer Holmberg" ; "Rohan Mahy" > > Sent: Friday, April 11, 2003 11:33 AM > Subject: [Sipping] Connection re-use > > > >>Hi, >> >>In the connection re-use draft: >> >> > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-connect-reuse-reqs-00 > .txt > >>when a server gets a request with an alias parameter in the topmost >>Via entry, it creates a binding between the sent-by in this Via entry >>and the connection the request came from. >> >>sent-by = host [ COLON port ] >> >>The sent-by parameter can be, for instance, proxy1.ericsson.com. This >>FQDN will be the one that proxy1.ericsson.com inserts in the >>Record-Route. This way, requests sent in the opposite direction >>*within the same dialog* will re-use the same connection. >> >>However, requests that belog to different dialogs will not probably be >>addressed to proxy1.ericsson.com. They will probably be addressed to >>ericsson.com instead. >> >>Then, if you perform an SRV lookup on ericsson.com you will get: >>proxy1.ericsson.com proxy2.ericsson.com >> >>If the SRV algorithm used to choose a particular server yields proxy2, >>there would be two connections instead of one. And this was what we >>were trying to avoid. >> >> >>A possible solution for this would be to make proxies check whether >>they have a connection for all the resutls of an SRV lookup. If they >>have an existing connetion, they use that connection (i.e., they do >>not use the SRV algorithm to choose one). >> >>Opinions? > > > > >>Gonzalo >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP Use >>sip-implementors@cs.columbia.edu for questions on current sip Use >>sip@ietf.org for new developments of core SIP > > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip Use > sip@ietf.org for new developments of core SIP -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 14 02:42:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25722 for ; Mon, 14 Apr 2003 02:42:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3E6nv226775 for sipping-archive@odin.ietf.org; Mon, 14 Apr 2003 02:49:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6nv826772 for ; Mon, 14 Apr 2003 02:49:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25718 for ; Mon, 14 Apr 2003 02:41:56 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194xhc-0000D4-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 02:44:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194xhc-0000D1-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 02:44:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6n9826756; Mon, 14 Apr 2003 02:49:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6mr826736 for ; Mon, 14 Apr 2003 02:48:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25705 for ; Mon, 14 Apr 2003 02:40:53 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194xgb-0000Cw-00 for sipping@ietf.org; Mon, 14 Apr 2003 02:43:25 -0400 Received: from [61.144.161.2] (helo=mta2) by ietf-mx with esmtp (Exim 4.12) id 194xgY-0000Cm-00 for sipping@ietf.org; Mon, 14 Apr 2003 02:43:25 -0400 Received: from mta2 (localhost [127.0.0.1]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HDB0029HMOL71@mta2.huawei.com> for sipping@ietf.org; Mon, 14 Apr 2003 14:43:34 +0800 (CST) Received: from mailin.huawei.com ([10.18.1.252]) by mta2.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.7 (built Jun 26 2002)) with ESMTP id <0HDB00HOUMOK6F@mta2.huawei.com> for sipping@ietf.org; Mon, 14 Apr 2003 14:43:33 +0800 (CST) Received: from nkannanCL1068 ([10.18.2.104]) by mailin.huawei.com (Netscape Messaging Server 4.15) with ESMTP id HDBMRM00.N0A; Mon, 14 Apr 2003 14:45:22 +0800 Date: Mon, 14 Apr 2003 12:17:00 +0530 From: Natesan Kannan Subject: Re: [Sipping] Connection re-use To: Gonzalo Camarillo , seancolson@yahoo.com Cc: "'sal'" , "'sipping'" , "'Christer Holmberg'" , "'Rohan Mahy'" Message-id: <003401c30251$a6694830$6802120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <000501c301e3$f14f5ce0$6501a8c0@cranberry> <3E9A51C8.9030406@lmf.ericsson.se> Content-Transfer-Encoding: 7BIT Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Considering orthogonal servers in a cluster, the load balance could be based purely on "load", which could be administered in the DNS by having an SRV query yeild proxy.ericsson.com, but record routing being done by proxy1 or proxy2. In this case, any policy to reuse connection may go against the load balance policy in the domain. So, I agree with Sean that this is implementation specific, and hence difficult to document in the draft, as clearly as in the within-the-same-dialog case. -Kannan ----- Original Message ----- From: "Gonzalo Camarillo" To: Cc: "'sal'" ; "'sipping'" ; "'Christer Holmberg'" ; "'Rohan Mahy'" Sent: Monday, April 14, 2003 11:44 AM Subject: Re: [Sipping] Connection re-use > My point is that this is something that we have to discuss and *document > * in the draft. I can see advantages in both approaches: > > 1) sending everything to the same proxy in the cluster, > 2) having N connections open at the same time to all the proxies in the > cluster. > > It depends on the type of load balancing you want to perform: > transaction based or (proxy-to-proxy) relationship based. > > Gonzalo > > Sean Olson wrote: > > Actually, this was exactly the point I was trying to make. We SHOULD change > > proxies based on the SRV algorithm > > and re-use the connection when you connect to the same proxy. But again, I > > think this is an implementation specific > > thing. There may be good reasons in some topologies and with some > > implementations not to change the proxy that you > > connect to. > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 14 03:03:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26002 for ; Mon, 14 Apr 2003 03:03:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3E7BDK28337 for sipping-archive@odin.ietf.org; Mon, 14 Apr 2003 03:11:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7BC828334 for ; Mon, 14 Apr 2003 03:11:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25993 for ; Mon, 14 Apr 2003 03:03:11 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194y2C-0000Fs-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 03:05:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194y2B-0000Fp-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 03:05:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7AG828273; Mon, 14 Apr 2003 03:10:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E79L828240 for ; Mon, 14 Apr 2003 03:09:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25967 for ; Mon, 14 Apr 2003 03:01:20 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194y0P-0000FM-00 for sipping@ietf.org; Mon, 14 Apr 2003 03:03:53 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 194y0O-0000FJ-00 for sipping@ietf.org; Mon, 14 Apr 2003 03:03:52 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3E73hRs012230; Mon, 14 Apr 2003 09:03:44 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2VDNZKH3; Mon, 14 Apr 2003 09:03:45 +0200 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.31.77]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3E73fR6003459; Mon, 14 Apr 2003 10:03:41 +0300 (EET DST) Message-ID: <3E9A5D4D.FED87D26@lmf.ericsson.se> Date: Mon, 14 Apr 2003 10:03:41 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Natesan Kannan CC: Gonzalo Camarillo , seancolson@yahoo.com, "'sal'" , "'sipping'" , "'Rohan Mahy'" Subject: Re: [Sipping] Connection re-use References: <000501c301e3$f14f5ce0$6501a8c0@cranberry> <3E9A51C8.9030406@lmf.ericsson.se> <003401c30251$a6694830$6802120a@in.huawei.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Assume I have a connection to proxy1.ericsson.com and port X. Then, a SRV lookup returns proxy1.ericsson.com and port Y (same proxy, different port). I guess it in this case also is an implementation issue if I want to establish a new connection to the new port, or if I use the existing connection to the old port? In any case, I agree with Gonzalo on the fact that it would be good to document these cases. No matter if it's an implementation issue from the UAC point of view, it has to be specificed what the UAS is supposed to be able to handle. Regards, Christer Holmberg Ericsson Finland Natesan Kannan wrote: > Considering orthogonal servers in a cluster, the load balance could be based > purely on "load", which could be administered in the DNS by having an SRV > query yeild proxy.ericsson.com, but record routing being done by proxy1 or > proxy2. > > In this case, any policy to reuse connection may go against the load > balance policy in the domain. > > So, I agree with Sean that this is implementation specific, and hence > difficult to document in the draft, as clearly as in the > within-the-same-dialog case. > > -Kannan > ----- Original Message ----- > From: "Gonzalo Camarillo" > To: > Cc: "'sal'" ; "'sipping'" ; > "'Christer Holmberg'" ; "'Rohan Mahy'" > > Sent: Monday, April 14, 2003 11:44 AM > Subject: Re: [Sipping] Connection re-use > > > My point is that this is something that we have to discuss and *document > > * in the draft. I can see advantages in both approaches: > > > > 1) sending everything to the same proxy in the cluster, > > 2) having N connections open at the same time to all the proxies in the > > cluster. > > > > It depends on the type of load balancing you want to perform: > > transaction based or (proxy-to-proxy) relationship based. > > > > Gonzalo > > > > Sean Olson wrote: > > > Actually, this was exactly the point I was trying to make. We SHOULD > change > > > proxies based on the SRV algorithm > > > and re-use the connection when you connect to the same proxy. But again, > I > > > think this is an implementation specific > > > thing. There may be good reasons in some topologies and with some > > > implementations not to change the proxy that you > > > connect to. > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 14 06:05:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29607 for ; Mon, 14 Apr 2003 06:05:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3EACok08406 for sipping-archive@odin.ietf.org; Mon, 14 Apr 2003 06:12:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EACo808403 for ; Mon, 14 Apr 2003 06:12:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29604 for ; Mon, 14 Apr 2003 06:04:44 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1950rt-00016N-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 06:07:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1950rt-00016K-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 06:07:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EABT808317; Mon, 14 Apr 2003 06:11:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EA9U808220 for ; Mon, 14 Apr 2003 06:09:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29534 for ; Mon, 14 Apr 2003 06:01:24 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1950of-00015P-00 for sipping@ietf.org; Mon, 14 Apr 2003 06:03:57 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1950of-00015B-00 for sipping@ietf.org; Mon, 14 Apr 2003 06:03:57 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3EA3UR19643 for ; Mon, 14 Apr 2003 06:03:30 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Apr 2003 11:03:26 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00439ECB7@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Dean Willis'" Cc: "'sipping@ietf.org'" Subject: RE: [Sipping] Draft Minutes, SIPPING WG, IETF 56 Date: Mon, 14 Apr 2003 11:03:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1252" X-MIME-Autoconverted: from 8bit to quoted-printable by auemail1.firewall.lucent.com id h3EA3UR19643 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3EA9U808221 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3EABT808317 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3EACo808403 Content-Transfer-Encoding: 8bit Text of minutes: "Do we want to work on this problem? That is the real issue for us to decide now. Many people approached the mic and agreed to the requirements being valid. Gonzalo took a hum level on taking the requirements as base for the work going forward. Hum level indicated interest." Firstly, I thought the hum was on having a requirements document in this area being worked as a working group draft, rather than on the current contents. While I do not have any major issues with the contents, I prefer to get this correct. Secondly, one of the comments I made at the mic related to the relationship to the solutions document in http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-00.txt to the effect that the requirements document should be advanced, and when we have the requirements document agreed, we will then see if this solutions draft is the correct solution, or whether others exist. I think that it is important to capture something to this effect. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 13 April 2003 02:29 > To: sipping@ietf.org > Subject: [Sipping] Draft Minutes, SIPPING WG, IETF 56 > > > draft minuets are posted at: > http://www.softarmor.com/sipping/meets/ietf56/notes/minutes.html > > text follows > > Draft Minutes, SIPPING Working Group. IETF 56 > edited by Dean Willis > > Session 1, Monday March 1700, 1930-2200 > > Scribe: Vijay Gurbani, Mary Barnes > Chat coordinator: Al with the Hat > > > Chairs called meeting to order. > Agenda agreed as: > > 1930 Agenda Bash > 1935 Status -- Chairs > Call Control Issues > 1945 Service Examples, Alan Johnston > draft-ietf-sipping-service-examples-04.txt > 1955 Call Control -- Transfer, Allan Johnston > draft-ietf-sipping-cc-transfer-01.txt > 2005 Caller Preferences Use cases, Jonathan Rosenberg > draft-rosenberg-sipping-callerprefs-usecases-00.txt > NAT and Policy Issues > 2015 Persistent Connection Management Requirements, Vijay K. Gurbani > draft-jain-sipping-persistent-conn-reqs-00.txt > draft-ietf-sipping-connect-reuse-reqs-00.txt > 2035 SIP Network Address Translation, Jonathan Rosenberg > draft-ietf-sipping-nat-scenarios-00.txt > draft-rosenberg-sipping-ice-00.txt > 2045 Session Policy Requiments, Jonathan Rosenberg > draft-rosenberg-sipping-session-policy-00.txt > 2055 URI Leasing, Jonathan Rosenberg > draft-rosenberg-sipping-lease-00.txt > Design Teams > 2105 SIP Conferencing Design Team, Alan Johnston > Web Page for the Design Team > 2135 Application Server Interaction Design Team, Jonathan Rosenberg > Web Page for the Design Team > 2140 Transcoding Design Team, Gonzalo Camarillo > Web Page for the Design Team > 2145 Emergency Calls Design Team, Jon Peterson > Web Page for the Design Team > 2150 Limiting Notifications Rate, Aki Niemi > draft-niemi-sipping-event-throttle-reqs-01.txt > 2200 Wrap > > > Topic: Service Examples, Alan Johnston > > Moving well. Author wishes to add some text discussing how to > implement > some servcies and discussing trade-offs and expects that > draft will be > complete before next meeting > > Topic: cc-transfer, Alan Johnston > > Slides presented, included in proceedings. > > This version had few changes: added a section on use of Referred-By > header. Added selected message details. Added many more > call flows on > attended transfer and unattended transfer. Added a security > consideration section. No known open issues with the I-D. > Group polled > on readiness for WGLC: No objections noted. Audience asked > if there was > any overlap or dependency on globally-routable contact URI > work. Author > belives there is currently no dependency, but that if the GRURI work > completes, it would be nice to reference it from this draft. > > > Topic: Status report: Chairs > > Slides presented, included in proceedings. > > We have 3 RFCs which have been published, considering the > amount of work > we had on our plate. 2 on IESG queue; bunch of individual I-D. 3 in > here that are ready for WGLC. A lot of work is blocked on > other stuff > -- call control, ICE, work going on in midcom, etc. > > Note chairs believe that formal expert review is not required for all > individual drafts. Current policy is to announce the draft to > the list, > and ask the participantst to verify that the draft does not conflict > with WG efforts. Under the current process, we do a formal > expert review > for P-headers or when asked to do so by IESG/ADs. > > It may be useful for us to split things into smaller groups > -- some I-Ds > document usage of SIP, others talk about services (cc-conferening, > cc-transfer). It may be appropriate to let some of this work proceed > without supervision of the WG. We may end up doing this in Vienna in > order to get up to speed. Will like to get comments on the > mailing list > or after session on if this is okay. > > > > Topic: Caller-Preferences Use Cases, Jonathan Rosenberg > > Slides presented, included in proceedings. > > > Poll: Useful, interest in accepting as WG document? Strong consensus > recorded. AD suggested that these use cases be packaged with > CallerPrefs > drafts. > > > > Topic: ICE, Jonathan Rosenberg > > Slides presented, included in proceedings. > > Provides general methodology for using address-fixing > protocols to get > SIP through NAT. > > Question: What is the impact if some sort of underlying mobility > function causes node address changes? Does ICE resolve? Ans: Unknown, > but we think it should work if the frequency of address > changes is lower > than 1/RTT. > > Question: Does having STUN server on every node open up the > network to > denial-of-service attacks on NAT translation? Ans: No -- at least, no > more than port-scanning already would. > > Poll: Who read: fairly large number. > > Question: Muxing STUN and media -- is that required? What is the > implication of demux? Ans: It seems to be feasible to use > magic-cookies > in the TUN level to work it out. > > Comment: This DOES require widespread deployment to be useful, can we > get that? Ans: If it works, people will implement it. > > Question: What are implications if only one end supports? > Ans: We fall > back to what we have now. Question: IS it easier to fix the > NAT than to > fix the SIP? Ans. Debatable. There's a lot of $39 NAT boxes > out there. > > Poll: How many people would be interested in implementing? (several) > Will one volunteer to write the preconditions (document > things like like > SDP changes, requirements in SIPPING) Yes-- Cullen Jennings. > > Poll: Would you like this work to be documented in SIPPING, > along with > fallback to previous modes? Ans: Loud response, a few dissenters. > Proposal: Cullen to work on preconditions, Jonathan to work on > furthering ICE draft, WG to request authorization to pursue > as WG effort. > > > > Topic: Session Policy Requirements, Jonathan Rosenberg > > Slides presented, included in proceedings. > > Slides presented reviewed scenarios. Poll: Do we want to work > on this? > Brian Rosen reports that he really needs this for dealing with 6Mb/s > streams and managing admissions policy dynamically. Another > comment made > that this approach could obviate the need for some B2BUAs. > Comment that > we should add requirements to do this without "new headers" > and it shoud > work with e2e encryption (req #1 in presentation). Poll: who > thinks we > should take this work on as a baseline for requirements? Strong > consensus reported, none opposed. > > What happens when a service provider wants to insist on some > aspects of > a session (media flows through a realy, video not be used, > etc.) So far > this has been done with SDP modification. Well known > problems: does not > work with data encryption, requires proxies to have knowledge > of session > descriptions, proxy complexity increases, ... > > Solution: 3GPP does this -- they use 488 as a response code to list > codecs which are acceptable. This has some drawbacks as well. > > Do we want to work on this problem? That is the real issue for us to > decide now. > > Many people approached the mic and agreed to the requirements > being valid. > > Gonzalo took a hum level on taking the requirements as base > for the work > going forward. Hum level indicated interest. > > > > > Topic: URI Leasing, Jonathan Rosenberg > > Slides presented, included in proceedings. > > Material introduced from slides. > > Question: This allows for temporally scoped URIs. Can we give > an example > of where this would be useful? Ans. Assume a conference call running > over a set time. Discussion that current document may be a > bit complex > in this area. The word "temporal" is probably misapplied in > this context > and the author would like to withdraw it. This all comes down to > embedded route headers vs. a lease-and-preference model. > Perhaps we need > to step up a level and ask what the top-level requirements > really are? > The draft proposes three explicit. There may be also "without hiding > state in the domain name" and some others. > > Comment: Leasing seems to imply temporal scoping. Huh? Long > discussion . . . > > Comment: It seems that all of the given requirements could be met by > relaxing a single restriction in 3261. > > Conclusion: More list discussion on requirements needed. > > > > Topic: App Interaction Design Team, Jonathan Rosenberg > > Slides presented, included in proceedings. > > Minimal activity since last meeting. We should develop use cases > illustrating the requirements. Jonathan Rosenberg requested that > proposed use cases be sent to him via email. > > > > Topic: Persistent Connections, Vijay Gurbani > > Slides presented included in proceedings. > > Basics presented. Discussion ensued. > > Question: What is the requirement difference between signaled > persistence and simply configuring persistence? > > Assertion: Reuse is only important in the client-server case. > > Assertion: This sounds like my kids discussing bedtime. There > is really > only reason to close a TCP connection -- to recover resources. > Therefore, the interesting thing, is not how do connections > come up, but > figuring out which connection to kill if we need to kill one. > > Assertion: the mechanism here is equivalent to "just doing the right > thing" with TCP, so we should fix it operationally, not by > changing the > protocol. > > Poll: Should we change the SIP spec to encourage leaving TCP > connections open unless they need to be closed? Strong consensus > reported. Proposed that we do minimal bug fixes in SIP, and do a > separate document with an operational focus on "how to" reuse TCP, > initially as a discussion and possibly leading into a BCP. No > objections > noted. Vijay Gurbani may volunteer to lead on a usage document. > > > > Topic: Conferencing Design Team, Alan Johnstson > > Requirements, Framework, and Call Control ready for WG adoption. > Conference Policy is splitting into two and should be ready shortly. > Media policies work requirements progressing, work on policy > manipulation is ongoing, and the policy work needs a new > home. MMUSIC is > not going to adopt this in their new charter. > > Question: This policy work is related to data manipulation in SIMPLE, > can we combine it? Ans: Probably not. One is data manipulation, the > other is policy RPC. > > Open issues recapped in slides. > > Discussion of absolute vs. relative time in focus. Why not > have absolute > time? Ans. Simplifies timeing coordination on focus. > > Comment: We do have requirements for realtime transitional > controls for > things like camera-follows-speaker. SOAP and ACAP don't > combine to meet > this requirement. Ans: This is for more persistent policy, not > floor-control. Floor-control remains a media problem. > > Poll: Do we wish to, as proposed, adopt the requirements, > framework, and > call control drafts as wg efforts? Strong consensus, no objections. > > Question: Is discovery in-scope? It could be a furball. > > Request: Make focus migration happen sooner rather than > later. This will > be required for three-way to more-way migrations. This is > also important > from a fault recovery standpoint. The call-control is easy, > just a REFER > series, but handling the policy migration is more interesting. > > Discussion: Policy group needs working group home. Rohan: > mmusic will > NOT be chartered to do this; so it is either us or a new BOF. > Will work > it out with the ADs later. We have not been told that we > have to stop > working on this. > > Open issues: conference policy protocol, floor control, notifications. > > Proposed: Adopt Reqs, framework, and call control I-Ds as WG > documents. > Poll taken, and strong consensus reported. > > Open reqs: discovery, focus role migration, cascading and > camera control. > > > > Topic: Hearing impaired media transcoding, Gonzalo Camarillo > > Work proceeding, no surprises. Author reports little progresssince > last IETF and believes that now that we have media policy I-D and > session policy reqs, we will make more progress for the next IETF. > > > > Topic: Emergency calling design team, Jon Peterson > > Work proceeding, will try to have face-to-face meeting here. > Two cases > -- regular 911 calls, and PSAP access-link replacement. Can we divide > these two cases so that there is something available for > "today's PSTN > PSAP"? > > > > Topic: Event Throttling Requirements, Aki Niemi > > Notification rate limiting is the "common factor" among most of the > event filtering discussions. Issues: Is the model accurate and > appropriate? Do we need both the leaky bucket and the strict > throttle? > Is it ok to leave handling of quarantined notifications out > of scope? Is > this work useful? > > Discussion: It may be important to have a different > throttling mechanism > for "aggregated/filtered" notifications than for simply > prioritized or > decimated notifications. The current work does not really consider > notification volume/size, just counts. Discussion about the > difference > between quarantine and gating/throttling functions. One can define a > five-token multibucket scenario that's fairly complete. Is this too > complicated to be practical? Volutneers to review reqs -- Jonathan, > David Oran, and Tomn Taylor volunttered. Poll for adoption: none > opposed. Question: Is there standardization required to be > able to rate > limit? > > Event Throttle Requirements, Aki Niemi > > Aki went through the model and the requirements (see slides). > Issues: Is > the model accurate and appropriate? Do we need both > leaky-bucket and the > strict throttle models, or is only one of them enough? > > Observation from floor: Quarantining and throttling are not the same > thing. One introduces delay the other control rates. > > Rohan: Jonathan, Dave Oran and Dean will review the I-D and > the WG will > receive an update from them before this becomes a WG document. > > > > > > Session 2, Wednesday March 19, 1530-1730: > > Scribes: Paul Kyzivat, Vijay Gurbani > Chat coordinator: Brian Rosen > > Session called to-order by chairs. Agenda agreed as follows: > > 1530 Agenda Bash > Security Related Issues > 1535 Role-based Authorization Requirements, Jon Peterson > draft-peterson-sipping-role-authz-00.txt > 1545 Request History, Mary Barnes > draft-ietf-sipping-req-history-02.txt > draft-barnes-sipping-history-info-02.txt > Operations > 1605 SIP Endpoint Service Charging Requirements, Wolfgang Beck > draft-beck-sipping-svc-charging-req-01.txt > 1615 SIP User Agent Configuration - Dan Petrie > draft-ietf-sipping-config-framework-00.txt > 1625 Issues in Dual Stack Environments, Hakan Persson > draft-persson-sipping-sip-issues-dual-stack-00.txt > 1635 SIP-AAA Requirements, Gonzalo Camarillo > draft-ietf-sipping-aaa-req-02.txt > Media Related Issues > 1645 Early Media, Gonzalo Camarillo > draft-camarillo-sipping-early-media-01.txt > 1710 Network Announcements, Eric Burger > draft-burger-sipping-netann-05.txt > 1720 Considerations on the IPREP Requirements, Jon Peterson > draft-peterson-sipping-ieprep-00.txt > 1730 Wrap > > > > Topic: Role-Based Authentication, Jon Peterson > > Slides introduce concept. Question: Can you show some use > cases? Assume > two previously unassociated carriers in a federation wish to exchange > calls. One carrier issues an authorization object, which the caller > hands to the other carrier, allowing the call to proceed. > Other examples > followed. > > Discussion from floor: Are we proposing replacing identity > with roles? > Jon responded that this could encompass identity, but maybe not. > suggested from floor that we add more in doc explaining relationship > between identity and roles, agreed to by author. > > Request: Somebody asked for more use cases. Was also > concerned whether > all stated requirements were self consistent. > > Observation from floor: Jiri Kuthan suggested that this was a > replacement/alternative for network asserted identity. > > Observation from floor: Somebody suggested that Role wasn’t > exactly the > right term to use. > > > > Topic: Request History Rqmts and Solution, Mary Barnes > > Slides presented, included in proceedings. Mary Barnes > presented current > status of both documents. Both requirements and solution > have had two > new versions since last meeting, now up to -02. Mary > explained changes. > Of note - separating out security requirements, to separate document. > > Remaining open issue is security, which is work-in-progress, which a > seperate security solution draft expected soon. > > Consensus that requirements document is roughly complete and > should be > referred to SIP WG for action. Chairs need to refer to AD for > approval. > > > > Topic: SIP Endpoint Service Charging Requirements, Wolfgang Beck > > Slides presented included in proceedings. > > Introduces requirements and a model for third-party trust assignment > with SIP. Possibly combinable with role-based-authorization. > > Proposal: this should be two drafts, one around charging and another > about advice-of-charge. > > Comment: this seems to be limited to a fixedSIP architecture as > currently written. > > Comment: the evaluation of the requirements presented in the draft > would be greatly aided by the inclusion of use cases. > > Comment: reading the document indicates a specific business model > in-mind. Work here should be network agnostic and not make > assumptions > about who is paying (like caller always pays) etc. > > Question from chairs: Are we interested in trying to gather > requirements > to support an endpoint based charging model (i.e., not billing from > intermediaries). Consensus that we would like to see the work more > completely illustrated, including use cases, before > considering its utility. > > > > Topic: Config Framework, Dan Petrie > > Slides presented included in proceedings. > > Open Question: Should HTTPS be a SHOULD or MUST strength > reequirement: > Ans. MUST implement, SHOULD use. Open Question: Is HTTPish > preferred to > LDAP or ACAP? > Open Question: Is this related to NETCONF work? > > Discussion: There are issues here that cannot be fixed with > HTTPS pixie > dust. You need a separate mechanism of top of HTTPS to verify the > identity of the node requesting configuration. Of course, > this needs to > be configured in. So there is a bootstrapping problem. > > Open question: device identity parameters: User-agent header? New > header? No decision made. > > Open question: How to indicate profile type? Accept-header or event > header parameter or request-URI? Comment: this is the same problem as > SIMPLE's buddy list management and should use the same mechanism. > Further discussion taken to the list. > > Dan Petrie presented. Identified changes from prior version. > (draft-petrie-sipping-config-framework-00) > > There were comments about strength of use for HTTPS for content > indirection in here. General sentiment seemed to be that > HTTPS should be > MUST implement, SHOULD use. Other protocols other than http/https are > also possible. > > Henning Schulzrinne said https isn’t enough. Said there were both > confidentiality issues as well as way to ensure the client gets the > right data. In absence of client cert, which you can’t assume during > config, presents difficult problems – how to bootstrap. > > Dan acknowledged this problem, and said he has already proposed to do > work to deal with that. Further discussion went on. Rohan asked that > this go to list. > > Dan requested input on list for where device identification > should go – > in User-Agent header or somewhere else. > > Discussion of profile type – where to indicate in > subscription. Jonathan > Rosenberg thought you could subscribe to a different request uri for > each kind of thing. Rohan Mahy disagreed. Was sent to the list for > discussion. > > Jonathan suggested this is similar to SIMPLE problem regarding > buddylists, and the two works should be synchronized. > > > > Topic: Dual-Stack Issues, Hakan Persson > > Slides introduce problem and recaps several solutions. The "contact" > problem seems to be addressable in part by dual-interfaced > record-route > and in part by ICE. The document will be revisited by the author > exlporing usage of these techniques and, if the solution is > satisfactory, can become a usage document illustrating the > solution to > the problems it has already raised. > > > > Topic: AAA Req, Gonzalo Camarillo > > Slides presented included in proceedings. > > Currently in WGLC. Poll: Any issues that have been missed? No new > issues. Attendees encouraged to follw WGLC. > > > > Topic: Early Media, Gonzalo Camarillo > > Slides presented included in proceedings. > > Open issues: There appear to be three ringback states from ISUP, and > only two codes (180, 183) available in SIP. Not all protagonists are > present and the author proposes to hold a conference call for > resolution. Debate ensued anyhow, trying to capture essence of the > issue. Francois, Flemming, Rohan, others agreed to send use cases > illustrating the issues they need solved. Poll: should we add > a flag? No > clear consensus > > > > Topic: Network Announcements, Eric Burger > > Slides presented included in proceedings. > > Open Issue: Media on Hold? What does a media server do when > it gets put > on hold? This seems to be application specific, not a SIP > protocol problem. > > Open Issue: 409 Result code proposal? Suggestion from audience Can we > TRY not to use things that are used in HTTP to mean something > different? > Sugggestion: Could we use a standard response code and a > Reason field? > Conversation deferred to list with emphasis on 6xx vs 4xx debate. > > Open Issue: Multiple Media Streams:? What do do then, to > play multiple > things? Eric asserted this isn’t an issue if the target uri is a > composite object. He wanted to know if that is the > predominant use case. > And if not, how would the multiple streams be synced? Brian Rosen > wondered why it isn’t good enough to pick one stream. > Confusion reigns, > deferred to list. > > Open issue: IS everything in this draft consistent with WG usage? We > need to be sure we're aligned with conferencing and early media work? > Author asked to work with Alan Johnston on conferencing > alignment, and > Gonzalo Camarillo on early media. > > > > Topic: IEPREP Considerations, Jon Peterson > > SIPPING asked to provide formal response to the IEPREP > considerations, > widely discussed on mailing list. Open Issue: SHOULD we address this > here? As there is already work in SIP on the priority header? > Should we > do it here? > > Discussion: > > Jon Peterson presented. Said this work was in response to requests by > area directors for comments on RFC3478. This is Jon’s private > attempt at > comments, based on some discussion on list. > > Jon raised privacy issues. Henning said there are fundamental > tradeoffs > between privacy and proxies, and that therefore it is > necessary to offer > endpoint with options for either. > > Keith Drage asserted that either there is an error in the IEPREP > requirements that ought to be fixed there, or else it should be dealt > with by SIP in responding to the requirements, so there is no > need for > SIPPING draft in this instance. Allison Mankin agreed, said the area > directors could deal with this aspect now, and don’t need > any more input. > > Rohan observed that SIP already adopted a mechanism that > relates to this. : > > Meeting concluded. > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 14 19:33:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26794 for ; Mon, 14 Apr 2003 19:33:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ENfS302028 for sipping-archive@odin.ietf.org; Mon, 14 Apr 2003 19:41:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ENfS802025 for ; Mon, 14 Apr 2003 19:41:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26781 for ; Mon, 14 Apr 2003 19:33:05 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195DUA-00069i-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 19:35:38 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195DUA-00069e-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 19:35:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ENbx801875; Mon, 14 Apr 2003 19:37:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ENZM800943 for ; Mon, 14 Apr 2003 19:35:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26652 for ; Mon, 14 Apr 2003 19:27:00 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195DOH-00067U-00 for sipping@ietf.org; Mon, 14 Apr 2003 19:29:33 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 195DOG-00067P-00 for sipping@ietf.org; Mon, 14 Apr 2003 19:29:32 -0400 Received: from softarmor.com ([216.229.166.130]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h3ENS5sD004921 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 14 Apr 2003 18:29:07 -0500 Message-ID: <3E9B43CC.8030008@softarmor.com> Date: Mon, 14 Apr 2003 18:27:08 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'sipping@ietf.org'" Subject: Re: [Sipping] Draft Minutes, SIPPING WG, IETF 56 References: <475FF955A05DD411980D00508B6D5FB00439ECB7@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439ECB7@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > Text of minutes: > > "Do we want to work on this problem? That is the real issue for us to > decide now. > > Many people approached the mic and agreed to the requirements being valid. > > Gonzalo took a hum level on taking the requirements as base for the work > going forward. Hum level indicated interest." > > Firstly, I thought the hum was on having a requirements document in this area being worked as a working group draft, rather than on the current contents. While I do not have any major issues with the contents, I prefer to get this correct. I'll clarify this in the minutes. > Secondly, one of the comments I made at the mic related to the relationship to the solutions document in http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-00.txt to the effect that the requirements document should be advanced, and when we have the requirements document agreed, we will then see if this solutions draft is the correct solution, or whether others exist. I think that it is important to capture something to this effect. ok, will note. New text: "Do we want to work on this problem? That is the real issue for us to decide now. Many people approached the mic and agreed to the requirements being valid. Keith Drage suggested that we resolve the requirements before proceeding with a solution, and that consideration of various solutions (such as Jonathan's proposal) should be deferred until the requirements are agreed. Poll: who thinks we should take this work on as a baseline for requirements? Strong consensus reported, none opposed. Chairs will request approval as a WG item from ADs." -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 14 22:40:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00923 for ; Mon, 14 Apr 2003 22:40:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F2ifY13639 for sipping-archive@odin.ietf.org; Mon, 14 Apr 2003 22:44:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F2ia813633 for ; Mon, 14 Apr 2003 22:44:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00885 for ; Mon, 14 Apr 2003 22:36:11 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195GLL-0006zP-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 22:38:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195GLK-0006zM-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 22:38:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F2cK813369; Mon, 14 Apr 2003 22:38:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F2bb813269 for ; Mon, 14 Apr 2003 22:37:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00728 for ; Mon, 14 Apr 2003 22:29:12 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195GEa-0006xR-00 for sipping@ietf.org; Mon, 14 Apr 2003 22:31:44 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 195GEZ-0006xN-00 for sipping@ietf.org; Mon, 14 Apr 2003 22:31:43 -0400 Received: from dynamicsoft.com ([63.113.46.26]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3F2VABd017545; Mon, 14 Apr 2003 22:31:10 -0400 (EDT) Message-ID: <3E9B6EEA.3030207@dynamicsoft.com> Date: Mon, 14 Apr 2003 22:31:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Volker Hilt CC: sipping , Henning Schulzrinne References: <3E9B19F3.5090505@bell-labs.com> In-Reply-To: <3E9B19F3.5090505@bell-labs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: dialog event package: event code Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit responses inline. Volker Hilt wrote: > Hi all, > > I don't know if the following issue has already been discussed on the list. > > The dialog event package defines a way of reporting dialog state to > another user. The dialog information format (the default payload format > for dialog event NOTIFYs) contains information about the current dialog > state and it may provide information about the event that has caused the > state transition. Here's what the draft says: > > 3.1.2 State > > The state element indicates the state of the dialog. Its value is an > enumerated type describing one of the states in the FSM above. It has > an optional event attribute that can be used to indicate the event > which caused the transition into the current state, and an optional > code attribute that indicates the response code associated with the > transition, assuming the event was 1xx-tag, 1xx-notag, or 2xx. > > My question refers to the last sentence of this section: what is the > reason for restricting the reporting of response codes to 1xx and 2xx > events? Wouldn't it make sense to also allow the reporting of response > codes for rejected events and possibly also for error and timeout > events? (Btw. the schema definition already allows codes between 100 and > 699.) I can't think of a particularly good reason, to be honest. I think it would be fine to include the response code for any event caused by a response. I'll make the change in the next rev (which is probably going to be the result of AD comments, as I believe this doc is ready to go to IESG). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 14 23:47:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02321 for ; Mon, 14 Apr 2003 23:47:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F3tiY17601 for sipping-archive@odin.ietf.org; Mon, 14 Apr 2003 23:55:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F3ti817598 for ; Mon, 14 Apr 2003 23:55:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02309 for ; Mon, 14 Apr 2003 23:47:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195HS9-0007KY-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 23:49:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195HS9-0007KV-00 for sipping-web-archive@ietf.org; Mon, 14 Apr 2003 23:49:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F3sV817570; Mon, 14 Apr 2003 23:54:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F3rD817505 for ; Mon, 14 Apr 2003 23:53:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02186 for ; Mon, 14 Apr 2003 23:44:46 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195HPi-0007Jw-00 for sipping@ietf.org; Mon, 14 Apr 2003 23:47:18 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 195HPh-0007Jr-00 for sipping@ietf.org; Mon, 14 Apr 2003 23:47:17 -0400 Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3F3koBd017589; Mon, 14 Apr 2003 23:46:50 -0400 (EDT) Message-ID: <3E9B80A5.7080903@dynamicsoft.com> Date: Mon, 14 Apr 2003 23:46:45 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: Gonzalo Camarillo , sipping@ietf.org, Rohan Mahy Subject: Re: [Sipping] Questions on connect-reuse References: <3E802C1F.6EF210E@lmf.ericsson.se> <3E8D5F19.8@lmf.ericsson.se> <3E9111FD.993C2F93@lmf.ericsson.se> <3E912D87.4070309@lmf.ericsson.se> <3E914087.E152F307@lmf.ericsson.se> In-Reply-To: <3E914087.E152F307@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Christer Holmberg wrote: > Hi, > > >>the client wants the server to create an alias even if the server never >>sends requests back to the client within this dialog. The server may >>send requests that belong to different dialogs, for instance. Therefore, >>you argument in favor of Route loses its stregth. >> >>In addition to that, having that information in the Via header field is >>quite good from the processing point of view. When you receive a >>request, you parse the Via header field to add a received parameter, for >>instance... it seems like a good time for creating the alias. > > > True. > > Another question: > > Assume the connection goes down between two servers. Now, both create a new > connection at the same time, so we will have two connections between the servers > (this scenario is what the connect-reuse extension is supposed to avoid). Now, is > this something we should accept as something which can happen? I don't think we > can say that one of the servers to close one of the connections, because we don't > know which server would do it, and we don't know which connection it would > close... It is not worth trying to figure out which to close. Both connections would exist. > > And, since there are now two connections between the node, is there any priority > on which should be used when a request is sent: the connection (which our server > created) to the "real" port (which would be used if there was no existing > connection) of the other server, or the connection (created by the remote server) > to the emphemeral port of the other server? This is no different than the case where I have multiple TCP connections open to the same well-known port. The spec doesn't specify a load balancing algorithm across connections. Generally, you should prefer one of them, rather than spreading across them, for reasons of congestion control. That probably needs to be said in rfc3261. > > > Another question: > > RFC3261 basically talks about re-use of connections in one direction. Also, > RFC3261 doesn't say (I appologise if it does and I missed it) anything about port > overriding ("use the connection even if the port of your lookup is different") > which the connect-reuse draft says. So, I would just like to confirm that it means > that a RFC3261 node, NOT supporting the connect-reuse extension, should send > requests to whatever port is has recieved, no matter if a connection already > exists to the same IP address, but another port? Correct. In rfc3261, the combination of IP and port serve as the connection index. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 15 00:25:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03125 for ; Tue, 15 Apr 2003 00:25:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F4XWc19789 for sipping-archive@odin.ietf.org; Tue, 15 Apr 2003 00:33:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4XW819786 for ; Tue, 15 Apr 2003 00:33:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03122 for ; Tue, 15 Apr 2003 00:25:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195I2i-0007V1-00 for sipping-web-archive@ietf.org; Tue, 15 Apr 2003 00:27:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195I2i-0007Uy-00 for sipping-web-archive@ietf.org; Tue, 15 Apr 2003 00:27:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4WP819748; Tue, 15 Apr 2003 00:32:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4V9819680 for ; Tue, 15 Apr 2003 00:31:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02834 for ; Tue, 15 Apr 2003 00:22:41 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195I0P-0007UW-00 for sipping@ietf.org; Tue, 15 Apr 2003 00:25:13 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 195I0O-0007UT-00 for sipping@ietf.org; Tue, 15 Apr 2003 00:25:12 -0400 Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3F4OqBd017595 for ; Tue, 15 Apr 2003 00:24:52 -0400 (EDT) Message-ID: <3E9B8990.7080509@dynamicsoft.com> Date: Tue, 15 Apr 2003 00:24:48 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] comments on connection reuse requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Much of the discussion so far on connection reuse has been on the mechanism. However, if we wish to make progress on this (and we do), we need to separate the mechanism from the requirements, and make sure we are happy with the requirements. So, a few comments: > 2. A connection sharing mechanism SHOULD allow SIP entities to reuse > existing connections with closely coupled nodes which act as a > single SIP entity (for example a cluster of nodes acting as a > proxy server). this requirement is hard to understand, and its actually the driving force behind the current design decision. I think what you are really trying to say is: A connection sharing mechanism SHOULD ensure that a UA can maintain multiple connections, each one to a server in a cluster, so that if an element in the cluster fails, the UA can still receive requests from a connection to a different server in the cluster. There is also this unwritten requirement: The mechanism must be backwards compatible, so that if a peer doesn't support it, the result is that two connections will be opened, as per the current specification. The current mechanism, however, doesn't let a UA know if the next hop supports the alias mechanism or not. I suggest this requirement: There must be a way for a client to determine if the server supported the extension. This is easily done the same way rport works. The alias is "filled in" by the server when the resposne is forwarded. If the client sees it filled in, it knows the extension was supported. Here, the value filled in is irrelevant; just a flag to indicate it was supported. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 15 00:37:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03382 for ; Tue, 15 Apr 2003 00:37:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F4j7C21021 for sipping-archive@odin.ietf.org; Tue, 15 Apr 2003 00:45:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4j7821018 for ; Tue, 15 Apr 2003 00:45:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03374 for ; Tue, 15 Apr 2003 00:36:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195IDv-0007XC-00 for sipping-web-archive@ietf.org; Tue, 15 Apr 2003 00:39:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195IDu-0007X9-00 for sipping-web-archive@ietf.org; Tue, 15 Apr 2003 00:39:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4d5820830; Tue, 15 Apr 2003 00:39:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F4cR820801 for ; Tue, 15 Apr 2003 00:38:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03227 for ; Tue, 15 Apr 2003 00:29:59 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195I7T-0007W8-00 for sipping@ietf.org; Tue, 15 Apr 2003 00:32:31 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 195I7T-0007Vy-00 for sipping@ietf.org; Tue, 15 Apr 2003 00:32:31 -0400 Received: from dynamicsoft.com ([63.113.46.85]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3F4RRBd017601; Tue, 15 Apr 2003 00:27:27 -0400 (EDT) Message-ID: <3E9B8A2B.3030102@dynamicsoft.com> Date: Tue, 15 Apr 2003 00:27:23 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: Natesan Kannan , Gonzalo Camarillo , seancolson@yahoo.com, "'sal'" , "'sipping'" , "'Rohan Mahy'" Subject: Re: [Sipping] Connection re-use References: <000501c301e3$f14f5ce0$6501a8c0@cranberry> <3E9A51C8.9030406@lmf.ericsson.se> <003401c30251$a6694830$6802120a@in.huawei.com> <3E9A5D4D.FED87D26@lmf.ericsson.se> In-Reply-To: <3E9A5D4D.FED87D26@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > Assume I have a connection to proxy1.ericsson.com and port X. Then, a SRV lookup > returns proxy1.ericsson.com and port Y (same proxy, different port). > > I guess it in this case also is an implementation issue if I want to establish a > new connection to the new port, or if I use the existing connection to the old > port? No. I thik it always uses the port returned from DNS, and if it has a connection to that alias, uses that connection. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 15 04:02:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18634 for ; Tue, 15 Apr 2003 04:02:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F8A0C14542 for sipping-archive@odin.ietf.org; Tue, 15 Apr 2003 04:10:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8A0814539 for ; Tue, 15 Apr 2003 04:10:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18610 for ; Tue, 15 Apr 2003 04:01:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195LQ7-0000qq-00 for sipping-web-archive@ietf.org; Tue, 15 Apr 2003 04:03:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195LQ7-0000qn-00 for sipping-web-archive@ietf.org; Tue, 15 Apr 2003 04:03:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F88f814445; Tue, 15 Apr 2003 04:08:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EMKT829214 for ; Mon, 14 Apr 2003 18:20:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24508 for ; Mon, 14 Apr 2003 18:12:09 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195CDp-0005ft-00 for sipping@ietf.org; Mon, 14 Apr 2003 18:14:41 -0400 Received: from oe31.pav1.hotmail.com ([64.4.30.88] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 195CDp-0005ff-00 for sipping@ietf.org; Mon, 14 Apr 2003 18:14:41 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 14 Apr 2003 15:14:16 -0700 Received: from 64.102.254.33 by oe31.pav1.hotmail.com with DAV; Mon, 14 Apr 2003 22:14:16 +0000 X-Originating-IP: [64.102.254.33] X-Originating-Email: [sip_developer@hotmail.com] From: "SIP Developer" To: Date: Mon, 14 Apr 2003 18:14:14 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C302B1.A7C442B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 14 Apr 2003 22:14:16.0498 (UTC) FILETIME=[301BA920:01C302D3] Subject: [Sipping] Few questions on SIP Protocol Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C302B1.A7C442B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I am new to SIP Protocol. I am having few questions : 1) How can a SIP Gateway indicate a "Resource Availability" to SIP Proxy = or SIP Redirect (similar to RAI mechanism in H.323)? 2) How can an endpoint sends DTMF in a reliable way ? Does RFC2833 = provides a reliable mechanism to send DTMF ? How is RFC2833 compared to = SIP INFO ? 3) Does SIP provides a mechanism for failover to backup signaling entity = if the primary signaling entity fails ? Please also give me pointers to specific documents (if any).=20 Rohan Kumar ------=_NextPart_000_000B_01C302B1.A7C442B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I am new to SIP Protocol.
 
I am having few questions = :
 
1) How can a SIP Gateway indicate a = "Resource=20 Availability" to SIP Proxy or SIP Redirect (similar to RAI mechanism in=20 H.323)?
2) How can an endpoint sends DTMF in a = reliable way=20 ? Does RFC2833 provides a reliable mechanism to send DTMF ? How is = RFC2833=20 compared to SIP INFO ?
3) Does SIP provides a mechanism for = failover=20 to backup signaling entity if the primary signaling entity fails=20 ?
 
Please also give me pointers to = specific documents=20 (if any).
 
Rohan Kumar
 
------=_NextPart_000_000B_01C302B1.A7C442B0-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 15 04:03:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18648 for ; Tue, 15 Apr 2003 04:03:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F8BEq14636 for sipping-archive@odin.ietf.org; Tue, 15 Apr 2003 04:11:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8BE814633 for ; Tue, 15 Apr 2003 04:11:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18630 for ; Tue, 15 Apr 2003 04:02:42 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195LRJ-0000rG-00 for sipping-web-archive@ietf.org; Tue, 15 Apr 2003 04:05:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195LRI-0000rD-00 for sipping-web-archive@ietf.org; Tue, 15 Apr 2003 04:05:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F88U814424; Tue, 15 Apr 2003 04:08:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EKaw820683 for ; Mon, 14 Apr 2003 16:36:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20645 for ; Mon, 14 Apr 2003 16:28:40 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Abg-0004zg-00 for sipping@ietf.org; Mon, 14 Apr 2003 16:31:12 -0400 Received: from ns2.research.bell-labs.com ([204.178.16.49] helo=crufty.research.bell-labs.com) by ietf-mx with esmtp (Exim 4.12) id 195Abf-0004zd-00 for sipping@ietf.org; Mon, 14 Apr 2003 16:31:11 -0400 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h3EKV29Y015653; Mon, 14 Apr 2003 16:31:02 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h3EKUuUf077362; Mon, 14 Apr 2003 16:30:56 -0400 (EDT) Received: from bell-labs.com (volker-hopc [135.180.240.186]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h3EKUsQ4000822; Mon, 14 Apr 2003 16:30:54 -0400 (EDT) Message-ID: <3E9B19F3.5090505@bell-labs.com> Date: Mon, 14 Apr 2003 16:28:35 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: sipping CC: Henning Schulzrinne , Jonathan Rosenberg Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] dialog event package: event code Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I don't know if the following issue has already been discussed on the list. The dialog event package defines a way of reporting dialog state to another user. The dialog information format (the default payload format for dialog event NOTIFYs) contains information about the current dialog state and it may provide information about the event that has caused the state transition. Here's what the draft says: 3.1.2 State The state element indicates the state of the dialog. Its value is an enumerated type describing one of the states in the FSM above. It has an optional event attribute that can be used to indicate the event which caused the transition into the current state, and an optional code attribute that indicates the response code associated with the transition, assuming the event was 1xx-tag, 1xx-notag, or 2xx. My question refers to the last sentence of this section: what is the reason for restricting the reporting of response codes to 1xx and 2xx events? Wouldn't it make sense to also allow the reporting of response codes for rejected events and possibly also for error and timeout events? (Btw. the schema definition already allows codes between 100 and 699.) This would allow the subscriber (e.g. a call logging application) to better understand why a call has failed (e.g. differentiate between a 486 Busy Here and a 404 Not Found). Thanks, Volker -- Volker Hilt Bell Labs / Lucent Technologies phone: +1 732 332 6432 101 Crawfords Corner Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 15 10:19:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29112 for ; Tue, 15 Apr 2003 10:19:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FER9R07088 for sipping-archive@odin.ietf.org; Tue, 15 Apr 2003 10:27:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FER9807085 for ; Tue, 15 Apr 2003 10:27:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29102 for ; Tue, 15 Apr 2003 10:18:29 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195RIy-0002kZ-00 for sipping-web-archive@ietf.org; Tue, 15 Apr 2003 10:21:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195RIx-0002kW-00 for sipping-web-archive@ietf.org; Tue, 15 Apr 2003 10:20:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FEQI807032; Tue, 15 Apr 2003 10:26:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FEOt806973 for ; Tue, 15 Apr 2003 10:24:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28882 for ; Tue, 15 Apr 2003 10:16:16 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195RGp-0002js-00 for sipping@ietf.org; Tue, 15 Apr 2003 10:18:47 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 195RGo-0002jj-00 for sipping@ietf.org; Tue, 15 Apr 2003 10:18:46 -0400 Received: from cia.cisco.com (IDENT:mirapoint@cia.cisco.com [64.100.238.51]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3FEIGB0027868; Tue, 15 Apr 2003 10:18:16 -0400 (EDT) Received: from mhammer-w2k02.cisco.com (dhcp-hrn-64-100-229-172.cisco.com [64.100.229.172]) by cia.cisco.com (Mirapoint) with ESMTP id ACE77874; Tue, 15 Apr 2003 10:18:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20030415101727.00b4f468@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Apr 2003 10:18:14 -0400 To: Henning Schulzrinne From: Michael Hammer Subject: Re: [Sipping] Geopriv and SIP current state Cc: Dean Willis , "'Shane McCormack'" , "'Sipping@Ietf. Org'" In-Reply-To: <3E95B260.20700@cs.columbia.edu> References: <003d01c2ff89$bcf2daf0$ee036e3f@txdwillis> <003d01c2ff89$bcf2daf0$ee036e3f@txdwillis> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Henning, There are already standard representations of geolocation and geo-velocity. Do you intend to be compatible with those? Mike At 02:05 PM 4/10/2003 -0400, Henning Schulzrinne wrote: >Jon and I are (will be...) working on a draft for geopriv on the SIMPLE >aspect. As is noted in Jon's current simple-for-geopriv draft, SIMPLE >offers many of the mechanisms that are needed to satisfy the geopriv >privacy requirements. > >Dean Willis wrote: > >> >>I think that geolocation information could reasonably be included in >>presence documents and correspondingly delivered in presence >>notifications as being developed in SIMPLE. It would probably NOT be >>appropriat, as a general solution, to include geoloc (as a header or >>otherwise) in every message as the overhead of protecting that content >>could become enormous. >> >>Requesting "just geoloc" when subscribing to someone's presence would >>perhaps be implemented using the filtering mechanisms currently being >>discussed in SIMPLE and SIPPING. >> >>The actual format of geoloc data has not yet been determined. I >>anticipate using the location format deliverable of the GEOPRIV working group. >> > > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 15 22:51:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20595 for ; Tue, 15 Apr 2003 22:51:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3G30M128539 for sipping-archive@odin.ietf.org; Tue, 15 Apr 2003 23:00:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G30L828536 for ; Tue, 15 Apr 2003 23:00:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20591 for ; Tue, 15 Apr 2003 22:51:27 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195d3d-00067U-00 for sipping-web-archive@ietf.org; Tue, 15 Apr 2003 22:53:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195d3c-00067Q-00 for sipping-web-archive@ietf.org; Tue, 15 Apr 2003 22:53:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G2r3828243; Tue, 15 Apr 2003 22:53:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G2pt828169 for ; Tue, 15 Apr 2003 22:51:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20407 for ; Tue, 15 Apr 2003 22:43:01 -0400 (EDT) From: Mpierce1@aol.com Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195cvT-00065J-00 for sipping@ietf.org; Tue, 15 Apr 2003 22:45:31 -0400 Received: from imo-r04.mx.aol.com ([152.163.225.100]) by ietf-mx with esmtp (Exim 4.12) id 195cvS-00064x-00 for sipping@ietf.org; Tue, 15 Apr 2003 22:45:30 -0400 Received: from Mpierce1@aol.com by imo-r04.mx.aol.com (mail_out_v34.21.) id c.169.1d3fe7b4 (17079); Tue, 15 Apr 2003 22:44:48 -0400 (EDT) Message-ID: <169.1d3fe7b4.2bce1d9f@aol.com> Date: Tue, 15 Apr 2003 22:44:47 EDT Subject: Re: [Sipping] Geopriv and SIP current state To: mhammer@cisco.com, hgs@cs.columbia.edu CC: sipping@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_169.1d3fe7b4.2bce1d9f_boundary" X-Mailer: 6.0 for Windows XP sub 10501 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --part1_169.1d3fe7b4.2bce1d9f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 4/15/2003 10:36:19 AM Eastern Standard Time, mhammer@cisco.com writes: > There are already standard representations of geolocation and > geo-velocity. Do you intend to be compatible with those? > There's a good one in Q.763 that should suffice for location. I've missed the point of the requirement for "velocity". Mike --part1_169.1d3fe7b4.2bce1d9f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 4/15/2= 003 10:36:19 AM Eastern Standard Time, mhammer@cisco.com writes:


There are already standard=20= representations of geolocation and=20
geo-velocity.  Do you intend to be compatible with those?


There's a good one in Q.763 that should suffice for location. I've misse= d the point of the requirement for "velocity".

Mike
--part1_169.1d3fe7b4.2bce1d9f_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 16 03:17:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20983 for ; Wed, 16 Apr 2003 03:17:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3G7PxC25906 for sipping-archive@odin.ietf.org; Wed, 16 Apr 2003 03:25:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G7Pw825903 for ; Wed, 16 Apr 2003 03:25:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20980 for ; Wed, 16 Apr 2003 03:16:57 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195hCa-0007Fm-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 03:19:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195hCa-0007Fj-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 03:19:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G7PD825870; Wed, 16 Apr 2003 03:25:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G7Or825825 for ; Wed, 16 Apr 2003 03:24:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20962 for ; Wed, 16 Apr 2003 03:15:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195hBX-0007FZ-00 for sipping@ietf.org; Wed, 16 Apr 2003 03:18:23 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 195hBX-0007FW-00 for sipping@ietf.org; Wed, 16 Apr 2003 03:18:23 -0400 Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3G7I3Bd018059 for ; Wed, 16 Apr 2003 03:18:03 -0400 (EDT) Message-ID: <3E9D03A7.1090505@dynamicsoft.com> Date: Wed, 16 Apr 2003 03:17:59 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Thoughts on GRUUs, URI leasing and embedded route headers Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit During the San Francisco IETF, there was a lot of discussion on the concept of a GRUU: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-lease-00.txt A GRUU, defined in this I-D, is a URI with the property that it routes to a specific UA instance. GRUUs are needed for lots of applications, like assisted call transfer, presence, and 3g/802.11 roaming (a recent application for a gruu identified on the list). During the meeting, there was a lot of confusion on two points, and I want to continue the dialog over email and attempt to clarify them. 1. The I-D talks about temporal scoping. Forget the word temporal. The idea really is that a UA should be able to manufacture an infinite supply of URIs that route to itself. In the process of that manufacturing, it needs to be able to place information into the URI, so that it can use that information to determine some kind of context when it receives a call to that URI. As an example, if a UA decides to host a conference, it needs to manufacture a conference URI that is unique for that conference, and identifies the conference. 2. Getting to specifics, there are really two candidate approaches for constructing a GRUU. Rohan and Alan advocated the idea of using embedded Route headers, thusly: sip:user@example.com?Route=sip:proxy1.example.com?Route=sip:proxy2.example.com A UA would be provisioned with this sequence of routes. The idea I was trying to promote in my I-D is that there is another way. Instead, the UA asks the domain to give it a URI that has the GRUU property. The domain can populdate the user portion of this URI in such a way that it provides sufficient context for the domain to route the request to that UA. THis can be done in a stateless way if the leasing operation is combined with a registration. So, for example, when a UA registers thusly: REGISTER To: sip:user@example.com Contact: sip:1.2.3.4 the domain could provide the UA with the following URI in the 200 OK to REGISTER: sip:cookie-user-1.2.3.4@example.com When someone sends a request to this URI, the example.com proxy recognizes this as a GRUU, and sees that what it needs to do is route the request to user@example.com, at their 1.2.3.4 contact. So, it can directly send it to 1.2.3.4 from there. The key idea is that because the domain is the one manufacturing this URI, it can construct the user part in any way it likes, including the inclusion of context to facilitate stateless routing. Now, inclusion of context for stateless routing is just one approach. If a domain wants, it can also just create state for each lease. Its a domain policy issue. One last point here - the draft also talks about the idea that the URI returned by the domain can be considered a URI factory. There can be some kind of wildcard in the URI, which the user can put anything it wants into it, to give the user context. So, which approach is better? I believe that the leasing approach I propose is the right one. Why? Because a GRUU is a *name*. Names need to be obtained from the owner of that namespace, especially when you want the name to be associated with some specific semantic. The first approach, of embedded route headers, is confusing a name with a route. It is trying to identify somethign by the way in which you get to it. As an example of a consequence of this, the way in which a call is routed may depend on the caller. For example, a call center may route calls through some kind of logging server, which are allocated based on the caller's identity. But, with the embedded Route approach, the route is bound to the name, so you cannot change it depending on who is calling. Comments and criticisms? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 16 03:25:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21173 for ; Wed, 16 Apr 2003 03:25:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3G7Xo726261 for sipping-archive@odin.ietf.org; Wed, 16 Apr 2003 03:33:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G7Xo826258 for ; Wed, 16 Apr 2003 03:33:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21087 for ; Wed, 16 Apr 2003 03:24:49 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195hKC-0007HT-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 03:27:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195hKB-0007HQ-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 03:27:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G7X6826226; Wed, 16 Apr 2003 03:33:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3G7WF826182 for ; Wed, 16 Apr 2003 03:32:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21067 for ; Wed, 16 Apr 2003 03:23:13 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195hIe-0007HA-00 for sipping@ietf.org; Wed, 16 Apr 2003 03:25:45 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 195hIe-0007H1-00 for sipping@ietf.org; Wed, 16 Apr 2003 03:25:44 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h3G7O2C02473; Wed, 16 Apr 2003 07:24:02 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Apr 2003 03:25:11 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B2579C4@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Michael Hammer'" , Henning Schulzrinne Cc: Dean Willis , "'Shane McCormack'" , "'Sipping@Ietf. Org'" Subject: RE: [Sipping] Geopriv and SIP current state Date: Wed, 16 Apr 2003 03:25:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is properly a thread for geopriv, but briefly, geopriv is not out to invent any new location formats. It is chartered to define a security and policy wrapper for the carriage of location information on the Internet. Hopefully, geopriv will be compatible with the widest possibility variety of existing geolocation standards. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Tuesday, April 15, 2003 7:18 AM > To: Henning Schulzrinne > Cc: Dean Willis; 'Shane McCormack'; 'Sipping@Ietf. Org' > Subject: Re: [Sipping] Geopriv and SIP current state > > > Henning, > > There are already standard representations of geolocation and > geo-velocity. Do you intend to be compatible with those? > > Mike > > > At 02:05 PM 4/10/2003 -0400, Henning Schulzrinne wrote: > >Jon and I are (will be...) working on a draft for geopriv on > the SIMPLE > >aspect. As is noted in Jon's current simple-for-geopriv > draft, SIMPLE > >offers many of the mechanisms that are needed to satisfy the geopriv > >privacy requirements. > > > >Dean Willis wrote: > > > >> > >>I think that geolocation information could reasonably be > included in > >>presence documents and correspondingly delivered in presence > >>notifications as being developed in SIMPLE. It would > probably NOT be > >>appropriat, as a general solution, to include geoloc (as a > header or > >>otherwise) in every message as the overhead of protecting > that content > >>could become enormous. > >> > >>Requesting "just geoloc" when subscribing to someone's > presence would > >>perhaps be implemented using the filtering mechanisms > currently being > >>discussed in SIMPLE and SIPPING. > >> > >>The actual format of geoloc data has not yet been determined. I > >>anticipate using the location format deliverable of the > GEOPRIV working group. > >> > > > > > >_______________________________________________ > >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > >This list is for NEW development of the application of SIP > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sip@ietf.org for new developments of core SIP > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 16 08:30:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27239 for ; Wed, 16 Apr 2003 08:30:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GCdM316132 for sipping-archive@odin.ietf.org; Wed, 16 Apr 2003 08:39:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GCdL816129 for ; Wed, 16 Apr 2003 08:39:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27207 for ; Wed, 16 Apr 2003 08:30:13 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195m5k-0000hf-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 08:32:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195m5c-0000hD-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 08:32:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GCcV816068; Wed, 16 Apr 2003 08:38:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GCVJ814980 for ; Wed, 16 Apr 2003 08:31:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27052; Wed, 16 Apr 2003 08:22:12 -0400 (EDT) Message-Id: <200304161222.IAA27052@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 16 Apr 2003 08:22:12 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-cc-conferencing-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : Session Initiation Protocol Call Control - Conferencing for User Agents Author(s) : A. Johnston, O. Levin Filename : draft-ietf-sipping-cc-conferencing-00.txt Pages : 24 Date : 2003-4-15 This document defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from different user agent (UA) types perspective: conference-unaware, conference-aware and focus UAs. The use of URIs in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-conferencing-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sipping-cc-conferencing-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-cc-conferencing-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: <2003-4-16083741.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-cc-conferencing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-cc-conferencing-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-16083741.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 16 08:35:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27369 for ; Wed, 16 Apr 2003 08:35:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GChrT16416 for sipping-archive@odin.ietf.org; Wed, 16 Apr 2003 08:43:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GChr816413 for ; Wed, 16 Apr 2003 08:43:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27359 for ; Wed, 16 Apr 2003 08:34:45 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195mA8-0000jf-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 08:37:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195mA8-0000jc-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 08:37:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GCh4816365; Wed, 16 Apr 2003 08:43:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GCgU816331 for ; Wed, 16 Apr 2003 08:42:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27313 for ; Wed, 16 Apr 2003 08:33:23 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195m8n-0000jF-00 for sipping@ietf.org; Wed, 16 Apr 2003 08:35:53 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 195m8m-0000jC-00 for sipping@ietf.org; Wed, 16 Apr 2003 08:35:53 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3GCZxRs010501; Wed, 16 Apr 2003 14:35:59 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JB3YMSS4; Wed, 16 Apr 2003 14:36:00 +0200 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.31.77]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3GCa0R6017719; Wed, 16 Apr 2003 15:36:00 +0300 (EET DST) Message-ID: <3E9D4E30.78848FFA@lmf.ericsson.se> Date: Wed, 16 Apr 2003 15:36:00 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sipping Subject: Re: [Sipping] Thoughts on GRUUs, URI leasing and embedded route headers References: <3E9D03A7.1090505@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Some initial comments. In general, I don't have any major comments on the solution itself, just some of the technical details. URI wildcarding ----------------- First, RFC3261 allows the "*" character in the URI, but it doesn't say anything about the fact that it should be used for wildcarding only. So, how will the receiver of the LEASE response, and the Leaser header, know if the "*" (the URI MAY even contain multiple "*" characters) is to be used for wildcarding, or if it's simply part of the URI name itself? Before answering this, please read the following question :) Second, if you allow wildcarding, I think it is very important (I assume those who have been working with H.248 agree) to define wildcarding rules. In your example the FIRST character in the URI is used for wildcarding. Can the wildcarding character be elsewhere in the URI? And, to come back to the first question, how does the UAC know which "*" characters are wildcards, and which are parts of the URI name? Register -------- Assume I send a LEASE, but NOT a REGISTER. What will now happen if the proxy receive a Request, destinated to the URI (the wildcard has been replaced with a specific value) it returned in the LEASE response? The reason I ask is because some nodes, especially gateways, do not register - due to well known facts. A gateway can use wildcarded LEASE, but not wildcarded REGISTER (of course, one could say that since gateways most often are static nodes, if GRUU are needed they can be configured in the gateway). In fact, one could even ask: if we now introduce URI wildcarding, and allow it in the LEASE command, should we also introduce wildcarded registering? Just a thought... Regards, Christer Holmberg Ericsson Finland Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > During the San Francisco IETF, there was a lot of discussion on the > concept of a GRUU: > > http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-lease-00.txt > > A GRUU, defined in this I-D, is a URI with the property that it routes > to a specific UA instance. GRUUs are needed for lots of applications, > like assisted call transfer, presence, and 3g/802.11 roaming (a recent > application for a gruu identified on the list). > > During the meeting, there was a lot of confusion on two points, and I > want to continue the dialog over email and attempt to clarify them. > > 1. The I-D talks about temporal scoping. Forget the word temporal. The > idea really is that a UA should be able to manufacture an infinite > supply of URIs that route to itself. In the process of that > manufacturing, it needs to be able to place information into the URI, so > that it can use that information to determine some kind of context when > it receives a call to that URI. As an example, if a UA decides to host a > conference, it needs to manufacture a conference URI that is unique for > that conference, and identifies the conference. > > 2. Getting to specifics, there are really two candidate approaches for > constructing a GRUU. Rohan and Alan advocated the idea of using embedded > Route headers, thusly: > > sip:user@example.com?Route=sip:proxy1.example.com?Route=sip:proxy2.example.com > > A UA would be provisioned with this sequence of routes. > > The idea I was trying to promote in my I-D is that there is another way. > Instead, the UA asks the domain to give it a URI that has the GRUU > property. The domain can populdate the user portion of this URI in such > a way that it provides sufficient context for the domain to route the > request to that UA. THis can be done in a stateless way if the leasing > operation is combined with a registration. So, for example, when a UA > registers thusly: > > REGISTER > To: sip:user@example.com > Contact: sip:1.2.3.4 > > the domain could provide the UA with the following URI in the 200 OK to > REGISTER: > > sip:cookie-user-1.2.3.4@example.com > > When someone sends a request to this URI, the example.com proxy > recognizes this as a GRUU, and sees that what it needs to do is route > the request to user@example.com, at their 1.2.3.4 contact. So, it can > directly send it to 1.2.3.4 from there. > > The key idea is that because the domain is the one manufacturing this > URI, it can construct the user part in any way it likes, including the > inclusion of context to facilitate stateless routing. Now, inclusion of > context for stateless routing is just one approach. If a domain wants, > it can also just create state for each lease. Its a domain policy issue. > > One last point here - the draft also talks about the idea that the URI > returned by the domain can be considered a URI factory. There can be > some kind of wildcard in the URI, which the user can put anything it > wants into it, to give the user context. > > So, which approach is better? I believe that the leasing approach I > propose is the right one. Why? Because a GRUU is a *name*. Names need to > be obtained from the owner of that namespace, especially when you want > the name to be associated with some specific semantic. The first > approach, of embedded route headers, is confusing a name with a route. > It is trying to identify somethign by the way in which you get to it. > > As an example of a consequence of this, the way in which a call is > routed may depend on the caller. For example, a call center may route > calls through some kind of logging server, which are allocated based on > the caller's identity. But, with the embedded Route approach, the route > is bound to the name, so you cannot change it depending on who is calling. > > Comments and criticisms? > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 16 10:31:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03558 for ; Wed, 16 Apr 2003 10:31:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GEdfH26255 for sipping-archive@odin.ietf.org; Wed, 16 Apr 2003 10:39:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GEdf826252 for ; Wed, 16 Apr 2003 10:39:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03525 for ; Wed, 16 Apr 2003 10:30:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195ny9-0001qP-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 10:33:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195ny9-0001qM-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 10:33:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GEYh825065; Wed, 16 Apr 2003 10:34:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GEX1824989 for ; Wed, 16 Apr 2003 10:33:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03241 for ; Wed, 16 Apr 2003 10:23:51 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195nri-0001o5-00 for sipping@ietf.org; Wed, 16 Apr 2003 10:26:22 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 195nri-0001nq-00 for sipping@ietf.org; Wed, 16 Apr 2003 10:26:22 -0400 Received: from cia.cisco.com (IDENT:mirapoint@cia.cisco.com [64.100.238.51]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3GEPmB0018821; Wed, 16 Apr 2003 10:25:49 -0400 (EDT) Received: from mhammer-w2k02.cisco.com (dhcp-hrn-64-100-229-172.cisco.com [64.100.229.172]) by cia.cisco.com (Mirapoint) with ESMTP id ACE89505; Wed, 16 Apr 2003 10:25:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20030416102239.00b59178@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Apr 2003 10:25:46 -0400 To: From: Michael Hammer Subject: Re: [Sipping] Geopriv and SIP current state Cc: hgs@cs.columbia.edu, sipping@ietf.org In-Reply-To: <169.1d3fe7b4.2bce1d9f@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , I haven't seen how this is used yet, but it could have applications where mobility is involved (e.g., calculating whether to handoff between a micro-cellular and a macro-cellular network), and could play a role in E911 services. Mike At 10:44 PM 4/15/2003 -0400, Mpierce1@aol.com wrote: >In a message dated 4/15/2003 10:36:19 AM Eastern Standard Time, >mhammer@cisco.com writes: > > >>There are already standard representations of geolocation and >>geo-velocity. Do you intend to be compatible with those? > > >There's a good one in Q.763 that should suffice for location. I've missed >the point of the requirement for "velocity". > >Mike _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 16 18:51:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20538 for ; Wed, 16 Apr 2003 18:51:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GN0cD31547 for sipping-archive@odin.ietf.org; Wed, 16 Apr 2003 19:00:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GN0c831544 for ; Wed, 16 Apr 2003 19:00:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20532 for ; Wed, 16 Apr 2003 18:51:19 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195vmm-00049d-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 18:53:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195vmm-00049a-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 18:53:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GMuS831397; Wed, 16 Apr 2003 18:56:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GMr2831285 for ; Wed, 16 Apr 2003 18:53:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20435 for ; Wed, 16 Apr 2003 18:43:43 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195vfQ-00048Q-00 for sipping@ietf.org; Wed, 16 Apr 2003 18:46:12 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 195vfP-00048F-00 for sipping@ietf.org; Wed, 16 Apr 2003 18:46:12 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3GMjhB0003270; Wed, 16 Apr 2003 18:45:43 -0400 (EDT) Received: from cisco.com ([161.44.79.220]) by cannon.cisco.com (Mirapoint) with ESMTP id ABH44038; Wed, 16 Apr 2003 18:54:30 -0400 (EDT) Message-ID: <3E9DDD16.9030505@cisco.com> Date: Wed, 16 Apr 2003 18:45:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: Jonathan Rosenberg , sipping Subject: Re: [Sipping] Thoughts on GRUUs, URI leasing and embedded route headers References: <3E9D03A7.1090505@dynamicsoft.com> <3E9D4E30.78848FFA@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christer, I don't know for sure what Jonathan intended, but it isn't necessary to have actual wildcarding for this to work. All that is needed is agreement on a part of the returned URI that may be filled in arbitrary values without altering how requests are routed. Two ways that come to mind that seem suitable are: - when proxy/registrar constructs GRUU, it uses a URL parameter to indicate it is a GRUU and to carry all required context. The username is left empty. The proxy ignores the username field of the URL when routing a request URL containing the GRUU parameter. So the endpoint can construct URLs from the GRUU, using whatever it wants in the username field. - we standardize a URL parameter that the proxy/registrar guarantees to ignore when routing GRUUs. The proxy probably uses the username portion to encode its own context. The endpoint can construct URLS from this GRUU by adding a GRUU parameter containing whatever it wants. I like the first of these better than the second. The registering device would get back a GRUU something like: and then it could use addresses like: Paul Christer Holmberg wrote: > Hi, > > Some initial comments. In general, I don't have any major comments on the solution > itself, just some of the technical details. > > > URI wildcarding > ----------------- > > First, RFC3261 allows the "*" character in the URI, but it doesn't say anything > about the fact that it should be used for wildcarding only. So, how will the > receiver of the LEASE response, and the Leaser header, know if the "*" (the URI > MAY even contain multiple "*" characters) is to be used for wildcarding, or if > it's simply part of the URI name itself? Before answering this, please read the > following question :) > > Second, if you allow wildcarding, I think it is very important (I assume those who > have been working with H.248 agree) to define wildcarding rules. In your example > the FIRST character in the URI is used for wildcarding. Can the wildcarding > character be elsewhere in the URI? And, to come back to the first question, how > does the UAC know which "*" characters are wildcards, and which are parts of the > URI name? > > > Register > -------- > > Assume I send a LEASE, but NOT a REGISTER. What will now happen if the proxy > receive a Request, destinated to the URI (the wildcard has been replaced with a > specific value) it returned in the LEASE response? > > The reason I ask is because some nodes, especially gateways, do not register - due > to well known facts. A gateway can use wildcarded LEASE, but not wildcarded > REGISTER (of course, one could say that since gateways most often are static > nodes, if GRUU are needed they can be configured in the gateway). > > In fact, one could even ask: if we now introduce URI wildcarding, and allow it in > the LEASE command, should we also introduce wildcarded registering? Just a > thought... > > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > Regards, > > Christer Holmberg > Ericsson Finland > > > > Jonathan Rosenberg wrote: > > >>During the San Francisco IETF, there was a lot of discussion on the >>concept of a GRUU: >> >>http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-lease-00.txt >> >>A GRUU, defined in this I-D, is a URI with the property that it routes >>to a specific UA instance. GRUUs are needed for lots of applications, >>like assisted call transfer, presence, and 3g/802.11 roaming (a recent >>application for a gruu identified on the list). >> >>During the meeting, there was a lot of confusion on two points, and I >>want to continue the dialog over email and attempt to clarify them. >> >>1. The I-D talks about temporal scoping. Forget the word temporal. The >>idea really is that a UA should be able to manufacture an infinite >>supply of URIs that route to itself. In the process of that >>manufacturing, it needs to be able to place information into the URI, so >>that it can use that information to determine some kind of context when >>it receives a call to that URI. As an example, if a UA decides to host a >>conference, it needs to manufacture a conference URI that is unique for >>that conference, and identifies the conference. >> >>2. Getting to specifics, there are really two candidate approaches for >>constructing a GRUU. Rohan and Alan advocated the idea of using embedded >>Route headers, thusly: >> >>sip:user@example.com?Route=sip:proxy1.example.com?Route=sip:proxy2.example.com >> >>A UA would be provisioned with this sequence of routes. >> >>The idea I was trying to promote in my I-D is that there is another way. >>Instead, the UA asks the domain to give it a URI that has the GRUU >>property. The domain can populdate the user portion of this URI in such >>a way that it provides sufficient context for the domain to route the >>request to that UA. THis can be done in a stateless way if the leasing >>operation is combined with a registration. So, for example, when a UA >>registers thusly: >> >>REGISTER >>To: sip:user@example.com >>Contact: sip:1.2.3.4 >> >>the domain could provide the UA with the following URI in the 200 OK to >>REGISTER: >> >>sip:cookie-user-1.2.3.4@example.com >> >>When someone sends a request to this URI, the example.com proxy >>recognizes this as a GRUU, and sees that what it needs to do is route >>the request to user@example.com, at their 1.2.3.4 contact. So, it can >>directly send it to 1.2.3.4 from there. >> >>The key idea is that because the domain is the one manufacturing this >>URI, it can construct the user part in any way it likes, including the >>inclusion of context to facilitate stateless routing. Now, inclusion of >>context for stateless routing is just one approach. If a domain wants, >>it can also just create state for each lease. Its a domain policy issue. >> >>One last point here - the draft also talks about the idea that the URI >>returned by the domain can be considered a URI factory. There can be >>some kind of wildcard in the URI, which the user can put anything it >>wants into it, to give the user context. >> >>So, which approach is better? I believe that the leasing approach I >>propose is the right one. Why? Because a GRUU is a *name*. Names need to >>be obtained from the owner of that namespace, especially when you want >>the name to be associated with some specific semantic. The first >>approach, of embedded route headers, is confusing a name with a route. >>It is trying to identify somethign by the way in which you get to it. >> >>As an example of a consequence of this, the way in which a call is >>routed may depend on the caller. For example, a call center may route >>calls through some kind of logging server, which are allocated based on >>the caller's identity. But, with the embedded Route approach, the route >>is bound to the name, so you cannot change it depending on who is calling. >> >>Comments and criticisms? >> >>Thanks, >>Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Scientist Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >>_______________________________________________ >>Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >>This list is for NEW development of the application of SIP >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 16 19:48:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21548 for ; Wed, 16 Apr 2003 19:48:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GNvC502692 for sipping-archive@odin.ietf.org; Wed, 16 Apr 2003 19:57:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GNvC802689 for ; Wed, 16 Apr 2003 19:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21542 for ; Wed, 16 Apr 2003 19:47:51 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195wfV-0004LK-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 19:50:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195wfU-0004LH-00 for sipping-web-archive@ietf.org; Wed, 16 Apr 2003 19:50:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GNrL802600; Wed, 16 Apr 2003 19:53:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GNoV802479 for ; Wed, 16 Apr 2003 19:50:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21486 for ; Wed, 16 Apr 2003 19:41:11 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195wZ2-0004Kp-00 for sipping@ietf.org; Wed, 16 Apr 2003 19:43:40 -0400 Received: from oe33.pav1.hotmail.com ([64.4.30.90] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 195wZ1-0004KU-00 for sipping@ietf.org; Wed, 16 Apr 2003 19:43:40 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 16 Apr 2003 16:43:19 -0700 Received: from 161.44.182.156 by oe33.pav1.hotmail.com with DAV; Wed, 16 Apr 2003 23:43:19 +0000 X-Originating-IP: [161.44.182.156] X-Originating-Email: [sip_developer@hotmail.com] From: "SIP Developer" To: "David R. Oran" Cc: , References: <9107515.1050412371@ORANLT.cisco.com> Subject: Re: [Sipping] Few questions on SIP Protocol Date: Wed, 16 Apr 2003 19:43: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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 16 Apr 2003 23:43:19.0737 (UTC) FILETIME=[F5C0BA90:01C30471] Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks David for the answers. I have few more questions based on your previous answers: a) VRRP provides a 1+1 redundancy at Layer 3 and will have scaling issues. How do you acheive n+k redundancy in SIP networks? b) I haven't read the complete RFC2833 RFC. But I have one generic question which you may answer directly : I know for fact that sending inband DTMF with codecs like G.729 is having issues. How is that handled by RFC2833 ? Is it still a problem with RFC2833 to send DTMF with G.729 codecs? I am assuming that special payload type takes care of it but just need to confirm. When do you prefer SIP INFO method over RFC2833 ? c) I believe SIP SRV will give you failover mechanisms for new calls. Can you tell me how you can preserve calls in progress (signalling + media) on SIP network ? I know for fact that H.323 added a Annex which specifically address this issue for highly available H.323 networks. d) Does SIP protocol provides a mechanism to propogate call context information between cluster of redundant devices ? Thanks for your answers. Rohan Kumar ----- Original Message ----- From: "David R. Oran" To: "SIP Developer" Sent: Tuesday, April 15, 2003 1:12 PM Subject: Re: [Sipping] Few questions on SIP Protocol > > > --On Monday, April 14, 2003 6:14 PM -0400 SIP Developer > wrote: > > > > > > > Hello, > > > > I am new to SIP Protocol. > > > > I am having few questions : > > > > 1) How can a SIP Gateway indicate a "Resource Availability" to SIP Proxy > > or SIP Redirect (similar to RAI mechanism in H.323)? > Look at TGRP. > > > 2) How can an > > endpoint sends DTMF in a reliable way ? Does RFC2833 provides a reliable > > mechanism to send DTMF ? > Yes. > > > How is RFC2833 compared to SIP INFO ? > Info loses all the timing information. > > > 3) Does > > SIP provides a mechanism for failover to backup signaling entity if the > > primary signaling entity fails ? > No. This is the responsibility of other protocols. Look at SIP-SRV, VRRP, > etc. > > > Please also give me pointers to specific documents (if any). > > > > Rohan Kumar > > > > > > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.com > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 17 04:41:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12606 for ; Thu, 17 Apr 2003 04:41:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3H8oeP15739 for sipping-archive@odin.ietf.org; Thu, 17 Apr 2003 04:50:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H8oe815736 for ; Thu, 17 Apr 2003 04:50:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12594 for ; Thu, 17 Apr 2003 04:41:08 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1964zZ-00068z-00 for sipping-web-archive@ietf.org; Thu, 17 Apr 2003 04:43:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1964zZ-00068v-00 for sipping-web-archive@ietf.org; Thu, 17 Apr 2003 04:43:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H8mC815549; Thu, 17 Apr 2003 04:48:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3H8kL815487 for ; Thu, 17 Apr 2003 04:46:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12519 for ; Thu, 17 Apr 2003 04:36:48 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1964vO-000689-00 for sipping@ietf.org; Thu, 17 Apr 2003 04:39:18 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 1964vN-000685-00 for sipping@ietf.org; Thu, 17 Apr 2003 04:39:17 -0400 Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA03345; Thu, 17 Apr 2003 10:39:24 +0200 (MET DST) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id KAA28903; Thu, 17 Apr 2003 10:39:23 +0200 (MET DST) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Apr 2003 10:39:03 +0200 Message-ID: <15A0F4D7BF4DD411BD4C0008C71E2F28019D2E95@mchh233e.mchh.siemens.de> From: Milinski Alexander To: "'Jonathan Rosenberg'" , sipping Subject: RE: [Sipping] Thoughts on GRUUs, URI leasing and embedded route h eaders Date: Thu, 17 Apr 2003 10:38:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Though I have not followed the debate previously, I have a question as follows (and it seems to be independent of the solution chosen): Consider the example of the call transfer: A calls B, and B wishes to transfer the call to C. Here we need a GRUU for A. However, unless A is a prophet, A will not know that B wishes to tranfer the call to C. So what would be A's motivation to use a GRUU? Is it proposed that GRUUs will (almost) ALWAYS be used in the future for outgoing calls? Regards, Alexander Alexander Milinski Siemens -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, April 16, 2003 9:18 AM To: sipping Subject: [Sipping] Thoughts on GRUUs, URI leasing and embedded route headers During the San Francisco IETF, there was a lot of discussion on the concept of a GRUU: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-lease-00.txt A GRUU, defined in this I-D, is a URI with the property that it routes to a specific UA instance. GRUUs are needed for lots of applications, like assisted call transfer, presence, and 3g/802.11 roaming (a recent application for a gruu identified on the list). During the meeting, there was a lot of confusion on two points, and I want to continue the dialog over email and attempt to clarify them. 1. The I-D talks about temporal scoping. Forget the word temporal. The idea really is that a UA should be able to manufacture an infinite supply of URIs that route to itself. In the process of that manufacturing, it needs to be able to place information into the URI, so that it can use that information to determine some kind of context when it receives a call to that URI. As an example, if a UA decides to host a conference, it needs to manufacture a conference URI that is unique for that conference, and identifies the conference. 2. Getting to specifics, there are really two candidate approaches for constructing a GRUU. Rohan and Alan advocated the idea of using embedded Route headers, thusly: sip:user@example.com?Route=sip:proxy1.example.com?Route=sip:proxy2.example.com A UA would be provisioned with this sequence of routes. The idea I was trying to promote in my I-D is that there is another way. Instead, the UA asks the domain to give it a URI that has the GRUU property. The domain can populdate the user portion of this URI in such a way that it provides sufficient context for the domain to route the request to that UA. THis can be done in a stateless way if the leasing operation is combined with a registration. So, for example, when a UA registers thusly: REGISTER To: sip:user@example.com Contact: sip:1.2.3.4 the domain could provide the UA with the following URI in the 200 OK to REGISTER: sip:cookie-user-1.2.3.4@example.com When someone sends a request to this URI, the example.com proxy recognizes this as a GRUU, and sees that what it needs to do is route the request to user@example.com, at their 1.2.3.4 contact. So, it can directly send it to 1.2.3.4 from there. The key idea is that because the domain is the one manufacturing this URI, it can construct the user part in any way it likes, including the inclusion of context to facilitate stateless routing. Now, inclusion of context for stateless routing is just one approach. If a domain wants, it can also just create state for each lease. Its a domain policy issue. One last point here - the draft also talks about the idea that the URI returned by the domain can be considered a URI factory. There can be some kind of wildcard in the URI, which the user can put anything it wants into it, to give the user context. So, which approach is better? I believe that the leasing approach I propose is the right one. Why? Because a GRUU is a *name*. Names need to be obtained from the owner of that namespace, especially when you want the name to be associated with some specific semantic. The first approach, of embedded route headers, is confusing a name with a route. It is trying to identify somethign by the way in which you get to it. As an example of a consequence of this, the way in which a call is routed may depend on the caller. For example, a call center may route calls through some kind of logging server, which are allocated based on the caller's identity. But, with the embedded Route approach, the route is bound to the name, so you cannot change it depending on who is calling. Comments and criticisms? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 17 08:28:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19021 for ; Thu, 17 Apr 2003 08:28:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HCbJQ31311 for sipping-archive@odin.ietf.org; Thu, 17 Apr 2003 08:37:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HCbJ831308 for ; Thu, 17 Apr 2003 08:37:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18980 for ; Thu, 17 Apr 2003 08:27:43 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1968Wq-0007WX-00 for sipping-web-archive@ietf.org; Thu, 17 Apr 2003 08:30:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1968Wq-0007WU-00 for sipping-web-archive@ietf.org; Thu, 17 Apr 2003 08:30:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HCaX830701; Thu, 17 Apr 2003 08:36:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HCX6830550 for ; Thu, 17 Apr 2003 08:33:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18880 for ; Thu, 17 Apr 2003 08:23:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1968Sl-0007V6-00 for sipping@ietf.org; Thu, 17 Apr 2003 08:25:59 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 1968Sk-0007V3-00 for sipping@ietf.org; Thu, 17 Apr 2003 08:25:58 -0400 Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h3HCQ1pT025497 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 17 Apr 2003 08:26:02 -0400 (EDT) Message-ID: <3E9E9D3E.5020301@cs.columbia.edu> Date: Thu, 17 Apr 2003 08:25:34 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: Dean Willis , "'Shane McCormack'" , "'Sipping@Ietf. Org'" Subject: Re: [Sipping] Geopriv and SIP current state References: <003d01c2ff89$bcf2daf0$ee036e3f@txdwillis> <003d01c2ff89$bcf2daf0$ee036e3f@txdwillis> <4.3.2.7.2.20030415101727.00b4f468@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20030415101727.00b4f468@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Yes, at least semantically. (I see no need to mimic a particular bit pattern to, say, encode a binary values as base64 in XML.) Michael Hammer wrote: > Henning, > > There are already standard representations of geolocation and > geo-velocity. Do you intend to be compatible with those? > > Mike _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 18 02:44:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04143 for ; Fri, 18 Apr 2003 02:44:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3I6rhQ23794 for sipping-archive@odin.ietf.org; Fri, 18 Apr 2003 02:53:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I6rh823791 for ; Fri, 18 Apr 2003 02:53:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04131 for ; Fri, 18 Apr 2003 02:43:44 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196PdS-0005Yc-00 for sipping-web-archive@ietf.org; Fri, 18 Apr 2003 02:46:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196PdS-0005YZ-00 for sipping-web-archive@ietf.org; Fri, 18 Apr 2003 02:46:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I6nD823643; Fri, 18 Apr 2003 02:49:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I6mk823615 for ; Fri, 18 Apr 2003 02:48:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04054 for ; Fri, 18 Apr 2003 02:38:48 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196PYf-0005XH-00 for sipping@ietf.org; Fri, 18 Apr 2003 02:41:14 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 196PYf-0005XC-00 for sipping@ietf.org; Fri, 18 Apr 2003 02:41:13 -0400 Received: from dynamicsoft.com ([63.113.46.20]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3I6f0Bd019146; Fri, 18 Apr 2003 02:41:01 -0400 (EDT) Message-ID: <3E9F9DF9.6040504@dynamicsoft.com> Date: Fri, 18 Apr 2003 02:40:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: sipping Subject: Re: [Sipping] Thoughts on GRUUs, URI leasing and embedded route headers References: <3E9D03A7.1090505@dynamicsoft.com> <3E9D4E30.78848FFA@lmf.ericsson.se> In-Reply-To: <3E9D4E30.78848FFA@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > Some initial comments. In general, I don't have any major comments on the solution > itself, just some of the technical details. I appreciate the comments, but I think its way to early to worry about technical details of the sort you are pointing out. We can figure out the right syntax for wildcarding (perhaps along the lines of what Paul suggested). ITs the concept thats important. In fact, it is far more important at this point to discuss whether or not people think this is an important problem, and also whether or not they like the embedded route header or lease approaches. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 18 02:46:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04226 for ; Fri, 18 Apr 2003 02:46:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3I6tt223930 for sipping-archive@odin.ietf.org; Fri, 18 Apr 2003 02:55:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I6tt823927 for ; Fri, 18 Apr 2003 02:55:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04207 for ; Fri, 18 Apr 2003 02:45:57 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Pfb-0005Zm-00 for sipping-web-archive@ietf.org; Fri, 18 Apr 2003 02:48:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196Pfa-0005Zj-00 for sipping-web-archive@ietf.org; Fri, 18 Apr 2003 02:48:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I6s4823838; Fri, 18 Apr 2003 02:54:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I6rv823807 for ; Fri, 18 Apr 2003 02:53:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04135 for ; Fri, 18 Apr 2003 02:43:59 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Pdg-0005Yi-00 for sipping@ietf.org; Fri, 18 Apr 2003 02:46:25 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 196Pdg-0005YX-00 for sipping@ietf.org; Fri, 18 Apr 2003 02:46:24 -0400 Received: from dynamicsoft.com ([63.113.46.20]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3I6kBBd019149; Fri, 18 Apr 2003 02:46:11 -0400 (EDT) Message-ID: <3E9F9F30.4080404@dynamicsoft.com> Date: Fri, 18 Apr 2003 02:46:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Milinski Alexander CC: sipping Subject: Re: [Sipping] Thoughts on GRUUs, URI leasing and embedded route h eaders References: <15A0F4D7BF4DD411BD4C0008C71E2F28019D2E95@mchh233e.mchh.siemens.de> In-Reply-To: <15A0F4D7BF4DD411BD4C0008C71E2F28019D2E95@mchh233e.mchh.siemens.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Milinski Alexander wrote: > Though I have not followed the debate previously, I have a question > as follows (and it seems to be independent of the solution chosen): > Consider the example of the call transfer: A calls B, and B wishes to > transfer the call to C. Here we need a GRUU for A. In this case, you don't need a GRUU. B would send a REFER in-dialog to A, with C's AOR. No GRUU needed. The case where you do need it is assisted call transfer. There, A calls B. A then calls C. A wants to tranfer B to C. This requires A to have a GRUU for C, to send in a REFER to B. > However, unless A > is a prophet, A will not know that B wishes to tranfer the call to C. > So what would be A's motivation to use a GRUU? Is it proposed that > GRUUs will (almost) ALWAYS be used in the future for outgoing calls? Your question is still a valid one in the context of the assisted call transfer case. How does A get the GRUU for C? I believe that the GRUU would need to be included as information associated with the dialog. I had originally thought that UAs would simply use a GRUU in the Contact header of the iNVITE/200 OK, but I think thats a bad idea now. Rather, we would need some kind of new header, like UA-Instance or something, that conveys this. So, if A calls C, A includes a UA-Instance header in their INVITE, and when C answers, C includes one in its 200 OK. You want to do it right away to support features like assisted call transfer, which will need it later on. You don't want to have to explicitly ask the other end for it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 18 12:10:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18298 for ; Fri, 18 Apr 2003 12:10:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IGKcj27218 for sipping-archive@odin.ietf.org; Fri, 18 Apr 2003 12:20:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IGKc827215 for ; Fri, 18 Apr 2003 12:20:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18278 for ; Fri, 18 Apr 2003 12:10:27 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196YTu-0000MX-00 for sipping-web-archive@ietf.org; Fri, 18 Apr 2003 12:12:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196YTt-0000MT-00 for sipping-web-archive@ietf.org; Fri, 18 Apr 2003 12:12:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IGIa826910; Fri, 18 Apr 2003 12:18:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IG4x825408 for ; Fri, 18 Apr 2003 12:04:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17824 for ; Fri, 18 Apr 2003 11:54:48 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196YEl-0000IW-00 for sipping@ietf.org; Fri, 18 Apr 2003 11:57:15 -0400 Received: from petasus.ch.intel.com ([143.182.124.5]) by ietf-mx with esmtp (Exim 4.12) id 196YEk-0000IN-00 for sipping@ietf.org; Fri, 18 Apr 2003 11:57:14 -0400 Received: from azsmsxvs040.ch.intel.com (azsmsxvs040.ch.intel.com [10.2.248.11]) by petasus.ch.intel.com (8.11.6p2/8.11.6/d: solo.mc,v 1.49 2003/01/13 19:45:39 dmccart Exp $) with SMTP id h3IFulP22631 for ; Fri, 18 Apr 2003 15:56:47 GMT Received: from azsmsx023.ch.intel.com ([10.2.248.28]) by azsmsxvs040.ch.intel.com (NAVGW 2.5.2.11) with SMTP id M2003041808565829273 for ; Fri, 18 Apr 2003 08:56:58 -0700 Received: by azsmsx023.ch.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Apr 2003 08:52:12 -0700 Message-ID: <3D90571297ABD511957400508BF29C43043EA72D@pysmsx101.py.intel.com> From: "Miao, Kai" To: "'sipping@ietf.org'" Date: Fri, 18 Apr 2003 09:05:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sipping] Draft of SIP Telephony Device Requirements Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Henry, Sorry for the big delay for (re)sending these comments on the SIP device drafts to this list: 1) SIP devices with an analog user front-end probably need to be singled out in someway. For example, the document mentioned the T.38 only applies to this type of SIP devices, but does not include other differences with them such as echo cancellation, tone detection, tone generation, etc. 2) In "IP requirements", it does not mentioned ICMP, nor IGMP amd multicast. These probably should be at least "may" items? 3) This document only mentions DTMFs and ringback for tone support. There can be other tones which may also be required, such as call progress tones transferred over via RFC2833 when a call comes from a IP-PSTN gateway, dial tone when a user first "picks up" the device, etc. In addition, tones may also be transported "out of band" via signaling channel (using, for example, SIP INFO method), has this been intentionally left out? 4) For multi-line support, it does not mention if a call or even a conference can be established between the lines. I like the local mixing requirement for two or more parties from the network. But it is not clear to me how such mixing capability relates to the local multiple lines that are available. 5) I didn't any see volume control and level control mentioned anywhere. Is something like ALC (G.169) required for SIP devices. 6) The silence suppression related statements in the document do not seem to be clear to me. RFC 3389 specifies for RTP comfort noise payload format only for codecs like G.711, G.726, G.722, etc. Exactly the same applies to G.711 Annex II. For codecs like G.729 and G.723.1, CNG/VAD is internally defined (see RFC1890). 7) I am also wondering why there is no mention of anything related to delay variation (netwrk jitter) compensention. Is PLC (G.711 annex I) reqquired? 8) SIP security is mentioned in the document, not media security. Is SRTP required? Best Regards, Kai _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 21 07:54:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11228 for ; Mon, 21 Apr 2003 07:54:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3LC5rf23831 for sipping-archive@odin.ietf.org; Mon, 21 Apr 2003 08:05:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LC5q823828 for ; Mon, 21 Apr 2003 08:05:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11122 for ; Mon, 21 Apr 2003 07:54:19 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197Zuc-00078E-00 for sipping-web-archive@ietf.org; Mon, 21 Apr 2003 07:56:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 197Zub-00078A-00 for sipping-web-archive@ietf.org; Mon, 21 Apr 2003 07:56:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LC4F823710; Mon, 21 Apr 2003 08:04:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LBoO822937 for ; Mon, 21 Apr 2003 07:50:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09946 for ; Mon, 21 Apr 2003 07:38:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197Zfe-0006s2-00 for sipping@ietf.org; Mon, 21 Apr 2003 07:41:14 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 197Zfe-0006rz-00 for sipping@ietf.org; Mon, 21 Apr 2003 07:41:14 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3LBfUI3006283; Mon, 21 Apr 2003 13:41:30 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JDV2B8QS; Mon, 21 Apr 2003 13:41:31 +0200 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3LBfVR6018722; Mon, 21 Apr 2003 14:41:31 +0300 (EET DST) Message-ID: <3EA3D915.DBDC44BB@lmf.ericsson.se> Date: Mon, 21 Apr 2003 14:42:13 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sipping Subject: Re: [Sipping] Thoughts on GRUUs, URI leasing and embedded route headers References: <3E9D03A7.1090505@dynamicsoft.com> <3E9D4E30.78848FFA@lmf.ericsson.se> <3E9F9DF9.6040504@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > >Some initial comments. In general, I don't have any major comments on the >solution > itself, just some of the technical details. > > I appreciate the comments, but I think its way to early to worry about > technical details of the sort you are pointing out. We can figure out > the right syntax for wildcarding (perhaps along the lines of what Paul > suggested). ITs the concept thats important. In fact, it is far more > important at this point to discuss whether or not people think this is > an important problem, and also whether or not they like the embedded > route header or lease approaches. I agree with what you say. I just thought I'd bring the issue up, in case the wildcarding would be an essentintial part of your proposed solution. But, as Paul said, it MAY not be needed in the first place... Some functional comments, though: To make this work, it is assumed that requests sent in the backward direction really will be directed via the proxy which issued the leased URI (unless the proxy is able to "share" the information with other proxies). So, won't we have the same problem with the Record-Route URI that you now try to solve for the Contact URI - ie we want to make sure that requests reach a specific node, and not just any node within a specific user domain? Regards, Christer Holmberg Ericsson Finland Regards, Christer Holmberg Ericsson Finland > > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 22 02:01:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17564 for ; Tue, 22 Apr 2003 02:01:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3M6D2q06861 for sipping-archive@odin.ietf.org; Tue, 22 Apr 2003 02:13:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M6D2806858 for ; Tue, 22 Apr 2003 02:13:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17020 for ; Tue, 22 Apr 2003 02:01:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197qsK-0006W3-00 for sipping-web-archive@ietf.org; Tue, 22 Apr 2003 02:03:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 197qsK-0006Vx-00 for sipping-web-archive@ietf.org; Tue, 22 Apr 2003 02:03:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M6Bj803502; Tue, 22 Apr 2003 02:11:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FEeM808627 for ; Tue, 15 Apr 2003 10:40:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29571 for ; Tue, 15 Apr 2003 10:31:43 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195RVl-0002ny-00 for sipping@ietf.org; Tue, 15 Apr 2003 10:34:13 -0400 Received: from crufty.research.bell-labs.com ([204.178.16.49]) by ietf-mx with esmtp (Exim 4.12) id 195RVl-0002nv-00 for sipping@ietf.org; Tue, 15 Apr 2003 10:34:13 -0400 Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h3FEYF9Y022708; Tue, 15 Apr 2003 10:34:15 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h3FEY8c6063082; Tue, 15 Apr 2003 10:34:09 -0400 (EDT) Received: from bell-labs.com (volker-hopc [135.180.240.186]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h3FEY8Q4023652; Tue, 15 Apr 2003 10:34:08 -0400 (EDT) Message-ID: <3E9C17D5.6030407@bell-labs.com> Date: Tue, 15 Apr 2003 10:31:49 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sipping , Henning Schulzrinne Subject: Re: [Sipping] Re: dialog event package: event code References: <3E9B19F3.5090505@bell-labs.com> <3E9B6EEA.3030207@dynamicsoft.com> In-Reply-To: <3E9B6EEA.3030207@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > responses inline. > > Volker Hilt wrote: > >> Hi all, >> >> I don't know if the following issue has already been discussed on the >> list. >> >> The dialog event package defines a way of reporting dialog state to >> another user. The dialog information format (the default payload format >> for dialog event NOTIFYs) contains information about the current dialog >> state and it may provide information about the event that has caused >> the state transition. Here's what the draft says: >> >> 3.1.2 State >> >> The state element indicates the state of the dialog. Its value is an >> enumerated type describing one of the states in the FSM above. It has >> an optional event attribute that can be used to indicate the event >> which caused the transition into the current state, and an optional >> code attribute that indicates the response code associated with the >> transition, assuming the event was 1xx-tag, 1xx-notag, or 2xx. >> >> My question refers to the last sentence of this section: what is the >> reason for restricting the reporting of response codes to 1xx and 2xx >> events? Wouldn't it make sense to also allow the reporting of response >> codes for rejected events and possibly also for error and timeout >> events? (Btw. the schema definition already allows codes between 100 and >> 699.) > > I can't think of a particularly good reason, to be honest. I think it > would be fine to include the response code for any event caused by a > response. I'll make the change in the next rev (which is probably going > to be the result of AD comments, as I believe this doc is ready to go to > IESG). Great! Thanks, Volker -- Volker Hilt Bell Labs / Lucent Technologies phone: +1 732 332 6432 101 Crawfords Corner Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 22 05:03:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00776 for ; Tue, 22 Apr 2003 05:03:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3M9EuD21047 for sipping-archive@odin.ietf.org; Tue, 22 Apr 2003 05:14:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M9Eu821044 for ; Tue, 22 Apr 2003 05:14:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00762 for ; Tue, 22 Apr 2003 05:02:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197tiI-0007VS-00 for sipping-web-archive@ietf.org; Tue, 22 Apr 2003 05:05:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 197tiI-0007VM-00 for sipping-web-archive@ietf.org; Tue, 22 Apr 2003 05:05:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M94b819890; Tue, 22 Apr 2003 05:04:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M93G819844 for ; Tue, 22 Apr 2003 05:03:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00561 for ; Tue, 22 Apr 2003 04:51:18 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197tX1-0007Sz-00 for sipping@ietf.org; Tue, 22 Apr 2003 04:53:39 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 197tX0-0007Sv-00 for sipping@ietf.org; Tue, 22 Apr 2003 04:53:38 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3M8rx707308 for ; Tue, 22 Apr 2003 11:53:59 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 22 Apr 2003 11:53:59 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Apr 2003 11:53:59 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 22 Apr 2003 11:53:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sipping] Thoughts on GRUUs, URI leasing and embedded route headers Date: Tue, 22 Apr 2003 11:53:58 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194522A@esebe013.ntc.nokia.com> Thread-Topic: [Sipping] Thoughts on GRUUs, URI leasing and embedded route headers Thread-Index: AcMD6YJ4vHj1Ox72T4yVAPbYcKVcLwEwlZ2Q To: , X-OriginalArrivalTime: 22 Apr 2003 08:53:59.0303 (UTC) FILETIME=[B6EF2970:01C308AC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3M93G819845 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, I agree on the concept that a GRUU needs to be a name rather than a route. I also have a wild idea to throw into this thread. In the message-sessions work, the MSRP relays have a very similar function to perform, namely getting a unique "end-point-ID" with the BIND request. What if we consider this to be another use case for leasing a GRUU? The only difference would be that the UA would basically be leasing an MSRP URI, and not a SIP URI. Cheers, Aki > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 16 April, 2003 10:18 > To: sipping > Subject: [Sipping] Thoughts on GRUUs, URI leasing and embedded route > headers > > > During the San Francisco IETF, there was a lot of discussion on the > concept of a GRUU: > > http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-l > ease-00.txt > > A GRUU, defined in this I-D, is a URI with the property that > it routes > to a specific UA instance. GRUUs are needed for lots of > applications, > like assisted call transfer, presence, and 3g/802.11 roaming > (a recent > application for a gruu identified on the list). > > During the meeting, there was a lot of confusion on two > points, and I > want to continue the dialog over email and attempt to clarify them. > > 1. The I-D talks about temporal scoping. Forget the word > temporal. The > idea really is that a UA should be able to manufacture an infinite > supply of URIs that route to itself. In the process of that > manufacturing, it needs to be able to place information into > the URI, so > that it can use that information to determine some kind of > context when > it receives a call to that URI. As an example, if a UA > decides to host a > conference, it needs to manufacture a conference URI that is > unique for > that conference, and identifies the conference. > > 2. Getting to specifics, there are really two candidate > approaches for > constructing a GRUU. Rohan and Alan advocated the idea of > using embedded > Route headers, thusly: > > sip:user@example.com?Route=sip:proxy1.example.com?Route=sip:p > roxy2.example.com > > A UA would be provisioned with this sequence of routes. > > The idea I was trying to promote in my I-D is that there is > another way. > Instead, the UA asks the domain to give it a URI that has the GRUU > property. The domain can populdate the user portion of this > URI in such > a way that it provides sufficient context for the domain to > route the > request to that UA. THis can be done in a stateless way if > the leasing > operation is combined with a registration. So, for example, > when a UA > registers thusly: > > REGISTER > To: sip:user@example.com > Contact: sip:1.2.3.4 > > the domain could provide the UA with the following URI in > the 200 OK to > REGISTER: > > sip:cookie-user-1.2.3.4@example.com > > When someone sends a request to this URI, the example.com proxy > recognizes this as a GRUU, and sees that what it needs to do > is route > the request to user@example.com, at their 1.2.3.4 contact. > So, it can > directly send it to 1.2.3.4 from there. > > The key idea is that because the domain is the one > manufacturing this > URI, it can construct the user part in any way it likes, > including the > inclusion of context to facilitate stateless routing. Now, > inclusion of > context for stateless routing is just one approach. If a > domain wants, > it can also just create state for each lease. Its a domain > policy issue. > > One last point here - the draft also talks about the idea > that the URI > returned by the domain can be considered a URI factory. There can be > some kind of wildcard in the URI, which the user can put anything it > wants into it, to give the user context. > > > So, which approach is better? I believe that the leasing approach I > propose is the right one. Why? Because a GRUU is a *name*. > Names need to > be obtained from the owner of that namespace, especially > when you want > the name to be associated with some specific semantic. The first > approach, of embedded route headers, is confusing a name > with a route. > It is trying to identify somethign by the way in which you get to it. > > As an example of a consequence of this, the way in which a call is > routed may depend on the caller. For example, a call center > may route > calls through some kind of logging server, which are > allocated based on > the caller's identity. But, with the embedded Route > approach, the route > is bound to the name, so you cannot change it depending on > who is calling. > > Comments and criticisms? > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 22 10:28:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11585 for ; Tue, 22 Apr 2003 10:28:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3MEeTN10164 for sipping-archive@odin.ietf.org; Tue, 22 Apr 2003 10:40:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEeS810158 for ; Tue, 22 Apr 2003 10:40:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11546 for ; Tue, 22 Apr 2003 10:28:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197ynE-00027D-00 for sipping-web-archive@ietf.org; Tue, 22 Apr 2003 10:30:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 197ynE-000277-00 for sipping-web-archive@ietf.org; Tue, 22 Apr 2003 10:30:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MEdN810005; Tue, 22 Apr 2003 10:39:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3METi808735 for ; Tue, 22 Apr 2003 10:29:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11269 for ; Tue, 22 Apr 2003 10:17:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197ycq-00023O-00 for sipping@ietf.org; Tue, 22 Apr 2003 10:20:00 -0400 Received: from radvmail.radvision.com ([12.44.63.10] helo=radvpost.RADVISION.com) by ietf-mx with esmtp (Exim 4.12) id 197ycp-00023L-00 for sipping@ietf.org; Tue, 22 Apr 2003 10:19:59 -0400 Received: by radvpost.radvision.com with Internet Mail Service (5.5.2653.19) id <2JB4H9GC>; Tue, 22 Apr 2003 10:18:14 -0400 Message-ID: From: Orit Levin To: "'Eric Burger'" , "Sipping (E-mail)" Subject: RE: [Sipping] conf: comments on draft-levin-sipping-conferencing- requirements-03 Date: Tue, 22 Apr 2003 10:18:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Eric, Thanks a lot for the detailed review. I am addressing your notes inline (and in the upcoming SIPPING 00 version of the draft). Orit. > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Tuesday, March 25, 2003 11:22 AM > To: Sipping (E-mail) > Subject: [Sipping] conf: comments on draft-levin-sipping-conferencing- > requirements-03 > > Section 2 > "Each dialog can belong to a different SIP session." > ^^^ "Can", "Does", "May or May Not"? > Pick one. Explain choice. I tend to remove this vague sentence and say: "... focus has direct peer-wise relationships with participants by maintaining a separate SIP dialog with each." "Dialog" is a technical SIP concept. "Session" is not. > > "...media sessions are established between the focus and each one of the > participants" > I would offer that *signaling* (e.g., SIP) sessions are established > between the focus and the participants. However, I would also offer that > it is rare for *media* (e.g., RTP) sessions to be between the focus and > the participants. > The full quote goes as following: "In centralized case, the media sessions are established between the focus and each one of the participants. In de-centralized (i.e. distributed) case, the media graph is a (multicast or multi-unicast) mesh among the participants..." We prefer not to state any preference for one way or another because, based on our discussions, both exist and valid. > > Section 3.2 > I do not understand the explicitly requirements families, "X with default > properties" and "X with particular properties." How about: > REQ-1 Creation of an ad-hoc conference identifier with specified > properties. > REQ-2 Creation of a reserved conference identifier with specified > properties. > REQ-3 Properties for conference creation may have well-defined (standard) > defaults.* > Your understanding is absolutely correct. I think your wording is better and will use it in the next version. > * Do we want to have well-defined defaults? Why or why not? > Yes, we do want to have this ability as a part of the architecture: one entity can define profiles or a default, another entity can create a conference without specifying its parameters. Immediate examples would be creating conferences by light end devices and by conference-unaware devices. > > Section 3.4.6 > REQ-1 has implications for RTP/RTCP which I would suggest get spelt out. > E.g., the mixer MUST anonymize the CSRC text, etc. > Very good point! What about the following wording: "The privacy related requirements imply that "anonymizing" operations MUST be performed on all: the call control, the media control and the media content when appropriate." We can't go into the media details in this document - they should be captured by the media-related drafts. > > Section 3.5.1 > REQ-3 > What are conference state elements? Conference state elements are "evolving conference state aspects" as described in the section. For example: "the current speaker". Would changing "elements" to "aspects" help in understanding the requirement? Other suggestions? > > REQ-4 > Is this requirement that there is a minimal state, or that there is a > minimal state report, e.g., the list of public participants (cf. 3.4.6 > REQ-1). It is the minimal state report. Done: I added "report" for clarification. From the standardization work perspective - they are the same - only what goes on the wire is of our interest. > > > Section 3.5.2 > REQ-1 > Would not the "including" phrase be for non-participants? Of course > conference participants are interested parties. > Done :-) Thanks. > REQ-5 > Again, what is meant by "state" here? Is it state or reporting? > Done: "Report". > > Section 3.7 > REQ-1 highlights why a side bar URI MUST be distinct from the conference > URI. If it was the same, it would not be possible for a non-participant > to address the side bar. 3.7 REQ-1 merely says that a non-participant can participate in a side-bar using SIP means only. The implementation of this requirement doesn't necessary require a different URI. The user can potentially be limited to participate in a side-bar by an ACL maintained (by non-SIP means) in the focus. I suggest putting the side-bar discussion on hold till a draft dedicated to side-bars will be available soon (before the IETF meeting). > > REQ-6 > Isn't the logical requirement of a conference-unaware user agent be that > SIP means MUST be the ONLY *standard* method for side bar operations? If > a conference-unaware user agent knows non-SIP means, it mean, BY > DEFINITION, that it *IS* conference-aware. We are entering a slippery ground here :-) 1. A conference-aware participant by definition (in the framework) MUST have a SIP conference-aware UA (as defined in cc-conferencing). 2. This conference-aware participant MAY use additional non-SIP means in order to host/participate in a conference, such as for side-bars. > > REQ-7 > What is the perceived value of not establishing a distinct side-bar URI? > Also, this contradicts REQ-1. Please, refer to the note for REQ-1 above. > > REQ-8 and REQ-9 > What does it mean to be a participant in multiple side-bars? How would a > UAC manage multiple side-bars if they are not multiple SIP dialogs? One potential application would be participating in a number of IM discussions all belonging to the same public conference. The simplistic answer - by non-SIP means. The real answer - in the draft to be published. > > > > > > > Typo > Section 3.5.3, last line > "information, it wants and capable to receive" > "information it wants and capable to receive" > ^ Done. > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 23 02:04:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13462 for ; Wed, 23 Apr 2003 02:04:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3N6GCL24660 for sipping-archive@odin.ietf.org; Wed, 23 Apr 2003 02:16:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6GB824657 for ; Wed, 23 Apr 2003 02:16:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12941 for ; Wed, 23 Apr 2003 02:03:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198DOR-0000F7-00 for sipping-web-archive@ietf.org; Wed, 23 Apr 2003 02:06:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198DOR-0000F3-00 for sipping-web-archive@ietf.org; Wed, 23 Apr 2003 02:06:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6FD824613; Wed, 23 Apr 2003 02:15:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6Ej824477 for ; Wed, 23 Apr 2003 02:14:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11434 for ; Wed, 23 Apr 2003 02:02:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198DN3-0000Ee-00 for sipping@ietf.org; Wed, 23 Apr 2003 02:04:41 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 198DN3-0000Eb-00 for sipping@ietf.org; Wed, 23 Apr 2003 02:04:41 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3N64bdh000764; Wed, 23 Apr 2003 02:04:38 -0400 (EDT) Message-ID: <3EA62CED.7070200@dynamicsoft.com> Date: Wed, 23 Apr 2003 02:04:29 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christer Holmberg CC: sipping Subject: Re: [Sipping] Thoughts on GRUUs, URI leasing and embedded route headers References: <3E9D03A7.1090505@dynamicsoft.com> <3E9D4E30.78848FFA@lmf.ericsson.se> <3E9F9DF9.6040504@dynamicsoft.com> <3EA3D915.DBDC44BB@lmf.ericsson.se> In-Reply-To: <3EA3D915.DBDC44BB@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Christer Holmberg wrote: > Some functional comments, though: > > To make this work, it is assumed that requests sent in the backward > direction really will be directed via the proxy which issued the > leased URI (unless the proxy is able to "share" the information with > other proxies). So, won't we have the same problem with the > Record-Route URI that you now try to solve for the Contact URI - ie > we want to make sure that requests reach a specific node, and not > just any node within a specific user domain? No. Just because I ask a specific server for a URI that is routable in the domain, does not meant that requests have to go to that specific server. It is a requirement on the administrator of the domain to guarantee that the URI will route to the UA instance when used by anyone from anywhere. This will frequently require coordinated routing policies throughout the domain. Thats fine. Thats why you need to ask for the name - to make sure what you get is consistent with those routing policies. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 23 02:07:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17119 for ; Wed, 23 Apr 2003 02:07:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3N6Jnm24814 for sipping-archive@odin.ietf.org; Wed, 23 Apr 2003 02:19:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6Jn824811 for ; Wed, 23 Apr 2003 02:19:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16596 for ; Wed, 23 Apr 2003 02:07:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198DRx-0000GK-00 for sipping-web-archive@ietf.org; Wed, 23 Apr 2003 02:09:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198DRw-0000GH-00 for sipping-web-archive@ietf.org; Wed, 23 Apr 2003 02:09:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6J5824761; Wed, 23 Apr 2003 02:19:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N6IM824724 for ; Wed, 23 Apr 2003 02:18:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15113 for ; Wed, 23 Apr 2003 02:05:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198DQY-0000Fl-00 for sipping@ietf.org; Wed, 23 Apr 2003 02:08:18 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 198DQX-0000FW-00 for sipping@ietf.org; Wed, 23 Apr 2003 02:08:17 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3N68Edh000768; Wed, 23 Apr 2003 02:08:14 -0400 (EDT) Message-ID: <3EA62DC6.9000704@dynamicsoft.com> Date: Wed, 23 Apr 2003 02:08:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: sipping@ietf.org Subject: Re: [Sipping] Thoughts on GRUUs, URI leasing and embedded route headers References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194522A@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194522A@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > Hi, > > I agree on the concept that a GRUU needs to be a name rather than a > route. > > I also have a wild idea to throw into this thread. In the > message-sessions work, the MSRP relays have a very similar function > to perform, namely getting a unique "end-point-ID" with the BIND > request. What if we consider this to be another use case for leasing > a GRUU? The only difference would be that the UA would basically be > leasing an MSRP URI, and not a SIP URI. Heh. Indeed, the idea for using a leasing concept to solve the GRUU problem arose out of my involvement in the message sessions stuff, so there is a relationship in that regard. That said, its actually quite important that the leasing operation be combinable with registration, since this enables stateless construction of GRUU. That would mean that a unified leasing protocol would need to also be integrated with the existing SIP registration system. Thus, it is not as independent as you would like it to be. Simplicity would argue for adding the leasing operation as part of registration, and I'd rather do that than try and combine it with MSRP binding. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 23 10:31:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20897 for ; Wed, 23 Apr 2003 10:31:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NEh9630672 for sipping-archive@odin.ietf.org; Wed, 23 Apr 2003 10:43:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NEh9830669 for ; Wed, 23 Apr 2003 10:43:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20856 for ; Wed, 23 Apr 2003 10:30:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198LIs-0004HF-00 for sipping-web-archive@ietf.org; Wed, 23 Apr 2003 10:32:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198LIs-0004HC-00 for sipping-web-archive@ietf.org; Wed, 23 Apr 2003 10:32:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NEai829413; Wed, 23 Apr 2003 10:36:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NEZ3829332 for ; Wed, 23 Apr 2003 10:35:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20621 for ; Wed, 23 Apr 2003 10:22:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198LB3-0004En-00 for sipping@ietf.org; Wed, 23 Apr 2003 10:24:49 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 198LB2-0004Eh-00 for sipping@ietf.org; Wed, 23 Apr 2003 10:24:48 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3NEP6I3029838; Wed, 23 Apr 2003 16:25:06 +0200 (MEST) Received: from hendrix.lmf.ericsson.se ([131.160.11.8]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JQAFVKT0; Wed, 23 Apr 2003 16:25:07 +0200 Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.31.77]) by hendrix.lmf.ericsson.se (8.12.8/8.12.8/lmf-2.1-jcs) with ESMTP id h3NEP7R6022982; Wed, 23 Apr 2003 17:25:08 +0300 (EET DST) Message-ID: <3EA6A278.C21C0D95@lmf.ericsson.se> Date: Wed, 23 Apr 2003 17:26:00 +0300 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Christer Holmberg X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sipping Subject: Re: [Sipping] Thoughts on GRUUs, URI leasing and embedded route headers References: <3E9D03A7.1090505@dynamicsoft.com> <3E9D4E30.78848FFA@lmf.ericsson.se> <3E9F9DF9.6040504@dynamicsoft.com> <3EA3D915.DBDC44BB@lmf.ericsson.se> <3EA62CED.7070200@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > >To make this work, it is assumed that requests sent in the backward > >direction really will be directed via the proxy which issued the > >leased URI (unless the proxy is able to "share" the information with > >other proxies). So, won't we have the same problem with the > >Record-Route URI that you now try to solve for the Contact URI - ie > >we want to make sure that requests reach a specific node, and not > >just any node within a specific user domain? > > No. > > Just because I ask a specific server for a URI that is routable in the > domain, does not meant that requests have to go to that specific server. > It is a requirement on the administrator of the domain to guarantee > that the URI will route to the UA instance when used by anyone from > anywhere. This will frequently require coordinated routing policies > throughout the domain. Thats fine. Thats why you need to ask for the > name - to make sure what you get is consistent with those routing policies. Ok, but assume that proxy A still wants a request to be sent via it. Now, it can do so by inserting its IP address in the Record-Route URI, but aren't the problems them the same as if the UA would insert its IP address in the Contact? My question basically is: should it only be possible for UAs to obtain a GRUU, or should it also be possible for proxies? I know your draft only talks about UAs, so proxies may be out of the scope of it, but I would still like to raise the question. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 24 10:17:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17931 for ; Thu, 24 Apr 2003 10:17:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OEJnT13674 for sipping-archive@odin.ietf.org; Thu, 24 Apr 2003 10:19:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEJn813671 for ; Thu, 24 Apr 2003 10:19:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17920 for ; Thu, 24 Apr 2003 10:16:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198hYw-0006AM-00 for sipping-web-archive@ietf.org; Thu, 24 Apr 2003 10:18:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198hYw-0006AI-00 for sipping-web-archive@ietf.org; Thu, 24 Apr 2003 10:18:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEI3813583; Thu, 24 Apr 2003 10:18:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OEGu813525 for ; Thu, 24 Apr 2003 10:16:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17667 for ; Thu, 24 Apr 2003 10:13:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198hWA-00069J-00 for sipping@ietf.org; Thu, 24 Apr 2003 10:16:06 -0400 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 198hW9-00069G-00 for sipping@ietf.org; Thu, 24 Apr 2003 10:16:05 -0400 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 9493; Thu, 24 Apr 2003 10:18:16 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 24 Apr 2003 10:18:08 -0400 Message-ID: <4A3384433CE2AB46A63468CB207E209D2DFA07@zoe.office.snowshore.com> Thread-Topic: conf: comments on draft-koskelainen-sipping-conf-policy-req-00 Thread-Index: AcMKSRjZvi8TNttaRs2Dwo2CWASTYgAIyYTQ From: "Eric Burger" To: "Petri K. Koskelainen" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3OEGu813526 Subject: [Sipping] RE: conf: comments on draft-koskelainen-sipping-conf-policy-req-00 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit All sounds good. Let's look at the open issue: > -----Original Message----- From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu] [snip] > > REQ-A6 > > What does it mean to terminate the conference instance > > but keep the conference URI and attributes? > > What I meant was that the current conference instance is terminated, > but the name (SIP URI) itself remains and the conference > (with that SIP URI) may be restarted or reactivated later. > Does this kind of feature makes any sense? > > Anyway, it seems that this feature is already possible without Req-A6 > since req-A2 already says that it must be possible to associate > policy attributes to a conference URI (and one attribute is > active/inactive). So, it is possibly to turn "inactive" > attribute on, which effectively means the same. > > Should we also specify in this document what exactly should happen > when the conference mode changes to "inactive"? > (For example, are users kicked-out > or just put on hold, what happens to ACL-lists etc). > I assume that static policy data (e.g. ACL lists) remain as is > but it is always possible to clear all policy data when reactivating > the conference. I guess it depends on why you want to have a name without a conference. If it is to be able to have a reserved conference, then yes, everyone gets kicked out when the mode becomes inactive. _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 24 10:59:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18948 for ; Thu, 24 Apr 2003 10:59:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OF2Pr16564 for sipping-archive@odin.ietf.org; Thu, 24 Apr 2003 11:02:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OF2P816561 for ; Thu, 24 Apr 2003 11:02:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18930 for ; Thu, 24 Apr 2003 10:59:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198iEA-0006Ok-00 for sipping-web-archive@ietf.org; Thu, 24 Apr 2003 11:01:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198iE9-0006Oh-00 for sipping-web-archive@ietf.org; Thu, 24 Apr 2003 11:01:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OF1H816462; Thu, 24 Apr 2003 11:01:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OF0s816395 for ; Thu, 24 Apr 2003 11:00:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18889 for ; Thu, 24 Apr 2003 10:57:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198iCg-0006Ng-00 for sipping@ietf.org; Thu, 24 Apr 2003 11:00:02 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 198iCg-0006NS-00 for sipping@ietf.org; Thu, 24 Apr 2003 11:00:02 -0400 Received: from dynamicsoft.com ([63.113.46.50]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3OF01dh001593; Thu, 24 Apr 2003 11:00:01 -0400 (EDT) Message-ID: <3EA7FBED.7000701@dynamicsoft.com> Date: Thu, 24 Apr 2003 10:59:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger CC: "Sipping (E-mail)" Subject: Re: [Sipping] conf: comments on draft-rosenberg-sipping-conferencing-framework-01 References: <4A3384433CE2AB46A63468CB207E209D097C33@zoe.office.snowshore.com> In-Reply-To: <4A3384433CE2AB46A63468CB207E209D097C33@zoe.office.snowshore.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My apologies for the delay in responding. Thanks for your comments. Responses inline. Eric Burger wrote: > Section 2, Mixer "A mixer receives a set of media streams of the same > type..." What about a conference with Audio/Video streams as well as > Audio-only streams. The first sentence seems a bit limiting without > any added value. THe idea is that a conference would just have multiple mixers if there were multiple media types. Its really just a matter of definition about whether a mixer is single or multiple media. Some folks on the design team felt strongly that it should be a single media per mixer. > > Section 3.1, 4th & 5th paragraphs The example URI > ("discussion-on-dogs@example.com") would seem to contradict the > admonition that "a conference URI is never constructed or guessed by > a user." The key point is the conference URI is opaque. It could > mean something, or it could be a license plate. Requiring meaning is > BAD. Requiring obscuration is also BAD. Just leave it as opaque to > the framework. Having a URI with a mnemonic user part does not mean its no longer opaque to the system, no longer unique, or that the intent is for it to be guessed. For long lived conferences in particular, where there is a likelihood that someone will need to convey one over a phone, I see value in them being mnemonic. > > Section 4.4 I would offer that the state of the focus is something > quite distinct from the conference policy. Moreover, different > actors have different interests and permissions to access these two > disparate information items. Thus I would offer that separate > notification services tend to each. That is, one (package) for the > state of the focus and one (package) for the conference policy. The design team has debated this issue heavily. At the time of the writing of the framework, we hadnt really decided, and so the wording was made vague so as to allow the decision to be made later. Since then, we have agreed on an approach. The idea is to have a single package, but to use an event parameter to indicate whether or not you would want only the focus state or the policy state. A single package avoids the waste of managing two subscriptions in the common case of endpoints that want both. Here is the updated text to clarify: This state is composed of two separate pieces. The first is the state of the focus and the second is the conference policy. A subscriber to the conference notification service can use capabilities defined in the SIP events framework \citenonnorm{rfc3265} to request that it receive focus state changes only, conference policy changes only, or both. > > Section 5.1 I am not comfortable saying "the creation of a conference > actually constructs several elements." In reality, the elements > described by the framework rarely exist. Rather, there are virtual > implementations. For example, most policy servers are hard coded > into the application logic. There are not separate policy servers > today, and likely into the future. The text is not saying that a policy SERVER is constructed, its saying that an instance of the conference policy and focus are created. In a real implementation, this would manifest itself as the addition of a row in a table or something. I clarified the definitions of conference and media policy to make it clear that these were per-conference. > > Section 5.1 Would a better example of deterministic URI generation be > algorithmic? Keeping records of URIs only helps me be unique within > me. It doesn't help me be globally unique. Unique within you is OK if you are unique, since the URI includes the domain part. I'll mention that algorithmic is another choice - i.e., some kind of GUID generator. > > Section 5.1.1 & 5.1.3 I think it is a key point to mention that the > mechanism in the first paragraph of 5.1.1 is identical to 5.1.3. > That is, there is nothing special about IVR. You are right. In fact, the first paragraph of 5.1.1 doesnt belong there, since the mechanism is not automated. It belongs rather in 5.1.3 which describes non-automated mechanisms. I've changed the first paragraph in 5.1.1 to read: SIP can be used to create conferences hosted in a central server by sending an INVITE to a conferencing application that would automatically create a new conference and then place a user into it. and the first paragraph in 5.1.3 is now: One way to create a conference is through interaction with an IVR application. The user would send a SIP INVITE to the conferencing application. This application would interact with the user, collect information about the desired conference, and create it. The user can then be placed into their newly created conference. > > Section 5.2.1 Is it worth mentioning a stateful application server as > a mechanism for running a conference? I don't understand. 5.2.1 is talking about adding users to a conference. What does that have to do with using an application server? > > Section 5.3 Is it worth mentioning RTCP anonimyzation? The section doesn't give any details on what the conference server needs to do in order to provide anonymity. It merely discusses how a user would ask for anonymity before joining. SO, I dont see the need here. > > Section 5.4.2 and 5.4.3 I don't really get the difference between > these two examples. One of them uses CPCP to remove a user. This can be done by an automata. The other uses a web application to remove a user. THis can only be done by a user. > > > > Section 5.5 This section creates a whole "What's the difference > between CPCP and SIP?" question in my head. These are totally difference protocols, so I dont see the confusion. CPCP will allow you to do things like say "when Eric joins the conference, he will be granted permission to eject other users", or "eject bob from the conference" or "create a new conference with bill as the moderator". How can any of these be done with sip? CPCP is a basic data transaction protocol. The only intersection with SIP is that both change the state of the conference in some way. As a result, since state changes can be moderated, SIP invitations or CPCP actions may need to be moderated. I think its reasonable that the basic moderation mechanisms should not depend on how the state change request was made. Thats all this section is saying. So, just because both SIP and CPCP can change the state of a conference, does not mean that they are the same protocol. > > Saying that moderation is handled the same in CPCP and SIP doesn't > help. > > Note that the mechanism described in the second paragraph of page 21 > doesn't make sense to me. If the session is moderated and someone > does an INVITE and the focus rejects the INVITE, how can anyone ever > join the conference? Yeah, good point. I'll remove that bit and leave the part that says you get put on hold. > The time-out mechanism in the third paragraph > of page 22 helps, but again doesn't really fit in with the what I > imagine to be the call flows. OK - what did you have in mind? > > The notification algorithm described on page 22 in the fourth > paragraph is hard for me to understand. If I (the client) request a > change, and it is denied, why would I ever expect it to later become > approved? "Pending" to rejected/approved makes sense. Yeah, I see why this is confusing. The right way to say this is that the CPCP transaction completes, with a response of "will be done pending authorization". THus, later, it is either approved or rejected. I'll change the wording. > > Also, w.r.t. section 5.8.2, I would really hope that CPCP is SIP: I'm > really hesitant to have to implement all the same protocol actions > with two different protocols "just because." Let's pick one and run > with it. See above discussion on why these are just not the same. In the case of conference participants, you will basically learn them as the result of a full-state update generated by a subscription to the conference state. CPCP, being a data transaction protocol, would also allow you to directly query for the list. Just because there is this sliver of overlap does not mean that they are the same protocol. > > > Section 5.6 This section needs a good, strong case for the sidebar > NOT having a distinct conference URI. I'm confused - are you saying it should have the same URI? Sidebars do have a separate URI. > > *Why* are users in a sidebar NOT in a different dialog? There is > different media, different participants, different features, > different notifications, etc. The problem was that this would require endpoint mixing to work. What you want is that the user in the conference have their one dialog to the server, and if they join a sidebar, the media they receive on that dialog changes to reflect their presence in the sidebar. I personally really wanted to have it be a truly separate conferenece, separate dialog, etc., but the complexity of doing this was extremely high. So, the text you see now is a middle ground position - to try and keep them separate to the greatest degree possible without imposing undue burdens on the endpoints. > > My reading of the requirements document is that having the same > conference URI would violate REQ-1 of section 3.7 of the requirements > document. Right - but its not. > > The mechanism for joining a sidebar is extremely convoluted. > Wouldn't it just be easier to re-INVITE to the sidebar, at a unique > URI, instead? There is no way in SIP to re-INVITE to a different URI. > > > > Section 7 I think conferencing is the kind of service that might > benefit from a Privacy section, e.g., hidden members etc. Good point. I added: Privacy is an important aspect of conferencing. Users may wish to join a conference without anyone knowing that they have joined, in order to silently listen in. In other applications, a participant may wish just to hide their identity from other participants, but otherwise let them know of their presence. These functions need to be provided by the conferencing system. > > > Typos ===== Section 3, page 9, 5th paragraph "... As far as its > concerned, its a UA just like any other." "... As far as it's > concerned, it's a UA just like any other." ^ ^ [it is = > it's; it (possessive) = its] I frequently make this mistake. Fixed. > > Section 4.1, 1st paragraph, line 2 "All participants in the > conference are connected to it using a SIP dialog." "All participants > in the conference are connected to it by a SIP dialog." ^^ Fixed. > > Section 5.1.1 sip:conferences@service.com I would offer > sip:conferences@example.net Fixed all non example.com or example.net domain references. > > Section 5.8 "Obtaining Membership" "Obtaining Membership Information" > The original section title implies "obtaining membership *in* the > conference", e.g., joining the conference, not "obtaining membership > *of* the conference", e.g., who is in the conference. Fixed. Thanks for your comments! -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 24 12:21:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22176 for ; Thu, 24 Apr 2003 12:21:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OGNwi23079 for sipping-archive@odin.ietf.org; Thu, 24 Apr 2003 12:23:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OGNv823076 for ; Thu, 24 Apr 2003 12:23:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22171 for ; Thu, 24 Apr 2003 12:20:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198jV2-000723-00 for sipping-web-archive@ietf.org; Thu, 24 Apr 2003 12:23:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198jV2-00071z-00 for sipping-web-archive@ietf.org; Thu, 24 Apr 2003 12:23:04 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OGKT822967; Thu, 24 Apr 2003 12:20:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OGJ5822874 for ; Thu, 24 Apr 2003 12:19:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22061 for ; Thu, 24 Apr 2003 12:15:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198jQK-0006zy-00 for sipping@ietf.org; Thu, 24 Apr 2003 12:18:12 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 198jQJ-0006zj-00 for sipping@ietf.org; Thu, 24 Apr 2003 12:18:11 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HDU00H01VXBPS@siemenscomms.co.uk> for sipping@ietf.org; Thu, 24 Apr 2003 17:17:36 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HDU00HKBVXAF9@siemenscomms.co.uk> for sipping@ietf.org; Thu, 24 Apr 2003 17:17:34 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Apr 2003 17:18:06 +0100 Content-return: allowed Date: Thu, 24 Apr 2003 17:18:26 +0100 From: "Elwell, John" Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network To: "'sipping@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT I had only two replies to this question (see below) when I raised it a few weeks ago, so I still don't know what conclusions to draw. Brett Tate (4th April) commented on solution 4 (sending UPDATE with new asserted ID), saying that this is valid although not explicitly documented. Francois Audet (4th April) supported the use of a new INVITE with Replaces header (and Supported header to ensure that INVITE is rejected if Replaces not supported). Personally I tend to favour sending UPDATE with a new asserted ID , but I would like to gain more confidence that this would be acceptable to the community before proceeding in that direction. Failing that I would go for a new INVITE with Replaces header, but I believe the overheads would be somewhat greater. John Elwell ( john.elwell@siemens.com ) -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens.com] Sent: 03 April 2003 22:18 To: sipping@ietf.org Subject: [Sipping] Impact on SIP of transfer in QSIG network There has been some discussion in the past on this list concerning the situation where call transfer takes place in a QSIG network and the impact of this on a party in a SIP network. The outcome was inconclusive, and talking to a couple of you at IETF56 I found that the original problem had not been explained too well. I attempt below to set out the problem and potential solutions. The problem: A transferor in a QSIG network transfers a call and EITHER the transferee OR the transfer target is a SIP UA. Prior to transfer there is a call linking the SIP UA via a gateway with the QSIG transferor. After transfer there is a call linking the SIP UA via the same gateway with the third party. If no SIP action is taken, the original dialog will remain in place between the SIP UA and the gateway. Note that SIP REFER is not involved - the equivalent takes place within the QSIG network. The problem with this is that the SIP UA receives no information about the change of partner in the conversation. In particular, if the SIP UA originally received the identity of the original partner by means of asserted or authenticated identity from the gateway, that information will no longer be valid and needs to be updated. Potential solutions: 1. Do nothing. This has a significant disadvantage that information sent to the SIP UA at dialog establishment time is not updated. 2. Change the From or To header (depending on direction of dialog) leaving the tag unchanged. This has all the disadvantages of relying on From/To for identity at dialog establishment time. It is unsatisfactory if the SIP UA had previously obtained its identify from another source (e.g., P-Asserted-Identity) rather than From/To. 3. Send Re-INVITE with new asserted or authenticated ID to SIP UA, but no change of session parameters. I believe this may be a misuse of Re-INVITE and it is unclear how UAs would react. 4. Send UPDATE with new asserted ID. Same remarks as above. 5. Send INVITE (new dialog) with Replaces header and Required header (Replaces required). This would be rejected by a UA that does not support the Replaces header. 6. Send INFO with new identity information (e.g, P-Asserted-Identity). I don't need to mention the concerns about INFO that have been expressed in the past. I would welcome comments on the above and any new proposals. John Elwell (john.elwell@siemens.com) _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 24 13:28:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24420 for ; Thu, 24 Apr 2003 13:28:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OHV6v27788 for sipping-archive@odin.ietf.org; Thu, 24 Apr 2003 13:31:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OHV5827785 for ; Thu, 24 Apr 2003 13:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24413 for ; Thu, 24 Apr 2003 13:27:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198kXy-0007Y6-00 for sipping-web-archive@ietf.org; Thu, 24 Apr 2003 13:30:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198kXy-0007Y3-00 for sipping-web-archive@ietf.org; Thu, 24 Apr 2003 13:30:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OHTU827666; Thu, 24 Apr 2003 13:29:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OHSG827610 for ; Thu, 24 Apr 2003 13:28:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24229 for ; Thu, 24 Apr 2003 13:25:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198kVG-0007X2-00 for sipping@ietf.org; Thu, 24 Apr 2003 13:27:22 -0400 Received: from gorilla.mchh.siemens.de ([194.138.158.18]) by ietf-mx with esmtp (Exim 4.12) id 198kVF-0007Wn-00 for sipping@ietf.org; Thu, 24 Apr 2003 13:27:21 -0400 Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id TAA06205 for ; Thu, 24 Apr 2003 19:27:41 +0200 (MET DST) Received: from mchh253e.mchh.siemens.de (mchh253e.mchh.siemens.de [139.21.200.63]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id TAA04043 for ; Thu, 24 Apr 2003 19:27:42 +0200 (MET DST) Received: by mchh253e.mchh.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Apr 2003 19:27:21 +0200 Message-ID: <5B788FC2CAFBD6118BAE0030848B025C416CB4@LNN201E> From: Marjou Xavier To: "'sipping@ietf.org'" Subject: RE: [Sipping] conf: comments on draft-rosenberg-sipping-conferenc ing-framework-01 Date: Thu, 24 Apr 2003 19:25:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Hello, Something is not clear to me : is CPCP really mandatory to perform something as "simple" as calling many recipients via a focus (adhoc conference). In my opinion, it should be as simple as sending an e-mail to multiple recipients (Of course, having everybody in the "To" header is not possible in SIP, but having another header for giving the list of recipients whould be very nice). By reading the document, I am not sure whether it's feasible. Does it mean that the only way to perfom "mass invitation" is by setting the list of participants via CPCP each time I want to sent an INVITE ? Of course, I understand the need for a CPCP protocol to override the default behaviour of the conference, or to control what's happening in a conference. Best regards, Xavier Marjou _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Thu Apr 24 21:56:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12908 for ; Thu, 24 Apr 2003 21:56:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P1x4W32184 for sipping-archive@odin.ietf.org; Thu, 24 Apr 2003 21:59:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1x3832181 for ; Thu, 24 Apr 2003 21:59:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12905 for ; Thu, 24 Apr 2003 21:55:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198sTO-0003sM-00 for sipping-web-archive@ietf.org; Thu, 24 Apr 2003 21:57:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198sTO-0003sJ-00 for sipping-web-archive@ietf.org; Thu, 24 Apr 2003 21:57:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1vc832141; Thu, 24 Apr 2003 21:57:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1us832103 for ; Thu, 24 Apr 2003 21:56:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12872 for ; Thu, 24 Apr 2003 21:53:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198sRJ-0003re-00 for sipping@ietf.org; Thu, 24 Apr 2003 21:55:49 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 198sRI-0003rU-00 for sipping@ietf.org; Thu, 24 Apr 2003 21:55:48 -0400 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h3P1tbsC018321 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 24 Apr 2003 20:55:38 -0500 From: "Dean Willis" To: , "Aki Niemi" Cc: , "David Oran" Date: Thu, 24 Apr 2003 20:55:32 -0500 Message-ID: <001101c30acd$c1af7220$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3P1us832104 Subject: [Sipping] Commentary on draft-niemi-sipping-event-throttle-reqs Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit At the last meeting, we agreed (well, actually Rohan volunteered us) that we would look at the event throttling requirements draft, and that at least a couple of us would post discussions before we considered taking it on as a WG effort. So here's my try at it. The given draft is: http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttle-reqs- 01.txt Overall, I think that developing an event throttling mechanism is a good idea, and that this draft is a reasonable start on the requirements. General comment: The draft seems to confuse the maximum notification rate "desired" or "allowed" by the subscriber with the rate "required" by the notifier. I'll come back to this at several points in the discussion. There also seems to be a bit of confusion on the difference between average rates and minimum interval -- they're not exactly inverses of each other. English is such a fun language -- too bad it doesn't work well for specifications. Section 3: Event Throttle Model This section raises two throttling models, which it identifies as "strict" and "leaky bucket" quarantines. The usage of the "strict" model should be clarified as establishing the minimum time period allowed between two notifications. The draft says that the choice of which notification is sent is implementation dependent, although it seems to assume a "newest" notification, where "newer" notifications replace "older" ones if the minimum notification interval time has not elapsed. I suspect that this replacement model has a lot of overlap with filtering. Should we explicitly include a requirement that the replacement policy be describable in the subscription process? This section also refers to what it calls a "leaky bucket style algorithm", which is probably a misnomer. Traditionally (at least in my pointy head) a "leaky bucket" refers to a FIFO queue with a variable arrival rate and a fixed departure rate. There might be input "bursts" at a rate higher than the output rate, resulting in a lengthening of the queue, but the output rate is held constant as long as the queue length is non-zero. However, the policy described in the draft is one of rate-averaging, which is something like a leaky-bucket that kicks in only if the sliding-window average rate exceeds the prescribed maximum. This could use some cleanup. Additionally, one might envision a rate-averaging queue that enforces its operation by discarding or combining notifications instead of delaying them. So basically, there are two queue models proposed: 1) minimum fixed interval or period between notifications, where the interval can be described as a time value like 5 seconds. This can also be described as maximum fixed rate, or notifications per unit of time, like 0.2 notifications per second or 1 notification per 5 seconds (oddly enough, this is the reciprocal of the minimum interval) 2) minimum average interval or period between notifications, which is better described as the maximum average rate of notifications and best described in notifications per unit of time, averaged over some time window. And two reasonable queue-servicing policies: 1) Delay notifications in a FIFO manner to conform to policy. 2) Discard out-of-profile notifications or combine them with other notifications to result in a notification stream that conforms to policy. Note that policy 1 can result in increasing queue depth if the arrival rate persists in exceeding the departure rate. Consequently, practical systems using 1 are likely to revert to 2 at some point. Efficiency may also be improvable by using a quenching mechanism to reduce the arrival rate. Section 4, Example Use Case: This doesn't really describe a use case, but just presents us with the mathematical notation of the reciprocal relationship between frequency and period. Useful background, but a real use case (with actors, etc.) would be nice here too. Perhaps something like: Case 1: Alice subscribes to the status of Bob. Bob's status is served by server S. Alice tells S (subscribes with a notification throttling policy) that she wishes to receive notifications no more frequently than once every five seconds. Bob publishes a status of Red to the server S, which notifies Alice. Sub case a: After a delay of three seconds, Bob publishes a status of Green to S. S, which implements a policy of discarding out-of-profile notifications, stores the status of Green but does not notify Alice. After three more seconds, Bob publishes a status of Blue to S. Since six seconds have elapsed since the last notification to Alice, S notifies Alice that Bob's status is now Blue. Note that in this sub-case, Alice is never notified that Bob's status was Green, but the notifications that she does receive are timely. Sub case b: After a delay of three seconds, Bob publishes a status of Green to S. S, which implements of policy of delaying out-of-profile notifications so that they become compliant, stores the status of Bob. After two more seconds, S notifies Alice that Bob's status is now Green. One second later, Bob publishes a status of Blue. Again, S stores the new state for Bob, but does not immediately notify Alice. Four seconds later, S notifies Alice that Bob's status is now Blue. Note that in this sub-case, Alice is notified of all statuses published by Bob, but often has a different understanding of Bob's status than does Bob, because the notifications from S to Alice are delayed. REQ3: Says that "The notifier must be able to indicate that it does not support the use of a throttle mechanism in the subscription. This would be better worded as ". . . for a specific subscription", otherwise we'll have people thinking "in the subscription" means "in the SUBSCRIBE", when we all know it would have to be "in the response to the SUBSCRIBE". REQ6: Ends in "For example, local policy could dictate an even lower rate of notification than what the subscriber requires." Refer back to my General Comment earlier in this missive. It seems to me that this would be better worded as " . . . what the subscriber allows". I think we're having a tendency to get confused about what the rate limit is asking for. The subscriber is saying "I want to receive notifications no more frequently than once per X seconds", not "You MUST notify me EVERY X seconds." REQ7: Says that security mechanisms "SHOULD be applied to subscriptions . . . ". This is trying to define operational guidelines at protocol requirements time. Rather, we should word this sort of thing to require a capability to be met by the mechanism to be developed. Perhaps "A throttle mechanism MUST allow for the application of authentication and integrity protection mechanisms to subscriptions invoking that mechanism." Section 6: Security Requirements Issue 1 points out that it might be possible for a subscriber to set a maximum notification interval longer than the subscription duration, consequently resulting in only getting one notification per subscription. Should we add a new requirement on the order of "A notifier receiving a subscription request including throttling policy MUST be able to response with something having the semantic of 'That's a really freaking stupid idea'.? Or should we add a requirement more like "A throttling mechanism MUST include discussion of the situation resulting from a minimum inter-notification period which exceeds the subscription duration and include mechanisms for avoiding this situation and/or guidance to implementers on the dangers of getting exactly what they asked for"? Issue 2 raises the possibility that a subscriber might set a very short minimum inter-notification period (or very high maximum notification rate), thereby causing the notifier to exhaust itself sending at that frequency. This is, well, bogus. As I pointed out above, the throttling policy does not tell the notifier the rate at which notifications should be sent. Rather, it tells the server the rate that notifications must not exceed. This is something like a traffic sign. If the sign on the street says "Speed Limit: 30 kph", this does not force all cards to speed up to 30 kph. In most situations (barring a few large motorways that have a SEPARATE policy for minimum speeds) driving at 28 kph, or even 20 kph, would be just fine. Conclusion: Note that there is considerable potential for confusion between frequency (or rate) and period (or interval) in this conversation. We should be careful to say explicitly what we mean. Is it feasible to use just one term in all discussions? I have the feeling that SIP is not likely to be well-suited to exceptionally frequent notifications. Is it reasonable to state a minimum period in seconds? This lets us use a signed-16 range to express inter-notification periods ranging from 1 second to a little over 9 hours. Do we need higher resolution than that? There's probably a resolution requirement that needs to be stated in this draft. -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 25 01:48:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16452 for ; Fri, 25 Apr 2003 01:48:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P5pcB14915 for sipping-archive@odin.ietf.org; Fri, 25 Apr 2003 01:51:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P5pc814912 for ; Fri, 25 Apr 2003 01:51:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16449 for ; Fri, 25 Apr 2003 01:48:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198w6O-00050f-00 for sipping-web-archive@ietf.org; Fri, 25 Apr 2003 01:50:28 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198w6O-00050c-00 for sipping-web-archive@ietf.org; Fri, 25 Apr 2003 01:50:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P5na814861; Fri, 25 Apr 2003 01:49:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P5mq814822 for ; Fri, 25 Apr 2003 01:48:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16408 for ; Fri, 25 Apr 2003 01:45:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198w3i-000502-00 for sipping@ietf.org; Fri, 25 Apr 2003 01:47:42 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 198w3i-0004zy-00 for sipping@ietf.org; Fri, 25 Apr 2003 01:47:42 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3P5lc08020389; Thu, 24 Apr 2003 22:47:39 -0700 (PDT) Received: from [192.168.0.12] (sjc-vpn3-76.cisco.com [10.21.64.76]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADO03193; Thu, 24 Apr 2003 22:47:37 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 24 Apr 2003 22:47:35 -0700 Subject: Re: [Sipping] Impact on SIP of transfer in QSIG network From: Cullen Jennings To: "Elwell, John" , "'sipping@ietf.org'" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Just to make sure I understand the problem ... The main thing this information is used for is to update the display on the users phone so they understand who they are speaking too? On 4/24/03 9:18 AM, "Elwell, John" wrote: > I had only two replies to this question (see below) when I raised it a few > weeks ago, so I still don't know what conclusions to draw. > > Brett Tate (4th April) commented on solution 4 (sending UPDATE with new > asserted ID), saying that this is valid although not explicitly documented. > > Francois Audet (4th April) supported the use of a new INVITE with Replaces > header (and Supported header to ensure that INVITE is rejected if Replaces > not supported). > > Personally I tend to favour sending UPDATE with a new asserted ID , but I > would like to gain more confidence that this would be acceptable to the > community before proceeding in that direction. Failing that I would go for a > new INVITE with Replaces header, but I believe the overheads would be > somewhat greater. > > John Elwell ( john.elwell@siemens.com ) > > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens.com] > Sent: 03 April 2003 22:18 > To: sipping@ietf.org > Subject: [Sipping] Impact on SIP of transfer in QSIG network > > > > There has been some discussion in the past on this list concerning the > situation where call transfer takes place in a QSIG network and the impact > of this on a party in a SIP network. The outcome was inconclusive, and > talking to a couple of you at IETF56 I found that the original problem had > not been explained too well. I attempt below to set out the problem and > potential solutions. > > The problem: > > A transferor in a QSIG network transfers a call and EITHER the transferee OR > the transfer target is a SIP UA. Prior to transfer there is a call linking > the SIP UA via a gateway with the QSIG transferor. After transfer there is a > call linking the SIP UA via the same gateway with the third party. If no SIP > action is taken, the original dialog will remain in place between the SIP UA > and the gateway. Note that SIP REFER is not involved - the equivalent takes > place within the QSIG network. > > The problem with this is that the SIP UA receives no information about the > change of partner in the conversation. In particular, if the SIP UA > originally received the identity of the original partner by means of > asserted or authenticated identity from the gateway, that information will > no longer be valid and needs to be updated. > > Potential solutions: > > 1. Do nothing. This has a significant disadvantage that information sent to > the SIP UA at dialog establishment time is not updated. > > 2. Change the From or To header (depending on direction of dialog) leaving > the tag unchanged. This has all the disadvantages of relying on From/To for > identity at dialog establishment time. It is unsatisfactory if the SIP UA > had previously obtained its identify from another source (e.g., > P-Asserted-Identity) rather than From/To. > > 3. Send Re-INVITE with new asserted or authenticated ID to SIP UA, but no > change of session parameters. I believe this may be a misuse of Re-INVITE > and it is unclear how UAs would react. > > 4. Send UPDATE with new asserted ID. Same remarks as above. > > 5. Send INVITE (new dialog) with Replaces header and Required header > (Replaces required). This would be rejected by a UA that does not support > the Replaces header. > > 6. Send INFO with new identity information (e.g, P-Asserted-Identity). I > don't need to mention the concerns about INFO that have been expressed in > the past. > > I would welcome comments on the above and any new proposals. > > John Elwell (john.elwell@siemens.com) > > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 25 03:06:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29241 for ; Fri, 25 Apr 2003 03:06:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P79WN31692 for sipping-archive@odin.ietf.org; Fri, 25 Apr 2003 03:09:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P79W831689 for ; Fri, 25 Apr 2003 03:09:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29233 for ; Fri, 25 Apr 2003 03:06:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198xJk-0005ej-00 for sipping-web-archive@ietf.org; Fri, 25 Apr 2003 03:08:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198xJk-0005eg-00 for sipping-web-archive@ietf.org; Fri, 25 Apr 2003 03:08:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P76N830741; Fri, 25 Apr 2003 03:06:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P74k830649 for ; Fri, 25 Apr 2003 03:04:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29180 for ; Fri, 25 Apr 2003 03:01:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198xF8-0005dA-00 for sipping@ietf.org; Fri, 25 Apr 2003 03:03:34 -0400 Received: from mailgate.siemenscomms.co.uk ([194.129.217.115]) by ietf-mx with esmtp (Exim 4.12) id 198xF8-0005cw-00 for sipping@ietf.org; Fri, 25 Apr 2003 03:03:34 -0400 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #45905) id <0HDW002010WX6P@siemenscomms.co.uk> for sipping@ietf.org; Fri, 25 Apr 2003 08:02:57 +0100 (BST) Received: from beex10.siemenscomms.co.uk ([137.223.246.252]) by siemenscomms.co.uk (PMDF V6.0-24 #45905) with ESMTP id <0HDW001AA0WXWH@siemenscomms.co.uk>; Fri, 25 Apr 2003 08:02:57 +0100 (BST) Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 25 Apr 2003 08:03:29 +0100 Content-return: allowed Date: Fri, 25 Apr 2003 08:03:50 +0100 From: "Elwell, John" Subject: RE: [Sipping] Impact on SIP of transfer in QSIG network To: "'Cullen Jennings'" , "'sipping@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Cullen, Yes, this is correct. John > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 25 April 2003 06:48 > To: Elwell, John; 'sipping@ietf.org' > Subject: Re: [Sipping] Impact on SIP of transfer in QSIG network > > > > Just to make sure I understand the problem ... The main thing this > information is used for is to update the display on the users > phone so they > understand who they are speaking too? > > > On 4/24/03 9:18 AM, "Elwell, John" wrote: > > > I had only two replies to this question (see below) when I > raised it a few > > weeks ago, so I still don't know what conclusions to draw. > > > > Brett Tate (4th April) commented on solution 4 (sending > UPDATE with new > > asserted ID), saying that this is valid although not > explicitly documented. > > > > Francois Audet (4th April) supported the use of a new > INVITE with Replaces > > header (and Supported header to ensure that INVITE is > rejected if Replaces > > not supported). > > > > Personally I tend to favour sending UPDATE with a new > asserted ID , but I > > would like to gain more confidence that this would be > acceptable to the > > community before proceeding in that direction. Failing that > I would go for a > > new INVITE with Replaces header, but I believe the > overheads would be > > somewhat greater. > > > > John Elwell ( john.elwell@siemens.com > ) > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens.com] > > Sent: 03 April 2003 22:18 > > To: sipping@ietf.org > > Subject: [Sipping] Impact on SIP of transfer in QSIG network > > > > > > > > There has been some discussion in the past on this list > concerning the > > situation where call transfer takes place in a QSIG network > and the impact > > of this on a party in a SIP network. The outcome was > inconclusive, and > > talking to a couple of you at IETF56 I found that the > original problem had > > not been explained too well. I attempt below to set out the > problem and > > potential solutions. > > > > The problem: > > > > A transferor in a QSIG network transfers a call and EITHER > the transferee OR > > the transfer target is a SIP UA. Prior to transfer there is > a call linking > > the SIP UA via a gateway with the QSIG transferor. After > transfer there is a > > call linking the SIP UA via the same gateway with the third > party. If no SIP > > action is taken, the original dialog will remain in place > between the SIP UA > > and the gateway. Note that SIP REFER is not involved - the > equivalent takes > > place within the QSIG network. > > > > The problem with this is that the SIP UA receives no > information about the > > change of partner in the conversation. In particular, if the SIP UA > > originally received the identity of the original partner by means of > > asserted or authenticated identity from the gateway, that > information will > > no longer be valid and needs to be updated. > > > > Potential solutions: > > > > 1. Do nothing. This has a significant disadvantage that > information sent to > > the SIP UA at dialog establishment time is not updated. > > > > 2. Change the From or To header (depending on direction of > dialog) leaving > > the tag unchanged. This has all the disadvantages of > relying on From/To for > > identity at dialog establishment time. It is unsatisfactory > if the SIP UA > > had previously obtained its identify from another source (e.g., > > P-Asserted-Identity) rather than From/To. > > > > 3. Send Re-INVITE with new asserted or authenticated ID to > SIP UA, but no > > change of session parameters. I believe this may be a > misuse of Re-INVITE > > and it is unclear how UAs would react. > > > > 4. Send UPDATE with new asserted ID. Same remarks as above. > > > > 5. Send INVITE (new dialog) with Replaces header and Required header > > (Replaces required). This would be rejected by a UA that > does not support > > the Replaces header. > > > > 6. Send INFO with new identity information (e.g, > P-Asserted-Identity). I > > don't need to mention the concerns about INFO that have > been expressed in > > the past. > > > > I would welcome comments on the above and any new proposals. > > > > John Elwell (john.elwell@siemens.com) > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 25 07:48:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03847 for ; Fri, 25 Apr 2003 07:48:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PBpaV17874 for sipping-archive@odin.ietf.org; Fri, 25 Apr 2003 07:51:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PBpa817871 for ; Fri, 25 Apr 2003 07:51:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03843 for ; Fri, 25 Apr 2003 07:48:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1991ic-00072G-00 for sipping-web-archive@ietf.org; Fri, 25 Apr 2003 07:50:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1991ib-00072D-00 for sipping-web-archive@ietf.org; Fri, 25 Apr 2003 07:50:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PBof817795; Fri, 25 Apr 2003 07:50:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PBl9817617 for ; Fri, 25 Apr 2003 07:47:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03676; Fri, 25 Apr 2003 07:43:34 -0400 (EDT) Message-Id: <200304251143.HAA03676@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 25 Apr 2003 07:43:34 -0400 Subject: [Sipping] I-D ACTION:draft-ietf-sipping-conferencing-requirements-00.txt Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : High Level Requirements for Tightly Coupled SIP Conferencing Author(s) : O. Levin, R. Even Filename : draft-ietf-sipping-conferencing-requirements-00.txt Pages : 13 Date : 2003-4-24 This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-conferencing-requirements-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sipping-conferencing-requirements-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-conferencing-requirements-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: <2003-4-24150617.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-conferencing-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-conferencing-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-24150617.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 25 10:52:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11549 for ; Fri, 25 Apr 2003 10:52:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PEtqC00547 for sipping-archive@odin.ietf.org; Fri, 25 Apr 2003 10:55:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PEtq800544 for ; Fri, 25 Apr 2003 10:55:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11511 for ; Fri, 25 Apr 2003 10:52:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1994as-0001HL-00 for sipping-web-archive@ietf.org; Fri, 25 Apr 2003 10:54:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1994as-0001HI-00 for sipping-web-archive@ietf.org; Fri, 25 Apr 2003 10:54:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PErk800418; Fri, 25 Apr 2003 10:53:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PEqG800329 for ; Fri, 25 Apr 2003 10:52:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11391 for ; Fri, 25 Apr 2003 10:48:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1994XP-0001Fg-00 for sipping@ietf.org; Fri, 25 Apr 2003 10:50:55 -0400 Received: from tomts20.bellnexxia.net ([209.226.175.74] helo=tomts20-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 1994XP-0001Fd-00 for sipping@ietf.org; Fri, 25 Apr 2003 10:50:55 -0400 Received: from Shulin ([199.243.90.234]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030425145123.UWJF22383.tomts20-srv.bellnexxia.net@Shulin> for ; Fri, 25 Apr 2003 10:51:23 -0400 From: "Shu-Lin CHen" To: Date: Fri, 25 Apr 2003 10:51:23 -0400 Message-ID: <000001c30b3a$24390070$390aa8c0@blueslicemtl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <5B788FC2CAFBD6118BAE0030848B025C416CB4@LNN201E> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Sipping] MESSAGE method Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi: In which document is the MESSAGE method defined/discussed? Thanks. shu-lin _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 25 11:24:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12174 for ; Fri, 25 Apr 2003 11:24:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PFRBb02847 for sipping-archive@odin.ietf.org; Fri, 25 Apr 2003 11:27:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PFRB802844 for ; Fri, 25 Apr 2003 11:27:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12165 for ; Fri, 25 Apr 2003 11:23:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19955B-0001Su-00 for sipping-web-archive@ietf.org; Fri, 25 Apr 2003 11:25:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19955A-0001Sr-00 for sipping-web-archive@ietf.org; Fri, 25 Apr 2003 11:25:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PFPu802804; Fri, 25 Apr 2003 11:25:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PFN2802575 for ; Fri, 25 Apr 2003 11:23:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12064 for ; Fri, 25 Apr 2003 11:19:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19951A-0001Qr-00 for sipping@ietf.org; Fri, 25 Apr 2003 11:21:40 -0400 Received: from angelica.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 199519-0001Qc-00 for sipping@ietf.org; Fri, 25 Apr 2003 11:21:39 -0400 Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id LAA26178; Fri, 25 Apr 2003 11:21:32 -0400 (EDT) Message-ID: <3EA9527B.6050604@ulticom.com> Date: Fri, 25 Apr 2003 11:21:31 -0400 From: Steve Pellegrino Organization: Ulticom, Inc. (http://www.ulticom.com) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Shu-Lin CHen CC: sipping@ietf.org Subject: Re: [Sipping] MESSAGE method References: <000001c30b3a$24390070$390aa8c0@blueslicemtl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit RFC 3428. Shu-Lin CHen wrote: >Hi: > >In which document is the MESSAGE method defined/discussed? > >Thanks. > >shu-lin > >_______________________________________________ >Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping >This list is for NEW development of the application of SIP >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sip@ietf.org for new developments of core SIP > _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Fri Apr 25 11:48:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12840 for ; Fri, 25 Apr 2003 11:48:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PFpf905040 for sipping-archive@odin.ietf.org; Fri, 25 Apr 2003 11:51:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PFpf805037 for ; Fri, 25 Apr 2003 11:51:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12826 for ; Fri, 25 Apr 2003 11:48:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1995Ss-0001eN-00 for sipping-web-archive@ietf.org; Fri, 25 Apr 2003 11:50:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1995Ss-0001eH-00 for sipping-web-archive@ietf.org; Fri, 25 Apr 2003 11:50:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PFeC804513; Fri, 25 Apr 2003 11:40:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PFZg803423 for ; Fri, 25 Apr 2003 11:35:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12480 for ; Fri, 25 Apr 2003 11:32:02 -0400 (EDT) From: mielias@hss.hns.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1995DP-0001Y4-00 for sipping@ietf.org; Fri, 25 Apr 2003 11:34:19 -0400 Received: from 210-210-93-19.lan.sify.net ([210.210.93.19] helo=hss.hns.com) by ietf-mx with esmtp (Exim 4.12) id 1995DO-0001Xo-00 for sipping@ietf.org; Fri, 25 Apr 2003 11:34:19 -0400 Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hss.hns.com (8.11.6/8.11.2) with SMTP id h3PEuGO16585; Fri, 25 Apr 2003 20:26:19 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256D13.0055584D ; Fri, 25 Apr 2003 21:02:11 +0530 X-Lotus-FromDomain: HSSBLR To: "Shu-Lin CHen" cc: sipping@ietf.org Message-ID: <65256D13.005556C5.00@sampark.hss.hns.com> Date: Fri, 25 Apr 2003 20:43:33 +0530 Subject: Re: [Sipping] MESSAGE method Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Have a look at Rfc 3428 - Session Initiation Protocol (SIP) Extension for Instant Messaging. -Elias Hughes Software Systems www.hssworld.com "Shu-Lin CHen" on 04/25/2003 09:21:23 PM To: sipping@ietf.org cc: (bcc: Mohamed Ibrahim Elias/HSSBLR) Subject: [Sipping] MESSAGE method Hi: In which document is the MESSAGE method defined/discussed? Thanks. shu-lin _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sun Apr 27 04:23:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20700 for ; Sun, 27 Apr 2003 04:23:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3R8R8t19753 for sipping-archive@odin.ietf.org; Sun, 27 Apr 2003 04:27:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3R8R8819750 for ; Sun, 27 Apr 2003 04:27:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20697 for ; Sun, 27 Apr 2003 04:22:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199hSw-000451-00 for sipping-web-archive@ietf.org; Sun, 27 Apr 2003 04:24:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 199hSw-00044x-00 for sipping-web-archive@ietf.org; Sun, 27 Apr 2003 04:24:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3R8Q1819730; Sun, 27 Apr 2003 04:26:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3R8NV819646 for ; Sun, 27 Apr 2003 04:23:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20653 for ; Sun, 27 Apr 2003 04:19:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199hPR-000443-00 for sipping@ietf.org; Sun, 27 Apr 2003 04:21:17 -0400 Received: from comversegw.icomverse.com ([192.118.48.248] helo=il-tlv-smtpout1.icomverse.com) by ietf-mx with esmtp (Exim 4.12) id 199hPQ-000440-00 for sipping@ietf.org; Sun, 27 Apr 2003 04:21:16 -0400 Received: from il-tlv-mbdg2.comverse.com (localhost.localdomain [127.0.0.1]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id h3R8LdU15595 for ; Sun, 27 Apr 2003 11:21:39 +0300 Received: by il-tlv-mbdg2.comverse.com with Internet Mail Service (5.5.2655.55) id <20VK6FVC>; Sun, 27 Apr 2003 11:21:46 +0300 Message-ID: <32B823C1CD4FD5119C0D0002A560F78E091FF435@ismail3.comverse.com> From: Fuxbruner Amihay To: sipping@ietf.org Subject: [Sipping] Session timer - Supported header question Date: Sun, 27 Apr 2003 11:21:44 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C30C95.C6AA70A8" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , 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_01C30C95.C6AA70A8 Content-Type: text/plain; charset="windows-1255" Hello all, The session timer draft (draft-ietf-sip-session-timer-10.txt) section 7.1 says: " A UAC which supports the session timer extension defined here MUST include a Supported header field in each request (except ACK), listing the option tag "timer" [1]. It MUST do so even if the UAC is not requesting usage of the session timer for this session." Is this requirement reasonable?? Isn't it enough to send Supported header in the initial request?? Thanks for your answer in advance. Amihay Fuxbruner System Engineering - Signaling R&D Comverse ------_=_NextPart_001_01C30C95.C6AA70A8 Content-Type: text/html; charset="windows-1255" [Sipping] Session timer - Supported header question

Hello all,

The session timer draft (draft-ietf-sip-session-timer-10.txt) section 7.1 says:

"  A UAC which supports the session timer extension defined here MUST
   include a Supported header field in each request (except ACK),
   listing the option tag "timer" [1]. It MUST do so even if the UAC is
   not requesting usage of the session timer for this session."

Is this requirement reasonable??
Isn't it enough to send Supported header in the initial request??

Thanks for your answer in advance.

Amihay Fuxbruner
System Engineering - Signaling R&D
Comverse

------_=_NextPart_001_01C30C95.C6AA70A8-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Sun Apr 27 23:08:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07626 for ; Sun, 27 Apr 2003 23:08:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3S3Cqr19770 for sipping-archive@odin.ietf.org; Sun, 27 Apr 2003 23:12:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S3Cp819767 for ; Sun, 27 Apr 2003 23:12:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07621 for ; Sun, 27 Apr 2003 23:08:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199z1y-0007bc-00 for sipping-web-archive@ietf.org; Sun, 27 Apr 2003 23:10:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 199z1x-0007bZ-00 for sipping-web-archive@ietf.org; Sun, 27 Apr 2003 23:10:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S32S818565; Sun, 27 Apr 2003 23:02:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S30p818343 for ; Sun, 27 Apr 2003 23:00:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07394 for ; Sun, 27 Apr 2003 22:56:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199yqM-0007Yv-00 for sipping@ietf.org; Sun, 27 Apr 2003 22:58:14 -0400 Received: from [61.144.161.2] (helo=mta0) by ietf-mx with esmtp (Exim 4.12) id 199yqL-0007Yq-00 for sipping@ietf.org; Sun, 27 Apr 2003 22:58:13 -0400 Received: from Natarajucl1127 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HE1006H59IIXD@mta0.huawei.com> for sipping@ietf.org; Mon, 28 Apr 2003 10:56:46 +0800 (CST) Date: Mon, 28 Apr 2003 08:28:00 +0530 From: "Nataraju A.B." Subject: Re: [Sipping] Session timer - Supported header question To: Fuxbruner Amihay , sipping@ietf.org Message-id: <001c01c30d31$fb84d150$5d02120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_KbNmYyteHiliomE1rPexmw)" X-Priority: 3 X-MSMail-priority: Normal References: <32B823C1CD4FD5119C0D0002A560F78E091FF435@ismail3.comverse.com> Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_KbNmYyteHiliomE1rPexmw) Content-type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 7BIT [Sipping] Session timer - Supported header questionRegards, -Nataraju A.B. ----- Original Message ----- From: Fuxbruner Amihay To: sipping@ietf.org Sent: Sunday, April 27, 2003 1:51 PM Subject: [Sipping] Session timer - Supported header question Hello all, The session timer draft (draft-ietf-sip-session-timer-10.txt) section 7.1 says: " A UAC which supports the session timer extension defined here MUST include a Supported header field in each request (except ACK), listing the option tag "timer" [1]. It MUST do so even if the UAC is not requesting usage of the session timer for this session." Is this requirement reasonable?? Isn't it enough to send Supported header in the initial request?? [Nataraju] The Supported header must be there in the refresh request also since there could be SE value negotiation even in the refresh requests also. This could happen just because the elements will check only about the SE in the request and its local Min-SE values. This scenario may occurs rarely but we need tolerate these situations also. Thanks for your answer in advance. Amihay Fuxbruner System Engineering - Signaling R&D Comverse --Boundary_(ID_KbNmYyteHiliomE1rPexmw) Content-type: text/html; charset=windows-1255 Content-Transfer-Encoding: 7BIT [Sipping] Session timer - Supported header question
Regards,
-Nataraju A.B.
----- Original Message -----
Sent: Sunday, April 27, 2003 1:51 PM
Subject: [Sipping] Session timer - Supported header question

Hello all,

The session timer draft (draft-ietf-sip-session-timer-10.txt) section 7.1 says:

"  A UAC which supports the session timer extension defined here MUST
   include a Supported header field in each request (except ACK),
   listing the option tag "timer" [1]. It MUST do so even if the UAC is
   not requesting usage of the session timer for this session."

Is this requirement reasonable??
Isn't it enough to send Supported header in the initial request??

[Nataraju] The Supported header must be there in the refresh request also since there could be SE value negotiation even in the refresh requests also. This could happen just because the elements will check only about the SE in the request and its local Min-SE values. This scenario may occurs rarely but we need tolerate these situations also.

Thanks for your answer in advance.

Amihay Fuxbruner
System Engineering - Signaling R&D
Comverse

--Boundary_(ID_KbNmYyteHiliomE1rPexmw)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 28 06:41:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26023 for ; Mon, 28 Apr 2003 06:41:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SAk8K30052 for sipping-archive@odin.ietf.org; Mon, 28 Apr 2003 06:46:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SAk8830049 for ; Mon, 28 Apr 2003 06:46:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26009 for ; Mon, 28 Apr 2003 06:41:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A66T-0001v5-00 for sipping-web-archive@ietf.org; Mon, 28 Apr 2003 06:43:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19A66S-0001v1-00 for sipping-web-archive@ietf.org; Mon, 28 Apr 2003 06:43:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SAjJ830033; Mon, 28 Apr 2003 06:45:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SAi3829983 for ; Mon, 28 Apr 2003 06:44:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25989 for ; Mon, 28 Apr 2003 06:39:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A64R-0001uh-00 for sipping@ietf.org; Mon, 28 Apr 2003 06:41:15 -0400 Received: from [61.144.161.2] (helo=mta0) by ietf-mx with esmtp (Exim 4.12) id 19A64C-0001uY-00 for sipping@ietf.org; Mon, 28 Apr 2003 06:41:00 -0400 Received: from Natarajucl1127 (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <0HE1008V9UX623@mta0.huawei.com> for sipping@ietf.org; Mon, 28 Apr 2003 18:39:13 +0800 (CST) Date: Mon, 28 Apr 2003 16:10:01 +0530 From: "Nataraju A.B." To: sipping@ietf.org Message-id: <000b01c30d72$8966bbb0$5d02120a@in.huawei.com> Organization: HTIPL MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_M9iYe511Xk6aLbjoLz9eTg)" X-Priority: 3 X-MSMail-priority: Normal Subject: [Sipping] CSF applications. Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --Boundary_(ID_M9iYe511Xk6aLbjoLz9eTg) Content-type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7BIT Hi All, Can I know instances where I need a CSF. Thsnks in Advance, Regards, -Nataraju A.B. -------------------------------------------------------------------------------- --Boundary_(ID_M9iYe511Xk6aLbjoLz9eTg) Content-type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7BIT
Hi All,
 
Can I know instances where I need a CSF.
 
Thsnks in Advance,
 
Regards,
-Nataraju A.B.

Upgrade Your Email - Click here!
--Boundary_(ID_M9iYe511Xk6aLbjoLz9eTg)-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 28 16:35:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13831 for ; Mon, 28 Apr 2003 16:35:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SKe8C11788 for sipping-archive@odin.ietf.org; Mon, 28 Apr 2003 16:40:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKe8811785 for ; Mon, 28 Apr 2003 16:40:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13807 for ; Mon, 28 Apr 2003 16:34:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AFN6-0005Ff-00 for sipping-web-archive@ietf.org; Mon, 28 Apr 2003 16:37:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AFN5-0005Fc-00 for sipping-web-archive@ietf.org; Mon, 28 Apr 2003 16:37:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKZc810766; Mon, 28 Apr 2003 16:35:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SKYn810651 for ; Mon, 28 Apr 2003 16:34:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13644 for ; Mon, 28 Apr 2003 16:29:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AFHx-0005E3-00 for sipping@ietf.org; Mon, 28 Apr 2003 16:31:49 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19AFHx-0005Dq-00 for sipping@ietf.org; Mon, 28 Apr 2003 16:31:49 -0400 Received: from cia.cisco.com (IDENT:mirapoint@cia.cisco.com [64.100.238.51]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3SKVqlY028659; Mon, 28 Apr 2003 16:31:53 -0400 (EDT) Received: from mhammer-w2k02.cisco.com (dhcp-hrn-64-100-229-133.cisco.com [64.100.229.133]) by cia.cisco.com (Mirapoint) with ESMTP id ACF93616; Mon, 28 Apr 2003 16:31:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20030428162616.0503dcf0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 28 Apr 2003 16:31:50 -0400 To: "Dean Willis" From: Michael Hammer Subject: Re: [Sipping] Commentary on draft-niemi-sipping-event-throttle-reqs Cc: , "Aki Niemi" , , "David Oran" In-Reply-To: <001101c30acd$c1af7220$ee036e3f@txdwillis> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Dean,

I would need to refresh my memory on this, but isn't the strict rate mechanism just a sub-case of the leaky-bucket one, i.e. one where the token bucket has a maximum size of one token?

I also have a serious case of deja-vu on the minumum server - maximum receiver discussion.  Previous worked out protocols on this (related to timers) should be re-used, no?

Mike


At 08:55 PM 4/24/2003 -0500, Dean Willis wrote:

At the last meeting, we agreed (well, actually Rohan volunteered us) that we
would look at the event throttling requirements draft, and that at least a
couple of us would post discussions before we considered taking it on as a
WG effort. So here's my try at it.

The given draft is:

http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttle-reqs-
01.txt


Overall, I think that developing an event throttling mechanism is a good
idea, and that this draft is a reasonable start on the requirements.

General comment: The draft seems to confuse the maximum notification rate
"desired" or "allowed" by the subscriber with the rate "required" by the
notifier. I'll come back to this at several points in the discussion. There
also seems to be a bit of confusion on the difference between average rates
and minimum interval -- they're not exactly inverses of each other. English
is such a fun language -- too bad it doesn't work well for specifications.

Section 3: Event Throttle Model

This section raises two throttling models, which it identifies as "strict"
and "leaky bucket" quarantines.

The usage of the "strict" model should be clarified as establishing the
minimum time period allowed between two notifications. The draft says that
the choice of which notification is sent is implementation dependent,
although it seems to assume a "newest" notification, where "newer"
notifications replace "older" ones if the minimum notification interval time
has not elapsed. I suspect that this replacement model has a lot of overlap
with filtering. Should we explicitly include a requirement that the
replacement policy be describable in the subscription process?

This section also refers to what it calls a "leaky bucket style algorithm",
which is probably a misnomer. Traditionally (at least in my pointy head) a
"leaky bucket" refers to a FIFO queue with a variable arrival rate and a
fixed departure rate. There might be input "bursts" at a rate higher than
the output rate, resulting in a lengthening of the queue, but the output
rate is held constant as long as the queue length is non-zero. However, the
policy described in the draft is one of rate-averaging, which is something
like a leaky-bucket that kicks in only if the sliding-window average rate
exceeds the prescribed maximum. This could use some cleanup.

Additionally, one might envision a rate-averaging queue that enforces its
operation by discarding or combining notifications instead of delaying them.


So basically, there are two queue models proposed:

1) minimum fixed interval or period between notifications, where the
interval can be described as a time value like 5 seconds. This can also be
described as maximum fixed rate, or notifications per unit of time, like 0.2
notifications per second or 1 notification per 5 seconds (oddly enough, this
is the reciprocal of the minimum interval)

2) minimum average interval or period between notifications, which is better
described as the maximum average rate of notifications and best described in
notifications per unit of time, averaged over some time window.

And two reasonable queue-servicing policies:

1) Delay notifications in a FIFO manner to conform to policy.

2) Discard out-of-profile notifications or combine them with other
notifications to result in a notification stream that conforms to policy.

Note that policy 1 can result in increasing queue depth if the arrival rate
persists in exceeding the departure rate. Consequently, practical systems
using 1 are likely to revert to 2 at some point. Efficiency may also be
improvable by using a quenching mechanism to reduce the arrival rate.


Section 4, Example Use Case:

This doesn't really describe a use case, but just presents us with the
mathematical notation of the reciprocal relationship between frequency and
period. Useful background, but a real use case (with actors, etc.) would be
nice here too.

Perhaps something like:

Case 1: Alice subscribes to the status of Bob. Bob's status is served by
server S. Alice tells S (subscribes with a notification throttling policy)
that she wishes to receive notifications no more frequently than once every
five seconds. Bob publishes a status of Red to the server S, which notifies
Alice.

Sub case a: After a delay of three seconds, Bob publishes a status of Green
to S. S, which implements a policy of discarding out-of-profile
notifications, stores the status of Green but does not notify Alice. After
three more seconds, Bob publishes a status of Blue to S. Since six seconds
have elapsed since the last notification to Alice, S notifies Alice that
Bob's status is now Blue. Note that in this sub-case, Alice is never
notified that Bob's status was Green, but the notifications that she does
receive are timely.

Sub case b: After a delay of three seconds, Bob publishes a status of Green
to S. S, which implements of policy of delaying out-of-profile notifications
so that they become compliant, stores the status of Bob. After two more
seconds, S notifies Alice that Bob's status is now Green. One second later,
Bob publishes a status of Blue. Again, S stores the new state for Bob, but
does not immediately notify Alice. Four seconds later, S notifies Alice that
Bob's status is now Blue. Note that in this sub-case, Alice is notified of
all statuses published by Bob, but often has a different understanding of
Bob's status than does Bob, because the notifications from S to Alice are
delayed.


REQ3:

Says that "The notifier must be able to indicate that it does not support
the use of a throttle mechanism in the subscription. This would be better
worded as ". . . for a specific subscription", otherwise we'll have people
thinking "in the subscription" means "in the SUBSCRIBE", when we all know it
would have to be "in the response to the SUBSCRIBE".

REQ6:

Ends in "For example, local policy could dictate an even lower rate of
notification than what the subscriber requires." Refer back to my General
Comment earlier in this missive. It seems to me that this would be better
worded as " . . . what the subscriber allows". I think we're having a
tendency to get confused about what the rate limit is asking for. The
subscriber is saying "I want to receive notifications no more frequently
than once per X seconds", not "You MUST notify me EVERY X seconds."

REQ7:

Says that security mechanisms "SHOULD be applied to subscriptions . . . ".
This is trying to define operational guidelines at protocol requirements
time. Rather, we should word this sort of thing to require a capability to
be met by the mechanism to be developed. Perhaps "A throttle mechanism MUST
allow for the application of authentication and integrity protection
mechanisms to subscriptions invoking that mechanism."


Section 6: Security Requirements

Issue 1 points out that it might be possible for a subscriber to set a
maximum notification interval longer than the subscription duration,
consequently resulting in only getting one notification per subscription.
Should we add a new requirement on the order of "A notifier receiving a
subscription request including throttling policy MUST be able to response
with something having the semantic of 'That's a really freaking stupid
idea'.? Or should we add a requirement more like "A throttling mechanism
MUST include discussion of the situation resulting from a minimum
inter-notification period which exceeds the subscription duration and
include mechanisms for avoiding this situation and/or guidance to
implementers on the dangers of getting exactly what they asked for"?

Issue 2 raises the possibility that a subscriber might set a very short
minimum inter-notification period (or very high maximum notification rate),
thereby causing the notifier to exhaust itself sending at that frequency.
This is, well, bogus. As I pointed out above, the throttling policy does not
tell the notifier the rate at which notifications should be sent. Rather, it
tells the server the rate that notifications must not exceed. This is
something like a traffic sign. If the sign on the street says "Speed Limit:
30 kph", this does not force all cards to speed up to 30 kph. In most
situations (barring a few large motorways that have a SEPARATE policy for
minimum speeds) driving at 28 kph, or even 20 kph, would be just fine.

Conclusion: Note that there is considerable potential for confusion between
frequency (or rate) and period (or interval) in this conversation. We should
be careful to say explicitly what we mean. Is it feasible to use just one
term in all discussions? I have the feeling that SIP is not likely to be
well-suited to exceptionally frequent notifications. Is it reasonable to
state a minimum period in seconds? This lets us use a signed-16 range to
express inter-notification periods ranging from 1 second to a little over 9
hours. Do we need higher resolution than that? There's probably a resolution
requirement that needs to be stated in this draft.

--
Dean





_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP
_______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 28 23:47:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23820 for ; Mon, 28 Apr 2003 23:47:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3T3qqt13011 for sipping-archive@odin.ietf.org; Mon, 28 Apr 2003 23:52:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T3qq813008 for ; Mon, 28 Apr 2003 23:52:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23810 for ; Mon, 28 Apr 2003 23:47:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AM7j-0007WB-00 for sipping-web-archive@ietf.org; Mon, 28 Apr 2003 23:49:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AM7i-0007W8-00 for sipping-web-archive@ietf.org; Mon, 28 Apr 2003 23:49:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T3pE812956; Mon, 28 Apr 2003 23:51:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N37Q802013 for ; Tue, 22 Apr 2003 23:07:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04883 for ; Tue, 22 Apr 2003 22:55:05 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198ARq-0007Cj-00 for sipping@ietf.org; Tue, 22 Apr 2003 22:57:26 -0400 Received: from imo-m02.mx.aol.com ([64.12.136.5]) by ietf-mx with esmtp (Exim 4.12) id 198ARm-0007CQ-00 for sipping@ietf.org; Tue, 22 Apr 2003 22:57:22 -0400 Received: from AndrewAllen007@aol.com by imo-m02.mx.aol.com (mail_out_v34.22.) id l.94.36eb4538 (4116); Tue, 22 Apr 2003 22:56:03 -0400 (EDT) Message-ID: <94.36eb4538.2bd75ac3@aol.com> Date: Tue, 22 Apr 2003 22:56:03 EDT Subject: [Sipping] Some thoughts and comments regarding draft-sinnreich-sipdev-req-00 To: sipping@ietf.org CC: AndrewAllen007@aol.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_94.36eb4538.2bd75ac3_boundary" X-Mailer: 8.0 for Windows sub 6011 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , --part1_94.36eb4538.2bd75ac3_boundary Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Henry, Sorry for the late comments (I only recently got to your draft). As someone who has been closely involved with application of SIP in the=20 mobile phone environment (3GPP) I have some concern with the initial version= =20 of draft-sinnreich-sipdev-req. Although the Abstract indicates that the scope of the draft includes mobile=20 phones the contents do not seem to take into account the needs of mobile=20 phones and the requirements in draft-garcia-sipping-3gpp-reqs-03. Specifically (but not necessarily a complete list): 1. The Link Layer Requirements only address Ethernet and wireless LAN and do= =20 not include 3GPP GSM/GPRS and UMTS or indeed other cellular access systems=20 such as CDMA 2000 systems. Mobile phones should not be required to support=20 Ethernet or WLAN access or though multiple mode devices may. Bluetooth and=20 other access technologies may also be supported. 2. The IP Requirements does not include IP address aquisition using GPRS/UMT= S=20 mechanisms as utilised by 3GPP. 3. SIP User Agent Services: SIP-13 client-based conferencing: SIP devices MUST be able to=20 =A0 support handset based conferencing.=A0 A SIP client MUST be able to=20 =A0 initiate and mix the audio streams of at least 2 separate calls (i.e.=20 =A0 3 way conference calling).=A0=20 Making this mandatory in the mobile environment is problematic because this=20 type of conferencing is not really suitable in the cellular environment wher= e=20 bandwith is scarce. 4. SIP-14 and the requirement that mandates G.711 is not acceptable in the=20 cellular environment where bandwidth is scarce. If a single mandator codec i= s=20 felt to be essential then it must be a cellular codec such as AMR (although=20= a=20 single cellular codec is not likely to be acceptable to all the other mobile= =20 standardisation organisations out there). In practice the use of transcoders= =20 in the network although undesirable is likely to be necessary as agreeing on= =20 a single mandatory codec is like mandating that everyone in the world must=20 speak English. A general comment is that the are a lot of MAYs in the draft. In my opinion=20 any option in the SIP or other IP protocols MAY be supported by any SIP=20 client and therefore are unnecessary to be specified here.=20 Another general comment is that a lot of the mandatory requirements seem to=20 me to be optional features not mandatory requirements (for instance Message=20 Waiting indicator). Some of these may be mandatory for certain types of=20 devices but not others.=20 I understand that specifying a minimum set of requirements will aid=20 interoperability and also assist in product comparision and procurement.=20 However I think that the one shoe fits all approach is not practical.=20 Therefore I would propose that classes of devices are defined and then=20 minimum requirements for each class are defined. For instance a SIP mobile phone would be a different class device from a PC=20 based SIP UA as would be a dedicated SIP phone. This I think would make the=20 draft more structured/readable and useful. The current draft already has=20 caveats that state that this requirement only applies to certain types of=20 device which I think reinforces that certain requirements only apply to=20 certain device classes. So I think that either the scope needs to be restricted to avoid applying to= =20 mobile phones or much more work needs to be done to include the requirements= =20 for the mobile phone class (which should be gathered from the 3GPP and other= =20 relevent specifcation body work or specified by reference to those wireless=20 specifcations). Some of the relevent specifcations from 3GPP are: TS 22.228, TS 23.228, TS 24.229 located at http://www.3gpp.org/ftp/specs/latest/Rel-5/ regards Andrew --part1_94.36eb4538.2bd75ac3_boundary Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Henry,

Sorry for the late comments (I only recently got to your draft).

As someone who has been closely involved with application of SIP in the mobi= le phone environment (3GPP) I have some concern with the initial version of=20= draft-sinnreich-sipdev-req.

Although the Abstract indicates that the scope of the draft includes mobile=20= phones the contents do not seem to take into account the needs of mobile pho= nes and the requirements in draft-garcia-sipping-3gpp-reqs-03.

Specifically (but not necessarily a complete list):

1. The Link Layer Requirements only address Ethernet and wireless LAN and do= not include 3GPP GSM/GPRS and UMTS or indeed other cellular access systems=20= such as CDMA 2000 systems. Mobile phones should not be required to support E= thernet or WLAN access or though multiple mode devices may. Bluetooth and ot= her access technologies may also be supported.

2. The IP Requirements does not include IP address aquisition using GPRS/UMT= S mechanisms as utilised by 3GPP.

3. SIP User Agent Services:
SIP-13 client-based conferencing: SIP devices MUST be able to
=A0 support handset based conferencing.=A0 A SIP client MUST be able to
=A0 initiate and mix the audio streams of at least 2 separate calls (i.e. =A0 3 way conference calling).=A0
Making this mandatory in the mobile environment is problematic because this=20= type of conferencing is not really suitable in the cellular environment wher= e bandwith is scarce.

4. SIP-14 and the requirement that mandates G.711 is not acceptable in the c= ellular environment where bandwidth is scarce. If a single mandator codec is= felt to be essential then it must be a cellular codec such as AMR (although= a single cellular codec is not likely to be acceptable to all the other mob= ile standardisation organisations out there). In practice the use of transco= ders in the network although undesirable is likely to be necessary as agreei= ng on a single mandatory codec is like mandating that everyone in the world=20= must speak English.

A general comment is that the are a lot of MAYs in the draft. In my opinion=20= any option in the SIP or other IP protocols MAY be supported by any SIP clie= nt and therefore are unnecessary to be specified here.

Another general comment is that a lot of the mandatory requirements seem to=20= me to be optional features not mandatory requirements (for instance Message=20= Waiting indicator). Some of these may be mandatory for certain types of devi= ces but not others.

I understand that specifying a minimum set of requirements will aid interope= rability and also assist in product comparision and procurement. However I t= hink that the one shoe fits all approach is not practical. Therefore I would= propose that classes of devices are defined and then minimum requirements f= or each class are defined.

For instance a SIP mobile phone would be a different class device from a PC=20= based SIP UA as would be a dedicated SIP phone. This I think would make the=20= draft more structured/readable and useful. The current draft already has cav= eats that state that this requirement only applies to certain types of devic= e which I think reinforces that certain requirements only apply to certain d= evice classes.

So I think that either the scope needs to be restricted to avoid applying to= mobile phones or much more work needs to be done to include the requirement= s for the mobile phone class (which should be gathered from the 3GPP and oth= er relevent specifcation body work or specified by reference to those wirele= ss specifcations).

Some of the relevent specifcations from 3GPP are:

TS 22.228, TS 23.228, TS 24.229 located at http://www.3gpp.org/ftp/specs/latest/Rel-5/

regards
Andrew


 --part1_94.36eb4538.2bd75ac3_boundary-- _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Mon Apr 28 23:48:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23834 for ; Mon, 28 Apr 2003 23:48:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3T3qss13027 for sipping-archive@odin.ietf.org; Mon, 28 Apr 2003 23:52:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T3qs813024 for ; Mon, 28 Apr 2003 23:52:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23814 for ; Mon, 28 Apr 2003 23:47:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AM7l-0007WH-00 for sipping-web-archive@ietf.org; Mon, 28 Apr 2003 23:49:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AM7l-0007WE-00 for sipping-web-archive@ietf.org; Mon, 28 Apr 2003 23:49:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T3pf812976; Mon, 28 Apr 2003 23:51:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OA47828097 for ; Thu, 24 Apr 2003 06:04:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09901 for ; Thu, 24 Apr 2003 06:01:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198dZa-0004Hk-00 for sipping@ietf.org; Thu, 24 Apr 2003 06:03:22 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 198dZa-0004Hh-00 for sipping@ietf.org; Thu, 24 Apr 2003 06:03:22 -0400 Received: from diamond.cs.columbia.edu (diamond.cs.columbia.edu [128.59.16.9]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h3OA3m3o008962 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 24 Apr 2003 06:03:49 -0400 (EDT) Received: from diamond.cs.columbia.edu (localhost [127.0.0.1]) by diamond.cs.columbia.edu (8.12.9/8.12.6) with ESMTP id h3OA3m1K000234; Thu, 24 Apr 2003 06:03:48 -0400 (EDT) Received: (from petkos@localhost) by diamond.cs.columbia.edu (8.12.9/8.12.9/Submit) id h3OA3g6V000233; Thu, 24 Apr 2003 06:03:42 -0400 (EDT) From: "Petri K. Koskelainen" Message-Id: <200304241003.h3OA3g6V000233@diamond.cs.columbia.edu> To: eburger@snowshore.com Date: Thu, 24 Apr 2003 06:03:42 -0400 (EDT) Cc: sipping@ietf.org X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sipping] Re: conf: comments on draft-koskelainen-sipping-conf-policy-req-00 Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Eric, Thanks for the comments and sorry about the late answer. > Clarify language of abstract. > I can't tell if CPCP is or is not mandatory and if there > are or are not other mechanisms to manipulate conference policy data. Will do. (CPCP is not mandatory since other mechanisms to manipulate conference policy exist) > REQ-A6 > What does it mean to terminate the conference instance > but keep the conference URI and attributes? What I meant was that the current conference instance is terminated, but the name (SIP URI) itself remains and the conference (with that SIP URI) may be restarted or reactivated later. Does this kind of feature makes any sense? Anyway, it seems that this feature is already possible without Req-A6 since req-A2 already says that it must be possible to associate policy attributes to a conference URI (and one attribute is active/inactive). So, it is possibly to turn "inactive" attribute on, which effectively means the same. Should we also specify in this document what exactly should happen when the conference mode changes to "inactive"? (For example, are users kicked-out or just put on hold, what happens to ACL-lists etc). I assume that static policy data (e.g. ACL lists) remain as is but it is always possible to clear all policy data when reactivating the conference. > Isn't that purely a matter of implementation policy? > Should not the requirement be "It MUST be possible to > have a conference URI with its associated policy data > irrespective of the state of the conference referenced by the URI."? I'll remove A6 altogether. Thanks, Petri _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Tue Apr 29 21:36:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20689 for ; Tue, 29 Apr 2003 21:36:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3U1fxX19439 for sipping-archive@odin.ietf.org; Tue, 29 Apr 2003 21:41:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U1fx819436 for ; Tue, 29 Apr 2003 21:41:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20683 for ; Tue, 29 Apr 2003 21:36:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AgYA-0002UW-00 for sipping-web-archive@ietf.org; Tue, 29 Apr 2003 21:38:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AgYA-0002US-00 for sipping-web-archive@ietf.org; Tue, 29 Apr 2003 21:38:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U1au818289; Tue, 29 Apr 2003 21:36:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U1Zb818209 for ; Tue, 29 Apr 2003 21:35:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20565 for ; Tue, 29 Apr 2003 21:29:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AgS0-0002SV-00 for sipping@ietf.org; Tue, 29 Apr 2003 21:32:00 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19AgRz-0002RL-00 for sipping@ietf.org; Tue, 29 Apr 2003 21:31:59 -0400 Received: from softarmor.com (bdsl.greycouncil.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h3U1Vxdg002138; Tue, 29 Apr 2003 20:31:59 -0500 Message-ID: <3EAF2781.60006@softarmor.com> Date: Tue, 29 Apr 2003 20:31:45 -0500 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Hammer CC: sipping@ietf.org, Aki Niemi , jdrosen@dynamcisoft.com, David Oran Subject: Re: [Sipping] Commentary on draft-niemi-sipping-event-throttle-reqs References: <4.3.2.7.2.20030428162616.0503dcf0@cia.cisco.com> In-Reply-To: <4.3.2.7.2.20030428162616.0503dcf0@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael Hammer wrote: > Dean, > > I would need to refresh my memory on this, but isn't the strict rate > mechanism just a sub-case of the leaky-bucket one, i.e. one where the > token bucket has a maximum size of one token? You could look at it this way. Aki actually proposes that there may be some sort of status combiner or aggregator "in the bucket" that generates "new" presence information based on more than one input to the bucket, so this is a little different than a classic leaky bucket. > I also have a serious case of deja-vu on the minumum server - maximum > receiver discussion. Previous worked out protocols on this (related to > timers) should be re-used, no? You mean the wildly successful session timer work? ;-) -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 30 12:07:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10238 for ; Wed, 30 Apr 2003 12:07:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UGDU623758 for sipping-archive@odin.ietf.org; Wed, 30 Apr 2003 12:13:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UGDU823755 for ; Wed, 30 Apr 2003 12:13:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10233 for ; Wed, 30 Apr 2003 12:07:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Au9H-0000sv-00 for sipping-web-archive@ietf.org; Wed, 30 Apr 2003 12:09:35 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Au9G-0000ss-00 for sipping-web-archive@ietf.org; Wed, 30 Apr 2003 12:09:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UG6n821843; Wed, 30 Apr 2003 12:06:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UG41821254 for ; Wed, 30 Apr 2003 12:04:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09936 for ; Wed, 30 Apr 2003 11:57:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Au06-0000oo-00 for sipping@ietf.org; Wed, 30 Apr 2003 12:00:06 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19Au04-0000oI-00 for sipping@ietf.org; Wed, 30 Apr 2003 12:00:06 -0400 Received: from cia.cisco.com (IDENT:mirapoint@cia.cisco.com [64.100.238.51]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3UG06DP005821; Wed, 30 Apr 2003 12:00:07 -0400 (EDT) Received: from mhammer-w2k02.cisco.com (dhcp-hrn-64-100-229-133.cisco.com [64.100.229.133]) by cia.cisco.com (Mirapoint) with ESMTP id ACG13206; Wed, 30 Apr 2003 12:00:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20030430115713.00b89b38@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Apr 2003 12:00:03 -0400 To: Dean Willis From: Michael Hammer Subject: Re: [Sipping] Commentary on draft-niemi-sipping-event-throttle-reqs Cc: sipping@ietf.org, Aki Niemi , jdrosen@dynamcisoft.com, David Oran In-Reply-To: <3EAF2781.60006@softarmor.com> References: <4.3.2.7.2.20030428162616.0503dcf0@cia.cisco.com> <4.3.2.7.2.20030428162616.0503dcf0@cia.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Dean, Someone once defined insanity as repeating the same painful process and expecting a new outcome. Do you expect a different outcome? :) Mike At 08:31 PM 4/29/2003 -0500, Dean Willis wrote: >Michael Hammer wrote: > >>Dean, >>I would need to refresh my memory on this, but isn't the strict rate >>mechanism just a sub-case of the leaky-bucket one, i.e. one where the >>token bucket has a maximum size of one token? > >You could look at it this way. Aki actually proposes that there may be >some sort of status combiner or aggregator "in the bucket" that generates >"new" presence information based on more than one input to the bucket, so >this is a little different than a classic leaky bucket. > >>I also have a serious case of deja-vu on the minumum server - maximum >>receiver discussion. Previous worked out protocols on this (related to >>timers) should be re-used, no? > >You mean the wildly successful session timer work? ;-) > >-- >Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From mailnull@www1.ietf.org Wed Apr 30 16:35:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23105 for ; Wed, 30 Apr 2003 16:35:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UKekj02247 for sipping-archive@odin.ietf.org; Wed, 30 Apr 2003 16:40:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UKek802244 for ; Wed, 30 Apr 2003 16:40:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23055 for ; Wed, 30 Apr 2003 16:32:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AyHO-0003Le-00 for sipping-web-archive@ietf.org; Wed, 30 Apr 2003 16:34:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AyHO-0003Lb-00 for sipping-web-archive@ietf.org; Wed, 30 Apr 2003 16:34:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UKav800703; Wed, 30 Apr 2003 16:36:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UKWi824507 for ; Wed, 30 Apr 2003 16:32:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22819 for ; Wed, 30 Apr 2003 16:26:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ay94-0003Hs-00 for sipping@ietf.org; Wed, 30 Apr 2003 16:25:38 -0400 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 19Ay8z-0003HS-00 for sipping@ietf.org; Wed, 30 Apr 2003 16:25:33 -0400 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h3UKPDdg010399 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 30 Apr 2003 15:25:14 -0500 From: "Dean Willis" To: "'Michael Hammer'" Cc: , "'Aki Niemi'" , , "'David Oran'" Subject: RE: [Sipping] Commentary on draft-niemi-sipping-event-throttle-reqs Date: Wed, 30 Apr 2003 15:25:12 -0500 Message-ID: <000a01c30f56$9b2f5380$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-reply-to: <4.3.2.7.2.20030430115713.00b89b38@cia.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sipping-admin@ietf.org Errors-To: sipping-admin@ietf.org X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIPPING Working Group (applications of SIP) List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Someone once defined insanity as repeating the same painful > process and > expecting a new outcome. Do you expect a different outcome? :) > Given that we are now in a state of either partial non-consensus or confusion on the utility of the session-timer work, I don't really expect different results but question whether that path can be expected to bear useful fruit. Perhaps the path less-chosen will prove more useful, or at least not so muddy. -- Dean _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP