From sip-admin@ietf.org Wed Aug 1 01:38:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02601 for ; Wed, 1 Aug 2001 01:38:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08649; Wed, 1 Aug 2001 01:16:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08616 for ; Wed, 1 Aug 2001 01:16:51 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29298 for ; Wed, 1 Aug 2001 01:15:50 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f715GiN08300; Wed, 1 Aug 2001 07:16:45 +0200 (MEST) Received: from lmf.ericsson.se (lmf00225pc.lmf.ericsson.se [131.160.30.24]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f715Gi528394; Wed, 1 Aug 2001 08:16:44 +0300 (EET DST) Message-ID: <3B6790BB.5504972D@lmf.ericsson.se> Date: Wed, 01 Aug 2001 08:16:43 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Gonzalo Camarillo , sip@ietf.org, mmusic , Colin Perkins , Jonathan Rosemberg Subject: Re: [Sip] Re: SDP hold References: <3B670282.4E3F57FB@lmf.ericsson.se> <3B672171.684C8D42@cisco.com> <3B67285F.AE7C83F6@lmf.ericsson.se> <3B673246.596702B5@cisco.com> Content-Type: multipart/mixed; boundary="------------A826358D2101C03A63CF8B14" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------A826358D2101C03A63CF8B14 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Can't we use the "inactive" tag, so we don't have to define a new? "Inactive" is used by both MGCP and MEGACO when a connection is created, but no media is supposed to be sent nor received, so maybe it would be a good idea to use the same tag also for SIP. Regards, Christer Holmberg Ericsson Finland Paul Kyzivat wrote: > > Gonzalo Camarillo wrote: > > > > Hello, > > > > > I know I will remember eventually, but can you remind me of such a > > > scenario? I think I recall some cases where you invite on hold, and then > > > reinvite. But when would this be used rather than inviting without SDP? > > > > Actually you INVITE without SDP and get an SDP in the 200 OK. Now you > > MUST send an SDP in the ACK. > > > > You MAY try to send an INVITE with the SDP just obtained to the other > > party and expect the 200 OK to arrive quickly enough. That is, before > > the fist party gets tired of retransmitting the 200 OK without getting > > an ACK. > > > > Luckily you have another option. When you receive the 200 OK from your > > first INVITE without SDP, you send an ACK with SDP 0.0.0.0 (hold). Then > > you INVITE the other party and get his SDP. Now you can re-INVITE the > > first party. > > OK, that makes some sense. But it is problematic unless it can be > depended upon to work all the time, with any type of media. (The 3pcc > may not understand the media being used by the endpoints.) I am not sure > this is the case. > > Also, isn't there a potential problem with this technique? > After you re-INVITE the first party with the SDP from the other party, > the SDP you get back may not be the same as it was in the first invite. > If not, then you have to reinvite the other party again. This process > may never terminate. > > Seems like it would be better to count on turning around the invite to > the other party before the first party times out. It takes a long time > to timeout, so this shouldn't usually be a problem. > > > > > > Where this isn't sufficient, it might be better to simply invite without > > > any media sessions at all, just to establish a signalling relationship. > > > (But I don't believe that is technically legal at the moment.) > > > > You INVITE without any media description. The thing is that since you > > will get media description in the 200 OK, you MUST send an SDP in your > > ACK. > > What I meant was that you might invite with the intent of establishing a > call that has no media sessions. It isn't straightforward to do, since > if you offer SDP that contains no m= lines it is like offering no SDP. > You can probably do it by offering an SDP with "m=xxx 0 ...", but > probably most UAs would reject this as useless. And in any case it > wouldn't serve your purpose. > > Paul > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------A826358D2101C03A63CF8B14 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------A826358D2101C03A63CF8B14-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 02:35:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18804 for ; Wed, 1 Aug 2001 02:35:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09831; Wed, 1 Aug 2001 02:13:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09804 for ; Wed, 1 Aug 2001 02:13:36 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15361 for ; Wed, 1 Aug 2001 02:12:33 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f716C0w3025526; Wed, 1 Aug 2001 02:12:01 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 02:12:34 -0400 Message-ID: From: Jonathan Rosenberg To: "'John Lazzaro'" , sip@ietf.org Subject: RE: [Sip] update to nat traversal draft! Date: Wed, 1 Aug 2001 02:12:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: John Lazzaro [mailto:lazzaro@CS.Berkeley.EDU] > Sent: Tuesday, July 31, 2001 1:16 PM > To: sip@ietf.org > Subject: RE: [Sip] update to nat traversal draft! > > > > > > Jonathan Rosenberg writes > > > An interesting solution might be for the caller (and > callee) to always offer > > two alternate media streams (using the FID draft), one of > which is with its > > public address, and another with the private address. If > media starts > > arriving on the private address, it re-invites to disable > the stream on the > > public one. Actually, that is probably the most robust and simplest > > solution. Not sure FID gives you all the semantics you need > for this, > > though... > > Yes, the online gaming world uses this technique and it seems > to work > well, so there's some successful history with the general idea of > "send to both the public and private address and see what comes back > in the return packets on the same UDP port." For RTP, the trick is going to be to figure out which of the two succeeded when you start receiving packets. For regular unidirectional RTP, its not clear that the source address tells you much. For symmetric RTP, its easy if you are the active side (the source address in the media in the reverse direction matches one of the two places you sent media to). > Also, if the source > address on the return packet is neither the public or private address > that a third party has handed you, its an indication that the sender > is behind a NAT that is not a Full Cone NAT, I think (not > totally sure). That doesn't sound right... for all the nat cases it should be the address you sent to (at least for symmetric RTP). -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 02:38:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18899 for ; Wed, 1 Aug 2001 02:38:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09998; Wed, 1 Aug 2001 02:21:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09973 for ; Wed, 1 Aug 2001 02:21:40 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16773 for ; Wed, 1 Aug 2001 02:20:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f716L0w3025551; Wed, 1 Aug 2001 02:21:00 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 02:21:34 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gonzalo Camarillo'" , sip@ietf.org, mmusic , Colin Perkins Date: Wed, 1 Aug 2001 02:21:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] RE: SDP hold Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, July 31, 2001 3:10 PM > To: sip@ietf.org; mmusic; Colin Perkins; Jonathan Rosemberg > Subject: SDP hold > > > Hello, > > I am sending this mail to SIP and MMUSIC because both groups are > interested in this issue. Sorry if somebody receives it twice. > > We have already agreed that the SDP 0.0.0.0 mechanism for putting the > other party on hold does not work because it does not provide > an address > for RTCP. Therefore, we need a new mechanism for putting on hold. > > It seems that the best proposal is to use the direction tag (sendonly, > sendrecv, recvonly) to do this. It has been proposed to define a new > direction tag value that would mean that the media stream > will not carry > media (neither-send-nor-receive). This could be encoded as a=nomedia, > for instance. Just to be clear, you do not need a new attribute for hold. In the current usage of 0.0.0.0, hold is unidirectional. As a result, using a=sendonly is the appropriate way to replace this functionality. There is also a need, I think, to indicate that a media stream is temporarily disabled (in which case there is neither RTP or RTCP in either direction). But, this is not needed for hold. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 02:42:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18980 for ; Wed, 1 Aug 2001 02:42:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09883; Wed, 1 Aug 2001 02:14:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09854 for ; Wed, 1 Aug 2001 02:14:38 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15576 for ; Wed, 1 Aug 2001 02:13:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f716E2w3025533; Wed, 1 Aug 2001 02:14:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 02:14:36 -0400 Message-ID: From: Jonathan Rosenberg To: "'Billy Biggs'" , Jonathan Cumming Cc: SIP List Subject: RE: [Sip] Re-use of Call-ID in the SIP Replaces header Date: Wed, 1 Aug 2001 02:14:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Billy Biggs [mailto:billy@billybiggs.com] > Sent: Tuesday, July 31, 2001 10:36 AM > To: Jonathan Cumming > Cc: SIP List > Subject: Re: [Sip] Re-use of Call-ID in the SIP Replaces header > > > Jonathan Cumming (jrc@dataconnection.com): > > > In section 2.2 of draft-biggs-sip-replaces-01, you specify that "A > > unique call-id may be given to the replacement call.". This seems > > unnecessarily weak and could lead to interoperability problems where > > an application assumes the re-use of the Call-ID. > > > > If a unique Call-ID is required, as specified in RFC 2543, then why > > give the end-point the option to re-use the existing Call-ID? > > When we were first discussing methods of performing attended call > transfer, there was alot of discussion about using the Call-ID to > perform the replaces operation, that is, the replacement call (or > joining call) would be identified by having the same Call-ID as an > existing call. > > So, the text should really read "in our replaces model, a unique > call-id may be given to the replacement call, instead of > previous models > which overloaded the meaning of the call-id". I wasn't trying to > dictate behavior either way. "may" is not strong enough. I think the consensus was to continue to have call-ids be unique, in which case the replacement call MUST use a new call-id. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 02:48:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19068 for ; Wed, 1 Aug 2001 02:48:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10601; Wed, 1 Aug 2001 02:37:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10572 for ; Wed, 1 Aug 2001 02:37:11 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18852 for ; Wed, 1 Aug 2001 02:36:10 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f716aFw3025574; Wed, 1 Aug 2001 02:36:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 02:36:49 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gonzalo Camarillo'" , sip@ietf.org Cc: adam.roach@ericsson.com, Jonathan Rosenberg Date: Wed, 1 Aug 2001 02:36:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] RE: 489 status code Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, July 31, 2001 3:39 PM > To: sip@ietf.org > Cc: adam.roach@ericsson.com; Jonathan Rosemberg > Subject: 489 status code > > > Hello, > > A minor comment about 489 status code: In Adam's event draft it means > "Bad Event", and in Jonathan's early media draft it means "Request > Updated". Since both are just I-Ds this is not really an issue right > now, but when they advance to RFCs we will have to resolve this > conflict. To quote the great Homer Simpson: "Doh!" This problem is why bis-04 requests the creation of an IANA registry for response codes. However, I don't know if it can be established prior to publication of bis as an rfc, which is what we really want. I did ask IANA about that, but got no reply. Anyway, since Adam was there first, I will change this in the early media draft to something else. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 02:50:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19155 for ; Wed, 1 Aug 2001 02:50:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10073; Wed, 1 Aug 2001 02:23:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10044 for ; Wed, 1 Aug 2001 02:23:53 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17121 for ; Wed, 1 Aug 2001 02:22:52 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f716NIw3025561; Wed, 1 Aug 2001 02:23:18 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 02:23:52 -0400 Message-ID: From: Jonathan Rosenberg To: "'Christer Holmberg'" , Paul Kyzivat Cc: Gonzalo Camarillo , sip@ietf.org, mmusic , Colin Perkins Subject: RE: [Sip] Re: SDP hold Date: Wed, 1 Aug 2001 02:23:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I think that this is a good idea. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, August 01, 2001 1:17 AM > To: Paul Kyzivat > Cc: Gonzalo Camarillo; sip@ietf.org; mmusic; Colin Perkins; Jonathan > Rosemberg > Subject: Re: [Sip] Re: SDP hold > > > > Hi, > > Can't we use the "inactive" tag, so we don't have to define a new? > "Inactive" is used by both MGCP and MEGACO when a connection > is created, > but no media is supposed to be sent nor received, so maybe it > would be a > good idea to use the same tag also for SIP. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > Paul Kyzivat wrote: > > > > Gonzalo Camarillo wrote: > > > > > > Hello, > > > > > > > I know I will remember eventually, but can you remind > me of such a > > > > scenario? I think I recall some cases where you invite > on hold, and then > > > > reinvite. But when would this be used rather than > inviting without SDP? > > > > > > Actually you INVITE without SDP and get an SDP in the 200 > OK. Now you > > > MUST send an SDP in the ACK. > > > > > > You MAY try to send an INVITE with the SDP just obtained > to the other > > > party and expect the 200 OK to arrive quickly enough. > That is, before > > > the fist party gets tired of retransmitting the 200 OK > without getting > > > an ACK. > > > > > > Luckily you have another option. When you receive the 200 > OK from your > > > first INVITE without SDP, you send an ACK with SDP > 0.0.0.0 (hold). Then > > > you INVITE the other party and get his SDP. Now you can > re-INVITE the > > > first party. > > > > OK, that makes some sense. But it is problematic unless it can be > > depended upon to work all the time, with any type of media. > (The 3pcc > > may not understand the media being used by the endpoints.) > I am not sure > > this is the case. > > > > Also, isn't there a potential problem with this technique? > > After you re-INVITE the first party with the SDP from the > other party, > > the SDP you get back may not be the same as it was in the > first invite. > > If not, then you have to reinvite the other party again. > This process > > may never terminate. > > > > Seems like it would be better to count on turning around > the invite to > > the other party before the first party times out. It takes > a long time > > to timeout, so this shouldn't usually be a problem. > > > > > > > > > Where this isn't sufficient, it might be better to > simply invite without > > > > any media sessions at all, just to establish a > signalling relationship. > > > > (But I don't believe that is technically legal at the moment.) > > > > > > You INVITE without any media description. The thing is > that since you > > > will get media description in the 200 OK, you MUST send > an SDP in your > > > ACK. > > > > What I meant was that you might invite with the intent of > establishing a > > call that has no media sessions. It isn't straightforward > to do, since > > if you offer SDP that contains no m= lines it is like > offering no SDP. > > You can probably do it by offering an SDP with "m=xxx 0 ...", but > > probably most UAs would reject this as useless. And in any case it > > wouldn't serve your purpose. > > > > Paul > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 03:51:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21091 for ; Wed, 1 Aug 2001 03:51:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11576; Wed, 1 Aug 2001 03:17:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11541 for ; Wed, 1 Aug 2001 03:17:48 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20001 for ; Wed, 1 Aug 2001 03:16:47 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f717GCw3025605; Wed, 1 Aug 2001 03:16:12 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 03:16:46 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gonzalo Camarillo'" , adam.roach@ericsson.com Cc: "'Rosen, Brian'" , "'Michael Thomas'" , "'Henning Schulzrinne'" , Juan-Carlos.Rojas@alcatel.fr, Paul Kyzivat , Jay Batson , sip@ietf.org Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest proposa l.) Date: Wed, 1 Aug 2001 03:16:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, July 31, 2001 1:57 PM > To: adam.roach@ericsson.com > Cc: 'Rosen, Brian'; 'Michael Thomas'; 'Henning Schulzrinne'; > Juan-Carlos.Rojas@alcatel.fr; Paul Kyzivat; Jay Batson; sip@ietf.org > Subject: Re: Transcoding != B2BUA (was RE: [Sip] Forking: a modest > proposa l.) > > > Hello, > > > The list of protocols which are designed to say this sort of thing > > is rather short. I'll leave it as an exercise for the readers of > > this list to find any beyond those that have already been mentioned. > > An example of transcoder invokation using 3pcc can be found at: > http://www.hut.fi/~gonzalo/papers/draft-camarillo-3pcc-qos-00.txt > > Note that this is an already expired draft though. Actually, the hearing-impaired draft has some flows that involve end-user initiated transcoding using 3pcc: http://www.jdrosen.net/papers/draft-vanwijk-sipping-deaf-req-00.txt See section 6.2. -Jonathan R. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 04:09:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21749 for ; Wed, 1 Aug 2001 04:09:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12256; Wed, 1 Aug 2001 03:38:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12225 for ; Wed, 1 Aug 2001 03:38:19 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20574 for ; Wed, 1 Aug 2001 03:37:17 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f717bZw3025662; Wed, 1 Aug 2001 03:37:36 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 03:38:09 -0400 Message-ID: From: Jonathan Rosenberg To: "'Juha Heinanen'" , sip@ietf.org Subject: RE: [Sip] proxy routing of a request Date: Wed, 1 Aug 2001 03:38:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Comments inline. > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi] > Sent: Monday, July 30, 2001 5:03 AM > To: sip@ietf.org > Subject: [Sip] proxy routing of a request > > > ther first paragraph of chapter 16 of bis-03 says: > > Record routing is the process whereby a proxy server can request to > receive all messages between two UAs for a particular call leg. The > proxy accomplishes this by inserting a header, called > Record-Route into > the initial request that begins the call leg. The user agents > use these > headers to construct a set of Route headers, that gets inserted into > subsequent requests in the call leg. The Route headers > contain a set of > proxies that the request must visit on its way from one UA to > another. Proxies use these to forward the requests, much like > strict IP > source routing. > > the above is not true, since if an invite arrives at the uas with only > one proxy listed in the record-route, according to 16.2 the route-set > contains > > uri-from-the-record-route > uri-from-the-contact > > when the uas then sends a bye, according to 16.4 the request-uri will > contain the uri of the proxy that inserted the record-route and the > route header will contain the uri of the contact: > > The request is constructed as specified in Section 15.4. The UA then > takes the list of URI in the route set. The top URI is > inserted into the > request URI of the request, including all parameters. Any URI > parameters > not allowed in the request URI MUST then be stripped. Each of the > remaining URIs (if any) from the route set, including all URI > parameters, are placed into a Route header into the request, in order. > > as the result, the route header of the bye will not contain uri of the > the record-routing proxy as the first paragraph claims. > > one could say that the first paragraph just gives an overall idea of > what happens and is not intended as an accurate description. You are correct that the first paragraph is not technically correct. Although it is just meant to give an overall idea of operation, it should be right. I will fix it. the > problem, however, seems to be more than editorial, since if the uas is > using another proxy to route its requests, this other proxy will route > the bye according to 16.5 as follows: > > When a proxy receives a request, it MUST check for the existence of a > Route header. If one exists, it MUST pop that Route header, > and place it > (including all URI parameters) into the Request-URI. > > in this case the request-uri contains the uri of the proxy, but since > there is also a route header containing the contact uri, this other > proxy will forget the request-uri and route the bye directly > to the uac > that originally sent the invite. as the result, the very idea of the > record-routing proxy wanting to be on the path of subsequent requests > gets lost. > > section 16.4.1 talks about UAs and outbound proxies, but i don't see > that the text would change what i described above, since the main rule > still is: > > A UA which uses a local outbound proxy, and attempts to send > a subequent > request in a call leg with a route set, SHOULD use the procedures in > Section 16.4. > > the rest of the section seems to apply only to dns uncapable UAs. > > what is the point that i'm missing here? The bit about dns-uncapable UAs would apply. Basically, the rule is that if you don't send the request to the top element in the route set, don't pop it. dns-less UA is one case where this will happen, but not the only one. I'll clarify that. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 04:55:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22947 for ; Wed, 1 Aug 2001 04:55:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12603; Wed, 1 Aug 2001 03:52:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12578 for ; Wed, 1 Aug 2001 03:52:25 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21076 for ; Wed, 1 Aug 2001 03:51:23 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f717phw3025678; Wed, 1 Aug 2001 03:51:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 03:52:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Vijay Gurbani'" , Jonathan Rosenberg Cc: "'sip@ietf.org'" Subject: RE: [Sip] new I-D on recovery of UA failures Date: Wed, 1 Aug 2001 03:52:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Vijay Gurbani [mailto:vkg@lucent.com] > Sent: Monday, July 16, 2001 5:51 PM > To: Jonathan Rosenberg > Cc: 'sip@ietf.org' > Subject: Re: [Sip] new I-D on recovery of UA failures > > > Jonathan Rosenberg wrote: > > > > Folks, > > > > I've submitted an I-D to the archives which discusses the problem of > > "crash-and-restart" recovery in a SIP UA. It discusses broader, more > > interesting applications of the recovery mechanism, and details the > > requirements on how to do it effectively. > > Jonathan: > > Quick question: in Section 4, when UA3 cannot reconstitute a > call (after > UA2, the original UA, has failed), why does UA1 send a BYE? > Does sending a > BYE help at all? If UA3 could not reconstitute the call, it > will probably > not be able to process the BYE as well. It ties back into another discussion we've been having. In general, if A sends a re-INVITE to B and gets a 481, should it just consider the call down, or send a BYE? The consensus on the list was to send a BYE. There were several reasons for that: 1. we have a general rule that a non-2xx response to a re-invite does not mean the call is down, just that the re-invite failed. We don't want to special case 481. 2. There may be call stateful proxies that would like to see the BYE. 3. We should only have one way of ending a call once established - sending a BYE. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 05:52:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24576 for ; Wed, 1 Aug 2001 05:52:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15063; Wed, 1 Aug 2001 05:18:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14961 for ; Wed, 1 Aug 2001 05:18:06 -0400 (EDT) Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23580; Wed, 1 Aug 2001 05:16:57 -0400 (EDT) Received: from [213.122.168.213] (helo=tkw) by gadolinium.btinternet.com with smtp (Exim 3.22 #9) id 15Rs8b-00069E-00; Wed, 01 Aug 2001 10:17:58 +0100 Message-ID: <005b01c11a6a$e96d6240$0200000a@tkw> From: "Pete Cordell" To: , "'sip-ietf (E-mail)'" , , "SG16" , Cc: "Steve Davies" Date: Wed, 1 Aug 2001 10:03:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Sip] VoIP Traversal of Non-upgraded Firewall & NATs @ IETF Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dear All, I would like to have a meeting at the IETF (informal BOF?) discussing methods for VoIP and Multimedia over IP traversing non-upgraded firewalls and NATs. These methods are intended to supplement the firewall architecture, and not require upgrade to existing firewall/NAT components, or clients (and other infrastructure such as proxies). There is a draft discussing one proposal at: http://www.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-00.txt If others have ideas in this area, then please contact me and we can arrange some sort of agenda. (Although note that I will be out of contact until the Sunday before the IETF - i.e. this Sunday! - so we might have to organise this at the IETF.) I hope the format will be something like: - Overview presentation of method - How this is secure and maintains administrator control - (Repeat for each proposal) - Collect issues that need to be addressed before going to a formal BOF. (The modified agenda involves the final item being changed to 'chaos'!) At this stage I would like to avoid discussion about how this compares to MidCom and other approaches - such as Rosenberg's - as I think it will quickly turn into a blood bath. - We should save that for the formal BOF! I'm hoping to hold the meeting in: The King's Suite/Sandringham 1 on Thursday 17:45 -> 18:45, but I obviously haven't had a chance to check this with the organisers. Therefore, please look out for final details on the noticeboard, and probably the door of the King's Suite. I look forward to seeing you all, Pete. (P.S. Sorry for putting this on the SG16 and TIPHON lists, but I'm well aware that many of you attend the IETF and I wanted to make sure you had the opportunity to come along.) ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 07:15:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27035 for ; Wed, 1 Aug 2001 07:15:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17344; Wed, 1 Aug 2001 06:58:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17312 for ; Wed, 1 Aug 2001 06:58:16 -0400 (EDT) Received: from tomts12-srv.bellnexxia.net (tomts12.bellnexxia.net [209.226.175.56]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26572 for ; Wed, 1 Aug 2001 06:57:13 -0400 (EDT) Received: from cybertron.div8.net ([64.230.148.156]) by tomts13-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010731143007.BBDN17648.tomts13-srv.bellnexxia.net@cybertron.div8.net>; Tue, 31 Jul 2001 10:30:07 -0400 Received: from vektor by cybertron.div8.net with local (Exim 3.12 #1 (Debian)) id 15RacX-0000tv-00; Tue, 31 Jul 2001 10:35:41 -0400 Date: Tue, 31 Jul 2001 10:35:41 -0400 From: Billy Biggs To: Jonathan Cumming Cc: SIP List Subject: Re: [Sip] Re-use of Call-ID in the SIP Replaces header Message-ID: <20010731103541.A3458@dumbterm.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jrc@dataconnection.com on Tue, Jul 31, 2001 at 01:18:48PM +0100 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan Cumming (jrc@dataconnection.com): > In section 2.2 of draft-biggs-sip-replaces-01, you specify that "A > unique call-id may be given to the replacement call.". This seems > unnecessarily weak and could lead to interoperability problems where > an application assumes the re-use of the Call-ID. > > If a unique Call-ID is required, as specified in RFC 2543, then why > give the end-point the option to re-use the existing Call-ID? When we were first discussing methods of performing attended call transfer, there was alot of discussion about using the Call-ID to perform the replaces operation, that is, the replacement call (or joining call) would be identified by having the same Call-ID as an existing call. So, the text should really read "in our replaces model, a unique call-id may be given to the replacement call, instead of previous models which overloaded the meaning of the call-id". I wasn't trying to dictate behavior either way. > I suggest that "A unique call-id MUST be given to the replacement > call". Since this seems to be the modern consensus on the issue, I will clarify this in the draft. -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 07:32:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27845 for ; Wed, 1 Aug 2001 07:32:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17963; Wed, 1 Aug 2001 07:17:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17879 for ; Wed, 1 Aug 2001 07:17:12 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27053 for ; Wed, 1 Aug 2001 07:16:09 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id EAA24168 for ; Wed, 1 Aug 2001 04:17:10 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA18740 for ; Wed, 1 Aug 2001 04:17:10 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id <3XDB7761>; Wed, 1 Aug 2001 06:17:10 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E293@IL27EXM10.cig.mot.com> From: Baniel Uri-CUB001 To: "'sip@ietf.org'" Date: Wed, 1 Aug 2001 06:17:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] "t=" in 200 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Is it allowed for a UAS to change the original value of the SDP "t=" field in its 200 response? > ============================================= > Uri.Baniel@motorola.com, > Tel: (847) 632 4616; Fax: (847) 632 3963; > "I was down since I began to crawl" Cream 71 > ============================================= > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 07:40:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28118 for ; Wed, 1 Aug 2001 07:40:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18169; Wed, 1 Aug 2001 07:25:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18138 for ; Wed, 1 Aug 2001 07:25:15 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27588 for ; Wed, 1 Aug 2001 07:24:12 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id EAA28391 for ; Wed, 1 Aug 2001 04:25:13 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA23140 for ; Wed, 1 Aug 2001 04:25:13 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 06:25:12 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E294@IL27EXM10.cig.mot.com> From: Baniel Uri-CUB001 To: "'sip@ietf.org'" Date: Wed, 1 Aug 2001 06:25:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] plain text in the 200 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org What would be the most appropriate way (fields) to return a short text message in a 200 OK (which its payload is occupied by a SDP element)? > ============================================= > Uri.Baniel@motorola.com, > Tel: (847) 632 4616; Fax: (847) 632 3963; > "I was down since I began to crawl" Cream 71 > ============================================= > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 07:53:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28517 for ; Wed, 1 Aug 2001 07:53:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18675; Wed, 1 Aug 2001 07:34:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18644 for ; Wed, 1 Aug 2001 07:34:35 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27885 for ; Wed, 1 Aug 2001 07:33:32 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f71BYHO27169; Wed, 1 Aug 2001 13:34:18 +0200 (MEST) Received: from lmf.ericsson.se (lmf00225pc.lmf.ericsson.se [131.160.30.24]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f71BYH509715; Wed, 1 Aug 2001 14:34:17 +0300 (EET DST) Message-ID: <3B67E937.BC0F22AD@lmf.ericsson.se> Date: Wed, 01 Aug 2001 14:34:15 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Baniel Uri-CUB001 CC: "'sip@ietf.org'" Subject: Re: [Sip] plain text in the 200 References: <35DBB8B7AC89D4118E98009027B1009B0137E294@IL27EXM10.cig.mot.com> Content-Type: multipart/mixed; boundary="------------D40D989D781E703A78ED9F57" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------D40D989D781E703A78ED9F57 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, You can use a MIME message body. Then you can include SDP, text and whatever else you want - all in the same message. The UAC must support MIME, of course. Regards, Christer Holmberg Ericsson Finland Baniel Uri-CUB001 wrote: > > What would be the most appropriate way (fields) to return a short text > message in a 200 OK (which its payload is occupied by a SDP element)? > > > ============================================= > > Uri.Baniel@motorola.com, > > Tel: (847) 632 4616; Fax: (847) 632 3963; > > "I was down since I began to crawl" Cream 71 > > ============================================= > > > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------D40D989D781E703A78ED9F57 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------D40D989D781E703A78ED9F57-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 07:56:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28613 for ; Wed, 1 Aug 2001 07:56:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18816; Wed, 1 Aug 2001 07:39:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18785 for ; Wed, 1 Aug 2001 07:39:13 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28020 for ; Wed, 1 Aug 2001 07:38:10 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id EAA27965 for ; Wed, 1 Aug 2001 04:39:11 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id EAA01696 for ; Wed, 1 Aug 2001 04:31:35 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 06:39:11 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E296@IL27EXM10.cig.mot.com> From: Baniel Uri-CUB001 To: "'Christer Holmberg'" , Baniel Uri-CUB001 Cc: "'sip@ietf.org'" Subject: RE: [Sip] plain text in the 200 Date: Wed, 1 Aug 2001 06:39:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org How do I exactly achieve that? Can I use multiple content-type field in the SIP header? -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Wednesday, August 01, 2001 6:34 AM To: Baniel Uri-CUB001 Cc: 'sip@ietf.org' Subject: Re: [Sip] plain text in the 200 Hi, You can use a MIME message body. Then you can include SDP, text and whatever else you want - all in the same message. The UAC must support MIME, of course. Regards, Christer Holmberg Ericsson Finland Baniel Uri-CUB001 wrote: > > What would be the most appropriate way (fields) to return a short text > message in a 200 OK (which its payload is occupied by a SDP element)? > > > ============================================= > > Uri.Baniel@motorola.com, > > Tel: (847) 632 4616; Fax: (847) 632 3963; > > "I was down since I began to crawl" Cream 71 > > ============================================= > > > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 08:05:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28876 for ; Wed, 1 Aug 2001 08:05:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18970; Wed, 1 Aug 2001 07:47:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18941 for ; Wed, 1 Aug 2001 07:47:46 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28297 for ; Wed, 1 Aug 2001 07:46:43 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f71BlhO04384; Wed, 1 Aug 2001 13:47:44 +0200 (MEST) Received: from lmf.ericsson.se (lmf00225pc.lmf.ericsson.se [131.160.30.24]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f71Blh510219; Wed, 1 Aug 2001 14:47:43 +0300 (EET DST) Message-ID: <3B67EC5D.1081BAA5@lmf.ericsson.se> Date: Wed, 01 Aug 2001 14:47:41 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Baniel Uri-CUB001 CC: "'sip@ietf.org'" Subject: Re: [Sip] plain text in the 200 References: <35DBB8B7AC89D4118E98009027B1009B0137E296@IL27EXM10.cig.mot.com> Content-Type: multipart/mixed; boundary="------------4FDD1A9B2639DB36D5D42814" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------4FDD1A9B2639DB36D5D42814 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >How do I exactly achieve that? Can I use multiple content-type field in the >SIP header? Yes. In draft-ietf-sip-isup-mime-10.txt you can read how it's done in SIP for ISUP message bodies. Of course you can also read the MIME RFCs. Christer Holmberg Ericsson Finland > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, August 01, 2001 6:34 AM > To: Baniel Uri-CUB001 > Cc: 'sip@ietf.org' > Subject: Re: [Sip] plain text in the 200 > > Hi, > > You can use a MIME message body. Then you can include SDP, text and > whatever else you want - all in the same message. The UAC must support > MIME, of course. > > Regards, > > Christer Holmberg > Ericsson Finland > > Baniel Uri-CUB001 wrote: > > > > What would be the most appropriate way (fields) to return a short text > > message in a 200 OK (which its payload is occupied by a SDP element)? > > > > > ============================================= > > > Uri.Baniel@motorola.com, > > > Tel: (847) 632 4616; Fax: (847) 632 3963; > > > "I was down since I began to crawl" Cream 71 > > > ============================================= > > > > > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip --------------4FDD1A9B2639DB36D5D42814 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------4FDD1A9B2639DB36D5D42814-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 11:10:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10544 for ; Wed, 1 Aug 2001 11:10:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23776; Wed, 1 Aug 2001 10:55:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23751 for ; Wed, 1 Aug 2001 10:55:52 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06955 for ; Wed, 1 Aug 2001 10:54:49 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f71EtlO15578; Wed, 1 Aug 2001 16:55:47 +0200 (MEST) Received: from lmf.ericsson.se (rmt160112.am.ericsson.se [138.85.160.112]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA18553; Wed, 1 Aug 2001 16:55:41 +0200 (MET DST) Message-ID: <3B681B37.B8350B4@lmf.ericsson.se> Date: Wed, 01 Aug 2001 18:07:35 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org, mmusic , Colin Perkins References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: SDP hold Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, > > It seems that the best proposal is to use the direction tag (sendonly, > > sendrecv, recvonly) to do this. It has been proposed to define a new > > direction tag value that would mean that the media stream > > will not carry > > media (neither-send-nor-receive). This could be encoded as a=nomedia, > > for instance. > > Just to be clear, you do not need a new attribute for hold. In the current > usage of 0.0.0.0, hold is unidirectional. As a result, using a=sendonly is > the appropriate way to replace this functionality. Yes, sendonly works if A puts B on hold in a sendrecv stream. However, if you have a recvonly stream and you want to put it on hold, you need the neither-send-nor-receive tag. > There is also a need, I think, to indicate that a media stream is > temporarily disabled (in which case there is neither RTP or RTCP in either > direction). But, this is not needed for hold. OK, we can call the "on hold" scenario I just described as a "temporarily disabled media" (the latter is probably more accurate). Anyway, we still need the new tag. I do not really care if we call it neithersendnorrecv, nomedia or inactive. However, as Christer suggested, in order to be consistent with other protocols we can use "inactive". Anyway, my question is: Colin, do you think that such a tag should be included in SDPnew? Otherwise we can write a half-page draft defining this attribute. Regards, Gonzalo > > -Jonathan R. > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 11:32:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16450 for ; Wed, 1 Aug 2001 11:32:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24398; Wed, 1 Aug 2001 11:12:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24372 for ; Wed, 1 Aug 2001 11:12:23 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10576 for ; Wed, 1 Aug 2001 11:11:13 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f71FC1N11522; Wed, 1 Aug 2001 17:12:01 +0200 (MEST) Received: from lmf.ericsson.se (rmt160112.am.ericsson.se [138.85.160.112]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id RAA19432; Wed, 1 Aug 2001 17:11:58 +0200 (MET DST) Message-ID: <3B681F06.F7CA70F0@lmf.ericsson.se> Date: Wed, 01 Aug 2001 18:23:50 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org, adam.roach@ericsson.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: 489 status code Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Yes, having an IANA registry for response codec would help have consistent specs. We will most likely use the "request updated" response code in the next version of the overlap draft, so we better be consistent :o) Regards, Gonzalo Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Tuesday, July 31, 2001 3:39 PM > > To: sip@ietf.org > > Cc: adam.roach@ericsson.com; Jonathan Rosemberg > > Subject: 489 status code > > > > > > Hello, > > > > A minor comment about 489 status code: In Adam's event draft it means > > "Bad Event", and in Jonathan's early media draft it means "Request > > Updated". Since both are just I-Ds this is not really an issue right > > now, but when they advance to RFCs we will have to resolve this > > conflict. > > To quote the great Homer Simpson: > > "Doh!" > > This problem is why bis-04 requests the creation of an IANA registry for > response codes. However, I don't know if it can be established prior to > publication of bis as an rfc, which is what we really want. I did ask IANA > about that, but got no reply. > > Anyway, since Adam was there first, I will change this in the early media > draft to something else. > > Thanks, > Jonathan R. > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 11:35:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16725 for ; Wed, 1 Aug 2001 11:35:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24161; Wed, 1 Aug 2001 11:01:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24132 for ; Wed, 1 Aug 2001 11:01:16 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07503 for ; Wed, 1 Aug 2001 11:00:12 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f71F13N06994; Wed, 1 Aug 2001 17:01:03 +0200 (MEST) Received: from lmf.ericsson.se (rmt160112.am.ericsson.se [138.85.160.112]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id RAA18787; Wed, 1 Aug 2001 17:00:59 +0200 (MET DST) Message-ID: <3B681C74.24E42161@lmf.ericsson.se> Date: Wed, 01 Aug 2001 18:12:52 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: sip@ietf.org, mmusic , Colin Perkins , Jonathan Rosemberg References: <3B670282.4E3F57FB@lmf.ericsson.se> <3B672171.684C8D42@cisco.com> <3B67285F.AE7C83F6@lmf.ericsson.se> <3B673246.596702B5@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: 3pcc question WAS SDP hold Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello Paul, Comments inline: Paul Kyzivat wrote: > > Gonzalo Camarillo wrote: > > > > Hello, > > > > > I know I will remember eventually, but can you remind me of such a > > > scenario? I think I recall some cases where you invite on hold, and then > > > reinvite. But when would this be used rather than inviting without SDP? > > > > Actually you INVITE without SDP and get an SDP in the 200 OK. Now you > > MUST send an SDP in the ACK. > > > > You MAY try to send an INVITE with the SDP just obtained to the other > > party and expect the 200 OK to arrive quickly enough. That is, before > > the fist party gets tired of retransmitting the 200 OK without getting > > an ACK. > > > > Luckily you have another option. When you receive the 200 OK from your > > first INVITE without SDP, you send an ACK with SDP 0.0.0.0 (hold). Then > > you INVITE the other party and get his SDP. Now you can re-INVITE the > > first party. > > OK, that makes some sense. But it is problematic unless it can be > depended upon to work all the time, with any type of media. (The 3pcc > may not understand the media being used by the endpoints.) I am not sure > this is the case. Have a look at the 3pcc draft. It contains the motivation for all the decisions that we have made. I believe that your concern was also included there. > Also, isn't there a potential problem with this technique? > After you re-INVITE the first party with the SDP from the other party, > the SDP you get back may not be the same as it was in the first invite. > If not, then you have to reinvite the other party again. This process > may never terminate. This problem is addressed by the latest version of the draft (02) > Seems like it would be better to count on turning around the invite to > the other party before the first party times out. It takes a long time > to timeout, so this shouldn't usually be a problem. > > > > > > Where this isn't sufficient, it might be better to simply invite without > > > any media sessions at all, just to establish a signalling relationship. > > > (But I don't believe that is technically legal at the moment.) > > > > You INVITE without any media description. The thing is that since you > > will get media description in the 200 OK, you MUST send an SDP in your > > ACK. > > What I meant was that you might invite with the intent of establishing a > call that has no media sessions. It isn't straightforward to do, since > if you offer SDP that contains no m= lines it is like offering no SDP. > You can probably do it by offering an SDP with "m=xxx 0 ...", but > probably most UAs would reject this as useless. And in any case it > wouldn't serve your purpose. > You can INVITE without SDP and then reject all the media streams offered in the 200 OK (by setting ports to zero in the ACK). However, if a UA receives an ACK that rejects allt he media streams, it might get confused. On the other hand, an ACK that puts streams on hold does not seem as surprising for the UA. Regards, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 11:54:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18069 for ; Wed, 1 Aug 2001 11:54:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24786; Wed, 1 Aug 2001 11:28:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24755 for ; Wed, 1 Aug 2001 11:28:16 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16028 for ; Wed, 1 Aug 2001 11:27:13 -0400 (EDT) Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f71FRvk25011 for ; Wed, 1 Aug 2001 11:27:57 -0400 (EDT) Received: by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA13157; Wed, 1 Aug 2001 11:27:50 -0400 (EDT) Cc: Paul Kyzivat , Gonzalo Camarillo , sip@ietf.org, mmusic , Colin Perkins , Jonathan Rosemberg Received: from lucent.com by wink.ho.lucent.com (8.9.3+Sun/EMS-1.5 sol2) id LAA13048; Wed, 1 Aug 2001 11:27:43 -0400 (EDT) Message-ID: <3B681F6A.F408723F@lucent.com> Date: Wed, 01 Aug 2001 11:25:30 -0400 From: Troy Cauble Reply-To: Troy Cauble X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Original-CC: Paul Kyzivat , Gonzalo Camarillo , sip@ietf.org, mmusic , Colin Perkins , Jonathan Rosemberg Subject: Re: [Sip] Re: SDP hold References: <3B670282.4E3F57FB@lmf.ericsson.se> <3B672171.684C8D42@cisco.com> <3B67285F.AE7C83F6@lmf.ericsson.se> <3B673246.596702B5@cisco.com> <3B6790BB.5504972D@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Yes. "inactive" is already commonly used in MGCP call waiting scenarios. -troy Christer Holmberg wrote: > > Hi, > > Can't we use the "inactive" tag, so we don't have to define a new? > "Inactive" is used by both MGCP and MEGACO when a connection is created, > but no media is supposed to be sent nor received, so maybe it would be a > good idea to use the same tag also for SIP. > > > What I meant was that you might invite with the intent of establishing a > > call that has no media sessions. It isn't straightforward to do, since > > if you offer SDP that contains no m= lines it is like offering no SDP. > > You can probably do it by offering an SDP with "m=xxx 0 ...", but > > probably most UAs would reject this as useless. And in any case it > > wouldn't serve your purpose. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 12:01:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18805 for ; Wed, 1 Aug 2001 12:01:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25176; Wed, 1 Aug 2001 11:33:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25125 for ; Wed, 1 Aug 2001 11:32:04 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16327 for ; Wed, 1 Aug 2001 11:31:01 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f71FVsO00783; Wed, 1 Aug 2001 17:31:54 +0200 (MEST) Received: from lmf.ericsson.se (rmt160112.am.ericsson.se [138.85.160.112]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id RAA20121; Wed, 1 Aug 2001 17:31:50 +0200 (MET DST) Message-ID: <3B6823AF.3C05AC0A@lmf.ericsson.se> Date: Wed, 01 Aug 2001 18:43:43 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'shh@ricochet.net'" , "Fairlie-Cuninghame, Robert" , "'sip@ietf.org'" Subject: Re: [Sip] update to nat traversal draft! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, > An interesting solution might be for the caller (and callee) to always offer > two alternate media streams (using the FID draft), one of which is with its > public address, and another with the private address. If media starts > arriving on the private address, it re-invites to disable the stream on the > public one. Actually, that is probably the most robust and simplest > solution. Not sure FID gives you all the semantics you need for this, > though... I believe it does. The syntax would look like this: a=group:FID 1 2 m=audio 10000 RTP/AVT 8 c=IN IP4 123.123.123.123 a=mid:1 m=audio 20000 RTP/AVT 8 c=IN IP4 10.0.0.1 a=mid:2 The application would send media to both addresses at the same time (in parallel), since both contain codec 8. Regards, Gonzalo > > > > > A secondary issue is that you would be exposing private IP addresses > > on the outside. > > How is that? The whole idea is that a public address is used in the SDP. > > > > > In the port sharing (on the AVT mailing list) case, with a VPN like > > tunnel, local calling (2 sip devices behind the same NAT) may require > > sending all packets across the WAN link and back. > > Yes, as I comment above, it is worse for the VPN case. > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 12:25:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20220 for ; Wed, 1 Aug 2001 12:25:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25991; Wed, 1 Aug 2001 12:00:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25733 for ; Wed, 1 Aug 2001 11:59:49 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18567 for ; Wed, 1 Aug 2001 11:58:45 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f71FxoI32137 for ; Wed, 1 Aug 2001 17:59:50 +0200 (CEST) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 0FCF9C112 for ; Wed, 1 Aug 2001 17:51:18 +0200 (CEST) Message-ID: <3B682831.5CC4F865@ccrle.nec.de> Date: Wed, 01 Aug 2001 18:02:57 +0200 From: Martin Stiemerling Organization: CCRLE, NEC Europe Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] DHCP option for SIP server Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, I'm currently working on DHCPv6 and I'm interested in one option proposed by Schulzrinne and Nair for DHCP (draft-ietf-sip-dhcp-04.txt). It is the DHCP Option for SIP Servers and it looks like this: Code Len DNS name of SIP server +-----+-----+-----+-----+-----+-----+-----+-- | TBD | n | s1 | s2 | s3 | s4 | s5 | ... +-----+-----+-----+-----+-----+-----+-----+-- As far as I see, is this option only for IPv4 (due to that code and len are only 8 bit long and in DHCPv6 these both are 16 bit). Is there any plan to make an option for DHCPv6? With best regards Martin Stiemerling -- *************************************************** Martin Stiemerling NEC Europe Ltd. Network Laboratories Europe Fon: +49 6221 90511 13 Fax: +49 6221 90511 55 _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 12:30:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20543 for ; Wed, 1 Aug 2001 12:30:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27065; Wed, 1 Aug 2001 12:18:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27034 for ; Wed, 1 Aug 2001 12:18:37 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19705 for ; Wed, 1 Aug 2001 12:17:33 -0400 (EDT) Received: from dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f71GHVw3003211; Wed, 1 Aug 2001 12:17:31 -0400 (EDT) Message-ID: <3B682BBC.85514593@dynamicsoft.com> Date: Wed, 01 Aug 2001 12:18:05 -0400 From: Anders Kristensen X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Baniel Uri-CUB001 , "'sip@ietf.org'" Subject: Re: [Sip] plain text in the 200 References: <35DBB8B7AC89D4118E98009027B1009B0137E294@IL27EXM10.cig.mot.com> <3B67E937.BC0F22AD@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit If you can squeeze your short text message into the reason phrase in the status line of the response you'll have a much better chance of interoperating than if you use multiparts. Anders Christer Holmberg wrote: > > Hi, > > You can use a MIME message body. Then you can include SDP, text and > whatever else you want - all in the same message. The UAC must support > MIME, of course. > > Regards, > > Christer Holmberg > Ericsson Finland > > Baniel Uri-CUB001 wrote: > > > > What would be the most appropriate way (fields) to return a short text > > message in a 200 OK (which its payload is occupied by a SDP element)? > > > > > ============================================= > > > Uri.Baniel@motorola.com, > > > Tel: (847) 632 4616; Fax: (847) 632 3963; > > > "I was down since I began to crawl" Cream 71 > > > ============================================= > > > > > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 13:26:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23332 for ; Wed, 1 Aug 2001 13:26:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28262; Wed, 1 Aug 2001 12:56:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28231 for ; Wed, 1 Aug 2001 12:56:30 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21847 for ; Wed, 1 Aug 2001 12:55:28 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA17511 for ; Wed, 1 Aug 2001 09:56:29 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA18588 for ; Wed, 1 Aug 2001 09:56:28 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id <3XDB8HBQ>; Wed, 1 Aug 2001 11:56:27 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E2A0@IL27EXM10.cig.mot.com> From: Baniel Uri-CUB001 To: "'Anders Kristensen'" , Christer Holmberg Cc: "'sip@ietf.org'" Subject: RE: [Sip] plain text in the 200 Date: Wed, 1 Aug 2001 11:56:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Sorry for my ignorance, but what is the status line of the response? ======================================================================= Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; "If it wasn't for bad luck, I would not have luck at all" - Cream 1968 ======================================================================= > -----Original Message----- > From: Anders Kristensen [mailto:akristensen@dynamicsoft.com] > Sent: Wednesday, August 01, 2001 11:18 AM > To: Christer Holmberg > Cc: Baniel Uri-CUB001; 'sip@ietf.org' > Subject: Re: [Sip] plain text in the 200 > > > If you can squeeze your short text message into the reason > phrase in the > status line of the response you'll have a much better chance of > interoperating than if you use multiparts. > > Anders > > > Christer Holmberg wrote: > > > > Hi, > > > > You can use a MIME message body. Then you can include SDP, text and > > whatever else you want - all in the same message. The UAC > must support > > MIME, of course. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Baniel Uri-CUB001 wrote: > > > > > > What would be the most appropriate way (fields) to return > a short text > > > message in a 200 OK (which its payload is occupied by a > SDP element)? > > > > > > > ============================================= > > > > Uri.Baniel@motorola.com, > > > > Tel: (847) 632 4616; Fax: (847) 632 3963; > > > > "I was down since I began to crawl" Cream 71 > > > > ============================================= > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the > application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 13:32:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23578 for ; Wed, 1 Aug 2001 13:32:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28815; Wed, 1 Aug 2001 13:10:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28784 for ; Wed, 1 Aug 2001 13:10:26 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22712 for ; Wed, 1 Aug 2001 13:09:22 -0400 (EDT) Received: from dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f71H9ew3003476; Wed, 1 Aug 2001 13:09:43 -0400 (EDT) Message-ID: <3B6837F6.7BAACA38@dynamicsoft.com> Date: Wed, 01 Aug 2001 13:10:14 -0400 From: Anders Kristensen X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Baniel Uri-CUB001 CC: Christer Holmberg , "'sip@ietf.org'" Subject: Re: [Sip] plain text in the 200 References: <35DBB8B7AC89D4118E98009027B1009B0137E2A0@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Baniel Uri-CUB001 wrote: > > Sorry for my ignorance, but what is the status line of the response? First line of responses, see section 9.1 of bis-04. Anders > > ======================================================================= > Uri.Baniel@motorola.com, > Tel: (847) 632 4616; Fax: (847) 632 3963; > "If it wasn't for bad luck, I would not have luck at all" - Cream 1968 > ======================================================================= > > > -----Original Message----- > > From: Anders Kristensen [mailto:akristensen@dynamicsoft.com] > > Sent: Wednesday, August 01, 2001 11:18 AM > > To: Christer Holmberg > > Cc: Baniel Uri-CUB001; 'sip@ietf.org' > > Subject: Re: [Sip] plain text in the 200 > > > > > > If you can squeeze your short text message into the reason > > phrase in the > > status line of the response you'll have a much better chance of > > interoperating than if you use multiparts. > > > > Anders > > > > > > Christer Holmberg wrote: > > > > > > Hi, > > > > > > You can use a MIME message body. Then you can include SDP, text and > > > whatever else you want - all in the same message. The UAC > > must support > > > MIME, of course. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > Baniel Uri-CUB001 wrote: > > > > > > > > What would be the most appropriate way (fields) to return > > a short text > > > > message in a 200 OK (which its payload is occupied by a > > SDP element)? > > > > > > > > > ============================================= > > > > > Uri.Baniel@motorola.com, > > > > > Tel: (847) 632 4616; Fax: (847) 632 3963; > > > > > "I was down since I began to crawl" Cream 71 > > > > > ============================================= > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 13:45:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24387 for ; Wed, 1 Aug 2001 13:45:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29023; Wed, 1 Aug 2001 13:24:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28993 for ; Wed, 1 Aug 2001 13:24:45 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23240 for ; Wed, 1 Aug 2001 13:23:43 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id NAA10494; Wed, 1 Aug 2001 13:24:35 -0400 (EDT) Message-ID: <3B683B4D.91BEF2E6@cs.columbia.edu> Date: Wed, 01 Aug 2001 13:24:29 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Martin Stiemerling CC: sip@ietf.org Subject: Re: [Sip] DHCP option for SIP server References: <3B682831.5CC4F865@ccrle.nec.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Martin Stiemerling wrote: > > Hello, > > I'm currently working on DHCPv6 and I'm interested in one option > proposed by Schulzrinne and Nair for DHCP (draft-ietf-sip-dhcp-04.txt). > It is the DHCP Option for SIP Servers and it looks like this: Well, we first have to get this sorry topic through the IESG... > > Code Len DNS name of SIP server > +-----+-----+-----+-----+-----+-----+-----+-- > | TBD | n | s1 | s2 | s3 | s4 | s5 | ... > +-----+-----+-----+-----+-----+-----+-----+-- > > As far as I see, is this option only for IPv4 (due to that code and len > are only 8 bit long and in DHCPv6 these both are 16 bit). Is there any > plan to make an option for DHCPv6? > No plan, but would be a good idea. Are you volunteering? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 1 13:56:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25043 for ; Wed, 1 Aug 2001 13:56:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29071; Wed, 1 Aug 2001 13:25:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29035 for ; Wed, 1 Aug 2001 13:25:01 -0400 (EDT) Received: from snap.CS.Berkeley.EDU (IDENT:root@snap.CS.Berkeley.EDU [128.32.37.81]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23256 for ; Wed, 1 Aug 2001 13:23:59 -0400 (EDT) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id KAA25493; Wed, 1 Aug 2001 10:24:10 -0700 Date: Wed, 1 Aug 2001 10:24:10 -0700 From: John Lazzaro Message-Id: <200108011724.KAA25493@snap.CS.Berkeley.EDU> To: jdrosen@dynamicsoft.com, lazzaro@CS.Berkeley.EDU, sip@ietf.org Subject: RE: [Sip] update to nat traversal draft! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > That doesn't sound right... for all the nat cases it should be the address > you sent to (at least for symmetric RTP). I'll be concrete here with an example, although I realize the details don't match your I-D that closely. Think of two clients, A and B, both of which are sending and receiving RTP on a single UDP port (lets not consider RTCP for now), and who are also communicating with a SIP server using that same UDP port. The SIP server is acting as a B2BUA conference server, shuffling SDP's between clients A and B to set up the session. No SIP proxies or ALGs in this scenareo. Each client sends in its SDP to the SIP server the IP/port it thinks it has. The SIP server can tell if the client is behind a NAT, and if so adds extra connection and media lines to the SDP whose port and IP number correspond to those it would add in the received and rport parameters of a Via. The SIP server sends this (potentially) modified SDP to the other client, who then uses it to start the RTP session, by sending RTP to both IP/ports sets in the SDP. This is happening for both clients, so initially -- client A is sending the first RTP wave to one or maybe 2 IP/ports for B -- client B is sending the first RTP wave to one or maybe 2 IP/ports for A In a world with static IP's and Full Cone NATs, I believe this first wave always has a happy ending -- whether both clients are behind a different NAT, both are behind the same NAT, or one or both have static IPs, each client will receive one of the two RTP packets sent by the other, and examining the IP/port reveals one of the two sources it also sent to. There's now enough knowledge to discard the useless address and just send on one channel. But consider the case where the clients are behind different NATs, but B's NAT isn't Full Cone -- it only lets in a UDP packet whose IP/port matches the IP/port destination address of the outgoing packet that established the binding. At the start of the session client A sends out his first wave of two RTP packets, but neither get to client B -- B's NAT discarded the packet that should have gotten through. Meanwhile, B's RTP wave is successful in getting to A, since A has a more sensible NAT. Client A is able to use the IP/port of the received packet to start sending data successfully back to B -- but: this IP/port will be different than both IP/ports it used to send to B the first time, I believe. And, to finish the story, the hopeless case seems to be when both client A and B are behind different NATs that aren't full cone, unless one of the clients is using a service provider that doesn't do egress filter, in which case source forging might work ... or else, of course, use a third party to shuttle every RTP packet. Is this scenareo too different from your I-D for the conclusions to apply, or is there an error in the logic above? ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 06:59:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21458 for ; Thu, 2 Aug 2001 06:59:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00260; Thu, 2 Aug 2001 05:26:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00227 for ; Thu, 2 Aug 2001 05:26:52 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA18178 for ; Thu, 2 Aug 2001 05:25:47 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f729QjI41070; Thu, 2 Aug 2001 11:26:46 +0200 (CEST) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 2349BC112; Thu, 2 Aug 2001 11:18:06 +0200 (CEST) Message-ID: <3B691D8F.C9F8361D@ccrle.nec.de> Date: Thu, 02 Aug 2001 11:29:51 +0200 From: Martin Stiemerling Organization: CCRLE, NEC Europe Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: sip@ietf.org, dhcp-v6@bucknell.edu Subject: Re: [Sip] DHCP option for SIP server References: <3B682831.5CC4F865@ccrle.nec.de> <3B683B4D.91BEF2E6@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Henning G. Schulzrinne" wrote: [...] > > are only 8 bit long and in DHCPv6 these both are 16 bit). Is there any > > plan to make an option for DHCPv6? > > > > No plan, but would be a good idea. Are you volunteering? Yes, I do. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- *************************************************** Martin Stiemerling NEC Europe Ltd. Network Laboratories Europe Fon: +49 6221 90511 13 Fax: +49 6221 90511 55 _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 09:16:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26071 for ; Thu, 2 Aug 2001 09:16:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03972; Thu, 2 Aug 2001 08:06:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA03944 for ; Thu, 2 Aug 2001 08:05:57 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23700 for ; Thu, 2 Aug 2001 08:04:52 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 13:05:03 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9DFD@RSYS002A> From: "Price, Richard" To: "'Aniruddha Kulkarni'" Cc: SIP mailing-list , RoHC mailing-list Date: Thu, 2 Aug 2001 13:05:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Sip] RE: EPIC Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi Aniruddha, We can implement "learning" EPIC in 3 ways: Offline version: Train the scheme offline for, say, SIP compression and put the resulting profile into an Internet Draft. Profiling version: Whilst performing SIP compression, dynamically update the profile at the compressor only. Periodically download the updated profile to the decompressor, and switch to the new profile when the download is complete. Dynamic version: Update the profile simultaneously at the compressor and decompressor. Note that as both the compressor and decompressor must see exactly the same packets, this only works over a reliable link. My own preference for SIP compression is just to use the offline version. If the profile becomes out-of-date then we suffer a slight drop in compression efficiency, but this is outweighed by the very low working memory requirements (as the SIP profile can be fixed in ROM). Richard P -----Original Message----- From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] Sent: Thursday, August 02, 2001 12:03 PM To: Price, Richard Cc: SIP mailing-list; RoHC mailing-list Subject: EPIC Hi Price I read about "learning" EPIC but I don't understand how a decompressor will know what a "learning" compressor has "learned" so far? I understand that both compressor and decompressor negotiate the profile and by that they know how other side will behave. But the compressor is "learning".. if I have understood it correct then "learning" would mean that the compressor will learn about new fields in the packets and add them to existing profile and other part is choosing compression scheme depending on probability of occurance of the field.. how does decompressor synchronize with that? How will this be handled in packet loss conditions? ---Aniruddha --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 10:13:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28305 for ; Thu, 2 Aug 2001 10:13:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02687; Thu, 2 Aug 2001 07:03:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02658 for ; Thu, 2 Aug 2001 07:03:16 -0400 (EDT) Received: from packer.effnet.com ([195.100.73.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21577 for ; Thu, 2 Aug 2001 07:02:11 -0400 (EDT) Received: from aniruddha (packer.effnet.com [195.100.73.130]) by packer.effnet.com (8.11.3/8.11.3) with SMTP id f72B73B19932; Thu, 2 Aug 2001 13:07:06 +0200 Message-ID: <01d201c11b42$a3573f00$710410ac@effnet.com> From: "Aniruddha Kulkarni" To: "Price Richard" Cc: "SIP mailing-list" , "RoHC mailing-list" Date: Thu, 2 Aug 2001 13:02:32 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CF_01C11B53.646C28D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [Sip] EPIC Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_01CF_01C11B53.646C28D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Price I read about "learning" EPIC but I don't understand how a = decompressor will know what a "learning" compressor has "learned" so = far?=20 I understand that both compressor and decompressor negotiate the = profile and by that they know how other side will behave. But the = compressor is "learning".. if I have understood it correct then = "learning" would mean that the compressor will learn about new fields in = the packets and add them to existing profile and other part is choosing = compression scheme depending on probability of occurance of the field.. = how does decompressor synchronize with that? How will this be handled in = packet loss conditions? ---Aniruddha ------=_NextPart_000_01CF_01C11B53.646C28D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Price
 
    I read about = "learning" EPIC but=20 I don't understand how a decompressor will know what a "learning" = compressor has=20 "learned" so far?
    I understand that = both=20 compressor and decompressor negotiate the profile and by that they know = how=20 other side will behave. But the compressor is "learning".. if I have = understood=20 it correct then "learning" would mean that the compressor will learn = about new=20 fields in the packets and add them to existing profile and other part is = choosing compression scheme depending on probability of occurance of the = field..=20 how does decompressor synchronize with that? How will this be handled in = packet=20 loss conditions?
 
---Aniruddha
------=_NextPart_000_01CF_01C11B53.646C28D0-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 10:56:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00203 for ; Thu, 2 Aug 2001 10:56:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05144; Thu, 2 Aug 2001 09:06:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05060 for ; Thu, 2 Aug 2001 09:06:16 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25726 for ; Thu, 2 Aug 2001 09:05:11 -0400 (EDT) Received: from mailhost.ubiquity.net by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 2 Aug 2001 13:06:14 UT Received: from neil ([193.195.52.214]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Thu, 2 Aug 2001 14:07:08 +0100 From: "Neil Deason" To: "Jonathan Rosenberg" , "'Juha Heinanen'" , Subject: RE: [Sip] proxy routing of a request Date: Thu, 2 Aug 2001 14:07:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: X-OriginalArrivalTime: 02 Aug 2001 13:07:08.0242 (UTC) FILETIME=[08D45320:01C11B54] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > [snip] > > The bit about dns-uncapable UAs would apply. Basically, the > rule is that if > you don't send the request to the top element in the route > set, don't pop > it. dns-less UA is one case where this will happen, but not > the only one. > I'll clarify that. To me this breaks the notion that pre-loaded routes are equivalent to strict source routing in IP. There are other things I don't like about the comparison, like the fact Route entries are urls, so could we lose the text making this comparison in 16.6? I am also interested in discussing more about what the other cases may be. I feel that a proxy might want to do this too. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 12:16:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04499 for ; Thu, 2 Aug 2001 12:16:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08143; Thu, 2 Aug 2001 11:17:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08114 for ; Thu, 2 Aug 2001 11:17:38 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01359 for ; Thu, 2 Aug 2001 11:15:50 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f72FHbI20197 for ; Thu, 2 Aug 2001 10:17:42 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 2 Aug 2001 10:16:43 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 2 Aug 2001 10:16:43 -0500 content-class: urn:content-classes:message Subject: RE: [rohc] RE: [Sip] SIP Compression Date: Thu, 2 Aug 2001 10:16:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [rohc] RE: [Sip] SIP Compression X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEbTHvAV5R9Loc/EdWBSQBQi2X+DwAFX3Zg To: , , Cc: , , X-OriginalArrivalTime: 02 Aug 2001 15:16:43.0359 (UTC) FILETIME=[232906F0:01C11B66] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA08115 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > How compression negotiation is done for SIP? It can be done either at SIP layer (by adding new headers/parameters) or at the compression layer (transparent to SIP). The latter is more generic as the same compression can be applied to application layer protocols other than SIP. > How does Proxy server know when to use compression > (as compression should be used only if there is cellular > link between proxy and end node)? The compression entity at a mobile UA and the compression entity at the proxy server need to initialize/negotiate (see above) the compression context before compression happens. This can be done, for example, when a mobile powers on or roaming to a new proxy server. After that, the proxy server will compress messages sent from/to the mobile. > when proxy server wants to connect to other end user, it > is starting session, does it know about link characteristics > between itself and the other end? No, it doesn't need to. The assumption is that each mobile pairs with a first-hop SIP proxy server (see above). BR, Zhigang > ---Aniruddha _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 13:24:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08207 for ; Thu, 2 Aug 2001 13:24:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07372; Thu, 2 Aug 2001 10:57:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07341 for ; Thu, 2 Aug 2001 10:57:53 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00233 for ; Thu, 2 Aug 2001 10:56:42 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 15:57:25 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9DFE@RSYS002A> From: "Price, Richard" To: "'Hans Hannu'" Cc: rohc@cdt.luth.se, sip@ietf.org Date: Thu, 2 Aug 2001 15:57:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Sip] RE: [rohc] Requirements for signaling compression Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, These requirements seem fine to me - assuming of course that SIP compression is performed on a per-hop basis. What about compression between a mobile and a SIP proxy? Is this beyond the scope of the ROHC WG? Regards, Richard P -----Original Message----- From: Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] Sent: Thursday, August 02, 2001 2:31 PM To: rohc Subject: [rohc] Requirements for signaling compression Hi, From the discussions I see that compression of SIP is the major concern all have, but maybe we should also look at the current version of the requirements document as we will discuss requirements in London, not only solutions. Chapter 3 of, http://www.ietf.org/internet-drafts/draft-ietf-rohc-signaling-req-assump-01. txt states the current requirements. There are most likely requirements missing and maybe not all are wanted... BR /Hans H --- Mailing list for Robust Header Compression WG Archive: http://www.cdt.luth.se/rohc/ --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 13:31:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08581 for ; Thu, 2 Aug 2001 13:31:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09196; Thu, 2 Aug 2001 11:58:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09168 for ; Thu, 2 Aug 2001 11:58:13 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03205 for ; Thu, 2 Aug 2001 11:57:07 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f72FZ3O14227; Thu, 2 Aug 2001 17:35:04 +0200 (MEST) Received: from lmf.ericsson.se (rmt160227.am.ericsson.se [138.85.160.227]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id RAA29607; Thu, 2 Aug 2001 17:35:00 +0200 (MET DST) Message-ID: <3B6975F4.7AEFC21E@lmf.ericsson.se> Date: Thu, 02 Aug 2001 18:47:00 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org, Jonathan Rosemberg Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Early media draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello Jonathan, I have read the early media draft again. I will give my opinion on some of the open questions that you have placed in the draft and I will make a proposal. The current mechanism effectively "trashes" the SDP contained in the first INVITE (and the SDP contained in re-INVITEs). Even if we are using a Require header and there would not be any backward compatibility problems, I do not like that. The current draft considers that when I add a media stream to the early media it means that I would like to have the same media stream added to the final media (media after the 200 OK). I would like to differentiate between early media and final media. That is, I can send you an INVITE with an audio media stream and a video media stream. You send me early media that consists of audio only. However, when you finally answer with a 200 OK, I want you to answer my original proposal (video+audio), not to renegotiate the parameters that we were using for early media. My proposal is that negotiation of final media and negotiation of early media are kept separate. That is, the SDP in the 200 OK will always be the answer to the SDP in the INVITE. Regardless of whether we are using early media or not (I believe that this is more consistent with bis). This would avoid media clipping when the 200 OK finally arrives, since the UAS can send media without waiting for the ACK. The process of changing early media parameters would have to be changed. Right now the UAC issues a re-INVITE. The SDP in this re-INVITE is effectively ignored (the real SDP exchange is 1xx-PRACK). My proposal is that the SDP in the re-INVITE is an update (or a refresh) of the SDP that was contained in the first INVITE. In short, I want the "INVITE-200 OK" SDP exchange to be independent of the "1xx-PRACK" SDP exchange. I believe that keeping both negotiations separate (early media parameters and final media parameters) is a powerful tool. I can update my final media SDP without updating my early media SDP and vice versa (or update both at the same time, of course). Opinions? Best regards, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 14:03:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10205 for ; Thu, 2 Aug 2001 14:03:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10206; Thu, 2 Aug 2001 12:03:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10175 for ; Thu, 2 Aug 2001 12:03:26 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03504 for ; Thu, 2 Aug 2001 12:02:22 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA29917 for ; Thu, 2 Aug 2001 09:03:24 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA23257 for ; Thu, 2 Aug 2001 09:03:24 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 11:03:04 -0500 Message-ID: <796456A0F96AD511A0AC009027B0F7410199AD4F@IL27EXM08.cig.mot.com> From: Ziyad Nigel-NZIYAD1 To: rohc@cdt.luth.se, sip@ietf.org Date: Thu, 2 Aug 2001 11:02:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] New Draft available--- draft-ziyad-rohc-tccb-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Abstract This document defines an efficient, robust, and scalable scheme for the compression of text-based protocols. Such protocols (e.g. SIP, SDP) when sent uncompressed over limited bandwidth networks (such as Cellular or the upstream of Hybrid Fiber Coax (HFC)) causes inadvertent delays in call set up. TCCB addresses these problems and proposes a simple mechanism to reduce the size of the messages and hence the recurrent delay. http://www.ietf.org/internet-drafts/draft-ziyad-rohc-tccb-00.txt _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 15:00:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13546 for ; Thu, 2 Aug 2001 15:00:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13931; Thu, 2 Aug 2001 14:09:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13901 for ; Thu, 2 Aug 2001 14:09:43 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10470 for ; Thu, 2 Aug 2001 14:08:40 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f72I9XS16005; Thu, 2 Aug 2001 21:09:33 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15209.38749.755621.111652@lohi.eng.telia.fi> Date: Thu, 2 Aug 2001 21:09:33 +0300 (EEST) To: "Neil Deason" Cc: "Jonathan Rosenberg" , Subject: RE: [Sip] proxy routing of a request In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit it seems to me that most of the section 16.4.1 about local outbound proxies is bogus. if local outbound proxy has been configured for a ua, then the ua should send ALL requests with or without route headers or with or without dns capability via that proxy. a very common reason why local outbound proxy has been configured for a ua is that the site has a firewall that denies 5060 traffic directly to/from the ua. if the text doesn't clearly mandate the use of configure outbound proxy, then some ua's would work and some others would not or we would include yet another parameter to the ua configuration, which is a very bad idea. also, the text doesn't tell what the ua should place in the request-uri when the ua didn't send the initial request. -- juha _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 15:13:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14438 for ; Thu, 2 Aug 2001 15:13:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11459; Thu, 2 Aug 2001 12:45:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11428 for ; Thu, 2 Aug 2001 12:45:03 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06099 for ; Thu, 2 Aug 2001 12:43:59 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f72GiwO06442; Thu, 2 Aug 2001 18:44:58 +0200 (MEST) Received: from lmf.ericsson.se (rmt160227.am.ericsson.se [138.85.160.227]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id SAA02049; Thu, 2 Aug 2001 18:44:55 +0200 (MET DST) Message-ID: <3B698656.677EE815@lmf.ericsson.se> Date: Thu, 02 Aug 2001 19:56:54 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Baniel Uri-CUB001 CC: "'sip@ietf.org'" Subject: Re: [Sip] "t=" in 200 References: <35DBB8B7AC89D4118E98009027B1009B0137E293@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, > Is it allowed for a UAS to change the original value of the SDP "t=" field in its 200 response? The t value is typically intended to be used for pre-arranged events. That is, the evening news will be multicast from 9 pm thru 10 pm. The SDP of an INVITE for an "ad-hoc" session typically contains t=0 0, since there is no pre-established duraction for the session. When the session is over, a BYE will be sent. So, if you receive an INVITE for a pre-arrange session (for example, the evening news from 9 thru 10), it means that the multicast (in this example) will begin at 9 and finish at 10. If you answer with a different t= value it just means that you will leave the multicast session before or after it has finished, but it does not make any difference. So, to answer you question, t= is nothing that you negotiate. You can send a BYE whenever you want, regardless of the t= value. Regards, Gonzalo > > > ============================================= > > Uri.Baniel@motorola.com, > > Tel: (847) 632 4616; Fax: (847) 632 3963; > > "I was down since I began to crawl" Cream 71 > > ============================================= > > > > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 15:27:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15217 for ; Thu, 2 Aug 2001 15:27:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11567; Thu, 2 Aug 2001 12:53:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11540 for ; Thu, 2 Aug 2001 12:53:25 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06484 for ; Thu, 2 Aug 2001 12:52:22 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA10730 for ; Thu, 2 Aug 2001 09:53:22 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA29363 for ; Thu, 2 Aug 2001 09:53:22 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 11:53:22 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E2C5@IL27EXM10.cig.mot.com> From: Baniel Uri-CUB001 To: "'Gonzalo Camarillo'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] "t=" in 200 Date: Thu, 2 Aug 2001 11:53:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Gonzalo Let me be more specific. Say a UAC send t= 0 0 (for an ad hock session) but the UAS likes to accept the call in 20 seconds, i.e. sends an immediate OK, but wish to have the RTP ports open up only 20 seconds later on. Would this be legal? (or is it non negotiable as you say...) Uri ======================================================================= Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; "If it wasn't for bad luck, I would not have luck at all" - Cream 1968 ======================================================================= > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, August 02, 2001 11:57 AM > To: Baniel Uri-CUB001 > Cc: 'sip@ietf.org' > Subject: Re: [Sip] "t=" in 200 > > > Hello, > > > Is it allowed for a UAS to change the original value of the > SDP "t=" field in its 200 response? > > > The t value is typically intended to be used for pre-arranged events. > That is, the evening news will be multicast from 9 pm thru 10 pm. > > The SDP of an INVITE for an "ad-hoc" session typically contains t=0 0, > since there is no pre-established duraction for the session. When the > session is over, a BYE will be sent. > > So, if you receive an INVITE for a pre-arrange session (for > example, the > evening news from 9 thru 10), it means that the multicast (in this > example) will begin at 9 and finish at 10. If you answer with a > different t= value it just means that you will leave the multicast > session before or after it has finished, but it does not make any > difference. > > So, to answer you question, t= is nothing that you negotiate. You can > send a BYE whenever you want, regardless of the t= value. > > Regards, > > Gonzalo > > > > > > ============================================= > > > Uri.Baniel@motorola.com, > > > Tel: (847) 632 4616; Fax: (847) 632 3963; > > > "I was down since I began to crawl" Cream 71 > > > ============================================= > > > > > > > > > > _______________________________________________ > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 17:11:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19788 for ; Thu, 2 Aug 2001 17:11:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11682; Thu, 2 Aug 2001 12:58:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11649 for ; Thu, 2 Aug 2001 12:58:39 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06810 for ; Thu, 2 Aug 2001 12:57:31 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f72GwPO09099; Thu, 2 Aug 2001 18:58:25 +0200 (MEST) Received: from lmf.ericsson.se (rmt160227.am.ericsson.se [138.85.160.227]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id SAA02433; Thu, 2 Aug 2001 18:58:21 +0200 (MET DST) Message-ID: <3B69897D.4A246BE5@lmf.ericsson.se> Date: Thu, 02 Aug 2001 20:10:21 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Baniel Uri-CUB001 CC: "'sip@ietf.org'" Subject: Re: [Sip] "t=" in 200 References: <35DBB8B7AC89D4118E98009027B1009B0137E2C5@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, That would be legal, because the session you are actually accepting in the one that you are sending in the 200 OK. However, no UA supports this. So, when I said that this was not negotiable, I meant that nobody implements this for ad-hoc sessions. It seems more reasonable to use a retry-after header. Regards, Gonzalo Baniel Uri-CUB001 wrote: > > Gonzalo > > Let me be more specific. Say a UAC send t= 0 0 (for an ad hock session) but > the UAS likes to accept the call in 20 seconds, i.e. sends an immediate OK, > but wish to have the RTP ports open up only 20 seconds later on. > > Would this be legal? (or is it non negotiable as you say...) > > Uri > > ======================================================================= > Uri.Baniel@motorola.com, > Tel: (847) 632 4616; Fax: (847) 632 3963; > "If it wasn't for bad luck, I would not have luck at all" - Cream 1968 > ======================================================================= > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Thursday, August 02, 2001 11:57 AM > > To: Baniel Uri-CUB001 > > Cc: 'sip@ietf.org' > > Subject: Re: [Sip] "t=" in 200 > > > > > > Hello, > > > > > Is it allowed for a UAS to change the original value of the > > SDP "t=" field in its 200 response? > > > > > > The t value is typically intended to be used for pre-arranged events. > > That is, the evening news will be multicast from 9 pm thru 10 pm. > > > > The SDP of an INVITE for an "ad-hoc" session typically contains t=0 0, > > since there is no pre-established duraction for the session. When the > > session is over, a BYE will be sent. > > > > So, if you receive an INVITE for a pre-arrange session (for > > example, the > > evening news from 9 thru 10), it means that the multicast (in this > > example) will begin at 9 and finish at 10. If you answer with a > > different t= value it just means that you will leave the multicast > > session before or after it has finished, but it does not make any > > difference. > > > > So, to answer you question, t= is nothing that you negotiate. You can > > send a BYE whenever you want, regardless of the t= value. > > > > Regards, > > > > Gonzalo > > > > > > > > > ============================================= > > > > Uri.Baniel@motorola.com, > > > > Tel: (847) 632 4616; Fax: (847) 632 3963; > > > > "I was down since I began to crawl" Cream 71 > > > > ============================================= > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com > > -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 17:11:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19785 for ; Thu, 2 Aug 2001 17:11:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04594; Thu, 2 Aug 2001 08:41:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA04563 for ; Thu, 2 Aug 2001 08:41:33 -0400 (EDT) Received: from packer.effnet.com ([195.100.73.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA24725 for ; Thu, 2 Aug 2001 08:40:25 -0400 (EDT) Received: from aniruddha (packer.effnet.com [195.100.73.130]) by packer.effnet.com (8.11.3/8.11.3) with SMTP id f72CH7B20604; Thu, 2 Aug 2001 14:17:07 +0200 Message-ID: <01fc01c11b4c$6d839950$710410ac@effnet.com> From: "Aniruddha Kulkarni" To: , , Cc: , , References: Subject: Re: [rohc] RE: [Sip] SIP Compression Date: Thu, 2 Aug 2001 14:12:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi How compression negotiation is done for SIP? How does Proxy server know when to use compression (as compression should be used only if there is cellular link between proxy and end node)? When SIP user starts session, it is obvious, when proxy server wants to connect to other end user, it is starting session, does it know about link characteristics between itself and the other end? ---Aniruddha ----- Original Message ----- From: To: ; ; Cc: ; ; Sent: Wednesday, July 25, 2001 9:34 PM Subject: RE: [rohc] RE: [Sip] SIP Compression > Hi, > > Somehow, I feel we're drifting away from the real issue. > First of all, the need of SIP compression arises only > because a SIP user is connected to the rest of world via > a bandwidth limited link (e.g. cellular). Otherwise, we > won't make all the mess to compress SIP, which negates > all the reasons why SIP is text based in the first place. > > Therefore, I think a compression between the SIP user and > a SIP proxy on the other side of the low-bandwidth link > is a reasonable approach. Note that this is neither hop-by-hop, > nor end-to-end (I assume by e2e you mean the two end SIP > users, not including the proxies). > > This solves the problem where it arises, with no effect to > the rest of networks. Specifically, a "normal" SIP user with > fast connection does not need to have the compression function, > nor does it have to determine if the peer SIP user is a mobile > or not. > > As to the extra load on SIP proxy performing the compression, I > don't think it is a problem as Markus indicated. Furthermore, the > function needs to be there anyway since the proxy needs uncompressed > (at least part of) SIP messages. > > Br, > Zhigang > > > -----Original Message----- > > From: ext Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] > > Sent: July 25, 2001 10:54 AM > > To: Isomaki Markus (NRC/Helsinki); ssh@cisco.com > > Cc: sean.olson@ericsson.com; rohc@cdt.luth.se; sip@ietf.org > > Subject: Re: [rohc] RE: [Sip] SIP Compression > > > > > > end-to-end compression seems more efficient as it doesn't > > depend on link > > characterictics of link between each hop. A payload compression scheme > > should be designed considering worst link characteristics > > that a packet may > > encounter in it's path.. cellular link is a good example for > > this between > > two hops. The gain obtained on those poor links can be carried over to > > better links without any loss. > > end-to-end scheme becomes more attractive when two disjoint > > hop-to-hop links > > are of poor characteristics. > > The processing time on hops could be a issue in hop-to-hop schemes. An > > intermediate hop serving multiple connections, if under load, > > could affect > > all connected entities.e.g. a base station serving multiple phones. > > (Particularly in payload compression schemes an intermediate > > hop need not > > decompress at all..) > > In end-to-end scheme, there is no such problem, resulting in a better > > overall performance. > > > > > > Definitely, this is not applicable in header compression > > schemes but for > > completely different reason, header required for routing. > > There hop-to-hop > > is the best scheme regardless of processing time issue on > > base station or > > any other benefits of end-to-end compression. > > > > ---Aniruddha > > > > ----- Original Message ----- > > From: > > To: ; > > Cc: ; ; > > Sent: Wednesday, July 25, 2001 4:26 PM > > Subject: [rohc] RE: [Sip] SIP Compression > > > > > > > Hi, > > > > > > > -----Original Message----- > > > > From: ext Suheel Hussain [mailto:ssh@cisco.com] > > > > Sent: 25 July, 2001 15:46 > > > > To: Aniruddha Kulkarni > > > > Cc: sean.olson@ericsson.com; rohc@cdt.luth.se; sip@ietf.org > > > > Subject: Re: [Sip] SIP Compression > > > > > > > > > > > > I have nagging issue with SIP compression -- compressing and > > > > decompressing on > > > > each proxy server is going to slow down call processing on > > > > large networks. > > > > IMO, it (compression) is not scalable. > > > > > > > > > > Well, obviously you would only compress/decompress where it > > makes sense. > > > This would usually be between UA in a cellular host and its outbound > > proxy. > > > There you may only have a few kilobits of capacity > > available (and during > > the > > > actual voice call even less), so it is feasible to trade between > > > transmission delay and processing complexity. So it is a classical > > > optimization problem with two constraints. Between proxies, > > where you > > > (should) have enoungh capacity, compression will probably > > just slow down > > > things. > > > > > > > Even end-to-end can be a problem if either (or both) UAS and > > > > UAC service a > > > > number of attached SIP-unaware systems. For instance a > > > > SIP-PSTN gateway. > > > > > > > > > > Again, using compression between gateways/controllers > > probably does not > > make > > > sense as the capacity limitations shouldn't be a problem. > > > > > > Regards, > > > Markus > > > > > > > Aniruddha Kulkarni wrote: > > > > > > > > > If one has high latency link then nothing can be done about > > > > it. Compression > > > > > is not a solution for that. > > > > > If one has low bandwidth link and large data to send then > > > > Compression can be > > > > > the solution. > > > > > SIP messages take up only small portion of the available > > > > bandwidth (even on > > > > > Cellular links..). Then why use compression for SIP > > messages? Well.. > > > > > cellular links have high BER, in this situation it is > > > > advisable to have > > > > > smaller packets to reduce error probability.. that is why > > > > use compression. > > > > > ... correct? > > > > > > > > > > Still large number of connections to internet are over > > > > telephone modem links > > > > > with low bandwidth, comparable with latest cellular links. > > > > Isn't it useful > > > > > to have end-to-end SIP message compression in that situation? > > > > > > > > > > How much the SIP compression schemes are dependant on RoHC? > > > > Could they have > > > > > in-built mechanism for configuration negotiation? Should > > > > they demand this > > > > > facility from lower layers? It seems to me that these > > > > schemes work more at > > > > > application level and should have configuration negotiation > > > > at that level > > > > > only. That way they could be easily extened for use on > > > > end-to-end rather > > > > > than limiting them to hop-to-hop (by depending on RoHC). > > > > > > > > > > ---Aniruddha > > > > > > > > > > ----- Original Message ----- > > > > > From: > > > > > To: "'Aniruddha Kulkarni'" ; > > > > > ; > > > > > Sent: Tuesday, July 24, 2001 6:27 PM > > > > > Subject: RE: [Sip] SIP Compression > > > > > > > > > > > > > > > > > > > >> SIP is not intended to transport large amounts of information. > > > > >> That plus the ratio of bandwidth used by signalling vs. > > > > >> the bandwidth used by the media, means that signalling > > compression > > > > >> for SIP is not in general a problem. It only really becomes a > > > > >> problem on low bandwidth, high latency *links* such as > > a cellular > > > > >> link where sometimes every byte counts. > > > > >> > > > > >> In short, I believe signalling compression is a hop-by-hop > > > > >> problem and not an end-to-end one. A hop-by-hop solution seems > > > > >> appropriate in this case. > > > > >> > > > > >> It should also be noted that you can always apply gzip > > compression > > > > >> to the MIME body of a SIP message to achieve some end-to-end > > > > >> compression. IMHO, this is not needed. > > > > >> > > > > >> I believe the compression techniques that have been > > > > >> described so far (ROGER, SCRIBE, EPIC, etc.) are > > > > >> fairly generic and would work well on a variety of > > > > >> link types. Some have been tailored with cellular > > > > >> in mind. > > > > >> > > > > >> Hopefully this addresses your concerns, > > > > >> Sean Olson > > > > >> Ericsson Inc. > > > > >> > > > > >> -----Original Message----- > > > > >> From: Aniruddha Kulkarni [mailto:aniruddha.kulkarni@effnet.com] > > > > >> Sent: Tuesday, July 24, 2001 8:30 AM > > > > >> To: rohc@cdt.luth.se; sip@ietf.org > > > > >> Subject: [Sip] SIP Compression > > > > >> > > > > >> RoHC works hop-to-hop, not end-to-end when there are > > > > multiple hops between > > > > > > > > > > two ends. > > > > > > > > > >> Does SIP Compression mechanisms also have this constraint? > > > > If yes, why? > > > > >> Are those designed to work only on cellular link between > > > > mobile terminal > > > > > > > > > > and > > > > > > > > > >> fixed end of cellular link (hop-to-hop) ? Why those > > > > mechanisms are not > > > > > > > > > > designed > > > > > > > > > >> for end-to-end compression? > > > > >> (reduce large payloads ,whatever be the link > > characteristics...) > > > > >> > > > > >> ---Aniruddha > > > > >> > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > > > This list is for NEW development of the core SIP Protocol > > > > > Use sip-implementors@cs.columbia.edu for questions on > > current sip > > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > > > > > > -- > > > > > > > > Suheel Hussain > > > > ssh@cisco.com > > > > Cisco Work # (919) 392-2312 > > > > > > > > > > > > _______________________________________________ > > > > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > > > > This list is for NEW development of the core SIP Protocol > > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > > > --- > > > Mailing list for Robust Header Compression WG > > > Archive: http://www.cdt.luth.se/rohc/ > > > > > > > --- > > Mailing list for Robust Header Compression WG > > Archive: http://www.cdt.luth.se/rohc/ > > > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 18:01:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25166 for ; Thu, 2 Aug 2001 18:01:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17852; Thu, 2 Aug 2001 17:15:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17823 for ; Thu, 2 Aug 2001 17:15:13 -0400 (EDT) Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19966 for ; Thu, 2 Aug 2001 17:14:07 -0400 (EDT) Received: from CONNIE ([192.168.1.238]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QCKY4M3P; Thu, 2 Aug 2001 17:15:04 -0400 From: "Connie Blanchard" To: Date: Thu, 2 Aug 2001 17:12:10 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Sip] Response Code of 422 in Session-Timer draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Section 4 of the Session-Timer draft makes reference to a Response code of 422. I cannot find in any of the documents listed in the bibliography of that response code. Is this a mis-print or am I missing a document? _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 18:53:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28727 for ; Thu, 2 Aug 2001 18:53:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17907; Thu, 2 Aug 2001 17:15:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17876 for ; Thu, 2 Aug 2001 17:15:50 -0400 (EDT) Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20002 for ; Thu, 2 Aug 2001 17:14:40 -0400 (EDT) Received: from CONNIE ([192.168.1.238]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QCKY4ML8; Thu, 2 Aug 2001 16:50:01 -0400 From: "Connie Blanchard" To: Date: Thu, 2 Aug 2001 16:47:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200107251040.GAA08401@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Sip] Refresher field of Session-Expires Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit In the Protocol Overview in draft 05 of Session Timer, it states in one paragraph that: "In all cases, the proxy MUST NOT insert or modify the value of the "refresher" parameter in the Session-Expires header." Then in a few paragraphs later, it states that a proxy can add a Session-Expires header and set the "refresher" parameter to "uac". I am assuming the MUST NOT only applies to Session-Expires that are inserted by another entity, and a proxy can insert the refresher parameter if it inserts the header. But the paragraph that includes the MUST NOT statement also talks about a proxy inserting a Session Expires header. Should this be clarified or do I need another cup of java? _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 19:13:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00016 for ; Thu, 2 Aug 2001 19:13:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19899; Thu, 2 Aug 2001 18:41:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA19800 for ; Thu, 2 Aug 2001 18:41:29 -0400 (EDT) Received: from ertpg15e1.nortelnetworks.com ([47.234.0.36]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27817 for ; Thu, 2 Aug 2001 18:40:23 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k [47.113.64.104]) by ertpg15e1.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f72Mea419300 for ; Thu, 2 Aug 2001 18:40:37 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 2 Aug 2001 17:34:33 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 2 Aug 2001 17:40:36 -0500 Message-ID: From: "Jayshree Bharatia" To: "'sip@ietf.org'" Date: Thu, 2 Aug 2001 17:40:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11BA4.286D9020" X-Orig: Subject: [Sip] New Draft on Early Media Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C11BA4.286D9020 Content-Type: text/plain; charset="iso-8859-1" Folks, We have submitted "Early Media Issues and Scenarios" draft which is available at http://www.ietf.org/internet-drafts/draft-sen-sip-earlymedia-00.txt Your comments are appreciated. Regards, Jayshree ------_=_NextPart_001_01C11BA4.286D9020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New Draft on Early Media

Folks,

We have submitted "Early Media = Issues and Scenarios" draft which is available at http://www.ietf.org/internet-drafts/draft-sen-sip-earl= ymedia-00.txt

Your comments are appreciated.

Regards,
Jayshree

------_=_NextPart_001_01C11BA4.286D9020-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 22:35:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13879 for ; Thu, 2 Aug 2001 22:35:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25376; Thu, 2 Aug 2001 22:19:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25149 for ; Thu, 2 Aug 2001 22:18:55 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11282 for ; Thu, 2 Aug 2001 22:17:49 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYSK00.NDN for ; Thu, 2 Aug 2001 21:57:56 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OXP00.JAE; Fri, 27 Jul 2001 19:51:25 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id QAA14391; Wed, 25 Jul 2001 16:15:22 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA03827 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 15:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25780 for ; Wed, 25 Jul 2001 06:40:44 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08381; Wed, 25 Jul 2001 06:40:42 -0400 (EDT) Message-Id: <200107251040.GAA08381@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:42 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-isup-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : ISUP to SIP Mapping Author(s) : G. Camarillo, A. Roach, J. Peterson, L. Ong Filename : draft-ietf-sip-isup-02.txt Pages : 54 Date : 24-Jul-01 This document describes a way to perform the mapping between two signaling protocols: the Session Initiation Protocol (SIP) and the ISDN User Part (ISUP) of SS7. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-isup-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-isup-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-isup-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-isup-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132829.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 22:35:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13897 for ; Thu, 2 Aug 2001 22:35:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25177; Thu, 2 Aug 2001 22:18:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25144 for ; Thu, 2 Aug 2001 22:18:54 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11285 for ; Thu, 2 Aug 2001 22:17:49 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYTI00.SC8 for ; Thu, 2 Aug 2001 21:58:30 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OXS00.EB1; Fri, 27 Jul 2001 19:51:28 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id KAA01297; Wed, 25 Jul 2001 10:31:24 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA28163 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 09:55:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25511 for ; Wed, 25 Jul 2001 06:33:25 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07556; Wed, 25 Jul 2001 06:33:24 -0400 (EDT) Message-Id: <200107251033.GAA07556@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:33:24 -0400 Subject: [Sip] I-D ACTION:draft-rosenberg-sip-conferencing-models-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Models for Multi Party Conferencing in SIP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-rosenberg-sip-conferencing-models-01.txt Pages : 26 Date : 24-Jul-01 The Session Initiation Protocol (SIP) can support multi-party conferencing in many different ways. In this draft, we define the various multi-party conferencing models, and for each, discuss how they are used and then analyze their relative benefits and drawbacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-conferencing-models-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sip-conferencing-models-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-sip-conferencing-models-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-conferencing-models-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-conferencing-models-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132327.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 22:35:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13908 for ; Thu, 2 Aug 2001 22:35:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25425; Thu, 2 Aug 2001 22:19:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25154 for ; Thu, 2 Aug 2001 22:18:56 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11296 for ; Thu, 2 Aug 2001 22:17:50 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYTW00.8DN for ; Thu, 2 Aug 2001 21:58:44 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OXV00.4AL; Fri, 27 Jul 2001 19:51:31 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id RAA16313; Wed, 25 Jul 2001 17:07:53 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA04006 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 15:35:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25787 for ; Wed, 25 Jul 2001 06:40:49 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08401; Wed, 25 Jul 2001 06:40:48 -0400 (EDT) Message-Id: <200107251040.GAA08401@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:47 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-session-timer-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Session Timer Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-05.txt Pages : 28 Date : 24-Jul-01 This document proposes an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines a new general header, Session-Expires, which conveys the lifetime of the session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-session-timer-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-session-timer-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132840.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 23:09:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14821 for ; Thu, 2 Aug 2001 23:09:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25637; Thu, 2 Aug 2001 22:22:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25591 for ; Thu, 2 Aug 2001 22:22:47 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11704 for ; Thu, 2 Aug 2001 22:21:41 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYXX00.3DB for ; Thu, 2 Aug 2001 22:01:09 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5PRW00.PE0; Fri, 27 Jul 2001 20:09:33 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id LAA04642; Wed, 25 Jul 2001 11:51:01 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id LAA29316 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 11:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25568 for ; Wed, 25 Jul 2001 06:34:39 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07687; Wed, 25 Jul 2001 06:34:39 -0400 (EDT) Message-Id: <200107251034.GAA07687@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:34:38 -0400 Subject: [Sip] I-D ACTION:draft-rosenberg-sip-entfw-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT Friendly SIP Author(s) : J. Rosenberg, J. Weinberger, H. Schulzrinne Filename : draft-rosenberg-sip-entfw-02.txt Pages : 32 Date : 24-Jul-01 In this draft, we discuss how SIP can traverse enterprise and residential firewalls and NATs. This environment is challenging because we assume here that the end user has little or no control over the firewall or NAT, and that the firewall or NAT is completely ignorant of SIP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sip-entfw-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-sip-entfw-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-entfw-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-entfw-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132442.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 2 23:11:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14893 for ; Thu, 2 Aug 2001 23:11:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25272; Thu, 2 Aug 2001 22:19:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25188 for ; Thu, 2 Aug 2001 22:18:57 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11305 for ; Thu, 2 Aug 2001 22:17:51 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYUR00.2CZ for ; Thu, 2 Aug 2001 21:59:15 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OYA00.TBV; Fri, 27 Jul 2001 19:51:47 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id QAA14709; Wed, 25 Jul 2001 16:25:30 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA04220 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 15:45:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25795 for ; Wed, 25 Jul 2001 06:40:55 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08414; Wed, 25 Jul 2001 06:40:54 -0400 (EDT) Message-Id: <200107251040.GAA08414@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:53 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-rfc2543bis-04.txt,.ps Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP: Session Initiation Protocol Author(s) : M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg Filename : draft-ietf-sip-rfc2543bis-04.txt,.ps Pages : 195 Date : 24-Jul-01 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-rfc2543bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-rfc2543bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc2543bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc2543bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132849.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 00:22:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17235 for ; Fri, 3 Aug 2001 00:22:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25230; Thu, 2 Aug 2001 22:19:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA25182 for ; Thu, 2 Aug 2001 22:18:57 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11303 for ; Thu, 2 Aug 2001 22:17:51 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYUQ00.NDO for ; Thu, 2 Aug 2001 21:59:14 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OYA00.MB2; Fri, 27 Jul 2001 19:51:46 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id QAA14864; Wed, 25 Jul 2001 16:29:52 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA04435 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 15:55:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25802 for ; Wed, 25 Jul 2001 06:41:00 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08430; Wed, 25 Jul 2001 06:40:59 -0400 (EDT) Message-Id: <200107251040.GAA08430@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:59 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-serverfeatures-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The SIP Supported Header Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-serverfeatures-05.txt Pages : 8 Date : 24-Jul-01 The Session Initiation Protocol (SIP) provides a mechanism that allows a client to request that a particular protocol extension be used to process the request. The server declines the request if it does not support the extension. However, there is currently no way for a server to determine which extensions are supported by the client. Knowing about client-supported extensions allows the server to tailor its response accordingly. Furthermore, SIP does not define a way for a client to query a server about the extensions it supports. This document defines a SIP extension that allows clients to indicate, in a request, the set of extensions supported. We also define a mechanism that allows clients, through an OPTIONS request, to determine the extensions supported by a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-serverfeatures-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-serverfeatures-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-serverfeatures-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-serverfeatures-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-serverfeatures-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132900.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 03:23:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08010 for ; Fri, 3 Aug 2001 03:23:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12617; Fri, 3 Aug 2001 03:06:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12586 for ; Fri, 3 Aug 2001 03:06:53 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07788 for ; Fri, 3 Aug 2001 03:05:50 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7376pN27675; Fri, 3 Aug 2001 09:06:51 +0200 (MEST) Received: from e0000865d41e2 (eplpc6014.epl.ericsson.se [150.132.176.14]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with SMTP id JAA02025; Fri, 3 Aug 2001 09:06:48 +0200 (MET DST) Message-ID: <005001c11bea$dd3c2c50$0eb08496@e0000865d41e2.epl.ericsson.se> From: "Hans Hannu" To: , , , Cc: , , Subject: Re: [rohc] RE: [Sip] SIP Compression Date: Fri, 3 Aug 2001 09:06:48 +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 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit >> How compression negotiation is done for SIP? > >It can be done either at SIP layer (by adding new >headers/parameters) or at the compression layer >(transparent to SIP). The latter is more generic >as the same compression can be applied to application >layer protocols other than SIP. Is it not so that it could be the same compression scheme in both cases (generic solution)? What would be different is how to negotiate the usage of the compression scheme in the first case. BR /Hans H > >> How does Proxy server know when to use compression >> (as compression should be used only if there is cellular >> link between proxy and end node)? > >The compression entity at a mobile UA and the compression >entity at the proxy server need to initialize/negotiate >(see above) the compression context before compression >happens. This can be done, for example, when a mobile >powers on or roaming to a new proxy server. After that, >the proxy server will compress messages sent from/to >the mobile. > >> when proxy server wants to connect to other end user, it >> is starting session, does it know about link characteristics >> between itself and the other end? > >No, it doesn't need to. The assumption is that each mobile >pairs with a first-hop SIP proxy server (see above). > >BR, >Zhigang > >> ---Aniruddha >--- >Mailing list for Robust Header Compression WG >Archive: http://www.cdt.luth.se/rohc/ _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 04:51:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09187 for ; Fri, 3 Aug 2001 04:51:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14970; Fri, 3 Aug 2001 04:35:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA14939 for ; Fri, 3 Aug 2001 04:35:14 -0400 (EDT) Received: from hotmail.com (oe72.pav2.hotmail.com [64.4.36.206]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09009 for ; Fri, 3 Aug 2001 04:34:11 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 3 Aug 2001 01:35:05 -0700 X-Originating-IP: [202.54.89.98] From: "Sunil" To: Date: Fri, 3 Aug 2001 12:13:53 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008D_01C11C15.C3166400" 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 Message-ID: X-OriginalArrivalTime: 03 Aug 2001 08:35:05.0121 (UTC) FILETIME=[31E77910:01C11BF7] Subject: [Sip] Problem in REGISTRATION with Proxy Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_008D_01C11C15.C3166400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, While REGISTERING with a freely available PROXY , we are getting 482 = REQUEST MERGING response. This should be the case when the VIA header in the request conatins = PROXY's IP Address.=20 But in our case the VIA header conatins our host IP Address. What may be the problem? Thanks and Regards Sunil Zack ------=_NextPart_000_008D_01C11C15.C3166400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
While REGISTERING with a freely = available PROXY ,=20 we are getting 482 REQUEST MERGING response.
This should be the case = when the=20 VIA header in the request conatins PROXY's IP Address.
But in our = case the=20 VIA header conatins our host IP Address.
 
What may be the problem?
 
Thanks and = Regards
Sunil Zack
 
 
------=_NextPart_000_008D_01C11C15.C3166400-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 05:17:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10488 for ; Fri, 3 Aug 2001 05:17:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16163; Fri, 3 Aug 2001 05:00:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA16124 for ; Fri, 3 Aug 2001 04:59:55 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09789 for ; Fri, 3 Aug 2001 04:58:51 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f738xrN07236; Fri, 3 Aug 2001 10:59:53 +0200 (MEST) Received: from e0000865d41e2 (eplpc6014.epl.ericsson.se [150.132.176.14]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with SMTP id KAA06321; Fri, 3 Aug 2001 10:59:51 +0200 (MET DST) Message-ID: <00b001c11bfa$a7a11410$0eb08496@e0000865d41e2.epl.ericsson.se> From: "Hans Hannu" To: "Price, Richard" Cc: , Date: Fri, 3 Aug 2001 10:59:50 +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 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [rohc] Requirements for signaling compression Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Comments inline. >These requirements seem fine to me - assuming of course that SIP >compression is performed on a per-hop basis. The requirements are not only considering SIP compression. The intention is to provide requirements for a generic solution applicable for compression of ASCII based signaling protocols, such as SIP/SDP, RTSP etc.. >What about compression between a mobile and a SIP proxy? I believe that the requirements apply also to this case. BR /Hans H >Is this beyond >the scope of the ROHC WG? > >Regards, > >Richard P > >-----Original Message----- >From: Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] >Sent: Thursday, August 02, 2001 2:31 PM >To: rohc >Subject: [rohc] Requirements for signaling compression > > >Hi, > >>From the discussions I see that compression of SIP is the major concern all >have, but maybe we should also look at the current version of the >requirements document as we will discuss requirements in London, not only >solutions. >Chapter 3 of, >http://www.ietf.org/internet-drafts/draft-ietf-rohc-signaling-req-assump-01 . >txt states the current requirements. There are most likely requirements >missing and maybe not all are wanted... > >BR >/Hans H > >--- >Mailing list for Robust Header Compression WG >Archive: http://www.cdt.luth.se/rohc/ > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 05:24:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10714 for ; Fri, 3 Aug 2001 05:24:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17003; Fri, 3 Aug 2001 05:13:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15468 for ; Fri, 3 Aug 2001 04:54:28 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09267 for ; Fri, 3 Aug 2001 04:53:25 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHF9D00.MQ0 for ; Fri, 3 Aug 2001 03:53:37 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OXV00.4AL; Fri, 27 Jul 2001 19:51:31 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id RAA16313; Wed, 25 Jul 2001 17:07:53 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA04006 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 15:35:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25787 for ; Wed, 25 Jul 2001 06:40:49 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08401; Wed, 25 Jul 2001 06:40:48 -0400 (EDT) Message-Id: <200107251040.GAA08401@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:47 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-session-timer-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Session Timer Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-05.txt Pages : 28 Date : 24-Jul-01 This document proposes an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines a new general header, Session-Expires, which conveys the lifetime of the session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-session-timer-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-session-timer-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132840.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 05:28:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10824 for ; Fri, 3 Aug 2001 05:28:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17111; Fri, 3 Aug 2001 05:15:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15524 for ; Fri, 3 Aug 2001 04:54:32 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09273 for ; Fri, 3 Aug 2001 04:53:26 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFA200.IPG for ; Fri, 3 Aug 2001 03:54:02 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OYA00.TBV; Fri, 27 Jul 2001 19:51:47 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id QAA14709; Wed, 25 Jul 2001 16:25:30 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA04220 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 15:45:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25795 for ; Wed, 25 Jul 2001 06:40:55 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08414; Wed, 25 Jul 2001 06:40:54 -0400 (EDT) Message-Id: <200107251040.GAA08414@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:53 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-rfc2543bis-04.txt,.ps Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP: Session Initiation Protocol Author(s) : M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg Filename : draft-ietf-sip-rfc2543bis-04.txt,.ps Pages : 195 Date : 24-Jul-01 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-rfc2543bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-rfc2543bis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132849.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc2543bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc2543bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132849.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 05:28:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10837 for ; Fri, 3 Aug 2001 05:28:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA17172; Fri, 3 Aug 2001 05:15:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15557 for ; Fri, 3 Aug 2001 04:54:34 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09277 for ; Fri, 3 Aug 2001 04:53:27 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFBU00.3QT for ; Fri, 3 Aug 2001 03:55:06 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5PRW00.PE0; Fri, 27 Jul 2001 20:09:33 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id LAA04642; Wed, 25 Jul 2001 11:51:01 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id LAA29316 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 11:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25568 for ; Wed, 25 Jul 2001 06:34:39 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07687; Wed, 25 Jul 2001 06:34:39 -0400 (EDT) Message-Id: <200107251034.GAA07687@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:34:38 -0400 Subject: [Sip] I-D ACTION:draft-rosenberg-sip-entfw-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT Friendly SIP Author(s) : J. Rosenberg, J. Weinberger, H. Schulzrinne Filename : draft-rosenberg-sip-entfw-02.txt Pages : 32 Date : 24-Jul-01 In this draft, we discuss how SIP can traverse enterprise and residential firewalls and NATs. This environment is challenging because we assume here that the end user has little or no control over the firewall or NAT, and that the firewall or NAT is completely ignorant of SIP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sip-entfw-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-sip-entfw-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosenberg-sip-entfw-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosenberg-sip-entfw-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132442.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 05:31:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11033 for ; Fri, 3 Aug 2001 05:31:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA16984; Fri, 3 Aug 2001 05:13:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15511 for ; Fri, 3 Aug 2001 04:54:31 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09271 for ; Fri, 3 Aug 2001 04:53:25 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFA100.QP6 for ; Fri, 3 Aug 2001 03:54:01 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OYA00.MB2; Fri, 27 Jul 2001 19:51:46 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id QAA14864; Wed, 25 Jul 2001 16:29:52 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA04435 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 15:55:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25802 for ; Wed, 25 Jul 2001 06:41:00 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08430; Wed, 25 Jul 2001 06:40:59 -0400 (EDT) Message-Id: <200107251040.GAA08430@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:59 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-serverfeatures-05.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The SIP Supported Header Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-serverfeatures-05.txt Pages : 8 Date : 24-Jul-01 The Session Initiation Protocol (SIP) provides a mechanism that allows a client to request that a particular protocol extension be used to process the request. The server declines the request if it does not support the extension. However, there is currently no way for a server to determine which extensions are supported by the client. Knowing about client-supported extensions allows the server to tailor its response accordingly. Furthermore, SIP does not define a way for a client to query a server about the extensions it supports. This document defines a SIP extension that allows clients to indicate, in a request, the set of extensions supported. We also define a mechanism that allows clients, through an OPTIONS request, to determine the extensions supported by a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-serverfeatures-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-serverfeatures-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-serverfeatures-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-serverfeatures-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-serverfeatures-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132900.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 05:58:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11580 for ; Fri, 3 Aug 2001 05:58:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18433; Fri, 3 Aug 2001 05:39:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA18348 for ; Fri, 3 Aug 2001 05:39:39 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11219 for ; Fri, 3 Aug 2001 05:38:33 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f739dTO11610; Fri, 3 Aug 2001 11:39:29 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.24]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f739dS529485; Fri, 3 Aug 2001 12:39:28 +0300 (EET DST) Message-ID: <3B6A714F.F715B11@lmf.ericsson.se> Date: Fri, 03 Aug 2001 12:39:27 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip@ietf.org, Jonathan Rosemberg Subject: Re: [Sip] Early media draft References: <3B6975F4.7AEFC21E@lmf.ericsson.se> Content-Type: multipart/mixed; boundary="------------D31E41B868C39C6F06F3D278" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------D31E41B868C39C6F06F3D278 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I agree with Gonzalo. Since early-media is something some nodes don't support, or care about, let's keep it separate from the "final-media". For example, if we don't keep early-media and final-media separate we MAY come with something like the following: In a forking scenario, the UAC may have an early-media "discussion" with UAS_1, but it may receive a 200 OK from another UAS, UAS_2, and for any reason the UAC chooses to start the session with UAS_2. The UAS_2 doesn't know anything about our messages with UAS_1, so it uses the SDP in the INVITE to generate the SDP in the 200. I would also - once again - like to raise the issue about canceling specific legs. If we, in a forking scenario, receive 18x from multiple UAS (all of them may, for example, offer early media), and we choose one of the legs, shouldn't we be able to CANCEL/BYE the other legs right away? If we have to wait for a final response it means that we have to send PRACKs to the other UASs as well. I KNOW this we have had (too) many discussions about this, and I KNOW about the problems related to it, but I really think it's an important part of the whole forking discussion, ESPECIALLY when early-media is involved. Regards, Christer Holmberg Ericsson Finland Gonzalo Camarillo wrote: > > Hello Jonathan, > > I have read the early media draft again. I will give my opinion on some > of the open questions that you have placed in the draft and I will make > a proposal. > > The current mechanism effectively "trashes" the SDP contained in the > first INVITE (and the SDP contained in re-INVITEs). Even if we are using > a Require header and there would not be any backward compatibility > problems, I do not like that. > > The current draft considers that when I add a media stream to the early > media it means that I would like to have the same media stream added to > the final media (media after the 200 OK). I would like to differentiate > between early media and final media. That is, I can send you an INVITE > with an audio media stream and a video media stream. You send me early > media that consists of audio only. However, when you finally answer with > a 200 OK, I want you to answer my original proposal (video+audio), not > to renegotiate the parameters that we were using for early media. > > My proposal is that negotiation of final media and negotiation of early > media are kept separate. That is, the SDP in the 200 OK will always be > the answer to the SDP in the INVITE. Regardless of whether we are using > early media or not (I believe that this is more consistent with bis). > > This would avoid media clipping when the 200 OK finally arrives, since > the UAS can send media without waiting for the ACK. > > The process of changing early media parameters would have to be changed. > Right now the UAC issues a re-INVITE. The SDP in this re-INVITE is > effectively ignored (the real SDP exchange is 1xx-PRACK). My proposal is > that the SDP in the re-INVITE is an update (or a refresh) of the SDP > that was contained in the first INVITE. > > In short, I want the "INVITE-200 OK" SDP exchange to be independent of > the "1xx-PRACK" SDP exchange. > > I believe that keeping both negotiations separate (early media > parameters and final media parameters) is a powerful tool. I can update > my final media SDP without updating my early media SDP and vice versa > (or update both at the same time, of course). > > Opinions? > > Best regards, > > Gonzalo > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------D31E41B868C39C6F06F3D278 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------D31E41B868C39C6F06F3D278-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 06:07:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11783 for ; Fri, 3 Aug 2001 06:07:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15820; Fri, 3 Aug 2001 04:54:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15454 for ; Fri, 3 Aug 2001 04:54:27 -0400 (EDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09263 for ; Fri, 3 Aug 2001 04:53:23 -0400 (EDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHF7V00.5P4 for ; Fri, 3 Aug 2001 03:52:43 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5OXP00.JAE; Fri, 27 Jul 2001 19:51:25 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id QAA14391; Wed, 25 Jul 2001 16:15:22 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA03827 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 15:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25780 for ; Wed, 25 Jul 2001 06:40:44 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08381; Wed, 25 Jul 2001 06:40:42 -0400 (EDT) Message-Id: <200107251040.GAA08381@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 25 Jul 2001 06:40:42 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-isup-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : ISUP to SIP Mapping Author(s) : G. Camarillo, A. Roach, J. Peterson, L. Ong Filename : draft-ietf-sip-isup-02.txt Pages : 54 Date : 24-Jul-01 This document describes a way to perform the mapping between two signaling protocols: the Session Initiation Protocol (SIP) and the ISDN User Part (ISUP) of SS7. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-isup-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-isup-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-isup-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-isup-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132829.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 06:46:13 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12669 for ; Fri, 3 Aug 2001 06:46:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19697; Fri, 3 Aug 2001 06:30:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA19666 for ; Fri, 3 Aug 2001 06:30:39 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12275 for ; Fri, 3 Aug 2001 06:29:36 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 11:30:30 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9DFF@RSYS002A> From: "Price, Richard" To: "'Hans Hannu'" Cc: rohc@cdt.luth.se, sip@ietf.org Date: Fri, 3 Aug 2001 11:30:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Sip] RE: [rohc] Requirements for signaling compression Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, Considering a generic solution is fine provided that it doesn't delay the availability of a SIP/SDP compression scheme. This is mainly a protocol rather than an algorithm issue (as most of the proposed algorithms are generic text compressors). If the protocol can also be made generic without too much additional effort then it is a step worth taking. Higher-layer compression might need one additional requirement - tolerance to reordering between the compressor and decompressor. We should word this similarly to Requirement 6, i.e: "The compression scheme must be able to tolerate the maximum expected message reordering between the compressor and decompressor." This makes sure that the requirement is automatically fulfilled when there is no message reordering (if per-hop compression is chosen). Best regards, Richard P -----Original Message----- From: Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] Sent: Friday, August 03, 2001 10:00 AM To: Price, Richard Cc: rohc@cdt.luth.se; sip@ietf.org Subject: Re: [rohc] Requirements for signaling compression Hi, Comments inline. >These requirements seem fine to me - assuming of course that SIP >compression is performed on a per-hop basis. The requirements are not only considering SIP compression. The intention is to provide requirements for a generic solution applicable for compression of ASCII based signaling protocols, such as SIP/SDP, RTSP etc.. >What about compression between a mobile and a SIP proxy? I believe that the requirements apply also to this case. BR /Hans H >Is this beyond >the scope of the ROHC WG? > >Regards, > >Richard P > >-----Original Message----- >From: Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] >Sent: Thursday, August 02, 2001 2:31 PM >To: rohc >Subject: [rohc] Requirements for signaling compression > > >Hi, > >>From the discussions I see that compression of SIP is the major concern all >have, but maybe we should also look at the current version of the >requirements document as we will discuss requirements in London, not only >solutions. >Chapter 3 of, >http://www.ietf.org/internet-drafts/draft-ietf-rohc-signaling-req-assump-01 . >txt states the current requirements. There are most likely requirements >missing and maybe not all are wanted... > >BR >/Hans H > >--- >Mailing list for Robust Header Compression WG >Archive: http://www.cdt.luth.se/rohc/ > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 07:35:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13656 for ; Fri, 3 Aug 2001 07:34:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20477; Fri, 3 Aug 2001 07:19:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20446 for ; Fri, 3 Aug 2001 07:19:36 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13288 for ; Fri, 3 Aug 2001 07:18:32 -0400 (EDT) Received: from mailhost.ubiquity.net by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 3 Aug 2001 11:19:35 UT Received: from neil ([193.195.52.214]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Aug 2001 12:20:35 +0100 From: "Neil Deason" To: "Sunil" , Subject: RE: [Sip] Problem in REGISTRATION with Proxy Date: Fri, 3 Aug 2001 12:20:35 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-OriginalArrivalTime: 03 Aug 2001 11:20:35.0521 (UTC) FILETIME=[50E24310:01C11C0E] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit You need to take this question to the administrator of the proxy, it is impossible to really help you with out access to the message logs. Before you do that it would help to better understand request merging. It is not about responding Proxy seeing it's own address in the Via header, it is about the same request appearing to come from two different places (i.e. having different Via headers). See: http://www.jdrosen.net/sip/multiple_requests.txt If you wish to further discuss request merging, or any other points relating to current protocol operation, please post them to the SIP Implementors list not here. http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Sunil Sent: 03 August 2001 07:44 To: sip@ietf.org Subject: [Sip] Problem in REGISTRATION with Proxy Hello, While REGISTERING with a freely available PROXY , we are getting 482 REQUEST MERGING response. This should be the case when the VIA header in the request conatins PROXY's IP Address. But in our case the VIA header conatins our host IP Address. What may be the problem? Thanks and Regards Sunil Zack _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 08:32:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14503 for ; Fri, 3 Aug 2001 08:32:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21988; Fri, 3 Aug 2001 08:16:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21959 for ; Fri, 3 Aug 2001 08:16:48 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14198 for ; Fri, 3 Aug 2001 08:15:37 -0400 (EDT) From: Markus.Isomaki@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f73CJvG12734 for ; Fri, 3 Aug 2001 15:19:57 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 3 Aug 2001 15:16:30 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVLWH8>; Fri, 3 Aug 2001 15:16:30 +0300 Message-ID: <034272783A93C944A6CA1D87FBF6F49E107ED3@esebe014.NOE.Nokia.com> To: jdrosen@dynamicsoft.com, zhigang.c.liu@nokia.com, Romeo.Zwart@att.com, jundery@ubiquity.net, Lars-Erik.Jonsson@epl.ericsson.se Cc: sip@ietf.org, rohc@cdt.luth.se Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Date: Fri, 3 Aug 2001 15:16:26 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I would still ask for some further clarification. Jonahan Rosenberg wrote: > > Yes, exactly. I am not proposing a new tranport protocol that > needs to be > signaled within IP (peer to UDP, TCP), but rather something that SIP > considers a transport protocol. This means that we can have > SRV records of > the form: > > _sip._cudp.foo.com > > which would identify servers for foo.com providing SIP over > this transport > (Compressed UDP, or whatever we call it). We can also have a SIP URL > transport param: > > sip:jdrosen@dynamicsoft.com;transport=cudp > > which can be used in record-routing, for example. > I think this looks like a good solution for negotiating whether there is compression at all or not, especially if SIP is considered. I don't know how e.g. HTTP would work, would there be a new port for "compressed HTTP" as (at least originally) defined for SSL/TLS? Two additional points: 1) Would it be so that SIP over "CUDP" would use a different destination port than SIP over UDP? Or how else does the receiver know whether the incoming packet contains a compressed or an uncompressed SIP message? 2) I don't know if there is need for more complex negotiation. If so, I assume this would somehow take place within the compression layer. As the solution should be application-protocol neutral, it is probably not a good idea to use e.g. SIP headers for this. I guess the required negotiation could be piggy-packed within the initial protocol transaction, which in SIP would be REGISTER-200. > -Jonathan R. > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > Markus _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 10:11:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16476 for ; Fri, 3 Aug 2001 10:11:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24275; Fri, 3 Aug 2001 09:47:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24248 for ; Fri, 3 Aug 2001 09:47:40 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16001 for ; Fri, 3 Aug 2001 09:46:36 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AAE17F85014C; Fri, 03 Aug 2001 09:45:05 -0400 Message-ID: <034301c11c22$c29205e0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Christer Holmberg" , "Gonzalo Camarillo" Cc: , "Jonathan Rosemberg" References: <3B6975F4.7AEFC21E@lmf.ericsson.se> <3B6A714F.F715B11@lmf.ericsson.se> Subject: Re: [Sip] BYE for provisional call legs (was Early media draft) Date: Fri, 3 Aug 2001 09:46:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > I would also - once again - like to raise the issue about canceling > specific legs. If we, in a forking scenario, receive 18x from multiple > UAS (all of them may, for example, offer early media), and we choose one > of the legs, shouldn't we be able to CANCEL/BYE the other legs right > away? If we have to wait for a final response it means that we have to > send PRACKs to the other UASs as well. I KNOW this we have had (too) > many discussions about this, and I KNOW about the problems related to > it, but I really think it's an important part of the whole forking > discussion, ESPECIALLY when early-media is involved. > In section 6 of bis-04, it says: A BYE request SHOULD NOT be sent to terminate a pending call request which has not generated either a final response or a provisional response containing a To tag. Which implies that we are allowed to BYE a specific call-leg using the To tag from a 1xx response. I think this is the right way to do it mainly because we have complete UAC-to-UAS call-leg, it just has not been answered yet. CANCELs should always match the original request and apply to the whole request (although the cancel would not apply to answered (200-OK) call-legs). I think we need to add some text stating that the way to terminate a "provisional call-leg" (one for which we have received a 1xx with a To-tag), is to send BYE with the To-tag. Also, do we need to have both a To-tag and a Contact from the 1xx, or would we always get the To-tag with a Contact? (-:bob _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 11:00:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17555 for ; Fri, 3 Aug 2001 11:00:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25521; Fri, 3 Aug 2001 10:44:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25490 for ; Fri, 3 Aug 2001 10:44:35 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17263 for ; Fri, 3 Aug 2001 10:43:30 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f73Ehhw3010835; Fri, 3 Aug 2001 10:43:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 10:44:20 -0400 Message-ID: From: Jonathan Rosenberg To: "'Christer Holmberg'" , Bob Penfield Cc: sip@ietf.org Subject: RE: [Sip] Some thoughts about CANCEL for specific legs, together with SIPextensions Date: Fri, 3 Aug 2001 10:44:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Attempting to catch up in prep for IETF.... Comments below. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, June 27, 2001 1:14 AM > To: Bob Penfield > Cc: sip@ietf.org > Subject: Re: [Sip] Some thoughts about CANCEL for specific legs, > together with SIPextensions > > > > > Conclusion: > > > > > > > > So, I don't know if we are talking about changes, or simple > > > > clarifications, in the spec, but the issues are: > > > > > > > > 1. Should we allow CANCEL for a specific call-leg, IF > we have received a > > > > To-tag and Contact in the provisional response? > > > > > > > >I personally like the idea. > > I think it can be useful also in other areas, for example when we talk > about EARLY MEDIA and media address/port verification. For example, if > the UAC receives multiple 18x, with multiple different session > descriptions, it can choose which leg to use and cancel the > others - and > the good thing is that all this can be done before the call is > established. > > Another scenario is when we send pre-call INFOs. If we have received > multiple provisonal responses, representing different > call-legs, the UAC > may not know to which server it should send the INFOs, or if it has to > send the INFO to all servers, OR if the INFOs should be sent like the > original INVITE (and currently also like CANCEL), ie without any tags, > routes and other leg information. This problem was also mentioned in a > mail by Jonathan a few days ago, I think. > > >>>2. Should we allow BYE for an established call-leg, even > if the whole > >>>call is yet not setup (the UAC is waiting for another > final response)? > > > >If by "established call-leg", you mean one that has received > a 2xx response, > >sending BYE is just for that leg is just fine. > > > >Section 6 of bis-03 says we SHOULD NOT send a BYE to > terminate a request > >that has not recieved either a final or provisional > response. Does that mean > >we can send BYE if we have received a provisional response? > A UAS is suppose > >to cancel a call-leg that it has not generated a final > response for if it > >gets a BYE. Is it legal (and desireable) to terminate a > provisional call-leg > >with BYE? > > This has been discussed alot, and the decission was that it > IS allowed. > However, I guess that we still have the same issue that we have with > CANCEL: are we allowed to BYE a specific call-leg before we have > received a final response for that leg, or is the BYE supposed to > terminate all call-leg setups? I do not like the idea of CANCEL for a specific call leg. I think we need to be able to terminate a specific leg before it is answered (i.e., after 1xx), and I think BYE does a far better job at this than CANCEL. One of the reasons is that its e2e as opposed to purely between each hop, as CANCEL is. So, my proposal is that a 1xx with tags and record-routes establish an "early call leg". Within that early call leg, you can send non-INVITE requests, including PRACK, INFO, BYE, etc. as you would for an answered call leg. This covers all of the cases that Christer has raised. I'll be talking about this one during IETF. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 11:48:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAB18886 for ; Fri, 3 Aug 2001 11:47:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26628; Fri, 3 Aug 2001 11:31:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26600 for ; Fri, 3 Aug 2001 11:31:42 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18126 for ; Fri, 3 Aug 2001 11:30:34 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f73FUwi10503 for ; Fri, 3 Aug 2001 10:30:58 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 3 Aug 2001 10:30:54 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Aug 2001 10:30:54 -0500 content-class: urn:content-classes:message Subject: RE: [rohc] RE: [Sip] SIP Compression Date: Fri, 3 Aug 2001 10:30:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [rohc] RE: [Sip] SIP Compression X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEb6uiJmycFCIfcEdWJUgAIx6TWpQAQyYyg To: , , , Cc: , , X-OriginalArrivalTime: 03 Aug 2001 15:30:54.0316 (UTC) FILETIME=[48C882C0:01C11C31] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA26601 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > >> How compression negotiation is done for SIP? > > > >It can be done either at SIP layer (by adding new > >headers/parameters) or at the compression layer > >(transparent to SIP). The latter is more generic > >as the same compression can be applied to application > >layer protocols other than SIP. > > Is it not so that it could be the same compression scheme in > both cases (generic solution)? What would be different is how to > negotiate the usage of the compression scheme in the first case. By "compression" I mean the entire compression functions including the negotiation etc. The difference is that in the latter case, the application protocol need not know anything about the compression (except perhaps its mere existence if encryption is an issue). Therefore, we can just insert the compression layer without any change to the application protocol above. I guess by "compression scheme" you mean the core compression engine *excluding* the negotiation part. In that case, I certainly agree with you. It can and should be common. BR, Zhigang _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 11:57:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19189 for ; Fri, 3 Aug 2001 11:57:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26788; Fri, 3 Aug 2001 11:42:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26759 for ; Fri, 3 Aug 2001 11:42:45 -0400 (EDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18563 for ; Fri, 3 Aug 2001 11:41:41 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 51C4D4CE05 for ; Fri, 3 Aug 2001 11:42:43 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA12947 for ; Fri, 3 Aug 2001 11:42:42 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id LAA84696 for sip@ietf.org; Fri, 3 Aug 2001 11:42:42 -0400 (EDT) Date: Fri, 3 Aug 2001 11:42:42 -0400 (EDT) Message-Id: <200108031542.LAA84696@fish.research.att.com> To: sip@ietf.org Subject: RE: [Sip] Some thoughts about CANCEL for specific legs, together with SIP extensions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Jonathan, This solution would then require the UAS to always insert the Contact and Record-Route headers in 1xx responses. I don't believe that is currently required, except as needed for reliable provisional responses (PRACK draft) and for resource preconditions (COMET draft). Is there an issue with backward compatibility? Would it still be required to include the Record-Route in the 200 response? It would be nice to only require the UAC to perform the Route header calculation once. Bill Marshall wtm@research.att.com Jonathan Rosenberg wrote: > Comments below. > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Wednesday, June 27, 2001 1:14 AM > > To: Bob Penfield > > Cc: sip@ietf.org > > Subject: Re: [Sip] Some thoughts about CANCEL for specific legs, > > together with SIPextensions > > > > > > > Conclusion: > > > > > > > > > > So, I don't know if we are talking about changes, or simple > > > > > clarifications, in the spec, but the issues are: > > > > > > > > > > 1. Should we allow CANCEL for a specific call-leg, IF > > we have received a > > > > > To-tag and Contact in the provisional response? > > > > > > > > > > >I personally like the idea. > > > > I think it can be useful also in other areas, for example when we talk > > about EARLY MEDIA and media address/port verification. For example, if > > the UAC receives multiple 18x, with multiple different session > > descriptions, it can choose which leg to use and cancel the > > others - and > > the good thing is that all this can be done before the call is > > established. > > > > Another scenario is when we send pre-call INFOs. If we have received > > multiple provisonal responses, representing different > > call-legs, the UAC > > may not know to which server it should send the INFOs, or if it has to > > send the INFO to all servers, OR if the INFOs should be sent like the > > original INVITE (and currently also like CANCEL), ie without any tags, > > routes and other leg information. This problem was also mentioned in a > > mail by Jonathan a few days ago, I think. > > > > >>>2. Should we allow BYE for an established call-leg, even > > if the whole > > >>>call is yet not setup (the UAC is waiting for another > > final response)? > > > > > >If by "established call-leg", you mean one that has received > > a 2xx response, > > >sending BYE is just for that leg is just fine. > > > > > >Section 6 of bis-03 says we SHOULD NOT send a BYE to > > terminate a request > > >that has not recieved either a final or provisional > > response. Does that mean > > >we can send BYE if we have received a provisional response? > > A UAS is suppose > > >to cancel a call-leg that it has not generated a final > > response for if it > > >gets a BYE. Is it legal (and desireable) to terminate a > > provisional call-leg > > >with BYE? > > > > This has been discussed alot, and the decission was that it > > IS allowed. > > However, I guess that we still have the same issue that we have with > > CANCEL: are we allowed to BYE a specific call-leg before we have > > received a final response for that leg, or is the BYE supposed to > > terminate all call-leg setups? > > > I do not like the idea of CANCEL for a specific call leg. I think we need to > be able to terminate a specific leg before it is answered (i.e., after 1xx), > and I think BYE does a far better job at this than CANCEL. One of the > reasons is that its e2e as opposed to purely between each hop, as CANCEL is. > > > So, my proposal is that a 1xx with tags and record-routes establish an > "early call leg". Within that early call leg, you can send non-INVITE > requests, including PRACK, INFO, BYE, etc. as you would for an answered call > leg. This covers all of the cases that Christer has raised. I'll be talking > about this one during IETF. > > -Jonathan R. > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 14:23:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23526 for ; Fri, 3 Aug 2001 14:23:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00276; Fri, 3 Aug 2001 13:41:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00245 for ; Fri, 3 Aug 2001 13:41:53 -0400 (EDT) Received: from eg01dc01.cbeyond.net (mail.cbeyond.net [63.104.33.251]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22619 for ; Fri, 3 Aug 2001 13:40:50 -0400 (EDT) Received: by eg01dc01.cbeyond.net with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 13:37:33 -0400 Message-ID: From: Nathan Nelson To: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-isup-02.txt Date: Fri, 3 Aug 2001 13:37:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Is there plans to write a document that outlines how to deal with all portability issues, both PSTN number portability and 8XX. The complexities of a 8XX call in the US networks is not caputured in the presented document. An 8XX Call that is terminated to a PSTN Number that has been ported provides three routing numbers LRN, Translated 800 Number in GAP C0, and 8XX Number in GAP 00. What numbers would a SIP proxy need to complete this call? What about billing or accounting how do these numbers map for that? Thx, Nate Nelson Cbeyond Communications _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 14:23:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23528 for ; Fri, 3 Aug 2001 14:23:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00612; Fri, 3 Aug 2001 13:59:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00582 for ; Fri, 3 Aug 2001 13:59:15 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22983 for ; Fri, 3 Aug 2001 13:58:12 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f73Hwdw3011703; Fri, 3 Aug 2001 13:58:39 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 13:59:13 -0400 Message-ID: From: Jonathan Rosenberg To: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Some thoughts about CANCEL for specific legs, together with SIP extensions Date: Fri, 3 Aug 2001 13:59:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Friday, August 03, 2001 11:43 AM > To: sip@ietf.org > Subject: RE: [Sip] Some thoughts about CANCEL for specific legs, > together with SIP extensions > > > Jonathan, > > This solution would then require the UAS to always insert the > Contact and Record-Route headers in 1xx responses. I don't believe > that is currently required, except as needed for reliable provisional > responses (PRACK draft) and for resource preconditions (COMET draft). > > Is there an issue with backward compatibility? Well, it will work like most of our other approaches for backwards compatibility. If the UAS doesn't send the 1xx with tags/RR, the client can't send early requests. The main question is what is the strength for sending the 1xx with tags/RR. Should we make it a SHOULD in bis? > > Would it still be required to include the Record-Route in the 200 > response? Yes, I would think so. Otherwise, you lose compatibility with older clients that won't look for it in the 1xx. > It would be nice to only require the UAC to perform the > Route header calculation once. I think it works like other updates to RR. The only thing that can be updated is the Contact. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 14:26:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23612 for ; Fri, 3 Aug 2001 14:26:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01269; Fri, 3 Aug 2001 14:10:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01236 for ; Fri, 3 Aug 2001 14:09:57 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23167 for ; Fri, 3 Aug 2001 14:08:54 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f73I8xw3011771; Fri, 3 Aug 2001 14:08:59 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 14:09:34 -0400 Message-ID: From: Jonathan Rosenberg To: "'zhigang.c.liu@nokia.com'" , Hans.Hannu@epl.ericsson.se, aniruddha.kulkarni@effnet.com, Markus.Isomaki@nokia.com, ssh@cisco.com Cc: Sean Olson , rohc@cdt.luth.se, sip@ietf.org Subject: RE: [rohc] RE: [Sip] SIP Compression Date: Fri, 3 Aug 2001 14:09:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: Friday, August 03, 2001 11:31 AM > To: Hans.Hannu@epl.ericsson.se; aniruddha.kulkarni@effnet.com; > Markus.Isomaki@nokia.com; ssh@cisco.com > Cc: sean.olson@ericsson.com; rohc@cdt.luth.se; sip@ietf.org > Subject: RE: [rohc] RE: [Sip] SIP Compression > > > > >> How compression negotiation is done for SIP? > > > > > >It can be done either at SIP layer (by adding new > > >headers/parameters) or at the compression layer > > >(transparent to SIP). The latter is more generic > > >as the same compression can be applied to application > > >layer protocols other than SIP. > > > > Is it not so that it could be the same compression scheme in > > both cases (generic solution)? What would be different is how to > > negotiate the usage of the compression scheme in the first case. > > By "compression" I mean the entire compression functions > including the negotiation etc. The difference is that > in the latter case, the application protocol need not know > anything about the compression (except perhaps its mere > existence if encryption is an issue). Therefore, we > can just insert the compression layer without any change > to the application protocol above. Well, the question is how one "just inserts" the compression layer in such a way that both sides know about it. Remember, signaling compression is between a wireless phone and proxy, for example, which is end-to-end at the IP layer (hop-by-hop in the SIP meaning), so the sender has to know whether to insert this compression layer before it sends its first message to the receiver. My proposal for modeling this as a SIP transport handles this case. I suspect that the usage of SRV records, a key piece of the SIP approach, will also work fine for other application protocols, such as RTSP. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 14:27:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23631 for ; Fri, 3 Aug 2001 14:27:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01355; Fri, 3 Aug 2001 14:13:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01325 for ; Fri, 3 Aug 2001 14:13:10 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23259 for ; Fri, 3 Aug 2001 14:12:07 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f73ICJw3011789; Fri, 3 Aug 2001 14:12:19 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 14:12:54 -0400 Message-ID: From: Jonathan Rosenberg To: "'Markus.Isomaki@nokia.com'" , Jonathan Rosenberg , zhigang.c.liu@nokia.com, Romeo.Zwart@att.com, jundery@ubiquity.net, Lars-Erik.Jonsson@epl.ericsson.se Cc: sip@ietf.org, rohc@cdt.luth.se Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP Date: Fri, 3 Aug 2001 14:12:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Markus.Isomaki@nokia.com [mailto:Markus.Isomaki@nokia.com] > Sent: Friday, August 03, 2001 8:16 AM > To: jdrosen@dynamicsoft.com; zhigang.c.liu@nokia.com; > Romeo.Zwart@att.com; jundery@ubiquity.net; > Lars-Erik.Jonsson@epl.ericsson.se > Cc: sip@ietf.org; rohc@cdt.luth.se > Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP > > > > _sip._cudp.foo.com > > > > which would identify servers for foo.com providing SIP over > > this transport > > (Compressed UDP, or whatever we call it). We can also have a SIP URL > > transport param: > > > > sip:jdrosen@dynamicsoft.com;transport=cudp > > > > which can be used in record-routing, for example. > > > > I think this looks like a good solution for negotiating > whether there is > compression at all or not, especially if SIP is considered. I > don't know how > e.g. HTTP would work, would there be a new port for > "compressed HTTP" as (at > least originally) defined for SSL/TLS? That is one way, but again - the http client has to have some way of handling the case when the server doesn't support compression, and is therefore not listening on this port. This is why, in http, the negotiation of the transport (tls/tcp) is handled within the http spec. In general, I see no way around negotiating the use of the compression on an application protocol by protocol basis. > > Two additional points: > > 1) Would it be so that SIP over "CUDP" would use a different > destination > port than SIP over UDP? Or how else does the receiver know whether the > incoming packet contains a compressed or an uncompressed SIP message? SRV allows for the server to indicate what port it is expecting a particular transport on. So, we could standardize a port, but SRV would eliminate the need for it. > > 2) I don't know if there is need for more complex > negotiation. If so, I > assume this would somehow take place within the compression > layer. As the > solution should be application-protocol neutral, it is > probably not a good > idea to use e.g. SIP headers for this. I guess the required > negotiation > could be piggy-packed within the initial protocol > transaction, which in SIP > would be REGISTER-200. As I have said, I think it is unavoidable for each application protocol to have to specify how to signal the usage of the compression in the first place. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 14:41:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23891 for ; Fri, 3 Aug 2001 14:41:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01500; Fri, 3 Aug 2001 14:19:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01473 for ; Fri, 3 Aug 2001 14:19:06 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23415 for ; Fri, 3 Aug 2001 14:18:04 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f73IIUw3011832; Fri, 3 Aug 2001 14:18:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 14:19:05 -0400 Message-ID: From: Jonathan Rosenberg To: "'Connie Blanchard'" , sip@ietf.org Subject: RE: [Sip] Refresher field of Session-Expires Date: Fri, 3 Aug 2001 14:19:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Connie Blanchard [mailto:connie@ss8.com] > Sent: Thursday, August 02, 2001 4:47 PM > To: sip@ietf.org > Subject: [Sip] Refresher field of Session-Expires > > > In the Protocol Overview in draft 05 of Session Timer, it > states in one > paragraph that: > > "In all cases, the proxy MUST NOT insert or modify the value of the > "refresher" parameter in the Session-Expires header." > > Then in a few paragraphs later, it states that a proxy can add a > Session-Expires header and set the "refresher" parameter to "uac". > > I am assuming the MUST NOT only applies to Session-Expires > that are inserted > by another entity, and a proxy can insert the refresher > parameter if it > inserts the header. But the paragraph that includes the MUST > NOT statement > also talks about a proxy inserting a Session Expires header. Yes, you are correct. The MUST NOT applies only when the session-expires header was there in the first place. I'll clarify in -06. Thanks. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 14:41:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23911 for ; Fri, 3 Aug 2001 14:41:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01441; Fri, 3 Aug 2001 14:17:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01412 for ; Fri, 3 Aug 2001 14:17:39 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23329 for ; Fri, 3 Aug 2001 14:16:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f73IH0w3011820; Fri, 3 Aug 2001 14:17:02 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 14:17:35 -0400 Message-ID: From: Jonathan Rosenberg To: "'Connie Blanchard'" , sip@ietf.org Subject: RE: [Sip] Response Code of 422 in Session-Timer draft Date: Fri, 3 Aug 2001 14:17:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Connie Blanchard [mailto:connie@ss8.com] > Sent: Thursday, August 02, 2001 5:12 PM > To: sip@ietf.org > Subject: [Sip] Response Code of 422 in Session-Timer draft > > > Section 4 of the Session-Timer draft makes reference to a > Response code of > 422. I cannot find in any of the documents listed in the > bibliography of > that response code. Is this a mis-print or am I missing a document? Oops. The formal definition of it needs to be defined with the session timer spec itself. It is sent when a proxy or UAS feels that the session timer value in a request was too small. The -05 spec does describe the overall semantics for it, but its scattered in the various sections. I'll include a separate discussion in -06. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 15:24:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24824 for ; Fri, 3 Aug 2001 15:24:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02428; Fri, 3 Aug 2001 14:59:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA02397 for ; Fri, 3 Aug 2001 14:59:06 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24298 for ; Fri, 3 Aug 2001 14:58:03 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f73IwMw3012040; Fri, 3 Aug 2001 14:58:22 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 14:58:57 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gonzalo Camarillo'" , Baniel Uri-CUB001 Cc: "'sip@ietf.org'" Subject: RE: [Sip] "t=" in 200 Date: Fri, 3 Aug 2001 14:58:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, August 02, 2001 1:10 PM > To: Baniel Uri-CUB001 > Cc: 'sip@ietf.org' > Subject: Re: [Sip] "t=" in 200 > > > Hello, > > That would be legal, because the session you are actually accepting in > the one that you are sending in the 200 OK. However, no UA supports > this. SIP imposes restrictions about what can be in the 200 OK in order for both sides to agree on whats going on. The text says nothing about the t value, and I would argue that this parameter should not be negotiable. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 15:24:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24835 for ; Fri, 3 Aug 2001 15:24:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02887; Fri, 3 Aug 2001 15:04:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02811 for ; Fri, 3 Aug 2001 15:04:17 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24435 for ; Fri, 3 Aug 2001 15:03:13 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f73J3Ww3012068; Fri, 3 Aug 2001 15:03:32 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 15:04:07 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gonzalo Camarillo'" , Jonathan Rosenberg Cc: "'shh@ricochet.net'" , "Fairlie-Cuninghame, Robert" , "'sip@ietf.org'" Subject: RE: [Sip] update to nat traversal draft! Date: Fri, 3 Aug 2001 15:04:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Wednesday, August 01, 2001 11:44 AM > To: Jonathan Rosenberg > Cc: 'shh@ricochet.net'; Fairlie-Cuninghame, Robert; 'sip@ietf.org' > Subject: Re: [Sip] update to nat traversal draft! > > > Hello, > > > An interesting solution might be for the caller (and > callee) to always offer > > two alternate media streams (using the FID draft), one of > which is with its > > public address, and another with the private address. If > media starts > > arriving on the private address, it re-invites to disable > the stream on the > > public one. Actually, that is probably the most robust and simplest > > solution. Not sure FID gives you all the semantics you need > for this, > > though... > > I believe it does. The syntax would look like this: > > a=group:FID 1 2 > m=audio 10000 RTP/AVT 8 > c=IN IP4 123.123.123.123 > a=mid:1 > m=audio 20000 RTP/AVT 8 > c=IN IP4 10.0.0.1 > a=mid:2 > > The application would send media to both addresses at the > same time (in > parallel), since both contain codec 8. I'm confused. My interpretation of the fid spec was that things in the same group were alternates. So, it would not send to both at the same time. It would instead choose one, which is not what you want. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 15:24:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24856 for ; Fri, 3 Aug 2001 15:24:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02966; Fri, 3 Aug 2001 15:07:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA02941 for ; Fri, 3 Aug 2001 15:07:54 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24461 for ; Fri, 3 Aug 2001 15:06:46 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id MAA08538 for ; Fri, 3 Aug 2001 12:00:20 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id MAA04548 for ; Fri, 3 Aug 2001 12:07:48 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 14:07:47 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E2E5@IL27EXM10.cig.mot.com> From: Baniel Uri-CUB001 To: "'Jonathan Rosenberg'" , "'Gonzalo Camarillo'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] "t=" in 200 Date: Fri, 3 Aug 2001 14:07:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I just thought of few scenarios, which having the ability to respond with a 200 OK and SDP:t=curr_time+x 0, may enable the UAS to let the UAC know it accepted the call, but will be able to start interchanging RTP only x seconds later on. ======================================================================= Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; "If it wasn't for bad luck, I would not have luck at all" - Cream 1968 ======================================================================= > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, August 03, 2001 1:59 PM > To: 'Gonzalo Camarillo'; Baniel Uri-CUB001 > Cc: 'sip@ietf.org' > Subject: RE: [Sip] "t=" in 200 > > > > > > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Thursday, August 02, 2001 1:10 PM > > To: Baniel Uri-CUB001 > > Cc: 'sip@ietf.org' > > Subject: Re: [Sip] "t=" in 200 > > > > > > Hello, > > > > That would be legal, because the session you are actually > accepting in > > the one that you are sending in the 200 OK. However, no UA supports > > this. > > SIP imposes restrictions about what can be in the 200 OK in > order for both > sides to agree on whats going on. The text says nothing about > the t value, > and I would argue that this parameter should not be negotiable. > > -Jonathan R. > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 15:54:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25598 for ; Fri, 3 Aug 2001 15:54:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03374; Fri, 3 Aug 2001 15:29:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03347 for ; Fri, 3 Aug 2001 15:29:27 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24945 for ; Fri, 3 Aug 2001 15:28:18 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f73JSiw3012176; Fri, 3 Aug 2001 15:28:44 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 15:29:19 -0400 Message-ID: From: Jonathan Rosenberg To: "'John Lazzaro'" , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] update to nat traversal draft! Date: Fri, 3 Aug 2001 15:29:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: John Lazzaro [mailto:lazzaro@CS.Berkeley.EDU] > Sent: Wednesday, August 01, 2001 1:24 PM > To: jdrosen@dynamicsoft.com; lazzaro@CS.Berkeley.EDU; sip@ietf.org > Subject: RE: [Sip] update to nat traversal draft! > > > > That doesn't sound right... for all the nat cases it should > be the address > > you sent to (at least for symmetric RTP). > > I'll be concrete here with an example, although I realize the details > don't match your I-D that closely. Think of two clients, A and B, > both of which are sending and receiving RTP on a single UDP port (lets > not consider RTCP for now), and who are also communicating with a > SIP server using that same UDP port. The same port for RTP and SIP? How will you demux? > Each client sends in its SDP to the SIP server the IP/port it > thinks it > has. The SIP server can tell if the client is behind a NAT, and if so > adds extra connection and media lines to the SDP whose port > and IP number > correspond to those it would add in the received and rport > parameters of > a Via. We found that its easier for the client to figure out whether its behind a nat, rather then the server to figure it out for it. This also simplifies the overall operation, since proxies can just be proxies rather than having to do all this SDP rewriting. > The SIP server sends this (potentially) modified SDP > to the other > client, who then uses it to start the RTP session, by sending RTP to > both IP/ports sets in the SDP. This is happening for both clients, so > initially > > -- client A is sending the first RTP wave to one or maybe 2 > IP/ports for B > -- client B is sending the first RTP wave to one or maybe 2 > IP/ports for A > > In a world with static IP's and Full Cone NATs, I believe this first > wave always has a happy ending -- whether both clients are behind a > different NAT, both are behind the same NAT, or one or both have > static IPs, each client will receive one of the two RTP packets sent > by the other, and examining the IP/port reveals one of the > two sources it also sent to. There's now enough knowledge to discard > the useless address and just send on one channel. This works only with symmetric RTP, since otherwise you can't figure out which one has succeeded or not. > > But consider the case where the clients are behind different NATs, > but B's NAT isn't Full Cone -- it only lets in a UDP packet > whose IP/port > matches the IP/port destination address of the outgoing packet that > established the binding. > > At the start of the session client A sends out > his first wave of two RTP packets, but neither get to client B -- > B's NAT discarded the packet that should have gotten through. > Meanwhile, > B's RTP wave is successful in getting to A, since A has a > more sensible > NAT. Client A is able to use the IP/port of the received > packet to start > sending data successfully back to B -- but: This is symmetric RTP - send the media back to the source IP/port where it came from. As you point out, it works only when ONE of the two parties is behind symmetric nats. > > this IP/port will be different than both IP/ports it used > to send to B the first time, I believe. > > And, to finish the story, the hopeless case seems to be when both > client A and B are behind different NATs that aren't full cone, unless > one of the clients is using a service provider that doesn't do egress > filter, in which case source forging might work ... or else, > of course, > use a third party to shuttle every RTP packet. > > Is this scenareo too different from your I-D for the conclusions to > apply, or is there an error in the logic above? Its pretty close. The main difference is that the clients to the detection of whether they are behind a nat or not, and allocation of a public address before the call is made. But otherwise, we use symmetric RTP if possible, take advtantage of full-cone nats if possible, and only use a third party intermediary server in the worst case when both are behind symmetric nats. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 16:08:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25945 for ; Fri, 3 Aug 2001 16:08:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04135; Fri, 3 Aug 2001 15:52:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04071 for ; Fri, 3 Aug 2001 15:52:55 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25561 for ; Fri, 3 Aug 2001 15:51:51 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA09300; Wed, 1 Aug 2001 12:53:26 -0400 (EDT) Message-ID: <3B683400.E684F6BC@cs.columbia.edu> Date: Wed, 01 Aug 2001 12:53:20 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Jonathan Rosenberg , sip@ietf.org, adam.roach@ericsson.com Subject: Re: [Sip] Re: 489 status code References: <3B681F06.F7CA70F0@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > > Hello, > > Yes, having an IANA registry for response codec would help have > consistent specs. We will most likely use the "request updated" response > code in the next version of the overlap draft, so we better be > consistent :o) Since IANA seems to have delay and packet loss problems, maybe I can set up a table of new codes. Anybody who has defined a new status code outside of bis, please set me a reference. Thanks. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 16:10:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26077 for ; Fri, 3 Aug 2001 16:10:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04054; Fri, 3 Aug 2001 15:52:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA04025 for ; Fri, 3 Aug 2001 15:52:37 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25535 for ; Fri, 3 Aug 2001 15:51:33 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f73Jpxw3012295; Fri, 3 Aug 2001 15:51:59 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 15:52:34 -0400 Message-ID: From: Jonathan Rosenberg To: "'Christer Holmberg'" , sip@ietf.org Subject: RE: [Sip] Response code for unsupported SIP version Date: Fri, 3 Aug 2001 15:52:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Thursday, July 26, 2001 9:00 AM > To: sip@ietf.org > Subject: [Sip] Response code for unsupported SIP version > > > > Hi, > > Just a small detail/cosmetic/clarification question: I think this goes down as the most minor nit ever raised against the spec. > > The 505 SIP Version not supported, which belongs to the Server Error > category, response code is used when a request with a > non-supported SIP > version (other than SIP/2.0, that is) is received. > > The ABNF grammar (bis-04, page 27), however, allows ONLY "SIP/2.0". If > something else is received, isn't it then, from a grammar > point of view, > a Syntax Error (ie a 4xx response code should be used)? > > So, if we want to use 505, shouldn't the grammar look something like: > > SIP-Version = "SIP/2.0" | other-version > other-version = "SIP/" 1*DIGIT "." 1*DIGIT > > ...or something similar. Consider 505 a "hope we will never use placeholder". Feel free to send a 4xx if you get a different version than 2.0. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 16:24:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27681 for ; Fri, 3 Aug 2001 16:24:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04681; Fri, 3 Aug 2001 16:07:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04652 for ; Fri, 3 Aug 2001 16:07:27 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25879 for ; Fri, 3 Aug 2001 16:06:03 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f73K81I02545 for ; Fri, 3 Aug 2001 15:08:01 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 3 Aug 2001 15:06:52 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 3 Aug 2001 15:06:52 -0500 content-class: urn:content-classes:message Subject: RE: [rohc] RE: [Sip] SIP Compression Date: Fri, 3 Aug 2001 15:06:51 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [rohc] RE: [Sip] SIP Compression X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEcR4E6S+aKYog5EdWrxAAIx6S5QwACQ15A To: , , , , Cc: , , X-OriginalArrivalTime: 03 Aug 2001 20:06:52.0312 (UTC) FILETIME=[D61E3180:01C11C57] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA04653 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Jonathan, > Well, the question is how one "just inserts" the compression > layer in such a way that both sides know about it. Remember, > signaling compression is between a wireless phone and proxy, > for example, which is end-to-end at the IP layer (hop-by-hop > in the SIP meaning), so the sender has to know whether > to insert this compression layer before it sends its first > message to the receiver. Yes. But I don't see why this cannot be done at compression layer (which is below the application protocol). The compression module at wireless phone can contact/negotiate with its peer at the proxy to setup compression state. If this fails (e.g. no response from peer or some other abnormal conditions), the local compression module simply passes any application message transparently without applying compression (i.e. turn itself off). > My proposal for modeling this as a SIP transport handles this > case. I suspect that the usage of SRV records, a key piece of the SIP > approach, will also work fine for other application protocols, such as RTSP. As I said, negotiation at application layer is certainly an alternative. But it looks to me less generic in that it may require additions/modifications to the existing application protocols. And we have to do that one by one. Second, there are some details in the compression state (e.g. compression algorithm) which I'm not sure should be handled at application layer. Also, negotiation at compression layer allows the procedure to be finished even before the first message is generated by the application protocol (e.g. as soon as the wireless phone is powered on). That mitigates the surge in bandwidth requirement and gives a smoother jump start for the compression (especially of the first message). Br, Zhigang _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 16:35:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28664 for ; Fri, 3 Aug 2001 16:35:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04932; Fri, 3 Aug 2001 16:15:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04848 for ; Fri, 3 Aug 2001 16:15:23 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27480 for ; Fri, 3 Aug 2001 16:14:19 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f73KEcw3012361; Fri, 3 Aug 2001 16:14:38 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 16:15:13 -0400 Message-ID: From: Jonathan Rosenberg To: "'John.Hearty@Level3.com'" , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] bis-04 available! Date: Fri, 3 Aug 2001 16:15:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com] > Sent: Tuesday, July 24, 2001 4:09 PM > To: jdrosen@dynamicsoft.com; sip@ietf.org > Subject: RE: [Sip] bis-04 available! > > > Jonathan, > > Section 16.3 includes the following updated language in the second > paragraph (thanks): > > The URL SHOULD NOT contain the > transport parameter, but can in private networks where it is known > that elements on both sides of the proxy support the specific > transport. > > However, the following language in paragraph 4 also needs to > be modified so > there is no conflict: > > The proxy MAY modify the Record-Route > value matching the one it inserted into the request. Like the URL in > the request, it MUST be a SIP URL and MUST NOT contain a transport > parameter. Thanks for pointing it out. I've fixed it for -05. > > > I'd also like to note that since the Record-Route may be > modified, it is > possible the transport could be modified, thus elements on > both sides of the > proxy may not need to support the specific transport as the > first modified > language indicates. For example, leave off the transport on the > Record-Route of an Invite going into the private network so > UDP defaults on > the inside, and include transport=tls in the 200 OK's > Record-Route when > interfacing with another element over an unsecure network. > This allows > subsequent requests to run over the same secure connection an initial > transaction ran over, without requiring the same transport on > the other side > of the proxy. Yes, you are correct. I have fixed this for -05 as well. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 16:41:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28820 for ; Fri, 3 Aug 2001 16:41:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04998; Fri, 3 Aug 2001 16:18:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04964 for ; Fri, 3 Aug 2001 16:18:32 -0400 (EDT) Received: from snap.CS.Berkeley.EDU (IDENT:root@snap.CS.Berkeley.EDU [128.32.37.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27531 for ; Fri, 3 Aug 2001 16:17:28 -0400 (EDT) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id NAA17225; Fri, 3 Aug 2001 13:18:21 -0700 Date: Fri, 3 Aug 2001 13:18:21 -0700 From: John Lazzaro Message-Id: <200108032018.NAA17225@snap.CS.Berkeley.EDU> To: jdrosen@dynamicsoft.com, sip@ietf.org Subject: RE: [Sip] update to nat traversal draft! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org >> John Lazzaro wrote: >> Think of two clients, A and B, >> both of which are sending and receiving RTP on a single UDP port (lets >> not consider RTCP for now), and who are also communicating with a >> SIP server using that same UDP port. > Jonathan Rosenberg wrote: > The same port for RTP and SIP? How will you demux? Pattern recognition on the beginning of the packet plus examination of the source address, lets the client handle this problem, the SIP server will only see SIP. For ISO 8859-1, the capital letter that starts a SIP method will be in the range 65-90 decimal, whereas for version 2 and above for RTP and RTCP, the first byte will be at least 128 (V=2). The next few bytes can be used as sanity checks. >> John Lazzaro wrote: >> >> The SIP server can tell if the client is behind a NAT, and if so >> adds extra connection and media lines to the SDP whose port >> and IP number correspond to those it would add in the received >> and rport parameters of a Via. > Jonathan Rosenberg wrote: > > We found that its easier for the client to figure out whether its behind a > nat, rather then the server to figure it out for it. Actually, we do also, but explaining it would have added several more paragraphs to an overly-long posting :-). Our SIP server always kicks back the first INVITE with a 401 Unauthorized, the client checks out the received and rport and adds the NAT information into the revised SDP for the new INVITE, to which it also adds the appropriate SIP Authorization header field. By the way, anyone reading on the list who wants to experiment with these symmetric RTP ideas can download our network musical performance client and bounce packets off our SIP server, I can send SIP logs of your session back to you in email if you want to see the NAT detection in action from the server side, see: http://www.cs.berkeley.edu/~lazzaro/sa/sfman/user/network/index.html for details on the networking and http://www.cs.berkeley.edu/~lazzaro/sa/index.html to actually download. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 16:50:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28978 for ; Fri, 3 Aug 2001 16:50:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06141; Fri, 3 Aug 2001 16:36:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06112 for ; Fri, 3 Aug 2001 16:36:29 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28641 for ; Fri, 3 Aug 2001 16:35:24 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f73KZow3012457; Fri, 3 Aug 2001 16:35:51 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 Aug 2001 16:36:26 -0400 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] bis-04 available! Date: Fri, 3 Aug 2001 16:36:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Thursday, July 26, 2001 7:07 AM > To: Jonathan Rosenberg > Cc: 'sip@ietf.org' > Subject: Re: [Sip] bis-04 available! > > > Hi > > Well I for one am glad the Authentication-Info is now > mentioned in the spec, > that makes my digest draft actually potentially useful!! It > would be nice > however to have the header mentioned in section 10, even if > it's just a short > entry like Authorization. > > James Undery Good point. I added it for bis-05. I was about to add Proxy-Authentication-Info too, and then I realized it doesn't work. The reason is that multiple proxies might want to insert this header. The header does not define a realm parameter, so that a UAC receiving many Proxy-Authentication-Info headers in a 2xx won't know which one applies to which realm. So, it won't be able to use the nextnonce, for example, since it doesn't know whcih username/pass to apply to each nonce. Our options are to: 1. forget about Proxy-Authentication-Info (its only briefly mentioned in rfc2617, easy to miss....) 2. define our own extension to this header containing a realm parameter. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 3 19:24:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00836 for ; Fri, 3 Aug 2001 19:24:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09102; Fri, 3 Aug 2001 19:06:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA09073 for ; Fri, 3 Aug 2001 19:06:07 -0400 (EDT) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00537 for ; Fri, 3 Aug 2001 19:05:06 -0400 (EDT) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id TAA11469 for ; Fri, 3 Aug 2001 19:06:07 -0400 (EDT) Message-ID: <3B6B2E5F.21A6F994@cs.columbia.edu> Date: Fri, 03 Aug 2001 19:06:07 -0400 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] List of current non-RFC2543 status codes Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit http://www.cs.columbia.edu/sip/statuscode.html Please send me any additional ones I missed. Thanks to Jonathan and Bill for providing the current set. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Aug 4 22:34:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05400 for ; Sat, 4 Aug 2001 22:34:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA14397; Sat, 4 Aug 2001 22:12:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA14366 for ; Sat, 4 Aug 2001 22:12:34 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04347 for ; Sat, 4 Aug 2001 22:11:27 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id TAA22587 for ; Sat, 4 Aug 2001 19:12:32 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id TAA23918 for ; Sat, 4 Aug 2001 19:12:32 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Sat, 4 Aug 2001 21:12:32 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E2EF@IL27EXM10.cig.mot.com> From: Baniel Uri-CUB001 To: "'Alan Johnston'" Cc: sip@ietf.org Date: Sat, 4 Aug 2001 21:12:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Route Header filed in service-examples-02 section 2.1 F14 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I have the feeling the Route header should be: Route: rather than Route: Uri _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sun Aug 5 04:10:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10139 for ; Sun, 5 Aug 2001 04:10:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28526; Sun, 5 Aug 2001 03:44:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28497 for ; Sun, 5 Aug 2001 03:44:07 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05712 for ; Sun, 5 Aug 2001 03:43:01 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f757i2N06941 for ; Sun, 5 Aug 2001 09:44:03 +0200 (MEST) Received: from ericsson.com ([164.48.154.109]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id JAA28850 for ; Sun, 5 Aug 2001 09:44:00 +0200 (MET DST) Message-ID: <3B6CF6CC.1A2E6817@ericsson.com> Date: Sun, 05 Aug 2001 10:33:32 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Comment to draft-rosenberg-sip-conferencing-models-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: Section 3.1 of draft-rosenberg-sip-conferencing-models-01.txt mentions that for Large Scale Multicast conferences UAs do not need to send BYE when they leave the conference. I believe this mechanism wil work in most of the scenarios. However, what about when there is a proxy that Recorded Route, usuallly because it wants to be informed when the session is over. The rr proxy will never get a BYE, and it will have to rely on other mechanisms (let's say, session-timer) to remove the installed states. I think the proposed behaviour of forgetting about BYEs will break in the common assumptions that BYEs are sent to indicate the end of the signalling relatioship. /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sun Aug 5 11:04:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14595 for ; Sun, 5 Aug 2001 11:04:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05454; Sun, 5 Aug 2001 10:32:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA05424 for ; Sun, 5 Aug 2001 10:32:50 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14361 for ; Sun, 5 Aug 2001 10:31:46 -0400 (EDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f75EWA527130 for ; Sun, 5 Aug 2001 10:32:10 -0400 (EDT) Received: from cisco.com ([161.44.109.7]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAB01373 (AUTH shbhatna); Sun, 5 Aug 2001 10:32:18 -0400 (EDT) Message-ID: <3B6D590C.B9C2ADE7@cisco.com> Date: Sun, 05 Aug 2001 10:32:44 -0400 From: Shail Bhatnagar X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] [Fwd: [Sip-implementors] Computing request hash] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I was hoping that someone will respond to this. I know it is an implementation issue, but should'nt the sip spec say 2 words about the process of computing the request hash - which parameters in the url should be included . Thanks, Shail -------- Original Message -------- Subject: [Sip-implementors] Computing request hash Date: Thu, 02 Aug 2001 22:41:39 -0400 From: Shail Bhatnagar To: sip-implementors@cs.columbia.edu When a transaction stateful proxy computes the hash of the following fields : Request-uri, From, To, Call-ID and Cseq.number (maybe even topmost via) does it include all url parameters of the sip urls in the above fields ? So, if the same request visits the proxy as sip:abcd@proxy sip:abcd@proxy;maddr=1.2.3.4 and the rest of the fields are same. Is this a loop ? Don't ask me how this happened. Imagine that there is one or more misbehaving client/proxy. Thanks, Shail _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sun Aug 5 16:11:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20150 for ; Sun, 5 Aug 2001 16:11:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11133; Sun, 5 Aug 2001 15:42:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11102 for ; Sun, 5 Aug 2001 15:42:36 -0400 (EDT) Received: from purple.east.isi.edu (host217-33-137-108.ietf.ignite.net [217.33.137.108]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19517 for ; Sun, 5 Aug 2001 15:41:30 -0400 (EDT) Received: from purple (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.9.3) with ESMTP id PAA07784; Sun, 5 Aug 2001 15:42:27 -0400 Message-Id: <200108051942.PAA07784@purple.east.isi.edu> To: Gonzalo Camarillo cc: Jonathan Rosenberg , sip@ietf.org, mmusic Subject: Re: [Sip] Re: SDP hold In-Reply-To: Your message of "Wed, 01 Aug 2001 18:07:35 +0300." <3B681B37.B8350B4@lmf.ericsson.se> Date: Sun, 05 Aug 2001 20:42:27 +0100 From: Colin Perkins Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --> Gonzalo Camarillo writes: >Hello, > >> > It seems that the best proposal is to use the direction tag (sendonly, >> > sendrecv, recvonly) to do this. It has been proposed to define a new >> > direction tag value that would mean that the media stream >> > will not carry >> > media (neither-send-nor-receive). This could be encoded as a=nomedia, >> > for instance. >> >> Just to be clear, you do not need a new attribute for hold. In the current >> usage of 0.0.0.0, hold is unidirectional. As a result, using a=sendonly is >> the appropriate way to replace this functionality. > >Yes, sendonly works if A puts B on hold in a sendrecv stream. However, >if you have a recvonly stream and you want to put it on hold, you need >the neither-send-nor-receive tag. > >> There is also a need, I think, to indicate that a media stream is >> temporarily disabled (in which case there is neither RTP or RTCP in either >> direction). But, this is not needed for hold. > >OK, we can call the "on hold" scenario I just described as a >"temporarily disabled media" (the latter is probably more accurate). >Anyway, we still need the new tag. I do not really care if we call it >neithersendnorrecv, nomedia or inactive. However, as Christer suggested, >in order to be consistent with other protocols we can use "inactive". > >Anyway, my question is: Colin, do you think that such a tag should be >included in SDPnew? Otherwise we can write a half-page draft defining >this attribute. I don't see the need for a new draft, so if there's consensus on this, send me some suggested wording. Colin _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 6 02:25:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17673 for ; Mon, 6 Aug 2001 02:25:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29277; Mon, 6 Aug 2001 01:59:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29249 for ; Mon, 6 Aug 2001 01:59:13 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08861 for ; Mon, 6 Aug 2001 01:58:08 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f765xBN19781; Mon, 6 Aug 2001 07:59:12 +0200 (MEST) Received: from e0000865d41e2 (eplpc6014.epl.ericsson.se [150.132.176.14]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with SMTP id HAA00346; Mon, 6 Aug 2001 07:59:10 +0200 (MET DST) Message-ID: <002201c11e3c$e9470020$0eb08496@e0000865d41e2.epl.ericsson.se> From: "Hans Hannu" To: , , , Cc: , , Subject: Re: [rohc] RE: [Sip] SIP Compression Date: Mon, 6 Aug 2001 07:59:09 +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 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit >> >> How compression negotiation is done for SIP? >> > >> >It can be done either at SIP layer (by adding new >> >headers/parameters) or at the compression layer >> >(transparent to SIP). The latter is more generic >> >as the same compression can be applied to application >> >layer protocols other than SIP. >> >> Is it not so that it could be the same compression scheme in >> both cases (generic solution)? What would be different is how to >> negotiate the usage of the compression scheme in the first case. > >By "compression" I mean the entire compression functions >including the negotiation etc. The difference is that >in the latter case, the application protocol need not know >anything about the compression (except perhaps its mere >existence if encryption is an issue). Therefore, we >can just insert the compression layer without any change >to the application protocol above. Ok, good. > >I guess by "compression scheme" you mean the core compression >engine *excluding* the negotiation part. In that case, I >certainly agree with you. It can and should be common. Yes. That was my meaning. > >BR, >Zhigang _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 6 10:43:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24348 for ; Mon, 6 Aug 2001 10:43:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10732; Mon, 6 Aug 2001 09:46:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10701 for ; Mon, 6 Aug 2001 09:46:46 -0400 (EDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23296 for ; Mon, 6 Aug 2001 09:45:41 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id f76DkjQ06036 for ; Mon, 6 Aug 2001 09:46:46 -0400 (EDT) Reply-To: From: "Eric Burger" To: Subject: RE: [Sip] new I-D on early media Date: Mon, 6 Aug 2001 09:46:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Figure 2 in section 5.2 of the draft: I think the 200 PRACK (message 6) is going in the wrong direction. It should be from the UAS to the UAC, not the other way around. _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 6 12:08:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26538 for ; Mon, 6 Aug 2001 12:08:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14654; Mon, 6 Aug 2001 11:43:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14624 for ; Mon, 6 Aug 2001 11:43:17 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25981 for ; Mon, 6 Aug 2001 11:42:09 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f76Fh9O04077; Mon, 6 Aug 2001 17:43:09 +0200 (MEST) Received: from lmf.ericsson.se ([164.48.154.84]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id RAA27134; Mon, 6 Aug 2001 17:43:07 +0200 (MET DST) Message-ID: <3B6EBDF3.A76033A7@lmf.ericsson.se> Date: Mon, 06 Aug 2001 18:55:31 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'shh@ricochet.net'" , "Fairlie-Cuninghame, Robert" , "'sip@ietf.org'" Subject: Re: [Sip] update to nat traversal draft! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Comments inline: Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Wednesday, August 01, 2001 11:44 AM > > To: Jonathan Rosenberg > > Cc: 'shh@ricochet.net'; Fairlie-Cuninghame, Robert; 'sip@ietf.org' > > Subject: Re: [Sip] update to nat traversal draft! > > > > > > Hello, > > > > > An interesting solution might be for the caller (and > > callee) to always offer > > > two alternate media streams (using the FID draft), one of > > which is with its > > > public address, and another with the private address. If > > media starts > > > arriving on the private address, it re-invites to disable > > the stream on the > > > public one. Actually, that is probably the most robust and simplest > > > solution. Not sure FID gives you all the semantics you need > > for this, > > > though... > > > > I believe it does. The syntax would look like this: > > > > a=group:FID 1 2 > > m=audio 10000 RTP/AVT 8 > > c=IN IP4 123.123.123.123 > > a=mid:1 > > m=audio 20000 RTP/AVT 8 > > c=IN IP4 10.0.0.1 > > a=mid:2 > > > > The application would send media to both addresses at the > > same time (in > > parallel), since both contain codec 8. > > I'm confused. My interpretation of the fid spec was that things in the same > group were alternates. So, it would not send to both at the same time. It > would instead choose one, which is not what you want. An application chooses one codec and then sends RTP over all the m lines that contain that codec. At the beginning I was assuming that a particular codec would be present only in one m line. However, you suggested (in an MMUSIC meeting) that we had to define semantics for this case (when a codec appears in multiple m lines). Henning and I finally agreed that this was the "right thing to do". Version 03 of the draft already defines this behavior, but version 04 (will appear in the archives right after London) provides a more formal definition (without changing the semantics). Regards, Gonzalo > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 6 12:08:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26569 for ; Mon, 6 Aug 2001 12:08:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14782; Mon, 6 Aug 2001 11:46:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14753 for ; Mon, 6 Aug 2001 11:46:23 -0400 (EDT) Received: from mail.net2phone.com (mail.net2phone.com [216.53.3.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26050 for ; Mon, 6 Aug 2001 11:45:18 -0400 (EDT) Received: from mailsvr.net2phone.com (exchange.net2phone.com [216.53.60.1]) by mail.net2phone.com (8.9.3/8.9.3) with ESMTP id LAA17554 for ; Mon, 6 Aug 2001 11:45:56 -0400 (EDT) Received: by mailsvr with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 11:45:56 -0400 Message-ID: <6F46FABB90ABD411BD690002B3152FB9466E1A@lkwmail01> From: Romel Khan To: "'sip@ietf.org'" Date: Mon, 6 Aug 2001 11:45:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Cancel method in SIP bis-04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I have couple of questions/points on procedures related to Cancel method (I don't recall whether SIP bis 04 is clear on that): 1. UAC sends Invite to UAS. UAS sends 200 OK to UAC. Meanwhile before the 200 OK is received by the UAC, it for some reason sends a Cancel to the UAS. So what should happen in this glare situation? I assume the UAS will ignore the Cancel since it has already sent the 200 OK. And the UAC, upon receiving the 200 OK, should either send Bye to UAS or let the call connect sending an ACK depending on the particular reason the Cancel was sent in the 1st time. The Cancel, however, is not retransmitted. Or is there a different procedure? Which pages in which SIP RFC might have talked about this? 2. UAC sends Invite to UAS. UAS sends a response such as 200 OK but it is improperly formatted. How should the sending side behave in this case? I notice from SIP implementations that the UAC will send Cancel to UAS. It will be very helpful to have some kind of 'reason' header field in the Cancel request so that the reason why the Cancel is being will be much clearer. Thanks. Romel Khan Net2Phone Ph: (732)-363-0213, x241 _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 6 12:09:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26594 for ; Mon, 6 Aug 2001 12:09:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14601; Mon, 6 Aug 2001 11:42:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14570 for ; Mon, 6 Aug 2001 11:42:22 -0400 (EDT) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25975 for ; Mon, 6 Aug 2001 11:41:17 -0400 (EDT) Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f76FftJ14718; Mon, 6 Aug 2001 17:41:55 +0200 (MEST) Message-ID: <3B6EBAC4.DE05B3E9@tzi.uni-bremen.de> Date: Mon, 06 Aug 2001 17:41:56 +0200 From: Joerg Ott X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Connie Blanchard'" , sip@ietf.org Subject: Re: [Sip] Response Code of 422 in Session-Timer draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Since we did not get to Session Timer today... There could be another issue with a 422 response (which may or may not be intended or accepted as such). You run into an interesting failure scenario if you have e.g. two timer-aware proxies and a timer-unaware UAC as follows: UAC ----- P-A ----- P-B ------ UAS Now consider P-A with a preferred session timeout of 10 minutes (which it always inserts) and P-B with a preferred session timeout of 15 minutes (which it always wants to insist on). 1. UAC sends a simple INVITE w/o any session timer. 2. P-A inserts Session-Expires: 600 3. P-B detects that this value is too small and generates a 422 Session Timer too small Session-Expires: 900 4. P-A forwards this up the UAC The INVITE transaction has completed so P-A clears all state (there was no call established). 5. The UAC receives 422 Response but does not understand it. Hence, the 422 defaults to 400 class response; no retry with different timer value is done. -> The UAS was not reached because of a client error which simply was not caused by the client. In particular, the UAC has no idea what to do differently. Interestingly enough, in the other direction, calls go through just fine (assuming a UAS that supports timer). A UAC supporting timer can also initiate calls just fine. A similar scenarion may arise if you have P-A always reducing the Session-Expires: header below what P-B expects (even if the UAC understands and uses Session-Expires:). But this one is solved by having Min-SE: in there set to the value desired by P-B in the UAC. Am I missing something? Joerg _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 6 12:13:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26720 for ; Mon, 6 Aug 2001 12:13:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14905; Mon, 6 Aug 2001 11:49:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14875 for ; Mon, 6 Aug 2001 11:49:39 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26079 for ; Mon, 6 Aug 2001 11:48:34 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA11763 for ; Mon, 6 Aug 2001 08:49:40 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA16339 for ; Mon, 6 Aug 2001 08:49:40 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Mon, 6 Aug 2001 10:49:40 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0137E2F4@IL27EXM10.cig.mot.com> From: Baniel Uri-CUB001 To: "'Gonzalo Camarillo'" Cc: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: RE: [Sip] "t=" in 200 Date: Mon, 6 Aug 2001 10:49:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Yes, actually I agree that for my needs I will be using the mechanism of accepting (200 OK) a call with an "on hold" SDP. When the "acceptor" wants to get the caller off hold he will have to do it explicitly... Thanks, Uri ======================================================================= Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; "If it wasn't for bad luck, I would not have luck at all" - Cream 1968 ======================================================================= > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Monday, August 06, 2001 10:59 AM > To: Baniel Uri-CUB001 > Cc: 'Jonathan Rosenberg'; 'sip@ietf.org' > Subject: Re: [Sip] "t=" in 200 > > > Hello, > > You can always accept (200 OK) a call with an "on hold" SDP. However, > there is no way to signal that you will place the call > out-of-hold at a > particular time in the future. > > It seems that you are looking for such a mechanism, right? > > As Jonathan suggested, using the t line does not seem to be the right > approach. It is neither defined in the spec nor implemented > by anybody. > > Regards, > > Gonzalo > > Baniel Uri-CUB001 wrote: > > > > I just thought of few scenarios, which having the ability > to respond with a > > 200 OK and SDP:t=curr_time+x 0, may enable the UAS to let > the UAC know it > > accepted the call, but will be able to start interchanging > RTP only x > > seconds later on. > > > > > ============================================================== > ========= > > Uri.Baniel@motorola.com, > > Tel: (847) 632 4616; Fax: (847) 632 3963; > > "If it wasn't for bad luck, I would not have luck at all" - > Cream 1968 > > > ============================================================== > ========= > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Friday, August 03, 2001 1:59 PM > > > To: 'Gonzalo Camarillo'; Baniel Uri-CUB001 > > > Cc: 'sip@ietf.org' > > > Subject: RE: [Sip] "t=" in 200 > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Thursday, August 02, 2001 1:10 PM > > > To: Baniel Uri-CUB001 > > > Cc: 'sip@ietf.org' > > > Subject: Re: [Sip] "t=" in 200 > > > > > > > > > Hello, > > > > > > That would be legal, because the session you are actually > > accepting in > > > the one that you are sending in the 200 OK. However, no UA supports > > > this. > > > > SIP imposes restrictions about what can be in the 200 OK in > > order for both > > sides to agree on whats going on. The text says nothing about > > the t value, > > and I would argue that this parameter should not be negotiable. > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 6 12:15:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26794 for ; Mon, 6 Aug 2001 12:15:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14828; Mon, 6 Aug 2001 11:46:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14800 for ; Mon, 6 Aug 2001 11:46:49 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26059 for ; Mon, 6 Aug 2001 11:45:39 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f76FkjN27604; Mon, 6 Aug 2001 17:46:45 +0200 (MEST) Received: from lmf.ericsson.se ([164.48.154.84]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id RAA27314; Mon, 6 Aug 2001 17:46:43 +0200 (MET DST) Message-ID: <3B6EBECB.CA15F797@lmf.ericsson.se> Date: Mon, 06 Aug 2001 18:59:07 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Baniel Uri-CUB001 CC: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: Re: [Sip] "t=" in 200 References: <35DBB8B7AC89D4118E98009027B1009B0137E2E5@IL27EXM10.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, You can always accept (200 OK) a call with an "on hold" SDP. However, there is no way to signal that you will place the call out-of-hold at a particular time in the future. It seems that you are looking for such a mechanism, right? As Jonathan suggested, using the t line does not seem to be the right approach. It is neither defined in the spec nor implemented by anybody. Regards, Gonzalo Baniel Uri-CUB001 wrote: > > I just thought of few scenarios, which having the ability to respond with a > 200 OK and SDP:t=curr_time+x 0, may enable the UAS to let the UAC know it > accepted the call, but will be able to start interchanging RTP only x > seconds later on. > > ======================================================================= > Uri.Baniel@motorola.com, > Tel: (847) 632 4616; Fax: (847) 632 3963; > "If it wasn't for bad luck, I would not have luck at all" - Cream 1968 > ======================================================================= > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Friday, August 03, 2001 1:59 PM > > To: 'Gonzalo Camarillo'; Baniel Uri-CUB001 > > Cc: 'sip@ietf.org' > > Subject: RE: [Sip] "t=" in 200 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Thursday, August 02, 2001 1:10 PM > > > To: Baniel Uri-CUB001 > > > Cc: 'sip@ietf.org' > > > Subject: Re: [Sip] "t=" in 200 > > > > > > > > > Hello, > > > > > > That would be legal, because the session you are actually > > accepting in > > > the one that you are sending in the 200 OK. However, no UA supports > > > this. > > > > SIP imposes restrictions about what can be in the 200 OK in > > order for both > > sides to agree on whats going on. The text says nothing about > > the t value, > > and I would argue that this parameter should not be negotiable. > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 6 13:22:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27954 for ; Mon, 6 Aug 2001 13:22:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17493; Mon, 6 Aug 2001 12:59:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17468 for ; Mon, 6 Aug 2001 12:59:47 -0400 (EDT) Received: from hoteldns02.stsn.com (p82.usslc13.stsn.com [208.32.226.82]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27558 for ; Mon, 6 Aug 2001 12:58:44 -0400 (EDT) Received: from BobP ([10.112.2.159]) by hoteldns02.stsn.com (8.11.0/8.11.0) with SMTP id f76FseH10007; Mon, 6 Aug 2001 09:54:40 -0600 Message-ID: <003e01c11e98$f1254b60$2300000a@acmepacket.com> From: "Bob Penfield" To: "Romel Khan" , References: <6F46FABB90ABD411BD690002B3152FB9466E1A@lkwmail01> Subject: Re: [Sip] Cancel method in SIP bis-04 Date: Mon, 6 Aug 2001 12:57:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Romel Khan" To: Sent: Monday, August 06, 2001 11:45 AM Subject: [Sip] Cancel method in SIP bis-04 > I have couple of questions/points on procedures related to Cancel method (I > don't recall whether SIP bis 04 is clear on that): > 1. UAC sends Invite to UAS. UAS sends 200 OK to UAC. Meanwhile before the > 200 OK is received by the UAC, it for some reason sends a Cancel to the UAS. > So what should happen in this glare situation? I assume the UAS will ignore > the Cancel since it has already sent the 200 OK. And the UAC, upon receiving > the 200 OK, should either send Bye to UAS or let the call connect sending an > ACK depending on the particular reason the Cancel was sent in the 1st time. > The Cancel, however, is not retransmitted. > Or is there a different procedure? Which pages in which SIP RFC might have > talked about this? The UAC must send the ACK, otherwise the UAS will re-transmit the 200-OK (it ignored the CANCEL). After sending the ACK, the UAC can send a BYE. > > 2. UAC sends Invite to UAS. UAS sends a response such as 200 OK but it is > improperly formatted. How should the sending side behave in this case? I > notice from SIP implementations that the UAC will send Cancel to UAS. > It will be very helpful to have some kind of 'reason' header field in the > Cancel request so that the reason why the Cancel is being will be much > clearer. Again, the UAC should send ACK, otherwise UAS will just keep sending the 200-OK. Also, it should send BYE, not CANCEL. There was some discussion of a proposal to add a "Reason" header to the BYE that would indicate why the session is being terminated. I'm not sure if anybody is following up on this. > > Thanks. > > Romel Khan > Net2Phone > Ph: (732)-363-0213, x241 > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 6 19:12:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04020 for ; Mon, 6 Aug 2001 19:12:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29387; Mon, 6 Aug 2001 18:47:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29356 for ; Mon, 6 Aug 2001 18:47:21 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03634 for ; Mon, 6 Aug 2001 18:46:15 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 15:47:41 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg '" Cc: "''sip@ietf.org' '" Date: Mon, 6 Aug 2001 15:47:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Early media proposal. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi Jonathan, I really like the 18x/PRACK offer/answer model for early media. However, in order in order to avoid the high (IMO) conceptual and programmtic complexity of the potential overlapping invites (which I'm sure will result in only one thing - a lot of people not implementing it fully) I have an alterative suggestion. Instead of having overlapping invites (when the caller wants to initiate a media change), simply devise a mechanism to trigger the callee to resend a 18x early media offer. In this manner all the logic is re-used, all the call setup is kept (seamlessly) in the same SIP transaction and it is a lot conceptually simpler (which in my book counts for a lot). The simplest mechanism is to merely come up with a new method that the caller sends - which has no state in itself - that simply causes the callee to send another 18x early media SDP offer. Robert. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 6 22:40:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08189 for ; Mon, 6 Aug 2001 22:40:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03404; Mon, 6 Aug 2001 22:17:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03373 for ; Mon, 6 Aug 2001 22:17:53 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07068 for ; Mon, 6 Aug 2001 22:16:43 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f772HCw3017941 for ; Mon, 6 Aug 2001 22:17:13 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 22:17:48 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Mon, 6 Aug 2001 22:17:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] slides for bis open issues discussion Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, The slides I will be using tomorrow for the sip rfc2543bis open issues discussion can be found at: http://www.jdrosen.net/papers/sip_bis_open.ppt Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 7 05:35:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28682 for ; Tue, 7 Aug 2001 05:35:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19831; Tue, 7 Aug 2001 04:37:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA19801 for ; Tue, 7 Aug 2001 04:37:50 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27771 for ; Tue, 7 Aug 2001 04:36:44 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id EAA04527; Tue, 7 Aug 2001 04:37:43 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id EAA27903; Tue, 7 Aug 2001 04:37:42 -0400 (EDT) Message-ID: <3B6FD3FB.7CD72853@cs.columbia.edu> Date: Tue, 07 Aug 2001 04:41:47 -0700 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Security roadmap draft Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit http://www.cs.columbia.edu/~hgs/sip/drafts/security_roadmap.txt This is a rough draft, not nearly as thorough as Michael Thomas' draft. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 7 07:25:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01024 for ; Tue, 7 Aug 2001 07:24:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22693; Tue, 7 Aug 2001 06:14:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22662 for ; Tue, 7 Aug 2001 06:14:14 -0400 (EDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29162 for ; Tue, 7 Aug 2001 06:13:07 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id f77AEEQ16502 for ; Tue, 7 Aug 2001 06:14:14 -0400 (EDT) Reply-To: From: "Eric Burger" To: "SIP List" Date: Tue, 7 Aug 2001 06:14:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_01C11F08.2E0F7950" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [Sip] Issue #113, wrt Content Sequencing Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C11F08.2E0F7950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On the one hand, I would love to find a generic mechanism for ordering and detecting loss in overlapped non-INVITE content. However, we hashed over this issue in the SIP-events discussion. Namely, content sequencing and recovery is inherently content-specific. Thus I would propose Strict Sequencing (if needed) in the content, as Jonathan originally proposed. ------=_NextPart_000_0008_01C11F08.2E0F7950 Content-Type: text/x-vcard; name="Eric Burger (E-mail).vcf" Content-Disposition: attachment; filename="Eric Burger (E-mail).vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Burger;Eric FN:Eric Burger (E-mail) ORG:SnowShore Networks, Inc. TITLE:Chief Technology Officer TEL;WORK;VOICE:+1 (978) 367-8403 TEL;CELL;VOICE:+1 (703) 304-3883 TEL;WORK;FAX:+1 (978) 367-8499 ADR;WORK:;;285 Billerica Rd.;Chelmsford;MA;01824-4120;United States of = America LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:285 Billerica = Rd.=3D0D=3D0AChelmsford, MA 01824-4120=3D0D=3D0AUnited States of = Ameri=3D ca EMAIL;PREF;INTERNET:eburger@snowshore.com REV:20010410T151935Z END:VCARD ------=_NextPart_000_0008_01C11F08.2E0F7950-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 7 11:30:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06329 for ; Tue, 7 Aug 2001 11:30:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01462; Tue, 7 Aug 2001 10:58:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01393 for ; Tue, 7 Aug 2001 10:58:46 -0400 (EDT) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05583; Tue, 7 Aug 2001 10:57:38 -0400 (EDT) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 0EE776A904; Tue, 7 Aug 2001 17:58:44 +0300 (EEST) Message-ID: <3B70033A.4070407@piuha.net> Date: Tue, 07 Aug 2001 18:03:22 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Cc: sip-security@ietf.org References: <3B6FD3FB.7CD72853@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Extended HTTP authentication draft for SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I'd like to announce a draft we have produced on the use of an extensible authentication scheme for SIP. We hope to be able to talk about this in the SIP Security Bar BOF on Wednesday, and I believe it will also be touched upon in the 3GPP presentation in the SIPPING WG. Currently, SIP can use external security schemes such as IPSec/IKE or TLS also for authentication, or one of the HTTP and PGP methods within the protocol itself. As you know, there is some ongoing work in the group to extend the HTTP methods to better fit the requirements in the SIP case. Also, AAA protocol extensions are under discussion in the AAA WG in order to handle cases where the SIP node doesn't store the authentication passwords by itself and needs to talk to an authentication server over a protocol. What we intend to add to this is one new HTTP/SIP authentication method called HTTP EAP. Here we leverage an existing protocol EAP (RFC 2284), originally developed for the PPP world but nowadays being adopted also for WLANs and possibly other places. EAP supports many authentication methods, such password or token-card based, as well as PKI, GSM, and UMTS AKA-based authentication schemes. Originally, we started to think about an approach like this as the 3G networks required the use of the UMTS AKA authentication scheme (due to the deployed operator infrastructure for handing out the authentication tokens for GSM/UMTS, and the existence of the necessary technical components such as the SIM cards already for other reasons). We could add UMTS AKA authentication directly to SIP, but somehow we feel that it would be better to add generic authentication to SIP in one go, allowing various parties to use different kinds of authentication methods they find suitable in their situation. At the same time, an added benefit of the EAP approach is that existing AAA protocols such as DIAMETER and RADIUS can be used with less extension work, as they already support EAP. Likewise, most SIP equipment could in the future stay unchanged even if new authentication methods are invented. Draft: http://www.arkko.com/draft-torvinen-http-eap-00.txt Presentation: http://www.arkko.com/sip_eap_ietf51.ppt Feedback on this approach would be greatly appreciated, particularly on its SIP applicability, soundness of security, how to proceed with this in the IETF process, and the relationship of this to the various security proposals that the WG is now getting. We also look forward to interesting discussions in general about the SIP security framework. Jari Arkko Ericsson _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 7 12:50:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08139 for ; Tue, 7 Aug 2001 12:50:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04294; Tue, 7 Aug 2001 12:11:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04192 for ; Tue, 7 Aug 2001 12:11:33 -0400 (EDT) Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07248; Tue, 7 Aug 2001 12:10:13 -0400 (EDT) Received: from [213.122.126.85] (helo=tkw) by tungsten.btinternet.com with smtp (Exim 3.22 #9) id 15U9Rr-0003FO-00; Tue, 07 Aug 2001 17:11:15 +0100 Message-ID: <001501c11f5b$a9784100$0200000a@tkw> From: "Pete Cordell" To: , "'sip-ietf (E-mail)'" , , "SG16" , Cc: "Steve Davies" , "Greg Meyer" Date: Tue, 7 Aug 2001 17:10:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Subject: [Sip] Re: VoIP Traversal of Non-upgraded Firewall & NATs @ IETF Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Just to confirm the announcement I made at the SIP meeting this morning.... This meeting is now on... It will be held in: Hilton Rooms 10, 11, & 12 Thursday 17:45 -> 19:00 (although we'll make it shorter if we can) Hope to see you there. Pete. ============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Pete Cordell To: ; 'sip-ietf (E-mail)' ; ; SG16 ; Cc: Steve Davies Sent: 01 August 2001 10:03 Subject: VoIP Traversal of Non-upgraded Firewall & NATs @ IETF > Dear All, > > I would like to have a meeting at the IETF (informal BOF?) discussing > methods for VoIP and Multimedia over IP traversing non-upgraded firewalls > and NATs. These methods are intended to supplement the firewall > architecture, and not require upgrade to existing firewall/NAT components, > or clients (and other infrastructure such as proxies). > > There is a draft discussing one proposal at: > > http://www.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-00.txt > > If others have ideas in this area, then please contact me and we can arrange > some sort of agenda. (Although note that I will be out of contact until the > Sunday before the IETF - i.e. this Sunday! - so we might have to organise > this at the IETF.) > > I hope the format will be something like: > > - Overview presentation of method > - How this is secure and maintains administrator control > - (Repeat for each proposal) > - Collect issues that need to be addressed before going to a formal BOF. > > (The modified agenda involves the final item being changed to 'chaos'!) > > At this stage I would like to avoid discussion about how this compares to > MidCom and other approaches - such as Rosenberg's - as I think it will > quickly turn into a blood bath. - We should save that for the formal BOF! > > I'm hoping to hold the meeting in: > > The King's Suite/Sandringham 1 on > Thursday 17:45 -> 18:45, > > but I obviously haven't had a chance to check this with the organisers. > Therefore, please look out for final details on the noticeboard, and > probably the door of the King's Suite. > > I look forward to seeing you all, > > Pete. > > (P.S. Sorry for putting this on the SG16 and TIPHON lists, but I'm well > aware that many of you attend the IETF and I wanted to make sure you had the > opportunity to come along.) > > ============================================= > Pete Cordell > Tech-Know-Ware > pete@tech-know-ware.com > +44 1473 635863 > ============================================= > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 7 15:27:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11520 for ; Tue, 7 Aug 2001 15:27:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09010; Tue, 7 Aug 2001 14:50:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA08979 for ; Tue, 7 Aug 2001 14:50:15 -0400 (EDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10944 for ; Tue, 7 Aug 2001 14:49:08 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f77InK902071 for ; Tue, 7 Aug 2001 14:49:20 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 7 Aug 2001 13:50:00 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 13:49:36 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430308AC58@crchy271.us.nortel.com> From: "Brian Stucker" To: sip@ietf.org Date: Tue, 7 Aug 2001 13:49:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C11F71.AE114F20" Subject: [Sip] Sip Timers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C11F71.AE114F20 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11F71.AE114F20" ------_=_NextPart_001_01C11F71.AE114F20 Content-Type: text/plain; charset="iso-8859-1" Hey, noticed the discussion about timers has reappeared on the list. Here's a possible solution. <> Regards, Brian ------_=_NextPart_001_01C11F71.AE114F20 Content-Type: text/html; charset="iso-8859-1" Sip Timers

Hey, noticed the discussion about timers has reappeared on the list.

Here's a possible solution.

<<draft-bssp-sip-ctimer00.txt.txt>>

Regards,

Brian

------_=_NextPart_001_01C11F71.AE114F20-- ------_=_NextPart_000_01C11F71.AE114F20 Content-Type: text/plain; name="draft-bssp-sip-ctimer00.txt.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-bssp-sip-ctimer00.txt.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Internet Draft Brian = Stucker Sriram = Parameswar =09 Nortel = Networks Draft-bssp-sip-ctimer00.txt August 7th, 2001 Expires: February, 2001 SIP Timer Preferences STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance = with=20 all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering = Task Force (IETF), its areas, and its working groups. Note that=20 other groups may also distribute working documents as=20 Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six=20 months and may be updated, replace, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet-Drafts = as reference material or to cite them other than as work in=20 progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes a set of extensions to SIP [1] which=20 allows a SIP UA to recommend an appropriate set of retransmission = timers to a called or calling UA in order to provide better=20 service, and reduce network traffic in some networks where direct network bandwidth measurement is difficult or not possible by a=20 UA. It does so by defining one new header, Session-Timers, which specifies the set of retransmission timers appropriate for that=20 session. This new header is present in all 1xx and 2xx responses, as well as any SIP request message, but could be extended to new SIP request methods in the future. 1.0 Introduction When a SIP UA initiates a session with another UA which is = located in a different network, or when a proxy is involved in the = session=20 creation (perhaps as a gateway between disparate network=20 transports), the retransmission timer suggestions in SIP [1] may=20 not apply well.=20 =20 For instance, a UA that normally operates in a 10Mbit network may not have appropriate timer settings for setting up a session to a UA that is located in a 56Kb network, and as a result of this=20 =20 =20 Stucker, Parameswar [Page = 1] =0C Internet Draft SIP Timer Preferences August = 2001 =20 could throttle the UA in the slower network with over-zealous=20 retransmission of SIP messages.=20 =20 The SIP Timestamp header works to prevent this by including a = base clock value that is echoed back by each UAS as the message=20 traverses the network in order to determine appropriate=20 retransmission timers at the UAC. This works well in a relatively homogenous network. Where problems arise is when a proxy is used=20 as a gateway from a relatively "fast" network (i.e. 802.3, LAN, etc.) into a relatively "slow" network (i.e. CDPD, GPRS, etc.),=20 which the initial Timestamp suggests a fast retransmission rate,=20 when that rate is not appropriate to the final destination (which may take a significant amount of time to respond). In order to augment the operation of the Timestamp header, a new=20 header is suggested that allows a UA to explicitly state what it=20 thinks the appropriate retransmission timers are for the session=20 (the values of T1 and T2). The UA receiving this information may=20 wish to completely ignore it if it so chooses. 2.0 Header Field Definitions Table 1 specifies an extension of Table 5 in RFC-2543 [1] for the = new header defined here. Table 1: Definition of use of Session-Timers Header field where proxy ACK BYE CAN INV OPT REG Session-Timers R,1xx,2xx amr - o o o o o 2.1 Session-Timers Header Parameters The Session-Timers header field MAY be included to RECOMMEND to a = client or server on a per-hop, per session basis, to use the=20 retransmission timer values specified by in RFC-2543 [1], or an=20 alternative that may be otherwise be used by that user agent. = This=20 header may be ignored if the user agent so chooses, and does not=20 need to notify the sender in this case. If the user agent chooses to consider using the values specified=20 in the header, then the following algorithm SHOULD apply = (although a suitable alternative may be used): * Retransmission timers should never be "reduced" as a result of=20 accepting a timer value from this header. If the user agent is=20 already using a longer timer setting for that timer, the value=20 of that timer suggested in the Session-Timers header should be=20 ignored. =20 =20 Stucker, Parameswar [Page = 2] =0C Internet Draft SIP Timer Preferences August = 2001 =20 * If a timer has partially expired, and the value of the timer in the Session-Timers header is accepted for use, then the time=20 elapsed for that timer on the user agent MUST be deducted from=20 the timer value in the header before restarting the timer. * Timer values MAY change from response to response, and SHOULD = be evaluated for possible use if the user agent has accepted any=20 previous timer values. Table 2 specifies the parameters for the Session-Timers header. Table 2: Definition of use of Session-Timers Session-Timers =3D "Session-Timers" ":"=20 (( 1# (Timer-name "=3D" length)) * (";")) Timer-name =3D SIP [1] defined timer string Length =3D delta-milliseconds Example : Context-Timers: T1=3D800;T2=3D1200 Would update timers T1 and T2 to 800ms, and 1200ms,=20 respectively. 3.0 Author's Addresses Brian Stucker Nortel Networks 2380 Glenville Richardson, TX 75083 USA electronic mail: bstucker@nortelnetworks.com Sriram Parameswar Nortel Networks 2375-B Glenville Richardson, TX 75083 USA electronic mail: sriramp@nortelnetworks.com 4.0 References [1] Handley, Schulzrinne, Schooler, and Rosenberg, "SIP: Session=20 Initiation Protocol," Request for Comments 2543 bis 02, = Internet=20 Engineering Task Force, Sept. 2000. =20 =20 Stucker, Parameswar [Page = 3] =0C Internet Draft SIP Timer Preferences August = 2001 ------_=_NextPart_000_01C11F71.AE114F20-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 7 16:30:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12264 for ; Tue, 7 Aug 2001 16:30:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10198; Tue, 7 Aug 2001 15:42:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10166 for ; Tue, 7 Aug 2001 15:42:24 -0400 (EDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11692 for ; Tue, 7 Aug 2001 15:41:16 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f77JfM916234 for ; Tue, 7 Aug 2001 15:41:23 -0400 (EDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 7 Aug 2001 14:41:24 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 7 Aug 2001 14:41:00 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430308AD3E@crchy271.us.nortel.com> From: "Brian Stucker" To: "Brian Stucker" , sip@ietf.org Subject: RE: [Sip] Sip Timers Date: Tue, 7 Aug 2001 14:40:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11F78.DCC6FED0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11F78.DCC6FED0 Content-Type: text/plain; charset="iso-8859-1" Please note, that this has NOT been submitted to the IETF. -----Original Message----- From: Stucker, Brian [NGB:B651:EXCH] Sent: Tuesday, August 07, 2001 1:49 PM To: sip@ietf.org Subject: [Sip] Sip Timers Hey, noticed the discussion about timers has reappeared on the list. Here's a possible solution. <> Regards, Brian ------_=_NextPart_001_01C11F78.DCC6FED0 Content-Type: text/html; charset="iso-8859-1" Sip Timers
Please note, that this has NOT been submitted to the IETF.

 -----Original Message-----
From: Stucker, Brian [NGB:B651:EXCH]
Sent: Tuesday, August 07, 2001 1:49 PM
To: sip@ietf.org
Subject: [Sip] Sip Timers

Hey, noticed the discussion about timers has reappeared on the list.

Here's a possible solution.

<<draft-bssp-sip-ctimer00.txt.txt>>

Regards,

Brian

------_=_NextPart_001_01C11F78.DCC6FED0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 8 03:12:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07264 for ; Wed, 8 Aug 2001 03:12:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02133; Wed, 8 Aug 2001 02:31:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02102 for ; Wed, 8 Aug 2001 02:31:55 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06770 for ; Wed, 8 Aug 2001 02:30:48 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f786VsO02584; Wed, 8 Aug 2001 08:31:54 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.24]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f786Vq504138; Wed, 8 Aug 2001 09:31:52 +0300 (EET DST) Message-ID: <3B70DCD3.5FC05BF7@lmf.ericsson.se> Date: Wed, 08 Aug 2001 09:31:47 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'sip@ietf.org'" Subject: Re: [Sip] slides for bis open issues discussion References: Content-Type: multipart/mixed; boundary="------------967D7FE8522DAEA3422638E1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------967D7FE8522DAEA3422638E1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Hopefully, when you read this mail all issues are solved, and the slides aren't needed anymore... :) Anyway, I do have a few comments, and I appologise that I weren't able to post them before. First, I didn't see any issue about the Record-Route, Outbound proxy, and non-DNS UA issue. Did we solve that? Second, I would like to know what people like about the idea of putting the whole media handling, which I proposed earlier, in a separate draft. Then, some comments on a few of the issues: #11: Record-Routing non-INVITE mid-call For this case I think it should also be clarified not only if we are talking about non-routed mid-call requests, or if the proxy actually REPLACES an existing route with another. #71: RTT Estimation with Timestamp My only question: Do we really need this on the application level? And, if a UA wants to calculate the RTT, doesn't the time between sending the request and receiving the response give a pretty good answer? Or, does anyone really need, on the SIP level, to separate the time it took for the request to reach the UAS and the time it took for the response to reach the UAC? #73: Responding to held SDP with held SDP This is related to the issue how to put media on hold in the first place (#133). Also, it depends on the "direction" of the call hold. For example, if a UAC indicates a call hold with "a:inactive" I guess the UAS can return a held SDP too (assuming it is able to put the call on hold. But, if the UAC indicates it is only going to LISTEN to media, the UAS can return the original SDP. And, if the UAC indicates it is only going to SEND media, I guess the UAS can return the original SDP too. Another approach would be to only send only the c= line and the a:inactive (or whatever we will use) attribute, if we assume that the call hold will not affect the codecs, ports etc used, and also assuming that the whole session (ie all streams) will be put on hold. #121: BYE/CANCEL Reason Phrases A proposal is that this stuff could also be put in a separate draft (compare to MEGACO). I am sure we going to come up with new codes in future, and I don't think it's a good idea to write a separate extension draft every time that happens (especially if there is no extension feature attached). The only thing the bis then would have to specify is the response code GROUPING, ie 1xx, 2xx, 3xx, 4xx, 5xx and 6xx. #122: CANCEL on 200/600 stength I would like to apply this also for BYE, because a proxy may receive 200, but it doesn't want to accept THAT branch. For example, it may have received 18x responses from other branches, or for whatever security/authentication reason the proxy does not allow the leg for which it received 200 to be established. #130: BYE v. CANCEL This proposal I like very much :) However, even if we allow BYE w/tags we should not remove the BYE without tags - no matter if the call is established or not. Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > Folks, > > The slides I will be using tomorrow for the sip rfc2543bis open issues > discussion can be found at: > > http://www.jdrosen.net/papers/sip_bis_open.ppt > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------967D7FE8522DAEA3422638E1 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------967D7FE8522DAEA3422638E1-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 8 06:17:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09536 for ; Wed, 8 Aug 2001 06:17:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08219; Wed, 8 Aug 2001 05:57:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08188 for ; Wed, 8 Aug 2001 05:57:03 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09225 for ; Wed, 8 Aug 2001 05:55:53 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f789v0N07991; Wed, 8 Aug 2001 11:57:01 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.24]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f789v0509904; Wed, 8 Aug 2001 12:57:00 +0300 (EET DST) Message-ID: <3B710CE6.C657ECC8@lmf.ericsson.se> Date: Wed, 08 Aug 2001 12:56:54 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mukesh R Shah CC: sip@ietf.org Subject: Re: [Sip] VIA Header References: Content-Type: multipart/mixed; boundary="------------D60E82EC8B2234D2CEF55DB1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------D60E82EC8B2234D2CEF55DB1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Mukesh, I am not really sure I understand your question, but I'll give it a try. In SIP you can have multiple VIA headers. The ABNF, however, also allow you to put all the values of those headers in a single header, separated with a comma. I don't think I've ever seen it in real-world use, but it is allowed. Regards, Christer Holmberg Ericsson Finland Mukesh R Shah wrote: > > Hi All, > > Its a basic doubt . > Why r we having multiple values in VIA header ? > What is the significance of having it? > Also give situation when the proxy will add multiple value to VIA header? > > Thanks in Advance, > Mukesh > > ------------------------------------------------------------------------ > Name: InterScan_Disclaimer.txt > InterScan_Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit --------------D60E82EC8B2234D2CEF55DB1 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------D60E82EC8B2234D2CEF55DB1-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 8 06:18:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09578 for ; Wed, 8 Aug 2001 06:18:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08054; Wed, 8 Aug 2001 05:49:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA08023 for ; Wed, 8 Aug 2001 05:49:36 -0400 (EDT) Received: from pdc2proxy.wipro.com ([203.129.228.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09159 for ; Wed, 8 Aug 2001 05:48:21 -0400 (EDT) Received: from pdc2vwall.wipro.com (pdc2vwall.wipro.com [10.111.14.18]) by pdc2proxy.wipro.com (8.11.3/8.11.3) with SMTP id f78FKP209261 for ; Wed, 8 Aug 2001 15:20:25 GMT Received: from 10.111.12.18 by pdc2vwall.wipro.com (InterScan E-Mail VirusWall NT); Wed, 08 Aug 2001 15:19:29 -0700 Received: from mrshah ([10.111.11.56]) by pdc2mail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GHQTUT00.90W for ; Wed, 8 Aug 2001 15:17:17 +0530 From: "Mukesh R Shah" To: Date: Wed, 8 Aug 2001 15:24:32 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: [Sip] VIA Header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi All, Its a basic doubt . Why r we having multiple values in VIA header ? What is the significance of having it? Also give situation when the proxy will add multiple value to VIA header? Thanks in Advance, Mukesh --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit The Information contained and transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 8 08:42:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11386 for ; Wed, 8 Aug 2001 08:42:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12430; Wed, 8 Aug 2001 08:20:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12401 for ; Wed, 8 Aug 2001 08:20:20 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10939 for ; Wed, 8 Aug 2001 08:19:10 -0400 (EDT) Received: from broadsofsaroja (host217-33-147-192.ietf.ignite.net [217.33.147.192]) by broadsof.temp.veriohosting.com (8.11.2) id f78CKHg11416; Wed, 8 Aug 2001 08:20:18 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Response Code of 422 in Session-Timer draft Date: Wed, 8 Aug 2001 08:19:33 -0400 Message-ID: <000001c12004$624bd720$c09321d9@broadsofsaroja> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3B6EBAC4.DE05B3E9@tzi.uni-bremen.de> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > There could be another issue with a 422 response (which may or may not > be intended or accepted as such). > > You run into an interesting failure scenario if you have e.g. two > timer-aware proxies and a timer-unaware UAC as follows: > > UAC ----- P-A ----- P-B ------ UAS > > Now consider P-A with a preferred session timeout of 10 minutes > (which it always inserts) and P-B with a preferred session timeout > of 15 minutes (which it always wants to insist on). > > 1. UAC sends a simple INVITE w/o any session timer. > 2. P-A inserts Session-Expires: 600 > 3. P-B detects that this value is too small and generates a > > 422 Session Timer too small > Session-Expires: 900 > > 4. P-A forwards this up the UAC > > The INVITE transaction has completed so P-A clears all state > (there was no call established). > > 5. The UAC receives 422 Response but does not understand it. > Hence, the 422 defaults to 400 class response; no retry with > different timer value is done. > > -> The UAS was not reached because of a client error which simply > was not caused by the client. In particular, the UAC has no > idea what to do differently. > > Interestingly enough, in the other direction, calls go through just > fine (assuming a UAS that supports timer). A UAC supporting timer can > also initiate calls just fine. > > A similar scenarion may arise if you have P-A always reducing the > Session-Expires: header below what P-B expects (even if the UAC > understands and uses Session-Expires:). But this one is solved > by having Min-SE: in there set to the value desired by P-B in the > UAC. Solution 1) Have P1 return a 503 with Retry-After of 1 second. This is bad because the same proxies might not be in the path of the subsequent INVITE. A might not submit the request with the same Call-ID. A might not retry at all. Solution 2) Define a new 5xx response which means resubmit the request. The response would be basically mean the same as a 503; however the resubmit should be immediate and the proxies should record-route if they wish to be part of the resubmit. The resubmit may use the same call-id with a higher cseq. One problem is that this would require a bis change. Second problem is that the originator would have to limit the resubmits to avoid attacks and infinite resubmits. Solution 3) Allow P1 to fork the same request to P2 but use a higher Session-Expires. This is bad because P2 potentially may not realize that it is a different request and assume that a forked request merged. Thus the same negative response might get returned. Solution 3's problem is common for any merged forking situation where a proxy includes different headers or header values on the different branches. This could be hopefully avoided by specifying in the bis that if a negative response was returned on a merged branch request, subsequent merged requests must still be checked to see if the same response applies. I prefer solutions 3 if SIP intends to allow proxies to become smarter. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 8 09:23:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12102 for ; Wed, 8 Aug 2001 09:23:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14361; Wed, 8 Aug 2001 09:06:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14334 for ; Wed, 8 Aug 2001 09:06:01 -0400 (EDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11801 for ; Wed, 8 Aug 2001 09:04:52 -0400 (EDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id f78D5xQ00475 for ; Wed, 8 Aug 2001 09:05:59 -0400 (EDT) Reply-To: From: "Eric Burger" To: Subject: RE: [Sip] Sip Timers Date: Wed, 8 Aug 2001 09:05:59 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <85AA7486A2C1D411BCA20000F8073E430308AC58@crchy271.us.nortel.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit At best this is a hint; I'd call it such (like Timers-Hint). Calling it Session-Timers sounds like a request. Yes, the implementer should read the draft before implementing it, but that doesn't always happen :-( I have a more fundamental issue with the concept. How does the originating UAC know about the network topology from the originating UAC to the terminating UAC? Likewise, what if each UAC has a high-speed connection to their proxy, their proxy has a high-speed connection to an IP-IXC, but in the middle of the IP-IXC, there's a slow connection? Each UAC sees a high-speed connection, so they won't give good hints. The draft does hint (correctly) that this is a hop-by-hop issue. The parameter isn't a top-level (end-to-end) UAC attribute; it is hop-by-hop (tie it to Via? If so, how would it survive crossing proxy boundaries? Is that an issue at all? Also, there's a typo in the example in section 2.1. I presume that the example should read Session-Timers: T1=800;T2=1200 and not Context-Timers: T1=800;T2=1200 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 8 09:52:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12682 for ; Wed, 8 Aug 2001 09:52:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14803; Wed, 8 Aug 2001 09:28:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14718 for ; Wed, 8 Aug 2001 09:28:05 -0400 (EDT) Received: from gatekeeper.calltrol.com (root@[65.105.250.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12131 for ; Wed, 8 Aug 2001 09:26:55 -0400 (EDT) Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253]) by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id JAA07576 for ; Wed, 8 Aug 2001 09:29:01 -0400 Received: by NT-SERVER with Internet Mail Service (5.5.2448.0) id <3K3SSXFC>; Wed, 8 Aug 2001 09:29:45 -0400 Message-ID: <60A9CA50081AD4118BD60040F60C1A9F27227E@NT-SERVER> From: Wai Wu To: sip@ietf.org Subject: RE: [Sip] VIA Header Date: Wed, 8 Aug 2001 09:29:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1200E.2FD55E20" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1200E.2FD55E20 Content-Type: text/plain; charset="iso-8859-1" Hi Christer, The Cisco Sip implementation (at least for their IP phones, the ones I am working on are CISCO IP PHONE 7960/7940s) puts values from all the VIA headers in a single header, separated with a comma. Wai Wu -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Wednesday, August 08, 2001 5:57 AM To: Mukesh R Shah Cc: sip@ietf.org Subject: Re: [Sip] VIA Header Hi Mukesh, I am not really sure I understand your question, but I'll give it a try. In SIP you can have multiple VIA headers. The ABNF, however, also allow you to put all the values of those headers in a single header, separated with a comma. I don't think I've ever seen it in real-world use, but it is allowed. Regards, Christer Holmberg Ericsson Finland Mukesh R Shah wrote: > > Hi All, > > Its a basic doubt . > Why r we having multiple values in VIA header ? > What is the significance of having it? > Also give situation when the proxy will add multiple value to VIA header? > > Thanks in Advance, > Mukesh > > ------------------------------------------------------------------------ > Name: InterScan_Disclaimer.txt > InterScan_Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit ------_=_NextPart_001_01C1200E.2FD55E20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] VIA Header

Hi Christer,
        The Cisco = Sip implementation (at least for their IP phones, the ones I am working = on are CISCO IP PHONE 7960/7940s) puts values from all the VIA headers = in a single header, separated with a comma.

Wai Wu

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
Sent: Wednesday, August 08, 2001 5:57 AM
To: Mukesh R Shah
Cc: sip@ietf.org
Subject: Re: [Sip] VIA Header



Hi Mukesh,

I am not really sure I understand your question, but = I'll give it a try.

In SIP you can have multiple VIA headers. The ABNF, = however, also allow
you to put all the values of those headers in a = single header, separated
with a comma. I don't think I've ever seen it in = real-world use, but it
is allowed.

Regards,

Christer Holmberg
Ericsson Finland


Mukesh R Shah wrote:
>
> Hi All,
>
> Its a basic doubt .
> Why r we having multiple values in VIA header = ?
> What is the significance of having it?
> Also give situation when the proxy will add = multiple value to VIA header?
>
> Thanks in Advance,
> Mukesh
>
>   = ------------------------------------------------------------------------=
>          = ;            = ;          Name: = InterScan_Disclaimer.txt
>    = InterScan_Disclaimer.txt    Type: Plain Text = (text/plain)
>          = ;            = ;      Encoding: 7bit

------_=_NextPart_001_01C1200E.2FD55E20-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 8 09:58:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12782 for ; Wed, 8 Aug 2001 09:58:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15147; Wed, 8 Aug 2001 09:30:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15118 for ; Wed, 8 Aug 2001 09:30:49 -0400 (EDT) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12157 for ; Wed, 8 Aug 2001 09:29:39 -0400 (EDT) Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id f78DUSJ09291 for ; Wed, 8 Aug 2001 15:30:28 +0200 (MEST) Message-ID: <3B713EF6.A89BC56D@tzi.uni-bremen.de> Date: Wed, 08 Aug 2001 15:30:30 +0200 From: Joerg Ott X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SIP gettogethers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Dates and times for SIP ad-hoc gettogethers: Security -- Wednesday 1730-1930, Hilton rooms 7,8,9 Call Control -- Wedneday 2200-2400, Hilton Rooms 7,8,9 Firewall Traversal -- Thurs 1745-1900, Hilton Rooms 10,11,12 (Calldd by Mark Davies) Privacy and Outbound Services from Remote Proxy -- Thursday 2130-2300, Hilton rooms 7,8,9 Joerg _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 8 10:15:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13126 for ; Wed, 8 Aug 2001 10:15:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15606; Wed, 8 Aug 2001 09:48:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15574 for ; Wed, 8 Aug 2001 09:48:33 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12577 for ; Wed, 8 Aug 2001 09:47:22 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f78Dn5J18001; Wed, 8 Aug 2001 08:49:05 -0500 Message-ID: <009c01c12010$ecb78420$728821d9@ietf.ignite.net> From: "Dean Willis" To: "IETF SIP" Cc: "Brian Rosen \(E-mail\)" , "Jonathan Rosenberg \(E-mail\)" Date: Wed, 8 Aug 2001 08:40:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] Resend -- Adhoc Meetings at IETF51 (was Bar BOFS) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I don't know what happened when I sent this out yesterday, but it didn't seem to make it. I don't know what happened. On the bright side, there were some changes, and a new notice was probably in-order anyhow. The following SIP-related adhoc meetings are currently scheduled: Security -- Wednesday 1730-1930, Hilton rooms 7,8,9 -- (may change). Firewall Traversal -- Thurs 1745-1900, Hilton Rooms 10,11,12 Privacy, Outbound Services from Remote Proxy (Source routing?) -- Thursday 2030-2300, Hilton rooms 7,8,9 Also, the Call Control session for late tonight has been cancelled at the request of the organizers. Call Control -- Wedneday 2200-2400, Hilton Rooms 7,8,9 -- CANCELLED _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 8 10:23:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13362 for ; Wed, 8 Aug 2001 10:23:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16074; Wed, 8 Aug 2001 09:59:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16046 for ; Wed, 8 Aug 2001 09:59:48 -0400 (EDT) Received: from pdc2proxy.wipro.com ([203.129.228.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12795 for ; Wed, 8 Aug 2001 09:58:29 -0400 (EDT) Received: from pdc2vwall.wipro.com (pdc2vwall.wipro.com [10.111.14.18]) by pdc2proxy.wipro.com (8.11.3/8.11.3) with SMTP id f78JUS212312 for ; Wed, 8 Aug 2001 19:30:28 GMT Received: from 10.111.12.18 by pdc2vwall.wipro.com (InterScan E-Mail VirusWall NT); Wed, 08 Aug 2001 19:29:33 -0700 Received: from mrshah ([10.111.11.56]) by pdc2mail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GHR5FL00.801; Wed, 8 Aug 2001 19:27:21 +0530 From: "Mukesh R Shah" To: "Wai Wu" , Subject: RE: [Sip] VIA Header Date: Wed, 8 Aug 2001 19:34:35 +0530 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <60A9CA50081AD4118BD60040F60C1A9F27227E@NT-SERVER> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C12041.2792A6D0" ------=_NextPart_000_0002_01C12041.2792A6D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [Sip] VIA Headerhi, But i dont think any proxy adds two VIA header value at a time. Am i right ? i think putting of all VIA values in single VIA header might be taking place at the last proxy server or UAS ? Thanks, Mukesh -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Wai Wu Sent: Wednesday, August 08, 2001 7:00 PM To: sip@ietf.org Subject: RE: [Sip] VIA Header Hi Christer, The Cisco Sip implementation (at least for their IP phones, the ones I am working on are CISCO IP PHONE 7960/7940s) puts values from all the VIA headers in a single header, separated with a comma. Wai Wu -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Wednesday, August 08, 2001 5:57 AM To: Mukesh R Shah Cc: sip@ietf.org Subject: Re: [Sip] VIA Header Hi Mukesh, I am not really sure I understand your question, but I'll give it a try. In SIP you can have multiple VIA headers. The ABNF, however, also allow you to put all the values of those headers in a single header, separated with a comma. I don't think I've ever seen it in real-world use, but it is allowed. Regards, Christer Holmberg Ericsson Finland Mukesh R Shah wrote: > > Hi All, > > Its a basic doubt . > Why r we having multiple values in VIA header ? > What is the significance of having it? > Also give situation when the proxy will add multiple value to VIA header? > > Thanks in Advance, > Mukesh > ------------------------------------------------------------------------ > Name: InterScan_Disclaimer.txt > InterScan_Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit ------=_NextPart_000_0002_01C12041.2792A6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] VIA Header
hi,
 
But i=20 dont think any proxy adds two VIA header value at a = time.
Am i=20 right ?
i=20 think putting of all VIA values in single VIA header might be taking = place at=20 the last proxy server or UAS ?
 
Thanks,
Mukesh
-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of Wai Wu
Sent:=20 Wednesday, August 08, 2001 7:00 PM
To:=20 sip@ietf.org
Subject: RE: [Sip] VIA = Header

Hi Christer,=20
        The = Cisco Sip=20 implementation (at least for their IP phones, the ones I am working on = are=20 CISCO IP PHONE 7960/7940s) puts values from all the VIA headers in a = single=20 header, separated with a comma.

Wai Wu

-----Original Message-----
From:=20 Christer Holmberg [mailto:christer.holmber= g@lmf.ericsson.se]=20
Sent: Wednesday, August 08, 2001 5:57 AM =
To: Mukesh R Shah
Cc: = sip@ietf.org=20
Subject: Re: [Sip] VIA Header



Hi Mukesh,

I am not really sure I understand your question, but = I'll give=20 it a try.

In SIP you can have multiple VIA headers. The ABNF, = however,=20 also allow
you to put all the values of = those headers=20 in a single header, separated
with a comma. = I don't=20 think I've ever seen it in real-world use, but it
is=20 allowed.

Regards,

Christer Holmberg
Ericsson = Finland


Mukesh R Shah wrote:
>=20
> Hi All,
>=20
> Its a basic doubt .
>=20 Why r we having multiple values in VIA header ?
>=20 What is the significance of having it?
> = Also give=20 situation when the proxy will add multiple value to VIA header? =
>
> Thanks in = Advance,=20
> Mukesh
> =
>  =20 = ------------------------------------------------------------------------<= /FONT>=20
>          =             &= nbsp;        =20 Name: InterScan_Disclaimer.txt
>   =20 InterScan_Disclaimer.txt    Type: Plain Text=20 (text/plain)
>          =             &= nbsp;    =20 Encoding: 7bit

------=_NextPart_000_0002_01C12041.2792A6D0-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The Information contained and transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 8 11:36:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15182 for ; Wed, 8 Aug 2001 11:36:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16605; Wed, 8 Aug 2001 10:09:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16548 for ; Wed, 8 Aug 2001 10:08:58 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12983 for ; Wed, 8 Aug 2001 10:07:49 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f78E8uO17790; Wed, 8 Aug 2001 16:08:56 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.24]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f78E8t517634; Wed, 8 Aug 2001 17:08:55 +0300 (EET DST) Message-ID: <3B7147F0.1DDE3DD3@lmf.ericsson.se> Date: Wed, 08 Aug 2001 17:08:48 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mukesh R Shah CC: Wai Wu , sip@ietf.org Subject: Re: [Sip] VIA Header References: Content-Type: multipart/mixed; boundary="------------B43C57ACA1CBDBF1213FD5A1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------B43C57ACA1CBDBF1213FD5A1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Mukesh, >But i dont think any proxy adds two VIA header value at a time. >Am i right ? Yes. >i think putting of all VIA values in single VIA header might be taking >place at the last proxy server or UAS ? I think it can take place at anywhere. Regards, Christer Holmberg Ericsson Finland > > Thanks, > Mukesh > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On > Behalf Of Wai Wu > Sent: Wednesday, August 08, 2001 7:00 PM > To: sip@ietf.org > Subject: RE: [Sip] VIA Header > > Hi Christer, > The Cisco Sip implementation (at least for their IP > phones, the ones I am working on are CISCO IP PHONE > 7960/7940s) puts values from all the VIA headers in a single > header, separated with a comma. > > Wai Wu > > -----Original Message----- > From: Christer Holmberg > [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, August 08, 2001 5:57 AM > To: Mukesh R Shah > Cc: sip@ietf.org > Subject: Re: [Sip] VIA Header > > Hi Mukesh, > > I am not really sure I understand your question, but I'll > give it a try. > > In SIP you can have multiple VIA headers. The ABNF, however, > also allow > you to put all the values of those headers in a single > header, separated > with a comma. I don't think I've ever seen it in real-world > use, but it > is allowed. > > Regards, > > Christer Holmberg > Ericsson Finland > > Mukesh R Shah wrote: > > > > Hi All, > > > > Its a basic doubt . > > Why r we having multiple values in VIA header ? > > What is the significance of having it? > > Also give situation when the proxy will add multiple value > to VIA header? > > > > Thanks in Advance, > > Mukesh > > > > > ------------------------------------------------------------------------ > > > Name: > InterScan_Disclaimer.txt > > InterScan_Disclaimer.txt Type: Plain Text > (text/plain) > > Encoding: 7bit > > Name: InterScan_Disclaimer.txt > InterScan_Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit --------------B43C57ACA1CBDBF1213FD5A1 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------B43C57ACA1CBDBF1213FD5A1-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 8 11:37:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15219 for ; Wed, 8 Aug 2001 11:37:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16619; Wed, 8 Aug 2001 10:09:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16555 for ; Wed, 8 Aug 2001 10:08:58 -0400 (EDT) Received: from ix.netcorps.com (ix.netcorps.com [216.65.52.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12986 for ; Wed, 8 Aug 2001 10:07:50 -0400 (EDT) Received: from indigosw.com (194-78-202-25.pro.turboline.skynet.be [194.78.202.25]) by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id HAA13805 for ; Wed, 8 Aug 2001 07:10:15 -0700 (PDT) Message-ID: <3B7147F3.B58E8579@indigosw.com> Date: Wed, 08 Aug 2001 16:08:51 +0200 From: Ali Aziz Organization: Indigo Software X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Content-Type: multipart/mixed; boundary="------------5AB0CD678AAC053D0746AC23" Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------5AB0CD678AAC053D0746AC23 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------5AB0CD678AAC053D0746AC23 Content-Type: text/x-vcard; charset=us-ascii; name="aaziz.vcf" Content-Description: Card for Ali Aziz Content-Disposition: attachment; filename="aaziz.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Aziz;Ali Ahmad tel;fax:+32 2 280 26 76 tel;home:+32 2 648 22 51 tel;work:+32 2 235 09 63 x-mozilla-html:FALSE url:www.indigosw.com org:Indigo Software, Inc. version:2.1 email;internet:aaziz@indigosw.com title:Software Engineer adr;quoted-printable:;;50 Rue Wiertz=0D=0A;Brussels;;1050;Belgium fn:Ali Aziz end:vcard --------------5AB0CD678AAC053D0746AC23-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 8 12:07:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15968 for ; Wed, 8 Aug 2001 12:06:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21592; Wed, 8 Aug 2001 11:49:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21561 for ; Wed, 8 Aug 2001 11:49:44 -0400 (EDT) Received: from mail2.dynamicsoft.com (mail2.dynamicsoft.com [216.173.40.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15442 for ; Wed, 8 Aug 2001 11:48:30 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (bluebird [216.173.40.50]) by mail2.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f78Fn0w3023231 for ; Wed, 8 Aug 2001 11:49:00 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Aug 2001 11:49:36 -0400 Message-ID: From: Rakesh Shah To: "SIPWG Mailing List (E-mail)" Date: Wed, 8 Aug 2001 11:49:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12021.B8D63460" Subject: [Sip] SIP WG - Last Call Weekly Status Update Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12021.B8D63460 Content-Type: text/plain; charset="iso-8859-1" This Working Group Last Call status update is being sent out to keep the list up-to-speed. Any questions about this information can be addressed to Rakesh Shah ( rshah@dynamicsoft.com ). Last Call Calendar ( http://www.softarmor.com/sipwg/lastcall/lccalendar.pl ). Drafts in some part of WGLC: draft-ietf-sip-serverfeatures-05.txt Has completed WGLC. Draft was submitted to IESG, returned for updates and updates were made by authors. draft-ietf-sip-session-timer-05.txt Has completed Last Call Review. Open issues closed at IETF-51. Authors are updating the draft. Once complete, will be submitted to IESG. draft-ietf-sip-callerprefs-04.txt Last Call Reviewers assigned. Open list discussion to be announced 17Aug01. draft-ietf-sip-mib-03.txt In NITS review. Open discussion to be announced 31Aug01. draft-roach-sip-subscribe-notify-03.txt This work has been picked up as Working Group items. Therefore a new draft was issued - draft-ietf-sip-events-00.txt. -00 is not ready for WGLC. draft-ietf-sip-manyfolks-resource-01.txt Ready for WGLC. NITS reviewer to be assigned around 17Aug01. Drafts queued up for WGLC: draft-ietf-sip-call-auth-01.txt Ready for WGLC. NITS review being planned. draft-ietf-sip-privacy-02.txt Will have a -03 issued. -03 will be ready to go to WGLC. draft-ietf-sip-state-01.txt Ready for WGLC. Queued up after call-auth. draft-ietf-sip-rfc2543bis-04.txt Expected to be ready for WGLC around 6Oct01. draft-johnston-sip-osp-token-01.txt Progressing to WGLC. draft-ietf-sip-security-requirements-00.txt While this is on the LCC, there are no listed authors. This may be pulled off for now. draft-ietf-sip-guidelines-02.txt Token: AD. Awaiting feedback from Allison Mankin. draft-ietf-sip-100rel-03.txt Feedback expected from Allison Mankin. All of this information is kept current on the SIP WG Supplemental Website ( http://www.softarmor.com/sipwg ). Regards, Rakesh _________________________ Mr. Rakesh C. Shah Project Coordinator dynamicsoft Inc. 72 Eagle Rock Avenue 1st Floor East Hanover, N.J. 07936 (973) 952-5066 direct (201) 214-6084 cell (973) 952-5000 main (973) 952-5050 fax rshah@dynamicsoft.com ------_=_NextPart_001_01C12021.B8D63460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This Working Group Last Call status update is being sent = out to keep=20 the list up-to-speed.
 
Any=20 questions about this information can be addressed to Rakesh Shah (rshah@dynamicsoft.com).=
 
Last Call Calendar (http://ww= w.softarmor.com/sipwg/lastcall/lccalendar.pl).
 
Drafts in some part of=20 WGLC:
 
draft-ietf-sip-serverfeatures-05.txt
Has=20 completed WGLC. Draft was submitted to IESG, returned for updates and=20 updates were made by authors.
 
draft-ietf-sip-session-timer-05.txt
Has=20 completed Last Call Review. Open issues closed at IETF-51. Authors are = updating=20 the draft. Once complete, will be submitted to = IESG.
 
draft-ietf-sip-callerprefs-04.txt
Last Call Reviewers assigned. Open list discussion to be = announced=20 17Aug01.
 
draft-ietf-sip-mib-03.txt
In=20 NITS review. Open discussion to be announced = 31Aug01.
 
draft-roach-sip-subscribe-notify-03.txt
This work has been picked up as Working Group items. Therefore = a new=20 draft was issued - draft-ietf-sip-events-00.txt. -00 is not ready for=20 WGLC.
 
draft-ietf-sip-manyfolks-resource-01.txt
Ready for WGLC. NITS reviewer to be assigned around=20 17Aug01.
 
Drafts queued up for WGLC:
 
draft-ietf-sip-call-auth-01.txt
Ready for WGLC. NITS review being planned.
 
draft-ietf-sip-privacy-02.txt
Will have a -03 issued. -03 will be ready to go to=20 WGLC.
 
draft-ietf-sip-state-01.txt
Ready for WGLC. Queued up after call-auth.
 
draft-ietf-sip-rfc2543bis-04.txt
=
Expected to be ready for WGLC = around=20 6Oct01.
 
draft-johnston-sip-osp-token-01.txt
Progressing to WGLC.
 
draft-ietf-sip-security-requirements-00.txt
While this is on the LCC, there = are no=20 listed authors. This may be pulled off for now.
 
draft-ietf-sip-guidelines-02.txt
=
Token: AD. Awaiting feedback from = Allison=20 Mankin.
 
draft-ietf-sip-100rel-03.txt
Feedback expected from Allison=20 Mankin.
 
All=20 of this information is kept current on the SIP WG Supplemental Website = (http://www.softarmor.com/sipwg).
 
 
Regards,

Rakesh
_________________________
Mr. = Rakesh C.=20 Shah
Project Coordinator
dynamicsoft Inc.
72 Eagle Rock Avenue
1st Floor
East = Hanover,=20 N.J. 07936
(973) 952-5066 = direct
(201) 214-6084 cell
(973) = 952-5000=20 main
(973) 952-5050=20 fax
rshah@dynamicsoft.com
 
------_=_NextPart_001_01C12021.B8D63460-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 8 13:33:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17895 for ; Wed, 8 Aug 2001 13:33:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25228; Wed, 8 Aug 2001 13:10:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25199 for ; Wed, 8 Aug 2001 13:10:11 -0400 (EDT) Received: from cam-po2.genuity.com (cam-po2.genuity.com [171.78.68.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17366 for ; Wed, 8 Aug 2001 13:09:03 -0400 (EDT) Received: from ksethare_2 (dhcp113-156.genuity.com [171.78.113.156]) by cam-po2.genuity.com (8.11.3/8.11.2) with SMTP id f78HAA903973 for ; Wed, 8 Aug 2001 13:10:10 -0400 (EDT) Message-Id: <200108081710.f78HAA903973@cam-po2.genuity.com> X-Recipient: X-Sender: ksethare@po3.Genuity.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 08 Aug 2001 13:02:52 -0400 To: sip@ietf.org From: Elliot Eichen (by way of Kerry Sethares ) Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Sip] Symposium on IP Telephony: ICC 2002 / IPTel 2002 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: quoted-printable Dear Colleague:

As part of the IEEE Conference on Communications (ICC 2002), and
in combination with IPTel 2002, a symposium on IP Telephony and
Voice Over IP will be held in New York City, 28 April - 2 May,
2002.=A0 This symposium is part of Symposium G: Multimedia Services and
VoIP - Services and Technologies.=A0 Participation in this symposium is
open to all registrants of ICC 2002 (i.e., separate registration is=20
not required).=A0 Please note that the paper submission deadline for the
symposium has been extended to 3 September 2001.

Papers submitted for consideration should focus on topics
related to IP Telephony services, and the technologies needed to
implement those services.=A0 Examples of topics of interest
include:

Architecture and Protocols:
- Advanced Feature/Call Routing
- Protocol Interoperability
- Network Scalability and Reliability

Network Interworking
- 3G Wireless
- PSTN

Applications and Services
- IP-PBX / IP-Centrex
- Messaging and Presence
- Call Centers
- Conferencing
- IP-Telephone over Broadband Access
- Desktop Integration and IP Telephony
- Internet Gaming

Security
- Privacy and Encryption
- Authorization and Authentication
- Firewalls
- Regulatory Requirements

Operations Support Systems
- Network Configuration and Management
- Service Creation and Provisioning
- Accounting

Pilots and Deployments
- Advanced Applications
- Performance/Scalability/Robustness
- User Experience

Quality of Service
- WAN/LAN/Application Layer QoS
- Voice/Video Coding and Transmission

The paper submission schedule and process is the same as for the
general ICC 2002 conference.=A0 When submitting your paper through the
Automated Paper Submission System (all papers must be submitted
electronically), please note that themes for IP Telephony and VoIP are
G10 through G16 on the drop down menu.

Important Sites:
----------------

Call for Papers, Symposium on Multimedia and VoIP:
http://www.icc2002.com/MultimediaSymp.html

Instructions for Authors:
http://www.icc2002.com/InfoForAuthors.html

ICC 2002:
http://www.icc2002.com/

IPTel 2002
http://www.iptel.org/2002/


Best Regards:

Elliot Eichen
Co-Chair, Symposium on Multimedia and VoIP - Services and
Technologies



 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 9 12:24:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29370 for ; Thu, 9 Aug 2001 12:24:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13884; Thu, 9 Aug 2001 12:03:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13853 for ; Thu, 9 Aug 2001 12:03:53 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28664 for ; Thu, 9 Aug 2001 12:02:44 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA06261 for ; Thu, 9 Aug 2001 12:03:53 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA11568; Thu, 9 Aug 2001 12:03:52 -0400 (EDT) Message-ID: <3B72DF8A.51F84269@cs.columbia.edu> Date: Thu, 09 Aug 2001 12:07:54 -0700 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org, sip-implementors@cs.columbia.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] FYI: SIPstone Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit This is for information only. This is not a work item of the SIP working groups. Some folks at Ubiquity and Columbia University have put together a first draft on how to measure, in a repeatable fashion, some typical performance metrics for SIP proxy, redirect and registrar servers. The metrics are supposed to reflect common operational conditions; they are not intended to test the functionality, protocol conformance, robustness or overload behavior of the servers. We will also provide a simple test tool that can be used to run these tests, probably in early September. The draft is at http://www.cs.columbia.edu/sip/drafts/sipstone.pdf Since this is not of interest to all members of this list and is not an IETF work item, I have set up a new list for the discussion of this topic at http://lists.cs.columbia.edu/mailman/listinfo/sipstone Messages can be addressed to sipstone@cs.columbia.edu The authors of the draft look forward to your comments and suggestions. Henning _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 9 12:53:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00070 for ; Thu, 9 Aug 2001 12:53:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14449; Thu, 9 Aug 2001 12:22:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14417 for ; Thu, 9 Aug 2001 12:22:25 -0400 (EDT) Received: from mail.inetmail.att.net (mailhost1.inetmail.att.net [204.127.132.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29246 for ; Thu, 9 Aug 2001 12:20:41 -0400 (EDT) Received: from ranjit ([12.41.17.140]) by mail.inetmail.att.net (mtiagic01) with SMTP id <20010809153938gi128279lqe>; Thu, 9 Aug 2001 15:39:38 +0000 From: "Ranjit K Avasarala" To: Date: Thu, 9 Aug 2001 10:46:52 -0500 Message-ID: <000501c120ea$83103c80$0d00000a@testone.masconit.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200107251034.GAA07687@ietf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 7bit Subject: [Sip] query on draft-rosenberg-sip-entfw-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi I have a question on a statement in this draft: It says NAT will disappear with the deployment of Ipv6. Why is it so? Regards Ranjit -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, July 25, 2001 5:35 AM Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-rosenberg-sip-entfw-02.txt << Message: Untitled Attachment >> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : NAT Friendly SIP Author(s) : J. Rosenberg, J. Weinberger, H. Schulzrinne Filename : draft-rosenberg-sip-entfw-02.txt Pages : 32 Date : 24-Jul-01 In this draft, we discuss how SIP can traverse enterprise and residential firewalls and NATs. This environment is challenging because we assume here that the end user has little or no control over the firewall or NAT, and that the firewall or NAT is completely ignorant of SIP A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosenberg-sip-entfw-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosenberg-sip-entfw-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 9 16:11:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04535 for ; Thu, 9 Aug 2001 16:11:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20899; Thu, 9 Aug 2001 15:55:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20870 for ; Thu, 9 Aug 2001 15:55:10 -0400 (EDT) Received: from femail13.sdc1.sfba.home.com (femail13.sdc1.sfba.home.com [24.0.95.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04091 for ; Thu, 9 Aug 2001 15:54:02 -0400 (EDT) Received: from c1009573a ([24.7.239.16]) by femail13.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20010809195504.GXYW2054.femail13.sdc1.sfba.home.com@c1009573a> for ; Thu, 9 Aug 2001 12:55:04 -0700 Message-ID: <005e01c1210d$b9730960$6401a8c0@flrmnd1.tx.home.com> From: "Kevin's email" To: Date: Thu, 9 Aug 2001 14:58:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit confirm 592279 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 10 03:53:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00818 for ; Fri, 10 Aug 2001 03:53:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12933; Fri, 10 Aug 2001 03:30:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12902 for ; Fri, 10 Aug 2001 03:30:56 -0400 (EDT) Received: from ss3000e.cselt.it (ss3000e.cselt.it [163.162.41.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00427 for ; Fri, 10 Aug 2001 03:29:47 -0400 (EDT) Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0GHU00KALCNWAC@ss3000e.cselt.it> for sip@ietf.org; Fri, 10 Aug 2001 09:26:21 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Aug 2001 09:30:50 +0200 Content-return: allowed Date: Fri, 10 Aug 2001 09:29:54 +0200 From: "Rombola' Pasquale" To: "'sip@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" Subject: [Sip] (no subject) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, could i have a list of causes for error codes ? If not possible to get all list, I would like to know a list of possible causes when a SIP-server return a "404 - Not Found" error to a client. Pasquale Rombola` _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 10 06:51:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03296 for ; Fri, 10 Aug 2001 06:51:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17625; Fri, 10 Aug 2001 06:38:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17597 for ; Fri, 10 Aug 2001 06:38:07 -0400 (EDT) Received: from ss3000e.cselt.it (ss3000e.cselt.it [163.162.41.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02937 for ; Fri, 10 Aug 2001 06:36:40 -0400 (EDT) Received: from lemon.cselt.it (lemon [163.162.4.1]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0GHU0056DLBI9M@ss3000e.cselt.it> for sip@ietf.org; Fri, 10 Aug 2001 12:33:19 +0200 (MET DST) Received: from tilab.com (hpi10687.cselt.it [163.162.3.188]) by lemon.cselt.it with ESMTP (8.7.1/8.7.1) id MAA27200; Fri, 10 Aug 2001 12:25:58 +0200 (METDST) Date: Fri, 10 Aug 2001 12:37:04 +0200 From: Alberto Cuda Subject: Re: [Sip] (no subject) To: "Rombola' Pasquale" Cc: sip@ietf.org Message-id: <3B73B950.66113340@tilab.com> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rombola' Pasquale wrote: > Hello, > could i have a list of causes for error codes ? > If not possible to get all list, I would like to know a list of possible > causes when a SIP-server return a "404 - Not Found" error to a client. Section 11 of draft rfc2543bis-04 contains that list. Status code 404 is defined on page 67: # The server has definitive information that the user does not exist # at the domain specified in the Request-URI. # This status is also returned if the domain in the Request-URI does # not match any of the domains handled by the recipient of the # request. Cheers. Alberto. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 10 10:25:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAB05381 for ; Fri, 10 Aug 2001 10:25:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21779; Fri, 10 Aug 2001 10:09:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21749 for ; Fri, 10 Aug 2001 10:09:52 -0400 (EDT) Received: from gatekeeper.calltrol.com (root@[65.105.250.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05163 for ; Fri, 10 Aug 2001 10:08:42 -0400 (EDT) Received: from nt-server.telephonyserver.com (nt-server [192.168.0.253]) by gatekeeper.calltrol.com (8.8.4/8.8.7) with ESMTP id KAA15131; Fri, 10 Aug 2001 10:11:20 -0400 Received: by NT-SERVER with Internet Mail Service (5.5.2448.0) id <3K3SSXLF>; Fri, 10 Aug 2001 10:12:01 -0400 Message-ID: <60A9CA50081AD4118BD60040F60C1A9F272280@NT-SERVER> From: Wai Wu To: "'sip@ietf.org'" Cc: "'Jasson Casey'" Subject: RE: [Sip] VIA Header Date: Fri, 10 Aug 2001 10:11:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C121A6.6C374B50" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C121A6.6C374B50 Content-Type: text/plain; charset="iso-8859-1" We have custom SIP proxy product. As with every other proxy, we insert a the proxy's Via header (with Via: and value) in the request message. So now we have two Via headers (one for the proxy, one for the endpoint making the request). When we get the response message back from the destination (a Cisco 7960), there is only one Via header (with two value seperated by a comma) in the message. Wai -----Original Message----- From: Jasson Casey [mailto:casey@metreos.com] Sent: Thursday, August 09, 2001 9:17 PM To: Wai Wu Subject: Re: [Sip] VIA Header How exactly does that work, the phone is the endpoint. When it sends a message it only has one via value (itself, or is it something to do with multi-homing, etc). And when it receives a message it is not adding a value. I am confused. Just curious. -jasson ----- Original Message ----- From: Wai Wu To: sip@ietf.org Sent: Wednesday, August 08, 2001 8:29 AM Subject: RE: [Sip] VIA Header Hi Christer, The Cisco Sip implementation (at least for their IP phones, the ones I am working on are CISCO IP PHONE 7960/7940s) puts values from all the VIA headers in a single header, separated with a comma. Wai Wu -----Original Message----- From: Christer Holmberg [ mailto:christer.holmberg@lmf.ericsson.se ] Sent: Wednesday, August 08, 2001 5:57 AM To: Mukesh R Shah Cc: sip@ietf.org Subject: Re: [Sip] VIA Header Hi Mukesh, I am not really sure I understand your question, but I'll give it a try. In SIP you can have multiple VIA headers. The ABNF, however, also allow you to put all the values of those headers in a single header, separated with a comma. I don't think I've ever seen it in real-world use, but it is allowed. Regards, Christer Holmberg Ericsson Finland Mukesh R Shah wrote: > > Hi All, > > Its a basic doubt . > Why r we having multiple values in VIA header ? > What is the significance of having it? > Also give situation when the proxy will add multiple value to VIA header? > > Thanks in Advance, > Mukesh > > ------------------------------------------------------------------------ > Name: InterScan_Disclaimer.txt > InterScan_Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit ------_=_NextPart_001_01C121A6.6C374B50 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] VIA Header
We have custom SIP proxy product. As with every other proxy, we insert a the proxy's Via header (with Via: and value) in the request message. So now we have two Via headers (one for the proxy, one for the endpoint making the request). When we get the response message back from the destination (a Cisco 7960), there is only one Via header (with two value seperated by a comma) in the message.
 
Wai
 
-----Original Message-----
From: Jasson Casey [mailto:casey@metreos.com]
Sent: Thursday, August 09, 2001 9:17 PM
To: Wai Wu
Subject: Re: [Sip] VIA Header

How exactly does that work, the phone is the endpoint. When it sends a message it only has one via value (itself, or is it something to do with multi-homing, etc). And when it receives a message it is not adding a value. I am confused.
 
Just curious.
 
-jasson
----- Original Message -----
From: Wai Wu
Sent: Wednesday, August 08, 2001 8:29 AM
Subject: RE: [Sip] VIA Header

Hi Christer,
        The Cisco Sip implementation (at least for their IP phones, the ones I am working on are CISCO IP PHONE 7960/7940s) puts values from all the VIA headers in a single header, separated with a comma.

Wai Wu

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
Sent: Wednesday, August 08, 2001 5:57 AM
To: Mukesh R Shah
Cc: sip@ietf.org
Subject: Re: [Sip] VIA Header



Hi Mukesh,

I am not really sure I understand your question, but I'll give it a try.

In SIP you can have multiple VIA headers. The ABNF, however, also allow
you to put all the values of those headers in a single header, separated
with a comma. I don't think I've ever seen it in real-world use, but it
is allowed.

Regards,

Christer Holmberg
Ericsson Finland


Mukesh R Shah wrote:
>
> Hi All,
>
> Its a basic doubt .
> Why r we having multiple values in VIA header ?
> What is the significance of having it?
> Also give situation when the proxy will add multiple value to VIA header?
>
> Thanks in Advance,
> Mukesh
>
>   ------------------------------------------------------------------------
>                                Name: InterScan_Disclaimer.txt
>    InterScan_Disclaimer.txt    Type: Plain Text (text/plain)
>                            Encoding: 7bit

------_=_NextPart_001_01C121A6.6C374B50-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 10 14:00:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09046 for ; Fri, 10 Aug 2001 14:00:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26833; Fri, 10 Aug 2001 13:43:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26802 for ; Fri, 10 Aug 2001 13:43:39 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08883 for ; Fri, 10 Aug 2001 13:42:29 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 10:43:20 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , sip@ietf.org Subject: RE: [Sip] bis-04 available! Date: Fri, 10 Aug 2001 10:43:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Also Jonathan, The maddr header is still listed as mandatory for Record-Route in Table 2. Regards, Robert. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, August 03, 2001 9:15 PM > To: 'John.Hearty@Level3.com'; Jonathan Rosenberg; sip@ietf.org > Subject: RE: [Sip] bis-04 available! > > > > > > > > -----Original Message----- > > From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com] > > Sent: Tuesday, July 24, 2001 4:09 PM > > To: jdrosen@dynamicsoft.com; sip@ietf.org > > Subject: RE: [Sip] bis-04 available! > > > > > > Jonathan, > > > > Section 16.3 includes the following updated language in the second > > paragraph (thanks): > > > > The URL SHOULD NOT contain the > > transport parameter, but can in private networks where it is known > > that elements on both sides of the proxy support the specific > > transport. > > > > However, the following language in paragraph 4 also needs to > > be modified so > > there is no conflict: > > > > The proxy MAY modify the Record-Route > > value matching the one it inserted into the request. Like the URL in > > the request, it MUST be a SIP URL and MUST NOT contain a transport > > parameter. > > Thanks for pointing it out. I've fixed it for -05. > > > > > > > > I'd also like to note that since the Record-Route may be > > modified, it is > > possible the transport could be modified, thus elements on > > both sides of the > > proxy may not need to support the specific transport as the > > first modified > > language indicates. For example, leave off the transport on the > > Record-Route of an Invite going into the private network so > > UDP defaults on > > the inside, and include transport=tls in the 200 OK's > > Record-Route when > > interfacing with another element over an unsecure network. > > This allows > > subsequent requests to run over the same secure connection > an initial > > transaction ran over, without requiring the same transport on > > the other side > > of the proxy. > > > Yes, you are correct. I have fixed this for -05 as well. > > -Jonathan R. > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 10 14:27:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09362 for ; Fri, 10 Aug 2001 14:27:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27557; Fri, 10 Aug 2001 14:07:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA27527 for ; Fri, 10 Aug 2001 14:06:58 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09153 for ; Fri, 10 Aug 2001 14:05:48 -0400 (EDT) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7AI6UQ27746; Fri, 10 Aug 2001 11:06:30 -0700 (PDT) Received: from cisco.com (dhcp-171-71-159-231.cisco.com [171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id AGW09869; Fri, 10 Aug 2001 13:06:24 -0500 (CDT) Message-ID: <3B7422C1.D2FCA77E@cisco.com> Date: Fri, 10 Aug 2001 13:06:57 -0500 From: Henry Chen X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Markus.Isomaki@nokia.com'" , christer.holmberg@lmf.ericsson.se, sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-kiss-sip-s100rel-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > If I could do SIP over from scratch, I would change many, many things, not > the least of which was reliability of provisional responses. But, we have no > such luxury. Could you list some most valuable things you would like to change? Thanks, Henry _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 10 17:08:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11572 for ; Fri, 10 Aug 2001 17:08:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02955; Fri, 10 Aug 2001 16:51:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02926 for ; Fri, 10 Aug 2001 16:51:47 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11380 for ; Fri, 10 Aug 2001 16:50:37 -0400 (EDT) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id UAA01022 for ; Fri, 10 Aug 2001 20:51:45 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id UAA10494 for ; Fri, 10 Aug 2001 20:51:45 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <3RFXNKM3>; Fri, 10 Aug 2001 14:51:44 -0600 Message-ID: <17052388D394D411803900508BDFFAF601B36E78@n0214idc1.oss.level3.com> To: sip@ietf.org Subject: RE: [SIP] Killing hung media streams Date: Fri, 10 Aug 2001 14:51:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Sorry to dredge up this thread again, but in reading through it, I didn't get the impression there was consensus on what to do, and didn't notice anything in bis-04 that addressed it. Getting back to the original issue that prompted it (though many varied needs were voiced), say we have a UA that gets media it is not expecting as it has no corresponding session. The early consensus seemed to be to send ICMPs. The desire of that UA is to get the sender to stop the stream. This is my main concern with this thread. The sender of the stream may desire to attempt to re-establish the session, or may desire to kill the session it believes was active and associated with the stream. This seems to be an implementation specific decision, though communicating that desire may be something that is a protocol issue. What should the UA sending the media do when it gets ICMPs in either case? In my envirenment, I could live with either action taken by the UA, but need some action(s) standardized, rather than the current inaction. In the first case (re-Invite), I would establish a new session which would likely be to a different media address/port, and expect the UAC to stop sending to the first port. In the second case, I would send a 481 if a BYE for a non-existent session was received. Note that there was discussion in the thread of sending a 481 response to a re-Invite. At least in my environment, we would send the ICMPs because we have no session associated with the received stream. Hence we may not have state for that session, and would recognize the Invite as a new session and not a re-Invite, so could not be expected to send a 481. John Hearty Level 3 Communications, Inc. -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Wednesday, June 27, 2001 9:11 AM To: Fairlie-Cuninghame, Robert Cc: Jonathan Rosenberg; sip@ietf.org Subject: Re: [SIP] Killing hung media streams Hello, > Perhaps something along the lines that a proxy MAY use a 481 > inidication to remove a call from a active call-state; however, call > state must be retained for at least 32 seconds so that BYE requests > may be propagated to all record-routed proxy. If a proxy considers the call down when the 481 is received, it will just have to route the BYE that will be received later as an out-of-the-blue BYE. Since the BYE will have record-route, I do not think this is a major problem. Regards, Gonzalo > > Robert. > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, June 26, 2001 8:12 PM > To: Jonathan Rosenberg > Cc: 'adam.roach@ericsson.com'; 'Michael Thomas'; > John.Hearty@level3.com; sip@ietf.org > Subject: Re: [SIP] Killing hung media streams > > Hello, > > > So, this begs a related question, which Pauls email introduces. If > we say > > that a 481 to the INVITE means the call is down, does that mean the > UAC > > should issue a BYE, or just destroy the call state? Right now, > bis-03 says > > it should consider the call down, and does not mandate that a BYE > should be > > sent (since, in any case, it will also result in a 481). The > advantage of > > sending a BYE is for call-stateful boxes in the middle. It gives us > the nice > > property that a call is always terminated by a BYE, even if > triggered as a > > result of some other event in the SIP signaling path. This reduces > the > > number of cases that devices need to worry about. > > With this addition we basically recover the nice feature of treating > unknown 4xx reponses as 400. SIP entities that do not understand 481 > will be able to treat a 481 received as a 400. That is, 481 indicates > that the request failed (as any other 4xx response), but it does not > indicate that the session has been terminated. This will still be > indicated by a BYE. > > Best regards, > > Gonzalo > > > > > So, I would propose that text be added to bis-03 which further > mandates that > > a BYE be sent upon receiving a 481 to a mid-call request. Any > objections? > > > > Paul also wrote: > > > But there are some issues with the re-INVITE that I don't > understand: > > > > > > If I believe the problem is with my end, and there is something > > > I can change (e.g. in my SDP) that would help solve the problem, > > > then of course I can offer that. > > > > > > But it seems like either I will believe the problem is with the > > > other end, or else I will have no idea where it is and have no > > > idea what kind of change might help. Suppose I have received ICMP > > > errors on my sends, and suspect the port I am sending to, or the > > > path to it, are down. When I send a reinvite, there is nothing > > > obvious for me to change in *my* SDP - I want the other end to > > > offer me something that will work better. So perhaps I send > > > unchanged SDP. When the other end receives this, it may have no > > > idea that anything is wrong. How does it decide that it should do > > > anything other than send unchanged SDP back? > > > > Well, its the job of the user at the other end to know that there is > a > > problem if one of its media streams has failed. How it knows this > depends on > > the device. In the case of a decomposed gateway, if the gateway > fails, > > presumably the MGC can detect this, and therefore do something about > it when > > the re-INVITE arrives. > > > > The interesting case is when the failure in the media stream is not > due to > > either endpoint, but rather something in the network. In this case, > a > > re-INVITE won't help, as it will change nothing (both sides offer > the same > > SDP as before). In this case, you UA has to know to stop re-INVITing > after a > > while, if the re-INVITEs don't eventually solve the problem. I > suspect this > > will be a rare case, since if the media fails due to a network > failure, the > > signaling will probably fail as well. > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sip mailing list > > Sip@ietf.org > > http://www.ietf.org/mailman/listinfo/sip > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Aug 11 04:10:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04623 for ; Sat, 11 Aug 2001 04:10:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23085; Sat, 11 Aug 2001 03:52:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23054 for ; Sat, 11 Aug 2001 03:52:01 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04511 for ; Sat, 11 Aug 2001 03:50:50 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Sat, 11 Aug 2001 00:51:42 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'sip@ietf.org'" Cc: "'jdrosen@dynamicsoft.com'" Date: Sat, 11 Aug 2001 00:51:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Weakness in SIP offer/answer model. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I perceive a strong weakness in the current SIP offer/answer model. The problem pertains to the fact that the callee has no way of indicating its media profile requirements. Consider the situation: A sends INVITE B with m=audio 5454 RTP/AVP 0 m=video 4444 RTP/AVP 31 However the server only supports (or requires for this call) a different profile, eg RTP/SAVP or some other transport profile (RTP/AVP-USCTP or TLS or something). There is no way that the callee has to communicate this information to the caller. This will be needed for proper deployment of SRTP on servers and a great many other things. - You cannot accept the call by setting the port to zero and then sending a re-INVITE as you cannot be sure that the client supports this profile. Answering calls successfully when you really don't have the ability to communicate is something that we want to avoid at all costs (dead handset syndrome). - It cannot be communicated in SIP headers as this is a layer violation (and just bad design). You are trying to use the session protocol to signal he required SDP transport paths. - You could send a 4xx error with an SDP indicate the appropriate offer that the caller should make to be successful. The requires more messages, longer call setup times and new parsing & analysis logic of the SDP on the client side. I don't like it. I have a proposal: I think what we need is to allow a offer/counter-offer/answer model. Now this sounds very familiar -> Jonathan's new Early Media model! SDP in INVITE, callee instead sends counter-offer in reliable provisional response, to which the caller either accepts or rejects with the SDP in PRACK. When the 200 OK is eventually sent by the callee it is in answer to the SDP in the PRACK (rather than original INVITE). I would like to see this generalized such that it can also be used with local ringback (rather than removed as some have requested). Once again, I see this functionality as _absolutely_ crucial to the proper deployment of SRTP and other SDP transport profiles. This also apples to the situation where the callee needs to know whether the caller supports a certain SDP capability (for instance, support for a particular SDP attributes) - another very, very important case. Please suggest something else if you don't like this scheme. [Jonathan proposed an alternate solution in the open issues section of his early media draft: .... We would then need a token in the 1xx somewhere which says "I ignored your offer of SDP in the INVITE, this 2xx is an offer, not an answer". This token, perhaps a require token, would be present in the original 1xx but not 1xx in response to re-INVITEs. We could apply this to INVITE/2xx/ACK as well. We should try to make any scheme consistent and as long as it works I am not bothered.] Regards, Robert. P.S. I'm going to be away for the next couple of weeks (good duck and cover tactic :-) _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 00:37:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05565 for ; Tue, 14 Aug 2001 00:37:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28641; Tue, 14 Aug 2001 00:09:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28610 for ; Tue, 14 Aug 2001 00:09:06 -0400 (EDT) Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05303 for ; Tue, 14 Aug 2001 00:07:58 -0400 (EDT) Received: from khanr ([12.89.131.85]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP id <20010814040838.XLRQ8490.mtiwmhc23.worldnet.att.net@khanr> for ; Tue, 14 Aug 2001 04:08:38 +0000 Message-ID: <000b01c12477$1a70e900$5583590c@khanr> From: "Munira Sharmin" To: Date: Tue, 14 Aug 2001 00:10:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP bis 04 questions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit 1. Section 15.4, 1st paragraph: +ACI-A UA MUST NOT initiate a new regular transaction while a regular transaction is in progress+ACI-. What does 'regular transaction' mean here? 2. Section 15.4, 3rd paragraph: +ACI-The To field of CANCEL requests always contain exactly the same value as the request it is cancelling+ACI-. Does it mean that the CANCEL request will not have a tag if a previous INVITE request that it is canceling does not have a tag even if a provisional response had a tag in it? _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 09:07:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02440 for ; Tue, 14 Aug 2001 09:07:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19348; Tue, 14 Aug 2001 08:52:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19317 for ; Tue, 14 Aug 2001 08:52:43 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01365 for ; Tue, 14 Aug 2001 08:51:30 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 13:52:41 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9E05@RSYS002A> From: "Price, Richard" To: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Cc: "'Jonathan Rosenberg'" Date: Tue, 14 Aug 2001 13:52:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Sip] Reduced processing overhead for SIP compression Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, Now that the ROHC WG is looking at SIP compression between the mobile and the proxy, I would like to discuss the possibility of combining a SIP compressor with the SIP stack itself. A "SIP-aware" compression algorithm such as EPIC performs the compression by parsing a SIP message, converting text strings to their Huffman equivalents. If we are performing compression in the mobile and the SIP proxy then we can miss out the text phase altogether, writing a SIP stack capable of reading and outputting Huffman characters directly. Motivation for combining the SIP compressor with the SIP stack is that the processing overhead of compression is negligible, or perhaps even negative (as Huffman characters are shorter than their text equivalents, so there is less to read/output). Comments on this suggestion would be appreciated, particularly to check that it fits with the "protocol shim" for carrying compressed SIP messages as proposed by Jonathan Rosenberg. Regards, Richard P ------------------------------------------------------------------------- Richard Price Internet Applications & Mobility Roke Manor Research Ltd. Old Salisbury Lane Romsey, Hants SO51 0ZN, UK. Telephone: +44 1794 833681 E-mail: richard.price@roke.co.uk ------------------------------------------------------------------------- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 09:26:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03693 for ; Tue, 14 Aug 2001 09:26:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20150; Tue, 14 Aug 2001 09:13:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20119 for ; Tue, 14 Aug 2001 09:13:55 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02847 for ; Tue, 14 Aug 2001 09:12:42 -0400 (EDT) Received: from mailhost.ubiquity.net by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 14 Aug 2001 13:13:55 UT Received: from ubiquity.net ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 14 Aug 2001 14:14:28 +0100 Message-ID: <3B7923E9.7582FC37@ubiquity.net> Date: Tue, 14 Aug 2001 14:13:13 +0100 From: James Undery X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Price, Richard" CC: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" , "'Jonathan Rosenberg'" Subject: Re: [Sip] Reduced processing overhead for SIP compression References: <76C92FBBFB58D411AE760090271ED4186F9E05@RSYS002A> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Aug 2001 13:14:28.0933 (UTC) FILETIME=[0C756F50:01C124C3] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Price, Richard" wrote: > Hi, > > Now that the ROHC WG is looking at SIP compression between the > mobile and the proxy, I would like to discuss the possibility > of combining a SIP compressor with the SIP stack itself. > > A "SIP-aware" compression algorithm such as EPIC performs the > compression by parsing a SIP message, converting text strings > to their Huffman equivalents. If we are performing compression > in the mobile and the SIP proxy then we can miss out the text > phase altogether, writing a SIP stack capable of reading and > outputting Huffman characters directly. > > Motivation for combining the SIP compressor with the SIP stack > is that the processing overhead of compression is negligible, > or perhaps even negative (as Huffman characters are shorter > than their text equivalents, so there is less to read/output). > > Comments on this suggestion would be appreciated, particularly > to check that it fits with the "protocol shim" for carrying > compressed SIP messages as proposed by Jonathan Rosenberg. My comment would be this is an implementation issue and an obvious (?) extension, if you make the the shim a "logical shim" for an optimised stack this would work fine. I'd also note that it doesn't require both ends to make the same implementation decisions. James Undery _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 09:27:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03760 for ; Tue, 14 Aug 2001 09:27:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20199; Tue, 14 Aug 2001 09:15:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20169 for ; Tue, 14 Aug 2001 09:15:36 -0400 (EDT) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02944 for ; Tue, 14 Aug 2001 09:14:24 -0400 (EDT) Received: from cabo3 (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f7EDF7J18858; Tue, 14 Aug 2001 15:15:07 +0200 (MEST) From: "Dr. Carsten Bormann" To: "Price, Richard" , , Cc: "'Jonathan Rosenberg'" Date: Tue, 14 Aug 2001 15:15:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <76C92FBBFB58D411AE760090271ED4186F9E05@RSYS002A> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] RE: [rohc] Reduced processing overhead for SIP compression Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Now that the ROHC WG is looking at SIP compression between the > mobile and the proxy, Just as a careful wording reminder: We aren't officially chartered yet to do this. The WG chairs have seen some "general hallway nods" (can I patent this term?) from the ADs, but until the charter is written, they can't say "yes". This shouldn't stop us all from working on this, of course. > If we are performing compression > in the mobile and the SIP proxy then we can miss out the text > phase altogether This is an implementation strategy question, not a question about the interoperability of the standard (or do you think it is a requirement/nice-to-have on the standard to allow this implementation strategy?). The strategy may make sense depending on a lot of factors, including make-or-buy decisions on the SIP stack. Gruesse, Carsten _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 10:20:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05666 for ; Tue, 14 Aug 2001 10:20:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21741; Tue, 14 Aug 2001 10:05:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21710 for ; Tue, 14 Aug 2001 10:05:53 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05253 for ; Tue, 14 Aug 2001 10:04:40 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 15:05:50 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9E07@RSYS002A> From: "Price, Richard" To: "'Dr. Carsten Bormann'" , sip@ietf.org, rohc@cdt.luth.se, "'James Undery'" Cc: "'Jonathan Rosenberg'" Date: Tue, 14 Aug 2001 15:05:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Sip] RE: [rohc] Reduced processing overhead for SIP compression Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, I raised this issue to allay concerns that SIP compression would be a significant resource drain on the proxy. If we choose this implementation strategy then compression has no processing overhead at all. Only requirement on the standard is that it should be lightweight enough not to preclude this implementation strategy! Regards, Richard P -----Original Message----- From: Dr. Carsten Bormann [mailto:cabo@tzi.org] Sent: Tuesday, August 14, 2001 2:15 PM To: Price, Richard; sip@ietf.org; rohc@cdt.luth.se Cc: 'Jonathan Rosenberg' Subject: RE: [rohc] Reduced processing overhead for SIP compression > Now that the ROHC WG is looking at SIP compression between the > mobile and the proxy, Just as a careful wording reminder: We aren't officially chartered yet to do this. The WG chairs have seen some "general hallway nods" (can I patent this term?) from the ADs, but until the charter is written, they can't say "yes". This shouldn't stop us all from working on this, of course. > If we are performing compression > in the mobile and the SIP proxy then we can miss out the text > phase altogether This is an implementation strategy question, not a question about the interoperability of the standard (or do you think it is a requirement/nice-to-have on the standard to allow this implementation strategy?). The strategy may make sense depending on a lot of factors, including make-or-buy decisions on the SIP stack. Gruesse, Carsten --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 10:41:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06166 for ; Tue, 14 Aug 2001 10:41:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22221; Tue, 14 Aug 2001 10:27:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22192 for ; Tue, 14 Aug 2001 10:27:19 -0400 (EDT) Received: from cundall.co.uk ([193.118.202.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05755 for ; Tue, 14 Aug 2001 10:26:06 -0400 (EDT) Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000055542; Tue, 14 Aug 2001 15:28:12 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: Date: Tue, 14 Aug 2001 15:27:03 +0100 To: sip@ietf.org, rohc@cdt.luth.se From: Lawrence Conroy Cc: "Dr. Carsten Bormann" , "Price, Richard" , "'Jonathan Rosenberg'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Sip] RE: [rohc] Reduced processing overhead for SIP compression Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > > Now that the ROHC WG is looking at SIP compression between the >> mobile and the proxy, > >Just as a careful wording reminder: >We aren't officially chartered yet to do this. >The WG chairs have seen some "general hallway nods" (can I patent this >term?) from the ADs, but until the charter is written, they can't say "yes". >This shouldn't stop us all from working on this, of course. > >> If we are performing compression >> in the mobile and the SIP proxy then we can miss out the text >> phase altogether > >This is an implementation strategy question, not a question about the >interoperability of the standard (or do you think it is a >requirement/nice-to-have on the standard to allow this implementation >strategy?). >The strategy may make sense depending on a lot of factors, including >make-or-buy decisions on the SIP stack. > >Gruesse, Carsten > >--- >Mailing list for Robust Header Compression WG >Archive: http://www.cdt.luth.se/rohc/ To which I reply, (In the hypothetical case that SIP/Whatever Compression is chartered in time to be used for GERAN R5:) Yup; It *is* an implementation issue. However, if someone can buy in a stack (or develop one) that reduces the compression processing requirements a lot, then this is going to be favourably received by mobile phone manufacturers. As Carsten points out, it is a "nice-to-have" to allow this implementation option, and I'd be uncomfortable losing it. The protocol and compression scheme will work regardless of implementation option chosen, but it may calm some unhappy people if we don't add a new feature requiring X Mips to implement (for a change, they tell me :). BR, Lawrence -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 10:46:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06293 for ; Tue, 14 Aug 2001 10:46:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22731; Tue, 14 Aug 2001 10:34:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22701 for ; Tue, 14 Aug 2001 10:34:11 -0400 (EDT) Received: from watermelon.icoe.att.com (mushroom.icoe.net [194.242.71.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05921 for ; Tue, 14 Aug 2001 10:32:58 -0400 (EDT) Received: from romeo-w2000.icoe.att.com (mikan.icoe.att.com [135.76.170.4]) by watermelon.icoe.att.com (Postfix) with ESMTP id 8D62B41A12; Tue, 14 Aug 2001 16:33:48 +0200 (MET DST) Message-Id: <5.1.0.14.0.20010814162216.02e15eb8@watermelon.icoe.att.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 14 Aug 2001 16:36:31 +0200 To: Jonathan Rosenberg From: Romeo Zwart Subject: RE: [Sip] I-D ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt Cc: sip@ietf.org, rohc@cdt.luth.se In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Coming back from vacation I see a lot of water has passed under the bridge on this topic. One minor question remains, please see below. At 11:38 PM 7/30/2001, Jonathan Rosenberg wrote: > > -----Original Message----- > > From: Romeo Zwart [mailto:Romeo.Zwart@att.com] > > Sent: Thursday, July 19, 2001 3:27 PM > > To: jdrosen@dynamicsoft.com > > Cc: sip@ietf.org; rohc@cdt.luth.se > > Subject: Re: [Sip] I-D ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt > > > > Jonathan, > > > > In the diagram of section 4.6, the WRITE HIGH REFERENCE token > > is shown as > > identical to the WRITE HIGH token. I assume this is a typo. > > What is the > > intended token for the WRITE HIGH REFERENCE case? > >No, they're not the same. The WRITE HIGH REFERECE appears on the top of page >9. So, WRITE REFERENCE is: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| index |1|1|0| TC | tokens.. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >and WRITE HIGH REFERENCE is: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| index |0|1|1| index |x|x|x| TC | tokens > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Right, whereas, in section 4.4 WRITE HIGH is also shown as: 4.4 WRITE HIGH +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| index |0|1|1| index | length | entry... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ One of these has to be a typo, right? Romeo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 10:53:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06481 for ; Tue, 14 Aug 2001 10:53:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22928; Tue, 14 Aug 2001 10:40:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22900 for ; Tue, 14 Aug 2001 10:40:09 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06048 for ; Tue, 14 Aug 2001 10:38:48 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7EEblO23822; Tue, 14 Aug 2001 16:37:47 +0200 (MEST) Received: from e0000865d41e2 (eplpc6014.epl.ericsson.se [150.132.176.14]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with SMTP id QAA15466; Tue, 14 Aug 2001 16:37:44 +0200 (MET DST) Reply-To: From: "Hans Hannu" To: "'Price, Richard'" , , Cc: "'Jonathan Rosenberg'" Date: Tue, 14 Aug 2001 16:37:47 +0200 Message-ID: <006401c124ce$b0136ad0$0eb08496@e0000865d41e2.epl.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 In-Reply-To: <76C92FBBFB58D411AE760090271ED4186F9E05@RSYS002A> Content-Transfer-Encoding: 7bit Subject: [Sip] RE: [rohc] Reduced processing overhead for SIP compression Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > A "SIP-aware" compression algorithm such as EPIC performs the > compression by parsing a SIP message, converting text strings > to their Huffman equivalents. If we are performing compression > in the mobile and the SIP proxy then we can miss out the text > phase altogether, writing a SIP stack capable of reading and > outputting Huffman characters directly. Is this really compression anymore? To be it sounds like making SIP binary. /Hans H > > Motivation for combining the SIP compressor with the SIP stack > is that the processing overhead of compression is negligible, > or perhaps even negative (as Huffman characters are shorter > than their text equivalents, so there is less to read/output). > > Comments on this suggestion would be appreciated, particularly > to check that it fits with the "protocol shim" for carrying > compressed SIP messages as proposed by Jonathan Rosenberg. > > Regards, > > Richard P > > -------------------------------------------------------------- > ----------- > Richard Price > Internet Applications & Mobility > Roke Manor Research Ltd. > Old Salisbury Lane > Romsey, Hants > SO51 0ZN, UK. > Telephone: +44 1794 833681 > E-mail: richard.price@roke.co.uk > -------------------------------------------------------------- > ----------- > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 12:18:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08689 for ; Tue, 14 Aug 2001 12:18:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25377; Tue, 14 Aug 2001 12:00:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25333 for ; Tue, 14 Aug 2001 11:59:59 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08089 for ; Tue, 14 Aug 2001 11:58:44 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 16:59:51 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9E09@RSYS002A> From: "Price, Richard" To: "'Hans.Hannu@epl.ericsson.se'" Cc: sip@ietf.org, rohc@cdt.luth.se Date: Tue, 14 Aug 2001 16:59:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Sip] RE: [rohc] Reduced processing overhead for SIP compression Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, Yes, this is still compression because the output of a combined SIP stack/SIP compressor is identical to the output of a standalone compressor. Key difference between this and making SIP binary is that the Huffman binary codes are made up by the compressor and do not need to be standardized by the SIP WG: thus we avoid all of the problems synchronizing between the text and binary encodings for SIP. Regards, Richard P -----Original Message----- From: Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] Sent: Tuesday, August 14, 2001 3:38 PM To: Price, Richard; sip@ietf.org; rohc@cdt.luth.se Cc: 'Jonathan Rosenberg' Subject: RE: [rohc] Reduced processing overhead for SIP compression > A "SIP-aware" compression algorithm such as EPIC performs the > compression by parsing a SIP message, converting text strings > to their Huffman equivalents. If we are performing compression > in the mobile and the SIP proxy then we can miss out the text > phase altogether, writing a SIP stack capable of reading and > outputting Huffman characters directly. Is this really compression anymore? To be it sounds like making SIP binary. /Hans H > > Motivation for combining the SIP compressor with the SIP stack > is that the processing overhead of compression is negligible, > or perhaps even negative (as Huffman characters are shorter > than their text equivalents, so there is less to read/output). > > Comments on this suggestion would be appreciated, particularly > to check that it fits with the "protocol shim" for carrying > compressed SIP messages as proposed by Jonathan Rosenberg. > > Regards, > > Richard P > > -------------------------------------------------------------- > ----------- > Richard Price > Internet Applications & Mobility > Roke Manor Research Ltd. > Old Salisbury Lane > Romsey, Hants > SO51 0ZN, UK. > Telephone: +44 1794 833681 > E-mail: richard.price@roke.co.uk > -------------------------------------------------------------- > ----------- > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 12:55:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10040 for ; Tue, 14 Aug 2001 12:55:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27745; Tue, 14 Aug 2001 12:38:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27716 for ; Tue, 14 Aug 2001 12:38:30 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09359 for ; Tue, 14 Aug 2001 12:37:17 -0400 (EDT) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA28418; Tue, 14 Aug 2001 18:38:10 +0200 (MET DST) Received: from mchh159e.mch.pn.siemens.de ([139.21.130.171]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA18070; Tue, 14 Aug 2001 18:38:12 +0200 (MET DST) Received: by mchh159e.mch.pn.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 18:38:19 +0200 Message-ID: From: Tan Ya-Ching ICM N MC MI E73 To: "'sip@ietf.org'" Cc: "'Jonathan Rosenberg'" , "'Henning G. Schulzrinne'" , Del Castillo Giuseppe ICM N MC MI E71 Subject: [SIP] Forking proxy and early call leg (also : Early media draft) Date: Tue, 14 Aug 2001 18:38:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Figure 3 and Figure 5 of draft-rosenberg-sip-early-media-00 do not show the correct handling of the 489 response (10) by the forking proxy. Figure 3 shows that the 489 response is forwarded immediately upstream by the forking proxy. According to the bis draft, for 4xx/5xx response received by the forking proxy, "the proxy MUST send an ACK. It remembers the response if it has a lower status code class than any previous 4xx and 5xx response. On completion, a response with the lowerst response class is returned if there were no 2xx, 3xx or 6xx responses". A SIP bis-compliant forking proxy would therefore silently discards this 489 response, and forwards only the 200 OK (19) upstream to the UAC. This brings us to a question concerning "early call leg". J. Rosenberg proposed in an earlier SIP mail that "a 1xx with tags and record-routes establish an early call leg. Within that early call leg, you can send non-INVITE requests, including PRACK, INFO, BYE, etc., as you would for an answered call leg". But how would the client be aware that the forking proxy has received a non-2xx final response and as a result, that particular early call leg has been terminated ? We therefore propose the following slight modification of forking proxy behavior to section 17.4 (Forking Proxy) of the bis draft : Once the forking proxy has received and forwarded a provisional response with a To tag upstream, it MUST forward upstream any final non-2xx responses received on that branch, regardless of the responses received on the other branches. On branches where no provisional responses with To tag were received, the forking proxy behaves as usual, by selecting the "best available final status" for those branches. - Ya-Ching Tan & Giuseppe Del Castillo _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 15:31:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13558 for ; Tue, 14 Aug 2001 15:31:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03529; Tue, 14 Aug 2001 15:13:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA03499 for ; Tue, 14 Aug 2001 15:13:36 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13316 for ; Tue, 14 Aug 2001 15:12:19 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7EJDZi05538 for ; Tue, 14 Aug 2001 14:13:35 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 14 Aug 2001 14:13:29 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 14 Aug 2001 14:13:28 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIP compression Date: Tue, 14 Aug 2001 14:13:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] RE: [rohc] Reduced processing overhead for SIP compression X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEk2jc4LXjrbZDNEdWpVgBQi2kYTQAGbOrA To: , Cc: , X-OriginalArrivalTime: 14 Aug 2001 19:13:29.0068 (UTC) FILETIME=[336132C0:01C124F5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA03500 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, I wasn't present during the ROHC WG meeting, so I don't know if this is a moot question already. But what happened to the requirements? Specifically, is this going to be a generic protocol or SIP-only? (I guess this will be clarified in the new WG charter as well as in the meeting minute.) BR, Zhigang _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 17:03:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15089 for ; Tue, 14 Aug 2001 17:03:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05185; Tue, 14 Aug 2001 16:40:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA05157 for ; Tue, 14 Aug 2001 16:40:48 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14680 for ; Tue, 14 Aug 2001 16:39:29 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7EKe2O12406; Tue, 14 Aug 2001 22:40:02 +0200 (MEST) Received: from lmf.ericsson.se (rmt160135.am.ericsson.se [138.85.160.135]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id WAA29234; Tue, 14 Aug 2001 22:39:58 +0200 (MET DST) Message-ID: <3B798FB1.739A295@lmf.ericsson.se> Date: Tue, 14 Aug 2001 23:53:05 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org, Jonathan Rosemberg Subject: Re: [Sip] Early media draft References: <3B6975F4.7AEFC21E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, I sent the mail below some time ago and we had some discussion. I would like to discuss this issue in depth now, in order to get the early media draft stable. Comments are welcome. Regards, Gonzalo Gonzalo Camarillo wrote: > > Hello Jonathan, > > I have read the early media draft again. I will give my opinion on some > of the open questions that you have placed in the draft and I will make > a proposal. > > The current mechanism effectively "trashes" the SDP contained in the > first INVITE (and the SDP contained in re-INVITEs). Even if we are using > a Require header and there would not be any backward compatibility > problems, I do not like that. > > The current draft considers that when I add a media stream to the early > media it means that I would like to have the same media stream added to > the final media (media after the 200 OK). I would like to differentiate > between early media and final media. That is, I can send you an INVITE > with an audio media stream and a video media stream. You send me early > media that consists of audio only. However, when you finally answer with > a 200 OK, I want you to answer my original proposal (video+audio), not > to renegotiate the parameters that we were using for early media. > > My proposal is that negotiation of final media and negotiation of early > media are kept separate. That is, the SDP in the 200 OK will always be > the answer to the SDP in the INVITE. Regardless of whether we are using > early media or not (I believe that this is more consistent with bis). > > This would avoid media clipping when the 200 OK finally arrives, since > the UAS can send media without waiting for the ACK. > > The process of changing early media parameters would have to be changed. > Right now the UAC issues a re-INVITE. The SDP in this re-INVITE is > effectively ignored (the real SDP exchange is 1xx-PRACK). My proposal is > that the SDP in the re-INVITE is an update (or a refresh) of the SDP > that was contained in the first INVITE. > > In short, I want the "INVITE-200 OK" SDP exchange to be independent of > the "1xx-PRACK" SDP exchange. > > I believe that keeping both negotiations separate (early media > parameters and final media parameters) is a powerful tool. I can update > my final media SDP without updating my early media SDP and vice versa > (or update both at the same time, of course). > > Opinions? > > Best regards, > > Gonzalo > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com > > _______________________________________________ > Sip mailing list http://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 17:17:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15343 for ; Tue, 14 Aug 2001 17:17:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05911; Tue, 14 Aug 2001 17:02:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05880 for ; Tue, 14 Aug 2001 17:02:47 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15045 for ; Tue, 14 Aug 2001 17:01:26 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7EL1tO14976; Tue, 14 Aug 2001 23:01:55 +0200 (MEST) Received: from lmf.ericsson.se (rmt160135.am.ericsson.se [138.85.160.135]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA00245; Tue, 14 Aug 2001 23:01:50 +0200 (MET DST) Message-ID: <3B7994CE.E23C1704@lmf.ericsson.se> Date: Wed, 15 Aug 2001 00:14:54 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Colin Perkins CC: Jonathan Rosenberg , sip@ietf.org, mmusic Subject: Re: [Sip] Re: SDP hold References: <200108051942.PAA07784@purple.east.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello Colin, Colin Perkins wrote: > >OK, we can call the "on hold" scenario I just described as a > >"temporarily disabled media" (the latter is probably more accurate). > >Anyway, we still need the new tag. I do not really care if we call it > >neithersendnorrecv, nomedia or inactive. However, as Christer suggested, > >in order to be consistent with other protocols we can use "inactive". > > > >Anyway, my question is: Colin, do you think that such a tag should be > >included in SDPnew? Otherwise we can write a half-page draft defining > >this attribute. > > I don't see the need for a new draft, so if there's consensus on this, send > me some suggested wording. > In page 25 of: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-03.txt we have to add the following attribute: a=inactive This specifies that the tools should be started in inactive mode. This is necessary for interactive conferences where users can put other users on hold. No media is sent over an inactive media stream. It can be either a session or media attribute, and is not dependent on charset. When you make the change let us know, since RFC2543bis will have to be updated as well. Best regards, Gonzalo > Colin -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 18:28:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16301 for ; Tue, 14 Aug 2001 18:28:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07512; Tue, 14 Aug 2001 18:04:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07484 for ; Tue, 14 Aug 2001 18:04:04 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15974 for ; Tue, 14 Aug 2001 18:02:50 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f7EM4iJ03281; Tue, 14 Aug 2001 17:04:45 -0500 Message-ID: <01ac01c1250d$1f35b2e0$ad036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: "IETF SIP" Cc: "Scott Bradner \(E-mail\)" , "Allison Mankin \(E-mail\)" Date: Tue, 14 Aug 2001 17:04:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] First Draft Minutes, SIP WG IETF 51 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Here's my very first rough draft of minutes for SIP WG at IETF 51, based on mine and Tom Taylor's notes. Please send suggestions for corrections. Note that minutes and notes are being accumulated at: http://www.softarmor.com/sipwg/meets/ietf51/minutes/ -- Dean ---------------- Minutes prepared by Dean Willis, based mostly on notes by Tom Taylor, without whom we would cease to report. SIP Working Group met at IETF 51 for two long sessions, a total of 5 hours of meeting time. The revised was completed, with the exception that several of the Rosenberg drafts listed in conjunction with alternative views were not discussed in detail. Instead, Jonathan addressed only the significant differences between his approach and the alternative presented. We also scheduled three adhoc after-hours sessions: 1) Security, 2) Privacy and Outbound Services from Non-Adjacent Proxies, and 3) Firewall Traversal. A fourth adhoc on call Control was proposed by Rohan Mahy, but the proposal was withdrawn before the meeting. Slides are posted at: http://www.softarmor.com/sipwg/meets/ietf51/slides/ Work Plan status ----------------- Approximately half of the extant SIP drafts have been tentatively moved to SIPPING. The managed Last Call process is now starting to flow, and it looks like we'll be able to work through the backlog. We have a near-term requirement to reset several milestones, which will be executed on-list. REFER Method ----------------- This is part of the "call control" work, which addresses call transfers and thrid-part all control. The existing draft draft-ietf-sip-refer-00.txt was recently split off from the "transfer" draft. Open issues: 1) The "referred by" information is similar to the Remote-Party-ID of the Privacy work. Can these two share a general mechanism? 2) The draft defines a crude integrity mechanism for referred-by, but this should use a general-purpose header integrity mechanism. Consensus to advance draft by deleting integrity mechanism and referring to SIP Security work. 3) The MIME-type of the REFER body remains unresolved, and a number of security questions were raised with various proposals. Replaces Header ----------------- This header indicates which call leg the call leg mentioned in a REFER is to replace. This work is fairly mature, and no issues were raised. SIP Events ----------- Issues with authentication, 1) DoS attacks, and amplification, 2) Forking, 3) Record-Route, 4) Expires, 5) event package names, and 6) Call-leg correlation, 7) partial-vs-full state transmission were raised. 1 ) DoS/Amplification: Each SUBSCRIBE produces one response and one notification, which could make a 2-to-1 amplifiier. Consensus to define general "anonymous" authentication mechanism in bis. 2) Forking: No technical problems preclude support for forking of SUBSCRIBE if forking of INVITES is supported. 3) Record-Route: current draft's wording seems ambiguos and has resulted in variant interpretations. Consensus to clarify in revised draft. 4) Expires: Current draft overloads Expires header in NOTIFY to indicate when subscription will expire. This is an overload of header. There is a proposal to use a new header, Subscription-Expires, which may offeer semantic advnatge in subscription migration. Weak consensus for propsal. 5) Event Package Names: Debate is to whether to allow private event package names. Consenus seems to be to establish IANA registry on a first-served basis, no RFC or expert review. 6) Call-Leg Correlation: Question is how to correlate a NOTIFY -- is it with a "call" or a "call leg". This is mostly an issue on whether or not SUBSCRIPTIONS are initated within an extsing call leg. Current draft correlates with a call leg, but this may not solve all cases. Conensus to examine removing prohibition on mapping between notification and specific call as to whether this affects existing implementation semantics. 7) Partial vs. Full State transmission: Most interpretations of existing work seem to indicate that NOTIFYs will contain full states (SHOULD). State deltas may be important for many applications, but are problemactic in constructing full state because of possible missed messages. Consensus to consider body versioning techniques for state deltas. Early Media ------------- Many open issues, primarily with telephony interworking and QoS. Fundamental architecture issue is that early media is "forced" not "offered", and as a consequence we have no effective negotiation mechanism. This all seems to derive from need to map PSTN behavior exactly, and can be resolved if different user interface is allowed. There will be a lot more discussion on this topic. NAT Friendliness ------------------ Current proposal includes several techniques for symmetric and semisymmetric NATS, including new SIP Translate header with semantics of "I don't know where I am, please use the address and port this came from". Consensus to split into at least two drafts, including Translate header (question: do we need a charter adjustment or new milestone declared here?) and seperate "NAT detection protocol for RTP" to be pursued outside SIP. SIP SRC Indication ------------------- Propsal to include source IP address in port in SDP describing sesion, and to expicitly differentiate RTCP port information. This would allow building SIP ALGs and firewalls much more easily (esp. "line" as opposed to "cone" binding devices), as much less information would have to be deduced. It also reduces the opportunity for RTP port spamming, as attacker would have to know source IP and port as well as SSRC. However, it poses complications for current simple-NAT proposals. There will be further discussion of this topic. Extended HTTP-type-Authentication ------------------------------------- Discussion included drafts from Rosenberg and Undery. The basic idea is finding ways to get more mileage, such as mesage integrity protection, out of digest autnetication techniques already specified in SIP. This has all sorts of open isses. Furtehr discussion moved to Security ad-hoc and to mailing list, with no clear consensus reached in the meeting. Proxy-Supported Negotation ------------------------------ Idea is to determine whether at least one proxy in signaling path supports a specific feature. Existing negotiation technique can detect if ALL proxies in path support a feature. There has been ongoing list debate as to whether this is needed. Consensus reached in meeting that no requirement for this behavior, such as a specific application, has been identified and that work on the approach can be deferred until such time as a requirement has been identified. Reliability of Provisional Messages ----------------------------------- Alternative mechanism to 100Rel proposed. List discussions had been inconclusive. Consensus from meeting that proposed alternative offers no significant advantage in general case. Session Timer -------------- Two open isses: 1) New draft allows lower-bounding on sesssion-timer. Current proposal is to overload session-expires, with suggestion to establish new error code like 422-Minimum-Session-Expires. Consenus on proposal for new error code. 2) Absolute vs. relative timers. Consensus to deprecate absolute timers. SIPbis Open Issues -------------------- A bug tracking system is being used to track the large number of open issues in the bis draft. The meeting discussed several issues and attempted to get consensus for various propsed resolutions. 1) Issue 7: Allow CANCEL for non-INVITE methods. Current spec has muliple interpretations. Weak consensus to clarify indicating use of CANCEL only with INVITE. 2) Issue 10: Use of maddr: If client sends INVITE using maddr paremeter from route, should it strip the maddr off of the generated request URI? Consensus is yes, as documented in rfc2453-bis-03. 3) Issue 11: Record-routing for mid-call methods other than INVITE. This is intertwingled with Issue 138. Conensus is to allow mid-call record record-route on a case by case basis. 4) Issue 138: Forking of non-INVITE requests: Consensus to allow forking for non-INVITE methods on a case-by-case basis. 5) Issue 20: Mixing unicast & multicast in offer/answer . If offer SDP contains uni, can response contain multi? Proposal: general rule: answer should be something offeror can do. Hence don't send multicast in respons to unicats. If required, re-INVITE. Conensus to acdept proposal and add scenario to conferencing models draft. 6) Issue 23: dynamic PT reuse. SDP usage in 2543 says you can't reuse a dynamic PT number used previously for a different codec type. This limits number of codecs in a call to 127. It should be possible to reuse a PT once the transaction in which it was used has been completed. Consensus that this is not yet an issue for SIP and therefore there is no need to change. 7) Issue 146: Reuse disabled streams. SDP usage spec says once you have disabled a stream by setting port = 0that hat stream cannot be reused. This is important to maintain exlpicit ordering of codecs, but means the SDP size keeps increasing in on-off hold operations. Proposal: cannot remove disabled stream But if new one added, can take disabled stream's slot within SDP. No restriction on media type. This preserves ordering without increasing size of SDP. FID discussed as possible solution, but this doesn't seem to work completely. Further discussion is required. 8) Issue 58: Rejected mid-call SDP in 2xx: Question is what to "fall back to". Proposal to use general approach of using some signalling means to say that previous session description should be rtetained. Jonathan will consider in revised draft. 9) Issue 133: on-hold indication: Current SDP usage for on-hold is to set address/port number of all 0. This turns out to break RTCP, is IPv4 specific, and is generally ugly. Proposal to use a=inactive for non-sending codecs and a=sendonly for sending codecs, and preserve backward compatibility by accepting but not sending all-zeroes. This may have implications for QoS, and requires further analysis. SIP Security Work Plan ------------------------ We are beginning to see common themes in security questons that suggest a possible path for generalization. Proposal to seperate discussion of "outside" vs. "inside" attacks and advance independently. This would include basic "outside" defenses like IPSec and TLS in rfc2543bis. The HTTP-derived authentiation mechanisms would be reqtined in bis, and all other security considerations seperated. Individual extensions would be constrained from proposing cryptosolutions pending general solutions. Work Program: Develop Threats and Requirments draft. Finalize base requirments in bis and feeze. Define framework for popular auth mechnisms and focus on simple scheme provising UA-Proxy and Proxy-Proxy protections aliged with SRTP and SDP work. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 14 18:54:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16618 for ; Tue, 14 Aug 2001 18:54:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08622; Tue, 14 Aug 2001 18:41:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08591 for ; Tue, 14 Aug 2001 18:41:07 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16405 for ; Tue, 14 Aug 2001 18:39:55 -0400 (EDT) Received: from plate (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f7EMfnJ03421 for ; Tue, 14 Aug 2001 17:41:49 -0500 Message-ID: <026601c12512$4b1b3d80$ad036e3f@dfw.dynamicsoft.com> From: "Dean Willis" To: "IETF SIP" Date: Tue, 14 Aug 2001 17:41:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [Sip] Slides, Notes, Minutes and Stuff for IETF51 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I've started posting slides and stuff for SIP WG at IETF51 at: http://www.softarmor.com/sipwg/meets/ietf51 If you presented slides at the meeting, please make sure your slides are posted. If they aren't either send them to me or remind me that you've already sent them and that I should get offf my Aeron and post them. If you have notes, like for the ad-hoc meetings, please send those too . . . -- Dean _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 15 03:11:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10321 for ; Wed, 15 Aug 2001 03:11:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26494; Wed, 15 Aug 2001 02:48:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA26465 for ; Wed, 15 Aug 2001 02:48:46 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10165 for ; Wed, 15 Aug 2001 02:47:31 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7F6mhO22577; Wed, 15 Aug 2001 08:48:43 +0200 (MEST) Received: from e0000865d41e2 (eplpc6014.epl.ericsson.se [150.132.176.14]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with SMTP id IAA00259; Wed, 15 Aug 2001 08:48:41 +0200 (MET DST) Reply-To: From: "Hans Hannu" To: , Cc: , Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIP compression Date: Wed, 15 Aug 2001 08:48:44 +0200 Message-ID: <006a01c12556$543a5a10$0eb08496@e0000865d41e2.epl.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I'm currently doing some work on the requirements document to fit the comments that I received from the list before the London meeting. But I'll wait for the meeting minutes to see if there is a need for additional changes. /Hans H > Hi, > > I wasn't present during the ROHC WG meeting, so I don't > know if this is a moot question already. But what happened > to the requirements? Specifically, is this going to be a > generic protocol or SIP-only? > > (I guess this will be clarified in the new WG charter > as well as in the meeting minute.) > > BR, > Zhigang > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 15 05:43:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11428 for ; Wed, 15 Aug 2001 05:43:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00275; Wed, 15 Aug 2001 05:30:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA00226 for ; Wed, 15 Aug 2001 05:30:12 -0400 (EDT) Received: from purple.east.isi.edu (purple.cs.ucl.ac.uk [128.16.64.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11293 for ; Wed, 15 Aug 2001 05:28:58 -0400 (EDT) Received: from purple (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.9.3) with ESMTP id FAA02381; Wed, 15 Aug 2001 05:30:24 -0400 Message-Id: <200108150930.FAA02381@purple.east.isi.edu> To: Gonzalo Camarillo cc: Jonathan Rosenberg , sip@ietf.org, mmusic Subject: Re: [Sip] Re: SDP hold In-Reply-To: Your message of "Wed, 15 Aug 2001 00:14:54 +0300." <3B7994CE.E23C1704@lmf.ericsson.se> Date: Wed, 15 Aug 2001 10:30:23 +0100 From: Colin Perkins Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I've made the change to my working copy, and will try to submit a revision in the next couple of weeks (there are a few other changes in progress). Colin --> Gonzalo Camarillo writes: > >Hello Colin, > >Colin Perkins wrote: >> >OK, we can call the "on hold" scenario I just described as a >> >"temporarily disabled media" (the latter is probably more accurate). >> >Anyway, we still need the new tag. I do not really care if we call it >> >neithersendnorrecv, nomedia or inactive. However, as Christer suggested, >> >in order to be consistent with other protocols we can use "inactive". >> > >> >Anyway, my question is: Colin, do you think that such a tag should be >> >included in SDPnew? Otherwise we can write a half-page draft defining >> >this attribute. >> >> I don't see the need for a new draft, so if there's consensus on this, send >> me some suggested wording. >> > >In page 25 of: >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-03.txt > >we have to add the following attribute: > >a=inactive > This specifies that the tools should be started in inactive > mode. This is necessary for interactive conferences where users can >put other users on hold. No media is sent over an inactive media stream. >It can be either a session or media attribute, and is not dependent on >charset. > > >When you make the change let us know, since RFC2543bis will have to be >updated as well. > >Best regards, > >Gonzalo > > >> Colin > >-- >Gonzalo Camarillo Phone : +1 212 939 71 71 >Columbia University Mobile: +358 40 702 35 35 >472 Computer Science Building Fax : +358 9 299 30 52 >1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo >New York, NY 10027 >USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 15 17:38:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01695 for ; Wed, 15 Aug 2001 17:38:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19048; Wed, 15 Aug 2001 17:19:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19020 for ; Wed, 15 Aug 2001 17:19:09 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01350 for ; Wed, 15 Aug 2001 17:17:56 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA29071 for ; Wed, 15 Aug 2001 16:18:32 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 15 Aug 2001 16:18:05 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 Aug 2001 16:17:32 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E43031E26AD@crchy271.us.nortel.com> From: "Brian Stucker" To: "Price, Richard" , "'Hans.Hannu@epl.ericsson.se'" Cc: sip@ietf.org, rohc@cdt.luth.se Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIP compress ion Date: Wed, 15 Aug 2001 16:17:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C125CF.AFE3E290" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C125CF.AFE3E290 Content-Type: text/plain; charset="iso-8859-1" Well, except that you've got an installed base of parsers that only understand the text encoding for SIP. Brian -----Original Message----- From: Price, Richard [mailto:richard.price@roke.co.uk] Sent: Tuesday, August 14, 2001 11:00 AM To: 'Hans.Hannu@epl.ericsson.se' Cc: sip@ietf.org; rohc@cdt.luth.se Subject: [Sip] RE: [rohc] Reduced processing overhead for SIP compression Hi, Yes, this is still compression because the output of a combined SIP stack/SIP compressor is identical to the output of a standalone compressor. Key difference between this and making SIP binary is that the Huffman binary codes are made up by the compressor and do not need to be standardized by the SIP WG: thus we avoid all of the problems synchronizing between the text and binary encodings for SIP. Regards, Richard P -----Original Message----- From: Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] Sent: Tuesday, August 14, 2001 3:38 PM To: Price, Richard; sip@ietf.org; rohc@cdt.luth.se Cc: 'Jonathan Rosenberg' Subject: RE: [rohc] Reduced processing overhead for SIP compression > A "SIP-aware" compression algorithm such as EPIC performs the > compression by parsing a SIP message, converting text strings > to their Huffman equivalents. If we are performing compression > in the mobile and the SIP proxy then we can miss out the text > phase altogether, writing a SIP stack capable of reading and > outputting Huffman characters directly. Is this really compression anymore? To be it sounds like making SIP binary. /Hans H > > Motivation for combining the SIP compressor with the SIP stack > is that the processing overhead of compression is negligible, > or perhaps even negative (as Huffman characters are shorter > than their text equivalents, so there is less to read/output). > > Comments on this suggestion would be appreciated, particularly > to check that it fits with the "protocol shim" for carrying > compressed SIP messages as proposed by Jonathan Rosenberg. > > Regards, > > Richard P > > -------------------------------------------------------------- > ----------- > Richard Price > Internet Applications & Mobility > Roke Manor Research Ltd. > Old Salisbury Lane > Romsey, Hants > SO51 0ZN, UK. > Telephone: +44 1794 833681 > E-mail: richard.price@roke.co.uk > -------------------------------------------------------------- > ----------- > ------_=_NextPart_001_01C125CF.AFE3E290 Content-Type: text/html; charset="iso-8859-1" RE: [Sip] RE: [rohc] Reduced processing overhead for SIP compression

Well, except that you've got an installed base of parsers that only understand the
text encoding for SIP.

Brian

-----Original Message-----
From: Price, Richard [mailto:richard.price@roke.co.uk]
Sent: Tuesday, August 14, 2001 11:00 AM
To: 'Hans.Hannu@epl.ericsson.se'
Cc: sip@ietf.org; rohc@cdt.luth.se
Subject: [Sip] RE: [rohc] Reduced processing overhead for SIP
compression


Hi,

Yes, this is still compression because the output of a combined SIP
stack/SIP compressor is identical to the output of a standalone
compressor. Key difference between this and making SIP binary is that
the Huffman binary codes are made up by the compressor and do not
need to be standardized by the SIP WG: thus we avoid all of the
problems synchronizing between the text and binary encodings for SIP.

Regards,

Richard P

-----Original Message-----
From: Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se]
Sent: Tuesday, August 14, 2001 3:38 PM
To: Price, Richard; sip@ietf.org; rohc@cdt.luth.se
Cc: 'Jonathan Rosenberg'
Subject: RE: [rohc] Reduced processing overhead for SIP compression


 
> A "SIP-aware" compression algorithm such as EPIC performs the
> compression by parsing a SIP message, converting text strings
> to their Huffman equivalents. If we are performing compression
> in the mobile and the SIP proxy then we can miss out the text
> phase altogether, writing a SIP stack capable of reading and
> outputting Huffman characters directly.

Is this really compression anymore? To be it sounds like making SIP binary.

/Hans H


>
> Motivation for combining the SIP compressor with the SIP stack
> is that the processing overhead of compression is negligible,
> or perhaps even negative (as Huffman characters are shorter
> than their text equivalents, so there is less to read/output).
>
> Comments on this suggestion would be appreciated, particularly
> to check that it fits with the "protocol shim" for carrying
> compressed SIP messages as proposed by Jonathan Rosenberg.
>
> Regards,
>
> Richard P
>
> --------------------------------------------------------------
> -----------
> Richard Price
> Internet Applications & Mobility
> Roke Manor Research Ltd.
> Old Salisbury Lane
> Romsey, Hants
> SO51 0ZN, UK.
> Telephone: +44 1794 833681
> E-mail: richard.price@roke.co.uk
> --------------------------------------------------------------
> -----------
>

------_=_NextPart_001_01C125CF.AFE3E290-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 16 06:55:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27773 for ; Thu, 16 Aug 2001 06:54:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14310; Thu, 16 Aug 2001 06:27:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14281 for ; Thu, 16 Aug 2001 06:26:59 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27346 for ; Thu, 16 Aug 2001 06:25:47 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 11:26:46 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9E13@RSYS002A> From: "Price, Richard" To: "'Brian Stucker'" , "'Hans.Hannu@epl.ericsson.se'" Cc: sip@ietf.org, rohc@cdt.luth.se Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIP compress ion Date: Thu, 16 Aug 2001 11:26:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, If a combined SIP stack/SIP compressor cannot be used for whatever reason, then feel free to implement a standalone SIP compressor instead. The output of the compressor is identical in both cases. Regards, Richard P -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Wednesday, August 15, 2001 10:17 PM To: Price, Richard; 'Hans.Hannu@epl.ericsson.se' Cc: sip@ietf.org; rohc@cdt.luth.se Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIP compress ion Well, except that you've got an installed base of parsers that only understand the text encoding for SIP. Brian -----Original Message----- From: Price, Richard [mailto:richard.price@roke.co.uk] Sent: Tuesday, August 14, 2001 11:00 AM To: 'Hans.Hannu@epl.ericsson.se' Cc: sip@ietf.org; rohc@cdt.luth.se Subject: [Sip] RE: [rohc] Reduced processing overhead for SIP compression Hi, Yes, this is still compression because the output of a combined SIP stack/SIP compressor is identical to the output of a standalone compressor. Key difference between this and making SIP binary is that the Huffman binary codes are made up by the compressor and do not need to be standardized by the SIP WG: thus we avoid all of the problems synchronizing between the text and binary encodings for SIP. Regards, Richard P -----Original Message----- From: Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] Sent: Tuesday, August 14, 2001 3:38 PM To: Price, Richard; sip@ietf.org; rohc@cdt.luth.se Cc: 'Jonathan Rosenberg' Subject: RE: [rohc] Reduced processing overhead for SIP compression > A "SIP-aware" compression algorithm such as EPIC performs the > compression by parsing a SIP message, converting text strings > to their Huffman equivalents. If we are performing compression > in the mobile and the SIP proxy then we can miss out the text > phase altogether, writing a SIP stack capable of reading and > outputting Huffman characters directly. Is this really compression anymore? To be it sounds like making SIP binary. /Hans H > > Motivation for combining the SIP compressor with the SIP stack > is that the processing overhead of compression is negligible, > or perhaps even negative (as Huffman characters are shorter > than their text equivalents, so there is less to read/output). > > Comments on this suggestion would be appreciated, particularly > to check that it fits with the "protocol shim" for carrying > compressed SIP messages as proposed by Jonathan Rosenberg. > > Regards, > > Richard P > > -------------------------------------------------------------- > ----------- > Richard Price > Internet Applications & Mobility > Roke Manor Research Ltd. > Old Salisbury Lane > Romsey, Hants > SO51 0ZN, UK. > Telephone: +44 1794 833681 > E-mail: richard.price@roke.co.uk > -------------------------------------------------------------- > ----------- > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 16 07:24:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28808 for ; Thu, 16 Aug 2001 07:24:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15353; Thu, 16 Aug 2001 07:04:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15321 for ; Thu, 16 Aug 2001 07:04:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28263; Thu, 16 Aug 2001 07:02:48 -0400 (EDT) Message-Id: <200108161102.HAA28263@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 16 Aug 2001 07:02:48 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-sctp-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SCTP as a Transport for SIP Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo Filename : draft-ietf-sip-sctp-00.txt Pages : 8 Date : 15-Aug-01 This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport between SIP entities. SCTP is a new protocol which provides several features that may prove beneficial for transport between SIP entities which exchange a large amount of messages, including gateways and proxies. As SIP is transport independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sctp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-sctp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-sctp-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: <20010815145318.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sctp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sctp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010815145318.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 16 10:27:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09074 for ; Thu, 16 Aug 2001 10:27:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18573; Thu, 16 Aug 2001 09:57:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18546 for ; Thu, 16 Aug 2001 09:57:49 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07225 for ; Thu, 16 Aug 2001 09:56:35 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7GDvlE29924 for ; Thu, 16 Aug 2001 09:57:47 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Aug 2001 14:57:41 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB002A956F3@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: "'sip@ietf.org'" Date: Thu, 16 Aug 2001 14:57:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Question about SIP bis04 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Could someone please explain to me: 15.4 If a UAS never receives an ACK for a 2xx response to a re-INVITE, it SHOULD generate a re-INVITE itself in order to synchronize the state of the session. What does this description mean? If UAS needs a ACK, why it has to generate a re-INVITE? Thanks and Regards Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 16 15:29:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20653 for ; Thu, 16 Aug 2001 15:29:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27563; Thu, 16 Aug 2001 15:06:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27536 for ; Thu, 16 Aug 2001 15:06:31 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20090 for ; Thu, 16 Aug 2001 15:05:18 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7GJ6U708326 for ; Thu, 16 Aug 2001 15:06:31 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Aug 2001 20:06:24 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB002A956F4@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: "'Avshalom@ubique.com'" , sip@ietf.org Subject: RE: [Sip] Question about SIP bis04 Date: Thu, 16 Aug 2001 20:06:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I think this is not the reason, because the original re-INVITE is sent by UAC not UAS. Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Avshalom@ubique.com [mailto:Avshalom@ubique.com] Sent: 16 August 2001 19:01 To: sip@ietf.org Subject: Re: [Sip] Question about SIP bis04 I think in order to re-negotiate the session. The 2xx message itself or the ACK could have been lost. Since we can not know what have been lost, the negotiation should start from the beginning. Please correct me if I am wrong. --Avshalom "Chen, Xin (Xin)" To: "'sip@ietf.org'" Subject: [Sip] Question about SIP bis04 Sent by: sip-admin@iet f.org 16/08/2001 16:57 Could someone please explain to me: 15.4 If a UAS never receives an ACK for a 2xx response to a re-INVITE, it SHOULD generate a re-INVITE itself in order to synchronize the state of the session. What does this description mean? If UAS needs a ACK, why it has to generate a re-INVITE? Thanks and Regards Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 16 15:30:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20686 for ; Thu, 16 Aug 2001 15:30:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27492; Thu, 16 Aug 2001 15:03:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27463 for ; Thu, 16 Aug 2001 15:03:05 -0400 (EDT) Received: from ubqgate02.lotus.com (outbound-pat-address.lotus.co.uk [194.196.39.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19951 for ; Thu, 16 Aug 2001 15:01:51 -0400 (EDT) From: Avshalom@ubique.com Subject: Re: [Sip] Question about SIP bis04 To: sip@ietf.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: Date: Thu, 16 Aug 2001 22:01:13 +0300 X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at 16/08/2001 22:01:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I think in order to re-negotiate the session. The 2xx message itself or the ACK could have been lost. Since we can not know what have been lost, the negotiation should start from the beginning. Please correct me if I am wrong. --Avshalom "Chen, Xin (Xin)" To: "'sip@ietf.org'" Subject: [Sip] Question about SIP bis04 Sent by: sip-admin@iet f.org 16/08/2001 16:57 Could someone please explain to me: 15.4 If a UAS never receives an ACK for a 2xx response to a re-INVITE, it SHOULD generate a re-INVITE itself in order to synchronize the state of the session. What does this description mean? If UAS needs a ACK, why it has to generate a re-INVITE? Thanks and Regards Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 16 15:32:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20770 for ; Thu, 16 Aug 2001 15:32:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27611; Thu, 16 Aug 2001 15:06:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27580 for ; Thu, 16 Aug 2001 15:06:50 -0400 (EDT) Received: from mail2.intervoice-brite.com (mail2.intervoice-brite.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20093 for ; Thu, 16 Aug 2001 15:05:36 -0400 (EDT) Received: from 172.16.16.64 (gwsmtpsrv.intervoice.com [172.16.16.64]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with SMTP id OAA02410 for ; Thu, 16 Aug 2001 14:11:09 -0500 Received: from bculpepperpc ([151.214.151.212]) by 172.16.16.64; Thu, 16 Aug 2001 14:06:12 -0500 From: "Bert Culpepper" To: "'Chen, Xin (Xin)'" , Subject: RE: [Sip] Question about SIP bis04 Date: Thu, 16 Aug 2001 15:06:16 -0400 Message-ID: <007b01c12686$87110fc0$d497d697@orlando.brite.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <475FF955A05DD411980D00508B6D5FB002A956F3@en0033exch001u.uk.lucent.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Well, one use of a re-INVITE is to change the media characteristics of an existing session. So if a UAS never gets acknowledgement of its response (times out waiting for the ACK), it can (SHOULD) assume the transaction failed and continue with the media that existed prior to the re-INVITE. But, the other end has already changed presumably to match its re-INVITE and it may have even received the 200 from the UAS in which case it did change its media, leading to a "failed call" situation (UAC using new media and UAS using old media). The text you ask about describes a fall-back procedure for the UAS to "recover" the call. The UAC is not aware of the problem with the UAS receiving its ACK. regards, Bert -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chen, Xin (Xin) Sent: Thursday, August 16, 2001 9:58 AM To: 'sip@ietf.org' Subject: [Sip] Question about SIP bis04 Could someone please explain to me: 15.4 If a UAS never receives an ACK for a 2xx response to a re-INVITE, it SHOULD generate a re-INVITE itself in order to synchronize the state of the session. What does this description mean? If UAS needs a ACK, why it has to generate a re-INVITE? Thanks and Regards Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 16 15:34:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20848 for ; Thu, 16 Aug 2001 15:34:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27706; Thu, 16 Aug 2001 15:11:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27677 for ; Thu, 16 Aug 2001 15:11:23 -0400 (EDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20178 for ; Thu, 16 Aug 2001 15:10:10 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7GJBM111472 for ; Thu, 16 Aug 2001 15:11:22 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Aug 2001 20:11:21 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB002A956F5@en0033exch001u.uk.lucent.com> From: "Chen, Xin (Xin)" To: "'Bert Culpepper'" , "Chen, Xin (Xin)" , sip@ietf.org Subject: RE: [Sip] Question about SIP bis04 Date: Thu, 16 Aug 2001 20:11:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Thanks, I understand your explaination. But why Bis04 says that this is to synchronize the state of the session? Maybe some other reason as well. Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 -----Original Message----- From: Bert Culpepper [mailto:bert.culpepper@intervoice-brite.com] Sent: 16 August 2001 19:06 To: 'Chen, Xin (Xin)'; sip@ietf.org Subject: RE: [Sip] Question about SIP bis04 Well, one use of a re-INVITE is to change the media characteristics of an existing session. So if a UAS never gets acknowledgement of its response (times out waiting for the ACK), it can (SHOULD) assume the transaction failed and continue with the media that existed prior to the re-INVITE. But, the other end has already changed presumably to match its re-INVITE and it may have even received the 200 from the UAS in which case it did change its media, leading to a "failed call" situation (UAC using new media and UAS using old media). The text you ask about describes a fall-back procedure for the UAS to "recover" the call. The UAC is not aware of the problem with the UAS receiving its ACK. regards, Bert -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chen, Xin (Xin) Sent: Thursday, August 16, 2001 9:58 AM To: 'sip@ietf.org' Subject: [Sip] Question about SIP bis04 Could someone please explain to me: 15.4 If a UAS never receives an ACK for a 2xx response to a re-INVITE, it SHOULD generate a re-INVITE itself in order to synchronize the state of the session. What does this description mean? If UAS needs a ACK, why it has to generate a re-INVITE? Thanks and Regards Xin Chen Lucent Technologies Tel: +44 1793 883137 Mobile: +44 7799 034668 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 16 19:37:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27660 for ; Thu, 16 Aug 2001 19:37:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05496; Thu, 16 Aug 2001 19:18:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05468 for ; Thu, 16 Aug 2001 19:18:05 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27374 for ; Thu, 16 Aug 2001 19:16:53 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7GNGorN016635 for ; Thu, 16 Aug 2001 19:16:50 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 19:17:36 -0400 Message-ID: From: Rakesh Shah To: "'SIPWG Mailing List (E-mail)'" Date: Thu, 16 Aug 2001 19:15:47 -0400 Importance: high X-Priority: 1 Deferred-Delivery: Thu, 16 Aug 2001 19:17:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C126A9.6200E980" Subject: [Sip] SIP WG - Last Call Open List Discussion - draft-ietf-sip-callerpr efs-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 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_01C126A9.6200E980 Content-Type: text/plain The subject draft is going through WGLC. The assigned reviewers have or should be posting their initial comments. The Last Call Review on the list will be closed on 6Sep01. Please post your comments to the list. The authors will be collecting this input and addressing issues. After the review is complete, the authors will post a summary. Regards, Rakesh _________________________ Mr. Rakesh C. Shah Project Coordinator dynamicsoft Inc. 72 Eagle Rock Avenue 1st Floor East Hanover, N.J. 07936 (973) 952-5066 direct (201) 214-6084 cell (973) 952-5000 main (973) 952-5050 fax rshah@dynamicsoft.com ------_=_NextPart_001_01C126A9.6200E980 Content-Type: text/html Message
The subject draft is going through WGLC.
 
The assigned reviewers have or should be posting their initial comments.
 
The Last Call Review on the list will be closed on 6Sep01. Please post your comments to the list. The authors will be collecting this input and addressing issues. After the review is complete, the authors will post a summary.

Regards,

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

------_=_NextPart_001_01C126A9.6200E980-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 17 06:11:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22709 for ; Fri, 17 Aug 2001 06:11:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26851; Fri, 17 Aug 2001 05:51:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26793 for ; Fri, 17 Aug 2001 05:51:53 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22518 for ; Fri, 17 Aug 2001 05:50:37 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7H9pkv09506; Fri, 17 Aug 2001 11:51:46 +0200 (MEST) Received: from ericsson.com (E0080C7779971.lmf.ericsson.se [131.160.30.82]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7H9pj523585; Fri, 17 Aug 2001 12:51:45 +0300 (EET DST) Message-ID: <3B7CE930.8D9C3B72@ericsson.com> Date: Fri, 17 Aug 2001 12:51:44 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: sip@ietf.org, jdrosen@dynamicsoft.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] new SDP in RFC 2543bis? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi: I remember that in the MMUSIC meeting in London, Jonathan mentioned that RFC 2543bis depends on the new SDP draft. However, RFC 2543bis-04 references RFC 2327 (classic SDP). Is this going to be fixed in new versions of RFC 2543bis? Or am I missing something? Thanks a lot, Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 17 07:56:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25129 for ; Fri, 17 Aug 2001 07:56:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29114; Fri, 17 Aug 2001 07:26:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29087 for ; Fri, 17 Aug 2001 07:26:43 -0400 (EDT) Received: from cs.tut.fi (root@varis.cs.tut.fi [130.230.4.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24100 for ; Fri, 17 Aug 2001 07:25:28 -0400 (EDT) Received: from rami (root@varis.cs.tut.fi [130.230.4.42]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id OAA28310 for ; Fri, 17 Aug 2001 14:26:40 +0300 (EET DST) From: "Rami Lehtonen" To: Date: Fri, 17 Aug 2001 14:27:27 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] SIP authentication problem? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Does this following behaviour (to encrypt before authenticating) of SIP open up some security holes, because now you can send the encrypted body with valid signature even if you are not the original creator of that content? "Note that if a message is encrypted and authenticated using a digital signature, when the message is generated encryption is performed before the digital signature is generated. On receipt, the digital signature is checked before decryption." Have you thought about this situation? Regards, Rami Lehtonen _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 17 08:13:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26003 for ; Fri, 17 Aug 2001 08:13:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29500; Fri, 17 Aug 2001 07:33:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA29469 for ; Fri, 17 Aug 2001 07:33:19 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24278 for ; Fri, 17 Aug 2001 07:32:04 -0400 (EDT) Received: from mailhost.ubiquity.net by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 17 Aug 2001 11:33:18 UT Received: from ubiquity.net ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Fri, 17 Aug 2001 12:34:02 +0100 Message-ID: <3B7D00D7.9F0FECFD@ubiquity.net> Date: Fri, 17 Aug 2001 12:32:40 +0100 From: James Undery X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Rami Lehtonen CC: sip@ietf.org Subject: Re: [Sip] SIP authentication problem? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Aug 2001 11:34:02.0253 (UTC) FILETIME=[83844BD0:01C12710] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Rami Lehtonen wrote: > Hello, > > Does this following behaviour (to encrypt before authenticating) of SIP open > up some security holes, because now you can send the encrypted body with > valid signature even if you are not the original creator of that content? Sorry I don't quite follow why this is a problem, people often sign things they didn't create, if you don't trust it don't sign it. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 17 08:47:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27438 for ; Fri, 17 Aug 2001 08:47:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00587; Fri, 17 Aug 2001 08:31:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00556 for ; Fri, 17 Aug 2001 08:31:42 -0400 (EDT) Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26868 for ; Fri, 17 Aug 2001 08:30:26 -0400 (EDT) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA29065 for ; Fri, 17 Aug 2001 14:29:16 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA01213 for ; Fri, 17 Aug 2001 14:29:06 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 14:28:59 +0200 Message-ID: <5316E8083EC4D411957F0008C71EEE3473A9D2@MCHH227E> From: Euchner Martin To: "'Rami Lehtonen'" , James Undery Cc: sip@ietf.org Subject: AW: [Sip] SIP authentication problem? Date: Fri, 17 Aug 2001 14:28:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA00557 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit digital signatures are not an appropriate security means to prove ownership of content. But that particular problem is definitely not a SIP security issue. Kind Regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Rami Lehtonen [SMTP:rampe@cs.tut.fi] Gesendet am: Freitag, 17. August 2001 14:03 An: James Undery Cc: sip@ietf.org Betreff: RE: [Sip] SIP authentication problem? > Rami Lehtonen wrote: > > > Hello, > > > > Does this following behaviour (to encrypt before > authenticating) of SIP open > > up some security holes, because now you can send the encrypted body with > > valid signature even if you are not the original creator of > that content? > > Sorry I don't quite follow why this is a problem, people often > sign things they > didn't create, if you don't trust it don't sign it. That might be the problem, because now we don't know who actually created the content. It might be a problem also in case where the body contains some sensitive information like the following example: If there is e.g. a pre-paid ticket for some service in the body part, C could capture that message sent originally by A, remove the signature and include C's own signature and then send the message to B. Now B thinks that C originally paid money for the service, because there is C's signature and the content is encrypted using the B's public key as it should be. Anyway this was just a thought. I was just curious to hear if somebody has considered this as an authentication problem or not. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 17 09:10:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28833 for ; Fri, 17 Aug 2001 09:10:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00071; Fri, 17 Aug 2001 08:02:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00040 for ; Fri, 17 Aug 2001 08:02:21 -0400 (EDT) Received: from cs.tut.fi (root@varis.cs.tut.fi [130.230.4.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25454 for ; Fri, 17 Aug 2001 08:01:05 -0400 (EDT) Received: from rami (root@varis.cs.tut.fi [130.230.4.42]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id PAA01125; Fri, 17 Aug 2001 15:02:16 +0300 (EET DST) From: "Rami Lehtonen" To: "James Undery" Cc: Subject: RE: [Sip] SIP authentication problem? Date: Fri, 17 Aug 2001 15:03:03 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <3B7D00D7.9F0FECFD@ubiquity.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Rami Lehtonen wrote: > > > Hello, > > > > Does this following behaviour (to encrypt before > authenticating) of SIP open > > up some security holes, because now you can send the encrypted body with > > valid signature even if you are not the original creator of > that content? > > Sorry I don't quite follow why this is a problem, people often > sign things they > didn't create, if you don't trust it don't sign it. That might be the problem, because now we don't know who actually created the content. It might be a problem also in case where the body contains some sensitive information like the following example: If there is e.g. a pre-paid ticket for some service in the body part, C could capture that message sent originally by A, remove the signature and include C's own signature and then send the message to B. Now B thinks that C originally paid money for the service, because there is C's signature and the content is encrypted using the B's public key as it should be. Anyway this was just a thought. I was just curious to hear if somebody has considered this as an authentication problem or not. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 17 12:11:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06875 for ; Fri, 17 Aug 2001 12:11:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07710; Fri, 17 Aug 2001 11:58:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07679 for ; Fri, 17 Aug 2001 11:58:26 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06229 for ; Fri, 17 Aug 2001 11:57:10 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 16:58:24 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9E1E@RSYS002A> From: "Price, Richard" To: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Cc: "'Jonathan Rosenberg'" Date: Fri, 17 Aug 2001 16:58:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Sip] Encapsulating EPIC in UDPComp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, Attached is a (rather detailed) posting on the overhead of encapsulating EPIC within UDPComp. The conclusion is that by adding Huffman codes to UDPComp, the protocol overhead can be made very low (just 5 bytes per message). Comments are welcome! Richard P -------------------------------------------------------------------- This is a follow-up to my earlier posting on the performance of various signaling compression algorithms. I mentioned that one of the ideas of UDPComp is to make the compression algorithm a local implementation decision at the compressor: this makes the protocol very lightweight and flexible, but potentially reduces the compression efficiency due to transmitting the semantics of the compression algorithm in each packet. As promised, here are some performance figures to illustrate this overhead. We tested the EPIC algorithm encapsulated in UDPComp using the "Simple SIP to SIP" flow from . We assume that the compressor and decompressor each contain a static dictionary of text strings commonly used in SIP. This can be "learnt" by compressing sufficient SIP messages, or alternatively can be fixed a-priori. We also use a dynamic dictionary (i.e. compress relative to previous messages in the flow). Note that UDPComp offers significant flexibility in the choice of "token" used to transmit text strings from the compressor to the decompressor. Currently the scheme sends a fixed 1-2 byte index to reference each text string, but additional tokens can easily be added (for example tokens that use Huffman codes to reference text strings). We have provided a range of performance figures using different types of token to transmit the data. For comparison, the compression ratio using only the existing UDPComp tokens is given below: EPIC algorithm with no encapsulation: 9.78 UDPComp using existing tokens only: 1.17 The decrease in compression ratio is caused by sending a 1-2 byte index to reference each text string. In contrast, the EPIC algorithm usually references a text string by sending a short Huffman code (typically 1 - 4 bits). To improve the compression ratio it is possible to add Huffman codes to UDPComp. In general this is straightforward: the only potential problem is that the Huffman codes are chosen specifically for EPIC, and different variants of Lempel-Ziv may need a different set of Huffman codes. Thus, it may be necessary to download new sets of Huffman codes to the decompressor depending on the choice of algorithm. Adding Huffman codes to UDPComp can be done in several ways. Firstly we have a choice between EPIC-LITE (which uses ordinary Huffman codes) and EPIC (which uses a special version of Huffman encoding capable of compressing text strings down to less than one bit - for example 3 common text strings in a row might together be indicated by sending a single "0" bit). Secondly, we have a choice between selecting a global set of Huffman codes for all text strings, and using a different set for each dictionary entry. In the latter case the Huffman code for each text string actually changes depending on the previously received string. This improves the compression ratio at a cost of higher memory requirements (which may be a problem if we have to store the Huffman codes in working memory). Compression ratios for each choice are given below: UDPComp using EPIC-LITE with global Huffman codes: 5.90 UDPComp using EPIC-LITE with local Huffman codes: 6.29 UDPComp using EPIC with global Huffman codes: 6.85 UDPComp using EPIC with local Huffman codes: 8.24 Initial results are promising: if required we can make the overhead of encapsulating EPIC within UDPComp negligible (essentially it is just the 5 bytes of initial UDPComp header per message). I believe the next step should be to check how other compression algorithms fit into the UDPComp framework, and to decide on a "sweet spot" between compression efficiency and standardizing the protocol in the given timeframe. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 17 18:53:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16680 for ; Fri, 17 Aug 2001 18:53:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20082; Fri, 17 Aug 2001 18:47:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20051 for ; Fri, 17 Aug 2001 18:47:28 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16534 for ; Fri, 17 Aug 2001 18:45:59 -0400 (EDT) From: zhigang.c.liu@nokia.com Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7HMlIi00555 for ; Fri, 17 Aug 2001 17:47:18 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Aug 2001 17:47:13 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 17 Aug 2001 17:47:13 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] Encapsulating EPIC in UDPComp Date: Fri, 17 Aug 2001 17:47:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] Encapsulating EPIC in UDPComp X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEnNbdcJ7ncFpMkEdWxLgAIx6TWeAAN9ktw To: , , Cc: X-OriginalArrivalTime: 17 Aug 2001 22:47:13.0747 (UTC) FILETIME=[8EB92A30:01C1276E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA20055 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > For comparison, the compression ratio using only the existing UDPComp > tokens is given below: > > EPIC algorithm with no encapsulation: 9.78 > > UDPComp using existing tokens only: 1.17 Richard, I'm a bit puzzled by the numbers. According to your own data sent earlier (http://www.cdt.luth.se/robhc/msg02428.html), even a generic LZSS can achieve a compression ratio of 9.87 with a combined dictionary. What is the point here? BR, Zhigang _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 17 19:35:44 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17142 for ; Fri, 17 Aug 2001 19:35:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20934; Fri, 17 Aug 2001 19:22:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA20874 for ; Fri, 17 Aug 2001 19:22:50 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16994 for ; Fri, 17 Aug 2001 19:18:26 -0400 (EDT) From: khiem.le@nokia.com Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7HNJhi01965 for ; Fri, 17 Aug 2001 18:19:43 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 17 Aug 2001 18:19:39 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 17 Aug 2001 18:19:39 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIP compression Date: Fri, 17 Aug 2001 18:19:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] RE: [rohc] Reduced processing overhead for SIP compression X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcElVz/Uaf1uKZFIEdWBSQBQi2X+DwCGfbIQ To: , , Cc: , X-OriginalArrivalTime: 17 Aug 2001 23:19:39.0006 (UTC) FILETIME=[163021E0:01C12773] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA20877 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Hans, Since the SIP Call set up latency is one of the main (if not the main) problem we want to solve with signaling compression, I propose we add a requirement to that effect: The compression scheme MUST be such that when applied to SIP, the call set up latency is less than X seconds, for a representative set of scenarios to be defined. Scenarios specify the messages exchanged, their contents, as well as the channel bit rates. We need to agree on X and the scenarios, but I believe this requirement is useful, because compression ratio alone does not adequately capture the problem of call set up latency. Scenarios can be based on those typically envisioned in cellular cases like 3GPP. Khiem -----Original Message----- From: ext Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] Sent: 15 August, 2001 1:49 AM To: Liu Zhigang.C (NRC/Dallas); richard.price@roke.co.uk Cc: sip@ietf.org; rohc@cdt.luth.se Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIP compression Hi, I'm currently doing some work on the requirements document to fit the comments that I received from the list before the London meeting. But I'll wait for the meeting minutes to see if there is a need for additional changes. /Hans H > Hi, > > I wasn't present during the ROHC WG meeting, so I don't > know if this is a moot question already. But what happened > to the requirements? Specifically, is this going to be a > generic protocol or SIP-only? > > (I guess this will be clarified in the new WG charter > as well as in the meeting minute.) > > BR, > Zhigang > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > --- Mailing list for Robust Header Compression WG Archive: http://www.cdt.luth.se/rohc/ _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Aug 18 08:42:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11666 for ; Sat, 18 Aug 2001 08:41:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14592; Sat, 18 Aug 2001 08:13:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14561 for ; Sat, 18 Aug 2001 08:13:04 -0400 (EDT) Received: from cundall.co.uk ([193.118.202.13]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11274 for ; Sat, 18 Aug 2001 08:11:48 -0400 (EDT) Received: from [193.118.192.41] ([193.118.192.41] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000055736; Sat, 18 Aug 2001 13:13:59 +0100 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: References: Date: Sat, 18 Aug 2001 13:12:52 +0100 To: sip@ietf.org, rohc@cdt.luth.se From: Lawrence Conroy Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIP compression Cc: richard.price@roke.co.uk, Hans.Hannu@epl.ericsson.se, zhigang.c.liu@nokia.com, khiem.le@nokia.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org >Hi Hans, > >Since the SIP Call set up latency is one of the main (if not the main) >problem we want to solve with signaling compression, I propose we add a >requirement to that effect: > >The compression scheme MUST be such that when applied to SIP, the call >set up latency is less than X seconds, for a representative set of >scenarios to be defined. Scenarios specify the messages exchanged, their >contents, as well as the channel bit rates. > >We need to agree on X and the scenarios, but I believe this requirement >is useful, because compression ratio alone does not adequately capture >the problem of call set up latency. Scenarios can be based on those >typically envisioned in cellular cases like 3GPP. > >Khiem > To which I reply: Hi Folks, There is a GERAN meeting at the end of the month, and I will canvas to see if there is a HARD limit such as that proposed as a requirement. However... I think that the assumption that the main goal of SIP Comp is to reduce (or, as described above, =>LIMIT<= ) the call set up time is not obvious (to me, at least) and I'm not yet happy to have it included in the requirements document as proposed. For GERAN at least, the HARD requirement is on the mid-call Re-Invite sequence, NOT on the call set up. That's probably true for UTRAN as well, but that's not my area of interest. I have already sent a posting on my understanding of the GERAN mid-call problem and the figures that seem to apply there (and the reasons). Of course one benefit of SIP Comp is that we reduce the transmission time for messages sent during call set up for latency reasons, and so we may avoid too many re-transmissions of SIP messages. However, I don't see how this is a HARD requirement and would be interested in understanding the logic here. Do we have a specific limit (like the DCS one that is, I believe, regulated by the FCC)? BR, L. -- lwc@roke.co.uk: +44 1794 833666::: _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Aug 18 20:29:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16767 for ; Sat, 18 Aug 2001 20:29:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27621; Sat, 18 Aug 2001 20:07:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA23934 for ; Thu, 16 Aug 2001 12:43:33 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15508; Thu, 16 Aug 2001 12:42:21 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA18389; Thu, 16 Aug 2001 09:43:29 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA04809; Thu, 16 Aug 2001 09:43:28 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 16 Aug 2001 11:43:28 -0500 Message-ID: <796456A0F96AD511A0AC009027B0F741130E9C@IL27EXM08.cig.mot.com> From: Ziyad Nigel-NZIYAD1 To: sipping@ietf.org, sip@ietf.org, tsvwg@ietf.org, avt@ietf.org Date: Thu, 16 Aug 2001 11:43:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C12672.8CF97350" Subject: [Sip] Lost bag in London Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C12672.8CF97350 Content-Type: text/plain; charset="iso-8859-1" Please help. I was at the IETF meeting in London and I am missing a blue zippered bag containing a USB cable as in the picture attached. Contents also included a Motorola 2-way pager. I had it on the night of Thursday August 9 at 12 midnight between the computer room and the 4th floor telephones. My name and address are on the inside of the bag. If found please return to the address below. Thank you. Dr. Nigel A. Ziyad Motorola 1501 W. Shure Dr. MS-IL27/2D5 Arlington Heights, IL 60004 Phone: 847-632-2098 Fax: 847-632-7912 Pager (2-way): 888-478-0351 or 4780351@skytel.com ------_=_NextPart_000_01C12672.8CF97350 Content-Type: image/gif; name="missingbag.gif" Content-Disposition: attachment; filename="missingbag.gif" Content-Transfer-Encoding: base64 R0lGODlhrwHPAPcAAAAAAP///3diVYiDiJmUmYiLiHdqZiI5ZpmcmXd7d2ZaVXdzdyIxZqqkqoh7 d2ZSRCIxVSI5d3daVTM5ZhEQERExZndzZiJBd6qsqpmLiIhzZmZiZndqVWZqZiIgIjMxM2ZiVTNB d3diZhEYEREpVURBRIiDdyIpM2ZaRBE5dxEYIlVBRFVSVWZSVZmUiFVKRCJBiBE5ZqqcmURKVSIp RGZKRERKRCIpIjMxVTM5d4hqZru0u4hzdzM5RDM5M1VaVVU5RDMxREQ5RERSVRExVXd7iFVaZkQ5 MwAIACIgMzNBRGZKVREgIiIxM6qkmYiLmXeDiDM5VWZqdxEgRAAIESIpVVViZhEIAGZzdxEIEbu9 u0Q5VVVKVVU5MxEgM3daRDMpM1VSRDMpIlVBM1VBVUQxMzNBZjNKd4iUmQAQESIYIiIxRJmcqpmk qohqVREpRCIYEREQIqq0u0RBVTNKiLusqiI5VSJKiDMxZoh7iERBZoh7ZhEYM5mDiJmLmTMxIru0 qiIgRBEQAERBM6qsu4iUiGZaZjNBVSIgEUQxRCJBZndqd0RSZjNSiBEgVXeDdzNKZkRBd0RKZpmk mXeLmUQxIszFzHdaZpmDd1VKM2Z7iHeDmTMgIrvFzDNBiERaZqq9zDMpRGZBRGZzZkRKd1VKZhFB d0Q5ZlVqdzNKVVVidzNSdyJKd3dSVSIQEbu9zHdziBEpM5msuxEpZlVSZmZziBEgEVUxM6qcqkQx VREYRBEAABExd4icqoiUqndiRFU5VQAAEczNzJl7d8y9u2ZidyI5RJmsqhEQM6q0qqq9u3eLiGZK M0Q5IoicmQAQACIxInd7mTMgEURSdyIQADNSmWZBVVVqZgAQMwAYIhFBiERad0QpIoiDmWZ7d2Zq iCI5M6qUmVViVQAYEbusu1Vzd6qkuyIgVbvN3VUxRAAQIkRimZmkuzNBMyIxd6qUiAAAImZSM5mL ZndqRIiLd1ViiERid2Z7mcze7t3e7hEAESJBVZmDZqqDZpmcu1UxIiwAAAAArwHPAAAI/gAzPXjw opmCBzUGJlQgQcKLGpm6PBjzAIWCTBRRDFRYUYAAFBI8HiRYkaHFkCg0ptzoUWXKGihAfOHA4aMA EL8UaKyoMRMKAfFeeBTA4cvPmj6JetSggUPImi1//rx5VIEbDhp4eoSK9WpKDQLcbH3w0Q1ZFFjJ avgSFsUvmr/e0kThZg9NDvM07OHX9K2Gq1dr/lLK4ergwn+b1v3Lge4etk2JAqYpYLABDRY4HASr eSrnxkf7YqW5RwNasVNz+hW8dfRWAzRhjwXBFLRNi24yY8XcmihTEBhRGCi9m7LvlJRRhOGAiQOI ls9rxr67dWjhu7mvI/+VqTBaDnYP/lMG8XW0AvA/v/hEa3Ru5QccyBKF2jKAghYSakh8gL/FwFYP NdPFCmO0kJB/orzAXw0KEjTGCvw9EJIEB/XXEEMhCVBDQg2BlJJHEiD0AEMCKEDUQToIIIGHOknA QSsSGLAVWBRmKICEQ1Wn41AiCGCAASmKoIFQz8lHk1hb6XCVBBr8IpsAX4RYYopu6ECXBgzF5+JV klVmWGGSyZihGwbkpgNUbvy1xx4pcnCmYjT9JcAeAtS2WFhMqciWAgqwVeZBMsro45ySSRcnbFzV pANYYZ254gNf6JCiRgLoIKOJSoVVom8fmSiobBJYkCJRZb5WE2xnzshViTOV6iOS/jCl6GKOOY6Z 40wZjoqaW9XNxcEvYoHAAZAgUujUsF8QuxJROoBQUYgrKmBaSiB9RGkAKipQA4Qw1iSBfxuWMcaG FX6xxIb+rVADfjWMIYqECt6H0IQo4FfjSCOCeKMAPQ5ko0cifCEtVfgNtSKHA1k5kIcU5njpU9kO O6hHgqpI1IpoeXTmF2wpStcDSColYbIrauhjlIIi5gZqyWnaEqTVTUbmom5GFpabXN6cYUgCsyWw m43V+VFFlu5LV5lNaXAZU00dS2Z7tWlw5m5numFsUxAxKShuIkhM8R4iDFSp1HmSKhKtxDaElQNu KFB0iSAJC1uPw+pgAcVbmUii/sRT0VqnlDZHVtMD8aAAlpGnIUqrid5CZWKMHy1ELZNuWozVUPYp 9JCE/R6YnwKtPNDKhhwhNO6IDPLn0Lpf+EcihThOKPaj/H0xEKYfDqWRAR2CxEGPf0N6kIq3iyiS izroNFSLW1FIYolkYYUWWS7W1KdHbJElIQpRaiCChyr+1EJYynt0VW2/1ADmTFDZHv2O5tO0M1um hlwnoy05xVaVSzn1U23Zk46MFKObVKHgTD9ZFFi4JAEyOYVmO1MLfR4gtTLBplRkypGowGIVQckH BM+jCvJK5EAVNYxWIQHLZSZIH7+FpWJmGcPF6Je70PxCPoOZ2qieMyjI7a0i/pnY17M8UpFj3WiI HwkAQhKyoXWF6AXqekFDZMSfh7RAXkzMYg0YAjrVNeRbKfJPSHo0EpCEqCL+gVRDBnJFItbAJgIQ IxHZNBCBhS9KxruRcIqSr0dhymDLG9FPztIYsUjAMjahoPZ8F74kRSZFajSUV96HPe5ZTCxRyqAL A0OrKlXsfoWpGlNQtaoZCW5Wl8PfU5hiOOl8pHoNGYp6NAWzZnmNikw5k6tMJLVXDmVElZPR76D0 x2HmaFiadKGJLMAMF9FNBApUWon+FRYJsAUFY6DIGUtWmW5eTi68tJjDcmSln5xxDCuCCl00k72P kMciRHmAEhFiIISEYYkr/mBGJWJ1o/xwiEL+aQG4+KOvEGFKW6w6kBs5ZBHbgegFzBgR/S6zLx85 ZWEK+AdRXqBNc4ZPQpoR2xEz1Cdn+uhH/Dre2VqyFRGkyWoy4gfPTCQWDUwISDSqnFWsqaNf0G8w hMNUbnyZM6V07EwKRBLQzAelDLlpUWLBWapm5EA6NYVmbLKAG8jDrAeUCSsGSGBN6Lcpv0HFRoDy mkim6hEQRItoNLEUW882Sry5siY8lE10vEorBzxrJIOyY6duxKGhSQYs1JqJUtxwmo7Qak9EoVun zrIio8DGRQf5SZWM84sABPR22roiQl5QhocwZEQbsRcKWoEhDJmwRKGD/t26IuTENf5TYCGBpL+s 472+wW0oCpIVptC6M4oZ1GDPqVjXpnm9qlUugakSppWyMpTLLMpEOIrcxLJyFEPCESVkSZaYBCkr 41aLYosSlIua0rWwCuBuOijNeYayBwd8JjCIIUzSiiOljwRpGJqpzWsqA+DYQMlHJRNTdWyktepa h0Jvi0xIVvgUmonzJhb9CAfu9sdKnUojGuhCRtTWFG5a0ibGsZZSQrKHFXFmVvmaG+yIeNlXsZQg IWrc0PL1MgEEoF4hqgHvngcuFLxAtHF8QYJUt9s4RqgFo8IQhaIUS09B0kP+udhPyAg9Fxk0QyAZ 5RfQSSf64Qhm1e0l/uMk4Fam/gRIBq2XVGRkFxVdTnky2mIm2OxhH/2kBjIxAEmcIsVqbey89LNm 8mqikT69gNHDpeAorXcWtUQmK0xar4qkxpAVMoZZLXvLVt0wBrc5hVkWaJoDbjQMRhVnTopqzMDC zMGQeUqAllKUdfsHseGN0tWLKhHf3numRzfrJ+RBbaUmckSKDatyyB1Vkm7EKLAIJKwHRItUgFm0 l1CRiEeBj7jZEoaW5FTF85Hnha64RQ6sSygIBlK+hMyMMmRLyBFi8hYLJkb8iEBM38ruRyUUQe7t RCTVGtFWyZIi3m1Eex1GiY000oIWulVbBsCEjCA5hod84W5s4bBI/iRnox/ZzDoOppSSPuk7AStg MG5byojGByTr/cTKdPIRJnykQiZZgM12WxpvGJeyN1HmC2GAiVKswicsSbpHyVMLeQRtOLMlKcUg uczPWeUmQRkwS69R4KYoBZYu7OGTdTqPBZZ2tx+lSTNpr5dgB3WejSn9JoPJH3NgA9fHqtVbCbSJ BoYBEvnoLVmbmlS1puIswK9IbdgyoQQyAWUTvYBPZeXP8L5VozV+y2Rt5FyNRjRG4o2hoQyJEr4e DxIRRAu3IaXQhoiSkIQRloiZRW3fHp8tEFmEoJrGT6oKw1WiW0ppv/u7RT+FKK8hkz795amcAlUv QbWIhyc9GQiE/tkCDSR3UFKryeEUkGq0+66FUQElX4UmgT60+H5FEz9R6DR8ZNaYd9HZarT+9XcV ovxxFPNtQIZ5LWRgbSUjR6Ev01Qn6vVm83ETGfIcg3QqUZESJkErGuEigiIkL6YUo4JY86E41WI7 kyMTRIEC9lEjKAAhd+MsLSBn/1Y8AnVGDSIBPCAAPCBDb6QDNAciosNFNVIDF0JW4bMzYPZwDPMR FCES7kMsKyYhCkE8+SJgU0EijmIA/wY3TfE/vUcxTJEZJ6VLiFJzyjNpxDYdFgNikOQ2AzQswAQk opJ8y+UAwWZRPJAJPXIZS6MAPLR2E5MZ7RV2aDhMZyUfPvKC/nRoERpgX/jTNJzxGtkhbGwlWQ3j PxDjUqiCPw7zF57SUaYCAjxEE3cjinhlTMtTJ1xCIipUYhlDEfe0Z7nTeS1BTVtWVEbzgiFRRKfW Pn1SPvP1gCcyTwexOSVyEKe1TCVyRVaiIjqwLiIwMDqwAiHierHjPFJoLxJyPb7nN4MUIeWiE1Q0 ImtmcExyYbd3Ns+WIsxDFDzgfTRSJ3yFPHchTRnGJxpocslHGTqxG1txN/RCLyLADw6QY+xVXbqk NKkmTYZjAQ5wQWkBFRe0NIHCZqs4N/ShVmPDJjW3FFJzdgIwDLCxiKciTJThHBiWKRjWdSiXXmTi Bt9DMfaj/jRksmtucjcS4gZHYIgKhICDskIWkBkOGS2swkvPeD/CZhx4BR9QkRm+lZL4IjcvWTGY 5z3ItGqldhsbcX7YE00iURNKZC8M8oIVIo6l94J1Mj44mEAHYjtj9GX0dC+tAz29OHr5NiEqdWGC JoQ78QVCCFDzcl6VYhNLw3ELWFYp0gUy8hyfoRdOcRn2FSiB4mzVBZFgSH5NgSnPMWVoGSLBJgHx tUMWWVb/dikDtCnS8iNF+VuQ6SYmACQGMIwctQJRFJsrUAlH0AVHICAEcmTK6COf6QAgCTvP9iP8 +BzGCT91QyqKEoc4hRmXgpJ2Y5TPkwnFhCig+GwblmrO/nEeeMV715NzRpmA0dEYSxMan/RHIaIu udVPgIQCb/QsIKEgdbIo0oY0CKgTTQkW9lEp/UIQRSmfzhIGFWIB4xM2EgBNqhNHKiIjUCdoOPIu sRRkpHeKAvNXGEgW1oURAyGfI8IMmVCh1QJYjcOTBiUfCPgAN8gJGrMpKZRze9Bheoh8PcJDDnB2 ceI/SvEcfSIoBXNhIUGHp3lQeIN9/NJ2xsiAEjMcPnJ5E3YTOvACYcAMY3CbR5CbVHoLVNoFInab BFKblVAJIrYCmbACccQkeTIGX3VpunGRwyKUGuMtHVEmdGNd9PEpcSUqAzY2BZiSwjIsd2MRw0Ib i4Ok/rlGUYw2Hl8gLBkTNP9GHz2iEstVPjnCOL4pNALxAOvxACBQVH0DT4bCAUoUI5rxmkJheURC EDcSBgEjKXEkNQ1zoA/gejESIzrQMCKgID0CUAnBFrxHJtY0ZXEqlx5WPP8yLxO2JQjhWhclFA6A CSWjUx+nAWLgf7jIhb9gGnwCij6ydnIIAl2jF5gxTMLBh4QBApaCJLmKhYmnImunqXG0dgbgh6Co mD8CQiXCoE3BkCLwcyD0AGFwBGIgBl96BGVgm1OKm1o6Blq6AgNyBLdQBlVaBl16sFP6Al0wCBKC hUKhGTSxHHdhna7kWkgqlE9SYeilNLkEbRZFJqVR/nN5OB7DIkywERNrMifIZx3SpigqRBPRQR5y Y6PK4ybA00MTszyeYhP5QURuVRtLczky0YvziXKYMzs10JDUWW73xCeaygMg8AL1gnlb9EY5KUNd 0E/G8zpb9mUaglrM8ALJohEJkYG89I7WEyMo63RC8iOCxRRndDsQNBw1in+r9AI6cAQOMD6VozQv 1yIbWIzphWGYJxSyERsWoBG0wa0aAySpwmB1smocoKoBFlZHyy/b914esQFv2Jo/Mgb/Oghl8Add UAliQLBVWru0ewtAIARdIARAMAa6m7sPIgpZOgZlIC4DoqUESxHtZq7xcZLPlpIPKCx0yK2Py1aT /mtB4Dosihgk9XVq1RWvifmTHGuvDrBqdEiBekgQB6Q0wmIBZ8dV2isAywEfAqAgJAV0xVgvUSs2 YPECh+NnNCMjezIQsWEzWPFOTPgC9pG3K3J5CeEs9Yta95SsGlJqJCECYek8ElBuPxJaKUUWl6d7 IGoiRsFmySI17vkCXssQIPRmJVZ3r/QclgJPP/JteYgl/9AjGicADiACAzlNwzKayhlsCpCF6YuW N6g0q6YvP5IiyJeYpohSdqZ4Ejd/YEhzNTws7KsAYbB9FrAAIsACBCsGH1C8tWvGBAuxEEuwXQAE RwAEbQwEcgwEDAsE6SDHDKuluqulfNzGfHyb/h3nKa6ZKJmbfS8rbUsxPGISkuBqr5qbanvAA4W6 KQbwBTerVyclMTp6EjF7S6n2EYNwr4LWAVjBOJqKCR7ZXhukAWFgKVt0EGFwoL75ANzgOvxCEnni VqTRa9hpGrJxdihIetoyzP5aom3EJy+oA89IPSSyECNxZL6JV8UoaII2TW61E9wjWS/3EfToZ+gk yMU4KI1Kd/zimMTpyKOqh2ClNJfSzdvXcHcjTSjVMCBAcxxkKRcUXdJkkihlIo+LAkLiLVPXGLrM NC07FBvwkz9JqiVQpR/wAWIABmXw0GUgBEfwAUeQCLSruxx9BHc8x3BMx3K8u228Areguwy7/gK9 KwS+OwZuDMdcKgpNVANFIykZlJh6GK9bBr4WwAMeCSTR4SNys2HNQZyNakyQyUPAk4V+KFlySa7o G7Mg1AIWkNBh5Vb22nilAVo9eRN9YAHcUAkKgHav6VVM8yk3cR71hSUfocInWGrAcR5kYa4B8AKs BTuotUUj8oyY4joKRiJjPSJnQo0HZSLP2JjnMT6ZNWUsPERTcUV8UsRK41UkYn0ntYiveRnjfBmY AjyK6zV5SBvt7H2YQpyXAQLDsBQ6IDaSrDTDQIeskkLluwde5b4NKTE18rzn8SRSm53eB7neOiwb wMUvELEBCwZkDAZlXAY+UNHMrdFCwNEg/v3SuTvd063SJd27dOzHcJzSfHywBNtERnJSrnmK5Zcq SrMoYPgjLXgTBmACZwgwINCQUtxW7XVBiyjPqEmu/PI7ERmv1gMCPBCvDfmT0Tsomvc7OtECGYBa fPUCDKpgG2cBYdNp1sI4GvG8EuO/jdd2RLGf+UIS8XJFWXF5gFXhcTTWEoqFCk66DKI3l5dxSjMG zXA7PYNdXlsy33NRhtcCiTkx7zwcN8iGeIop+ZJcl3UeJk4WmOcpW/dv7Byj/2ZftmwAq2ZT6b2g 4ScBOXlrlBp2sIEku71VlGs3Uc7OPfICrisGiEDGF027xfsBQVDRR2DR0F0G1V0CKyAE/io9x3Gs 0n0+xyndu7LZ5wOi3d3t53BMvLbZBVZkorDxHD0ymorr4x4hKp8SrpGuxQ0JPAbgftG5fYIi6ijb jikzhtx63+ArIxtwE/BaX6Ii6mjlhSKX2aOaLRO2yBwgyZScfPfpZ0uXqCdYbjchgQGgGduieTMn SArwApRXIqVLFi+ZIhylILhIUCNR2jqQCcU9IjzwRyBkO97LOIFdca95Hhx0untDMVPnbGPtPZdy Oz8C0EzOVzyGUsz3BXnLc0Vj2BwwkAYw33kCzpBrEdKbatqJFTnHQ18ItM/BkBqwAAawAS1Q3H8Q sH/w0B+Q8cr90EFg0Rb9AdBd5xld/ue7C8e/y7t4LNKCLtIDAugD4tJ1POiy+SCFLpt9jJsQYthF Gs4awAMeznOKS95+SOCPGa8imbeXwQOa4c8Vc0GlvfQt2DVrp0t4VcOgeO7IZhGMZ2U8ZyKtNpUh JALO0jXPSKv7olYc5q/uenNcD44+ViKpozc3QRYvyB9tKo6Abdhu6R/Oni+RDcuuBxbtCE/LIxwQ OBUb+gCf/O6vyS+wHNnCnDwOuK+jHtkZApnvlRWmTTFHOyJzw2kAfbdg8fN0WM+xyjTlawIySihY sd5YEh1at+sMCa8igLoWLwYeIA1qENFlXMbIPdG/XwY9UOcQ+wEgD7GJcPJvrPIt/t/ygS7zdCyb Ig3o1X/dKyAKhe7GCHubKmztcLOv5bsopq5AvHRBaxfPv1ZzdruRruf4ScrOPDfbFO6nzpnFz7h9 LbB9FsFybm8iAAHigQINDgQoeABChwIBAkAgVGBAQIuGCiQIMMABY0MQAjQ25MDhwUiMHS0oQAFS QICOBxUwpHjw4EURFR/UeCDh5YMWDzBKMGDgIsKeFIU+SMnwgUQHDkYybNhw5EAUDF80FGFAhIIa YzRI3Mh1qYQwUEFwUJAVZcW0OthaAMrBgFsDDCVKBFEX40mMBgrWXRp04wYJFjhI+CpAgwURHRVY CPowDAsOZzVmrOzRgIWvES04/uBh4MeYIx8+cBIDpsyHMj4+/BEjxvSHI0eClPaxWoiQMruFHBGS CDgQIcSBGF9xfEVy5syPd1kBHcgYICuoW1/uvDqQLty9j8nepXYX8WWO9KxBUYQOvzw01Pw614EG jO8lZg2acSNkDjXD3N0jPgfai0+DghbDyy8LdAhpM7w2OAmEPTbQYI8wBLBAgDAuAquuFwLD6KWD BBNRAPjuCkqHCvnbbDGfMnwhEwVEQoGDMF6gcSUTIbtJgRc6akGilx7iCUiNWpDggRcQGkgni14w CMSXLmoBhKtmhKokiAaaSYExYkroqxfoy2s+lwy066CFODAoTY8cMtHAB2rC/hAmh4DCCqNhBvTL wMSimshABwjySwQJRNCAh4YMyMshRjkwrLLN9oAssrMsFWEDBWwowwMPwEgNDFFBBWO22VYz7Tch egButd526w2IRIhLTgjqjithu+aqq7W75XTlFdjsliNDuV+Zq2GFI8Abo1nzVnjhBfUQU5Qi9uoz YL6gZpTLDcYi+iki+hj6jD4DMIlPrr5ItMuAPe5bMKMN3H3pJANQ+CMTDRDyyFy3fDIBLIL2Vcwi zmqCbEoUEjJAjDE40ECjGVvSDC0UJETJBAEesCAAog56AQUnq5pRAB3GGMREExRgT6euerpIAhTQ 0yqljV/id6AXLnIpzYEn/moJrX1BoI+z+9TlNyK9DPBJBLnm4uwFyIzC0On8sP1KI6cdGmZlZhQz oAwM+xobBA7zK4ix/BpzIAMHQGABBB7OAsECCyhl1AJMBnDAbh5KGOSD1P4gddRSRf2g1EQ+WPyD IITwQYjbVn3VN+OKyzU74o4og1YhlitOc82n01WUFWoQpQYyRCEDmBWsef2F5UThwvTkZId22OXG gA66MdJrRYJDC9Wq+IzYy88tBd6ZL0CHaropLIwc6A+TleWCuFFGeXibs7oVyIu/zxpqwauCONjD IL8MaIEgh6jHaCmGONAhQ7822ogikRcW+gG5zF4QCL5wkKo8BSkBCMMY/nwCEYvMqCYM4QFXBKKA L9RkKAyRgNlKJIIxiOghAkBBY2TSLiG5aSd9QYhe3sMhiGQwKx2ZzwtqgJCsyGQuIKjBRrbGkah0 BG35CUph9hWR+RBEWzKpCQjopEMULeYrlcqPCSADgjIFzAILsMAGwnAE1SQuVKP6YuKCwDjHmSYI rVmcbdRIud0AxzdHIE5xtvMbXdWKV6FzjuhWwLrswA52ZFjB6lZXuxfYbo+7iw6zksMsIBwBOjVI z6F0gLyjWQRi8xEIWBbwHsU4wASKKskKwHY/xATlbYwq2r42A5SXcGABjHKQYTgWEp8EhUsSCYOh dFATvdyJMC/pU1Ay/lSlpaBAKCGpD1pAOBAQVKUqtORAAEYUGp48oCwEbJ9INoSRngzEIjrpDCSh coQ8hUhiI+wPidYVPhGkDyyMWQy4fMQliL1ETuBqVBiWwoElKe15+KzJEktkkUUJxWZ5aRGjTIQS u0BKfUCslALKUjcq2s1ufbPbAkBQgi+C4QZg8EASPpWE1JygVKH4QCjKgNIxJmKML7VN5D7Qg8rt xjiJCM7lACnH7GSuBL/63K4OeazXrWAJXPDjHle3hBosgamFhJYhmyO67nSBOr5bwZRM5BfkrauH WVFmtobBmI1sUzBK1MBZzPUYYSomQwlzEPi+kjX6qAlinIQMRyqD/igfbu2DT9NIXu9Fnz1gRCNn ASEIieZMKn4lDBpgCfgOMpJo4aQnH1JSLfdAFpeFzCsi+IIMCcqyyjBEBAM5LdOAabMkftCIA+Gk 3NqDJZTQxEQCWNKI3uWuAtVFBympS0QgxsuMBLQqGKlKXiQ2JYyNLSJnaWWLBlQpHfRNKx0QZkbz kgApbuAFNhBC4j4lKpMi7nChAAN6URqKILw0CC71weIWd5sgRK43wsGpb4qzX+UAIVeD8K/uBLzH 6vDRGnzklVGt8YIFw24JL3hwhEUB4aZCcsLJMl2yknU60/GOPEe4BXSWNDwEYc94/ZFJiGaUofqY LShZQxiWLtOi/tBUKG8KzQiONYK+uwzTmLflZUkwVGJe+lAi9svIHpaClIbYTG9yyRDRNPAAyO4k DC0gWWZ58qH2iYghdnnKDHVyS0SpNrhj4IhqUaCDKw9pK0sJkgZY8Bi5UNkhBLvPZuCkWpnsi0Ma UB5BoMKQuYpQIv0prGI4eR/8+eVtGHKtCdK6GfaguF6gCYpcElApi2qxBH84QWo+CgaTlreML20C GIJwgiCwt73u7UF7e8CqWB+hBz7oQXj1ezmd+nc7mRsWF5YjO0AGcjkOrl1RHWxUMjDVqclydoWd +oCjOtXZLXg2UycsCtt1eDrYgdYtAT3jqKBtRG7Ji6LEtZjC/oToLs30TEbKBMTNOOZidxqbUQ7T ro/4xS78cdQUhYTYhpjAmClBC1QgNim0oE8AewhAwr+cwZtc+bhNmpFOaEJQEYjZbALQCVpegKiG 5DZ+PVHiQ8AXGR5UxZQOeKGQbkvkPHHpQ07TJ7iiZcwMoghDYOnLgjaw1T1nmpcL2mqOBTCgRRlG BB1QQAuqxB4FLGAD4RPNZGwwCJB6ygOOA0MS1JAEVTvupekNgqpd/WpXJ6IHLv2A5HAdd1blV1X6 5e9xgsqcnxo7O8WGnSgc/GxrLMGoCo42F5bQggrLMMLUnvYSqC11yi8+PUytgTVqANXlQMeRjhzD h0zLW7XZ/hhDC6nPohbeHzZF5olMM2aOEzIguVnUaQylj8QqZE8VkshB8pbA0H14GRbXRF9+gZhH +FUZZdJyRpvxmD4fkmWezEwuoicUkggK8puRT0kztGH8XAKUqrQgonvZ1oUiMxb8UU8wHAFrlU5L KEbDiS7hZxmcfAi/IZUbxhJJCPHJGnmzGneJjJe4OgXIgLoAAah7AY66gQj8KJNSgSSIuygIhSRI AlZznBMIhSZotTVor7V7tVh7ux4wuzJAQcgJjpq6nHQojjlIjr4Dtp4KHWH7I9pZgmZTPGtbMGtT PGmrsKKYvMvDNqlrhcVbPCRMQgtbjmTBnexAGfEIPS65/hZHQxFy2aXHYBChUAAH2AOwGpC/oL+6 YJPw6ZusgYoACZAx4AETkIAvuYy0qggUQQsfAgGK2IBLshuHGAMWKxgQKhnkuph72aaVsBJu2gks g4mUuIqbuYq6MCYRKKD8aZIw+JcPkYkq+cIbMpHSUjkL4B4s8hGJsiYd6AhMqIsvMK1+wYQSWZ9t iRY88bcOkrmo6wkI+pP2QBEVkbS0wCSqUxp5mZ71aQwDwCIDYIESKIEjuAEPuIEPOIGQ+pSUchwa IDv2wgG0+0ASXDsccKn3epwgiLWXmqky8g278y/XKQFAAqTqKLbl4IJ5jEIICyTa0TynMiqnUrza kbr0/hhCIpS8FmgFgjTIVlCAgiRIansAhYQkp/pHxmO8zds88LAO0iiDSqgELjMmQIOfxWix9yAU AZC0unk4NjGTiKGf2JuRpuAMpssQ6uEBuTAQFIEMgskklOgIPEQJiegABMkIpPCfQYAUj7iMhouP d7k3EJAmAdCUZrImcVGsgWAUpLAIFJChpdiKQYmWgVCSeXIA0duKiXOXYSCarUiU6SE0QuMlFCMS SgGKZsKPaymzJBGZcFESPvlCDTC/YwwKv2IozjgJkTHGL1uBCBqUpfA/ECKnDBEBB1gALhADryO1 sPPAJAgFGgiFE9BMzWwvGgjBVWu1VyPNEiTH05Q1/lkTgi3ItfbCOyGYA//ar2Jxx0CKR2KRR6Pi AtXJjt3kR2njgn9cQsZbQuFxyOIUnksQnoRMSCQxyImcSA2DpCfECQyDJO7oglsIMVFonz7IAB4Q AVGMMsMCpoJgCIFgw+QzjBy6SZP4jD1giPQxjL0wjM8wDPeDjD7UiheiSiqqodXSs4jQSca4GCpK wx6jCwRCCE1ECWt6AdIADCKJluLrEOX5voE4EqahRB8RGYaCiAx5DMZQl6AIgxrYDP6gInVpgcpY kKKEivZZKBKhCJxhH7RcAAVQt2E0QBCQPrmgyxQRgdAwAEXRCkILjUVhs21hgRYoAU4QFQ0MhFCI /tJASAIa6EwrzcwgAE0tHc0sJUHSxIEgwAETPM1yJMceYM1xXJVE2AIhKIEtWAE4/ZzaJAN3rE3W mbAFU53NazAIg7BqG8gaYIH04AnLaoXgOVTKQ8gWuISXIMLqK0hcpDyL+Mf0+ALLuomuiA7ySIfs TIdbKANuWJKHQBBM0Mv5mRgDnI+OrJFh0IhMeEQDFAm28oj8tICHgBS5eBe7ockc44z3aAkSGtEp 4gAUeKy3yVW2kqu0souIE6Gt8CGHoEm++IqUsI+v4AkOONKdSAsT8SY/S4v4cAn8UIi7kKgQyQtx pcq0IhpGWbkPIqCWWIpxkYiRYxogwghNQRTa/uOIhVGiE1Wo+rGg0ICP9ziYRUmUk+AoMbgBNTgB DQy7zQyEzszMigVN0MSBi+XSjRXTHghTMUXNMO2BXDDNKBCCKIi11VTZ3WjTEtgNMvgpGQQka0Aq Bgsk2Uk2MqiBmgVUCNvNI6w8ysO24UTCJUBICWjUgmyFauqJghQZ4dGJ4DkUCVhaghQeglxa1OG2 02Gq5CiD3igDTlADMciqDeCBbzkLi5ob8emICmmIRIsYw/ALIjlJKXs+FECBeXkfu8mIu7lJBBkm xkCogbMMd0WBDmi4kgyKmSmUlPOY89SL/wGJGbEmkYMKwYiWh5sIn1myq+AkLkGiRdG/EbGh/sR4 PpSQi4gorAa1obE0ESs5lKhIoboYUq0YObsAjYkoi8ywDLJpV64AM3ER3LQIoA1ggSMQAzUYu8Qh u0A4gSilAc7M0s7k0lAQQRxwNRL8WJBtrzEdx9OMgvZKBJQNgi0oX5V9L5aNU1qJzRVwnUGyBp1F KtUpJGEzvKNqqqMShWoD2qLoicWjtiQU4OdEyEWVAIOEWo37JuExlAQ+4KXliX+EsKGtlVoRnFJh jQ8ogWgJA0NwgDxwgE3DGaKZrkrB2xGtF80wmmyxgAsRn1tFn/rEiD1IgII40m1JjPURCIZ5FEap iv+QojApoRVW0K3KOYcY4blZkhc4gsAY/heSibqQeaCBmA9v6oiyiLpbUrlxFQC3sSG84IyDQCzH CBBGJCDQ/bKBQLldYozwDIrcwo/G6Ak3FqHoMol7cQwNeMQFKCIFmJcf4CgPKDWRel7OvFKL5dI1 qNg1CNOMDQIRVGRFbq/wxQER7NgxxWSPjTXy5WQ0ddlcW1k33QIgAKT3rdMVELaa3U0ysMfd7MHg BFRYDs7Lm7wjDEiFREIkbCCNA7mLUE6NS5Lg6eUDrqalfTDZeYHdSIRXKQGc+ineSJzeOAIWQMbN wCIqmpcEGNY7M6Wb3IsdWZ8AtJusWYDdgqWDSR+nrMmdxI9tMQFKuU8qcggL0JglWb91/jMAlvi9 kVCi/2GZX6yIhsirbj0tLsnDL0uUL1sow3KagLKLrNiDlovFhyhAgaiSqmGrD5FQ9TiyqPMIqRMA Pq6Lr4C5v3yIlBu+4cOei4lhN6gLpxgQyHylH3hA5vWUQd5Mi7VSGnDkKhBT0ISAUAhqCBBTRmYv Rg4Cot5e7iXHj421j0XZMDVZk92CKGBTlZ0DIQAG2GxHrcZNQKo23Xww+Y0wV34wbJvl4GwBaZEh 4ry8piJOyjtgSj1gXr4E7qNa4Rnmut4YyVs83AECGcxqlYXZcQRl06hMH2DGycCiecmLDQgYKqpd EzABTMgMyQoDohHjmxQmuZCivIEy/hvRnoOtIRMTAHrggXd5jIc40b453I0JEpfIEI+ZCzjZw8bg ikh0CSHDj90GnxoSXQEdkSQ5Ty9TJvtpij9Qms7ACNxmoCICmS+Dxb+8swXQECgB1rnhkyJNiyJt bsN6lJ2ElK9wg4K5IgtogR9YxhNg7yRoAmzcwEAQwZ2GABqoglCoAqBO6v3maaRW6kfG3u4NAkpG ahyIAqkecJHNZKme6tUcWdhcWTiF0zqlcGGr0xfox7DmAh4c62qDZamDsDCIMApjAWcz8cVTyLrW OCTh5VboZRPZJZBTVIrE8BcgAzclg3mcgzlAUw+E8B5IAhVIu2dUXkEeATUoARv4/gED6IAQdgED 2ICs0OZ78ZEf2dF6I5d6g5TNKMmnsZuoY4g9jKXFCKjnMYD/OHNGQXOU3AyUaKcbLQymJGGZ65OC sK6JMKaTaKX3GAm/0AmyCU+faB+fGIR+QhKyKYvg6o85QQglCiEQLRQRoV2ZgFfhE2i8UIsXmBtg XAHiEoHwDI1/myKJSlFePYvdOghORMEPEKkNTAIvqNKdpoEpmFgcuG/7ZuT+xoFKrmRdT2qj3m+Q /dgwtWRKvuRGNnYcMN+qZlM0nYM2hfYSAIY5qPD4Betm89nFQ+WdVR1hs/GdXUJDMKoH2E0/NXHI Sw9dvgSC/OXlTGA3uGsRcAMd/nDxT5eA6WyOo1qBNy0BHo81Sw4CDTwBlwo7smuvaRSvE1ADD1AC IfiBAciAbO4AHqjh3+MTF5guS0kQExjDBBAA7DIaFDiiIa3JvOqASuFRMciWMOCM/ziIu9nDIPkk Bdklaaobx+puTWmBstAAx26BN8Mt+hMAFlg6qSAemZiTJSGJUtwWFeuxDEjooMAEF/sMAxiDwf1L EtIL+8zi5xvSvjlGC+ACHFmArBiQcP2KUGQUKjqLUWiRGy0BkGrvE/CC542FQJiCnV6Dna6CNYAA CKgCHCDqod5vCIiCA/d7MQ1Totb18D38x9/1xz9wlD38BI9qj32v8IX21dz8/tikU2Oz0wxXvByn 0w0f+xxfgRYY+wxX/QjL3yWESLk2BJ1AkqwQHh24/V3igUuoAc5JfVzE8H1nRlXzQPZ2XhoAA+TX QJGKgzhQAeengDigABUYgRHwOg9ABCGwgQ3YNAjJgAX4D5Z/m8dwiLqJjM1oG9rLLmvuG+ty+RsN lPbYySrh25DOrqeDpYGBIQt4AJbICsgAiBcvWoAwYEDBAxEGOChQ0IJhCwUvHggoKGLMCwEEFWjg 8aBhwowfJYCQIOCkApMiHoQRcJCig4UKXDpQaECABUwxHTjYY8CCAAUgCnIIymJmQxQNQTQUIEKE gA1PD/JwoMFEhj4aDIgQ/hq1YkELYhNYaMjChpAPTcAkOXEiEI0pSabQoPGGRpUqeOtCwEGjLwQa a3CsgRDEcBQchw/jgJBYMQ7Fj4MkjkI5COQekSMn1oyj8pYeuaJsKb1FSOk5QE4DI+P69QoyXFZw EcXlxRIuXGqQeUEm9grbK6xxyb37do3dSx4syb2kxpIWLZpLbyVdggRDInSIkFBDhw7s2yUsObKi xqWnT1uwaMGlhJBEYIJ8cJuEjwoVSfTH6d9fjQpqAKhGHAHmFyATAIrhwQcbZJBBTAnU9BMPBoTh gAUG8JChBRUaJJYBDpjQhwkaiFAQUyJogEmIGmigAFAbauCASwp8aBCO/gUZoONCLgElQkwKBDBT RU4xJYEBW4EQVVcf2egiUiZ95JJLOpjgwAsokGTAAzfZ2BVOImQCowADLSRCGDbO1BKOBhFUlUsa LKCDQUwpwMGOCoQRxlBRcQACSxJsAIJNN+0Y1QPthUGSCByIMKgCUnVgwQILjGKADSX4AIYHHpxA w6dw1fUGXHnpdepfOFThV2RrVLFGKBAMtkYUUfQ1mDGf1VrrYrtKlpgdmNmhWLCV6frZFomFluwc qJ1mmhCqkdFabLJZ61tsvskGHBe/ydatbku8oNu44y7BQnTnUjddC5e022563Umw3XfD6FADEOcp cIlUhrhXAguzxcep/hpJJOEBH2okqEIcBBJY4IABDjiCGhRTDMcIcFBAARw+sLDBIg5sgAkIFhSU QFggbmDAHglseOJPHVowqAUOZKDTjEtu4ACLOP1klQNhGGBChSD6ZJBXCnRVp0scmBCAUtIpYBXM BgXVZUMrifBjTFsnVFFEKJnpUpcWtKADBw+0YOIRTgmlAVMvciTUCzOdSJJTUGV9091LQcqUUzHn 2RCjDdloUIVVOaCAlRBWuAAPCSzQgSFnlXBCffa99WlddAVCQhUQhA6B6KFHBtjph83aGLCHVTYY ZX25jkOufdXaGGZ9NYaDZsYmlkityZZGWmmozbEFMKrN4VoJrs3W/i1w27oWPbfFkXtbbLylmy67 1lzSiiGXZHeJU+npwAOdl7xQhnlKP/rvHLSVIJ8HBhZoIP5JFCyxgAbCoQLGGjYCCsRhBCpwRQEF 5AqOlWADCqCHAwbAsgyYwCA2CQtPMoQjBZigRBrqoAlwEhMD6EAsUwlczQYhAQxlaCs7sonMAKeR hrTAAENaEggcpbSvRMohFlBIWUBQA4HgaUUHEcADBIKQiRBJBC9IUpcMIJCFTARwPAjKTVxSkoEA 6kttutFBvLKBoCypTjqygAZMaIAFWE0qKZEKGjuUJBd2yAFsNMQMfJC5JNRlDWuoC1xEdQ5TETJ0 qzJdY0Jxus3o/s5WxhpWFAbjmNhRpjJBsEOtJKkYw+BgWJD0VWIwIwTSjNJZzxICGbYQG2mtIHq+ wdZvnvebOfhGN9Yr121yORAusCs64bsEMMX3lEvowAE8aMEKuHEE9PCAB4ZYQXu4MAMhpCUUJ0hC fwgoIA/0Dw5x2NiAvknAAVJggRs7JzpdMUA1uEIQ5aQANVxxhB+44Eo/M4EFJkUWNe4oRCbrwwA2 tMYf/iRJBV1IGneEpD1EpAMGGZQITLAAB5BljUGpCFJmAoIAOKWjR6gbV07UFY5URQOGiIoCapAS EGgAiQ6UwAO2clEcZUIHL9rKA76mJxIWREkwc8qYNCLHroDA/kMVAtMFmZLDmP3JAA7FEw86YpCO 1CyqxrSJRBKyiJmxYJr1aUtdOFeXsVYhEIUkAehAl5fBrGowNGAMrRwThWF1sq67Qsyu8gqB3n2m r5B0DGc6aSzMRGY0ONjCaJ5lGiDMARglSB5jVxA/b71Hsq6MZW+sd5vc4KY4uZEOaJfwS2CKIF7n E0ELRBEcLuyLBSt4wSUWEbA5BAEMTPCPwwTksPoByJsE9OYC9YHO4Qrim/oQ7sZcobFdlNMVu0DC LuDARhN0QAEdGACGJmrHmTFlZTxhY5vkZIE+0GhJW4FbhWQqog1pUGk1a+GJQPACQnEloWkMQJ/G uIIa5mle/k7ZgJxswoM9NGUjK5BAQ57YUYNq4IkWoBPfqISkPM3IagTloggEGsYvBkUECwDRkjrw JxYeKkV2iohCDgeknbQ0KgapHBjAcM0khIIGofDjFLwQiDfohQR4ycsgC3mqVekuFKsS1mcAi0m5 LhmUunLksYoFWGMBpjK3i4xoSKNl1BAPNUJwLDBWoMotAKF5ZibDYy3bLWuB61u2LE572CMdf/kL XukhbWlLW4MycOMF6pGaIYQAhvoAqGFtMZD+sJnOjKkBEeUkZ3KbO4J2LtCczD0uc9+5C+WqQRCC GEQHeJIAfH44QyDYwFDFAl6ZadBqBiEvJhBSQwEM2AA6/glRQH8COYkIZWUVYulCrKIhIaGAv21y yAuOsjL+wmhpasuQQh6QIQ5kZCku+cmBgYQjoIRlJBFxUYVGmKaKcEUA2HXKlV72tp/sQSwZghGH VC3HpeDoKj+jUR0XIIASfIATSWALGGxMAz4GZgp3GbIjhDwBBjTGdI3cTJIb45iJ2/VYtTKMrD6D mbyyrjJTfngUJnA7KwsvCok1TWqSB+bHsvI3QrAsGWgpPVl21j2gNYQvgRm+dqmHtDq4xArKkIgl XALnK4hUoMsQ44b5p0BxMNjDvAkHNbxzgZleoBqE64oDjqDrGNvYAPWRBn08Qx+72IU+lDt1OKwd CXUr/pkD4F6WutXs3i4s2Q/PaDV8xn0oO0IjgBXwh4juJEIGWJlLqrs1rsSEKEOyUZkeAIKuCUBo GrJADeZ0RIe4N0ctqFENgRTRPuwhA0LDt0iVVlSzKWBD6faSQlpQFgO8wwUIsQoW5VT5mrngJj/4 YpJ4UKKabcVRP4EKj079gxf04AMydstYo08DIvylCkQIDI/xwmPS6YX7ottdX4alO7o+XOJ1FXmV Ly6r9bOOdY5hgCNFbgeRi/zJxuqrEJC1hWadJuapdI3ytAYXjBkQCEGZ0Ua4NEd0FAdo6YYoGIJ1 UMcloE+7SAAPZAcZAEFxxFYicAIXwIIRCNoJ8JZu/pUgHHATN02dOQmXPgiC1lHALmQdEnyTCmQD BQQDDiKBDsZBD6gAEqjBCVAAN93AB9THDZyAGHACHLhCGdSNA3DAi5gACAzCB9jM3zkAPVBQUfVE P+0BC3lhiXQFJuBJl7BUBX0QG2FIhbiYAciAFKkejmwNR2lIGBmC3CjAgSmNFE2VA63M4JCRVBye jVRQURnADzxKQbBAUV0JSNUEvLXAiVSETbzIQaCAVYSBn1nNTOAIQ5jMQXSRUCyFBBzBUOwJhpTM vZmaDzTfCdxAW/CRWFUBj3XfGwQG6dQi6eSiLoJflaEO+YFfXS3S7XCSr0Bc+w3LASQZsPQi6VjZ /sg5I7OURiKUBjCURsxVI2O5BipJFmO1BhkswTcyoAJKhwIuwQqI1p35yyW4wTB0xxEAQb5cAhck giEUAxnQAm15gBdwU4BQAACpAdtRAECyk8ZoGgyeHUJSABIIZDDcYDCkgQoYwxBYgSY8ARpQQgEw QX5Q3TbFmBgkwQ3cADvtQhlkwgO0mwlwAIYEBVlgAj1ggieaAMmIiAZZgBcyBQdsCAcIzXvFnVhg SAY9FAeszKkJzRHY0R5cickURADkCVNIR1coxOThiJMswLwUlFINSlR9mFINQM1sAJ/MxCBsIli2 QJrwRPDVkQVxhZ1sBZDwQIrhyU2MUYhYCFOY/owA9ERUpVFVLAkKtRuIdAAI/EAJHMFaXJNbfMof 7cVakYDo6CJk5qKtoA5lAob4LdLueNxn4EEUcGZmKuPF+Q7F2QEeiN9kng4oPUYPBE+tzAHx5ALK oVJjfVljXWP8TNbzOId7fBZo9SagxQtcKkAZAEEZwJkhHOciGEIikEH9MMyA9FYceBM7sdM5uUIL Clem3eBzqYEOIkEwNIERFAEqaMImUAIaoEEvsEEbQAESnIDE6IMadMoJgMENdAoncII0sM8YNIoG /AmHrFFBoGXp2R7LWEBTTdup/ckGcAAaORSBnWJEcEVBAVGdSFAF7YwJLIJNBEBNmAmhgEBE/kBl TLBe601NhvhhPwXl4cGMI9ZdBhxeOLjh1pSojeCGC0zFjSxNsPUnlZSRkvxEjfiIknDeT8ANUZwa IrJAYTrfDYDBGjSBNQlGH9miqzzmY44O6dgBBNgBlzIAZdpKXVFc+GFmXzAcmDqS7QCWyD0G+NnK BHTSmw6LyMHfBGDSBPTFAYyc/SUL8ZRGDxRPbAKDbGbjaxTHb1BHcxzHnEXEcYbPvrgPMpkjziGT EPRBHpABKoVCMAwIb6kANwGIcsWBOYWdICAB2TVap3ydPvzgIhTBADwBJWyCL/RCL1wkFNxqG8xA MMynB+hPp3TKEXZKEnIC+2TEkhgo3HAF/j6xzJWcolDsyKn50wIkFAYFjc/AZB9QCgt92M8oBOHZ yeWtkQZwKIi6j08Ryruhlo2wiB9e20H4IaptCE/wwNQYwApsAAtYyCBQyguEAZD0AYhaSAksjt1A RaMYFFZ+nuEoBErwyLUpJULxRNkohB2FAVrURxNgzh/V2GJKX2DoBRG8SmTqIh5sqcQ1Yy52kmW6 n/n5FWe+af1BkmDhQJ2eqe3M31zJX83SHyY5kiN9kpbxKcqVBmwiz/5R4/Iszwy4mZstAS0YR3Tc XAtkx5/NBm0YAi+RwQ/QgmyhGRgEAxKAgX4czH5MDNVRAHKZ3XMFwy6M3RGKQX14ACIY/hAXEIAv QAEbsEEvlCcl9G3f9oIcNIEKjIB7CiHBxKcYnAAneIArcEIldMGdTJCIIA1NfohY4F2RzkjpxSQh sswG7MGHjRB96UlDeNepCcQK8AiAldocVohEiNRW8AyYfElNiMELoOjhaRGMsBEPpMkRTEobmkDr 9WUNTWsGbMALOMAwNAVR2snOeIkAKImLYVSS0GWLWACCEUmP4AlP2NMPrIBa1AfGihUg1cWrnMrH jixkaqmXko75eVJjiN+wMJzukE7JbmbI0axc1V/9AaNgwR8E1ClnkiYmySkElGZpvmnH1cohkIb+ QUtq0GYqbYHz+J9uOI9z3BIvtcdx/j7FBmBtKwlBMbgHGMwBFxwnNYEB2nKTQHZKfvwPxaAt2prq c3UnEqSBIIyABxDhB/zBCHoAEnhAEcAqrP6t35onGkhBe1LACahBMMDBCALkr96ANLiCGFRC2wgA nnCvqaHaieDlgAGNiOCTWJDbHvwaTogFCoTF4Xkh4iwOCCwARxxehvDEGE2rQeDXyJjAKHIeHiYb TazMUnDCEx3eQRkE5GCRzbCRjWCJASTAGwsvjLTAICwAwNaNUDxFzdBICzhJkihEEZGbA3BHUBgT vSrF4eSJI24AF3DKfJ6AH4GKF0yBqzDmleZi6BRGZB6AHbRvnbqv7SRjMkIAw3lp/sm+32SWZhTA X57WaZ3S7FwJVs06RgFzZhTk6QCXJg4kIwMgo13Jla5MwBasqbI4cJ9S8P4lT8wlrfOsmS19Fi+1 AC20AJ11hcCUAC9xQSngoyGUAhf8W0POJ8PUDz8KZMWc06q2YBoM0EPuQkOmwf94ADSAQRMEKxNY gS/4AiXcQ6x2dN/6AhowQXueQA9wk+J2yjZxUxV3wRF0QYLKF49UENHwRFay0Hp1yA8IwERBqwN0 QIqtQFlI1BoFyU6pCVZkQB3kCKqBVwCMgRjU0As89XzxWkQ4QLbSKyT6zBePlEN10EHUjNyxkQWI QZrkUyp3jT1NVN59EZ6gEU/g/glU4IiPQIWxAoVXCI4DKUAJcIIQBkEQwPKNCUZhGJKp6GIuj6yX aukvH0AAs+8yh9xjj6n4afMBA4Y2TwBm569jzOk1h5yaQvMBvGmehvZjb3NnelLJinZfrKkZzEH9 YcYWHNZhHe3y7N//zQAXzMEMLI8tWUsptMBvzzOdGcIGNA9tjAs904IhwMIczAGv+iOnCKRI/moL c5M4DVcregAF4HAwPEMwGNARfkB4f2c3tAEaaIJGb0J58i0l4KCnKiQFfECAdAoiNJoaxNMYjMEK cO/iYIhBEAAFeSLF+reu1QwmOJTMGMruGYQTLF4jn2i9OgALYIgiNl6h/EQA/rCAS0AIDaGYVNYQ QiyNHYHRU66RCBxFV5RAs/lMe2hIGGzE1AwAB+SriCjAIqxRmuR0JAIJS+mJzyiAGxsTjkDYja8R GzlQjHGKwUDfCdzFG7wBCdRiXqQVIZWOlbYvMWd5yZYmA/xyLjL2MpPOaKssDgDwM4sf6QgwMkYz +oXc/G2pJ2H2m7t5Mir2/I12actpYN3OOCfLyZnGHOjB/jW3HpBBKRh6KWyBPi+6btACCyg3vgqa EOAzLaxAjAkBLUjCFvz1fhhapxyMCgghCpIT25qqPowAGPRACZRAD2TsDTABQz8DBYwAExChD6zB DajDCaDCrN6DL9xDL1CC/iZQwhPoqg57QMOg9NQpu9k1wxFkgghgAoQcEY4kgJxgCLyNkQNJVCn/ UKuBgMsQilqLlAW8KAiQiB2bmuuKQAIsRVWASAAMRBhcgkOojeFkTUFML3gh6YcswFDEVxyPUIVs ABwNtbh/4iF7F9L8Woh4iAE8CEgZSoVQRDNxBbwSvAJwgfPN5yteEw2ICi6GLDGrlfXhMmR6KcrP 351CAGO3fAIT8MniaZg3IwBvOTEnhsgJs5uHnDPPVa0oMzPbih2QNsubdmhPwAFwJvwxAGeqaWdC 9hacQvCI8ykcT6EHetI2tySQAW4zuj477XGyQHNHCxcYAT6acCk0dw9c/lOheSqvDq4H/I/co+2q oq2se+oHrKIe6ZF7dt12ExATuIVanEAs9MAnaEKw3wOwzyoqQGQ3BcgAAVBAtpMYZMKYzEiJxMRO 44gxxYQE3WXDjxAH0WvJLAAmQHKIEPjMwDG3pr4FDMDphwjR1Eyzwn5TYi9TYFhJEIrS7NCXLIVS QU7eVZXl3kiYNIQhm4y+bcC0LmjcfWK++vQgsNuMvMM7dPLxF8XKJNTWVIohvIAQ/HWvGsyS95Fd kM71QQARMEAVMMD6r3+WY7mX5ikDcPMBMLYxC3Nj1ymWs/z8DT1AQIAwAcKBCXYODrTDwOCBKHYG EnQ4McoBPHbsXJy4/hDHxIMHOlasOMFixowEJ+CIMiEKjlNRzGyJckrmlglb5pyaU2qLnhmlSs3Q QwYol1K0rNEqxaLUnDlCcNLiIhXqDC49QiVRESeOCjVJ1HjwwCSsWApnd1FAgiTt2bNlT3z40KOH DzAnmKigECwNBRUemjQJ0oQJtiGbNPWqhUoWlK1q1Izw60HvCDh6KehzBUfamDECNAgQYcBFHxN9 EjgwYWIBiAUGHChQ8GL0Bgs8HHQQYXsBDwMiHDjYIMLCAguLHAyAbeC2gQUCEoAwYEK4AOMGnFvY bWFDAOa7W7xooQDEJRAiBCgw8GADiBYiZisY/ps59tHBLdAHYVuE/msDtlUzwTcHLLDAAQPUy8A4 A/NbzgEO+shPgQcsUEAAHiq0kEDsFuhwkR/mCCKJEU8QMZA3AgmEBhqqeKNFgYhgAAIiIKhAIBlx vBECBqKQUUc8duxxIQYmYMAkHncUCIKLeJQRpIGCJFIkg0iaMiSEKHIISpDsOKCgHoUkiSQ8QCrp opQ6woGlNW2S6aYoeupJDz2cKkWSoiRR6ihDpCLDKTjvnGELSWSaY4YgAkkiLxUY9eCEE0bQS40b wLiBAkF2EUQfttYKBolg9nKLCUc/8KEuuU6IzK0RHm2ihya8iOWQepah5AkpDvEiDg/UcMsDOCiI DA5XdqEGDjgq/skEBQ0I1ICHPhYIzjgHFogwA9wMGGCD6WBbQEAEHOiDuQVG22+02wzMoD5qLcAk WtiuZQ7daLUDwQINApDNAAHGa+EBFh4YT18FRmsBQfHsrQ84A9xTwEDlXpNugwfO42A+BMOQTjUL OqivOAYr3PcF35gbJgMQBAhuXxBAIK9AA1goIQkPvEjiBC90OfFEGlykgQSfqyABRgaIoJEIG2nM sYocGcjRoB1llEhIIw/w0uqFsMbByCIrKoikkBzicYKDEDqIJYdQ6nLqijo6AKEvGxozIyLTXDMK PFaa6c2ZepqjJ57m0OPOQI86SikuAodzJ1r0CEKPLXrCIYk4/pDxatSZxQrrhiTEuIFYfXbZhS1N KRBdrb3S0Oesv+KiS64mxoqDgjQivaGJNXqIRYVYanliE1U8QAKMEXp9i4kRPEBEr7TUEEMaDjTQ YA9meRiAh97o61bB4NStvrd3M9gAw0VYziMDah243oBFLDjPNuzOF3AAEwo8EDvYCOxNgXxbKA67 llvQAhbIRj3q6Q98XqCeBWjAAB2QTgPJg5wDNUhCxIlYg6hlHABxRzoWeEEHTGCAP2QAE+0ywBgS qAF9GYCB5OEACH5Qgg94YGZ8GNEUAjGFKfgsEC0K2g+FZiOiVaFoOrKRjpr2tCKJyUtN8lKRdmSS i0yxIB2p/uLWyqSmsIlpISIZiEjONiWSBKlqE/Fa3CxSNTw0aQJTvJvdJnAKM6wEB1swQ04CJ4ko OGUOkhAKFyRhlMP5bVB2egmcovC4QCADGZP7y+YoIxk1fEAIH1DDpjiVKdUJQi2qcwsFRsCX1ZFK Lh8IQqUYBUpG2W4NJ9CdEaSwlxPEQR+Q8SQcPCAZVwjCFa4QQyXG4IY97IE+IhAQbjpkggSoh1rd UgC1rJM+2KzgPNQCzrucQzIO4Q82CWCOA+CDHfnoC0MsXEC+aCOA+/2mZQqQgAIENhrytKCD/2HO tjDIsP7YJzujCQM1+7MATHiTPAtIQIFSwwILUKcE0tHA/r0KiKB2slA9IHjBHzxAARoGgQZeyCEO IQBEkdLoRkYjQpeI4LaC4ChqXjMSkQySoyJd7aVYo1pBtrSll5qhiUeqiBkGogizxQ0hWFpIlQ7A Iy8VlYlkGgiRMvLGvK3pEKd4yQQCp4eZZFVwdGqKHuwUFD9BrqtaVckpQhGFKiADHknQxYg8cIOx iEUsNxBDRpEAutFdCi0UeMbsztKXzKRulKTqgVzAIJYRIK8JJ7idY72wFa70yhWrUoFkLqUPOIih DCv4xR74gQkTcGCB8OlAOfN3oGvlQXwZkGAeVGO+BbDAABkYQAsQcaBtRWsRzimhAzKQHwxpk4Ln mmC0/gJgAXoajGAW0AF85BOecKoQPhtoITOZRZ8Fbos8IviBCPZgTHA6jGHYyQ8HR+PNCf7AAMTU gAhewEJMqMdZLWNWB2zgA7me4C41ewMNBPJDR5CAiFVQUpKaliSjdalLbkvqSmOK4KdWMakZ8YhJ BOIlIOG0TFCdYtgyrLWyYQSpZsCSmLjIRJLEFI1fS2qPJNKRsbEEb3KMgt7mZBPBHeVOggvk4Pym OD2YQU1zOgUOIJAEGyahkTi4wQnoegMfCEEya9nFJdlSuswKAlSq82Rg3RIMT8ZBDa0Lwgccyygl HKIJNutBEKAcFw+oTg2Vrayq0iIITpThBQ8QgAU4/rAHTKgTe9G63oEG0AcFqMuDwM0WgkrgHBBc zzcbMIEf/HAgHphgAAR6wQYSdKCDVsg1/VFffWTjHv6dx0L9Cc8DZCMA6XBAPgx7gQBsY7A/G4I8 /1Mng0TwDgO84Dzta0EYRFDdBYyCNw4swEEPaoAEqOu5D3jBIngAT/mA2gYfAMOIVkSDHU5hDVXw GdBI8AYSEHjdRCCBjI6YpAosBAIxwFFS8c2QlzakakaVEUQK0qUVu40kQnVw2sR0xpG4DapiWokZ HG6Hh1QJR1jq8MKhdCaKWwkhU9XDTW5iVSN7Nay0UAqdIKcTrX58bEOGwAmUzBVHJZZXcU3esUon /jp97DwzZ/GkPgSR18WG+VP6iNRZgqEGJJTZA5R81BqMYQwpaCIwjpWLEkpwAyS4gs515uUudwGH P6zgQijzpgnUo50E9KHTxdk0CBbhzWx6sz0K/CZ24rst2AygN8npQxjkA4IwOAeeFrAtrgvkGwMt 4Njb8o7eG5bq+qBMNoCX9XJ0gOwH/maFzaWnA8JQhs23TNZhaLYBmN0BArWnZSwTQR+uJQBD/GcB G4jZKU+gAh2KW4c6BCK7ISC0GR14+MNPWo2cVFOGQFj5K8YpRqhmYbVd7SMBT+pQwfRiIqHEbFgy 8VDPFNOmLXFMSSUT15okEqWCbWwrWdMpJjDy/lPMqRSnGBxQcjyTOX38FAYxw//XIBD4gA/EAsrk Kq4wB1gwJZN8rnhUpy1kp+e87CwWC5NAZS+IR6N84ANSwRjsoAmMgRGGIBUcqwnAwAdKoAT+AFio YTMqaxd2ac8eQAJY6D6yxTYojdOoIzgGwGFQIziEA/AWwTiGq4E2AAidQzUIBAid4HycIwNMoGUc gACCKzg2gLSC44BuIwAy5jUGiDzqyTruZzwQxFn2xWBg4wGY5aF4AAXEQJ3CAEMU4A8YhIGwYwNw bRQaqDXsZdSYw5s0BkE4pA8ModtmZmY8aoeqYNx8iMAKjMBIKmkOIEZqZEeO76X0Dd/wbSE0/tFt nMqmispqqmbfygiNRoJIGGJsrq9LFCLFIK5KWlHF4oYhyASmUGIgZMwkmMj9huyq5iQS9GD+TgEY waoU9u9xXGL/4GRs/m8CaEAX+EAFbKaVcqkAzaJ0rKx0jE4fxCwznmEC3UIfUmccVYdRPMXogkEQ 4sBTKKBV3qAHjMELmoARmuCR4ioFheAG1ABYNqN0eIkbDKacOuB9XqND3C6DsIMAxKfTClIDBkg1 CrI9qCWEUiNaXsMI5aM4aC2BKkSgvCk1ZoM4NiAMWKCDAuAFaMsANO+AAMi8GEYAOkA90kNfNAAT DABDyFAETI9hTkO58MMlDaQDPqZCfmAB/hTAgUqSY1AgJRfBDxaAC1gA5hTFZmjgBE7E3H6GwByB RUhqRogIR5LGpjgsRpqG3jSxIPCtIGqxFLGGwSSCw5IEqc7o/AzixE5sidCmbL4PSwZiFsmPxciE TFYCSmYMS0SCp1ZiyFJi/vgvjo5REpRxC/AAMs2q5QZTANWBD6ryUcRCBRCBV1SA64JhF0ZTMogH ysARMyTwk1TnBnqgktQgDT4lM0ZgU+IADuIgDW4nFRqrB0YgDkaFCeLiA5rgCMrgVyjgBTlBDG4t OOwwO7BjuPKjY+5QBjSmQKJFOK7pJu2n02JjOsrpP+CJ2Mpr9ULofxwmNlxDQPYlO71D/jZEwIFG g2FqTQF+gDwyMtm2ZTTUiXwI5jxgQ9HKpe0IpD/0TiMtIDXax2EMxAFYxgG8yQL4rgM6QAikkYZW JAmmIAlQxIfe4ByERt1KSkaExmiIhuEYbPmWL9+qBi1TMS3rEiUcDAJAkSE6oqZKURZ1lN/KBo0g riFGoi9nasUC8/rUyBTjBsVYwgwUcwKYNP4cUw8igRjhb8bsj+VYAv5wYA2mYAD5oES0IljsygHT AFSQYFXg4AReoAfE4ngio1ciRVUiI1IyquluoDY7aRyMLlI25RCG4FFepQdO4AZGJa4c6waEQAiO IKPCDg5KgD3upe8ERFogckM4pEBu/uu0oqUPXGCf8iM5CqDTgKMigyMBrqM/FECDpsOBVKM9iDDa bpI6sENAkktfLjI/2oM4GAg+WOBCFtS8Zg+6aktdmKPXXuBTL/JcIsZeCIQ7HIZBFcD0WIbv2HRm mADOaICjAsGjWuRDUcRFDKzAKFGIHszBYuRc7SBGmmjf0LJqSGJFWRSNTEIU0RItE66MFi7FVGyJ mIoZDaIiwg8vi3SmajHFhBTi9PIAXpFJ4U+OjhEYI6EUgNFKW25sikwPkKxmvKBmqlJR1EAFwIAu lE4cN0UcLQsMSsAHPCAO9NHo4oB45IIyMqfpNCpMw+x0eoV2FsAK9OKwTkAJ0Cyy/oSzCeTiCIRA DIAFDkTvJuljD5KjOJSD027yIlMjD6hDAXDjY/7jCCEUuKQFBBDNa78nPzoEQAXvCF5ANWaVOnrD PcA2hPgjAEBg9rLnDpsrDw6quvKDDLkrEJdDPnhgP/7jXC41Oy3AECikQBgIBGIyKDumA2KoHlXg A6KABlRARf7rDRzBwKbAhxzBRUhqFizREmkkBmqkRY2ELCUxExliFEsxqVCR3/rNwSbCFlvUXVt0 xVCsxajEI1pMTFARL2Xx/BigI+hyd5V0xiDu45jUDE4hBPQgBCJBEkgBYs0gByYgEkIA4iIBDyo2 pLa1ZmzGWsHCA8DgA8QgM0BF/swIC5QiI67UAFT0gnbE4gNKoAfAgGjR7HxnwAgUoAT0wmRXRwX0 wQNYQAo+AJQGVQV8oOqYYFQc63ynTAzUwAe2RUGHozjsxwQsTVyMgwhVow+oBQqdA0HASUKl5T+A sDdS4yfvxwFcgGzHBzY6ppnyo4Pmp5ws4D23BQRY4IfPQ3B/gJ42gJ5QlbbkYwVqbTjKloCwQzlg Zre0o1ssKmEKxIF+oAMWoANYIAxUFuYehQ9iQdx4BkSrIGg6N2iARke88lyr4IiOiCE4kXadBMLw 7V0bgnXdtUtqsSJel3djSuCS1P9kMabaiEp+1MVkjEpUsfxoscXKZsbE5BUj/sFJn3dOslcPqheT ZywESIEUQoAZh0ytAgEaYc4LHlgFyMIrvCIz1mLnOAmUImUXIgV5RiANMkofJlcIeqAEWEAuhGAG XuADnswDbCBmMqrnLisykOADCOAH1qIymEBQ50JQmcALDhUFZegFYGsArKdAhAs7+mADMkBddpAH UsObC8S2LIAAZCADEmCAbiMmFaDTBsDw5mfRYOs1bGOfMcEF5A5sX4Zl6NM5nlM9AuAH/ikl9044 /OMFvMUAGmoRQC3VricOlUsB+oAHBmgDWiMDfmAkafhAFuAHVmAQ1KOB5MU5tviXaehmYuENvICM /4vdfkiNzzj4go8EyLIC/jKxjBjAdIW6FE8UqGnXdcsIavQNaqLIXc3ASMjkj1tXd3tXFd01eXd0 bII3jVaMSHLgkd+VILBokp10AkI5Ev5PSs0AGKE3/qY3lJ00B3IgBOgars0AequAD3Kmo4pZLJKg mOGgZEXnlT+peM4iAmUZCVhgBqYsZesCDJggAklWsC7rL9DxAxogAUoADrYOTyc3MBorFgZ1OOWi BIrS0j4YuKZlQfgZuGRAOMTZm75n79Slnn1D87ZFNa5nABoguKajnFcDnoEjhLgjObCDWmZjOa5j AVzAOyz1PyRGY6KD1wogt0n60HgA1FrDo93Df+4H1EDN8LYFCheBfjhG/tryAApS8LCSwAswNHN5 xmdchN0YgARm4YeIoMBC6lytxt4OYN5K0UbKKKX0GHYHLqqL5EVll8OQ+pHPz+KAV8VC4Hh5V4sa 2cJ6pHcLNhVtl2pIgqckeXlD4BRyIHql1MS3t5LjyKy3Nwf8rxkrFxqTYEXqKi/oqnM4O3RCB+ww ZVVkRzJUYBzcQgW4QAhM5X55mZgjAzMk42X9Yk97Jb034E73dHbgAIJdpepU4AZK6QOOoARU74MX 4HwYkrj20J72wzeYFX04CEPawzcsEtTgJQFGZgFkoPYkTQFMIH7Srj1Q7X4EijoGQG5XoASeie42 gDoTwKMNwAYaIDe4/mO3UFVfMtgQWsA4VI+cE4CDEz1aRiE3lkmLX+MHEvjbvMCGToCm4zu/bTpG quC+8zu/97sCvjKJGGLeGCIGgNreUuq/29VqqCaQjfoAIoCqXbepbX2O9W0CFMHFm+oAXDyNsNfZ q7raC5arqT3Bn53fGvl6r1cPSnzEoTcSqhetJ5YZnRSUX3HGIGBb9ZoGRqRQocwDbEEsAlt0MiVT MIWTgOWT/D0YguEIorIEbICxjRzNPvYyfrPJz2LOVGAtXuEHDIGvPimUtlwwXqUJwiIuNrAJxCCL pe1AHkFsqWNb8mCbNq0/hCNVTSAP9uAiCzJbXKCbGEbvnskEZAA2/oyJOvKj5E1voezHoO4JbEXY AsbAOx5GOTqmODpmizPABRSAAAbyDhdvm17jafXuCDugAFQDBAogPxZ9JBcBARSkA4zgUJJgDZRs xqug3NRN3bLSpoOvvsNVXOHtjestqG8dqf+7wSqgaipAEfIYdol68MkkAtaySOaYLlExiWYK2t0V 8SF/ArLdIIpdTI63kZVqjdCI84WX2xWBp0Ac4sQdrYeR3Kd0rbe3k8emru/aS8QtUbI1CHSFCbic mInnV+Ag6HQ8dASBGoCfGiiAGryMHPsiDVhgCIyZBWwgLjx+rijjTUGp4dOAsyngFUqlLVaFAlmH aEf7ySQYBUvS/moNyqAMxDSMg4O75Z6WI1ap5XoMJFumkADWyWu1ODm8uZlK46CoBQVKQAMAYkAG FyYMgDBgYAFCBw46tHARoMMCDQYUhFHQIYHCBRYGDJCxAcSLBA42tFBgYIOCDR0UGDKQgIcCFiws KATRwUAHFn0KOKhYYMGCBIZ6qFHhIQmNpYGmvDlHokrUqSQgkKhKgkEVIlqJQCCyFQIEBlwZxGBw 4ECFtDEOtF3rNq7cCWkZ2GEA4cAEtGnrRjiA58DfvQfQ4jhgR6/ivosV032sOIcZBnRzQJ7wmDLk wHgoA9aLmS6DwJcVK5pwAbPkHJEmRMqhJ1KI2JFIRdJjRk/o/hBm9pr53RsCDT5JTtA4AeaEBzUe mny4QWEEog+I4OxCsmuXIGrSulP7DgcOhfHkySNhUYLJjB8lPNxIcoOJByZqRlBQcV/NfQrB1ATr MYA+adhHwTPR4adCgiMwccIHTZxwA1JMOOeDD0LYMMoAFiRgQUIMxbQADx2aoNBCGi3gwEYm8LCA CSI4YEEGPyW0QB8IyOiAiBbouEFBIIgAE4wLDdCQAgd1mJAFILRgQAAiAknUBkLpBNMCCmjEwkgG aLjIRjl24AAB4QwQEooJbLCBIUI1BJNHGWzwgxBNJBcKDUl4QcMbVTgCVRVSQTCLWF5ZJSheX2ll FV4VjMVV/lpw9dUWEQcQoQhjbTFWWKaMeUYXHhFEYEYOB4iKVql0jeqYYgygNcFfo1IWAWmikhbB BKLmwClgmOlKWa+FtSoaYaEpZsYFvRl7AG+smRFJs87qwZtstgK36xlmHABBFTRMkcQadiZBX3Ni fODBeB6U8Yd12FGDSDOZxNNMvNKwC4crrlCgXxyuxMGfDxDaQMuDN7jngQojGBwHHHHYV59+FCBR 4cMGk1dfdOIFM0JzDUJ4ww3IfVDhByx0AGYCBqSYEkInG7DIjgOQNBFDFgBpQo4NWdClhww5YEIG MmawQAYK/MSQhyobtIEBHdo0owEi7GgBQxEVfbJGKbG0/gB7HbjQAZoKlNh1QgZwwQJC6LVgiEYb WBD1IwMsULbbYXgAxgdJ3H1nIDRU0WdUszAQKANZrSp4FYiOZTgEFYRV6lp8VWCWXJK3dWlffGHb F2GW1/qXqJbfpWlaf3GuKumV6VWr55YBOyweu4ra6a+asaoXq5CJGsJpxoY6wWyzOdusbcxiphtv IUxw7QSkTADBFFMEckIgaySRIBwqiCGEeyoIAkYYLyBy3S7SuCsAB/PME088zDQjTb336qffxPb1 UMIPA3vgxXwF24ffCPlSUK5gICFf/ovOwfgnoIeN4AMMdM6DIASNE/jgCE0oAQs2kAASKe1oCTHS Bnjm/jQkxQRnDCHSAoCEEI4IJUQJGABBWMCQBjSEIyYoAAiMxAIQQM0mmMiA0jqUIgdoKAAZKECZ ONKBG7JEBCoxgAy7xpAi5OhkRGrJD1SCkQ6BAARd6toP/JCAIpSgBBBSw3GkJ5y90YAEU3BEFWYh lVlEZXFY+YrixEKWsRyqCmfJi1lKpRa2MOYvkLtcpvyYllNhrnaArMuu9nKXVX3mVK3iC2oq4xlP oYZWpwMNWlynF85MsnagIeVjIJO748EuBLBhTQhuQwpS6EY1OfCdrfTyGzssxQtJeMMJTpAE/7nn AzZACr5+MIAWrEsamfgFCr6QvvSd7xeV2M549FGe/oIhIRglmIER6MMEONBHBdaDX3nGE4yH6cN/ BEKKeACIBAOCoQQ2IOOcOpaEcUnwA/T8wYkQMgASrY1oNeyD0kokRIagiEQOMJIOKwICDdRsImii WdFEgBIDvOAHJggHCHhWEgHY5GQ8AGnUIBK1BYTkgwr5wY4KIACVeI8FIhhA1xKQkx454AcO6APb tAgTE2QwAQmQwgaGEIQT8JIGa3jDGvN0Dq9EpQpWkYpVqxIorP6pjgwoZFcNV5hVOW5TmAqdWRWJ qVO56naVsmQiYXVLVQnmWokcjGNqlRbY3ep0t7xMqxYDGVbVKgTHc13vhtesVzorBJKYAA4gcIpm /oUKD3ggLGYYcDcagEEFNPhAHE5wsBssYAYeQMQIkKCPDjTAEK7YBTX+MY9fxAN9s62tNDHRAUHE 8wQPi8M20xCMNNBvf0eBgxrUcC8KJJcC+tjFeK6zTubYBxFqiCcTHgbA+i2gAzY4gsfEoBwGjctB ImNJGGJUgJp1SKUgEEp7XSAAgxjABCDogwM+ugAQEIAACliEC1KUByIJEYhWiwkINpABGaxIICbo w5QGYBAIY4RFGBVBADL0CBQlDUgoSRqYHJLErxlEpRZg6dBMsDQemIADHdhQAYA2hB4k1Th5msJV q6Cn5m11q4oLy6K8wpU7dnUshOtqpghXVrOy/opUSS5rBCo1AUV4bq2uSqSVowwsxlTqAlcejF0X A7tU8dUdlbkM52LXKt7ZCjOtkUzwZAMtPeDGNWewzGtqaQY8+OkESDkBc5STMTD4YAN/SMPDSgCF BphAGq7lzhfccD70nW+285CHPPaAU0M0YQQPAschUjGDIRhhA0pAAr+Uy6/kJhebuxCgc5kDB30g wRXp9J8tKLALfl5RIlmbQQkcJIb7NaiBJRg1SyygAY4ozQGjWJtGcGYCTFhABxXZw0+iZoE+JOAF Oi3R2hy8Mx4gDUY8W8TJMnCEgR4ERTYZURHvGwCFssQAYfBBC8AkEnErhAUnGQTR2E2kMGSw/mgt /qFOWKAEu3nBOGsQzhT2JpapWBUsfzIcWLwSOD0GGS9FLnJYS1WqthiyLrRrZOYYc6oQRAY0gxEN Wo6HqsdwWa10FdWX/6q6uwILdn4dlRnwesozh4p3p1hdayLBLFLMJgenkIQZYinLCVQWNlKvwvN6 oIIkfCAI8/nsDwwxHySIfQMIIAYCVoAdbjzgC9CUZqQtbelH7KEALZSCFBKABSjYHQsLKAIUwE6B U+vDFdgsvCCa+4xdYJMC4SGPB2xhn2DsgglH+EEHXraBUWyXBVwYxAeQc4M/b90HH1ACF+SbQQtI JCYc4ll+iYQSATwtIRtQ8U9qIkSfvZhI/h2pWREFQiSVJc0EGJlRRgfwDj/8+8ARQWICuNiRlWwA wgoemgFompL1woTeTxPRiFW/ARt8YJxNOI5TIbAGHl81KmLJVlUY9Se7cCXIi/I4yAEpyZGb1TH6 F8wgK4UqKvdzpyE6lDQqsRNmWpYDUIY6wEKAlAR0e/EYnBMYYfY6B6gsoXIAvHM8ruEaTFcbrYEZ vKEHZwAtk4U8jkUDusBLPVA3ygFANyAEDoJOPjAAyZAMLnAE64ICv/ALkQaE/WBp5zMKCaB3sFAL RVAEWLCEUPAEescCTWBqCqNci6cPuqUPz7B4I+AK/tMw0KEfSIAITOADKrUAj7ATGbEA/jbAAkPw HDeQHMshQb8GMjc0XySyNAM3FBmkIS+AIkBjEGGQNDMRUzozEA4AQwTwEwHFAzjCMgKVIiKgECny YhaQB3iIEArwAhGhE99mAUwyiPG1ALBnABlgMijRAfq2JAe2biq2E5/3S3bCFA+nJ3oCFmQhFVNB KFWxKCRABCSwKJADFoszf0bmOJAzVnxxOfonLJaTKQaYKp5DFyoHLHilGHgFO2ixgLeCKoqAV9bY SeCIjQ1YGpaxV6ERAao0gmvmga4kG9JijkjXgb3BLDiAA1UQCMSRBIHwIFKYIN30HhLDAmxACHWQ AaNADUhADZkwTdE0D/0ghPJQafTw/gh6VwywsAnFoAqaAAtFgAZSoAQqsE0e4AGnRh6sdoWLBwdc iC9iUC76AAdipw8fwBIYgQVexAUYtAAlYAU7AQYeMGwDAzIM1AMX8gMskEUq5AAccjIvlgcnEyY5 kgF5gAlP6QBA8zQlohBh4AAuwAM9Yl8uADMJkAEFwRHZhiIG0AcysGyMqBOG0HwCwV9N9AIK8DUK ADQXZJcaFERRYwCGsF4wkiYyFovGEQRvoDd+QgOOQANVdXETB3+MUji+CH/FWBb593Ga8kdyoYx1 ITto1WSuci21ImUEeC2SRCoXCBl6USlSljx5dWUr13NlFiuOsTo5gAe3yTvmuJu3/vE7SqcHlnEK x2NZehECp2AGipkExPFLN3AxGyAFVvAB98EEcbABhPAKhdAAIGAD1CAImZAJKPAubiAPEAl3o0CR mrAMtQAL3/AN0RANm1AEqoAKTGAwCUIf6XSS10Qg4yEeaiAe6/Qwu+ABH3Ah4uARWKAANgUnlrd5 HZAH3HUCf8BPzwGUH9ADNuADg+BdYlATGbRdB6WHPGAyDrAIGYAzBvE1GQAkLqQh4pYSPNABItAz HmFffxhEKSIiKdIhM1ojprgQAeBBK9EhXxM0RANSB8ZutUd7FvASHpEShnAESXECQTA9fOAFEBAI b9B+VJUVV7EVePGLekQWuBiM/mKlOENGOJLimXVxFoLROG2aVqa0KhKIKhV4V54hGbXCAODIcqGR GWmGV4qgcuKYLP53jbfEjWbWV6ujGux4m7YCLe84dMQZCWfQGnW2jlGAj8dRHHFYLkwADWgwCiWA BCIZBE9gCW1gDnIwAB6gW4iAArPqAnBHD/LwCI8wCo/gDJSgCZrwnr5QC/VQC6rQA2kQB9elDgej BtdFHveyXP7JheSkAs7FkjSpQjc5FFaQAIuQAHmgUiQjJVCQBxtQAgMzRj3wAeNSAitQAkewrsS0 EiiiEFGDMoZgol0SNEqDQo04Mz3VBxOFEDOzEoH4ohMlMyJwRQ4gA2TyAmVj/gEmEFAlIaT62lBu EjU5IWJiU4qLuCNSsqAEMFpblxxL8XDCsaV+8gaOAKZiehV4RCiLYkdlWn9lURbCeGT+5yqS5Jkj 15l8ERhyWnInZ4CKRBp7oY2VQYG/Qo21khqwWRp0AXSKISsHyClrZo65+ahaaxmvdAa20YHHIxux FAKVpXKSgQfDcRyh8DEeIB43wAI9oAACtE0zgAFy8Apt0ABQwAWohQiZQA/04AKDSw+FsAy56g2/ qgn3QAmb4LjxWQTGkAbqkAYJch8eEAzP0KwFRE6Mx4UrWTHZZEFlQwAFYFQ/AAJEVQLbNQAI8Agb IA4dsAh39zIscAJw4AMP/ut5H3AEg0CHNsAF71oCIGACLjCJRBKhphgOLpAHNnMyVllSJdaUMjIA IpI0A/aVHTEiDpAHKCqjPlURKSU2PRIACpE0CSECB3YRX2klClAQ1Xu9JrAIXOQAUrAAtOCCHwAG NBAES6FGVEVV2dJ+eAGmV1EBvlimN1sF9TdWmcIVoBNITQY5byoXT+aMhFGnmXQ6tmM6B7gap2Iq esGblhEZP5dyxkmAiLqNp6JXMVdmlpE6WGsrR/dKklobvvNKljW2xMnDzOM8fNADwMRAuHYDPmAD SnAD43BrSAAFeCsHBMAG7DAHA7QBfpABAxC4FvAIyzAAUBAN7bmRv+q4/ptQC4cQC8GQTvIxAoa2 H9GlD7agD4hQreWCBLzlAbugBjfAQGFgCGACBa07FDZRAASQADawAKPAAob8MgtgBULRk3AzAmAA BkcJB4OgBkcwRiUwQRn6sCVgADxgAxvwDhrBA2/jQ1siAs2LIhSBMiD0QQkQBmITNRC2AE5QByiD IoKZlRKrYjViiTbBAxHRokCjATnBRE2DMxdBeyDwA1xgA2oiBTNgN/uYWTymi1WxKgs8FvXHcYoi ZETAFYuiFnawFscYwXzhKhHQp4MEp2kBgKEzKw2IKpaRPBF4gLEpdbYJGjK8Sg/IZYdqV4+xgGJW SovqGJjhOoYVj4SV/sOEBXWF1RsdiDySgRlpdDe/9AG2AAcd4wHtwAQjAB1I0ARsgAE70AYESQBW 4B9BUAx+9whE9dJYIAWwAJ/x2biaUATlcAgqYJ9pMCBM4NPYhBQFY0D6YR/xhARg8DAigwVwckF8 JxQbYoREVQAIQCYeoRFuE0YqJSWbVwIj8Af85gNlIAY+AAZKgB766wMssAJ+WAAnEw4T1SE8sAgD 4ARXwhAysggMcWAM4QLhADT1iiICkW0lgRKljIccUVIFASNvgwkltQBEJCMIASYhkb4pk1A8ikGG gEHdUAQs8FmZ5b96clW7CCiMMzhnMX9qASiKUxiNAjlHJimGdBYU/szOVcYYXFZlq5ll03ioevVz GogZZLYqmoQreqUZj0qO9iwZpOR/1diAU3uBMMzPvTMtiqV0YEuPZkCc3H2p8jgB2vJwxgGUYHBr NyAGkBchSJAGG9CqhKAMbYAGbYAFKhAMRpAHnt13UIAFWMCeNf3F0QAFUGAFa3BdwWVAI6DgCk4e /RMH5ZJ4abCSHyAIOUkSL7Z6RPUyq6cQd5cHOJUABeARLwMTHfDHReARcLMLYlACD/ACN1AJ49ID 9KMER6CumBwGLVCXCMEDGnCVPIMJBPAAC0UkGbQQIp5QMEqvCNECLdQzLsCIIcKjKLLXaZkyGRAA JZYmIsADiljK/jsDQp58MvQKrj2AP2zbmI+VflsRFlgxcW8UppZZAb9Is9iyOG9a23/0KIGEzv4X A7g9OorAZcVyLZVyZrQTZr0BdFImm3ZKGsltGZ2BmyKMjlG2p6NyGmulGNSYSKTxKvG8GepYSwzd O7WBqcbTKbWkdMSpdMGhLUrxSxCSMffjnPxRxwkgB1pwDBiAAISAAUUghT3wBGzABkoIBfIpn/9d 04xQAk2wMApCAQMyHgpOXeOBH9P+MO5hxCXQNWjIEgNQALwmyHS3AAVQAFBAVBqeEQPw0iRTBJc3 AKMgBey+Ac75AS8gAGLACRjKQD4wBzZQBjfQru+6Am39AAqA/gIG8A5RowFKojMk8TJXKSPrVUR9 4DMKlW0rwr1MA+ZO0wES2wfBl0QOIKRc0AJP80Hpa74d8AIGkAcgAGE6MQA/kFTgohRLIRa5OEeA YpmzcHEXV6bAuMALXKZoIc55/hZxUTm1rfSWEkiV441lpUi9HXOySbUTQGbmaCucoRmOahmj0aeY USuPcS0WGPaoI5s8J89hRljc7fYNHQKkcAbHYzhxP/fcPYJ4zwDnwBQnsAa/NB8LwtFrzN4zgAZy gAFtcAydUAiygADtEAyjigZPgAbE3gu+gAZj3Li1gL8myRz9Mx7PEAyCwE4qIF3YTgFhoIY6RAA/ sNYdcEUs/gEnHTDIJ7JdDbo2f5zu25UAuKB3QzGKCKAAFCAGg8ADg1DJYDDjM6i/64rJK+A9RzAG zdAFmaABKGBt15buRGUCfkAijegzLkQAxktFb9JuDNEzBBCwJpAHJaYAUWMCNYMQIRFv4iYCNKPY OwKV+QWVDiBjSgAQM5okWQOBhkESb6pUIcGAyCyHsyDMIlKFCIQKGDE6ZMCRyAEGGEESqXDgQAwG B0oyQGkyQgyTJQ9EcBmDJk2YNE3u3Mlggkk8ICekDPpzQoSiBya4OxAUzwSoOSbkaBo0h8+pWac2 PQo1ghmqEX4eCKt0plmqRpWKJQv1p1SxIY6CDWHmTIi7/ndDhFBKKkQksBPqbmVwbkqgEzROgGni gYkHH38ojBgRDEkwK4QwHJOjDIOcNmjAIQE3AAGbAlAooXniqxclSkWkGOlBAQkSNWA8UNA3YjeF yWooU1DBOw1xMT5+2NhgokCCDo86bNiQYIGNDgsWjNrQ4YmLBdkfOZDSPUGRDGhMaGdfoMgCKAMK DDDhAA4iMSJQUFtRokePDxa7wQM1xBDjgy5KGKOFfzL5hR8NMNnDBA4McMAEEx4ZIAEDLLDQhQIu VMABB0BQwIAFLBCBBxJJTKCPDNZzIIMBHEDRwgUc2EAEBVgIwIBFFkBRAR4N2EABCxQIT4QUDeDi gx48/lDBCxqiWIOPi4ggoYqVKsioAiIc+hKCLDWqgKWUzkSpJJgYkOkkkGA6iaWdXqITTp7OOuCC nkDiKa211Errra5+8umqq9x666ms8JBKqqigUkowpRQxywyxUlILLbKamrRTqdoKQZG6cjBjL1Tv OtUMUlQFya69zAiJoSpoAOMEXD24YUAbPkhjhDSQ8AALNOQARQ5C5JADDTR+SIOJUdrwphAoRrGi HE00uQcNVIwZJ5hngANDDX0oUMMDVyhwJQ412lUhDgqSGGGXEcAogYUfBtjAhlEGsOARE9AoYBQW EkgAAYPfS6CA56YzeIMfujMggQ2loDgBLKzoroM8/p5jYYAVXEHkAQWkOWIBWgL84APdhACDEzHA GEOBPX5xgx9+MOFnDwtAAOFfigsZAIQFBhigjyQNODGP+hwQ0gkEbNyAhRY6GCBFHkwYAJMBMnDA 3wE04FCGHw0wQASzO+hwRxM2MDtHIXwIMLE1cKBhjQPsgAAChkgACUwvzwxzcMFD4ujLNB1SKU0I bIpzcTnZ1CknPSPgkyY+FbncUkVy6PyAUdMyo9OoQJ+g87cmheqpjhiANKscqHrqUan4wiOu1Gny 3KSywhrdKKqCP1UwsE5FFS+8BINErr30IsUvt8wwA48qdNHlsCCCACMJKXUdwQcmRjghmHFqaYMQ /lna+OwYNpwZAgkW2tiugEeWsR+NNigpxwsV0vgVEUTMy1zp0gcckgAcAlIgDiqAgwpuMAMLWGcD o3jBByyAAA0lwARS6EAHCAAFAhjsEQZLjXasVoAOKCA7HbBCAhzQLwLMZwA/YAEW5kMiE1gADpx4 gAjGIIQESIEWUUoCGFbmAQPFjAUC2AM/3BAPN4CAA3sQQBg2YIEOJEBgDZCBAyxQow1ox4VGcxqJ CpABGTQgAzmKEQ+0Y4EcWWBHSrKA0ywQABAYQG0WEIAIBKAAQC4gD0XowBySwIQkJMYiZGIkCbRU ARJAEpIMcGQkH5IRiVSAS5EESSQbNxI3xWQj/hWIQUnYdBI7wSkliTtTnkzCgAhYSk9CMcOmcmcW npxuKEgRy6N+4ii4/FIoSjFVMTHVlQuMxSTKzCVNjjKpr8gFLVupSzXPcE1D2eUufullXWoZCD5Q KQlJUIxwfDMgFYyDCUwIVhOgoKxeKKMTx2iDLJZhBWANAQpF0AQU/MkGQlDCCEy4zHFUMIJyEQc4 KlDDQXmjAhUE4wML9IAHlDCKhmWxA96wVgcKILQwiGMB61mYCwZAgBhaR4QLCGLRrIaAAogxhtPp gBS+qFIdlaEScFBADVzRgkUMIAxI+AASTyAGD5zgBh/wQQkEoIE9cEAAX+ijASpkATlGxwQG/oNj AWQAngaAx6QWKAABMjAdDlggAybVmgsA0QADvMCjJp1RBlwYgDD8QAQWwFDPRPC1BWzgA0E4gRcC UZA3hOlMi93I4MREEjC5aZQM4BIEKKsSkqQEcn7arElgghLQolImOnHlK2fpzE+RRRGCOsBqV8s7 P4XFJ2bpSqgEI6msBAp0pDPKT27yTKbohCp88txcknnb2EXKVMcLgV/MQKpqGm+5tcQBHwKRBD4k IXtqoICuwDCgERSnf2k4BCVkEU94OoN91wgGE4awjCf4cxmUmK8VCBqM36iAQCNQgyv0K6URAKeh wmmvGoIwhB7YwBvOKMQoxHGNDXUABFnU/loWCYCGBIzCYKMYRYoMlgALGOEHDkvAiK3D0kf4AYUU yxB9HNAHExigBQZ6gATEYEUH5MEQSBTCB5rw3ST4+AODQIEbLCBVPz6gBgq4Ygc0XLAGNOA5JiCk Czjkrx8sIAMFwCpL6dO18WDIYBfyIggudscfqBCOZnPRBubQg3DS4G52WMMUMEK4zCrWTW56yJ0L p+dZQFIlXFLJAT6SkjbBySaLxglO6JQCnuiEJrCU0yo1K5YLDEotRhGLTjR1qWXadiqje1RgQFdM YkIFLG2ZZas7pTtLUeWYoSteqZkLq+a1alSuM14tDRIIKmkvCWpQqq4cc9B0IkEdP0Dv/jFkoYxj cKYXQwhGGoaABjb8EwNPGIIKkJAGFTBhgfxtl3B+ExyGVoYJJ6DA9prwARu0g18YW9gyuNMBLHTQ hoEVRxgZtjCGMQwBCIgYxeYTxg4+Ig8Uk85IGbZl02jAAAJwBTXKoAAxcOKvA3CBEVcWoO8qVQw3 aAYKBPDHL7RgDEdYQRj0GMEwKIBiWExR0Qx2NXHwdUNacyFWHWAdp6HIQyeljwlA4IAAYBWLIAjj AqQghEOeoAcQKMjeyHS4jiBuTF+CrJhCOaY9C+6Vp0R0ofGkaJa8ZE4mYcpZSOv2OrlELV/5VFdW yxbfPpNQTRHLbdvSS6jwZSsTSCZt/s2SEtJ22iWY6txqk8kXuXwlB6iayl78gipSnOoMzqVKdKNQ hUAEggZJCEUPkoDfOZTgAwE+V3GQwAQrtAEUsjgGKJShDNpTYgjjSAMWsFAEKDyhDdw+AROCEYxw P2YEcQgvHMylhmAE+KDhFV8JimEEKbBgBj3wQRPW3QQfKMEGM7DBD6RgAiiEZwH9RjEhjfYILxcA Ddlh8XYGkB2jUWxDAGeYA9R2NBP4A1foAgOoAQpgEh7IgBK4ATFoggN5t3f7gD84gkx4gUxYgTHA wCM4ghdwObIiAPWLoLIqhBCRj60KkfUYAHrgARBjKYfLIY8ygEcwqa6xjgAAGA8r/oIN6AEvYAIq oQG9WQNHggCTyCzAcRPACRwkFBzQQpPWWSwxKbQmJKVQejQ0gbTPQjS1cwlFiCW4izvh2glA2TTY MpRO+Z2+y5S38CW5OKZlIqZAYYu0QApQmYm5iAC+8JwcSKYLWBXmMZ5IsKbmEkRUmby9kARfo4Ep UAwvICyI+oASKIET2C/HGAEkUAEsUJY2uD3au71lUIJLHIIiSIB9GgUj8IHLSD52wi+HUiDeCLCK UgF9uER74YIO+IFiCKNiuAYWsgEfAIcToIwT8IEZ2ACjCY+DQZjpAAE0GAAsWIACQAACeIRFuMUR EyMjOKFHKCv4U6kagSMTCIcB/ngACugCEQABTniB5hgABaCAI2CMj/MxH/CBIxiEQdjAelwBfByD MOArKzOY6YCjqNEgFyqr+qgjf9mqC3EhrdGaDPCQ+tAgL0q6DxsAIzgEL+ADIKQzMskSkliTlYgB PcsIMbmzUoKcNFmckAjJx0ETU4ITyYGJCsCJA0iBVbqJOpEll4g7PSHDTSs8vnhDPVym40o1TKkl wJMdvAMenwzD3cmBaOJDM+hDz0GVU5k8PbDKSDgD4/kLvXgLb5qANVDEEyCnIOCfJGiqILgB4qhE FZA6KGgDOYi2zmgD9sECcHgWK0iN9BuC+2KCG2iC/tEVASsOOOCuEXCF3TgO/g9gKu6TusH6gCGY gx8wAisYAsu0gh8IAtW7gROwgSEogQ3AAvSjOSwQQYYpBAIoBCcggB8whEd4gpgaMZ47Ru3oDgd4 uAtZAAXYBTGYGQ84AgPwFwfQlXgEv3hsqv7IwBcYg5WjwKOTgRo5oy1zAPBwoSzasvmIoBS8v4VM EesMEZZaj4kxgQBwMugYAi94g4LQGzKxg5LQnCREwrCDQlM6SVIiJSlMyVYypTeJHLODNM/aCZTA wrM7LQTdSd8yiaAsCtYyCk2RpkJhta6QC6motUkxFTlEnWDCwz0kvK0AHVTBND/0w2r6i0hwLryQ nlipnVKZAKpTDDlTjChh/oISmIEbYCjv8swS8Ki5lEtlIATOAIVrICgmkILTKIBuowDkQ6coeZbi OAHhMBcPOEz9sgXIGLGpmYEP4IIhYIEekMQcZQJitAEWMAI0BdNbkZIAKYEsG8UNGIIwwgLqqCkE aACDIQCoUT8ogA6WGgWUgr83gkYWMYA/4ASngoMyqKOg2gAKkJuPezdwgNSmGoQSsIEKzIRBqEAF EIAE8JmJOSNohMazWgACcIAYQki1ygAQaMj1+CKo4RCuCqEAEIcOKIIfYILEggA7IAL4xCxSigFh vQAviQmVOCWZjAn8xBM0WRw2CbuZoMmdnAnHeQm1a4kYcAfHmVYw1BPE/ks1udCU3zGd3Uqd0FGK C3iKtoAUVKsdwWhRpWCA4qG72jGer7CcuQiBPoS8EMDDC2CuE20V4omVv3CL5ooEykqCjDyBNQiC JjiBNDgBIQCQihKfYZwBI0gAZyAEBMAAZZCDzTgGDLACWzgBYkEDKPiBb6EA5YuDNAgGwewuNUAC hequikKEKp0BEyAAZ1yEILIBLBgkI2CBEqiFylwALJiBJGiCF5BTDuICAPGBirqBHsiyBECNDhqA ZtyAEhBUUkQhD+sAFjDG5yiAhasRNrIaHniBERgDrkWEFiAAF+iAPviDlfkDCJQbJVAZpjqCEliB F+jAFhAAE3kAKaCP/q4qgPpwAQL4EAv4KoPLzQJg3PmYDxdKABmYDyc4KxIJgO4wgmwoiDABrWAV 1hhIAdMNHNVVk5hgEyo0XZawCVPSLDW5z9dlCf0U0EXbyQu4AEnrE0vbE57gEzHciU2rJbQIjFBZ rr1QrqzotNsSPMPbiuUdtb0gHeGBXqicPOMt0b9o3kiIhAvYPBXNvOaqJdBDBsV42LJ0DA9IsNWj gBuIRMzsAChAAM3oDC2Qg2QIDSxAAhvAnwQogcr4L/EKMJsVLybdDbZEgl3wgIjJolHoABswjWeE xgKwmCJogGXohieQAo2ZAXMJAhaghRnosRnwgSiR2jC9miyTzRBK/gA/gD+jKStxkAICkLLtcMEB 0BAa7BoTcILeLAEDGIMDdFUF8EwxgAa5AT/wa2Km8gEbcAAFyKMHeAAUUIB+VLGf0xo5iqCCZKmf G2MT2DIX+BoMcZsFODq1WRikKwAjGIJY0Bv9/CxUOt3TRd2X3OOanJNFKyXQCq1mnUk8kROYxMnP okks5BM+MYXWajWaKInCS4nL6cl7NQrUmRTIK9fc4jRJkYtIsVBCgd6fkCZSEww9lDzTkYrHI7wT PZ7N24tAxIus5MqfYNFa+rxamYJ3s5UbYIJ3AxDP/IB2EALxM4KiwZ/N+FjQaINC8MsSeAI0mIHL 2JXjQGCG+q9Y/kyqKlWBEniB8lOAq4GOq8miJ7AOKSgAP4iPBGiDPsUCI9iAIhiAIjACSQQDMGiq DYhnG5iDG2CMG1BhKXAB2URG6KhN84ghKrOOIGGpPEgR+lgAF7ACQTiCHqGGHyCzDXmBXYFiHwuC NRCyu9ViEBCACgwDFkCqMEiAGDGAG4IjMnMhFxmjSXAB6WSYzEUAk2rNiEQ6NlAChrWDR+tjSEPd lzBqYcXdQBatJhTW3K3JAnWTCCiJoobqqX4JRutjO4aTWCLeCPhdnbgAzSJeOzReZ5LeWlqt2tKK Qom8rBBlDQ0MwSsUU6HQ4NGlENBQwoude528gW0ezWMVvTiV/lPIgVXwiwOoJTPQAzOIgl+Ts1AI aaVaN0hsgl0ZxhJQgnshlvNRFs9OBjmAgiH4xZQlKJYVL+6ClwYyF+JoF/7ygEhsulvsALK6oBFi qWrMMhlagCc4qQ9ywZgqj6npMSg5U64tKlwRg2K81QXIxucogoFpmKJ5uP1bgCJgmpu7vwLYgOBk AQWo6KzRoJgqqsgIaAj0sYeVxyPwgTBogUHoApb7Ax9oAQtwgYfMgC0Dx/XAAJ1GgByaGB7Iojw6 up4rTzhSoQAogliYgjWwgwNgiqo+XauOAVOQSd21Eyy0VqfWakYDLZ1IgfscappIAUUgcUVTO0jr 6gNw5C5s/nFG3klJ68KzKK7pldBSngCw6Lu8DozUoRTY+Z27Llc9fItaymsQBbxSYR4RxcMTNZ4z CEQzmOUJUJW64EozGMvrGifF+K4BSap5VIF89oEB8QEjwALhy1850ILNIIBruIFnsFEfCJa3bKDW M7d2oYCiqigmUAN4S7MOW7qsLYBJuD/0DCzojg8sOI9lSL8iQIMQYo/3cDquncQP0OwZIFqlagIS 1swFaAAC0BpT9ZdEB7hRzIMgobKroZHhNICAjjk4+IOdvZAY+YE/8IB3C8wT+ICQboII9AFoOAIW GIQPKIMNHIQwQOmJ4asCwAQv+jm++jlVh8at8pr12E6D/hlOB/DvO5qBE+DVQrPJq47JRF60FLDW qj73CkBdCT/3A+CFdr/jok53qPZdyxFQd1+7GHjxPq5kz3m7yjEL3QGdwrvlafKlH6+dC2VXEBVl 6q2lIe8cuoiuyePevJaLTNuLyTsV6Bpf5CmV8G3euODKz0MMOcOVSZzEioKGD/BM4wwQMk8AAujs Y0BzBLCCYBkBgsKNG0BMDwiw166oOy+XhDqC6vgy+OuybcwQq0HarbKOFUp0/6O/AVCxh54O6ria DbCCE85RG/APSIVEFgCBC+vhhVE/byyaq8kDo8mAPs0w6Bi5FzAAA0GjDJkyAvaBdmhMXJkbXvf1 Dxix/hUQg0qooDIogwk0gKbpYi/iKyGRdpY64whaMy8qgDpogDJ2AS1AgAEIgLHUm5SA8JkoCXe3 49RF8T2R3Q4/iaLucNMvd5uw1hGnVkcm8Qvv45m4gC7M99JyOxnnE76giU32ilvGLed9ndJ5Xkpx V+hVCosftUchFenacdqhi2ICWK7MC85DlUB8V0ioJRrwgilgWF1feWPble+q0tULhhPgAiwYAIDy 7M4AWSiwAWBxDFtwoN3wjZ43lxFooHSZDICgAGbGhg2GOuRxMGBAgQILEowiUChBhwEJXCRgkaBI ggVSLA5A4HDBqA0/bPx4mKdABj8MiyywYWPOBhYl/mbMKFGiyQcfH2xseGhxwQITIAsk8ENgwUsC HR08NPBhhA0LR+AYKEDPQQILhX7c8KHkxocbJ06YvdGkiY8mL6xsUOCjjCBER46EceDChAMLFhzw 5cE3AT0XA/yayMDQwkOkBlxk6JggA+AAPewcOEAkAucIDCLEYHAgxYEYoDPzKu3ONOnWo0GniBHb tOzRoz8fiPCate3YoEFfyJ1bkW7iMYhfUDRcd3DdEZRnnnBBunDdZiJcN3NgwvbpEyLgyTEhh5nx 3ye4m4Bn/PYQE8xPcP/+gHjy4t1PD9E+RAgz5UPkcAF5EQBoBoD8IRjCGQgu2B9/pPRHHn/lHQDB /huBnEDDWmXdQNYHHHqgggdMUODBEAmw0QYGcshBCCgtooEFE0gg4cENSFDwgQoUUHCCB8FQoIYH aqgxAgX6qCGGGissspAJC5jUAQgJmGBCAXoVYsEoVqJhgRUMPVHIEw0QUAACCaRUgAlFFDBAXwYU BYUNUhSBAEwdLFCEETbd9EEPH3gwQgkoDYBnAg0tVMhCBRiSpwGFcpSApCUgUoJVu4RR5QIgWNCR DR/80daHH4DRRKlNlABOTwX9IQYngyigQBggOAAYX0ZholULQfFFlAkJDODCArW60NemHXXKWABG mIEDJJk515lzmVFbWgW+mXYBaLVdQFoFvfUG/ptstI0WQ7mutQbcAaYc0Bxx7Rr3bnA5EHfdd8IF d9519CkyIHfzAWzfdvWZR7C+EcR33r/i5TeBGeQNbGAO+gE4nn0JGoiggRv/NzGE8vV3AAMk0DBF ErGEcpYHK6/swxF/FqnGjUkYQUADbRCizCsvYtBGETbMyMQJtpTIhJFMwBHMCH/cQIGRQQp5BC2L AJuAA3k8NYA4RVFpxUWHHjrAKBUttKikaFiEAAILpLSABVIc6kcGRFXEFBZFDPADF36W8MGgNnjw 6QgdsCAUUocWQcBSA/gBhQwDPII13oCXYMALgihgQrGFT2lBhzb80UMPPvzJ01olKOFBT2oI/iGD C5hw8IAAJmCSAWSJuWCYBQW4UOavDmRVh5oFyJBA8WFkoBiwJgQwQw9BRDGHIhc0py26pZmbQmfa xxAD9RHEFr62skXQLWzUwxCBKeBnRlpu5pq2bru5NbeubhXQppv71S5HLcMH6Adh9DkPfbKTA/ps Jzr/es8CGegw8TDwYQ4cGHcOSDD5WCwHGryPw/yTIAXRgRSiCQEpznCAaZyhPPE5wxlIAIEorOEs JwCDTzhxAw8gAhpCsIEQxHADNegjDRSgBRTYcAxZEKITr5DDzRogBQ/gKAlFisMIVFBFDzhtZSqA Q4lK5IE/lIAFu1uAAaCQh0eApCMNARYI/jrQELZt4BEbSMAjmDIKsSUAa6OAU0c2MAqKKGADa8yT A7AgKTK2SQp4KkEwBGEII4ThTz4QQjtYcEeLFIAATkDAAKBARxdAAY2HGYATEoCEI1gFDn8ggAxs IA4TQGEBUOiAT0pAwyB8oAmi80kPXtbLE+ziC8PghxsEEA9+YAJ2zbCADNT0KwP8ZQBPSoATCPCr YEVmAW0qypOgGQAWbEEIPYiCdqb3rs5kxlzQ4t5vtDebbXmPNOCzHi9S4E5T2PM34PpN/Nb3rvW1 6zflK035nEOceuWGOwRCoHgESC9/HdA9ipBOeRBmHwlC8KIJ26gE3+Me+zgMOw11z8Ny/hCJDRoo PmZgoYJCEAlSlCdj/+EPSycAARqsoQkn8EISwPCHD1BgF4gQg6l84AEwDEkfOTJCEeUAik6gQxbH aAAhCuADpyVhBGqwYhyI5AEu2ihQThORB3xwAh/8wAgbQAAB0OACtDGkI24kQEjwhhSiFGAHDYgr RQqQBygw5iGHTMAGOpCAtg5gAR0wALCgxNihMHZubQyLDbhgA5/cIIwVaZOZuuK2BdRRUiLB0wZ2 sQIDXOUIDiiAOAz7iEM5wCYfCkIPhEA6UvUAdaObg2V3wYx+AJeYbnDDHhSwhwzwICGJPRRl3OYC BMggA0aRJktMsDvDQCUAUjAEOE9g/gY7OEw/1eHMAZQTP86w03vjSpdt1Lcte+Yzn4pIQXKewy7S XMB78hvoc6bVnP4iJwQXCGD9HorA81g0PvQqUATo9Z3yTFRj4tlOTPuzUQc+rKIS/Ch35GPRDU4s Ehsj4RlKyKASO8hBkICQGSxEA5wmYWU3QCrLfPACoAKRRiqYwRNY9IpOvIhFskCAFMBAozgMqYpw EBET1GA0LCJhxiOAgwdKQBSmnOSwDTncXcn2CKSYaSGSgpw2+0jmBEAhk0hhyOGA1SmLOIAALihI SBTzZgsEhQWG+AELLjvJWhpWKB15LZu+rDaWEMAC+njBAlZQqQ4YFiLLhRILPDA6/iHoRJI34aGf WMCCL1DjH/1wwxf4kQkU8KNWfIGKdBVCj991YLVqAswApAunDBDg1QMIwCKkUAwu9OAQELCDf0Rj wuTMTzkFfR9wBnoBU3zPndpaX2ueDV9tEWd943sOfvu7HHUFJ78DzUxwBKwbC9JHQAMUqUINKB2I HfA8Ec0wwUBKUgaSZzz0TthFL/geDZ5UD+SJRAggQcIExedjIZBECssDgYdXYQ00EJ1OT6AGKu/i A2u6QTA8kAYV9GADT1jRDkChBWUQQqq9KIARRoAEFYBBDRRoslaHFCiZr2wEYBjBDQwhKUWhsQNB YesA6KplSb2WKIVdiAsKYChg/hWgEIhaQCEygIYyWYSubwRWYhX7XAt0ANdYz0CbDlWmUZwE05ft UBhTMpQ29a5NhVBsrTeAhDEsYBBw4IIBHsNmNJO9ABvomy5LMDrRcWEGPvHBoKRxC2lIA5lu4AAH 9mABDRSgD09ywWsVAhg1cyUxCHDCrzawu8isNgAbkIJHikGLGRwiClEALyTmox1y58bb2srvfefr ++Z4D3zuLJ+2qRdu6tlvfNMuX7eZr8/ymat875qfbkKwUOwgTFv2Qhj2H6yIEEz0AhuWN3sc5lEC 6pveEVr/ePql4fq4NAR6OPhM+ROgiY3YDFGAQCCSgNMg0FYQ+MjKGM0PDIAV/kxFGiDBEBQBIVgC OrzCKyjDDkjViqDBENyIF4WIkTiZk1XRCIBgoPgAC9jWoeQBGihPpLHVIxgGU0gG1lhERSgKGnBS ATQAsBCA2nRdm0yXUCCACzyBNg2AonRAGDQJnDREXxyKCSzCYyXAIhBF2tlACfgADbFABzyCEh4K RvzRlXSAAryAPoQBD5QBHCgAGp3Ja5le2SyAbPGEn/jJFBreDLAAFwRTPFBDF+zBHvDDA6CAAnCA USjElXATlURG3ykEYSmAm/iFNAFGAgRAnvwVLEjBBrxe7EWBwxzA7QUHvADYabwPQQUf9WgP9Akf fNEXaUAbcMiT9xgfvjAH/vW9RnvhXvU5R380WGYESHzoIgAlVLmJlPtNx3boW77VhwoV4/hFiMRs zMXYm4ixWCSkUEQhCB3wB4H0hxlE3ItlyAngUhP8kArM2AewwJ7MSDAYAxZEIJApgxaAggTKAQag wTW0gwogAZJ5QBw4Dc4JCZHU3FTogw04BAukRAe4ABuciWGRjSEB1iExRNFZRANMArBw0hAWwJfl oKBJykYaRTIsxCOcCQFgQAEYwCj4imIggB8gQB0QwCMYRUdok1MYgkxY1oeUwA9sAFRYTdRJiu8k lgKYoQh81QbYztwVAhoUwNVZBOtJwRAIQU+Mjk5QYQ8Q5A8oQCWIQBhQ/kMmWMAgiIE0zMpnOQFX rJabCIVRNB1jWIlD4IkDfJkDBEBHFAHWPIQU/ABOzIDsgVcCUUt9HVRysAttHAf9tIsrDh99MZ+2 NBtzIKZiFhT4oBcpfoZivsbuFVS/lE+A9AsA7eK5CQj2RVS/iJ+AxAeCABB7PJR+LFhKiZ+EaIz9 YYzGEBxMSaMZQIhHIUgk0MGCUAgOTAENBMEaCCAYnAUn2NyH9ICN2KM6eMMrCAMogILOdEInJIMz YAAbeAPQIEEaMIGOKM1WUYAKOJkVCckJkEoJxBFFzFEBFIGiEEUC4MIdqclKtEkdIcUj0NVrLcVh qVEDIAAuFIJTZBLX/klKUjrEBqCBDGgBsBQCmagJQ9DVk4QESDzXUYhNTcgEFTKeDSyCBZAdGrEg AkCaC/SBAuxCC7QAInDCD5hASypWgBrGKCyCDaxEEfxAbZXADuVEp/EZGCjAArwArTQDEtTFC3BA rVhAA9TKav0KYzhBoSgACyhAAQBCYijhrcDlnmxA0VkAX9QEd8meXvKlGUyUIkCHOSFbcODX94yG ZVKPKcCAtrzGb6xPfwUHtLWXvJgbc5SPXz6HgOUAc9xftJiBujWYaAYIoH6fL4LfBw1I/n3UhHyU +13MiKWYS22MNEaCwalUiCmc/R1AFUyBF7wYLuUSGHwAHJiFGEDl/gfMCBIwQhtAZ3ROpzJIlSxg gDN0QBOA4A0ZiVbNmM1plVYxAVmEUUQYXZswRAM4RIHmQSFwEmh1Xd0IIbDsACeZgBV0gOJk0h9V BEU85GGVCU4iBQHMVdFFBu+YDe+okeI8QqRdGeFk6IfYQBgYZKF0CgL8jgNsQAuIgQi8gCqxwGoZ lg2EBNqwBJ5c3QYoAeNF5RTOAE5aAdvAiQXYABJQgyDAQRhkBXIZxu94ljR16Q8ay2RcCa5NUwAE FkK8gAEMwrDwmRXMwBrAECTQwARAgmhkxkopB/i9C/wQFP1w27rsnj11y2ggR5/6Rp9yhmPKk3No j9Bmi5yWj/UN/thATUz9WB/4PVS/fB+BfC1+mMeBvAf3xYciPIyD0JuBQAjBEdwEkELcuscZSKMe mAEDrAfdLkiHEdwZHBAETAE2TEEQaAht+QjPJcmH3BAF0EgPoAFUTWd0zqoc9EIhLANaMMEGLtmQ kJXR6CNZfQAtFNYVPqRQjIKZDJLYQAlo1YlhYEEmtWQClEBDnAnYdIATtEkHuIQBFl0B3JHalIma FJaaaQ5dOUAR9IVDrBZUQKjVcRZFKN2n+MD0lsCPVgkWWECi4asDeMAKKMAKiIEQGMBaQkQBTAIC NMAOsEFjeVIeDMEgnIAN9IDi+cAGYMFBSAFjdcBVCMLSKIAF/vSBYpjAj46v1VjAKEnTU7iAFpRJ 0y0W7wRAoRhB5uyFAHQF4bAnCxwCDjCCf0AAmX7XAWBGo5rp9PlX7s2Tex1t085Tu8hpY5pGn+ZG KdIX/dDX93xPQQmInB5QcnTmomqLuQnI9FwHxWTfQz1MwxjQxhBIoY4HgpRQFCMc3a5UNsZHJADQ /M2fCkGAI1TBhQSCxH2AyiCC6gAKq0JRMJwAJciBMKCDrcoCkB1DLxzDMTyBEqTBDTCBFcEB0oxA zoWnkISVGpAjnjDFa0kG7JYJVGCBEDarRWRAmi3AW7EVJ0XEDhAA6x0WQrbJaNFuoeCJ0BlyB7De Q+agAC9X/iIeVjWN2ZNAQdONWQIYgk98wBHYgAIwVlcAC+7WGiK0gAOIgV1sadM5XdVYyQAsQiNz 3QIYQY7ewBH4CZ5YAdXI1SBMGQX8AcdSicj+CtllwF8UiyEaBpWo5a8UxQIEgDnPkQmAgAEgaQkw BCxYwRwcAs0egn8ohx1AQHmRKfglR5oGlHGEG/Gh1zwVrfUwbWM+ptBKiwtDm/H9l2V2xp7uMIGU GwBd7YANGAAhzIEQCHVQTLoJmMRMiIRACClEgqbSLQnRQXgto3uQkIg1CwSIKh/QwE3h1AfQQJLZ iBj4QCVA0csZARq4MXR2gjB0glQpwzHIidGEJwiqgS2w/sw+imeIqEEPsKoR5FECwA0MJiXkACHk HIY2HdqilImAyhrRmW8Dm4kJVCTR2Sdd9W5LFh0nWQB+mskPZlLu1FkCCIY0oe91roni4MmA+lkZ DEKQTsYjdMo384AF7MILiIBxrkCXNoQJPMJrYUEHQGFHGEXUOcUPjIIhiMMUnsQH/EAeKNYG+MAu jMAu/AEuK0QftIk1IQCuUSTqGUViMAacMOmwRKKkLFZcWMBexBZh5ckGMAI9758d3LNyHMImoq34 NWq4TQ/1aRti3tfuKSZ3G1+fumlnhPd343C0BGr1tcsullsQs3e7ZEfVcjTFTIxI5cf3ZdhIf5BL kQId/oQQ3YbQhFBYyIiH3M50yZRMGAdnhiSBHqvO9N6AGAQ1GBRBJ+QDOyqDHCiDMiTDMRSAFfCq 0uxxkbBMiASyjJUKMxtBHhDdE2zTH5nymiWWfJYdfk6CJl1dmg1AAzTARDyrjm8TAkCBCSDlUmjT lkmdsgboXe11BuRBsPg4nN0VJ6GBE7QBdWnNIqAR2+jEXdxyAqiNpAxwArwAJwCsGFTCDwgG76Du UFhAHrTkRZYJArzWli0AXPRZCXREIA0CkQoCKjUE2dWaNRkGZbhArOWgdTGFmltN8nSFyoKASUCT A4Qd2FkACPxAaxUBFMDCEATBIeyDc/vHp6PtqH8f/hETSH85W0BDJkRrz7P1afoodHg/Zre4+kBH 9HMEKntTdKJadKJ+jxHLt4AYCH1rkGjmd4qhNB1MgzQS+AQwAEVpEEy7VBSQQCC8GDfiFA2cQIwx QYx9gBLMwQfIHBLoww80wHR2gjJEp61OgjOgwQ/4wAgEgy3osQYK8hblnIj4gBEswA0GRRGwSZUn 3aF08khQRAcUQac84SNwsjRh0mFNAt1xK7CgASA8AZvV7kf6gbJuJNSBhEUwRl1Dxmo5xQLIddV5 0gJsTZuUhEmUwB8cQQmEgQLQwzvcSpdSwwrsQRlwwhH86GohwFGK9ZixQdm9uYrT4Ei6jbZ+QIe2 /tEg7AIcCIINrJZiuAmVLM+TKK+mDAtkOIEMVIlEKEQAjE0ClGSTbOliocmj/wCk3a8VqIIkzB6x RfcEKEf4hR92vCIO1+kqNq2bdvd3p4+0SHThKwK1tUspJm1FCxigarSAafR6F6qAfYf1JbHlj3Rr UveAMQjBhcA0KDtKSyMFiVR+29Q58IFNR0EPrMEY+0gHyhBPeByNfIADaIEwPKe6S1U8PoE4+EAa /DEiXBGEN5kKbNGOhKcHnBULuHkRLAKewATYFIAfFIJSLFciezbcgFkDRIYU/NEiFPNIRF3ZFTws VWjVmIlEkslyqZnVWA0U0FpdYx1UJKlIgASU/qgZUdQRCzz4C7wArADEowQWCmRwgOSFATFijoAw sMBEARMCEwwYkMCPEwQFBhQqMmpBoQxtMAwYZWSQjSMKFLBQcERQzEEGEjiIWMCACQcuCiYwgcAB iA4DeBawQNSiiwwDTASwkCDDwCILFhSo+AjEqA5hNrywsqFbLXuQDh3aN2GfGUVmJqw9cKHtBTMX QlxQdOHCgQiKIuCNYKovDLwXBKcgfPhCBMUpFPd1nLivqcEXDEPueyEH3hCO62am23czXdERQmeO YIY06Rxzc4RoTXqzmRCzz4Q4cyYSbjqkbJ/JgedA6wmzbc8+gMeRIxpTaKzpsebDCQ9qmCTx/pAk +vU4SIJ5KEFAmDBQoDrJ6XWsDZQhTNIIgkNhBBwPHm5YVzNCjRoV+tV8KMHCkA4qSmCBIgjYaIAC cEFggA4sgKKQAgTsCAECBoCigAIIqAgDq0wYgIACGrhIw0cs6ijBBBIoII8EKkxwABMzLACBSRq8 iqoMM3AhRKZq0jCDgh6xSsUFYISRKosSQESMF8L4wwYLInLBiTCkMaCFSspIyIEVrbrIRIsKWbCA CCW0oAgVB3hqARsUeIGFF1YYBBH3BBnkqYqCTJFHoHR6CoE6nMBpgaciSpAeGQJIYIMOxDGgABY2 WOAHC8RxEAQbCGwQCylUMYKRsg4xY1S1/trKgS/UQlCkLr/yeiwxygI7LALGDoOhL8YMM+yyyBQb 7LFfL/PkM9JGqwtZ0UxDFrQIMnsNWVZZnWsuZHsjpTZS6FCFtwlaa602BoqbjYEqpmAOgjXWoOGE JHwAQwUKPACjiRNuYEIFJoIJxgcsLOkEYC3kaKMXZ65pIo1n0kCkiRE84OQGD+BQY7788JsvCRaM WGQBKRZZMY8FsFggjwSfqPARji0KqUICXM4wxAys6KABCys6MBmONOSogw7yeKRHDEJsgEgCK0oQ gwYI1FDFgmB2wQ+YE3BhBwYtcjnEBIZMUKCeR4EiAzjECEMBHzKJCBMTTKBgBR4q4aSM/jCM/AkB E9DgSKAEN0zgCRMIMNHLixBAoOcOWhikhErgcE8MBQbI4MMEDEAgg5wGkKGiiAiIyoEMMHDBAYiY iqiBAEzwoecnGC1hgxAdpKqDSTNcQMA2CtiAlh5mYMQMM6pg64wJGNBLtBDMOICvu5SfbDAYJBNM G8IkCzYx53HVRjHBmN8+VmM7O5au7zFzdbNkYattNtHoOqA4Rc7wxDZFppkGAhJC0Cv9CUiLpBFS zIDgXOyKxQlO8IEPNCFiTKCYB5oAhohRgAk3SJgV5AAwDChDDs5AwyiGwB1bRGwEKkCEB0Ygr/l4 QAUlRCHF1DADjRRgAeL4wQLudpGI/iAADQNAgIoSkIwK3UxwkyCAC0BUAAeIaIcicwECdjAjDXWg KgwSmkSGlKGL/MgEFXFC1JjSpcfpLANDPNARZdAAIn6oIDwKIwFsVJVHDCUZGAgDIlZyhBV0Tm0v kAYPwsCJQYihAwZZgAMuwhMnDIBSPICCAa4WohBxpBAEWEBFhmICA3SABYigABKQYIANHTFqLhhR AmTgAqgkKEgIwMCgFhCkzgHFcQFAwAYSNMtRSOEpG9hAkTrwgxnSzgJc8aUUjECLIESBERM4Hlv2 sipnimYucnEVYEwBA16ZInrZFIz1blUZXEmGea16jGcy05m+lDM1ySLnZ4qnmQvQ/uECZ4inXJJ1 Bjq87zZnWAUk9gkB9kHiLcWBHx1ycAAImOsEA+xBE6BxAmgk0IEnTGEcmsBJI7RBC8pIhjKcsQwr +ABhSBgBEzxgLw+M8Do3kE4KKQCGEFJABT6YwdVedDSJFEFvHHEBGqICwydqjQAYSOLgNkKjBmwk ih0igBl3mIAQHSWSjwwSgSZZkDzcsE8cSVADNDLECqExA4XwURYTVCYnmiBCWltGAn4AhxUo4A8f 6BzoOMGSSizkBQsIkQMwNIDPGe1AN8EQzArwhMLCcJKN0mEDDHADIegyixbwwyQg57I1WiVJEgnd AkAApANFxUiy5OECJqWV2FnB/gAj24AvodgBB3TAAD9gARYW4Sla6GENbDnebPjCvnam7y3EWwxl iJvNC1QTMc7Di/YAIxjQDKYuxqIeqiKgl2eF7zPlc2ddiNWqEMCgNtgtDj4bQQfz0mEV+TzAAc6g iNX0xjcMmEIgEOqFEzQBpB4gqUod6wMC6jeFMS0CBtrgjAJgYQgIHEcwmDDSiN0AwvO5gQrkM5/9 lJRiPpiUIaqChhA94mdOhcIRnSg0RFqoTFQx0oZ0WQjDcmRFGxkKGmSwACioEgGcjZEOO3LTDEXk Q1Ol6hF50iUHfHZFMiCACa6KypcRkgAyqFCGvJShZTgAK64YhALEAIc9QK4S/ohwwAv+8AIhhAFS QywAj0zgB6aAIAMyaMMOlPrISQauADk0404kaRM3TzJEVGGUgwRkEI6EbmoIwMUAvGihyzWFQD/I gwWsYIFFNIpAHQBBowStIgs8BZM/2IARwmIEM8zhEHqwAyR0ewC1OFOe4fULNRXTXMNIJnra2yZh ZiUYcF4muuF0p7PGdz91qk983oPBbJYNT9vEE5/ONu9t6LAqV8dTEew13myEZ65ANIcG7JIOE5iA iBsY8F76GUEcXsoEI0Bh1B2QwnoYnMJ6faDBDtPvCCdKYRXcoAcsYMEPDJGAPGDokUMsa1GtuFUo 9IwAhSCQzYo0yZxekcoa/ppEEXaWxQ4UlShZq0qGEOBmi3RpklDuEVm7lAcewXBIB0IAEYmCADnL QKxOLcCNI4QAAwgiDC34gyt2wgNXGEABZfgDN47AgqG8KCJdqoheN3JJFoxiRlXJwJR9JKK/5Whq TImyDCYxRUaL7nFXzICbLaBkqevSiAFo1AYiuYEhGa0ARdDlhAQyyULxsAhWMEIR0LAJI6QiCqVy tWwOoD9W1eV9rWLeX/yiXOVGD5zI9XUEtHcBYhEmusH2S7K0+z3Se54uy0Y9d0PACvi987zva0QI Yh8Bea4X2sa7jRkYQAPlVKE5QViXvZIQwZKCITsUyAZ1rFOdGWygCFDQ/vsMFsoEBEYwXgE+4QhG cIP7LPADj9XQExD5BEBIAYqD23kGasYRKKiIiDNSUlkjBKKNVMSKVmwRiSIHpkUY8REWII7+Bv8I CciOhHJ05IoYrayIAhfaTOFODpU0hHKQpm42AmgswAMe4AWOQAwe5wU+IAP+SOlKIEd4gioc4Aks ACIoh0EijeqSiEa+DopuwJMgR4c2J9NSDiK6qmZ8YgecQIzq7ym8qA9coCQWJQHkLQBxSiD8oBBg B4pUzEhqyQ8wogBmAAug4Ak8ZQhCxQyioHd6p/Hggi48wZ7cafIkA7l4rXoiAHuWK7kmQ5yga7vY 6fSKDfV+6508jxVC/sATXC/a0DAEGqER8kkx2IcODoAB8ok3zAAHqiAQ5osGhC8U/ms+muAD3qWB PIAC7KsHekAJQrEHiuAJnqAbNqAJ4kA6KMBeVOAE9kvCbsAW9oMCKEANTsAHhKAHbMBIOM5CPGwJ CeIJuuRkRG4BHoH8WoaHKmTKhuT+jAZE7oaHdilFMAsEsOBohNBpskhNyipI/EarJCIPjuhDhigP CqBDaoqQrMIBiuCIIi5DuBEBorAAwqBJhEDpeMAAEMEAwmAFxGAQWkABJOJECKlCpnDJxOh2BCTS aEmsEAnQhgYoNiUDNMLISCtrKGfk1qxHwuhycGEpTCBHAgCRRuEI/n5A6lqkEPxAQHpmAbSiKtSm CGTgdooEC37ACqygCKTAChhBEkqFDM0AVcrJ887gD1mBe3TtuC4geppH85ySVhCjeeRwuUJPM1TP u4pH9bqLLt7H9WjvvM7LE8prM1ojVuhAMe5pAs4AAiAg3MLtEi8xYjDm3MqgB6YjhfTB+oyBFKED C4rhBLhjP5IgCcYBwOaDpOhjPuLjBhzmA2ZA4DagGNggUlgAiITqkUhOQ77OSypiFFQkZGikANxs ZFgEb2QOagqhZBZgcMxICn4EKsRKrDQkh1bkcYJk6wiAz5ZIyXjkHU1gTwpABrbOJo8IAQ5JJypC /YgCCn7ibxzg/gPKYAX+gCFA4AW4wAQ+4Ai40yU0a0ZcoIy2YgNmUK9gyG9c5iJe5iIcxCLoYYiK oAGIIQysgGlmc6l4syYyR0SIYQf2ZuQsIos6JwAwaQGUgFGoLkca5CGKRId2CAQIoA1UxAouQidZ wBs6xQiCsix6R5mIMjjC5/QuYzDu4AJYAQZ2bdduxSono/O+q3miyzGITZxIY9m0kitD4A5or/U8 gQ58lA4iwbyway1rowIgr3/echKTIBCCwEnB4ATEQC89wICo1PuCAQ5UQAWaIAiU4BCUYBR7ADuS IA6sIw7mIw68b6RUQL9CyBZKKILmQGMMQApi083Q4GMGAKdW/uRASAQ9+/RmNsQqHAlofGrJ8A+x BmcARsYEOkAbhWojeMREOgANEICrymRwVkQIi2ypnCCHiPOHYMSK0MhvuGrJOtOKfOJleGLi7g8O 4OQDOAFOSsACAvJVw8C1ZmRP+q8iQMAATaQqCsEFJG4UYuQzrYLmCuVAAAGRJMdIDJCIIMJCJEkB RsEmaoKQEG2QNGRReqmqTOJvhmZRnSoBBu4iJskGoCgBOiTTrAAExKEIAhMLVCEKoiAoSYHVtq26 6IIV5GlVfoV75HBFTVTXCJZFmbLz2ukqkY2diAVI/TUQ0RCezqsR1qHaQON+9MKe7il46me+vi0I wMA6kqD7/j7gDyJGDKI0DvTBYeJgF4KhCVKhBLy0BHrgEEhRZPeDD1DoOlCI+xzmBsCAAs5thqDI sA7uS1wGCgpkyjArqDZEQhGkEHaoAxbBAqzGr6wCcHDT4srKxlyTI/Nux6zIBdrgQKTsQJygAZIm bS2VWcNoiSwkizTHICUCDaJVdC7VBE5miZaiIEQHBMpACMagDMTgAxJiBUrAZHtAASqi5QrCItCT 0XBqiTZiIu7skiCCJJ8Ccj8kdI4oA6S1IB4JAYihbopxRg7EQvjqXOPMzbokABrA7nbJNa3CEDhi FCzgCQjAAozgQU5MCyxiFEQNb2RotX5gUYvAD2BhDuxV/iiNg30ez1/tAlaq8lZYIddM9CmdCy/g ySp1TfK2a0fxglicTTQG8Z24a/YaoRp+FBCry3vyqTZ4rwpIANxOAAyCQDoeRkrn4wiE4AT0wYS2 Ixg+wArYAApm4L5stgTmoGaD4ANoAEr5oy4vTDFHwOkYBKfUk+M2AAsG4Ggf9AlcQHVIMwGmFrR0 yA8QBA08VXPU72dEdWwZFGsAh4SHlSnKas3u1hkH5UQShEdkbm1tkiOW4iIcgJCghqx2JGtQSUmm iigWoQTs6AjAoEkUwBAGwQd8oOmOgohsgigKIioyALTWDG9M4P2OyERuomuQlziFymiAgjjbtios wQmK/kQIg0TNOjeHSTJ2AiDnVISWMm5Rc/X9BG0DbIAFlKDNMg0EpGADjqJIpqJOQSUoP5TVyPCZ EDF5SPRgP/kw7kBFU/QCCBZFEePztCeVB6O7brRH78l8xTJI1XIvEjGeVoFjDQoC3oA5KlHcToAT kiBoESGuxCBe5oMCggEJ9KEJWMBAimEITkAdTqAHgkB3RtGB56CawcAT4yCFKAamzq1fXGRDulZD 3AwK9DQBOA6GoAIK0ISIVLdMIm6p1pgNTOAjqqw0IzL/7i9FIldDeIQnTMRMaCQ5N6IBIOcRjAxy OcJvnMAA84AeItfRakJvemRFiqwmGIQHLORNhCBx/jygDBSgK6xTDP7jUk74h3koBz8tjDArIh7h JmLMcovEbyinJraOr/RYbXUCA2xyADyJG8vokTpnKXDztQKgWI/Gl36AY2wa/YhiCWmXSH7ACPTK QXjIAgigA2xXCnpyAxhhBiQBEsoaEs5gLtqCNsJrLs5pMNrQRPHCYLfplGFAKeeaME6ZfEVDML6L u5QyllVP2iI2LMGrfNpL984AErIt3NIlCMCtB7hZPzxADHzgA8TgPlyBAvRhX+LgA4xAT3+gB5Ag DdiNgG6gCYRACUrgEGxgBsIUXm5RH7R0aH3gBYbAKjBECgxBCjBkhaeo4VbGSAIQz5aqAdBgAYho /iiu8UWShLgpcGprZgCEqFjzjEfMRE0E+mQG52wjMoc/q8gCBQ0GlCgEeiCSJEioDERWzkKOIgMU oARa4AjKgBM4gXVagIs/QAl+oGeOIv+UwrJcRwpAxAXURlh1mCAGhx4i4o6d2G/kwJSo4kOWCBec SlGHwog6gjcvKR43R4wMYFHKc0WMROKcSiOUBCRW5kt0qETuWApdc5BoAoaMoE4/YaxTgax5Z9uk pTjooreqR2AJAwbuwGDxWkXrmjDO4EZBb9kIVsn9OpaJ5X3owhDLFzIgrzbyKdsggAi8oBKfIwga KDqo46QKSErhYN2SmQJmoBh60gaY4BbTgMx5/jYIwKEHSmAGZrYESkAIPgD5uHk+FFknFaAec0yX qsKwQBiEG4AQhAYKjkpnMsQP0plGMCAZZGAAcshEJqE0W8YkEoCnRm5wcOGoCERRDwRm2LOqGE5n NqJFPuRxuPundQgDXrrhVMQBpMAAHiGs9sQnaE43DYAHbud/w4C+PUAIWKIExKAHDneXYixm5G9U Ee1DnnNnIgTI6OGsNoUnmCID+sYntIoAnOAnipNRwlGHTOkhgBgdj6gDlBCGBmCG7Kwi3q+sVESS 2AiwNkBS0gQjQIwFDWBSWqRAfpIRPiEVUiFf0dp47KI3ouUyjlyuS/l67Xq58NpgPcFECVsw/ohl 11oZ8rprR8vrDGAD955Ny+2ACN6gOT6g2aHjvk7oBqRUDd7jFpNZBUqgGCB5DvQlGPIFSrU0MXUR TMHUBubABoRA6UuAC3YJpy4CC0JkEhjEUdPRsAyLAHAhaXJI/fimQgoBOek5sJjmqDbiBz64ILib 5BxpAC5lM48qRArBCdqgKFDdoT8E7AslHfXmQ9RWJCzECZRsr5KkS1yGJ1zAlDKEjPSTN+WEBcrA isugBbqiirnYBjYgNKEA8XWG0WpiwtFxSCYJrRCfJyIikkp/P1WQ5mAdREqJOTEClTpAHKPsClm8 ZHTQ4CxA7iTO4mJMaXhIQI4qJi8CJBKg/uwDTq8swg8WgAUWABMGQAEitAGgAAp88hrmNRUO4awf Xjag7TbCNypTVJThya4FQ5RTtJpMWUXvwPVQlPzlemLxYsq5K57GkkdJQ56qa/faSxHsgMtXHiCU 9PDxockNDycOIryhZgQFD0iQ6BPCQpWhE3zSqGjS7sQzChT0jfDgYQQTDzdO+FBig+UMMiWEUCyC y0EBBAgSFNAph8CCDgsGDCjQAAGaAk8IFBgAJcOABDgzoFnw6GmCBQkSFCGgFOfOoC7QEDg6oCqB soUKYC1QgMAoAjiHIigKF4NSE4XOQingIGsGF0uXZpjUQIZSF2xwEnAhNAOCoS7ODiDQ/oDtTgR1 0Azwk2HDChYrxHAqw6VFGCEfPigA0SHBIxPLvjpwjEBGgwS0M7RFYEEnggJ5C+GVgQAwcN2O6cow UYA5rp0DZOjEfXvRAAdDBwDVbQJ7AafXAyRYVGBDAi0NBthYMJZFAgc/E/hJ8GM81g4lbi4dUGRo ngQWbNBba49sUAAWHUABBRZD9GCGJJCQEuEZZigSwhln0IHhBRfAwKGHMLDC4R0hwgDDHR2i2OEF JHYIood3hHAHHSzSESMMIcBwhoeecNjjGRfsmGEjZ0QQwQUhRHBGJCEcQMo0q5gBwRtTrGElDT4M 5AMYDI3wgUJwOJSGREEYIQUtQagQ/scJQSRBgUZMqODBSR6ooMINKpjUxEotlTCHDTOgVsIPCxRR wFSPJNCGH1AkIBR/hQqVFAJsnGUUZb9xlVZbBEDRQQGAYYBBTgNMctZuSuUB3FK4YJAeVxgsYNl3 gJU1mAuOOtacoyYMgMBdA2waGVuGueCCU8zhxJxuC5jgQjLcLeDEDs7KYEAJL4QGhitCKMDCEWB8 cIQ4izwCRVWPJJrVAL2+JysBfRHgRB2PFCDDJIAZ24BwwP3WK3PEMTZUBkWYoNRsQ9XBFwEJMPdd cQsskAEBTi3gAMWOBkCgUJUlsAFWDhDqcQcsjBKUFFpdVcQCT6SHFVNaGVAAC339/vArAQUCNYQP tFiRyiGMMHKIGZBAYgaGqwB5wIdHsmjiHZ6c6KKHLJpC9R1YZ80KjSjqyOPWNvbYo4lbN9LIKqso AskZB4QQSQSO6CI3CRAcEAUEXiRBw940BNFEEB6AURJJN3xAkkMR6VMCLRtw8UESHiSRRJwqnKSC GoOPcAIFiDjEREMeKFFCD0rMwEIJoishkA0dGIrG6zv1h5Rajj5VxMSZulBIIUIh4PBNTjCcgFKU FdDBZPsOtZRXlElnQVUmIIABcYsdKgMGTuyGOwJOPAbCAAZq8RtOigEH1yTETsJcHRgcC6pu9jaQ TPaYJeMTC4PYsIIPHojxQgug/hHXEXxwFZ3sJAFQiJhNntKsATjBVXxxlAUYExkXjAoukOHeUioj s1PJQC0OqOBSMFaA6SXAAO9hmFPyMoC1LMUEGRCPTrQziv8goAMb+IFSPLWAj8lKO1eZzAKkgBSu PCEPkxnAKJ4ilKB0QApA8dgQNgCFTSzgZ6lghNEqpAgzsCJDF+jRinAEIlbAIGpm7FqJSpSjHEWt QzQKUY+OdKQkXSACdLCRiFixirPF4ABH00XcsIGNKWCDD3zbGxjCtUgw6OMGcwCDGnpgODVQQBAg gcMNjtCDHrQpDipIwgcupwI4kHIktgADIpowksENblA/yJIShsCCIaCuBMY4/oESrAAFSjUAFw1Y FFv684T9POEo9coLAtJSiLlgYBI4KYTHhKKf4SWgmUphFxrY172lBLE2C0PAxBZTBEcNKzJRuQoC ljgqF+AEMIXQTV7cKSrGgMoFJuiV7vJZAHogqwBOWA4IwmCDQXxADH8YhCF+8AIfiMEHprMKuqCQ z15hR3ltaQAgKoMdkYGqLZDZz2ScIs62ACZ7lEkeUbgHL6JUZii96s17kpWBcSolAGYBX6IWYAO1 sOUqCwBMowighSL4YYg+wcLHkKLEH26AmgQQR3zWNQpDdAALC0DFB4Q2A6CtQhJnUIQizkCkGHHo rC+aGovWWiIXmXFFXLtA/hzj6EYynogO1WiEIvh4hlUcoBFmwAYysHEOCECAD4fkAx9OcAIanAAM J5CcCmaQhx9cDiEgCcYIRvKHHnhADZQDLSnrBLo6jWQkFBjBnXxQgj1ZIStWKMFKZiC6IZSOBUr4 QA86cBQ04AIBCRSKTiTTFj+wJVi/aksB2iCq8g0vU08pAC64Qr7fNKAwi1nMxK73Qa4051e9igv8 DHOdtiTrUA2YhB8K4QfF5At77MoA7+JZCMY0rFb0uGcCOmADgn4AETeA5QvA9YEXCCgrWVlVVZqY gArOxwEshCFf2IVEZ6lqgbi5yb0YtgHzCMUF3aNYAepgqu8oJcPZCYxN/uDnBBc0S4ZsKdBjaoiG rCygN2MpLwE2kBMjjFBluvkPFJRSAML8ZmAHBCqCjGAENBQjaJJgxDTWZoajZWhrK+rQW03kNDN6 GUY5CqPT2CrXDrVRR57wBJYbsY5GXCAFFxgrCaZBWMEe4BBRWINi+ZCEQIBBcpBbZAJmMLoPbA4J eUIESuBwEgpc7rF10gdKSPI5OqmW0SgRAws60AEQPJV3BYgtoXU7BEDZAHWG9oDpOrCIDbRuhE9o 1GTEohnl7cVgikED72RVgL3ApQHCMNWvpAcXYokzpc0kR05s4oDacKUOlTEMqopNgFFlxZ2LQUNt JqGZ6OGKOeF1Nj3e/lPfv/wqAfgrwSCOIIZNhgEEsg3XIH4QxY8Wog0IqJduHMCcZxOPfNf9jq18 xZjjUVAo1VaYwT5oAtz81mNAdUzwXIBEThXHDws2QVL4AgWcLqKGw15EwzxWgDw84j8ITsATEmAJ DBThMZop5wBibXIbO8rG2bkKSBGYACywAQtGUAUjIER0o51haxcSkonocCISkSiNKTrRXU8koxzt yIwyumMYYUAjT6yDDk2LANdZ0SRdwOOwNMDBGiCQZz6ooE0n+IDgClcCLrDpBupw9AnUYKeDMGGz k+P7nEiCEJLkCXM3CNMNfPCCH1hhKE+oSl72srIiYMEGPgjCqWdA/ssZ+OAGlOyBDVjwMUMVWyho kMpOqqLzYBUzL9BZSlDIZ79zD6AB1ALYY26CAafg6mO6gcuvnHDdZDTgWJhxQlomMSr4aJMtYbEv qNjFGGc9zL4NI3IGLPCDQaj7S38oAQsYWoIjfGAQmzaArBDQhryICi7UFUxxjusUj2WA1xODilLA AlNC6cZRxBF8xcFAExcXEcMWf6FdajEA7sQuBLADMYQAC7Bp+jEzBYAyFgAU0fUUn7IAhKAWT7AI WKEV/6GBbNBs5eRi0jRD76IdT6AdTGYFUqAJUvAJkkB0RxMCX3QHZ8CDX8Z0TlciKIIidMAKasZ1 SOhlRxgCdCA2/nnUI3TQCBGQAicSNTTCAPCADSewBnnWWEFAAyqgDpWzEAjxASWwBmoSDKrmWQYx J5RDSnaiWmrgd3MSJpv1JhTQAyzwMm2AL9RUAIbyBM6AAE+wAEZgW4AyOkpAekMgBKxVAkNgCJtm VAXQDVyBM31xKCbAa4FxE4+RXOvCLr/hiQiQDFogH4oRFcTxG82yFJFhGxN3XR/EgA2gQvBXPsaR HfEFfYfRAPLVHDfGgI+RgWGQGut2UD7AAgM1QD5wBJtmQAD1GI8gPcxHHEXxML/CGI6RATZhUk9w LIbhO3yBQn1xL04xMbzDgNk0fQmQBy7gBzDUYiAFGN7Vby1U/kImEAAF8Ag/sQBg4FLHw2muxhbp 8Qgd0A2qMnM7kAw7UATewR8zdyoLMAorA1UFYDI7dWSvtQDdAAVF8A1GMHQQsjZ9hSE9eAFG+GVD OIRrRCJckyNYVyJQCDVg4wkhwCFM5wnVAHYR4A7YQApREAyxAFmOxVgn4AFqiHj9cwNgEAwqoAQ+ cAKHUAKHMAc90ARHmSd5klqRUxJywgRhYgtqYAsO4QE+0BtHwVJoEBbK8wRGoROJAQUbMAQF4QOn toglkJc9kJdKQBGu9mrZNGQNoBk1dlycgkwYdTPLowUthwHq2BbExxUNUAfd9Yk40QDdMywvpDyc CTzQVI+9/hIcA/AXQyF8jNEXNqEUFnA6R/AHqeFQyagAYSBbA1QCx+OJypV9v1IUyMEpLgAfQQE/ 8hIwT+AEbbCNT4FCi3A8DoAF7zE8EbRiArdiLfQIBGBcv6kZ4OQA2FF9SxEA4pAHv2EyGzAKrcEe aOAEQgEFLoAyDhBFUrBALYRVSaEZwIEBS6Qd+ZZRO+Zh8QQFO9AWRSCXxdABqmAEMzADI4k0R3eT aAUiK9llY+MiZvZ0R8h0N4kjcxQkdHAA7tCEadYI8IAOtRAnPsAEfnMCejgDdFg4gjMCNxAMTBAF nEc6o9NJWKkCFLB3cnIQmGMLYaICiuYBq7SHrpIM0qNr/nOBPsEyGQcyAHIgPrKzAD+gOnkpfoQm ejZghjPQA0LwAygzmJNhfHMxANpmFXLBn+iUHQiwA7U4CTJQBBYwmoCRAcFzZLhGmc1Rmr6TmhQk A3nRcMJ1E9gnjMXxGyjUHbgBF/ZlALP5B3/QjB/wB4XzAiDwA0LwB0cgOgrQYPYJKsXkTr4DMdvB GOo5PN2TnLspTqzKMBZDURtgAAy0iQvgbELRFxEDFLnpK71CADCUYbKaF78WPAFgHq4yAB/QRCYj TQTgnEkmBS8DiE9UTi/4KTtGekHxFN7RKRgAHfXBFiYwKpXhlgkgBVKgIFIQktuwrmewNmcDJHuU NSz5/lZwhCJGEiJypSJy1Qg7aSQR8CN51AgmopN5pAt7QwH84wNYqRICcQKt5AFkiUkacQNNYKO0 dQiAMgcCgZVfIngnMRJMAGDnZwMb4ATM94lYARdtQACc9htWgAE7UAg7EKDsubI9xAKPOAM2wAUs wAUzwLM6ixofYANQtBe1SIhL0QHFxAZPkBfyNRaHMmxQSwCTQA7Tsx/foW0IUI7TUxnK9WEEczEa tQOjsgPHJj3qiSo7gR0Uw0ArVhvHR6UvcGqy9QGOKAbhogAT2IwlYIZDm7Ld0ytlIRdc4YAEYAkE UAi1yE9cMRi+Ii8N8BPT42wF5AC90UMJYBu1gSvq/mgCHcCNJhC3+ZcBbBB7j6Ko2AECOKVErdGB jgJSA2ABTuRqBtATRbCcHzMULEOIWvFSCWAy7MmKtONiCHgTY9ErdgEFj5IAtXAIqQAJh3AIRTNW G/IhrKA1UuOSMwIjnjCFH7Kvs4BHUNgjDNA2IZBmeRQCgZU3afAljKUQh9MQnTMCmOQQlZMQKtoD U3kIqmOVfUsQCQG/hGeXCVBjcuAVBRwfoFII5cQ7HSAqy4UA5uGWnqK86Xo6qMNap0O3dGsENrCX QmAFBiI9DVBMK2VcYhEVbLEpvXITZOoUnmgpToFB9qK5BGCOrogT3VNT7uQEyKFjhnGJgouA8Fcg /iwQBi8gW2VQfqmRGjZgABuwpeJiA1T8KbzjAm0gA40iuNQ0f7oBCEtBXvZisphxw/ToAr44GaKS AaGpKtxoXjnnK7VoE1AgA8nwFJgJKlvbikPhMQbQTBnQcex1gPvnKDgkVa3hTSqDYAuABYuABeRA b90AnH0cMRhVTg3WBkUhFGnRVFhxZImCBVBkBQf6Ceu6DdMAJURyVmuFNV1GIx8SR7GcR1Hor1AT sOXLoRkSAhMwAdiQBLEwAp8XOHVyeCPAaA4BEndoOX0XBDZKlSXQVX4yEF5qOIs3AyAgBSaQngNg F0bRzS6gvGLhTeaRAL/1BB/0A5MhgeYhPMtZ/gw/EBN5SUss4MF7yQI7y1p6aAVF4JYFwAYNQAj2 qRjC91vrWBu1kRYyAG2MMT3BImLw9x2F0W2jSU3dTFwYNDBE1h1IJlwLoABS/IhHkJc3IAbYMn5J PNKDQElDa51sQRjBI6h6rDDXwS5s8BfYczPX+Y7K9R03cRWhq55YcbRFQV4Tsx/JBRcZ4CrUsXsZ cEKTYVHDYxiWGwBLtClB8QjfmEBZgUPvQnJ+cERQlAepohTmak0RY50nZhPrNxTHE9Fs0SivuxMG cFU/MAQhGb1aBCVJc3Q2Iq9OAyLfCyJR2AgkwoQ4kkdylUfTEAlE0iSGZQd5wxAHRXilNGlE/toQ YaJoIBsmjpYSHxAESjAHM/AnCXqlqBYEM9A6TMEWC8BMy1MICwACw9NM+WYdy2SmSjQ8+zKCBvCC x1UEG9C3Xip+XLCzhDYEppMljki0T6Vcr10UOIFv3EPQeeEElTIZG2UvWuAEBwgqmMkYCAAIO6AF x8Koc1GLOyAMdTCaMtCbAidcuLoBLDC3qTHSVyoE0JAaQpDN3nJqBCEuXAAC7GE8N9cBJ/YItLG1 tUMUxkkMbqp9K7jO8IgdKetiQOGdkZEW7lR9x9Jwvgcf2fPeINWrLrYA13PiCRAA9CZ7QREYuJIA laGBZfEyTyFy/7wA2naAT5C86xIYAM16/p+iREOGBp9pQOx3jfzYyFJgBYc4kqSwCtNwBjrYgyuZ dSTCZTZShCmidSDSCE0YAUzYCNvANlPyBm/QBHnzd6aVzIFzlHOiaLZApCQhlpVWWnHnA0KQoAk6 B35y2izBAuMnMr6iGDXeAUPQAYVQTL+CBce1FtXZAHZhGcXEMWYrBR0mW8VtOtE8KNF8aroFUT3w AzkkntINw0gRFlyBBjIgA7hiLwwDs+oRBh2mnOKwAQ6gvNmDZNXWPsRgCS7wVN1TB7hwmlexmoJ+ apx0BEJQAso+qR9AASsAFFC8s1c60uZxE+hzEyuIbTdcBwiwCLLbG+g0MRsOw5yBfNkF/iyR8R5C IbjI8RgpBn/YMUMFsAOYEhkxPRkWYAFtsRYLoI+D+lOEUh4s0KRDkSjCJQVYBSlIsQhDsAhQIDOP 8ZxUwXuFW6vAlQDecDxGHk2eaBwdgADqg0BFAGVFkyFAgjVb3nRHUoRRw3U7mQJNE7DdG0YhwK+S oL4HMCVrYAxWgpWmRQF8R/Qe8CVhIr9qgAh5QqQjoRCaQ1pJ0ATN7ueERto+ywV+3kmQaAQamLhL US8pSzs7sRMNJ+MYoH6KO2yOWYlogAGvgABSQCng8wOe1wOEdmq0gNw/8Cd/Ei46S2/1BrVLYduZ EkGu/RcbYIZH/AJKMLeDQlAdxhr9/tgXAjKBYSCeSHRCP1DfkJ+XzJ4/x923YtDEN/BDHcBQPWB+ eOsDnfofrjYKwAEg7MkG+PQEO6AwQGExi9Exu5GNuMIVLqa3BrM916ETCShOkyEDO9wWsKi8FMOo 7GIoRfEf+/EekFkAAZC4ZYEzEROebfAUIoMVC2AdwvCBBoAyV0FdhrgBRLSevRYx64IuBtQGjfIp b68FFOUa6mIB4mABAOGgA5YBRYzUUiUJEqlpq87QuXOHVcQQdyJcgAGDDsQL6+hcuLDxjqdGjTxd pFONzgQGECDYMQYTXA8lN1SowYkTjgoPNzzwHKECDpMRcCh4QIQUqVAPHtSMUOPh/kOQHnNmzLE6 g8sQFjNY2LBRooQPHzZ+bOiwAcsCtgMKDXhEwMWABAUGmMCAocCCum5lIBgAZQCCBg0GLBhAwO6A wwt8nBDyYUYPG3NYDOFipWsJGzPEcmbRYcDcBIwLyC3NeECGAovD+Hjxw8YLG3kSKNiwgQWIHyzO gtgAgosHIRsWBN+gwIMYMEeElHjB5cWMF2KFPD/yAcwHLr25NCCwqHqJyCU+EP+xaECBSWgwaGlT oHRdBxsMEGggI0EGAgQwuMAAAQIQkMEJuewiABAtLGnABMLckou1BAxYbz0CEligAEAIaWCuAlxA AIEMHajLgAU6WMCABFBzwIEP/hnLgEACAugAw9zaQgyBugrIAIsf+BpgkvUWK6CbwBBLQAonGuir NBNKI4Attko7LYEOingEsNYeSaDLBCzgywUTMhywDUKeqIURSBiZpqEzJqJjoojogIGVlEq646M7 GqmmkQgqiICOktaJJAQSqiDhDRrWMMaYD8AhiwkK4qBABQqgUgMOnI7aCVNLm0JqhKJuYqKnJH5S 44MSZmB1Va9eZYEWVlngjDOwfrBiAW8yDKwAOVxY8TDFCBjTggQIUywBB57wsAEo5JMCMfz8SAAL z8AQywYuVhWiN1q+qpUsJXKzAkUupwSRgELwQ8AFI0pgYTwf6BIrjFqFsIEF/i7C+gCDDl7AzZAf DJHqiNm2Dasz8j6ARowPhGDBAsYcWOCFtMIaS9USNhiQMQT++xiB1pQdkDUXCNAvg7kG2GAAC3hI MTgWZlagrSdDtCAP+XTOYEWRY5zLQBfkg7JDB5g0YYcPXeQrgwFQVGy9MQdwooAAHlnk5EdqTGAU vgoAb13FFhilxgpTK0QvNKIeAA0dTSgA6lEKyaOQ1owrQMBCnlgPjdKgsOCJDCZprQAsEoAiPina QOMJTaQwgpFUINmGFVbOaOQjGDBKqc9GMMJoT4lCaqQeUiYgoooqosAhiDXWCKKJE3o4gScPRqBA DVfgcIWCS3EKxgMwgtHn/oMk4gh1hBNuH+G8EfRBggIuoHhiAQKK2ODhzriYYfuZh5hhiB9YnUGJ D5SwodyBjpWhAAtGkVq+IQcsxEUX5lrAQUy+bLFLsCmuww4GQCsuaO8I8IrNZTqDGVr54ANlYYER viIauOgMAU+IW2d+wIgfDEEJlBnCEKwyhHwpoSs2+AAhijGCyRTwByegQA8MUQIlvOA5KPwAWF6w AWVVyAQwE8dXwuLAP7CgAE4gXAdA0CUVPc0AFHMCBsDTMwMYgAth2NcRsvMBMfhAix8owyBK0JM0 qKUu/XnEYIbGnw8loBCWAAQUXAAFBzAGQyYgQAcKIEUELIkud6ljAQSS/oAn9cwEHeiAAQLgBMQ4 oAguwiBrGFOjvDUAMIvoABRMEB8EpNEubUTRkxZRADZUSDQgaoBdSjOJAQHLSa3Jw9AAk5gNSKED eUADFKBQFzSgoQjX+MEn7LGKVQgqTxCBSEkawYoL3KFPd7iAMhsxjTNMoAo0oAEOknCCE4TiAycA Q0/UcIMPOM93O3GFPjSVOwok4QNzCEIcngIqMdzAncsZgoryhwDsJUBnuWHBB3rwmXx5hStGGIIR Oji+D9JkCIYYAopKEyI1oiEDJpBaBlQmFxOQKAMkIiQ9NIoA/sjgQjwogALs9YLqrMBVvukNCTXD Kq50T6A0FJcNOgC+/iFYYQNGCN8nPhFCIww1fLKS1WSsMBklhG8O5vGACXsgUDFIpQQ1YwuP7nfR BYAABPYi4iDM4iAnAKtGAkoMAUg0AAfgwgkZOE5APfCZQQhBi58RywE5s68m/GgwUpSfCxqAAScM pgFLkk/eFFM4F7RBowQYqYiWBBgwKQujcMMoSAOQDDtSjDGFEBnZ+nOX9VhJQAsQGXgwQIA/tiYw dFEM3L5mSTY4aECsbZuFBGTJNuBHMQ1AAy78xgbDWKEAhFBGMtDQgVRswyHEbMQqMpenPTUiT9XA 7kQasY1GSOIAEFDUGnBAOxqAoQdBOA8TlidQH9jkUkg5pxpy1xQ1/kAsnD1wIE/myYINxEVkqrkS KQtQBD0e5gd4JeEMOmgFzUgQV5qhoapuxRY9FkAGARoQYQqxAAfQowBP+vBaT+YC/ty2xAPIgwWK sYExUuAD7WgqVyJoBCvgagNWMIJCe9OVrgzhAypQAhaKgAUslMMKRUYog4uK46X+QBIs6MEhjBAE 8AEVHGo4wXl8YJwh8DBZGC3cmAzwg+oMoh1HUEIJftABCzwCDXuxANwwRKLcbIDMM4tNC2ywgpnF CzQK8HOtXNo9rwzkjxYIzgKiSIAoTuIJE3VCG4Z2shAJqF15IwcgDHOy1tz2SZ8mpANMEAAHWMEA KKoR3Fh7Ih4K/mZdCfgBXVDbny6JDEN5a43I8igFE3AsAW8WWaUDNDRTunGxdquQXTYw5COjoQ1Q wDEWNAEJSCgCuskUSTLvsI5BrWMdZ2gJBNawqNfRAL3o/aYH4jAW/J7ndw6DwwiacpR5fwDKH/DJ CBCh5kSuqwGEI1tpMsQGBPihPwRAQ1y/RysbgO97HTTCjRVq564cYaBgMUS5MCSYAWhBBlyKkWIy 8BYX/UU+ReDRmwd0mtMAlgA4noxDefoDGqtlLdFKQBG6JAUpWIENnWBDEdDABkosAwqUgEI5pC1k K6hiBkxWhRGk0NNUDIGG4yrCAoqAgFKuSEhu6ZkDLGAAlYpx/hD4xVdoTKDzPhZAMAsQY16F4MC5 eiZbRljAIuysFRZohlZ7xVjDfcACHwhB3mXhTAJkAKK8JcBiAloZaJ3wBDxaki6E5FFrHus+uggy A2msSwA27IA8LNZCuxyAJbTASLPZkS4bJhvYGoDsvHnMWAOwgo4ylAHHWhQxdoHCgypZaQG1gQ0d eMLHsp6AJ9htGYWAgrTtUW1iOoRPytRTnBpxj3s0gghTsIO413CCbZJTO/b0yVynegImqMD9TCAn E+DQE1HtggmDGIIPBOETB3YLRXRBgAWZJQJAPUtqgDa4IPmQEizYAA/yDB9oAh+gDK/AFSPoACkg MlYLoiHw/gn1agKd6oBO+poP44suabNCcBogwaABaABLYIMLWYAn8IMnaAA2WIYNmAEfMIaBIh+a Sigbw0AiwwIoKAJQyIdjoARZ6ARQkAVZAAVlYIdeOAZfYAPqEbpNgDZUIDJKGAAsGIIgUIJM0qUC cBsLSSMB+RI7q44j8IGxAIPBEw0C0IIarBq7wII3LKce6AEhmCqvCIs9tIEFwIIOoBUlSCiEoiHy 6Yx8aYLMsAAjsAH7oBUDsItH8IPVi0SRqcQCwAVWMoFCqIPV6pk8CBHI2iUSyZ8BWLz/EBOrIQAD sKXF6JLLK4BRyLkTWQAuSaU8ihu7cIC88ANVygNb3Au3/kCtWQqWENkjLZiEOiqELkG5OirB/piB rXMWAkBAXUIDQsCAXpAFSpi+T3CIMzgD6cK+z2mEdbiHdYAA8IMdbvKALPMBTgAVqRAo+GM/9mOC UukJFdjHp7gBJmhDG7gBCvgDfdiY/yuEBkA+LdgBAjjDAsiDRxisZAAMy1uLLqGwtbC6GYDEEgih r+ieiLsSnSuCIng0KdgAG+iBJlAB3Gkes/CptGAwFPEGBqSxnMu5tTGcG2MB9MGCqSufNKs68Gmq GOOKkKSxDmCEIUicxlFCJ3xCUECHTpADUHgFUOgEdBAGdCAErewFb7CCTRiCNGgCPYRAH2iqBZhJ iZqQ/uSIl9mgjVUxjnOBwaBMixxkFfTpnoRZlQi6jKC0AkZQgjlIKM1IhVUZgk/oHpDsgVjrj7Wz gCDqABJpjTnsrx1Yl7f4KwPhoQWQGBJBAJSSCxETtXUxELughwAADIpxAZ37v87jo8tLjEc4DTxa Dyn4AbfrL5chCLp4Ftbao1WzTQRog/WowU4jKbdwi0UojScgAI5pm7yZgQGQAzl4muD7xnKwh0+g tlU4gAuoCEGphnXYNm47ABJYg0MYv6aIQDRLiqT4g3L6MRU4AdnZRybwAv30gPaLxxuIwBu4AQf6 gWMJEFXqvHbBEEsknARgAydQmg4gjbRYAMGATkJI/oZHIwA5gIINMB8J5IzuCSEGE7JdeQJnIAAM GsIO+AHzkRSzFFBuugEw+ED88kgjUIL+PAEfYBWwUAIlOIQFYgQa46BP2KAOAp/yuboZOISEkjZN 0KWic4ZeoAQ08EZvdEI5QIct7QRhyAdQaINjwIdOeIJr8IZquYYZgIYbQIJgeAYKOAEB/YAdC4M+ +wEu8I1FWAAp+IqBAo0ZmLsSiLgf9IocW7Cf+gEMRAUjSIWqMwJUYMwmbUoRajixIMQfkA14UQAL 6LTSoIcOIAClGRqMWsh/IwynWU7AEKyCexLSwixBUpYAMAHBkJixGQyi8QMQQcOJAq66IAwXsIHW /qiR/kgG12I0iOQhFwA9XJAPHUmAodFILTmNCgUbNNiANnBQP7CC9UAANHgELPCGAtAEb/AGVLAH NdkGMyBH8cyTzFkHUkiUKDCDIAgCGSULMUCEfF2OOO3PJGiCfz2BWIgF9eIDPiA//WyCJEACFXgg aCiB00DD0vq9xUo+8DgMAVktbrUkBUSkBGgDDCiISbAEOeAnxGFLEooxQuu7a6hQlGSDNjhA5JID xnE7L8GCcsGCvtOMnmrRBqQxrlCFG2MwVWAwJssxGjMq8LGBVCifljyBISDaprsGVEAFVVAFLKja ckA6TViGctgETUADX4hCZ6AEZzgGNPAGZ2uD/o89hpc1Tj9Yj+NgUd8IgzBgqYKqlYGaA4jxjM14 FwxUi5+CRBzLMRy7hiK4B01QhST9hKhLhUNgWkboUd9ggS5kjK95kj64tMFaEUC4kC6xzVZqgDog KVYqgB1ITR7pjxErrSchpAA4LFyoEAygyFGQASkAls4rALjdzQOBiwbIB9PYiwwxuNIALhN4tAw5 DUtyATaQIsZYmygREv+IjxgZLIoZLLuYBDRMwA7whmXQhKXzTkgoRzo4gwhA32iigwOoAgg4L/O5 ATVABAH1ifn8g6ZIAn91nVjYT/3kg/BalCA4BD2EMrwjQ9tEkY8ZEDJ5sxjZXtjCAFZaSAWu/pBk CYxnZIxJ2AER2SW2wMAOkKDykUCaKJ+IOtznM84GOIa1ZWEE7KULggKjw0AiDMqgvAa1oLGeQ6iE CqEQCh/PgERWeQwm0EOPxLEhYIShKqpPKFqihVpV+IRrCF8pvslNWIZPUIEh8AYoeIQxJLi8+Fhu BI+TkTVEEpha0o2+ozl9odzL+AFUGJ8drrqFymFNQDpUIMxD+IRFHQKmReKeKp8ZWAA0mIutAZMN cIDF6qMBkeBQTSWRQSTd4o928bRnDREZeB8ZAIT2AZEAgAvSGpnB0AIp4qECoLxOS6MBaIMd0AsH IQxbW9DTYCUEKFaEc4sDtAs52w8CaNDE/qgfwRiF0yCwEjwNtwm+EMGCNyOyoysHVVCTVZiGkjDf C4DmA6ABO4iCqQIDMYCGcvqDLpKGeItH8ksCLyjngG2CNYAAVagHPTgERtgCFZAEWGCDDSiGJ3iC IjAAnTsWS9K1oSmAQvCDdUlQu1gASQuRwhAbXyWH+PA5DECDxEg4+BGMXRKyItBhB+wgG0CfH224 IxuFw7nJBNhib8DAE/ngGquxHkZE8ckx8QEfmmi4hBrJw0m+XsCCVFCCT9jhJDCGnmrKIe1hJpYC Vdjpa8Daa5CCTzBED2pq8aE5C5QCDAlm2lQWRLOCjNsx3VAoHruM8MHRmTBExdzhEBKy/puVHCUI 6shdTEj0je7xjRqZakpDABNorHYpRWUlFqq5kMSgtJGDWzwCFr5wzU/6MMHCANZkLQzZkcRq1rzQ kQLYAFZCwLEx0H/7XIitxQF4D1ywgSfBD8JKABZwG1MuANDLkAtStQTQi+BIgGBcgMFKpdZYgIjq 4kJgAzTAY+80g23wtmlKRzqABGyOghLgHrEYBAcSUEQolak4AS8w59c5BMidgW2QBAjAJhw4hCg4 BFrohlooiAGAhTPKsP5ANtNYrMKRpLpI7cNym11DAEDoBCegEAidrAFpnF7CIGcjWfmYqTT7oCYA 0IFMMx/miqVaILBI0pkOH8KTnSb4/lEf8ACFElEriJZP+pgDPEBrCR8ffgLI6akdNgIoXswhMIZY sILFTHEmbigJ5GiQZKg0K9QOegHx4Y0I+gEFMAKBmRltacxVsZXxAUkAN/CvtoJrKKodHqoe9uGq c2PjyLmwOw0nAIxXHpDD6q1nTBtV7ZDVXbkKWY3CmAsTGBO4gdUAoO0Y2YEGOJoBECAWqLSBZkhR LZwu8Y/FzpHJs4vCOO0NcGwq6RLWQCtaG8HTQJmDg5ALgQK78ZuugR+34xJvKAJnppx6qIVGOANv W4dtmADYUQJD+IrIwLeeGFD0ooETyCbuloSmZNJDwCZsxoE1mAMaUAGrgIWTzANu/sUtBCEaCzFs C9EaA3iWwqkDLdgwuEDDH4CCSWDe0jZlipLl5OutLglKDGHAmlRasKAhs1BaQhsCcVAolxYHK8g5 0y4IW6rQnOubK7ekR1sLlsTbGcAAa3GVGUgFHvVooNQEe0cohVICJrABSPwgkPxIJcgpbcmXfdF2 sJi7i+uBF+hxPO2NIDVE2QiLNIOxhms4oGq48eGp7mFajra6HhgCBw2QyfMkEouLScgAKIiRhDYQ /6gaRrMouSCMDjkMTjWQYwHoPqrrUcuLOqKLN2sDP28NnbMN91gAfwES3AoR1ONlfqoRXhmFXC+4 N4OSYlQs/3qEXOwPAcEaxHAB/rhtLQRgZYQDWULmYm3UhHLYhreH5ugqnW2wAz7wAqrQDnDiptlx oOc+ARyYA0aQBEnAiunuAVVACCZllfMKgjES5DwAkpHZEQGRH9Cq68KhBzSYBCfwGzOHm2SwBAR4 Ruc8LShBll5pADlYLdPOEPDgi0dbhl76JL8ZRKEVh1arWcQZsK5fC76AglyH2MUqAmwsONCyJHWh a7sgSMng6MLUQ7FAn58U0fIxgjYogh/lqSFogmosgHdJmPPpUfwaKP4SBxsQAjHqgEWQDYMxjtAg m0WwRSgYhQ4qvAQHCz81eAU6yjZUyw/aeBwECHEbOiwY4GQHAgQZChDIMCCB/hMMCAokTEgAAYFC FzMSKOACI4GIBFw0RCBDocICGUx4bOAiQAIHCfxgwFBgwICEGJwkSEDgkcNRHW/ifFQAA06LFxGY aFAgQYEGOySOJHCxQIcBhfxMJPjoSQE/GhsQ2FDAQU4tO1z0XJAAQYINPxZ4LMCw0DIoyzShYgRJ EaRGqxptWwcpkJcgYMD0EKJESJAmJ27EOhFEj6RppCSZOSTJiCopstAUsTJDSY85NnrM8PChhCG3 DG8y7FgI5wACDZKJHekRQQMnA0wM+EiRJK7cR+VgBF7RREEEGAC16TiRAJq4WXviXFYAzcQibd1C gQJ8EhoCk5zaHUCxjcSn/lA7PiwgY2iDmjJI7iCG9KlcM9hQAoElCNEDgaixoMQHStjQBDhWGKHE ISykkloPUpA24BAz+HCIgKgpwcVcBbSBwENFMDSJDHYVkhAICzwynF0OQcGWFT/Y0EECWHTQgRUg LMjCD0OUYAOSC9rwApIbjIJFAk8QsIyMBGDQRgMTuVBIBtJpIVFFEyXkQm4TOeScShl0wBCZON1k QQcsOeBWAgHcxBFOZBbCox9uiUmRlT9Z2cAjbhWS5YwNaGGEQlJ0INR6CEAR3U0JPITRfGRydxtB 7mVAgAlYuPlWAYUYldAjHRj1IhSa8LUNJJBs0wgrjaxTyyFB9NDDFjNw/jFDFD3QoAITQYDICCnJ JltMNE+wwQYC3njzBBQP+sDCDSWUUQInHyhghHuzFTCJVQ/dmF8hJE2CwEcRFUDPIy/adREGCRDD 4kiHTvLQAIUCtRRbDE0ElRMT9cvdVT0lAIVWKE6y01K2cfSwE+R6ymUBLNFHUXAYueBEGyaAoJtE eQBpSAEG2PDaD1z4oMQNJ/jQxAcz76rEDD18sCuRKyMohA8znHbCBz9ggQUU4GGk0kSTFBzSRKOw ZBfVdmHg1CMGQGFVATM+ZcECC4AgkAFYmMDjAh1sQCd2NzHcb0JPLZSTbky5SZJ6CKS7lEf7aUVT HVMNlUEhDpggQzII/jhgQZ3QgWQCFG85tUG4DQxgEwZ5fLXRI3lctBDV63ZpKUgECJVxehrNmECW DDUgB3S4AQdIHTc1MAlLchYSVUcmcG1X0kij4QsUqGxz/GCb3DNNDziUMIcQUQRBQxJe9DCEEUNE QcMhtBTzTR6+sGEOO2y0gUbXhco1IAs+DPiBB3D8YABdD+GSDAb0aURATxTp7cIkyFWIPECFIu8q gDjyAYjEaUlL/KuNXTCVAQzUgUzJ2AHfxGOU9nhNPRLZwZfaULAX3S4jdrGUwPAGHCe4JGMyycBJ HEKSqKjlauTyyRO0kxucJKAIWPiBFUzjg131ADVN6IEN5oAgAZUg/mcsmAELpAAc7GRAShupSAEY Fzet5MsFVEvAAkZhKajoDYwJeBEadvKU9njRKvRwjxcbcCITPqV+JkCDCcD2MRSxBDgZe4ITsCMd DDikRgg4iBMi2IAGyKBLEWmRSkwAE5wshCwOYaQcGuATpMiABYawVAeQQi4E7Cs9JiEAWApQkFHk AVAF2AFW6EKAghjld9LhH+u0gIC5QEEGxbFKVk6IIoHtbmkFEM4o5IABNLBBClawgyQYsY1vMIIG 1LMmDXrACCPkTAkl8IAV/GCOJ2xASk8wxzKPggA0dMAG5rECCwY0oEEMYjUeYEIJrGAB8zQHfeHy ogtm+BDCjSSg/occSSFPSRL3YOSNLqhJAZ6QH3q1wS5coYqMcHEdfiWAXAS4nBaSIQNF6RIDO0hc fmxSpoU8wSSvsFxuwPJRLy4kAV40AQLq8AjdAEJgA5CCiiaVHlUSpEcLeEIRhoCaJdrAm0KbQQl8 4AEPLAANmuyJehqwO4rkj2MFa+O6BPapnMCFLgYzAOvIMsKwJSADaHhIoQqhyyjtZF24EByo5jOw rDbHaeD54HT4dzm0eMxSC8iAE2QwCa7KoCcZYMsCAqAQuvjhTnUbCXAIRw5yIeUtFrnJKBbAkvS4 QEoacUtOHkFK1EJlRlwLVysLEDkZzYuLk4qKHCdiuRmVbiIR/v0oSGxShBmkIgrdY8QMJHEI5M7A M1FYQxKuJYWCWCknbJAjTl6HgUkUoQNWRaANXhYGFhipfTUrgTd/IB6cRG4A6BvKcMK1kCK4d6Qe WRc9+mgXenSJLQmwKlkeeqVFfhQNpb0LTix2k4LkpCg5VaZJ1XJBshyKPVYBix9kyrUnyIANdREt v27yosvVZD5FGAhuTkQtFRWgCAigxA92ZYMQzaFDDLJBjmSEot35oTpMg5ZV1uME9KEBF+saWFQm AR9AIKBKs8GqmBrAhtuwqT1uGUpEgHO7il2kPlfJTbpMaRXi3GRLT7GKTawSON9spJEFICAP81Ac ySZgTRgp/mRPHHCTDFDOUiwwi1WScTsUdXhpD4FK6zKihTd3JGGUC9e8bkmcrXgJK8CRiKLyl5N5 WSU9LDJwHd9CFXNsQgrfUAUtJJFcYK0hCDNQRTFYcFSkLEBDfkCDWPzQw0Dmz2xbXQAWAjSgdjCx Bz74wM6u9RZcUJE2EXUBGkCXALBRRCODZItqTfAIByAgcSZoa0KsXZHtKuQRPqkNcAphKX/l5oy4 IOky3WOl+NSGoUCulKWw5CU5/oQNGPhItDmMgKnAxQiGVRFOcH2T9HS3BOSd8WkQpAQfoHcGG4CC ixcZLum4QDzHxEghTKrSQeXHKRdxCQEquoA8hOkmBvPf/sZoc2gUIqCyVjJYTqg8JgPm4UW+7V3E VKKS4iRABpg2ev74SJAuFRIQAaCPDGQwlwHUAVMD8INWd2B0nGolNx+1XELQV7VNu2cAlsiSRDpX iHerm27uMWkhVJSfYfKrA1axyO5s4wejyCSixHFvTxaJAGcVAQpPgAWskWsEIxQDFpvoBhSkIDAW 373Agl9A4v7LHqU9Yn0DEtqMB1SCndmASBuga3Ou9hQpPYXEecNifMNIgC+hDtrQ/lRIaiIRuK1o 7jPXXOek47oWIgAQVwOJ3uRdwkMPYBR+SBwbtKCFLM0HPAsZ+C3518q4SJ4NgiYAFNT2gxKcoAne RNCR/hZU8R9EKSGXwoi8xS4wjJj0OocU4Q4QspQ2EA7kisoSR8gfvvUQdzAEv8CVEyQO1ZBJLVmE U+BU61DNI4zSR3yKdNTBAnxOQuTHQlmKBQaSfQRAfowU3cFFdrHRE3wKIV3FLGEAFHybA3RO1ahS aP3ADWHA9C0FDgKCHOxAIhUCObDJUtyGVtSZDfjEMEHNm9XZAPiITPzAD9zcReQdBvgCLhACdrAB AUBe4T0BGnRDdxWBYA3AdTEErkmHU2ABQghFA6CBvoBEAfwQCzxRCXDBHApNCUTGCZyAwxXgIo0S kmEAOVjb4DyFuZ2RDBSCjl2EYo3EJGgBkzWA8ZUW/km0ASAIDhgZ4HxkxIuIkHQIQ00cmUVsUAa0 12n5hAm4QP7VRB6E1kOhiPBlBFxcRPgVBHhEnnlJ3Bx60xBwyAlYwQBMyjIgQHU4VpbczbvJEQvx VZA5R9wgIZNxBVlwzHX4Rtn1RGxVjm/ZhQu0AV6xi3jo1Ujkz7wB1GxkiRM8AblEhCVoQf2wS0y0 xEmwC9V8TgAUzGyIVgHgAlugFQGgRW6szglOwiNggEZwUBGYgJxZilWIwwAsAFUkwCiszQ7MR6Gg EFkJUkbgAhHOR3uYCKTxTjcWgBFQzpcxFCFUBxTAAhTcGhbWGoO5B8sxhE1VVBG4AFkwzAvmjxhF /orArMtDLIAV0MILOJXQPJEdzoAQ0Ixr2AAUZsUgCdYiPYUfQQX6dAmzqZIF5IFBrcd6JAMkBlBN jISB7UZNWM4C+GTr6N/StBQGaJRV3F1RxERO+CC7RA4CfMkk7MAkiIVUSMpHiBpSQMES+tAT+cAR GFv6jd8QPJwSKEH25MExSNk6FQFdtKEXEeG4XNDVZIRU5M+hxEe6uQkbkEup/MRb3F1ttYel7M/x cQ0aLhBcsEl8fYRFrMskGF8EjduggQpNOIEToJUFNIRe1YEk0kcCGMBRaIGdqBIPDcQiPAQB1MFD 5oYTVFYrrgmD1VxckhZ2hM0g2cUCoEhcJgD7/mUgiuQEvdWGF6kS69iEWfkWLAqeoLWBFhCABdSR C0BBflLEuzlnyT2BvF0XG4AFzbFBwbSIN06CF+VEekjn1ZCOU3SAqNSaFBgCLSDlEznVr7BAg0TV ZLwGa5rIkI2nRLzgRbSBoBWCga7KRVQMCyVgIO2OcUSFDbFHlmRdlsCfKwGKgfWLAUEOHE1CMvgk xywWBkBLyTEMRZAhArABGC2AEcwYk4jeHD6RjPUig3zABlRUIfhbksqWTyTDVSCZloFcyhnfKInm DrAHx3QEAIbbVIZLXNIGvQxZN2KEFqxLRyTAHX0Ei1rEDB3TlUSab1hEqJhAHbyWvLkALhSM/ktg BHG8kAxYgmQBYHEsgEz8Y0vN1NLEZbuxDilVxEik0rfhkUxFxagmgyVsxUGOHUZYYkWRHbmgXUKI BULsnk/4aXJ0QEIkgKYNE4eFn6qGxU1ICanGUgFYAgL46vxdjaiAAFRIgQW8Veu5nwmYE3bAwg/M wfM4XDGAUTEYwRzKE9CcAAW4xgzQhXyYCIoQppa1mB9hQf9VhFgmkmjtztRcjUYgKTmqFpo1B4Hl xkdoobx1TSryaXvSQ7pM21FoVYrmz4ywQXr0xCLMwA8IyB36ioAc5R3a4QZggRT4RHUQI1w8we59 xPSRxWVqFUMJ7KdiUN6cXHtayU2ASf6d/llGKFl7KgVD+GABkMNMeVSW5QvotJ56fJRWzOgABEfI KEACYJBJ3JlCNES4FEQGkM4DBcAAyIQl3VmkVW19aAUxHEPz8Yixks5bfdvWUI1y+E8mntwMZsRF 2YQDtBQsDQBfXg6SEUMbdBxc7OpTUJpv9csAMM6C5cGcPoUDxOVH/QigdERXPQxZwEWTaQxCWA1I bBoBsIEfDIBlAhstIIiAqgh5QVGRcEhT2QASNIEKGMEPDAR99VBErdsOKBNd3JRHdEQCalW69Mvd tQ5DeeYwZVqkfESkDIWLvIdBIoBRoMF6wMdEJE1+gEcbEkSwsUA7NAiS+MoPsMBiTikS/i1I0awJ djBUjk5f4O3LAogh/ugVER5K3Hhl1hWTbtTnoYlZWGCAMiRSemgBMbQp3g0cmLQhGdWfewCsnd6G pQCCFrCEVmlUpOKkHHhgVRyEwXybfbQII67QPwaA70ynelSWpxRAH7iV4ngOSRwfUQyhdBjaAmxF g3bEJEgwge0UUTBMo/WEupBFRxhF4GVuyokJipDE2yTtu8qbcnQtoHRJA1hgfwUuV1REgLHBSRxk Y0XUMXFR5sKNFrbYjDDTQyaAkTQBFD2cEVjBBjgKedmhw5WAkXxAE9CMEvyA5BUAxb6CFhCCefyh CSmHR+KkhE6ElPAIAUzF2QLg/pkU/gDuT6PNhtixqvQlQ0XtVHY4UweQa+gNCM6U3owRCXmBb7mu zQJQDkN8sdK4x4lAAcsNxbddFilp1FbILWxuRFxG2MsJ6qT4zp1EhDLdzhdrgSWglPHlxxoVnxzI wEmBCYuwS8g5xaFAW7oNk6YKjHVgQIuU3UaYgAZjgH9kjGTBIgJkJe6x5kOEMJBRotJM31h+m4zI gIo9ArRB8088hN2Vyp2MklY0ACHonhgRhV1MVJO9nQyAB/+oigHl0NToTV55hLog1u4sBElkhz5W 2di1xwB0AIetXXu8XEa6jRVpQQ6VZB5AwQlkbOlZQQdIAdJ0VxoPgRVAHBT1ooAU/hF5UWiwxefd OYGp0A+NhMx3WMQhrchJOcXllJBGLERIoVzYgcepoIEWyIGKtkGP/MiPTCl6HUmHfHIa/wAtoDQL lCTsDsFKZwV2LEVCrAs8W45HAor7YcFyjnPJnQhGAKDLicltkFBNhAmockcC7FSyvug49yUZ3c5a AAUOZu7t+Y8cncROp4QJlEgykOkFPk0g0UhIGGelZMAOCENPOUAA5E8C9EERf1RbLIJz4t7ADZm8 xeV+hkXkJGQaURD/nFzdOBkERQV1gBGJGYxPJMdeGgVOcARJbNJEPBptbKJvxSND84RL/PVsuACZ CYy13saMFHcHKADv1LBpQ4Vj/q9T2XnNduUPDmrBufkQStuAwSFNRncXsAUIVMX3agwRaoTBD/zI yOIxLiQpS1wXBqSSwGBAJsEfbpwRfD3oVajIehyyFqABeGCBU1hcjL1M6DlVY/4A7GZPYz5R6c2h Hdca5UCLlNA1KilScBACinTQeewVD6L1IXEgmNx13bhJQN+ZgQlfw3RaqeadLetNKwEHAwle0v4T vZzl7kTKYqlHcdhHVTTiQnwKcTyWvzWAxnTJfVhKAJCEW1mJ4DC5pZhAKYYwcJBJ1WhEbpgmbRiZ Vl2mUQhabuxeqSTFNMqIJDJH0b3vwIGZdIaLexGcT3AJYerZBjrb7hbC7nzJ/nCoR9dABY2SiXGQ GcakjQG51X04wI8z2w+bkQG9jhPsKUZMZnWUxhpnsgf4wGQMgRREjsiusRUUQxDRwhDMwVHuCrKB wQ0gmxWEjYSIkT13AFoJHZnluDVzSdw8Y0GECoVKiBE0gRWUwDhcDxRlD3mlsYRIyPc2ZugNQWNa gRRMl3sUQaZVntglRQ1XhEP0D8mBCh77lkaYkq3Sh3XwZW14DaS55UZeDcgMxUiF1bi8pbUpyt21 3cPUhBOUplAnkv8Y0CsJ+MGUjvJK9OB0rW6AoHTayQAsxH2gCFqdhKUDR9gEx6ER5nAAEvrklMsW hLVlNFTQeJVYCp8/GZ28/mBGD0q1NS2KjOfKW+6nfiRqJYzCfxZCLMwhMd/yWoDeZMyMQA59ZMDn 4oTvoA9hIXx4u0fBmIA3/JuPfEcbnE9ETYSPoFIHoEars3ThiYdYO5MULJ7aLB4L/Mo3EY0PCAHR XOmMQeHKzIB9q/GPQOH3CgiSOFw8Hdux3YAH7EoT9QC5Iv4GrPEGpLERiF8ozwBNY2yuC2UBtVTq tYGUABk9pgcA7pSP3YVUaAFV91wbufgGWvcZuUcJfdbdgdynnMjcHZTbzN8iSYQ/hdy+bNv8IZ8x iYtC3MhZRJB3M1JCfLdKIOhQOMCNeMxI5MbTrTx8lQnXSKJdkINEJCfa/o5LRfqjb5cdRhREVDib 4RqqvPgUdT1FtGGJdI5Cfn5JDi0A4tIp1SyCjAQkWfXr7bxI/+Azu7ALQBBwgmBAAROPChRIkMCC HwQNELggUGBABwIyCC5AgKDAIxMIJrkY8AhBIY4ITCRkw6YNAjRFoEBBs+BJLzloEiywYmSGkjlD rFgpMrQALCgbkBphwcJIU0NKaRnawGJGsR9Lw3CZUeJDCR8fbngYoe+ZGgoUEN0A0+SDDRssfkjt sEAKFilFpOSti0WVESuMaFlhMWSIkSEzhnQgzBQLTCiLnkBkgwFiEQIE0DxsSWAjZyeTEDhA4GSi E4iTMGhxUuTRZQSc/jdiJEDycgE/BAoWarCjwSSIGNo0wCBjYgHKTtq4yHz50YIEhXA1SNYAIgIZ aDKw4ViAQCECLhIU8D4JowuChTJwpigSSgaTA0Z+T08x/Xfr9gkkGOBA/3wXASZqYAD9BpABAwIW MAAKBzpIII+UCtyhgLkIEA4DYTBgY6AnFHLuEeEIQG2ABR7ZQYsC8piEoodAgyihERMQrpA8BhhF hmTg69C1lKAYwLICJvEDtI0KSqiQBZAbKDME2sDAhVEGQGChAT4rCUgEHpnyNRMSMMEFDCxp4LIM 9sPATNwIcmGBDkyYZKCICugNJC2GREA7NApAgwAo5CigDfiegKmI/gSk2GCGHnpQQokNjPDmLryM 2MAQK6RIYANYsKAUlkI7wGLNSgfoMYEicixgozwJ0M7AhDgcMAEo7KrLCCz82okpKwhjdAYWpBgl UiieCPWJ4BB4IoEK23CCEAxwqk04Nia6zDzhGtCNIOOmg02hKDmbLQ/uMNugAAMx8A3cHYSZzsyN 2N2oDdheewgBDDiSYVncvKuw3ALIdKG3AU2VyDfcHhlAOfNIY84BiqozGDaRzAMEATLDk/Y1ftuo AxACAhgoA37HjREBAwhwAL4ODBjgBwWWHcCPgggigBjqKJtoIeoKEc8PMxeat4FH/NCC3lPhe2iA QhIQJgFctNAi/jPqtMgpvNcGXKBIeF8Tc4AQcQNTC3YJSEaYBtA48LPiHmrAhSIsoMjgjWZCoI4d SHOBokLI2QEDJ4graSTuEgIytR2soxdaPbl797JJcAsRDbs5LADaDkpYYKoZBhnMBiUQw3UoLLAY dQEoErBi08YWELQIBKAoIjg02JCjDTkQSMalzJxZyJtroHDumtCD2qkDKZTwoakhQNcP8QJw4S6i zNAwoQgXGJ+X3omG3JtF7swjfMqUOBsatwIG+i4hibybWLiHZGtXoodMwyjeiQtxaMsFiJOWvLtN wIBwiErTgIS8pjvSAc/R8nOq7lAECggZDbuok7/vECA7TjCY/gy41aEMSGcAAehARUY0kaqZAA0y ONaAXCUDAT2iAxtwwAIAl54BmGBEBkCD2mBUiA1YpFo5eQi9CtIALUgIA4CIGgJY8JyCZIBJLvAU iQqyIIQkxDUbgWEhEIILl5igSf6DiBO044I2cJEylKEWGka0Ecbd0IIFEYkJnmC3AdRBCw342JdE eJnu3AYBgMAARQzyEC1srADmAY4MVAS4blFRSsYpDms2YBcsdMAKPvgBYYxQl2tIwVGNecITJDm6 TTTGFwtQBRQ6MApYdaAcWFgG6a7xyh9cY3g/qNUOO1U6K0BBIdyRjomqBRvtyMt5z4PfSQLUHRVS 7zWToKFJ/uS0ESaChDrVi1a7AgYugXTLBX6QiECEUweIkMk61nnTRL40HHnVATcN2JgTitiGIbmH OwajFkcGhLbzldN/jHOBgeDEGb2JZFzCYaIMMtAlAgwnAB/CBeHg04CcYBABi6DhAhZgMlNRcEoJ EA1zFHSZiiTkj08wgNUo47ZqzUtos/FOZoS2g5x1LWsJ6ABFCGSCHsGHhuDqjH5S0wATYMFgTzgV FS8zigrNazz8QtrWCNI2KdHQVfBxgAUeIhLnLJI7OYsSAghBuG7VzhK0gxnh7ISviRDzIQHyzuCM mqdlLGAIUrhGD2xghR8oygYz+AFimrIBKeykUI0RDK2s/oCFUcwAC6ZqwxOGhyu/UNIKDRoU6TDj J7K9xn87SAaCNALAy8yoM/mCp/qQSQBnbKQ61XIAGuBZnYiET7b0Ug5nPsYvP6SnEP6qQxmFY5od +PE1ZDIBdRrghOgUcUUNmJsTClAHhViHO2A60LyuVUgMJGNdCkmJfggAviH1JgNAayuXDMYdA1jk NU4wwUW2o8JkBGBECrEAfzCQHgxsbVsU3Gh1bkMcX4oTXOH5wbdeEZEfJKcj30LIWinjHXJsBExS IoAfKJI9M4owS99KCOnEEz4pDQBMk6AStAIHOPFYOEDggo/NKqSQJziBQ+ab4QthiE6FGICA+aJI d7Bb/t1qIpK1ibSbqQTosx+WRGvzwuAknoAGNIDSToVAQ0sGlQAsHGUwvOoALZRghan4pSl6ZdQN rPCqTsgBCkOwgRG0HB5gyYFZU6Yzk+iFRpBMzKYaAUlxqGiedgFQe+x63yQyANtGVnE36vqtb/TG EUFHxH6mIedoMPImBOhNwIAs50bgSQ6DZAA1gGDDexPAg3r6y0lUEoaEBkgZeYGvl1gagG+q44Ie CboAGOWOxi5zpvEV5CKgqUMAEgACS6VsYcW047EgQp0N5ic8uKCMoAeUHhOwoAOqSYAPaIKhBvQI NAi6DIUwoMMDQwSGKe7OQnujkIU4B3DwgeqIc8SZ/gbI4WxIpSECTgQuoaU0T8qpXbXAVUgtSgs7 BEyuQvTN2pIQ8DUFk6eYCCAH3vyxAMFqDXUqlC3UaNFMK1ZtG6jYBii4BDOput0A2qCdJwCrDe+K eQF4SVK4WYFJAP9sBzrQo0dc2UBNi5ccbEeAmieQMmg0VZxkvWRQt6s73H0gBDmiH0a+DxCdAARo 6GUqic1WOo+mWav51a0JwrecE3lvIS+DEQxGqQFyn8h80n4xkgjjaxLJUR8xkIBy0v3XyelOlzSk xX4JlzPEcYLEvrMf510EQBDBcMcd4JD56Gc0FZKoAA3ggItQpiBVU49JMSt4lJiKQeAtRGrMWIgO /jRgAaOoZwKUGrMRHakA/IGP611VsIR4+GoHgo6LJpIZdPkBIaip5nb07UfcjORt8nOubmQA9/RY 7zWI640etZuBdwEeNa6p9UKTQbg4cReGxZqmFsiRKv9tbQDBMpV22IC41QK8E1/LGc5HBQrYYKNI jDIswSXcpjU0YxKO4V1MwkxWa7vawCLWJdhCpGYeMLlaol0iYgf0hl6SC+AOBJD0DTR8Y2iIyVTM pDfMxLOcyzS0ppDgR+56Q35kQDaWCDYmCMnAqNAEqNnMYz3iCU4MAuoAZ6YQDeDwCUWMg9O8Q4VQ om0gQgZoRyIMomKIIwDMww8sBXAMhN36QMkA/ir7PiheMuCDKkS5CMAABA+I8CcfwoNenuBjMqLd cqIgWmMicsYSFiI8BoiB+Au8KAKj9OMRUkSE/m8jZkwL5AAQ5CC5UkML/u5YdG5rWjCYoG80cAGe diADBgKQwEU4esk+EK4QgihE7OZeoo1e8sAPl0wFMcBqGAczSIxw2oAc+gSfgIUAOATDJqJHdENF 9mQAlgOfTGCYINESAE0h2GASkoUjOGNJNtB/JjBOTsUkOEOLTNF5guuYrgMQPtA0WmKIyEMgRmMF 2cU0jEhoINGLqOmLKMxJ6iNeYEOc5gcjwKft/CUDmMg0BsLxKOhaltGd5IAzGAchzASEzgem/gDB FAViu/yIOCRCJH6DGLSgDhJGjhygPgohAArAAK5razCCHF6NifgohIhBDvwABDLqg7gHwxamcQDI BZ7g9aDxhwAJCkjoY7hma7yjATbAO8KjIHDBO/YJtF6kD0OlYpLyWP7IZ4wIHaXkIfzA9sJDaHyy AVDu1g5kAJiIjoZLYq7tBl8jAcxjQDYtpjBuRTCAEOAjGb5Ge6iDhfQjPJCPMgrml5xkBwqSM9hg AXjRNoTjOh6iYEyRJMxkGWRwEpqGiuroj6LkTwgqyQZiWfIEBYMDNejlGFFQPSaPXT7CTPznQFTE TEyDwtJJ0GzHQgrtAj1Qe8inJWQw8JhI/ohmxlTiRX7SEAZlwBQ3Ul50EJx+jDiopOwKqWgyzBKE hoAEwrMGAATSSwb1pkYKQW/0yDVIo/cGxAG0kgB+K/uIzQQWIAMCIL88Kk7ET6JSxkGoil+yzRRh aDdkoEHkAiIqoi6xIPsuIwGe4ED8EDxsozPODj6AKE4eQQj4q74GoBM+C0sss/YWwQLgozW0YCJk yiHWiiM64CFkrwOE5DrnhRxkjTwGYDe+ZobsZ4Kc8jr0RT16JoEIJkpakLtgDxe6yExI7mu0JQ+s hV2cLaIwAMPqjlp8EQEapBCqJDX8yBk0026OUQtmRo/c4zaa8wDpLN0WaiSahDQQcGju/gln3KlJ vkYKrGcglDQi/mw0muYDRdMRAaE3hGPsYAPXiKk2DyTu4Am6ilMkHrIz4Gl8qugGTQPu6u5tjiX9 LjJNioQ7TKPvHIgzHBEaXaMQJCaDZssF7MYP/i+3vHJaCCjtCikA6JE7xwUyi2Mek2v6vsXz7Og1 9FOnHAAKREI38ERuPouEisVq1irS9gtbBETfFuAHTGUk9EMc8Kksq+oRimCjNg1pCEIBXSRU1odG +umaokkLCKEkgrE4aEgGZMoQytA6uhEBuLBE9WY6DlNfng/5LAThNs1UPLAQHMCowE+nMOMAmedA vJVerE1ABgAXQAMGUaNpCu1UHmGD/tZFIsTEbggAFwDhFcwk/QZAHGBrxujFGaCQNzrvrc4DWnYD JaTpaYZo/AhoS8+Ru4RoB05wZE/zyAKmJcwjWZwAPUIkOvJjg+zxNGUAEET0QNLjTTJAYYeDXszE QOTumOhwSXjt3xbHZ2pt9ZbqbbxjWtKOTLhDhTSNX5KLJydCVJdK9MwLZvpGXEUTN8BHYeUNgIgN 5lyAEMrnq6LvaxJiAdCgjnTjObRAGQWP3R4hpWgvARYBh17DAqaEImiopQbAAhZgMl5DOahvrXoJ RELMNzpjOnGDPORAwKKkDhBgASRUImTACcqH4qhJObdjXmSqcUertaLHaijsa3xo/jN3invGpjap wzoJIG8H4iK1EjkozAmSIWeJhtXkJ+yOpo8GqREx4BE2AAGIQTORI/3oJWeeQN9OlDOoBwTFZICu 7jXSJzuJkY7oZTlZynZ8AzQGhIbAyXq+T2xJIwGYyE3qLlr+UdOoY2KI7R8Lyn+cgHC2L7fOkUsz om/9aaMsYAMGgLhkK31kIGOaJrxyRnG3hjzINWgXytTgaWMCIBkwSPwAlSePlrUwwm1IkGq45d+c RDvCLoGEQ2WL4L1KT0sSghzExBTnxcSCqkS8oxAs4XoKgQ1wCKfuzXvTZjb047ZMpW8kF16n488K AUIESQbshlokwnaRQ8AMslhI/ipIDPECuUNPfugARahwcbJBhIggnsNnlM7T1Kh5cjdMztggIULQ TOQDF/ZxQMJ/koE0ZkgFheOBjyVSRZOOlnNEWsN/6ERf7GR8v05bGIlsIZMkTOS6/BHX1EZe2CM0 kWNdHoJM0gN9tUk5yMQri2Z+4Wk41qO9nKeI7kMGF2402uBjpMMJlI+W1wN2oY6aJK5M6YZA2WkB 3kuOMGYiRy8Lt3fThkOF1qoBqpeC4u7U0sadKIMnKWah0EqAuBABLEEYCuAtEEghMtA7NCIZpgvI XqOHe80dtUBxhMh2FhUnogSNUCjEIi4hhGMDQcOXkmHCaqPjoKjc9MMJhKbX/uYFHM2IcdIHne7X FBGIgARmNzCEodUON+MFBGlrfd4HgspFTIXmfC8juDijDUxk4IRxI94rGZTzMLnDTTZikLLETUzF NE5wb1yEG6dDOu60UW2H1/pRNNMPEB6HfKT3O7oI1K4LbBi23KQpuiSt8RymW3hyY+XnIYyIc30J mGCwK/PlRo6aI6BAoLXnTUMwbUbxfQypvfRGgKzGiPQzVRXuQKwQtwogAP7tO9uggUUiD+wm0fjl h6BqhnDLjhimZu403ThCpnCDl4rjo0OkjpKY4wTo71rKOBKpDvDkSnDDDxdJJNAwIggB8i5GRiem mMJHRSpmoSixKNNjryNP/oUMerSjJblqdYgASF7gZpomwToRwkIuJm04GUzCZKWtmV6ahHCKaLvo bN/gFDg0WivXRThMDDGh63woN2f6d6bMEU5MokW6i+7oNGf2DYiOZXG0ctCSjrXeZFpMgzJYmgN3 WbvvtO0c5jQ/BpF+a5y8M37MtroAYRPNSWErUqyySgU7Azi2ayP8cGp81Glfjxj+CH5dhImKVlqS izoYtmsTQga0A8mGowh01XwcAmocXMOpBUMwLFE1AslAjl5IZLgiahQArgDAtQD48qiKIz6FSNYA Rv0SQFM7xDbEiJaHqHY+MBmyFT6w0fnAOMIc2TN6Q4v8VGs26Ot0UyTyq/fOPkbWkAo6jInCEC5E 5ORODXIFhUhoxgMKJsF2Cgk00ieP1eYR942G2QAXoIpmzCEZuAs0XCBnTELQWJphneSB6GQjMLXY LrC2o61OpJnazCNEJJKbKNi95RieFH2s0Zs8HgeIC6fCyykEC4k6BiK5vIl2ysujCsIEPgaqaqMO uMsJnksGU7UzOEt01cY+JqY7iE053Gm6OhF+iyjC2c5qDcYUU4JfAiAgAAA7 ------_=_NextPart_000_01C12672.8CF97350-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 20 04:06:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09162 for ; Mon, 20 Aug 2001 04:06:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19580; Mon, 20 Aug 2001 03:41:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19551 for ; Mon, 20 Aug 2001 03:41:28 -0400 (EDT) Received: from mail1.belgacom.be (mail1.belgacom.be [195.13.15.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08981 for ; Mon, 20 Aug 2001 03:40:11 -0400 (EDT) From: jan.van.geel@belgacom.be Received: from exhub01.bc (exchange.bc [45.34.4.231]) by mail1.belgacom.be with SMTP id HAA05173 for ; Mon, 20 Aug 2001 07:41:27 GMT Received: from 127.0.0.1 by exhub01.bc (InterScan E-Mail VirusWall NT); Mon, 20 Aug 2001 09:41:25 +0200 (W. Europe Daylight Time) Received: by exhub01.bc with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 09:41:09 +0200 Message-ID: <632E865A5993D211B40F0008C75D16A208E0FCA5@apl441.bc> To: sip@ietf.org Date: Mon, 20 Aug 2001 09:40:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] SIP question: headers Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Dear all, I'm new in the domain of VoIP and SIP, and while reading SIP (RFC 2543) and RFC2543bis-04 I encountered a problem with the contents of table 4. The problem is how to understand the table correctly. For example: The first line specifies that the "allow" header can occur in all Request messages except in the ACK, because the WHERE column indicates R, and in each column related to an individual Request the "o" indicates that it is optional, except for the ACK. The second line specifies that it can occur in response 415, but how should I interpret the "o" fields in the columns concerning the Request messages (INVITE? REGISTER, ...) ? A second problem, related to this is that headers, marked as response (e.g. warning) also have the "o" (optional) indication in all Requests. Does this mean that this respone header could also be present in a Request ? kind regards **** DISCLAIMER **** "This e-mail and any attachments thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation." _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 20 06:36:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10302 for ; Mon, 20 Aug 2001 06:36:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22965; Mon, 20 Aug 2001 06:21:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA22937 for ; Mon, 20 Aug 2001 06:21:03 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10156 for ; Mon, 20 Aug 2001 06:19:42 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 11:20:47 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9E21@RSYS002A> From: "Price, Richard" To: "'zhigang.c.liu@nokia.com'" , sip@ietf.org, rohc@cdt.luth.se Cc: jdrosen@dynamicsoft.com Subject: RE: [Sip] Encapsulating EPIC in UDPComp Date: Mon, 20 Aug 2001 11:20:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, The discrepancy is because the second set of compression ratios does not include a user-specific dictionary. In this case, the compression ratio for the EPIC algorithm with no protocol overhead is 9.78 (vs 15.53 including a user-specific dictionary). The purpose of the second set of compression ratios is to check the protocol overhead of UDPComp. This may be quite substantial because UDPComp employs a standard decompressor, not specifically optimized for any one particular compression algorithm. At present the decompressor doesn't even understand Huffman encoding, so an explicit 1-2 byte index has to be sent for each text string instead. This reduces the compression ratio as follows: No encapsulation at all: 9.78 UDPComp encapsulation: 1.17 Fortunately it is pretty easy to add Huffman encoding to UDPComp, and the protocol overhead is reduced substantially. For the most powerful variant of Huffman compression the overhead is as follows: UDPComp encapsulation with Huffman encoding: 8.24 This is a much lower overhead (5 bytes per compressed message). Regards, Richard P > -----Original Message----- > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > Sent: Friday, August 17, 2001 11:47 PM > To: Price, Richard; sip@ietf.org; rohc@cdt.luth.se > Cc: jdrosen@dynamicsoft.com > Subject: RE: [Sip] Encapsulating EPIC in UDPComp > > > > For comparison, the compression ratio using only the > existing UDPComp > > tokens is given below: > > > > EPIC algorithm with no encapsulation: 9.78 > > > > UDPComp using existing tokens only: 1.17 > > Richard, > > I'm a bit puzzled by the numbers. According to your own data sent > earlier (http://www.cdt.luth.se/robhc/msg02428.html), even a > generic LZSS can achieve a compression ratio of 9.87 with a combined > dictionary. What is the point here? > > BR, > Zhigang > > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 20 09:41:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20055 for ; Mon, 20 Aug 2001 09:41:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27908; Mon, 20 Aug 2001 09:32:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27884 for ; Mon, 20 Aug 2001 09:32:05 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19411 for ; Mon, 20 Aug 2001 09:30:48 -0400 (EDT) Received: from lms001.lu.erisoft.se (lms001.lu.erisoft.se [150.132.144.19]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7KDVmK21847; Mon, 20 Aug 2001 15:31:49 +0200 (MEST) Received: by lms001.lu.erisoft.se id PAA06375; Mon, 20 Aug 2001 15:31:48 +0200 (MET DST) Message-ID: <3B811142.4B0321B1@epl.ericsson.se> Date: Mon, 20 Aug 2001 15:31:47 +0200 From: Jan Christoffersson Organization: Ericsson Erisoft AB X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Price, Richard" CC: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" , "'Jonathan Rosenberg'" References: <76C92FBBFB58D411AE760090271ED4186F9E1E@RSYS002A> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [rohc] Encapsulating EPIC in UDPComp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Richard, I have a few comments to the performance figures when EPIC (or some other compression algorithm) is encapsulated in UDPComp. As defined in the draft UDPComp is unidirectional. This means that all messages from the "Simple SIP to SIP" flow from can't be used in the dynamic dictionary, only previous messages sent in the same direction as the current message. This would have significant impact on the performance figures, I believe. Another thing which I think will have impact on the performance is the choice of tokens. For example, the READ-token has nothing to do with dictionary/code book management, it just says ''read from a certain place in the dictionary and append this to the decompressed message''. But this is typically what the references in Lempel-Ziv compression algorithms mean. In practice this means that we are using two tokens with the same meaning to read a string from the dictionary, surely one token would be sufficient? I guess the there is room for plenty of discussion on what types of tokens are needed to support both the different compression algorithms that people would like to use and maybe also to support the kind of dictionary/code book manipulations that are desired. Regards, Jan Christoffersson "Price, Richard" wrote: > Hi, > > Attached is a (rather detailed) posting on the overhead of > encapsulating EPIC within UDPComp. The conclusion is that by adding > Huffman codes to UDPComp, the protocol overhead can be made very > low (just 5 bytes per message). > > Comments are welcome! > > Richard P > > -------------------------------------------------------------------- > > This is a follow-up to my earlier posting on the performance of > various signaling compression algorithms. I mentioned that one of the > ideas of UDPComp is to make the compression algorithm a local > implementation decision at the compressor: this makes the protocol > very lightweight and flexible, but potentially reduces the compression > efficiency due to transmitting the semantics of the compression > algorithm in each packet. > > As promised, here are some performance figures to illustrate this > overhead. We tested the EPIC algorithm encapsulated in UDPComp using > the "Simple SIP to SIP" flow from . > > We assume that the compressor and decompressor each contain a static > dictionary of text strings commonly used in SIP. This can be "learnt" > by compressing sufficient SIP messages, or alternatively can be fixed > a-priori. We also use a dynamic dictionary (i.e. compress relative to > previous messages in the flow). > > Note that UDPComp offers significant flexibility in the choice of > "token" used to transmit text strings from the compressor to the > decompressor. Currently the scheme sends a fixed 1-2 byte index to > reference each text string, but additional tokens can easily be added > (for example tokens that use Huffman codes to reference text strings). > We have provided a range of performance figures using different types > of token to transmit the data. > > For comparison, the compression ratio using only the existing UDPComp > tokens is given below: > > EPIC algorithm with no encapsulation: 9.78 > > UDPComp using existing tokens only: 1.17 > > The decrease in compression ratio is caused by sending a 1-2 byte index > to reference each text string. In contrast, the EPIC algorithm usually > references a text string by sending a short Huffman code (typically > 1 - 4 bits). > > To improve the compression ratio it is possible to add Huffman codes to > UDPComp. In general this is straightforward: the only potential problem > is that the Huffman codes are chosen specifically for EPIC, and different > variants of Lempel-Ziv may need a different set of Huffman codes. Thus, > it may be necessary to download new sets of Huffman codes to the > decompressor depending on the choice of algorithm. > > Adding Huffman codes to UDPComp can be done in several ways. Firstly > we have a choice between EPIC-LITE (which uses ordinary Huffman codes) > and EPIC (which uses a special version of Huffman encoding capable of > compressing text strings down to less than one bit - for example 3 > common text strings in a row might together be indicated by sending a > single "0" bit). > > Secondly, we have a choice between selecting a global set of Huffman > codes for all text strings, and using a different set for each dictionary > entry. In the latter case the Huffman code for each text string actually > changes depending on the previously received string. This improves the > compression ratio at a cost of higher memory requirements (which may be > a problem if we have to store the Huffman codes in working memory). > > Compression ratios for each choice are given below: > > UDPComp using EPIC-LITE with global Huffman codes: 5.90 > > UDPComp using EPIC-LITE with local Huffman codes: 6.29 > > UDPComp using EPIC with global Huffman codes: 6.85 > > UDPComp using EPIC with local Huffman codes: 8.24 > > Initial results are promising: if required we can make the overhead of > encapsulating EPIC within UDPComp negligible (essentially it is just > the 5 bytes of initial UDPComp header per message). I believe the next > step should be to check how other compression algorithms fit into the > UDPComp framework, and to decide on a "sweet spot" between compression > efficiency and standardizing the protocol in the given timeframe. > > ------------------------------------------------------------------------ > Name: RMRL-Disclaimer.txt > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > Encoding: 7bit _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 20 12:20:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25554 for ; Mon, 20 Aug 2001 12:20:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03215; Mon, 20 Aug 2001 12:11:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03186 for ; Mon, 20 Aug 2001 12:11:41 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25267 for ; Mon, 20 Aug 2001 12:10:23 -0400 (EDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7KGClI14774 for ; Mon, 20 Aug 2001 11:12:47 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Aug 2001 11:11:40 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 11:11:40 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] Encapsulating EPIC in UDPComp Date: Mon, 20 Aug 2001 11:11:39 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] Encapsulating EPIC in UDPComp X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEpYcxcENTfU5VUEdWBSQBQi2X+DwALTcnQ From: "Liu Zhigang.C (NRC/Dallas)" To: "'ext Price, Richard'" , , Cc: X-OriginalArrivalTime: 20 Aug 2001 16:11:40.0179 (UTC) FILETIME=[CBA75630:01C12992] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA03187 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Still, the numbers indicate that with a combined dictionary (including user-specific) can easily boost the compression ratio to close to 10, even for the generic approach like LZSS (I would assume LZW will have similar result). Then, shouldn't we assume a combined dictionary in all comparisons? BR, Zhigang > -----Original Message----- > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > Sent: August 20, 2001 5:21 AM > To: Liu Zhigang.C (NRC/Dallas); sip@ietf.org; rohc@cdt.luth.se > Cc: jdrosen@dynamicsoft.com > Subject: RE: [Sip] Encapsulating EPIC in UDPComp > > > Hi, > > The discrepancy is because the second set of compression ratios does > not include a user-specific dictionary. In this case, the compression > ratio for the EPIC algorithm with no protocol overhead is 9.78 (vs > 15.53 including a user-specific dictionary). > > The purpose of the second set of compression ratios is to check the > protocol overhead of UDPComp. This may be quite substantial because > UDPComp employs a standard decompressor, not specifically optimized > for any one particular compression algorithm. > > At present the decompressor doesn't even understand Huffman encoding, > so an explicit 1-2 byte index has to be sent for each text string > instead. This reduces the compression ratio as follows: > > No encapsulation at all: 9.78 > > UDPComp encapsulation: 1.17 > > Fortunately it is pretty easy to add Huffman encoding to UDPComp, and > the protocol overhead is reduced substantially. For the most powerful > variant of Huffman compression the overhead is as follows: > > UDPComp encapsulation with Huffman encoding: 8.24 > > This is a much lower overhead (5 bytes per compressed message). > > Regards, > > Richard P > > > -----Original Message----- > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > Sent: Friday, August 17, 2001 11:47 PM > > To: Price, Richard; sip@ietf.org; rohc@cdt.luth.se > > Cc: jdrosen@dynamicsoft.com > > Subject: RE: [Sip] Encapsulating EPIC in UDPComp > > > > > > > For comparison, the compression ratio using only the > > existing UDPComp > > > tokens is given below: > > > > > > EPIC algorithm with no encapsulation: 9.78 > > > > > > UDPComp using existing tokens only: 1.17 > > > > Richard, > > > > I'm a bit puzzled by the numbers. According to your own data sent > > earlier (http://www.cdt.luth.se/robhc/msg02428.html), even a > > generic LZSS can achieve a compression ratio of 9.87 with a combined > > dictionary. What is the point here? > > > > BR, > > Zhigang > > > > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 20 12:54:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26633 for ; Mon, 20 Aug 2001 12:54:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04442; Mon, 20 Aug 2001 12:45:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04414 for ; Mon, 20 Aug 2001 12:45:55 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26266 for ; Mon, 20 Aug 2001 12:44:35 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7KGjgv21255; Mon, 20 Aug 2001 18:45:42 +0200 (MEST) Received: from e0000865d41e2 (eplpc6014.epl.ericsson.se [150.132.176.14]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with SMTP id SAA12510; Mon, 20 Aug 2001 18:45:40 +0200 (MET DST) Reply-To: From: "Hans Hannu" To: "'Lawrence Conroy'" , , Cc: , , Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIPcompression Date: Mon, 20 Aug 2001 18:45:49 +0200 Message-ID: <00c801c12997$91e32eb0$0eb08496@e0000865d41e2.epl.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I like the idea of having some defined scenarios to be able to compare the scheme against and those scenarios could be included in the requirements document, but perhaps not under the requirements section, but under the "assumptions" section. We have already some message sequences (thanks to Richard and Ishita) that we could use. What we need to do now is just find out some representative channel bitrates to run these against. Maybe someone could provide some channel bitrates? Are there other "message exchange sequences" that someone thinks are more representative than those already used? BR /Hans H > >Hi Hans, > > > >Since the SIP Call set up latency is one of the main (if not > the main) > >problem we want to solve with signaling compression, I > propose we add a > >requirement to that effect: > > > >The compression scheme MUST be such that when applied to > SIP, the call > >set up latency is less than X seconds, for a representative set of > >scenarios to be defined. Scenarios specify the messages > exchanged, their > >contents, as well as the channel bit rates. > > > >We need to agree on X and the scenarios, but I believe this > requirement > >is useful, because compression ratio alone does not > adequately capture > >the problem of call set up latency. Scenarios can be based on those > >typically envisioned in cellular cases like 3GPP. > > > >Khiem > > > To which I reply: > Hi Folks, > There is a GERAN meeting at the end of the month, and I will canvas > to see if there is a HARD limit such as that proposed as a > requirement. > > However... > I think that the assumption that the main goal of SIP Comp is > to reduce > (or, as described above, =>LIMIT<= ) the call set up time is > not obvious > (to me, at least) and I'm not yet happy to have it included in the > requirements document as proposed. > > For GERAN at least, the HARD requirement is on the mid-call Re-Invite > sequence, NOT on the call set up. That's probably true for > UTRAN as well, > but that's not my area of interest. > > I have already sent a posting on my understanding of the > GERAN mid-call > problem and the figures that seem to apply there (and the reasons). > > Of course one benefit of SIP Comp is that we reduce the transmission > time for messages sent during call set up for latency reasons, and so > we may avoid too many re-transmissions of SIP messages. > However, I don't > see how this is a HARD requirement and would be interested in > understanding > the logic here. > > Do we have a specific limit (like the DCS one that is, I > believe, regulated > by the FCC)? > > BR, > L. > -- > lwc@roke.co.uk: +44 1794 833666::: > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 20 13:09:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27093 for ; Mon, 20 Aug 2001 13:09:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04968; Mon, 20 Aug 2001 13:02:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA04940 for ; Mon, 20 Aug 2001 13:02:09 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26842 for ; Mon, 20 Aug 2001 13:00:52 -0400 (EDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7KH3CI17030 for ; Mon, 20 Aug 2001 12:03:12 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Aug 2001 12:02:05 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 12:02:05 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIPcompression Date: Mon, 20 Aug 2001 12:02:04 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] RE: [rohc] Reduced processing overhead for SIPcompression X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEpl5BZvp3Q2ZWIEdWpVgBQi2kYTQAANNJQ From: "Liu Zhigang.C (NRC/Dallas)" To: , "'Lawrence Conroy'" , , Cc: , "Le Khiem (NRC/Dallas)" X-OriginalArrivalTime: 20 Aug 2001 17:02:05.0288 (UTC) FILETIME=[D6C25680:01C12999] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA04941 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi Hans, Are the message sequences you get from Richard and Ishita based on draft-ietf-sip-call-flows-05.txt or 3GPP TS 24.228? Were they sent to the mailing list? BR, Zhigang > -----Original Message----- > From: ext Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] > Sent: August 20, 2001 11:46 AM > To: 'Lawrence Conroy'; sip@ietf.org; rohc@cdt.luth.se > Cc: richard.price@roke.co.uk; Liu Zhigang.C (NRC/Dallas); Le Khiem > (NRC/Dallas) > Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for > SIPcompression > > > Hi, > > I like the idea of having some defined scenarios to be able > to compare the > scheme against and those scenarios could be included in the > requirements > document, but perhaps not under the requirements section, but > under the > "assumptions" section. > > We have already some message sequences (thanks to Richard and > Ishita) that > we could use. What we need to do now is just find out some > representative > channel bitrates to run these against. Maybe someone could > provide some > channel bitrates? > > Are there other "message exchange sequences" that someone > thinks are more > representative than those already used? > > BR > /Hans H > > > >Hi Hans, > > > > > >Since the SIP Call set up latency is one of the main (if not > > the main) > > >problem we want to solve with signaling compression, I > > propose we add a > > >requirement to that effect: > > > > > >The compression scheme MUST be such that when applied to > > SIP, the call > > >set up latency is less than X seconds, for a representative set of > > >scenarios to be defined. Scenarios specify the messages > > exchanged, their > > >contents, as well as the channel bit rates. > > > > > >We need to agree on X and the scenarios, but I believe this > > requirement > > >is useful, because compression ratio alone does not > > adequately capture > > >the problem of call set up latency. Scenarios can be based on those > > >typically envisioned in cellular cases like 3GPP. > > > > > >Khiem > > > > > To which I reply: > > Hi Folks, > > There is a GERAN meeting at the end of the month, and I > will canvas > > to see if there is a HARD limit such as that proposed as a > > requirement. > > > > However... > > I think that the assumption that the main goal of SIP Comp is > > to reduce > > (or, as described above, =>LIMIT<= ) the call set up time is > > not obvious > > (to me, at least) and I'm not yet happy to have it included in the > > requirements document as proposed. > > > > For GERAN at least, the HARD requirement is on the mid-call > Re-Invite > > sequence, NOT on the call set up. That's probably true for > > UTRAN as well, > > but that's not my area of interest. > > > > I have already sent a posting on my understanding of the > > GERAN mid-call > > problem and the figures that seem to apply there (and the reasons). > > > > Of course one benefit of SIP Comp is that we reduce the transmission > > time for messages sent during call set up for latency > reasons, and so > > we may avoid too many re-transmissions of SIP messages. > > However, I don't > > see how this is a HARD requirement and would be interested in > > understanding > > the logic here. > > > > Do we have a specific limit (like the DCS one that is, I > > believe, regulated > > by the FCC)? > > > > BR, > > L. > > -- > > lwc@roke.co.uk: +44 1794 833666::: > > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 20 13:28:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27730 for ; Mon, 20 Aug 2001 13:28:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05207; Mon, 20 Aug 2001 13:20:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05179 for ; Mon, 20 Aug 2001 13:20:32 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27337 for ; Mon, 20 Aug 2001 13:19:15 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id KAA24256 for ; Mon, 20 Aug 2001 10:20:30 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA15324 for ; Mon, 20 Aug 2001 10:20:30 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 20 Aug 2001 12:20:30 -0500 Message-ID: From: Majumdar Ishita-QA4906 To: Hans.Hannu@epl.ericsson.se, "'Lawrence Conroy'" , sip@ietf.org, rohc@cdt.luth.se Cc: richard.price@roke.co.uk, zhigang.c.liu@nokia.com, khiem.le@nokia.com Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIPcompressi on Date: Mon, 20 Aug 2001 12:20:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, How about we start with 9.6 kbps both uplink and downlink and use UMTS frames to estimate the call set up delay? We can then slowly progress to 14.4 kbps and then 144 kbps to have a comparative analysis between compression ratios and faster channels? After that we can incorporate processing delays/queueing delays at both sender and receiver assuming one is a Mobile and the other is a P_CSCF. As I said with TCCB, the compression ratio improves with each successive call between the same user agents. Here are some suggestions of scenarios.and performance parameters. a) User A calling User B (compression ratio, call et up delay improvement) b) User A receiving a call from User C c) User A calling User B (again) In order to do the delay analysis, we not only have to use the same scenario but also be sure that we use the same Protocol stack as specified in the 3GPP docs so that we add the correct header size to tha application layer messages for all the successive layers beneath. Also it would be interesting to know just how much more gain we get with SIP compression +UDP/IP header compression. I could provide the numbers probably by Thursday so we can have a rough idea what the numbers look. Comments are welcome. Thx, Ishita -----Original Message----- From: Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] Sent: Monday, August 20, 2001 11:46 AM To: 'Lawrence Conroy'; sip@ietf.org; rohc@cdt.luth.se Cc: richard.price@roke.co.uk; zhigang.c.liu@nokia.com; khiem.le@nokia.com Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIPcompression Hi, I like the idea of having some defined scenarios to be able to compare the scheme against and those scenarios could be included in the requirements document, but perhaps not under the requirements section, but under the "assumptions" section. We have already some message sequences (thanks to Richard and Ishita) that we could use. What we need to do now is just find out some representative channel bitrates to run these against. Maybe someone could provide some channel bitrates? Are there other "message exchange sequences" that someone thinks are more representative than those already used? BR /Hans H > >Hi Hans, > > > >Since the SIP Call set up latency is one of the main (if not > the main) > >problem we want to solve with signaling compression, I > propose we add a > >requirement to that effect: > > > >The compression scheme MUST be such that when applied to > SIP, the call > >set up latency is less than X seconds, for a representative set of > >scenarios to be defined. Scenarios specify the messages > exchanged, their > >contents, as well as the channel bit rates. > > > >We need to agree on X and the scenarios, but I believe this > requirement > >is useful, because compression ratio alone does not > adequately capture > >the problem of call set up latency. Scenarios can be based on those > >typically envisioned in cellular cases like 3GPP. > > > >Khiem > > > To which I reply: > Hi Folks, > There is a GERAN meeting at the end of the month, and I will canvas > to see if there is a HARD limit such as that proposed as a > requirement. > > However... > I think that the assumption that the main goal of SIP Comp is > to reduce > (or, as described above, =>LIMIT<= ) the call set up time is > not obvious > (to me, at least) and I'm not yet happy to have it included in the > requirements document as proposed. > > For GERAN at least, the HARD requirement is on the mid-call Re-Invite > sequence, NOT on the call set up. That's probably true for > UTRAN as well, > but that's not my area of interest. > > I have already sent a posting on my understanding of the > GERAN mid-call > problem and the figures that seem to apply there (and the reasons). > > Of course one benefit of SIP Comp is that we reduce the transmission > time for messages sent during call set up for latency reasons, and so > we may avoid too many re-transmissions of SIP messages. > However, I don't > see how this is a HARD requirement and would be interested in > understanding > the logic here. > > Do we have a specific limit (like the DCS one that is, I > believe, regulated > by the FCC)? > > BR, > L. > -- > lwc@roke.co.uk: +44 1794 833666::: > --- Mailing list for Robust Header Compression WG Archive: http://www.cdt.luth.se/rohc/ _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 20 13:57:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28615 for ; Mon, 20 Aug 2001 13:57:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05886; Mon, 20 Aug 2001 13:47:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05855 for ; Mon, 20 Aug 2001 13:47:15 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28298 for ; Mon, 20 Aug 2001 13:45:57 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7KHl3v04845; Mon, 20 Aug 2001 19:47:03 +0200 (MEST) Received: from e0000865d41e2 (eplpc6014.epl.ericsson.se [150.132.176.14]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with SMTP id TAA16168; Mon, 20 Aug 2001 19:47:00 +0200 (MET DST) Reply-To: From: "Hans Hannu" To: "'Liu Zhigang.C (NRC/Dallas)'" , , Cc: , Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIPcompression Date: Mon, 20 Aug 2001 19:47:07 +0200 Message-ID: <000101c129a0$23cb0b60$0eb08496@e0000865d41e2.epl.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_01C129B0.E753DB60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-MS-TNEF-Correlator: 00000000255E33C6958DD511B6B70000865D41E284BB2100 Importance: Normal In-Reply-To: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C129B0.E753DB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Zhigang, I read Ishita's mail too quickly. Thus, we currently only have one message sequnce, section 3.1.1 Successful Simple SIP to SIP, from draft-ietf-sip-call-flows-05.txt. If you could provide more sequences it would be good. BR /Hans H > -----Original Message----- > From: Liu Zhigang.C (NRC/Dallas) [mailto:zhigang.c.liu@nokia.com] > Sent: den 20 augusti 2001 19:02 > To: Hans.Hannu@epl.ericsson.se; 'Lawrence Conroy'; sip@ietf.org; > rohc@cdt.luth.se > Cc: richard.price@roke.co.uk; Le Khiem (NRC/Dallas) > Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for > SIPcompression > > > Hi Hans, > > Are the message sequences you get from Richard and Ishita > based on draft-ietf-sip-call-flows-05.txt or 3GPP TS > 24.228? Were they sent to the mailing list? > > BR, > Zhigang > > > -----Original Message----- > > From: ext Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] > > Sent: August 20, 2001 11:46 AM > > To: 'Lawrence Conroy'; sip@ietf.org; rohc@cdt.luth.se > > Cc: richard.price@roke.co.uk; Liu Zhigang.C (NRC/Dallas); Le Khiem > > (NRC/Dallas) > > Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for > > SIPcompression > > > > > > Hi, > > > > I like the idea of having some defined scenarios to be able > > to compare the > > scheme against and those scenarios could be included in the > > requirements > > document, but perhaps not under the requirements section, but > > under the > > "assumptions" section. > > > > We have already some message sequences (thanks to Richard and > > Ishita) that > > we could use. What we need to do now is just find out some > > representative > > channel bitrates to run these against. Maybe someone could > > provide some > > channel bitrates? > > > > Are there other "message exchange sequences" that someone > > thinks are more > > representative than those already used? > > > > BR > > /Hans H > > > > > >Hi Hans, > > > > > > > >Since the SIP Call set up latency is one of the main (if not > > > the main) > > > >problem we want to solve with signaling compression, I > > > propose we add a > > > >requirement to that effect: > > > > > > > >The compression scheme MUST be such that when applied to > > > SIP, the call > > > >set up latency is less than X seconds, for a > representative set of > > > >scenarios to be defined. Scenarios specify the messages > > > exchanged, their > > > >contents, as well as the channel bit rates. > > > > > > > >We need to agree on X and the scenarios, but I believe this > > > requirement > > > >is useful, because compression ratio alone does not > > > adequately capture > > > >the problem of call set up latency. Scenarios can be > based on those > > > >typically envisioned in cellular cases like 3GPP. > > > > > > > >Khiem > > > > > > > To which I reply: > > > Hi Folks, > > > There is a GERAN meeting at the end of the month, and I > > will canvas > > > to see if there is a HARD limit such as that proposed as a > > > requirement. > > > > > > However... > > > I think that the assumption that the main goal of SIP Comp is > > > to reduce > > > (or, as described above, =>LIMIT<= ) the call set up time is > > > not obvious > > > (to me, at least) and I'm not yet happy to have it included in the > > > requirements document as proposed. > > > > > > For GERAN at least, the HARD requirement is on the mid-call > > Re-Invite > > > sequence, NOT on the call set up. That's probably true for > > > UTRAN as well, > > > but that's not my area of interest. > > > > > > I have already sent a posting on my understanding of the > > > GERAN mid-call > > > problem and the figures that seem to apply there (and the > reasons). > > > > > > Of course one benefit of SIP Comp is that we reduce the > transmission > > > time for messages sent during call set up for latency > > reasons, and so > > > we may avoid too many re-transmissions of SIP messages. > > > However, I don't > > > see how this is a HARD requirement and would be interested in > > > understanding > > > the logic here. > > > > > > Do we have a specific limit (like the DCS one that is, I > > > believe, regulated > > > by the FCC)? > > > > > > BR, > > > L. > > > -- > > > lwc@roke.co.uk: +44 1794 833666::: > > > > > > ------=_NextPart_000_0002_01C129B0.E753DB60 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgsRAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHCAAUABMALwAAAAEANwEB A5AGAIgOAAArAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAALACsAAAAAAAMALgAA AAAAAwA2AAAAAAAeAHAAAQAAAEAAAABbU2lwXSBSRTogW3JvaGNdIFJlZHVjZWQgcHJvY2Vzc2lu ZyBvdmVyaGVhZCBmb3IgU0lQY29tcHJlc3Npb24AAgFxAAEAAAAWAAAAAcEpoCE8rbFnSZWQEdW2 uwAAhl1B4gAAAgEdDAEAAAAgAAAAU01UUDpIQU5TLkhBTk5VQEVQTC5FUklDU1NPTi5TRQALAAEO AAAAAEAABg4Awu4coCnBAQIBCg4BAAAAGAAAAAAAAAAlXjPGlY3VEba3AACGXUHiwoAAAAMAFA4B AAAACwAfDgEAAAADAAYQ6XPv1AMABxB4CwAAHgAIEAEAAABlAAAASElaSElHQU5HLElSRUFESVNI SVRBU01BSUxUT09RVUlDS0xZVEhVUyxXRUNVUlJFTlRMWU9OTFlIQVZFT05FTUVTU0FHRVNFUVVO Q0UsU0VDVElPTjMxMVNVQ0NFU1NGVUxTSQAAAAACAQkQAQAAAJgJAACUCQAAOBQAAExaRnWUpxSD AwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jh CsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFCzCwkBZDM2FlALp2MBMAAg SGkgWmhpZzkAcGcsCqIKhAqASSDBGCBhZCBJcx1wAZAOJwQgAMADEXRvbyAEcXUN4GtseS4gAFRo dXMsIHdlvCBjCHAYIAIwIIAgAiB7IcET4HYhMAIgITAHgXMcYWchMBQQIDBuY2UjIQAUEGN0aQIg IDN8LjEkcAYAGtAjoAQQZjp1AyBTB3ALUCEwU0keUB/hJdIhAANSIGRyWmEBgC0IkAAwLQCQcEQt YwdAbC1mF7B3oHMtMDUuDNB0IKBxHkVmIHkIYCFACGBs5R7wcANgdmkBAB+QBbB3IzQJ8CTxIB9A IRAp82IlITBnIABkLh3qQlIpHeQvSAYiSB3qPiDqLS9STwUQZwuAB0AF0Bci5C9TLtZGA2E6IEwG aSnAHWUuQyAoThBSQy9EJ/FhcylMIFsfoh/wOnoyJWOELmwx4EBub2sHMPs0cANwXS7WBmACMDGw AQDDA6AB0CBhdWcg4CQQhTaRMCSgMTk6MA5QXS7lVDPgHSAAcS4uEW7VNMBlC1AuBnFjBBACIAIu FBA7ICdMYXeXIYEjoBIhbgNgeSc6UNUnoUAnUi4FsGcZMC7lwQNgaGNAY2Qo4ApAzHRoOiEu1kNj MbA5sU8T4SygKkAN4GVAA2BromU1MS51azpQTCEwOksdcGUm0DK6NYd1YqZqI/ExsFJFMbBbJXD8 cF1CpDzyQzEJgBrQCYA3KjIk8guAZyHgImByaPse0gIQcjWHJfA1QSpARML/AiAu1kdeHTEuEh3V R7gHEP8hMD2gIrwrVCmiIyAFQCajtlI+xDbAbh72LtZiM0A/RFEkMSb/KA0h4AXAM0cSUCYAVFMu 1jI0LsAyMjg/IFcEkEpz/yHQFBACMCYSSpMfsUTyNKD9NxA/R14tgElHHWVHXi8//zBPV9IxdA7C LhQ5EjN3OL/3Occ1dzXmQTbjNpEhADdU0DE6NDYQwE1XeDhy/zp/O40871d4Pn8/jDHvMvb/QDhX eEDvXiRCP0NPRF9Fb/9GX1eHcF9X4R0wSUdXWh6g7zSgP7BKgyqBYSHgKYAiQe9t0jnwB4A2UWYL gG0xBPD/CfAKwCQgBCAmISxBAaAlsf9XeCYhb6IKwEpzV3gE8EVw/3VhIxALcV8RTUI9oHaAIzHv dicp5CxBC4BjCkABAB7w/wuASoNXeBggIDEYIAeAAjBqc1d4ZG2AdX5SIQBi5z2QKjBuMWFwBCA0 4AVA/yOABIFKg33qI9Z/xFd4gOd1V3giM0Bzf3AFMCQhc/4iI9YstXC8UqAiNAdAHsK/UyF1Ukrf MqA9oABwa3aT30zKcwkfIzNgihF0V3ghIv8p8yDgP8BSkIyhIRIioG0xnyYhf0CAkQfgBAAgal8C /3WxTqF/8XVDfUpG0iGRjLBeaSJgV3gT0VyQZQMgYu8fQE8ADrB2k3IjgEqCeuHjefUgoE1heSxB dUIikv8p5Fd4KkZ1QpKvk7dUx1da/0pVKuGAsJuRhOAi1g7Ak0L/SyqFsIySlgd3aR1wikJ4cv8q wpEvkjWMgnzietKIFo4B/mSZ/1fSLYZX0i4LcLxX0X9I3qbzppslcGGSSpIl4kP3J/EjQYDBcFRw lAEjkCHQ34/BIpJ0oVPFA6AoBpCAkv+mmqxGallX0SpBdyEm0CEh7ncAcFNzOfBsImED8D2gvTuR Z1ixbdJvqSEASaaa/SpBcHrSISEe4E0hppt96f9ThI5xARFrQqfvptcgwI2Cw2/HeXZNVVNULDKF IPsT0J4Ed0VwA6CAYAtQCJD/jwKmmiZTSpJP4qabqr9UcNsi4aH0WCPSAiBkIPFFwf82wEfHoR2+ gnSgvbx2LXWV1SCgU3Ync4AgYwaQIdDvSpl+mVfwnNZkvRN+IKab/8CBq0F+gCEAM0AhEaqBypH/ vTOTWB6wlAKGSaiOh5GO1v8jEAnRTrLAQHp0evl/xB6g/yxAu7Gh0wQAppp96aabj8H/jgElMX/B BZA20HrhuOqT8f8kIIgBIpJ/QAeRrR0e4CNh/5QBIcFP4AUwCHBkOVfRSpL/r2Z0oU/iqq3Fak/g A6AsQedN73qz2Ux5cA3gJ/Eh0P8J8CpwRxJ8pCOgKAAlQArB/0/gFBC/gXPSUTLMn6bIaL3/qI04 cLshZTFzkZHBIIC2+/0dMUYG8IpQp9vpMbihKuGDj8F0gEdFUkFOIsH/FCBt0o5xSpIJ8E6hrCUC IX5oynFNUldpA/DbIdzxdn8zQK1LsHHPIazhm4Tp00joQVJEVHFtK7G6k8sT/45xs4VNIZ/R0f9+ NOKa5zvzKFDRcXIu9gCmmh6gn4P/ngRKkoUI92isgyxwWMF0oX+qI2+xj7HuTRghbRGmmij/BbDK cwEABPIsQE0hBuAiYAEhAD0+TElNSVT4PD0gjHK9VKqmJBB1Yf/R3ICir4AqcAhgx1uKACAQ3weA ynFfICWwM0B0M2BNQ7YnJtCAonlMQYBRcMaB/yAQIkMrsXxN8q+B1n9GyoL/8db0H6bl6CASkOok A0a9FP/wU7Vaq6NKhCqAT9NXaWzgfC1J4EGUEKaaKxYhAE7+T7pADfXbCSCijLAfca9iP3cRxoGU gCEwbqtX8FVUfwuTyqSn23/ijJIfcYCibf/YsJ/xdINYoBAARuH0D/Z4/4fMCMMqMNzA6rMkMRfR gOP/NxDskW3TrCOmmuolDnWyzf+vk8+mdbBe8EbhngXqkCbQ787Cu5HGg+mhKM+mwVjyYO2FgSkZ D6blT9rhAdAdAP/PMnVwLECr4HWwwuL6CrrV/4FibQJ8+5PhejDwwHANd+H/ADLA8sbmUzRtAFhw sbLbGf/A8qsmfUoko+x0OfCmmo6h81QAF+F2b5fQzrEC4bAg+9iw+7AtKoqrsfn0xubim+f1lbKR fzFuJ6077zJ6wN+PoNGy7/m1WuySd3vIGKS/fKOmmhzLrU5QQFiQY3TA91KxJQ+m5UTmMYemxhU+ McXwpChzx0RDU6vDnhN/VJCyndE1DFD7sF7wLuJkwxYrxoRGQ0Mpo3moqztV2ekETOKbWZpX8Gx3 R2NwZghrcCs0NF/AN0I5TGA4MzM2TQA6vDo8F9GzoFighXI+tvoLpf9XZX1QcAMAEBAAAAAAAwAR EAYAAAAeAEIQAQAAAEAAAAA8QjgxQzg5NDA0QTlCRDY0OTgzRTM2OUI3RDQ0NTM5NDEwRDU2MkJA ZGFlYmUwMDUuTk9FLk5va2lhLmNvbT4AAwAJWQEAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAAD hQAAAAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAIgAggBgAAAAAAwAAAAAAA AEYAAAAAAYUAAAAAAAADAFqACCAGAAAAAADAAAAAAAAARgAAAABShQAA1hkAAB4AW4AIIAYAAAAA AMAAAAAAAABGAAAAAFSFAAABAAAABAAAADguNQALAFyACCAGAAAAAADAAAAAAAAARgAAAAAGhQAA AAAAAAsAXYAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwBegAggBgAAAAAAwAAAAAAAAEYA AAAAEYUAAAAAAAADAF+ACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAB4AYIAIIAYAAAAAAMAA AAAAAABGAAAAADaFAAABAAAAAQAAAAAAAAAeAGGACCAGAAAAAADAAAAAAAAARgAAAAA3hQAAAQAA AAEAAAAAAAAAHgBigAggBgAAAAAAwAAAAAAAAEYAAAAAOIUAAAEAAAABAAAAAAAAAAsAY4ALIAYA AAAAAMAAAAAAAABGAAAAAACIAAAAAAAACwBkgAsgBgAAAAAAwAAAAAAAAEYAAAAABYgAAAAAAAAC AfgPAQAAABAAAAAlXjPGlY3VEba3AACGXUHiAgH6DwEAAAAQAAAAJV4zxpWN1RG2twAAhl1B4gIB +w8BAAAAZQAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABtc3BzdC5kbGwAAAAAAE5JVEH5v7gBAKoA N9luAAAAQzpcV0lOTlRcUHJvZmlsZXNcZXBsaGFodVxQZXJzb25hbFxNYWlsdG9vbC5wc3QAAAAA AwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwMjU1RTMzQzY5NThERDUxMUI2Qjcw MDAwODY1RDQxRTI4NEJCMjEwMAAAAACsyw== ------=_NextPart_000_0002_01C129B0.E753DB60-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 20 15:34:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01197 for ; Mon, 20 Aug 2001 15:34:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08685; Mon, 20 Aug 2001 15:20:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08594 for ; Mon, 20 Aug 2001 15:20:41 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00774 for ; Mon, 20 Aug 2001 15:19:24 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7KJKji17998 for ; Mon, 20 Aug 2001 14:20:45 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 20 Aug 2001 14:20:40 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 14:20:39 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIPcompression Date: Mon, 20 Aug 2001 14:20:39 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C129AD.3276C859" Thread-Topic: [Sip] RE: [rohc] Reduced processing overhead for SIPcompression X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEpoCE8rbFnSZWQEdW2uwAAhl1B4gACPgjQ From: "Liu Zhigang.C (NRC/Dallas)" To: , , Cc: , X-OriginalArrivalTime: 20 Aug 2001 19:20:39.0959 (UTC) FILETIME=[32B07270:01C129AD] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C129AD.3276C859 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hans, Attached is a message sequence for mobile-originated call scenario in 3GPP (sorry about the size, ~6K). It was based=20 on 3GPP TS 24.228 (v0.4.0 March/2001): "Signaling flows for=20 the IP multimedia call control based on SIP and SDP".=20 It was generated back in April when we started the test. Recently, there is a new version (v1.2.0 July/2001) of TS 24.228 released. So, some updates might be needed. But the basic sequence is still the same.=20 If time allowed, we probably need another sequence for mobile- terminated call, which can be found in the same document. BR, Zhigang PS. I noticed that the lines in the files are terminated by LF=20 instead of CRLF (as it should be). I guess it was messed up=20 during the transfer between Windows and Linux. > -----Original Message----- > From: ext Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] > Sent: August 20, 2001 12:47 PM > To: Liu Zhigang.C (NRC/Dallas); sip@ietf.org; rohc@cdt.luth.se > Cc: richard.price@roke.co.uk; Ishita.Majumdar@motorola.com > Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for > SIPcompression >=20 >=20 > Hi Zhigang, >=20 > I read Ishita's mail too quickly. Thus, we currently only=20 > have one message sequnce, section 3.1.1 Successful Simple SIP=20 > to SIP, from draft-ietf-sip-call-flows-05.txt.=20 > If you could provide more sequences it would be good. >=20 > BR > /Hans H >=20 > > -----Original Message----- > > From: Liu Zhigang.C (NRC/Dallas) [mailto:zhigang.c.liu@nokia.com] > > Sent: den 20 augusti 2001 19:02 > > To: Hans.Hannu@epl.ericsson.se; 'Lawrence Conroy'; sip@ietf.org; > > rohc@cdt.luth.se > > Cc: richard.price@roke.co.uk; Le Khiem (NRC/Dallas) > > Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for > > SIPcompression > >=20 > >=20 > > Hi Hans, > >=20 > > Are the message sequences you get from Richard and Ishita > > based on draft-ietf-sip-call-flows-05.txt or 3GPP TS > > 24.228? Were they sent to the mailing list? > >=20 > > BR, > > Zhigang > >=20 > > > -----Original Message----- > > > From: ext Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] > > > Sent: August 20, 2001 11:46 AM > > > To: 'Lawrence Conroy'; sip@ietf.org; rohc@cdt.luth.se > > > Cc: richard.price@roke.co.uk; Liu Zhigang.C (NRC/Dallas); Le Khiem > > > (NRC/Dallas) > > > Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for > > > SIPcompression > > >=20 > > >=20 > > > Hi, > > >=20 > > > I like the idea of having some defined scenarios to be able=20 > > > to compare the > > > scheme against and those scenarios could be included in the=20 > > > requirements > > > document, but perhaps not under the requirements section, but=20 > > > under the > > > "assumptions" section. > > >=20 > > > We have already some message sequences (thanks to Richard and=20 > > > Ishita) that > > > we could use. What we need to do now is just find out some=20 > > > representative > > > channel bitrates to run these against. Maybe someone could=20 > > > provide some > > > channel bitrates? > > >=20 > > > Are there other "message exchange sequences" that someone=20 > > > thinks are more > > > representative than those already used? > > >=20 > > > BR > > > /Hans H > > >=20 > > > > >Hi Hans, > > > > > > > > > >Since the SIP Call set up latency is one of the main (if not > > > > the main) > > > > >problem we want to solve with signaling compression, I > > > > propose we add a > > > > >requirement to that effect: > > > > > > > > > >The compression scheme MUST be such that when applied to > > > > SIP, the call > > > > >set up latency is less than X seconds, for a=20 > > representative set of > > > > >scenarios to be defined. Scenarios specify the messages > > > > exchanged, their > > > > >contents, as well as the channel bit rates. > > > > > > > > > >We need to agree on X and the scenarios, but I believe this > > > > requirement > > > > >is useful, because compression ratio alone does not > > > > adequately capture > > > > >the problem of call set up latency. Scenarios can be=20 > > based on those > > > > >typically envisioned in cellular cases like 3GPP. > > > > > > > > > >Khiem > > > > > > > > > To which I reply: > > > > Hi Folks, > > > > There is a GERAN meeting at the end of the month, and I=20 > > > will canvas > > > > to see if there is a HARD limit such as that proposed as a > > > > requirement. > > > > > > > > However... > > > > I think that the assumption that the main goal of SIP Comp is > > > > to reduce > > > > (or, as described above, =3D>LIMIT<=3D ) the call set up time is > > > > not obvious > > > > (to me, at least) and I'm not yet happy to have it=20 > included in the > > > > requirements document as proposed. > > > > > > > > For GERAN at least, the HARD requirement is on the mid-call=20 > > > Re-Invite > > > > sequence, NOT on the call set up. That's probably true for > > > > UTRAN as well, > > > > but that's not my area of interest. > > > > > > > > I have already sent a posting on my understanding of the > > > > GERAN mid-call > > > > problem and the figures that seem to apply there (and the=20 > > reasons). > > > > > > > > Of course one benefit of SIP Comp is that we reduce the=20 > > transmission > > > > time for messages sent during call set up for latency=20 > > > reasons, and so > > > > we may avoid too many re-transmissions of SIP messages. > > > > However, I don't > > > > see how this is a HARD requirement and would be interested in > > > > understanding > > > > the logic here. > > > > > > > > Do we have a specific limit (like the DCS one that is, I > > > > believe, regulated > > > > by the FCC)? > > > > > > > > BR, > > > > L. > > > > -- > > > > lwc@roke.co.uk: +44 1794 833666::: > > > > > > >=20 > >=20 >=20 ------_=_NextPart_001_01C129AD.3276C859 Content-Type: application/x-zip-compressed; name="mo2-msg.zip" Content-Description: mo2-msg.zip Content-Disposition: attachment; filename="mo2-msg.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIANlwgirLJPcb3wAAAHgBAAAKAAAAMzgtYWNrLnR4dHWQMW/CMBCFd/+KG2FIwHYT 6KWpSEyrIhYkCkvVwXFcEtWxKfb/V02lDhXp2+707runV4kt+P6MwX1qm6/OyqsPmnZu0KnVAfab 3Yylc3LsJf4Os8N6B29ZFKKUEpumQaUUtm37Tp4vbkCoTK8t1Eb6oC/wcH1Q83yyf6kSOomHCY0q IPSDLnlOGX/K6gK8/ioXbDpdGaek6ZwPj0WQp5Iu6JItyavDMRSLGkfxWxSndzS7J0Iak2zWCCOp /pJuMxERdwiUU6jElghng1QBf1r8r5WrSduQGG1PoUOYk29QSwMEFAAAAAgA2HCCKoeJGYTPAAAA RAEAABEAAAAwMi0xMDAtdHJ5aW5nLnR4dHWOwWrCQBRF9/MVb6nI1LwJGnk2ookWsylCohvpYpIM cWCc0WQ2/fsOFGxL27O83Hu4ZXGYiqcIMIqg6t+17dhJS4LyM58etwc4zwJEUkqq65qapqG2bd/Y S++uBBujlYXMyMGrHp4HfaMsno/K/YbjaIJcoOBhzzGwBK+vKo3nKOLdLFvCoO5pIsbjtXGNNBc3 +FXoyC7FBBdiwSpH8K9RBP42xt+NLJfG8GJL8GV5HPq5/n2H5aW6E6BIoHg9FdWO5c56ZT03ynb+ QhCxD1BLAwQUAAAACADYcIIq+HTty+EBAAASAwAADgAAADExLTE4My1zZHAudHh0dZJRb9owEMff /SnusdUIxA5JiKmrBug0JrWLCONl2oNJHLAW22nsVmOffi5ojGrdPd35/v7p7zuXy2JEhiHgSQSl sFYaDUVvdr3P0UZyCuVJMfq6KOBb7INSzjndbre0qipa1/V39CBqyYP82e1NL39x5ykUstkmClOC VkIZJ4KC9+4QLBcUPpu9hlJJt4cbJ1r6AQcEk8CjA+LjFuXa6IPvHyh8aRr0sTeKQt5KoWHWcutE DzdWdnQWJVflpzzAVxcI7GMKTirBogST6D6eTcGKJ5aS6+u71lS83Rvrbr2G7xhO8YRM0NpQ+C/x 1dT7xOiSeAJGeIzjDM152x4f+5d4NveW9K81NPdnFDBJYfm4Wa7v0dxoxyt38ujMD6HxXVfZqsHD vVFiqIVDq/L1UhYSfJQL7YKFtJ2x8rSOrheV0fWxOivWh05Q4F3Xyuq4tpGtu3O3FXrn9hRIRBB6 YSEyLACSTdIs8vbjy3T5CMsigXf/B7IsQBV7qxFC0KZp/mjRluUlTcbIsSxMcRKTNIYQKcafa2kg icdjWK2LUb4pIEshQpz1rlO8o77KH1a+bpQ7VsrUIrDCsXBABvEgnYLiP5ueK2EZ8bonY6niuubO 9Ae/R137ybyAH04je4V+A1BLAwQUAAAACADYcIIq6tGqg4ABAACSAgAADAAAADEyLXByYWNrLnR4 dH1RUW/bIBh851d8j60UJwbHJiZjqpN2mjWtspIsL9MevmDSWDXgGlat/3400qZNzXZPHHx3HEez qdafwHeDCO5RW3ozKK+OdHpyRk+tDrCtmxmbpmTfofhFZl9uG/iaRwiBiOJwOAillGjb9hv5MDoj oOo7bWHVow96hHevF6yy4mr7sUroVRQmNGIJoTNaZgVl2V2+WoLXT5Kz6+ub3insT86H98uAD5Jy umALsnPikhWLuGyVvbXK6JzmJVlj3yf1rYALqf52epuJrOOeAMoW0LzWR9bOBlRBnHv8Vy8bVI8C ypTRqORQ3+/r3d1Zqm1Idi+DFoDD0HcKQ+fszLcD/D7utX0IJwHxpYQ8y5Q4mQArF7zMYtD8z2V9 D3VTwMUUxMuEKPn/mYOstqKYkyDLlNMiZzyHlBiJ39vOQTbPC9jsmlm1b6DkBOUYBoODKDlUnzeR H004M+NanXgdZDphk3zCl2Dwx3FEo71kce7JeWHQthjc+BL/y7ajVs/kJ1BLAwQUAAAACADYcIIq S1puTt4AAABhAQAADQAAADE3LTIwMC1vay50eHRtjsFPgzAUh+/9K95xO8BoKxs+xAyYxmUmkjG9 GA+l1EEs7Vz7/0ecJzO+4y/vffnqbbVgYQQsiuBlR956gVD/bYvXTQXv8QiiEAKbpkEpJbZt+0Ee z3ZAyHWvDBRaOK/OcOf6ExZ8Oauf8oDOxseAjqTg+0FlfEkZf4iLFJz6zlZsPl9rK4XurPP3qRfH jK5owhJysDilYiPTKn6t4vSGxrekFFoH2w3CRNV/03UTKccNgbIEqn1e7khpjRfSI/y2efulDFuf pJOfNOzsoEKj/OVGGR88K3P0HUJEfgBQSwMEFAAAAAgA2HCCKqiIoKxwAQAAegIAAAwAAAAxOS1j b21ldC50eHR9UU1P4zAUvPtXvCNITRs7TdK84hVpANEDuxHtcllxcB2XRuuPUBtE/z0u0q52RXfn 5HkezxuNm29312vw/YDB/VSWXQ7Syy0d75xRY6sCrJbthI1T8tAL/EUm369a+JFHIAohcLPZoJQS u657JDd7ZxBq3SsLCy18UHu4OC5YZMXZ6rZO6Fl8mNCIOYTeKJ4VlGXX+WIOXj3zkp2fX2onhd45 H77Mg3jitKQzNiNrh6esWMRpq+yzVUanNK9II7ROllcIJ1L97fQ5E2niDIGyCppjfaRxNggZ8KPH f/VyFCkbkvVhUAhiGHQvReidnfhugN/XWtmnsENgLCXklafE8QRYNSurLEbK/zwuv8KyLeDkPuJ5 QiT/v2bD6xUWUxJ4lZa0yFmZQ0oMFy9d7yCb5gXcr9tJ/dBCVRLB92EwYsCqhPruPvKtCR/MuE4l XgWejtgoH5VzMOJtuxdGec6i7tl59C9SKu/jv9jOWX0g71BLAwQUAAAACADYcIIqzCGCHd4AAABh AQAADQAAADI0LTIwMC1vay50eHRtjs1uwjAQBu9+ij3CISG2G342TQUJVKC2Aim0l6oHx3FJVMem 2O8v3PZUkTl+2h1NtTtMWJwASxLYP5G3TiBUf9vkdX2A9zSAKITAuq5RSolN03yQx4vtEVa6UwYK LZxXF7h33RkLPh1V21VER+ExooEMfNernE8p45u0yMCp73zGxuOltlLo1jr/kHlxyumMztmcHC0O qVhgWMVvVZze0XRBSqF1tFsjDFT9N902kTJsCJQtoNy/bI6ktMYL6RF+2rz9UoYvz9LJTxq3tlex Uf73RhkfPStz8i1CQq5QSwMEFAAAAAgA2XCCKvMfgrDKAAAAQgEAABIAAAAyNy0xODAtcmluZ2lu Zy50eHRtjjFvwjAQhXf/ihthSMnZDYRLU5UEqjKgRg2wIAYnsYIlYwPx/1ctdarIpze903169baa 8ZcYMI3hR9s+hB21JKj/DrPDuoJTEiCSUlLTNNS2LXVdd2afD3clWBmtLBRGDl494G3QNyrEfFJ/ rSKchMcIAxl4fVW5mCMXm6TIYFD3fMGn0w/jWmkubvDvmZd9jgtMecr2jsZUPDCuEs8qga+YLFkp jYm2a4KRVf9Nz5tYGToC5Esov3ebPSud9cr6yCjb+wtBzH4BUEsDBBQAAAAIANlwgiqw1/e88QAA AJIBAAAMAAAAMjgtcHJhY2sudHh0dZBBb4JAFITv+yveUQ8guyuij9IoaFNi0hC1XpoelmUrxGXX yv7/FE16aKRzm5fM9yZT7FbZFrrmgs6elZkuL7KTX9Svbat8oxzs82LC/IAcG4G/ZvK+LuAj7IUo hMCyLFFKiVVVfZKXq20RVrpRBlItOqeu8HR7kPLZaP+68uioD3q0VwyuaVXCZ5TxTZjG0KnvJGLj 8VJbKXRtO/ccO3FKaETnbE4OFodQrNcwij+iOJ3ScEEyobWXrxEGWv0lPXYiWX9DoDyA4jYfyaxx Qjq87/jfLjshzwiLgDGgLIL87ZgfNveoMs7TypxcjRCQH1BLAwQUAAAACADZcIIquQPl8t4AAABh AQAADQAAADMzLTIwMC1vay50eHRtjs1OwzAQBu9+ij22h6T+IW3ZENQkBVEViYgAF8TBcUwT4dil 9vuLUE6omeOn3dHUu2rBYwqcUnjak7deItR/2+J1W8F7MoIopcSmaVAphW3bfpD7kxsQctNrC4WR PugT3Pj+iIVYzuqHPGKz8TFiIymEftCZWDIu7pIiBa+/sxWfzzfGKWk658NtGuQhYyu25mvy4nBK xUemVeJSJdgVS65JKY2JdluEiar/pssmUo4bAhMUque83JPS2SBVQPhtC+5L22RzVF59srhzg46t DucbbUP0qO0hdAiU/ABQSwMEFAAAAAgA2XCCKkd4BZbeAAAAYQEAAA0AAAAzNy0yMDAtb2sudHh0 bY7BT4MwFIfv/SvecTvAaCtsPsQMmMZlJpIxvRgPpdRBLO1c+/9HnCczvuMv73356m21YGEELIrg ZUfeeoFQ/22L100F7/EIohACm6ZBKSW2bftBHs92QMh1rwwUWjivznDn+hMWPJnVT3lAZ+NjQEdS 8P2gMp5Qxh/iIgWnvrMlm8/X2kqhO+v8ferFMaNLumIrcrA4pWIj0yp+reL0hsa3pBRaB9sNwkTV f9N1EynHDYHyCKp9Xu5IaY0X0iP8tnn7pUyyPkknP2nY2UGFRvnLjTI+eFbm6DuEiPwAUEsDBBQA AAAIANhwgir6fi3EyAEAABIDAAANAAAAMDEtaW52aXRlLnR4dH1RXW/aMBR996+4j62GS+LUCZi6 aoBuy6R1ETBepj2YxJRI8Ucdg5p/P8O0jm3t7pPv1/G55xQP62J1D11j2bsYk5hgSikmIe52Rskr Lf1k30nH7c5oCcuiHJKrCK0bwX4lw6/zEr6FNcqYEIJtNhtWVRWr6/o7Wu6tNc7LmkEcRU62aCGV 8RKXwvkeF3MGn8xOw9xIuPGyPWcRh7hFpTPPPV7Ip33jJAPrmoOoepRro3vV+J7Bl+0WvXdGMcjb RmqYtqLz0sHN8appkl4sP+Y4vvgLeQK+UZInaUySezqdQCefeEYuL+9aU4l2Zzp/G2bEI4+zeERG aGUYvIl4VOx1xOQcEc1E256u/o3yQujP7X/poFmoBR1JBsXJNjQz2ovK/+T1lgXHIak9XvU26Ces bZtK+MboYVfbl24r9aPfMSA0QejAI2Q4BjIeZeMkUKLnz+IBijKFV79DHceo4v+f2fB8ydJr5Pk4 yuKUkoxChBQX+7oxkFzTFBarcpivSxhnkMA4RYI7b5WwLBTyz4uQb5U/ZcrUEnfS82hABnSQTUCJ 560TSnacnO2l8CEjKU7IcBRFUWg8mY4poWvhjeuDV7p2sjqgH1BLAwQUAAAACABLYIMqIG44Xd8A AABiAQAACgAAADUxLWJ5ZS50eHR1j0FrwkAQhe/7K+aolFV3w6pMmqKJKRV6ENIKIj1sksEENrua 3f7/xkNbS9t3G5j3vffSQw6+PeOd4FJIrpTictCqcR1NLIX43VOfnBtnCYrtbionM7ZvNX4e09fN Do6DTSFqrbEsS6yqCuu6fmOPvesQ1qYlC6nRPlAP99e0NJqPiqc1F6ObXDEohtB2lERzIaNcpTF4 uiQLOR6vjKu0aZwPD8OPPiViIZZyyV4cwr/E65K/idEtkWXaGL7dIHxTvgr9dP+uw7KCLggikpAe cpY5G8gG/kz2FBqEGfsAUEsDBBQAAAAIAEtggyrVUpx3ygAAAD0BAAANAAAANTItMjAwLW9rLnR4 dHWO24rCMBRF3/MV59Ei0eYEL5xa0VaHEQcUqoKID2kbbCFtRpv/ZwIDc2HG9bjZe7GzzX6IgxAw DGG3ZadaEWSf2fC42sNl5CFSSlGe51QUBZVleWUvD9sQLE2tW0iM6px+wKyr3ymR4172uuSi1xcc BXK/58ITgasbHcuxQLkeJRF0+h5PMAgWxhbKVLZzc99Rt1hMxBSn7GAJnhrR879R/jSyVBnDNyuC b8vXod/rv3dYmuk7gZAIyXnNUts63Tr+ptubqwhC9gFQSwECFAAUAAAACADZcIIqyyT3G98AAAB4 AQAACgAAAAAAAAABACAAtoEAAAAAMzgtYWNrLnR4dFBLAQIUABQAAAAIANhwgiqHiRmEzwAAAEQB AAARAAAAAAAAAAEAIAC2gQcBAAAwMi0xMDAtdHJ5aW5nLnR4dFBLAQIUABQAAAAIANhwgir4dO3L 4QEAABIDAAAOAAAAAAAAAAEAIAC2gQUCAAAxMS0xODMtc2RwLnR4dFBLAQIUABQAAAAIANhwgirq 0aqDgAEAAJICAAAMAAAAAAAAAAEAIAC2gRIEAAAxMi1wcmFjay50eHRQSwECFAAUAAAACADYcIIq S1puTt4AAABhAQAADQAAAAAAAAABACAAtoG8BQAAMTctMjAwLW9rLnR4dFBLAQIUABQAAAAIANhw giqoiKCscAEAAHoCAAAMAAAAAAAAAAEAIAC2gcUGAAAxOS1jb21ldC50eHRQSwECFAAUAAAACADY cIIqzCGCHd4AAABhAQAADQAAAAAAAAABACAAtoFfCAAAMjQtMjAwLW9rLnR4dFBLAQIUABQAAAAI ANlwgirzH4KwygAAAEIBAAASAAAAAAAAAAEAIAC2gWgJAAAyNy0xODAtcmluZ2luZy50eHRQSwEC FAAUAAAACADZcIIqsNf3vPEAAACSAQAADAAAAAAAAAABACAAtoFiCgAAMjgtcHJhY2sudHh0UEsB AhQAFAAAAAgA2XCCKrkD5fLeAAAAYQEAAA0AAAAAAAAAAQAgALaBfQsAADMzLTIwMC1vay50eHRQ SwECFAAUAAAACADZcIIqR3gFlt4AAABhAQAADQAAAAAAAAABACAAtoGGDAAAMzctMjAwLW9rLnR4 dFBLAQIUABQAAAAIANhwgir6fi3EyAEAABIDAAANAAAAAAAAAAEAIAC2gY8NAAAwMS1pbnZpdGUu dHh0UEsBAhQAFAAAAAgAS2CDKiBuOF3fAAAAYgEAAAoAAAAAAAAAAQAgALaBgg8AADUxLWJ5ZS50 eHRQSwECFAAUAAAACABLYIMq1VKcd8oAAAA9AQAADQAAAAAAAAABACAAtoGJEAAANTItMjAwLW9r LnR4dFBLBQYAAAAADgAOADsDAAB+EQAAAAA= ------_=_NextPart_001_01C129AD.3276C859-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 20 15:41:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01381 for ; Mon, 20 Aug 2001 15:41:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08827; Mon, 20 Aug 2001 15:28:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08799 for ; Mon, 20 Aug 2001 15:28:11 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00984 for ; Mon, 20 Aug 2001 15:26:53 -0400 (EDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7KJRLB11915; Mon, 20 Aug 2001 15:27:21 -0400 (EDT) Received: from cisco.com (dhcp-64-102-97-109.cisco.com [64.102.97.109]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABE03381; Mon, 20 Aug 2001 15:27:37 -0400 (EDT) Message-ID: <3B8165B8.1090904@cisco.com> Date: Mon, 20 Aug 2001 15:32:08 -0400 From: Suheel Hussain Organization: Cisco System User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; m18) Gecko/20010131 Netscape6/6.01 X-Accept-Language: en MIME-Version: 1.0 To: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu CC: Rakesh Shah , sip@ietf.org Subject: [SIP] Comments on draft-ietf-sip-callerprefs-04.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I did review the IETF draft and found following changes maybe required: 1. Move 'Table of Contents' to either page 2 or after Introduction section. 2. Function names are too long. Should be shortened; or subnames should be spaced out -- by underscores, etc. -- to improve readability. For instance: matchuriparameters could be changed to match_uri_parameters or matchUriParameters 3. Section 5.2 Accep-Contact header syntax vs example: Accept-contact defines rule is: * [*(";" (cp-params | q-param | scheme-param | strength)) ] Thus rule in example should have been: Accep-Contact: sip:sales@acme.com ; q=0; *;media="!video"; *;q=0.1 .. and so on.. This implies q-params should be followed by ';' instead of ','. Also, except for first q-param, all subsequent q-params should be prepended by '*;' (Maybe I have understood the example :( ) Suheel ssh@cisco.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 20 23:55:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12517 for ; Mon, 20 Aug 2001 23:55:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28261; Mon, 20 Aug 2001 23:46:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA28230 for ; Mon, 20 Aug 2001 23:46:25 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12453 for ; Mon, 20 Aug 2001 23:45:05 -0400 (EDT) Received: from blazer (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f7L3lCR13283 for ; Mon, 20 Aug 2001 22:47:13 -0500 Message-ID: <006001c129f3$92f00600$55fa403f@blazer> From: "Dean Willis" To: Date: Mon, 20 Aug 2001 22:44:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Sip] Need Firewall Traversal Adhoc Report from IETF51 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit There was an ad-hoc on firewall traversal at IETF 51. I literally couldn't get in the room -- it was too full. Guess it was a hot topic . . . So, whoever took the notes and attendance (Somebody Took Notes, Right?) please send them to me. Thanks. -- Dean _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 00:13:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12702 for ; Tue, 21 Aug 2001 00:13:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28804; Tue, 21 Aug 2001 00:03:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28776 for ; Tue, 21 Aug 2001 00:02:59 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12597 for ; Tue, 21 Aug 2001 00:01:44 -0400 (EDT) Received: from blazer (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f7L43lR13378; Mon, 20 Aug 2001 23:03:48 -0500 Message-ID: <012d01c129f5$e527ed50$55fa403f@blazer> From: "Dean Willis" To: , , "Lawrence Conroy" Cc: , , , References: Subject: Re: [Sip] RE: [rohc] Reduced processing overhead for SIP compression Date: Mon, 20 Aug 2001 23:01:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I would argue that there are two goals of SIP or UDP compression. 1) To reduce the bandwidth used by SIP messaging, especially non-session messaging such as REGISTERS and the like. 2) To reduce the serialization delay through very slow connections such as wireless. This impacts call setup time, mid call event processing, and call teardown. It further impacts the jitter induced by mixed signaling and media on a non-interleaving connection such as traditional PPP. -- Dean ----- Original Message ----- From: "Lawrence Conroy" To: ; Cc: ; ; ; Sent: Saturday, August 18, 2001 7:12 AM Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIP compression > >Hi Hans, > > > >Since the SIP Call set up latency is one of the main (if not the main) > >problem we want to solve with signaling compression, I propose we add a > >requirement to that effect: > > > >The compression scheme MUST be such that when applied to SIP, the call > >set up latency is less than X seconds, for a representative set of > >scenarios to be defined. Scenarios specify the messages exchanged, their > >contents, as well as the channel bit rates. > > > >We need to agree on X and the scenarios, but I believe this requirement > >is useful, because compression ratio alone does not adequately capture > >the problem of call set up latency. Scenarios can be based on those > >typically envisioned in cellular cases like 3GPP. > > > >Khiem > > > To which I reply: > Hi Folks, > There is a GERAN meeting at the end of the month, and I will canvas > to see if there is a HARD limit such as that proposed as a requirement. > > However... > I think that the assumption that the main goal of SIP Comp is to reduce > (or, as described above, =>LIMIT<= ) the call set up time is not obvious > (to me, at least) and I'm not yet happy to have it included in the > requirements document as proposed. > > For GERAN at least, the HARD requirement is on the mid-call Re-Invite > sequence, NOT on the call set up. That's probably true for UTRAN as well, > but that's not my area of interest. > > I have already sent a posting on my understanding of the GERAN mid-call > problem and the figures that seem to apply there (and the reasons). > > Of course one benefit of SIP Comp is that we reduce the transmission > time for messages sent during call set up for latency reasons, and so > we may avoid too many re-transmissions of SIP messages. However, I don't > see how this is a HARD requirement and would be interested in understanding > the logic here. > > Do we have a specific limit (like the DCS one that is, I believe, regulated > by the FCC)? > > BR, > L. > -- > lwc@roke.co.uk: +44 1794 833666::: > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 04:19:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02520 for ; Tue, 21 Aug 2001 04:19:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13055; Tue, 21 Aug 2001 03:59:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA13025 for ; Tue, 21 Aug 2001 03:59:17 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02319 for ; Tue, 21 Aug 2001 03:58:01 -0400 (EDT) Received: from hvssa01.nl.lucent.com (h135-85-68-2.lucent.com [135.85.68.2]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7L7xH327030 for ; Tue, 21 Aug 2001 03:59:17 -0400 (EDT) Received: by hvssa01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA20018; Tue, 21 Aug 2001 09:58:15 +0200 (MET DST) Cc: "'Chen, Xin (Xin)'" , sip@ietf.org Received: from lucent.com by hvssa01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA19651; Tue, 21 Aug 2001 09:56:32 +0200 (MET DST) Message-ID: <3B821351.E0FD8874@lucent.com> Date: Tue, 21 Aug 2001 09:52:49 +0200 From: Michel de Boer X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bert Culpepper Original-CC: "'Chen, Xin (Xin)'" , sip@ietf.org Subject: Re: [Sip] Question about SIP bis04 References: <007b01c12686$87110fc0$d497d697@orlando.brite.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit If the UAS never receives the ACK after having retransmitted its 200 OK several times, it seems that the signalling path is broken. So, I would think the a re-INVITE transaction started by the UAS in that case is doomed to fail as well. To me it seems more logical to tear down the session in this case. Regards, Michel Bert Culpepper wrote: > > Well, one use of a re-INVITE is to change the media characteristics of > an existing session. So if a UAS never gets acknowledgement of its > response (times out waiting for the ACK), it can (SHOULD) assume the > transaction failed and continue with the media that existed prior to the > re-INVITE. But, the other end has already changed presumably to match > its re-INVITE and it may have even received the 200 from the UAS in > which case it did change its media, leading to a "failed call" situation > (UAC using new media and UAS using old media). The text you ask about > describes a fall-back procedure for the UAS to "recover" the call. The > UAC is not aware of the problem with the UAS receiving its ACK. > > regards, > Bert > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Chen, > Xin (Xin) > Sent: Thursday, August 16, 2001 9:58 AM > To: 'sip@ietf.org' > Subject: [Sip] Question about SIP bis04 > > Could someone please explain to me: > > 15.4 If a UAS never receives an ACK for a 2xx response to a > re-INVITE, it SHOULD generate a re-INVITE > itself in order to synchronize the state of the session. > > What does this description mean? If UAS needs a ACK, why it has to > generate > a re-INVITE? > > Thanks and Regards > > Xin Chen > > Lucent Technologies > Tel: +44 1793 883137 > Mobile: +44 7799 034668 > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 05:32:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03216 for ; Tue, 21 Aug 2001 05:32:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15354; Tue, 21 Aug 2001 05:21:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15329 for ; Tue, 21 Aug 2001 05:21:43 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03082 for ; Tue, 21 Aug 2001 05:20:25 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 10:21:31 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9E24@RSYS002A> From: "Price, Richard" To: "'Jan Christoffersson'" Cc: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" , "'Jonathan Rosenberg'" Date: Tue, 21 Aug 2001 10:21:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Sip] RE: [rohc] Encapsulating EPIC in UDPComp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, Good point about the unidirectional nature of UDPComp. Since there is currently no shared information between the two flow directions, the dynamic dictionary takes longer to populate. I have rerun the simulations using the unidirectional flows only - results are below with the results for a shared dynamic dictionary given for comparison: Unidirectional flows Shared flows No encapsulation at all: 6.72 9.78 UDPComp encapsulation: 0.80 1.17 UDPComp with Huffman (type A): 4.04 5.90 UDPComp with Huffman (type B): 4.41 6.29 UDPComp with Huffman (type C): 4.65 6.85 UDPComp with Huffman (type D): 5.96 8.24 Concerning the choice of tokens to provide in UDPComp, we have one set of results using the existing UDPComp tokens only, as well as 4 sets of results using tokens generated by different variants of Huffman encoding. For an explanation of the 4 types of Huffman encoding please see my original email below. Note that the Huffman tokens replace the original READ token as they basically have the same function, and providing both types simultaneously would be inefficient. Regards, Richard P > -----Original Message----- > From: Jan Christoffersson [mailto:Jan.Christoffersson@epl.ericsson.se] > Sent: Monday, August 20, 2001 2:32 PM > To: Price, Richard > Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se'; 'Jonathan Rosenberg' > Subject: Re: [rohc] Encapsulating EPIC in UDPComp > > > Hi Richard, > I have a few comments to the performance figures when EPIC > (or some other > compression algorithm) is encapsulated in UDPComp. As defined > in the draft > UDPComp is unidirectional. This means that all messages from > the "Simple SIP > to SIP" flow from can't be > used in the > dynamic dictionary, only previous messages sent in the same > direction as the > current message. This would have significant impact on the performance > figures, I believe. > Another thing which I think will have impact on the > performance is the choice > of tokens. For example, the READ-token has nothing to do with > dictionary/code > book management, it just says ''read from a certain place in > the dictionary > and append this to the decompressed message''. But this is > typically what the > references in Lempel-Ziv compression algorithms mean. In > practice this means > that we are using two tokens with the same meaning to read a > string from the > dictionary, surely one token would be sufficient? I guess the > there is room > for plenty of discussion on what types of tokens are needed > to support both > the different compression algorithms that people would like > to use and maybe > also to support the kind of dictionary/code book > manipulations that are > desired. > > Regards, > Jan Christoffersson > > "Price, Richard" wrote: > > > Hi, > > > > Attached is a (rather detailed) posting on the overhead of > > encapsulating EPIC within UDPComp. The conclusion is that by adding > > Huffman codes to UDPComp, the protocol overhead can be made very > > low (just 5 bytes per message). > > > > Comments are welcome! > > > > Richard P > > > > -------------------------------------------------------------------- > > > > This is a follow-up to my earlier posting on the performance of > > various signaling compression algorithms. I mentioned that > one of the > > ideas of UDPComp is to make the compression algorithm a local > > implementation decision at the compressor: this makes the protocol > > very lightweight and flexible, but potentially reduces the > compression > > efficiency due to transmitting the semantics of the compression > > algorithm in each packet. > > > > As promised, here are some performance figures to illustrate this > > overhead. We tested the EPIC algorithm encapsulated in UDPComp using > > the "Simple SIP to SIP" flow from > . > > > > We assume that the compressor and decompressor each contain a static > > dictionary of text strings commonly used in SIP. This can > be "learnt" > > by compressing sufficient SIP messages, or alternatively > can be fixed > > a-priori. We also use a dynamic dictionary (i.e. compress > relative to > > previous messages in the flow). > > > > Note that UDPComp offers significant flexibility in the choice of > > "token" used to transmit text strings from the compressor to the > > decompressor. Currently the scheme sends a fixed 1-2 byte index to > > reference each text string, but additional tokens can > easily be added > > (for example tokens that use Huffman codes to reference > text strings). > > We have provided a range of performance figures using > different types > > of token to transmit the data. > > > > For comparison, the compression ratio using only the > existing UDPComp > > tokens is given below: > > > > EPIC algorithm with no encapsulation: 9.78 > > > > UDPComp using existing tokens only: 1.17 > > > > The decrease in compression ratio is caused by sending a > 1-2 byte index > > to reference each text string. In contrast, the EPIC > algorithm usually > > references a text string by sending a short Huffman code (typically > > 1 - 4 bits). > > > > To improve the compression ratio it is possible to add > Huffman codes to > > UDPComp. In general this is straightforward: the only > potential problem > > is that the Huffman codes are chosen specifically for EPIC, > and different > > variants of Lempel-Ziv may need a different set of Huffman > codes. Thus, > > it may be necessary to download new sets of Huffman codes to the > > decompressor depending on the choice of algorithm. > > > > Adding Huffman codes to UDPComp can be done in several ways. Firstly > > we have a choice between EPIC-LITE (which uses ordinary > Huffman codes) > > and EPIC (which uses a special version of Huffman encoding > capable of > > compressing text strings down to less than one bit - for example 3 > > common text strings in a row might together be indicated by > sending a > > single "0" bit). > > > > Secondly, we have a choice between selecting a global set of Huffman > > codes for all text strings, and using a different set for > each dictionary > > entry. In the latter case the Huffman code for each text > string actually > > changes depending on the previously received string. This > improves the > > compression ratio at a cost of higher memory requirements > (which may be > > a problem if we have to store the Huffman codes in working memory). > > > > Compression ratios for each choice are given below: > > > > UDPComp using EPIC-LITE with global Huffman codes: 5.90 > > > > UDPComp using EPIC-LITE with local Huffman codes: 6.29 > > > > UDPComp using EPIC with global Huffman codes: 6.85 > > > > UDPComp using EPIC with local Huffman codes: 8.24 > > > > Initial results are promising: if required we can make the > overhead of > > encapsulating EPIC within UDPComp negligible (essentially it is just > > the 5 bytes of initial UDPComp header per message). I > believe the next > > step should be to check how other compression algorithms > fit into the > > UDPComp framework, and to decide on a "sweet spot" between > compression > > efficiency and standardizing the protocol in the given timeframe. > > > > > -------------------------------------------------------------- > ---------- > > Name: RMRL-Disclaimer.txt > > RMRL-Disclaimer.txt Type: Plain Text (text/plain) > > Encoding: 7bit > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 05:55:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03508 for ; Tue, 21 Aug 2001 05:55:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15853; Tue, 21 Aug 2001 05:41:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA15822 for ; Tue, 21 Aug 2001 05:41:40 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03335 for ; Tue, 21 Aug 2001 05:40:22 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 10:41:27 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9E25@RSYS002A> From: "Price, Richard" To: "'Liu Zhigang.C (NRC/Dallas)'" , sip@ietf.org, rohc@cdt.luth.se Cc: jdrosen@dynamicsoft.com Subject: RE: [Sip] Encapsulating EPIC in UDPComp Date: Tue, 21 Aug 2001 10:41:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, Does UDPComp currently have the ability to support a user-specific dictionary? If no additional effort is required then we should certainly assume a combined dictionary in all comparisons. If UDPComp needs to be modified then we should compare results with and without a user-specific dictionary - if the gain in compression efficiency is big enough then we can make the necessary modifications to UDPComp. Regards, Richard P > -----Original Message----- > From: Liu Zhigang.C (NRC/Dallas) [mailto:zhigang.c.liu@nokia.com] > Sent: Monday, August 20, 2001 5:12 PM > To: Price, Richard; sip@ietf.org; rohc@cdt.luth.se > Cc: jdrosen@dynamicsoft.com > Subject: RE: [Sip] Encapsulating EPIC in UDPComp > > > Still, the numbers indicate that with a combined dictionary (including > user-specific) can easily boost the compression ratio to close to 10, > even for the generic approach like LZSS (I would assume LZW will > have similar result). Then, shouldn't we assume a combined dictionary > in all comparisons? > > BR, > Zhigang > > > > -----Original Message----- > > From: ext Price, Richard [mailto:richard.price@roke.co.uk] > > Sent: August 20, 2001 5:21 AM > > To: Liu Zhigang.C (NRC/Dallas); sip@ietf.org; rohc@cdt.luth.se > > Cc: jdrosen@dynamicsoft.com > > Subject: RE: [Sip] Encapsulating EPIC in UDPComp > > > > > > Hi, > > > > The discrepancy is because the second set of compression ratios does > > not include a user-specific dictionary. In this case, the > compression > > ratio for the EPIC algorithm with no protocol overhead is 9.78 (vs > > 15.53 including a user-specific dictionary). > > > > The purpose of the second set of compression ratios is to check the > > protocol overhead of UDPComp. This may be quite substantial because > > UDPComp employs a standard decompressor, not specifically optimized > > for any one particular compression algorithm. > > > > At present the decompressor doesn't even understand Huffman > encoding, > > so an explicit 1-2 byte index has to be sent for each text string > > instead. This reduces the compression ratio as follows: > > > > No encapsulation at all: 9.78 > > > > UDPComp encapsulation: 1.17 > > > > Fortunately it is pretty easy to add Huffman encoding to > UDPComp, and > > the protocol overhead is reduced substantially. For the > most powerful > > variant of Huffman compression the overhead is as follows: > > > > UDPComp encapsulation with Huffman encoding: 8.24 > > > > This is a much lower overhead (5 bytes per compressed message). > > > > Regards, > > > > Richard P > > > > > -----Original Message----- > > > From: zhigang.c.liu@nokia.com [mailto:zhigang.c.liu@nokia.com] > > > Sent: Friday, August 17, 2001 11:47 PM > > > To: Price, Richard; sip@ietf.org; rohc@cdt.luth.se > > > Cc: jdrosen@dynamicsoft.com > > > Subject: RE: [Sip] Encapsulating EPIC in UDPComp > > > > > > > > > > For comparison, the compression ratio using only the > > > existing UDPComp > > > > tokens is given below: > > > > > > > > EPIC algorithm with no encapsulation: 9.78 > > > > > > > > UDPComp using existing tokens only: 1.17 > > > > > > Richard, > > > > > > I'm a bit puzzled by the numbers. According to your own data sent > > > earlier (http://www.cdt.luth.se/robhc/msg02428.html), even a > > > generic LZSS can achieve a compression ratio of 9.87 with > a combined > > > dictionary. What is the point here? > > > > > > BR, > > > Zhigang > > > > > > > > > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 07:30:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05303 for ; Tue, 21 Aug 2001 07:30:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18339; Tue, 21 Aug 2001 07:13:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18307 for ; Tue, 21 Aug 2001 07:13:08 -0400 (EDT) Received: from rafi ([213.8.76.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04536 for ; Tue, 21 Aug 2001 07:11:50 -0400 (EDT) From: sales@seebex.com Received: from mail pickup service by rafi with Microsoft SMTPSVC; Tue, 21 Aug 2001 14:13:08 +0200 To: Date: Tue, 21 Aug 2001 14:13:08 +0200 Message-ID: <128e01c12a3a$a37db980$0200a8c0@rafi> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcEqOqN9EbWKnXMOSLyLWd50FnsKJQ== Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 21 Aug 2001 12:13:08.0258 (UTC) FILETIME=[A37F4020:01C12A3A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id HAA18308 Subject: [Sip] Instant Messaging platform at your Web site is now a few clicks away Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Instant Messaging platform at your Web site is now a few clicks away ---------------------------------------------------------------------- Install a FREE Instant Messaging server at your Web site. Use it as is or customize to meet your specific branding. Cross platform servers line support 25 and up to 1000 concurrent users All servers offered can be secured with RSA 512Bit (and higher) encryption!! Download free 10 concurrent users server at: http://www.seebex.com/download/get_server.asp It is easier, faster and affordable than ever!! For further information please check seebex Web site at: http://www.seebex.com or contact our Marketing & Sales department at sales@seebex.com First 50 Web sites to download and embed the free 10 concurrent users server are entitled to a free 100 concurrent users server and will be listed on Seebex Web site. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 07:37:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05571 for ; Tue, 21 Aug 2001 07:37:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18810; Tue, 21 Aug 2001 07:28:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18782 for ; Tue, 21 Aug 2001 07:28:23 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05174; Tue, 21 Aug 2001 07:27:06 -0400 (EDT) Message-Id: <200108211127.HAA05174@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 21 Aug 2001 07:27:06 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-overlap-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Mapping of ISUP Overlap Signalling to SIP Author(s) : G. Camarillo, A. Roach, J. Peterson, L. Ong Filename : draft-ietf-sip-overlap-01.txt Pages : 9 Date : 20-Aug-01 This document describes a way to map ISUP overlap signalling to SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-overlap-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-overlap-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-overlap-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: <20010820135834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-overlap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-overlap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010820135834.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 09:57:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13647 for ; Tue, 21 Aug 2001 09:57:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22859; Tue, 21 Aug 2001 09:47:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA22832 for ; Tue, 21 Aug 2001 09:47:10 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12776; Tue, 21 Aug 2001 09:45:53 -0400 (EDT) Message-Id: <200108211345.JAA12776@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 21 Aug 2001 09:45:52 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-overlap-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Mapping of ISUP Overlap Signalling to SIP Author(s) : G. Camarillo, A. Roach, J. Peterson, L. Ong Filename : draft-ietf-sip-overlap-01.txt Pages : 9 Date : 20-Aug-01 This document describes a way to map ISUP overlap signalling to SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-overlap-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-overlap-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-overlap-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: <20010820135834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-overlap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-overlap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010820135834.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 10:57:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18660 for ; Tue, 21 Aug 2001 10:57:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25876; Tue, 21 Aug 2001 10:42:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25786 for ; Tue, 21 Aug 2001 10:42:28 -0400 (EDT) Received: from mail2.intervoice-brite.com (mail2.intervoice-brite.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17265 for ; Tue, 21 Aug 2001 10:41:11 -0400 (EDT) Received: from 172.16.16.64 (gwsmtpsrv.intervoice.com [172.16.16.64]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with SMTP id JAA27864 for ; Tue, 21 Aug 2001 09:47:00 -0500 Received: from bculpepperpc ([151.214.151.122]) by 172.16.16.64; Tue, 21 Aug 2001 09:41:38 -0500 From: "Bert Culpepper" To: "'Michel de Boer'" Cc: "'Chen, Xin (Xin)'" , Subject: RE: [Sip] Question about SIP bis04 Date: Tue, 21 Aug 2001 10:42:04 -0400 Message-ID: <001801c12a4f$7fc53c60$15d8fea9@orlando.brite.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3B821351.E0FD8874@lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, I agree with you that subsequent signaling transactions are likely to fail under network conditions that resulted in the ACK never arriving at the UAS. However, there may be situations in which a re-INVITE in the reverse direction may succeed. There are also other uses of re-INVITE, such as session-timer, that the procedure described can add value to. Others more experienced with SIP than myself can better provide the motivation behind the text asked about. I suppose the authors feel it is better to attempt (at least once) to recover the session instead of dropping it right away. I myself interpret the text asked about as exhibiting this philosophy, with which I agree. I also suspect this is the "best" approach for all uses of re-INVITE, and is preferable to defining a procedure for each case. regards, Bert > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > Of Michel > de Boer > Sent: Tuesday, August 21, 2001 3:53 AM > To: Bert Culpepper > Cc: 'Chen, Xin (Xin)'; sip@ietf.org > Subject: Re: [Sip] Question about SIP bis04 > > > If the UAS never receives the ACK after having retransmitted > its 200 OK > several times, it seems that the signalling path is broken. So, I > would think the a re-INVITE transaction started by the UAS in > that case > is doomed to fail as well. To me it seems more logical to > tear down the > session in this case. > > Regards, > Michel > > Bert Culpepper wrote: > > > > Well, one use of a re-INVITE is to change the media > characteristics of > > an existing session. So if a UAS never gets acknowledgement of its > > response (times out waiting for the ACK), it can (SHOULD) assume the > > transaction failed and continue with the media that existed > prior to the > > re-INVITE. But, the other end has already changed > presumably to match > > its re-INVITE and it may have even received the 200 from the UAS in > > which case it did change its media, leading to a "failed > call" situation > > (UAC using new media and UAS using old media). The text > you ask about > > describes a fall-back procedure for the UAS to "recover" > the call. The > > UAC is not aware of the problem with the UAS receiving its ACK. > > > > regards, > > Bert > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On > Behalf Of Chen, > > Xin (Xin) > > Sent: Thursday, August 16, 2001 9:58 AM > > To: 'sip@ietf.org' > > Subject: [Sip] Question about SIP bis04 > > > > Could someone please explain to me: > > > > 15.4 If a UAS never receives an ACK for a 2xx response to a > > re-INVITE, it SHOULD generate a re-INVITE > > itself in order to synchronize the state of the session. > > > > What does this description mean? If UAS needs a ACK, why it has to > > generate > > a re-INVITE? > > > > Thanks and Regards > > > > Xin Chen > > > > Lucent Technologies > > Tel: +44 1793 883137 > > Mobile: +44 7799 034668 > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 11:19:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19786 for ; Tue, 21 Aug 2001 11:19:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26834; Tue, 21 Aug 2001 11:05:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26806 for ; Tue, 21 Aug 2001 11:05:08 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19043 for ; Tue, 21 Aug 2001 11:03:51 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7LF58v01947 for ; Tue, 21 Aug 2001 17:05:08 +0200 (MEST) Received: from lmf.ericsson.se (racom160254.am.ericsson.se [138.85.160.254]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id RAA07571 for ; Tue, 21 Aug 2001 17:05:05 +0200 (MET DST) Message-ID: <3B827BE5.B85D6FAF@lmf.ericsson.se> Date: Tue, 21 Aug 2001 18:19:01 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] I-D ACTION:draft-ietf-sip-overlap-01.txt References: <200108211345.JAA12776@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, This new version, besides minor changes, contains two main additions: 1) 490 Request updated 2) Explanation on how Cseq is handled Regards, Gonzalo Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Working Group of the IETF. > > Title : Mapping of ISUP Overlap Signalling to SIP > Author(s) : G. Camarillo, A. Roach, J. Peterson, L. Ong > Filename : draft-ietf-sip-overlap-01.txt > Pages : 9 > Date : 20-Aug-01 > > This document describes a way to map ISUP overlap signalling to SIP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sip-overlap-01.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-sip-overlap-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-sip-overlap-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. > > ------------------------------------------------------------------------ -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 11:26:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20287 for ; Tue, 21 Aug 2001 11:26:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27202; Tue, 21 Aug 2001 11:09:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27171 for ; Tue, 21 Aug 2001 11:09:55 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19294 for ; Tue, 21 Aug 2001 11:08:38 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7LF8crN006979 for ; Tue, 21 Aug 2001 11:08:38 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 11:09:26 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Tue, 21 Aug 2001 11:09:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] URGENT: session timer: new issues Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, I was in the process of updating the session timer draft, getting it ready for IESG, when I happened across several additional issues. For one, there is a reasonable solution, but the other is more serious and requires some discussion. Sigh... Issue #1 -------- The 422 response code allows a proxy to reject a request with a session-expires which is too low. It includes a Min-SE header with the minimum value that it is willing to accept. According to the current draft, the client is supposed to insert the Min-Se header into an INVITE, and the value is: the value MUST be the largest value amongst all Session-Expires values returned in 422 responses on that leg. This wording is imprecise, since a leg won't have been established when you get a 422 to the initial INVITE. As I was rewording this, I realized that you might get a bunch of 422's before the call is setup, from proxies that aren't eventually in the path of the final call leg (because of forking, primarily). Consider the case where A calls B, and there is a Session-Expires in the INVIITE A sends, with value 50. THis hits proxy X, which forks to Y and Z. Y returns a 422 with a Min-SE of 10000, and Z returns a 422 with a Min-SE of 75. The proxy forwards one of them arbitrarily, say the one from Y. The client should retry the request with a Min-SE header in the INVITE, with value 10000, and a Session-Expires of 10000. This once again forks to Y and Z. Its OK by Y, but not by Z, so Z returns 422 with value 75. The fork from Y returns a 486, so the proxy forwards the 422 upstream (there is another issue here, which is that if Z returns a 408, the proxy will forward the 408, and then thats it - call failure. Ideally, the proxy should have forwarded the 422 so that the client can retry the request. This is a generic problem, not specific to session timer, regarding which messages a proxy chooses to forward upstream). Anyway, the UAC gets that 422 with a Min-SE of 75, and then retries the request with a value of Min-SE of 10000, and Session-Expires of 10000. Once again, it forks through Y and Z. THe branch through Z returns a 200 OK. Now, in refreshes to the session, the Min-SE will always be present with a value of 10000. THis is veyr large, and way above the minimum required by the proxies on the path of the call leg established through Z. My fix for this is that the client uses the max of the Min-SE amongst all 422 in all responses for a particular CALL before any call legs are established. Once a call leg is established, it uses the max of the min-SE returned in all 422 responses for that call leg (i.e, with the same tag as the 2xx that created the leg). As a result, when the call is accepted, the max of the Min-SE is effectively "cleared", and then can be reset to the max of the Min-SE on the path of the call leg. This seems to work fine. ISSUE #2 -------- The big problem occurs when the 422 is used when the client doesn't support session timer. So, the client sends an INVITE, and it knows nothing of session-timer. A proxy inserts a Session-Expires into the request (which it is allowed to do). It uses a Session-Expires of value 100. A downstream proxy thinks that this is too small, so it rejects the request with a 422, and a Min-SE of 200. This hits the client. But, since the client doesn't know the session timer, the result is a call failure, since it won't know to retry the request with the Min-SE header present. Oops. Now, we can mandate that 422 is returned only when the Supported header was present in the INVITE. But, this means that sessions can be setup with really low session timers. That seems bad. A better solution (soln 1) is to mandate that when there is no Supported header, a proxy cannot insert a session timer value lower than a specific minimum (namely, 30 minutes), and that no proxy server can reject a request with a 422 if the session timer is larger than 30m (i.e., there be a maximum minimum session expiration). Another option (soln 2) is this. A proxy can insert both a Session-Expires and Min-SE into the request. If a proxy sees a request without a Supported header, but with a Session-Expires header below its minimum, it can insert a Min-SE header into the request before proxying it (although it can't increase the session timer). When this hits the UAS, if it sees a session-expires with a value lower than min-se, it uses the value from min-se instead of the value in session-expires. Soln 1 is simpler, but can result in sessions being established with large session timers even though smaller ones are possible and desired. Solution 2 sets up the session with the right timer value, but requires further special case processing. I would probably recommend solution 2, but I don't feel strongly and am not sure the complexity is worth it. Comments? -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 13:31:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24768 for ; Tue, 21 Aug 2001 13:31:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02376; Tue, 21 Aug 2001 13:03:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02348 for ; Tue, 21 Aug 2001 13:03:56 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23892 for ; Tue, 21 Aug 2001 13:01:25 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LH2ki24244 for ; Tue, 21 Aug 2001 12:02:46 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Aug 2001 12:02:41 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 12:02:41 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] Encapsulating EPIC in UDPComp Date: Tue, 21 Aug 2001 12:02:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] Encapsulating EPIC in UDPComp X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEqJXmoT9pTkZYXEdWrxAAIx6S5QwAN11vg From: "Liu Zhigang.C (NRC/Dallas)" To: "'ext Price, Richard'" , , Cc: X-OriginalArrivalTime: 21 Aug 2001 17:02:41.0561 (UTC) FILETIME=[16CAE890:01C12A63] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA02349 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit > Does UDPComp currently have the ability to support a user-specific > dictionary? If no additional effort is required then we > should certainly assume a combined dictionary in all comparisons. To me, yes, the user-specific dictionary is just a matter of pre-population (of entries in codebook for LZW, or byte array for LZSS). The effort should be much less than that of adding Huffman Coding (especially if it is dynamic). See more comments below. > If UDPComp needs to be modified then we should compare > results with and without a user-specific dictionary - > if the gain in compression efficiency is big enough > then we can make the necessary modifications to UDPComp. The results are already shown from various sources (you, Hans and us). Quoting your number (from 1.17 to 9.87), I would say the gain is big. And more important, the associated complexity is almost trivial. We can simply use the existing WRITE to pre-populate the codebook, plus a flag indicating no message should be delivered to the upper layer. Furthermore, it is generic and no SIP knowledge is assumed. Should we apply the same standard on all approaches, including EPIC? BR, Zhigang _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 13:36:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25015 for ; Tue, 21 Aug 2001 13:36:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02631; Tue, 21 Aug 2001 13:18:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02602 for ; Tue, 21 Aug 2001 13:17:59 -0400 (EDT) Received: from maliwan.psu.ac.th (maliwan.psu.ac.th [192.100.77.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24415 for ; Tue, 21 Aug 2001 13:16:41 -0400 (EDT) Received: from oossy ([172.30.2.69]) by maliwan.psu.ac.th (8.11.4/8.11.4) with SMTP id f7LHHqQ18783 for ; Wed, 22 Aug 2001 00:17:52 +0700 (ICT) Message-ID: <000801c12a65$fdd39550$45021eac@oossy> From: "Jatupong Arun" To: Date: Wed, 22 Aug 2001 00:23:27 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C12AA0.A9F6EAF0" 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 Subject: [Sip] don't understand about MD5 algorithm Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C12AA0.A9F6EAF0 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable I don't understand about MD5 algorithm for authentication.I read rfc2617 = but don't clear. If anybody know how i solve response when recieve = response 407,401. What parameter I must to know before solve response. = If any have source code about MD5 Algorithm or know the source for learn = MD5 algorithm. Thanks a lot oossy ------=_NextPart_000_0005_01C12AA0.A9F6EAF0 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
I don't understand about MD5 algorithm = for=20 authentication.I read rfc2617 but don't clear. If anybody know how i = solve=20 response when recieve response 407,401. What parameter I must to know = before=20 solve response. If any have source code about MD5 Algorithm or know the = source=20 for learn MD5 algorithm.
 
 
Thanks a lot
oossy
------=_NextPart_000_0005_01C12AA0.A9F6EAF0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 17:19:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01452 for ; Tue, 21 Aug 2001 17:19:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09230; Tue, 21 Aug 2001 17:04:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09197 for ; Tue, 21 Aug 2001 17:03:08 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01270 for ; Tue, 21 Aug 2001 17:01:49 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7LL0UrN010688; Tue, 21 Aug 2001 17:00:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 17:01:17 -0400 Message-ID: From: Jonathan Rosenberg To: "'Romeo Zwart'" , Jonathan Rosenberg Cc: sip@ietf.org, rohc@cdt.luth.se Subject: RE: [Sip] I-D ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt Date: Tue, 21 Aug 2001 17:01:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Romeo Zwart [mailto:Romeo.Zwart@att.com] > Sent: Tuesday, August 14, 2001 10:37 AM > To: Jonathan Rosenberg > Cc: sip@ietf.org; rohc@cdt.luth.se > Subject: RE: [Sip] I-D ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt > > > Coming back from vacation I see a lot of water has passed under > the bridge on this topic. One minor question remains, please see > below. > > At 11:38 PM 7/30/2001, Jonathan Rosenberg wrote: > > > -----Original Message----- > > > From: Romeo Zwart [mailto:Romeo.Zwart@att.com] > > > Sent: Thursday, July 19, 2001 3:27 PM > > > To: jdrosen@dynamicsoft.com > > > Cc: sip@ietf.org; rohc@cdt.luth.se > > > Subject: Re: [Sip] I-D > ACTION:draft-rosenberg-rohc-sip-udpcomp-00.txt > > > > > > Jonathan, > > > > > > In the diagram of section 4.6, the WRITE HIGH REFERENCE token > > > is shown as > > > identical to the WRITE HIGH token. I assume this is a typo. > > > What is the > > > intended token for the WRITE HIGH REFERENCE case? > > > >No, they're not the same. The WRITE HIGH REFERECE appears on > the top of page > >9. So, WRITE REFERENCE is: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1| index |1|1|0| TC | tokens.. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >and WRITE HIGH REFERENCE is: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1| index |0|1|1| index |x|x|x| TC | tokens > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Right, whereas, in section 4.4 WRITE HIGH is also shown as: > > 4.4 WRITE HIGH > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| index |0|1|1| index | length | entry... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > One of these has to be a typo, right? Write high and write high reference are not the same. Write high reference creates a new codebook entry by concatenating existing entries. Write high simply creates a new one from the enclosed text. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 21 21:14:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04205 for ; Tue, 21 Aug 2001 21:14:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14306; Tue, 21 Aug 2001 20:53:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14277 for ; Tue, 21 Aug 2001 20:53:17 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04006 for ; Tue, 21 Aug 2001 20:52:01 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.2) id f7M0rGQ60570; Tue, 21 Aug 2001 20:53:17 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Jonathan Rosenberg'" , Subject: RE: [Sip] URGENT: session timer: new issues Date: Tue, 21 Aug 2001 20:52:36 -0400 Message-ID: <004301c12aa4$bd28b7d0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > Issue #1 > -------- > My fix for this is that the client uses the max of the Min-SE > amongst all > 422 in all responses for a particular CALL before any call legs are > established. Once a call leg is established, it uses the max > of the min-SE > returned in all 422 responses for that call leg (i.e, with > the same tag as > the 2xx that created the leg). As a result, when the call is > accepted, the > max of the Min-SE is effectively "cleared", and then can be > reset to the max > of the Min-SE on the path of the call leg. This seems to work fine. Sounds good. > > ISSUE #2 > -------- > Another option (soln 2) is this. A proxy can insert both a > Session-Expires > and Min-SE into the request. If a proxy sees a request > without a Supported > header, but with a Session-Expires header below its minimum, > it can insert a > Min-SE header into the request before proxying it (although it can't > increase the session timer). When this hits the UAS, if it sees a > session-expires with a value lower than min-se, it uses the value from > min-se instead of the value in session-expires. Solution 2 sounds fine. The same solution works for when the UAS thinks Session-Expires was too small. The UAS would use its own Min-SE for the Session-Expires instead of rejecting with a 422. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 00:51:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09082 for ; Wed, 22 Aug 2001 00:51:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19550; Wed, 22 Aug 2001 00:41:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19519 for ; Wed, 22 Aug 2001 00:41:14 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09020 for ; Wed, 22 Aug 2001 00:39:56 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7M4dnrN012716; Wed, 22 Aug 2001 00:39:49 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 00:40:37 -0400 Message-ID: From: Jonathan Rosenberg To: "'Price, Richard'" , "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Cc: Jonathan Rosenberg Date: Wed, 22 Aug 2001 00:40:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Encapsulating EPIC in UDPComp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Friday, August 17, 2001 11:58 AM > To: 'sip@ietf.org'; 'rohc@cdt.luth.se' > Cc: 'Jonathan Rosenberg' > Subject: Encapsulating EPIC in UDPComp > > > Hi, > > Attached is a (rather detailed) posting on the overhead of > encapsulating EPIC within UDPComp. The conclusion is that by adding > Huffman codes to UDPComp, the protocol overhead can be made very > low (just 5 bytes per message). > > Comments are welcome! Yes, yes, yes! This is exactly the direction that I was arguing for at IETF. The idea with UDPComp is that you define a very general purpose decoder, define a protocol for conveying commands to the decoder, and then allow the implementors to choose an encoding mechanism that utilizes the facilities and capabilities of the decoder and protocol. THis is much like the way compression is done for video and audio, where the decoder is really simple, and the compression lies within the encoder. What Richard is proposing here are some new capabilities to add to the protocol/decoder (namely, support for Huffman codes). I think this is the tact we should take - examination of capabilities to add in order to find the right sweet spot between compression efficiency and flexibility. I think that this will ultimately be much more fruitful than needless bantering about whose proposal supports what capabilities, and the relative performances under some two dozen call flows. That kind of approach will mean we never finish in time for the 3g deliverables. Now, I have some comments on how I would incorporate Huffman codes into UDPComp, which are very detailed, and I will post separately. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 01:15:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10454 for ; Wed, 22 Aug 2001 01:15:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19719; Wed, 22 Aug 2001 00:57:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19690 for ; Wed, 22 Aug 2001 00:57:40 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09113 for ; Wed, 22 Aug 2001 00:56:22 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7M4uFrN012751; Wed, 22 Aug 2001 00:56:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 00:57:03 -0400 Message-ID: From: Jonathan Rosenberg To: "'Price, Richard'" , "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Cc: Jonathan Rosenberg Date: Wed, 22 Aug 2001 00:57:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Encapsulating EPIC in UDPComp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Friday, August 17, 2001 11:58 AM > To: 'sip@ietf.org'; 'rohc@cdt.luth.se' > Cc: 'Jonathan Rosenberg' > Subject: Encapsulating EPIC in UDPComp > > > Hi, > > Attached is a (rather detailed) posting on the overhead of > encapsulating EPIC within UDPComp. The conclusion is that by adding > Huffman codes to UDPComp, the protocol overhead can be made very > low (just 5 bytes per message). > > Comments are welcome! Richard is exactly correct that the cost of a general purpose decompressor like this is a hit in overhead. With purely static codebook indices, the overhead is quite large as the results below show. I agree totally that some kind of Huffman coding is needed. I have been thinking about this, and I have a proposal that is different from what Richard is proposing. My proposal would be to make the support for huffman coding very general purpose, and based on a tree-like structure where the codes are dependent on previous elements. Such a hierarchical structure is needed, I think, to support the TCCB and EPIC algorithms. TCCB is really about a two level encoding scheme - the top level are the names of headers, and the second level are their values. They add some optimizations that are SIP specific (such as sending nothing when it can be assumed that the header hasn't changed), which I would rather generalize in some efficient way. So, the idea is that when you write into the codebook, you provide a bit which says whether this write takes place at the current "level" in the hierarchy, or back at the top. Then, you provide a bitstring that represents the huffman code for the token, followed by the token. It is the responsibility of the encoder to make sure that each code is a valid prefix code. When the encoder sends a read command, it contains a bit which indicates whether the read is from the top of the tree or the current position, followed by the code. So, lets take a simple example. We want to compress something like: A: foo B: bar A: baz which is a sort-of sip message thing. We will use a TCCB-like approach, where we encode the headers and values separately. Assume two bits for the message type (READ or WRITE), and 8 bits per character. We can do better using a separate codebook for text, as Richard has proposed. for the first message, we send: WRITE, top=TRUE, "A:" code="0" (2 + 1 + 16 + 1 = 20 bits) WRITE, top=FALSE, "foo" code="01" (2 + 1 + 24 + 2 = 29 bits) WRITE, top=TRUE, "B:" code="11" (2 + 1 + 16 + 2 = 21 bits) WRITE, top=FALSE, "bar" code="01" (2 + 1 + 24 + 2 = 29 bits) READ, top=TRUE, code=0 (2 + 1 + 1 = 4 bits) WRITE, top=FALSE, "baz" code="11" (2 + 1 + 24 + 2 = 29 bits) TOTAL: 132 bits = 16.5 Bytes This is larger than the original (15 bytes), typical for the case where there is no static or user specific codebook. This results in a codebook in the compressor/decompressor that looks like: 0 "A:" 11 "B:" | | ----------- 01 "bar" | | 01 "foo" 11 "baz" Now, if the next message is: A: foo B: bar A: blip Its compressed as: READ, top=TRUE, code=0 (2 + 1 + 1 = 4 bits) READ, top=FALSE, code=01 (2 + 1 + 2 = 5 bits) READ, top=TRUE, code=11 (2 + 1 + 2 = 5 bits) READ, top=FALSE, code=01 (2 + 1 + 2 = 5 bits) READ, top=TRUE, code=0 (2 + 1 + 1 = 4 bits) WRITE, top=FALSE, "blip" code=001 (2 + 1 + 32 + 3 = 38 bits) Total: 61 bits, 7.625 bytes Now, this is better, achieving slightly better than 2:1 over a very small piece of data. An interesting improvement is that I can specify a command which says "READ code XX, and then read the next N symbols in the tree if the number of children at each node is 1, in which case you have no choice about the next symbol anyway". This is useful for trees that are really deep, as opposed to wide. If you think about it, this covers LZSS, which can be viewed as a "hierarchical" codebook where each node is a single character, and the tree is one where each node has only one child, the next character. Comments? Hopefully this makes some sense... -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 01:26:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11976 for ; Wed, 22 Aug 2001 01:26:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27357; Wed, 22 Aug 2001 01:12:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA27295 for ; Wed, 22 Aug 2001 01:12:46 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09992 for ; Wed, 22 Aug 2001 01:11:31 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7M5BRrN012831; Wed, 22 Aug 2001 01:11:27 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 01:12:15 -0400 Message-ID: From: Jonathan Rosenberg To: "'Bert Culpepper'" , "'Michel de Boer'" Cc: "'Chen, Xin (Xin)'" , sip@ietf.org Subject: RE: [Sip] Question about SIP bis04 Date: Wed, 22 Aug 2001 01:12:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Bert Culpepper [mailto:bert.culpepper@intervoice-brite.com] > Sent: Tuesday, August 21, 2001 10:42 AM > To: 'Michel de Boer' > Cc: 'Chen, Xin (Xin)'; sip@ietf.org > Subject: RE: [Sip] Question about SIP bis04 > > > Hi, > > I agree with you that subsequent signaling transactions are likely to > fail under network conditions that resulted in the ACK never > arriving at > the UAS. However, there may be situations in which a re-INVITE in the > reverse direction may succeed. There are also other uses of > re-INVITE, > such as session-timer, that the procedure described can add value to. > Others more experienced with SIP than myself can better provide the > motivation behind the text asked about. Failures can happen for all kinds of reasons. Some will be recoverable, some won't. The idea here is to apply a general recovery mechanism, which involves sending a re-INVITE to achieve agreement on call state and on the current SDP in use for the call. If the re-INVITE doesn't generate any response, a BYE is sent (which may not generate a response either, but at least lets intermediate proxies and other things know the change in call state). > > I suppose the authors feel it is better to attempt (at least once) to > recover the session instead of dropping it right away. I myself > interpret the text asked about as exhibiting this philosophy, > with which > I agree. I also suspect this is the "best" approach for all uses of > re-INVITE, and is preferable to defining a procedure for each case. Yes, that is a good point. Right now, there is no general place to put it.. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 09:43:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07565 for ; Wed, 22 Aug 2001 09:43:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09737; Wed, 22 Aug 2001 08:27:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09708 for ; Wed, 22 Aug 2001 08:27:39 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02612 for ; Wed, 22 Aug 2001 08:26:19 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 13:27:11 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9E29@RSYS002A> From: "Price, Richard" To: "'Jonathan Rosenberg'" , "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Date: Wed, 22 Aug 2001 13:27:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Sip] RE: Encapsulating EPIC in UDPComp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, Wonderful! If we can standardize a decompressor with a hierarchical dictionary then we can support all of the proposed algorithms (EPIC, TCCB, Lempel-Ziv etc.). The overhead of this scheme is pretty low (3 bits per Huffman code), but I believe we can reduce it even further. Comments inline... Regards, Richard P > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, August 22, 2001 5:57 AM > To: Price, Richard; 'sip@ietf.org'; 'rohc@cdt.luth.se' > Cc: Jonathan Rosenberg > Subject: RE: Encapsulating EPIC in UDPComp > > > -----Original Message----- > > From: Price, Richard [mailto:richard.price@roke.co.uk] > > Sent: Friday, August 17, 2001 11:58 AM > > To: 'sip@ietf.org'; 'rohc@cdt.luth.se' > > Cc: 'Jonathan Rosenberg' > > Subject: Encapsulating EPIC in UDPComp > > > > > > Hi, > > > > Attached is a (rather detailed) posting on the overhead of > > encapsulating EPIC within UDPComp. The conclusion is that by adding > > Huffman codes to UDPComp, the protocol overhead can be made very > > low (just 5 bytes per message). > > > > Comments are welcome! > > Richard is exactly correct that the cost of a general purpose > decompressor like this is a hit in overhead. With purely static > codebook indices, the overhead is quite large as the results > below show. I agree totally that some kind of Huffman coding is > needed. I have been thinking about this, and I have a proposal > that is different from what Richard is proposing. On the contrary, your proposal is exactly how I hoped Huffman coding would be introduced! > My proposal would be to make the support for huffman coding > very general purpose, and based on a tree-like structure where > the codes are dependent on previous elements. Such a hierarchical > structure is needed, I think, to support the TCCB and EPIC > algorithms. Yes. In EPIC, the Huffman codes are local to each dictionary item. > TCCB is really about a two level encoding scheme - the top level > are the names of headers, and the second level are their values. > They add some optimizations that are SIP specific (such as > sending nothing when it can be assumed that the header hasn't > changed), which I would rather generalize in some efficient way. EPIC is similar to TCCB, except that we use n levels of encoding (where n is determined by the BNF description of SIP). > So, the idea is that when you write into the codebook, you > provide a bit which says whether this write takes place at the > current "level" in the hierarchy, or back at the top. Then, you > provide a bitstring that represents the huffman code for the token, > followed by the token. I would propose to take this one step further, and make the Huffman code indicate not only the location of the dictionary item, but also the type of token (READ, WRITE etc.). We could do this as follows: - Keep all of the existing token types (READ, WRITE, WRITE-REFERENCE) but prefix them with a large bit pattern, say "11111111". - Reserve the remaining prefix codes ("00000000" to "11111110") for the Huffman codes. - When a token is sent explicitly, attach a "shorthand" Huffman code that can be used to send the token in future. When we send the Huffman code, it implicitly specifies the token type (READ, WRITE etc.) as well as the location of the item to be read or written. The advantage of this approach is that schemes like EPIC and Lempel-Ziv only ever send Huffman codes when reading and writing entries in the dictionary. Once UDPComp has successfully transmitted these Huffman codes to the decompressor there is no need to send the tokens explicitly any more. This makes the overhead of UDPComp negligible (in fact, the only overhead is the reserved bit pattern "11111111" that we used to send the tokens explicitly in the first place). > It is the responsibility of the encoder to make sure that each code > is a valid prefix code. When the encoder sends a read command, it > contains a bit which indicates whether the read is from the top of > the tree or the current position, followed by the code. Agreed. However we should make this indicator flag part of the Huffman code as well, so that we don't have to send it explicitly every time. > > So, lets take a simple example. We want to compress something like: > > A: foo > B: bar > A: baz > > which is a sort-of sip message thing. We will use a TCCB-like > approach, where we encode the headers and values separately. Assume > two bits for the message type (READ or WRITE), and 8 bits per > character. We can do better using a separate codebook for text, > as Richard has proposed. > > for the first message, we send: > > WRITE, top=TRUE, "A:" code="0" (2 + 1 + 16 + 1 = 20 bits) > WRITE, top=FALSE, "foo" code="01" (2 + 1 + 24 + 2 = 29 bits) > WRITE, top=TRUE, "B:" code="11" (2 + 1 + 16 + 2 = 21 bits) > WRITE, top=FALSE, "bar" code="01" (2 + 1 + 24 + 2 = 29 bits) > READ, top=TRUE, code=0 (2 + 1 + 1 = 4 bits) > WRITE, top=FALSE, "baz" code="11" (2 + 1 + 24 + 2 = 29 bits) > > TOTAL: 132 > bits = 16.5 Bytes > > This is larger than the original (15 bytes), typical for the > case where there is no static or user specific codebook. > > This results in a codebook in the compressor/decompressor > that looks like: > > 0 "A:" 11 "B:" > | | > ----------- 01 "bar" > | | > 01 "foo" 11 "baz" > > Now, if the next message is: > > A: foo > B: bar > A: blip > > Its compressed as: > > READ, top=TRUE, code=0 (2 + 1 + 1 = 4 bits) > READ, top=FALSE, code=01 (2 + 1 + 2 = 5 bits) > READ, top=TRUE, code=11 (2 + 1 + 2 = 5 bits) > READ, top=FALSE, code=01 (2 + 1 + 2 = 5 bits) > READ, top=TRUE, code=0 (2 + 1 + 1 = 4 bits) > WRITE, top=FALSE, "blip" code=001 (2 + 1 + 32 + 3 = 38 bits) > > Total: 61 bits, 7.625 bytes > > Now, this is better, achieving slightly better than 2:1 over > a very small piece of data. Note that there is still a 3 bit overhead for each Huffman code, due to transmitting 2 bits for the token type and 1 bit to indicate when to go back to the top of the tree. If we make these part of the Huffman code then we can eliminate even this overhead. > > An interesting improvement is that I can specify a command which > says "READ code XX, and then read the next N symbols in the tree > if the number of children at each node is 1, in which case you > have no choice about the next symbol anyway". This is useful for > trees that are really deep, as opposed to wide. If you think about > it, this covers LZSS, which can be viewed as a "hierarchical" > codebook where each node is a single character, and the tree > is one where each node has only one child, the next character. > A similar enhancement might be to allow 1 Huffman code to indicate several consecutive choices of branches on the tree. This is especially useful when there is a single very likely route through the tree, as we can specify this route using only a single short Huffman code. > Comments? Hopefully this makes some sense... It made perfect sense to me, which is probably a bad sign... > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 10:57:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11964 for ; Wed, 22 Aug 2001 10:57:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13284; Wed, 22 Aug 2001 10:12:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13193 for ; Wed, 22 Aug 2001 10:12:00 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09150 for ; Wed, 22 Aug 2001 10:10:39 -0400 (EDT) Received: from lms001.lu.erisoft.se (lms001.lu.erisoft.se [150.132.144.19]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7MEBmv01215; Wed, 22 Aug 2001 16:11:48 +0200 (MEST) Received: by lms001.lu.erisoft.se id QAA00089; Wed, 22 Aug 2001 16:11:45 +0200 (MET DST) Message-ID: <3B83BD9F.FD696CE0@epl.ericsson.se> Date: Wed, 22 Aug 2001 16:11:43 +0200 From: Jan Christoffersson Organization: Ericsson Erisoft AB X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Price, Richard'" , "'sip@ietf.org'" , "'rohc@cdt.luth.se'" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: [rohc] RE: Encapsulating EPIC in UDPComp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi Jonathan, It seems to me that the Huffman coding you describe would be much more efficient than using the tokens which are given in the UDPComp-draft. However, I don't quite understand how they can be used for Lempel-Ziv compression. What puzzles me is that the dictionary, from the Lempel-Ziv point of view, is considered to be a byte array. This means that the same character can be present in many of the array elements. In the Huffman tree on the other hand, each character (or string) appears only once, right? But if you want to be able to read a string from the dictionary using the command ''READ code XX, and then read the next N symbols in the tree'', this implies that there must be a possibility for each symbol to appear more than once. But then again, can this be so in a Huffman tree? Can someone help me out here? I think I'm missing something. Regards, Jan Christoffersson Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Price, Richard [mailto:richard.price@roke.co.uk] > > Sent: Friday, August 17, 2001 11:58 AM > > To: 'sip@ietf.org'; 'rohc@cdt.luth.se' > > Cc: 'Jonathan Rosenberg' > > Subject: Encapsulating EPIC in UDPComp > > > > > > Hi, > > > > Attached is a (rather detailed) posting on the overhead of > > encapsulating EPIC within UDPComp. The conclusion is that by adding > > Huffman codes to UDPComp, the protocol overhead can be made very > > low (just 5 bytes per message). > > > > Comments are welcome! > > Richard is exactly correct that the cost of a general purpose decompressor > like this is a hit in overhead. With purely static codebook indices, the > overhead is quite large as the results below show. I agree totally that some > kind of Huffman coding is needed. I have been thinking about this, and I > have a proposal that is different from what Richard is proposing. > > My proposal would be to make the support for huffman coding very general > purpose, and based on a tree-like structure where the codes are dependent on > previous elements. Such a hierarchical structure is needed, I think, to > support the TCCB and EPIC algorithms. TCCB is really about a two level > encoding scheme - the top level are the names of headers, and the second > level are their values. They add some optimizations that are SIP specific > (such as sending nothing when it can be assumed that the header hasn't > changed), which I would rather generalize in some efficient way. > > So, the idea is that when you write into the codebook, you provide a bit > which says whether this write takes place at the current "level" in the > hierarchy, or back at the top. Then, you provide a bitstring that represents > the huffman code for the token, followed by the token. It is the > responsibility of the encoder to make sure that each code is a valid prefix > code. When the encoder sends a read command, it contains a bit which > indicates whether the read is from the top of the tree or the current > position, followed by the code. > > So, lets take a simple example. We want to compress something like: > > A: foo > B: bar > A: baz > > which is a sort-of sip message thing. We will use a TCCB-like approach, > where we encode the headers and values separately. Assume two bits for the > message type (READ or WRITE), and 8 bits per character. We can do better > using a separate codebook for text, as Richard has proposed. > > for the first message, we send: > > WRITE, top=TRUE, "A:" code="0" (2 + 1 + 16 + 1 = 20 bits) > WRITE, top=FALSE, "foo" code="01" (2 + 1 + 24 + 2 = 29 bits) > WRITE, top=TRUE, "B:" code="11" (2 + 1 + 16 + 2 = 21 bits) > WRITE, top=FALSE, "bar" code="01" (2 + 1 + 24 + 2 = 29 bits) > READ, top=TRUE, code=0 (2 + 1 + 1 = 4 bits) > WRITE, top=FALSE, "baz" code="11" (2 + 1 + 24 + 2 = 29 bits) > > TOTAL: 132 bits = 16.5 Bytes > > This is larger than the original (15 bytes), typical for the case where > there is no static or user specific codebook. > > This results in a codebook in the compressor/decompressor that looks like: > > 0 "A:" 11 "B:" > | | > ----------- 01 "bar" > | | > 01 "foo" 11 "baz" > > Now, if the next message is: > > A: foo > B: bar > A: blip > > Its compressed as: > > READ, top=TRUE, code=0 (2 + 1 + 1 = 4 bits) > READ, top=FALSE, code=01 (2 + 1 + 2 = 5 bits) > READ, top=TRUE, code=11 (2 + 1 + 2 = 5 bits) > READ, top=FALSE, code=01 (2 + 1 + 2 = 5 bits) > READ, top=TRUE, code=0 (2 + 1 + 1 = 4 bits) > WRITE, top=FALSE, "blip" code=001 (2 + 1 + 32 + 3 = 38 bits) > > Total: 61 bits, 7.625 bytes > > Now, this is better, achieving slightly better than 2:1 over a very small > piece of data. > > An interesting improvement is that I can specify a command which says "READ > code XX, and then read the next N symbols in the tree if the number of > children at each node is 1, in which case you have no choice about the next > symbol anyway". This is useful for trees that are really deep, as opposed to > wide. If you think about it, this covers LZSS, which can be viewed as a > "hierarchical" codebook where each node is a single character, and the tree > is one where each node has only one child, the next character. > > Comments? Hopefully this makes some sense... > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > --- > Mailing list for Robust Header Compression WG > Archive: http://www.cdt.luth.se/rohc/ _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 12:01:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14765 for ; Wed, 22 Aug 2001 12:01:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17094; Wed, 22 Aug 2001 11:40:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA17059 for ; Wed, 22 Aug 2001 11:40:06 -0400 (EDT) Received: from watermelon.icoe.att.com (mushroom.icoe.net [194.242.71.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13930 for ; Wed, 22 Aug 2001 11:38:46 -0400 (EDT) Received: from romeo-w2000.icoe.att.com (unknown [135.76.80.143]) by watermelon.icoe.att.com (Postfix) with ESMTP id 701B941A12; Wed, 22 Aug 2001 17:39:41 +0200 (MET DST) Message-Id: <5.1.0.14.0.20010822172430.0227d880@watermelon.icoe.att.com> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 22 Aug 2001 17:42:33 +0200 To: "Liu Zhigang.C (NRC/Dallas)" , , , From: Romeo Zwart Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for SIPcompression Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Please all note the highly relevant remark by Lawrence earlier on in this thread: LWC>> For GERAN at least, the HARD requirement is on the mid-call LWC>> Re-Invite sequence, NOT on the call set up. That's probably LWC>> true for UTRAN as well, but that's not my area of interest. At least in the GERAN environment, the real tough cases are associated with mid-call signalling. This example flow is clearly not from a mid-call scenario. Also the quoted BW (starting off with 9.6kbps) does not sound like the mid-call available bandwidth in GERAN to me - but then I have not been directly involved in this work, so I may be underestimating GERAN :-) LWC>> I have already sent a posting on my understanding of the LWC>> GERAN mid-call problem and the figures that seem to apply LWC>> there (and the reasons). Lawrence, was this a post to rohc or sip list or both? Thanks, Romeo At 09:20 PM 8/20/2001, Liu Zhigang.C (NRC/Dallas) wrote: >Hans, > >Attached is a message sequence for mobile-originated call >scenario in 3GPP (sorry about the size, ~6K). It was based >on 3GPP TS 24.228 (v0.4.0 March/2001): "Signaling flows for >the IP multimedia call control based on SIP and SDP". > >It was generated back in April when we started the test. >Recently, there is a new version (v1.2.0 July/2001) of >TS 24.228 released. So, some updates might be needed. >But the basic sequence is still the same. > >If time allowed, we probably need another sequence for mobile- >terminated call, which can be found in the same document. > >BR, >Zhigang > >PS. I noticed that the lines in the files are terminated by LF >instead of CRLF (as it should be). I guess it was messed up >during the transfer between Windows and Linux. > > > -----Original Message----- > > From: ext Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] > > Sent: August 20, 2001 12:47 PM > > To: Liu Zhigang.C (NRC/Dallas); sip@ietf.org; rohc@cdt.luth.se > > Cc: richard.price@roke.co.uk; Ishita.Majumdar@motorola.com > > Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for > > SIPcompression > > > > > > Hi Zhigang, > > > > I read Ishita's mail too quickly. Thus, we currently only > > have one message sequnce, section 3.1.1 Successful Simple SIP > > to SIP, from draft-ietf-sip-call-flows-05.txt. > > If you could provide more sequences it would be good. > > > > BR > > /Hans H > > > > > -----Original Message----- > > > From: Liu Zhigang.C (NRC/Dallas) [mailto:zhigang.c.liu@nokia.com] > > > Sent: den 20 augusti 2001 19:02 > > > To: Hans.Hannu@epl.ericsson.se; 'Lawrence Conroy'; sip@ietf.org; > > > rohc@cdt.luth.se > > > Cc: richard.price@roke.co.uk; Le Khiem (NRC/Dallas) > > > Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for > > > SIPcompression > > > > > > > > > Hi Hans, > > > > > > Are the message sequences you get from Richard and Ishita > > > based on draft-ietf-sip-call-flows-05.txt or 3GPP TS > > > 24.228? Were they sent to the mailing list? > > > > > > BR, > > > Zhigang > > > > > > > -----Original Message----- > > > > From: ext Hans Hannu [mailto:Hans.Hannu@epl.ericsson.se] > > > > Sent: August 20, 2001 11:46 AM > > > > To: 'Lawrence Conroy'; sip@ietf.org; rohc@cdt.luth.se > > > > Cc: richard.price@roke.co.uk; Liu Zhigang.C (NRC/Dallas); Le Khiem > > > > (NRC/Dallas) > > > > Subject: RE: [Sip] RE: [rohc] Reduced processing overhead for > > > > SIPcompression > > > > > > > > > > > > Hi, > > > > > > > > I like the idea of having some defined scenarios to be able > > > > to compare the > > > > scheme against and those scenarios could be included in the > > > > requirements > > > > document, but perhaps not under the requirements section, but > > > > under the > > > > "assumptions" section. > > > > > > > > We have already some message sequences (thanks to Richard and > > > > Ishita) that > > > > we could use. What we need to do now is just find out some > > > > representative > > > > channel bitrates to run these against. Maybe someone could > > > > provide some > > > > channel bitrates? > > > > > > > > Are there other "message exchange sequences" that someone > > > > thinks are more > > > > representative than those already used? > > > > > > > > BR > > > > /Hans H > > > > > > > > > >Hi Hans, > > > > > > > > > > > >Since the SIP Call set up latency is one of the main (if not > > > > > the main) > > > > > >problem we want to solve with signaling compression, I > > > > > propose we add a > > > > > >requirement to that effect: > > > > > > > > > > > >The compression scheme MUST be such that when applied to > > > > > SIP, the call > > > > > >set up latency is less than X seconds, for a > > > representative set of > > > > > >scenarios to be defined. Scenarios specify the messages > > > > > exchanged, their > > > > > >contents, as well as the channel bit rates. > > > > > > > > > > > >We need to agree on X and the scenarios, but I believe this > > > > > requirement > > > > > >is useful, because compression ratio alone does not > > > > > adequately capture > > > > > >the problem of call set up latency. Scenarios can be > > > based on those > > > > > >typically envisioned in cellular cases like 3GPP. > > > > > > > > > > > >Khiem > > > > > > > > > > > To which I reply: > > > > > Hi Folks, > > > > > There is a GERAN meeting at the end of the month, and I > > > > will canvas > > > > > to see if there is a HARD limit such as that proposed as a > > > > > requirement. > > > > > > > > > > However... > > > > > I think that the assumption that the main goal of SIP Comp is > > > > > to reduce > > > > > (or, as described above, =>LIMIT<= ) the call set up time is > > > > > not obvious > > > > > (to me, at least) and I'm not yet happy to have it > > included in the > > > > > requirements document as proposed. > > > > > > > > > > For GERAN at least, the HARD requirement is on the mid-call > > > > Re-Invite > > > > > sequence, NOT on the call set up. That's probably true for > > > > > UTRAN as well, > > > > > but that's not my area of interest. > > > > > > > > > > I have already sent a posting on my understanding of the > > > > > GERAN mid-call > > > > > problem and the figures that seem to apply there (and the > > > reasons). > > > > > > > > > > Of course one benefit of SIP Comp is that we reduce the > > > transmission > > > > > time for messages sent during call set up for latency > > > > reasons, and so > > > > > we may avoid too many re-transmissions of SIP messages. > > > > > However, I don't > > > > > see how this is a HARD requirement and would be interested in > > > > > understanding > > > > > the logic here. > > > > > > > > > > Do we have a specific limit (like the DCS one that is, I > > > > > believe, regulated > > > > > by the FCC)? > > > > > > > > > > BR, > > > > > L. > > > > > -- > > > > > lwc@roke.co.uk: +44 1794 833666::: > > > > > > > > > > > > > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 12:22:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15480 for ; Wed, 22 Aug 2001 12:22:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18331; Wed, 22 Aug 2001 12:01:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18301 for ; Wed, 22 Aug 2001 12:01:02 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14694 for ; Wed, 22 Aug 2001 11:59:41 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 17:00:29 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9E2D@RSYS002A> From: "Price, Richard" To: "'Jan Christoffersson'" , Jonathan Rosenberg Cc: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Date: Wed, 22 Aug 2001 17:00:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Sip] RE: [rohc] RE: Encapsulating EPIC in UDPComp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, I believe the term "tree structure" for the new UDPComp dictionary is the source of the confusion - it's nothing to do with a "Huffman tree" per se. In fact, each dictionary item in the tree has its own set of codes (generated by Huffman or some other algorithm). The reason for making the dictionary tree-like is so that we can capture the hierarchical nature of SIP. For example a SIP message can be divided up into headers, and each header can be further subdivided into different values. For the "tree-based" dictionary we can change the Huffman codes we send based on the exact part of the SIP message we are currently compressing. However we can also support Lempel-Ziv just by ignoring the tree structure and making the dictionary flat. Hope this helps! Richard P > -----Original Message----- > From: Jan Christoffersson [mailto:Jan.Christoffersson@epl.ericsson.se] > Sent: Wednesday, August 22, 2001 3:12 PM > To: Jonathan Rosenberg > Cc: Price, Richard; 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: Re: [rohc] RE: Encapsulating EPIC in UDPComp > > > Hi Jonathan, > It seems to me that the Huffman coding you describe would be > much more efficient > than using the tokens which are given in the UDPComp-draft. > However, I don't quite understand how they can be used for Lempel-Ziv > compression. What puzzles me is that the dictionary, from the > Lempel-Ziv point > of view, is considered to be a byte array. This means that > the same character > can be present in many of the array elements. In the Huffman > tree on the other > hand, each character (or string) appears only once, right? > But if you want to be > able to read a string from the dictionary using the command > ''READ code XX, and > then read the next N symbols in the tree'', this implies that > there must be a > possibility for each symbol to appear more than once. But > then again, can this > be so in a Huffman tree? > Can someone help me out here? I think I'm missing something. > Regards, > Jan Christoffersson > > Jonathan Rosenberg wrote: > > > > > > > > -----Original Message----- > > > From: Price, Richard [mailto:richard.price@roke.co.uk] > > > Sent: Friday, August 17, 2001 11:58 AM > > > To: 'sip@ietf.org'; 'rohc@cdt.luth.se' > > > Cc: 'Jonathan Rosenberg' > > > Subject: Encapsulating EPIC in UDPComp > > > > > > > > > Hi, > > > > > > Attached is a (rather detailed) posting on the overhead of > > > encapsulating EPIC within UDPComp. The conclusion is that > by adding > > > Huffman codes to UDPComp, the protocol overhead can be made very > > > low (just 5 bytes per message). > > > > > > Comments are welcome! > > > > Richard is exactly correct that the cost of a general > purpose decompressor > > like this is a hit in overhead. With purely static codebook > indices, the > > overhead is quite large as the results below show. I agree > totally that some > > kind of Huffman coding is needed. I have been thinking > about this, and I > > have a proposal that is different from what Richard is proposing. > > > > My proposal would be to make the support for huffman coding > very general > > purpose, and based on a tree-like structure where the codes > are dependent on > > previous elements. Such a hierarchical structure is needed, > I think, to > > support the TCCB and EPIC algorithms. TCCB is really about > a two level > > encoding scheme - the top level are the names of headers, > and the second > > level are their values. They add some optimizations that > are SIP specific > > (such as sending nothing when it can be assumed that the > header hasn't > > changed), which I would rather generalize in some efficient way. > > > > So, the idea is that when you write into the codebook, you > provide a bit > > which says whether this write takes place at the current > "level" in the > > hierarchy, or back at the top. Then, you provide a > bitstring that represents > > the huffman code for the token, followed by the token. It is the > > responsibility of the encoder to make sure that each code > is a valid prefix > > code. When the encoder sends a read command, it contains a bit which > > indicates whether the read is from the top of the tree or > the current > > position, followed by the code. > > > > So, lets take a simple example. We want to compress something like: > > > > A: foo > > B: bar > > A: baz > > > > which is a sort-of sip message thing. We will use a > TCCB-like approach, > > where we encode the headers and values separately. Assume > two bits for the > > message type (READ or WRITE), and 8 bits per character. We > can do better > > using a separate codebook for text, as Richard has proposed. > > > > for the first message, we send: > > > > WRITE, top=TRUE, "A:" code="0" (2 + 1 + 16 + 1 = 20 bits) > > WRITE, top=FALSE, "foo" code="01" (2 + 1 + 24 + 2 = 29 bits) > > WRITE, top=TRUE, "B:" code="11" (2 + 1 + 16 + 2 = 21 bits) > > WRITE, top=FALSE, "bar" code="01" (2 + 1 + 24 + 2 = 29 bits) > > READ, top=TRUE, code=0 (2 + 1 + 1 = 4 bits) > > WRITE, top=FALSE, "baz" code="11" (2 + 1 + 24 + 2 = 29 bits) > > > > TOTAL: 132 > bits = 16.5 Bytes > > > > This is larger than the original (15 bytes), typical for > the case where > > there is no static or user specific codebook. > > > > This results in a codebook in the compressor/decompressor > that looks like: > > > > 0 "A:" 11 "B:" > > | | > > ----------- 01 "bar" > > | | > > 01 "foo" 11 "baz" > > > > Now, if the next message is: > > > > A: foo > > B: bar > > A: blip > > > > Its compressed as: > > > > READ, top=TRUE, code=0 (2 + 1 + 1 = 4 bits) > > READ, top=FALSE, code=01 (2 + 1 + 2 = 5 bits) > > READ, top=TRUE, code=11 (2 + 1 + 2 = 5 bits) > > READ, top=FALSE, code=01 (2 + 1 + 2 = 5 bits) > > READ, top=TRUE, code=0 (2 + 1 + 1 = 4 bits) > > WRITE, top=FALSE, "blip" code=001 (2 + 1 + 32 + 3 = 38 bits) > > > > Total: 61 bits, 7.625 bytes > > > > Now, this is better, achieving slightly better than 2:1 > over a very small > > piece of data. > > > > An interesting improvement is that I can specify a command > which says "READ > > code XX, and then read the next N symbols in the tree if > the number of > > children at each node is 1, in which case you have no > choice about the next > > symbol anyway". This is useful for trees that are really > deep, as opposed to > > wide. If you think about it, this covers LZSS, which can be > viewed as a > > "hierarchical" codebook where each node is a single > character, and the tree > > is one where each node has only one child, the next character. > > > > Comments? Hopefully this makes some sense... > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > --- > > Mailing list for Robust Header Compression WG > > Archive: http://www.cdt.luth.se/rohc/ > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 12:33:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15823 for ; Wed, 22 Aug 2001 12:33:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19162; Wed, 22 Aug 2001 12:15:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19132 for ; Wed, 22 Aug 2001 12:15:32 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15205 for ; Wed, 22 Aug 2001 12:14:10 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MGDwrN016176; Wed, 22 Aug 2001 12:13:58 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 12:14:45 -0400 Message-ID: From: Jonathan Rosenberg To: "'Jan Christoffersson'" Cc: "'Price, Richard'" , "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Date: Wed, 22 Aug 2001 12:14:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] RE: [rohc] RE: Encapsulating EPIC in UDPComp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Jan Christoffersson [mailto:Jan.Christoffersson@epl.ericsson.se] > Sent: Wednesday, August 22, 2001 10:12 AM > To: Jonathan Rosenberg > Cc: 'Price, Richard'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: Re: [rohc] RE: Encapsulating EPIC in UDPComp > > > Hi Jonathan, > It seems to me that the Huffman coding you describe would be > much more efficient > than using the tokens which are given in the UDPComp-draft. Yes. There is no reason to keep the fixed length tokens in that draft. > However, I don't quite understand how they can be used for Lempel-Ziv > compression. What puzzles me is that the dictionary, from the > Lempel-Ziv point > of view, is considered to be a byte array. This means that > the same character > can be present in many of the array elements. In the Huffman > tree on the other > hand, each character (or string) appears only once, right? No, thats not true. I think things are confused because there are really two trees here. One is the tree that represents the Huffman code itself (since a Huffman table can be represented as traversing a tree with bits at each vertex). THe other is the tree of contexts, which basically tell you which table is being used. Let me explain. The Huffman codes effectively encode string values (Richard has proposed they encode more than that, which I agree with, but thats an orthogonal issue. Lets keep it simple for explanatory purposes). Each entry in the table contains an arbitrary string, which is the string to be outputted as part of the decompressed message. Consider a simple table: Code value --------------------------------------- 0 jdrosen@dynamicsoft.com 10 INVITE 111 From: 1100 Via: Call this "table 1". I can have many such tables, each of which contains a Huffman code for a series of strings. The idea is that you start compression/decompression with a "root table". The output of the Huffman code not only specifies the string to output into the decompressed message, but also basically specifies a pointer to the "next table". So, really, if the above table were the root table, it should really look like: Code value Next table ---------------------------------------------------- 0 jdrosen@dynamicsoft.com table 2 10 INVITE table 3 111 From: table 4 1100 Via: table 5 Rather than explicitly specifying the next table by a table number, I do it with a bit. A value of 0 indicates that you use the root table. A value of 1 means you use a table which is unique to the sequence of huffman codes that have been traversed from the root till now. Thus, determination of which table to use is effectively modeled as a tree as well: Please view in a fixed-width font such as Courier. start | | | .......................... . . . . . Root table . . / . .......................... | | | | 0| 10| 111| 1100| ......... ....... ....... .............. . Table . .Table. .Table. . Table . . /0 . ./10 . ./111 . ./1100 . . . . . . . . . ......... ....... ....... .............. | | 1 | 0| | | | | ........ ....... . Table. .Table. ./1100/1 ./1100/0 . . . . ........ ....... So, we start at the root (table /). If the code transmitted is 1100, we output the string "Via:" to the decompressed message, and then use the table named /1100 (i.e., 1100 is like a subdirectory off the root). Now, lets assume this table has two entries: Code String ---------------- 0 SIP/2.0/UDP 1 SIP/2.0/TCP The next thing sent by the compressor is "use the current table, and read index 0". This outputs SIP/2.0/UDP to the decompressed message, and sets the table to /1100/0. The process continues. Now, what is interesting is when you have Huffman tables with only one entry. Consider table /1100/1. Lets say its like this: Code String ---------------- 00 CRLF CSeq: So, lets say we started from the root, and the encoder sent 1100, which resulted in outputing "Via:". Then, it sends a command which means "output the string at index 1 of the current table. Then, if the next table has only one entry, output that, and then if the next has one entry, output that, and so on, until you come to a table with more than one entry". So, the decompressor reads entry 1 from table /1100, and outputs "SIP/2.0/TCP". The next table, /1100/1 has only one entry, so that is output as well, resulting in "CRLF CSeq:" being written into the decompressed message. This is very, very useful as a primitive, since it totally reduces the overhead to zero. If you extend this command a little bit, and allow the encoder to say "output the next N things assuming there is only one entry in each table", you can implement LZSS at the encoder with this primitive command, without the decoder even having to know what LZSS stands for, or how it works. You do need an efficient way to tell the encoder to construct a series of tables in sequence, though. Doing that is easy as well. Hope that clarifies. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 12:33:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15835 for ; Wed, 22 Aug 2001 12:33:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19417; Wed, 22 Aug 2001 12:19:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19393 for ; Wed, 22 Aug 2001 12:19:30 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15329 for ; Wed, 22 Aug 2001 12:18:10 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MGHtrN016241; Wed, 22 Aug 2001 12:17:55 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 12:18:42 -0400 Message-ID: From: Jonathan Rosenberg To: "'Price, Richard'" , "'Jan Christoffersson'" Cc: "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Date: Wed, 22 Aug 2001 12:18:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: [rohc] RE: Encapsulating EPIC in UDPComp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Wednesday, August 22, 2001 12:00 PM > To: 'Jan Christoffersson'; Jonathan Rosenberg > Cc: 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: RE: [rohc] RE: Encapsulating EPIC in UDPComp > > > Hi, > > I believe the term "tree structure" for the new UDPComp dictionary is > the source of the confusion - it's nothing to do with a "Huffman tree" > per se. In fact, each dictionary item in the tree has its own set of > codes (generated by Huffman or some other algorithm). Exactly correct! I just typed an email and sent it explaining this in more detail. > > The reason for making the dictionary tree-like is so that we can > capture the hierarchical nature of SIP. For example a SIP message can > be divided up into headers, and each header can be further subdivided > into different values. For the "tree-based" dictionary we can change > the Huffman codes we send based on the exact part of the SIP message > we are currently compressing. However we can also support Lempel-Ziv > just by ignoring the tree structure and making the dictionary flat. Right! Note that this is not SIP specific. All protocols generally have a structure where the previous thing restricts what is coming next. Some of them have deep hierarchies, some are flat, but the point is, they are all trees. By defining a general purpose "tree context construction and access" protocol, we can cover a lot of protocols and a lot of algorithms. I have argued that this tree structure covers LZW, LZSS, TCCB, and EPIC, which is a pretty good set of coverage... -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 13:05:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16879 for ; Wed, 22 Aug 2001 13:05:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20892; Wed, 22 Aug 2001 12:51:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20860 for ; Wed, 22 Aug 2001 12:51:44 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16287 for ; Wed, 22 Aug 2001 12:50:25 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MGoJrN016521; Wed, 22 Aug 2001 12:50:19 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 12:51:06 -0400 Message-ID: From: Jonathan Rosenberg To: "'Price, Richard'" , Jonathan Rosenberg , "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Date: Wed, 22 Aug 2001 12:51:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Encapsulating EPIC in UDPComp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Price, Richard [mailto:richard.price@roke.co.uk] > Sent: Wednesday, August 22, 2001 8:27 AM > To: 'Jonathan Rosenberg'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > Subject: RE: Encapsulating EPIC in UDPComp > > > Richard is exactly correct that the cost of a general purpose > > decompressor like this is a hit in overhead. With purely static > > codebook indices, the overhead is quite large as the results > > below show. I agree totally that some kind of Huffman coding is > > needed. I have been thinking about this, and I have a proposal > > that is different from what Richard is proposing. > > On the contrary, your proposal is exactly how I hoped Huffman > coding would be introduced! Great! I had thought you were proposing that a pre-agreed upon Huffman code be referenced during startup time, or that it was downloaded at startup time. The proposal here is that the Huffman codes are constructed as you go, since you need that to support dynamic codebooks, which I think we all agree is needed. Of course, one can easily support downloading of the codes at start time if a primitive is defined which is "WRITE this, but don't output anything into a decompressed message". > > > My proposal would be to make the support for huffman coding > > very general purpose, and based on a tree-like structure where > > the codes are dependent on previous elements. Such a hierarchical > > structure is needed, I think, to support the TCCB and EPIC > > algorithms. > > Yes. In EPIC, the Huffman codes are local to each dictionary item. I think that you will need such a thing in general to achieve really good compression. > > So, the idea is that when you write into the codebook, you > > provide a bit which says whether this write takes place at the > > current "level" in the hierarchy, or back at the top. Then, you > > provide a bitstring that represents the huffman code for the token, > > followed by the token. > > I would propose to take this one step further, and make the Huffman > code indicate not only the location of the dictionary item, but also > the type of token (READ, WRITE etc.). Excellent idea! Our goal should ultimately be that the encoder output is always a series of huffman codes, with some extra stuff to write the strings into the codebooks that are not already there. Some more thoughts on that below. > We could do this as follows: > > - Keep all of the existing token types (READ, WRITE, > WRITE-REFERENCE) > but prefix them with a large bit pattern, say "11111111". > > - Reserve the remaining prefix codes ("00000000" to "11111110") for > the Huffman codes. > > - When a token is sent explicitly, attach a "shorthand" Huffman code > that can be used to send the token in future. > > When we send the Huffman code, it implicitly specifies the token type > (READ, WRITE etc.) as well as the location of the item to be read or > written. I agree with that, but I'm not sure that you want to use these large bit patterns to represent the initial commands. The result will be that initial WRITEs and READs are really, really large. You only need these large codes when there are lots of Huffman codes in any particular table. That won't always be the case at all. One way to solve this is to have a really nice way to dynamically construct the Huffman codes. Lets say you have a Huffman code represented by some tree. Adding a new string can be done in only one way. You take an existing vertex somewhere in the tree, and remove the subtree (if present). Add two new branches below that vertex. Add the subtree to the right branch, and place your new string to the the other. Here's an example Huffman tree. Assume 0 is left, 1 is right: /\ /\ A B C THis corresponds to: 00 B 01 C 1 A Now, we wish to add D. TO do that, we send a command that reads like: "WRITE into the table, spltting at 00, and the value is D". So, the decoder finds the vertex 00. TO do this, it starts at the root, goes left, and then left again. This is the vertex which currently encodes B. It removes B, adds two branches, places B on the right, and the new element on the left: /\ /\ A /\ C D B Now, this table looks like: 1 A 01 C 001 B 000 D So, the idea is that we always start with a default table that has two codes in it, which says "WRITE" in one of the two places: initial table: Code output ------------------- 0 WRITE the string which follows by splitting the indicated vertex in the curren table 1 WRITE the string which follows into the root table (i.e, change contexts) by splitting the indicated vertex This code would need to be followed by the identity of the vertex, and then the text itself. This way, you start off with very efficient codes that write into the table. As the table gets larger, you use the efficient codes for the common strings, and the code for writing into the table gets longer. Rather than simply enclosing the text as a string, we should either Huffman encode that with a standardized table, or else take all of the text in a message, put them together, compress it as an independent blob, and then send that together. > > The advantage of this approach is that schemes like EPIC and > Lempel-Ziv > only ever send Huffman codes when reading and writing entries in the > dictionary. Once UDPComp has successfully transmitted these > Huffman codes > to the decompressor there is no need to send the tokens explicitly any > more. This makes the overhead of UDPComp negligible (in fact, the only > overhead is the reserved bit pattern "11111111" that we used to send > the tokens explicitly in the first place). Right. My proposal above reduces that as well, since this overhead is not once per message, but once per new token. > > > It is the responsibility of the encoder to make sure that each code > > is a valid prefix code. When the encoder sends a read command, it > > contains a bit which indicates whether the read is from the top of > > the tree or the current position, followed by the code. > > Agreed. However we should make this indicator flag part of the Huffman > code as well, so that we don't have to send it explicitly every time. Right, that is the proposal above. > > An interesting improvement is that I can specify a command which > > says "READ code XX, and then read the next N symbols in the tree > > if the number of children at each node is 1, in which case you > > have no choice about the next symbol anyway". This is useful for > > trees that are really deep, as opposed to wide. If you think about > > it, this covers LZSS, which can be viewed as a "hierarchical" > > codebook where each node is a single character, and the tree > > is one where each node has only one child, the next character. > > > > A similar enhancement might be to allow 1 Huffman code to indicate > several consecutive choices of branches on the tree. This is > especially useful when there is a single very likely route through > the tree, as we can specify this route using only a single short > Huffman code. Hmm, interesting idea. You need to be careful about this, though, since management of this tangle of tables can be complex. It would be really nice to maintain a simple structure. I think the way to do what you are proposing is to define a command which is "WRITE into the current table, splitting the specified vertex. The element to write is found by reading from here with the following huffman codes: XXX, and then the next table is the existing one at the end of the read". This turns the tree of tables into a more general purpose digraph, which is probably a really good idea. It can save a lot of overhead in the management of the table. Protocols, like SIP, have many "paths" through the message which can arrive at a common piece of data (for example, the SIP URL). This way, the encoding for the SIP URL appears only once in memory, rather than based on each path to get to it. Maybe time to start writing all of this up in an updated I-D for UDPComp, since its probably hard to get it from these terse emails.... -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 13:50:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18247 for ; Wed, 22 Aug 2001 13:50:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22467; Wed, 22 Aug 2001 13:40:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22435 for ; Wed, 22 Aug 2001 13:40:17 -0400 (EDT) Received: from maliwan.psu.ac.th (maliwan.psu.ac.th [192.100.77.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17980 for ; Wed, 22 Aug 2001 13:38:56 -0400 (EDT) Received: from oossy ([172.30.2.69]) by maliwan.psu.ac.th (8.11.4/8.11.4) with SMTP id f7MHeAI03959 for ; Thu, 23 Aug 2001 00:40:10 +0700 (ICT) Message-ID: <000c01c12b32$4731a6c0$45021eac@oossy> From: "Jatupong Arun" To: Date: Thu, 23 Aug 2001 00:45:48 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C12B6C.F36D6660" 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 Subject: [Sip] How compute response Http digest follow by standard rfc2617 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C12B6C.F36D6660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How i can get response http digest follow by standard rfc2617.What = parameter must to know before compute.I also don't clear md5 algorithm. Thanks a lot oossy=20 ------=_NextPart_000_0009_01C12B6C.F36D6660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
How i can get response http digest = follow by=20 standard rfc2617.What parameter must to know before compute.I also don't = clear=20 md5 algorithm.
 
Thanks a lot
oossy 
------=_NextPart_000_0009_01C12B6C.F36D6660-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 14:40:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19944 for ; Wed, 22 Aug 2001 14:40:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24983; Wed, 22 Aug 2001 14:32:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24954 for ; Wed, 22 Aug 2001 14:32:46 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19575 for ; Wed, 22 Aug 2001 14:31:27 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MIVQrN017581; Wed, 22 Aug 2001 14:31:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 14:32:13 -0400 Message-ID: From: Jonathan Rosenberg To: "'Munira Sharmin'" , "sip+AEA-ietf.org" Date: Wed, 22 Aug 2001 14:32:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-7" Subject: [Sip] RE: +AFs-Sip+AF0- SIP bis 04 questions Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org +AD4- -----Original Message----- +AD4- From: Munira Sharmin +AFs-mailto:msharmin+AEA-worldnet.att.net+AF0- +AD4- Sent: Tuesday, August 14, 2001 12:11 AM +AD4- To: sip+AEA-ietf.org +AD4- Subject: +AFs-Sip+AF0- SIP bis 04 questions +AD4- +AD4- +AD4- 1. Section 15.4, 1st paragraph: +ACI-A UA MUST NOT initiate a +AD4- new regular +AD4- transaction while a regular transaction is in progress+ACI-. What +AD4- does 'regular +AD4- transaction' mean here? Regular transactions are defined in the terminology section. The definition provided there is: Regular Transaction: A regular transaction is any transaction with a method other than INVITE, ACK,or CANCEL. +AD4- +AD4- 2. Section 15.4, 3rd paragraph: +ACI-The To field of CANCEL +AD4- requests always +AD4- contain exactly the same value as the request it is +AD4- cancelling+ACI-. Does it +AD4- mean that the CANCEL request will not have a tag if a previous INVITE +AD4- request that it is canceling does not have a tag even if a provisional +AD4- response had a tag in it? Yes. That is what +ACI-containing the exact same value as the request it is cancelling+ACI- means. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen+AEA-dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 14:41:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19977 for ; Wed, 22 Aug 2001 14:41:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24247; Wed, 22 Aug 2001 14:22:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24155 for ; Wed, 22 Aug 2001 14:21:57 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19127 for ; Wed, 22 Aug 2001 14:20:38 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MIKarN017435; Wed, 22 Aug 2001 14:20:36 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 14:21:23 -0400 Message-ID: From: Jonathan Rosenberg To: "'Miguel A. Garcia'" , sip@ietf.org, Jonathan Rosenberg Cc: "'confctrl@isi.edu'" Date: Wed, 22 Aug 2001 14:21:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Sip] RE: new SDP in RFC 2543bis? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: Friday, August 17, 2001 5:52 AM > To: sip@ietf.org; jdrosen@dynamicsoft.com > Subject: new SDP in RFC 2543bis? > > > Hi: > > I remember that in the MMUSIC meeting in London, Jonathan > mentioned that RFC 2543bis depends on the new SDP draft. > However, RFC 2543bis-04 references RFC 2327 (classic SDP). Is > this going to be fixed in new versions of RFC 2543bis? Or am > I missing something? I don't think anything in the *current* SDP usage is dependent on SDP-bis. The whole SDP/SIP issue was discussed at IETF, and the following was the consensus of the meeting: 1. Appendix B of bis will be removed from bis. It will instead become a standalone draft, done through mmusic. 2. This draft will not be sip specific, but rather define an offer/answer paradigm with SDP. 3. The draft will only reference rfc2327, not sdp-bis. Thats because SIP-bis depends on this draft, and if this draft depending on sdp-bis, SIP-bis could not go to RFC until sdp-bis did. Since sdp-bis is going out as draft standard, the bar is very high for that and it will likely take a very long time until an rfc number is assigned (look at how long RTP has taken - YEARS since it was started, and still not done). The only real issue is the a=inactive attribute. My easy fix for that is for the offer/answer draft to reference rfc3108 (ATM SDP) which defines this for the first time. 4. SIP-bis will reference this new draft, explaining how to encapsulate the offer/answer model into sip messages. The result is a nice generalization of a usage of sdp that is appropriate for other protocols too, and a needed shortening of the sip-bis spec. So, if anyone objects to this plan, speak now. I will be ripping this appendix out of bis in about two weeks and resubmitting it as standalone at that time. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 14:48:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20204 for ; Wed, 22 Aug 2001 14:48:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24701; Wed, 22 Aug 2001 14:30:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA24660 for ; Wed, 22 Aug 2001 14:30:08 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19402 for ; Wed, 22 Aug 2001 14:28:48 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MISkrN017535; Wed, 22 Aug 2001 14:28:46 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 14:29:33 -0400 Message-ID: From: Jonathan Rosenberg To: "'Colin Perkins'" , Gonzalo Camarillo Cc: Jonathan Rosenberg , sip@ietf.org, mmusic Subject: RE: [Sip] Re: SDP hold Date: Wed, 22 Aug 2001 14:29:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org So, here is an important question on the inactive attribute. If a stream is inactive, is RTCP sent? I think it probably should, actually... RTCP helps to keep state alive in various places, and this session is still alive, just suspended. THoughts? -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Colin Perkins [mailto:csp@purple.cs.ucl.ac.uk] > Sent: Wednesday, August 15, 2001 5:30 AM > To: Gonzalo Camarillo > Cc: Jonathan Rosenberg; sip@ietf.org; mmusic > Subject: Re: [Sip] Re: SDP hold > > >a=inactive > > This specifies that the tools should be started in inactive > > mode. This is necessary for interactive conferences > where users can > >put other users on hold. No media is sent over an inactive > media stream. > >It can be either a session or media attribute, and is not > dependent on > >charset. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 16:00:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22505 for ; Wed, 22 Aug 2001 16:00:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29095; Wed, 22 Aug 2001 15:47:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29066 for ; Wed, 22 Aug 2001 15:47:11 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22129 for ; Wed, 22 Aug 2001 15:45:51 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MJjhrN018499; Wed, 22 Aug 2001 15:45:45 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 15:46:31 -0400 Message-ID: From: Jonathan Rosenberg To: "'Fairlie-Cuninghame, Robert'" , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] bis-04 available! Date: Wed, 22 Aug 2001 15:46:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Good catch. Fixed. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Friday, August 10, 2001 1:43 PM > To: 'Jonathan Rosenberg'; sip@ietf.org > Subject: RE: [Sip] bis-04 available! > > > Also Jonathan, > > The maddr header is still listed as mandatory for > Record-Route in Table 2. > > Regards, > > Robert. > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 16:06:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22697 for ; Wed, 22 Aug 2001 16:06:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28041; Wed, 22 Aug 2001 15:30:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA27987 for ; Wed, 22 Aug 2001 15:30:34 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21549 for ; Wed, 22 Aug 2001 15:29:13 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MJSdrN018256; Wed, 22 Aug 2001 15:28:39 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 15:29:27 -0400 Message-ID: From: Jonathan Rosenberg To: "'John.Hearty@Level3.com'" , sip@ietf.org Subject: RE: [SIP] Killing hung media streams Date: Wed, 22 Aug 2001 15:29:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com] > Sent: Friday, August 10, 2001 4:52 PM > To: sip@ietf.org > Subject: RE: [SIP] Killing hung media streams > > > > Sorry to dredge up this thread again, but in reading through > it, I didn't > get the impression there was consensus on what to do, and > didn't notice > anything in bis-04 that addressed it. Getting back to the > original issue > that prompted it (though many varied needs were voiced), say > we have a UA > that gets media it is not expecting as it has no > corresponding session. The > early consensus seemed to be to send ICMPs. That has little to do with SIP, and will just happen in the OS since no one is listening on that port anyway. > > The desire of that UA is to get the sender to stop the > stream. This is my > main concern with this thread. The sender of the stream may desire to > attempt to re-establish the session, or may desire to kill > the session it > believes was active and associated with the stream. This > seems to be an > implementation specific decision, though communicating that > desire may be > something that is a protocol issue. What should the UA > sending the media do > when it gets ICMPs in either case? My recommendation is this. If a UA is in a call, and begins getting ICMP errors on a media stream, and wishes to continue with the call, it SHOULD send a re-INVITE on that leg. As an orthogonal issue, if a UAC receives a 481 to a mid-call re-INVITE, it SHOULD tear down the call by sending a BYE. For your case, the re-INVITE will trigger a 481 since the call is not known and not wanted at this server (the Tag indicates its a re-invite), and thus the call is torn down and the media stops. > > In my envirenment, I could live with either action taken by > the UA, but > need some action(s) standardized, rather than the current > inaction. In the > first case (re-Invite), I would establish a new session which > would likely > be to a different media address/port, and expect the UAC to > stop sending to > the first port. In the second case, I would send a 481 if a BYE for a > non-existent session was received. Well, as I mentioned above, the call is not likely to be established in the general case (although it can if recovery is what is desired). > > Note that there was discussion in the thread of sending a > 481 response to a > re-Invite. At least in my environment, we would send the > ICMPs because we > have no session associated with the received stream. Hence > we may not have > state for that session, and would recognize the Invite as a > new session and > not a re-Invite, so could not be expected to send a 481. Tag in the To field = re-INVITE. The process is described in section 15.5 of bis-04 (although it says nothing yet about sending a BYE after getting the 481. Thats the proposal.) -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 16:30:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23270 for ; Wed, 22 Aug 2001 16:30:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29790; Wed, 22 Aug 2001 16:10:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29758 for ; Wed, 22 Aug 2001 16:10:02 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22816 for ; Wed, 22 Aug 2001 16:08:42 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MK8grN018839; Wed, 22 Aug 2001 16:08:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 16:09:30 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ranjit K Avasarala'" , sip@ietf.org Subject: RE: [Sip] query on draft-rosenberg-sip-entfw-02.txt Date: Wed, 22 Aug 2001 16:09:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Ranjit K Avasarala [mailto:ranjitka@masconit.com] > Sent: Thursday, August 09, 2001 11:47 AM > To: sip@ietf.org > Subject: [Sip] query on draft-rosenberg-sip-entfw-02.txt > > > > Hi > I have a question on a statement in this draft: > > It says NAT will disappear with the deployment of Ipv6. Why is it so? I suspect this is going to start a very large flame war, as nat discussions always do, but I'll bite, since I think this is important. Some argue that nats exist because address space is limited. My ISP has limited space, so they give me only a single address, or charge exhorbitant rates for extra addresses. So, I buy a nat to allow multiple devices to exist behind a single address. Indeed, I am behind a nat at home right now. With v6, address space is so plentiful, that the provider will happily give me 100 addresses for nothing. So, the need for the nat goes away. Thats the theory, at least. I am not convinced that this is really actually true. I fear there will still even be nats with v6. Here is why: 1. some people deploy nats for privacy reasons. That is, they make it so that no one can know the actual internal addresses of boxes within my network. In a typical configuration, nats won't actually provide any extra protection, since mappings are frequently guessable or static. But, when done right, it can provide a degree of privacy that is not afforded with a firewall (generally, it requires randomized, dynamic mapping of internal addresses into a LARGE external address space, larger than the internal one!). The large external address space required here is expensive in v4, but becomes cheaper in v6. Arguably, this usage of nats therefore becomes more attractive with the deployment of v6! 2. People want addresses, so there is demand. Providers control the supply. Even though they are plentiful, you still must go to an ISP to get one, and they'll try and charge you money because of they know you want one. The large supply will certainly drive the price down, but will virtually unlimited addresses really be free? Not clear. Free is a hard business model to sustain, as the last year has taught many of us.... 3. v4 to v6 transition requires nats of some sort. So, I hope they do go away ultimately, but I am not so certain. Because of their pervasiveness today, and because its not clear they'll go away even with v6, I am a strong advocate of dealing with them in a reasonable fashion so that new applications can continue to be built and function, even though there are lots of nats around. OK, flame away. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 16:36:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23476 for ; Wed, 22 Aug 2001 16:36:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00041; Wed, 22 Aug 2001 16:20:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00010 for ; Wed, 22 Aug 2001 16:20:37 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22974 for ; Wed, 22 Aug 2001 16:19:16 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MKJ3rN018952; Wed, 22 Aug 2001 16:19:04 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 16:19:51 -0400 Message-ID: From: Jonathan Rosenberg To: "'Joerg Ott'" , Jonathan Rosenberg Cc: "'Connie Blanchard'" , sip@ietf.org Subject: RE: [Sip] Response Code of 422 in Session-Timer draft Date: Wed, 22 Aug 2001 16:19:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Comments below. > -----Original Message----- > From: Joerg Ott [mailto:jo@tzi.uni-bremen.de] > Sent: Monday, August 06, 2001 11:42 AM > To: Jonathan Rosenberg > Cc: 'Connie Blanchard'; sip@ietf.org > Subject: Re: [Sip] Response Code of 422 in Session-Timer draft > > > Since we did not get to Session Timer today... > > There could be another issue with a 422 response (which may or may not > be intended or accepted as such). > > You run into an interesting failure scenario if you have e.g. two > timer-aware proxies and a timer-unaware UAC as follows: > > UAC ----- P-A ----- P-B ------ UAS > > Now consider P-A with a preferred session timeout of 10 minutes > (which it always inserts) and P-B with a preferred session timeout > of 15 minutes (which it always wants to insist on). > > 1. UAC sends a simple INVITE w/o any session timer. > 2. P-A inserts Session-Expires: 600 > 3. P-B detects that this value is too small and generates a > > 422 Session Timer too small > Session-Expires: 900 > > 4. P-A forwards this up the UAC > > The INVITE transaction has completed so P-A clears all state > (there was no call established). > > 5. The UAC receives 422 Response but does not understand it. > Hence, the 422 defaults to 400 class response; no retry with > different timer value is done. > > -> The UAS was not reached because of a client error which simply > was not caused by the client. In particular, the UAC has no > idea what to do differently. > > Interestingly enough, in the other direction, calls go through just > fine (assuming a UAS that supports timer). A UAC supporting timer can > also initiate calls just fine. > > A similar scenarion may arise if you have P-A always reducing the > Session-Expires: header below what P-B expects (even if the UAC > understands and uses Session-Expires:). But this one is solved > by having Min-SE: in there set to the value desired by P-B in the > UAC. > > Am I missing something? No, you are correct that this is a problem. I wish I had seen this email earlier. I discovered this problem as well yesterday when updating the session timer draft. I forwarded a note to the list with a proposed solution, which was basically to have the proxy insert a Min-SE header in this case, instead of rejecting it, and then proxying it on. The UAS chooses the session timer to be the MAX(Min-SE, Session-Expires) and returns that in the Session-Expires header in the response. I welcome your comments on this mechanism. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 16:56:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23808 for ; Wed, 22 Aug 2001 16:56:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00849; Wed, 22 Aug 2001 16:42:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA00820 for ; Wed, 22 Aug 2001 16:42:34 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23567 for ; Wed, 22 Aug 2001 16:41:14 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MKf9rN019187; Wed, 22 Aug 2001 16:41:09 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 16:41:56 -0400 Message-ID: From: Jonathan Rosenberg To: "'brett@broadsoft.com'" , sip@ietf.org Subject: Legal merged requests (issue #172), was: RE: [Sip] Response Code of 422 in Session-Timer draft Date: Wed, 22 Aug 2001 16:41:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Wednesday, August 08, 2001 8:20 AM > To: sip@ietf.org > Subject: RE: [Sip] Response Code of 422 in Session-Timer draft > > Solution 3) Allow P1 to fork the same > request to P2 but use a higher Session-Expires. > This is bad because P2 potentially may not > realize that it is a different request and > assume that a forked request merged. Thus the > same negative response might get returned. > > Solution 3's problem is common for any > merged forking situation where a proxy includes > different headers or header values on the > different branches. This could be hopefully > avoided by specifying in the bis that if a > negative response was returned on a merged branch > request, subsequent merged requests must still > be checked to see if the same response applies. I think it is worth discussing this as a separate item. Its come up a few times and is amongst my open issues list for bis. We've run into a couple of cases now where a merged request isn't a bad thing. The current text on merged requests (http://www.jdrosen.net/sip/multiple_requests.txt) pretty much assumes that the only thing of relevance for a proxy is the r-uri, so that if this hasn't changed, the results of the proxy processing won't change. It has become clear that this is not the case at all. We now have several things that an upstream proxy might have modified which will result in differing behaviors: 1. Require/Proxy-Require stripping/addition 2. Session-Expires updating 3. modification of caller preferences headers There are several views on what to do here: 1. proxies shouldn't be mucking with any of these things anyway. The only real thing a proxy should change is the r-uri, so that the current merging text is correct. Basically, don't fix this problem. 2. As Brett has suggested, the proxy can redo its processing on these requests. If the "result" is the same, reject it as described in the text. Note that figuring out whether the result is the same is not easy. The previous request may have even been forked, so that this computation is quite hard. But, it is doable. Maybe the infrequency of this problem makes that OK. 3. Proxies don't even look for merged requests. A merged request is treated as a totally new and independent transaction, and thus processed normally. The result is that a proxy might proxy the same request twice. Hopefully, each time is with a different set of top via branch params. Ultimately, these arrive at a UA, which sees the merging. It applies the same response to all of them (so long as it uses the same tag, this works out ok). Comments? My leaning is probably 3 since I think its the easiest. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 17:17:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24193 for ; Wed, 22 Aug 2001 17:17:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01761; Wed, 22 Aug 2001 17:03:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01731 for ; Wed, 22 Aug 2001 17:03:24 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23964 for ; Wed, 22 Aug 2001 17:02:02 -0400 (EDT) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f7ML4BR16802; Wed, 22 Aug 2001 16:04:12 -0500 Message-ID: <004001c12b4d$f4aba3d0$ad036e3f@flak> From: "Dean Willis" To: "Jonathan Rosenberg" , References: Subject: Re: [Sip] URGENT: session timer: new issues Date: Wed, 22 Aug 2001 16:03:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Suggestions: 1) Deprecate forking -- solves the whole problem. Failing that, your proposal seems adequate. 2) Allowing a proxy to insert Session-Expires only in the presence of a UA Supported header would solve the problem, but begs the question of how to deal with clients that don't support or indicate support. Rather than allowing low-timer setups (as your idea of not returning 422), this would preclude use of sessin timer if at least one UA doesn't support it. On the other hand, I'm not all that convinced we have this nut cracked anyhow. It strikes me that we could have made this whole mess irrelevant by making keepalives mandatory from the start and just using fixed (or algorithmic with a standard algorithm) timers rather than negotiated timers. -- Dean ----- Original Message ----- From: "Jonathan Rosenberg" To: Sent: Tuesday, August 21, 2001 10:09 AM Subject: [Sip] URGENT: session timer: new issues > Folks, > > I was in the process of updating the session timer draft, getting it ready > for IESG, when I happened across several additional issues. For one, there > is a reasonable solution, but the other is more serious and requires some > discussion. Sigh... > > Issue #1 > -------- > > The 422 response code allows a proxy to reject a request with a > session-expires which is too low. It includes a Min-SE header with the > minimum value that it is willing to accept. According to the current draft, > the client is supposed to insert the Min-Se header into an INVITE, and the > value is: > > the value MUST be the largest > value amongst all Session-Expires values returned in 422 responses on > that leg. > > This wording is imprecise, since a leg won't have been established when you > get a 422 to the initial INVITE. As I was rewording this, I realized that > you might get a bunch of 422's before the call is setup, from proxies that > aren't eventually in the path of the final call leg (because of forking, > primarily). > > Consider the case where A calls B, and there is a Session-Expires in the > INVIITE A sends, with value 50. THis hits proxy X, which forks to Y and Z. Y > returns a 422 with a Min-SE of 10000, and Z returns a 422 with a Min-SE of > 75. The proxy forwards one of them arbitrarily, say the one from Y. The > client should retry the request with a Min-SE header in the INVITE, with > value 10000, and a Session-Expires of 10000. This once again forks to Y and > Z. Its OK by Y, but not by Z, so Z returns 422 with value 75. The fork from > Y returns a 486, so the proxy forwards the 422 upstream (there is another > issue here, which is that if Z returns a 408, the proxy will forward the > 408, and then thats it - call failure. Ideally, the proxy should have > forwarded the 422 so that the client can retry the request. This is a > generic problem, not specific to session timer, regarding which messages a > proxy chooses to forward upstream). Anyway, the UAC gets that 422 with a > Min-SE of 75, and then retries the request with a value of Min-SE of 10000, > and Session-Expires of 10000. Once again, it forks through Y and Z. THe > branch through Z returns a 200 OK. Now, in refreshes to the session, the > Min-SE will always be present with a value of 10000. THis is veyr large, and > way above the minimum required by the proxies on the path of the call leg > established through Z. > > My fix for this is that the client uses the max of the Min-SE amongst all > 422 in all responses for a particular CALL before any call legs are > established. Once a call leg is established, it uses the max of the min-SE > returned in all 422 responses for that call leg (i.e, with the same tag as > the 2xx that created the leg). As a result, when the call is accepted, the > max of the Min-SE is effectively "cleared", and then can be reset to the max > of the Min-SE on the path of the call leg. This seems to work fine. > > ISSUE #2 > -------- > > The big problem occurs when the 422 is used when the client doesn't support > session timer. > > So, the client sends an INVITE, and it knows nothing of session-timer. A > proxy inserts a Session-Expires into the request (which it is allowed to > do). It uses a Session-Expires of value 100. A downstream proxy thinks that > this is too small, so it rejects the request with a 422, and a Min-SE of > 200. This hits the client. But, since the client doesn't know the session > timer, the result is a call failure, since it won't know to retry the > request with the Min-SE header present. Oops. > > Now, we can mandate that 422 is returned only when the Supported header was > present in the INVITE. But, this means that sessions can be setup with > really low session timers. That seems bad. > > A better solution (soln 1) is to mandate that when there is no Supported > header, a proxy cannot insert a session timer value lower than a specific > minimum (namely, 30 minutes), and that no proxy server can reject a request > with a 422 if the session timer is larger than 30m (i.e., there be a maximum > minimum session expiration). > > Another option (soln 2) is this. A proxy can insert both a Session-Expires > and Min-SE into the request. If a proxy sees a request without a Supported > header, but with a Session-Expires header below its minimum, it can insert a > Min-SE header into the request before proxying it (although it can't > increase the session timer). When this hits the UAS, if it sees a > session-expires with a value lower than min-se, it uses the value from > min-se instead of the value in session-expires. > > Soln 1 is simpler, but can result in sessions being established with large > session timers even though smaller ones are possible and desired. Solution 2 > sets up the session with the right timer value, but requires further special > case processing. > > I would probably recommend solution 2, but I don't feel strongly and am not > sure the complexity is worth it. > > Comments? > > -Jonathan R. > > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 17:22:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24280 for ; Wed, 22 Aug 2001 17:22:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01718; Wed, 22 Aug 2001 17:03:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01685 for ; Wed, 22 Aug 2001 17:03:16 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23961 for ; Wed, 22 Aug 2001 17:01:54 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7ML1orN019393; Wed, 22 Aug 2001 17:01:50 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 17:02:38 -0400 Message-ID: From: Jonathan Rosenberg To: "'eburger@snowshore.com'" , SIP List Subject: RE: [Sip] Issue #113, wrt Content Sequencing Date: Wed, 22 Aug 2001 17:02:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Tuesday, August 07, 2001 6:14 AM > To: SIP List > Subject: [Sip] Issue #113, wrt Content Sequencing > > > On the one hand, I would love to find a generic mechanism for > ordering and > detecting loss in overlapped non-INVITE content. However, we > hashed over > this issue in the SIP-events discussion. Namely, content > sequencing and > recovery is inherently content-specific. Thus I would propose Strict > Sequencing (if needed) in the content, as Jonathan originally > proposed. I think the first question we need to ask is whether we even want to solve the problem of overlapping non-INVITE. One of the bigger motivating factors was the MESSAGE method. However, simple has converged upon NOT using MESSAGE for message transport in the session model. As a result, that need has disappeared. Are there other burning needs? This is one of those things where there may not be a need now, but it could be a big issue down the road when someone comes up with a need. Notifications for rapid presence changes, like second-granularity geo-loc updates, might be a need. A more radical view is that if you want second-granular presence updates, you are better off setting up the notifications as a "media stream" as we are doing for IM, and use just SUBSCRIBE as is to set it up.... THoughts? Lets resolve this. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 17:22:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24278 for ; Wed, 22 Aug 2001 17:22:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01970; Wed, 22 Aug 2001 17:11:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01874 for ; Wed, 22 Aug 2001 17:10:56 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24085 for ; Wed, 22 Aug 2001 17:09:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7ML9VrN019492; Wed, 22 Aug 2001 17:09:31 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 17:10:19 -0400 Message-ID: From: Jonathan Rosenberg To: "'Dean Willis'" , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] URGENT: session timer: new issues Date: Wed, 22 Aug 2001 17:10:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, August 22, 2001 5:04 PM > To: Jonathan Rosenberg; sip@ietf.org > Subject: Re: [Sip] URGENT: session timer: new issues > > > > Suggestions: > > 1) Deprecate forking -- solves the whole problem. Failing that, your > proposal seems adequate. Dean, we did take a consensus at IETF 51 to put this to rest once and for all. As I recall, the consensus was to NOT deprecate forking, and therefore we can avoid continuing needless debates on this subject. Since forking will stay, I will integrate my proposal into the draft. > > 2) Allowing a proxy to insert Session-Expires only in the > presence of a UA > Supported header would solve the problem, but begs the > question of how to > deal with clients that don't support or indicate support. Right, thats exactly the problem. In this case, the proposal is to insert Min-SE, so that the UAS effectively does what the UAC cannot - make sure that the resulting session-expires is not less than Min-SE. Rather than > allowing low-timer setups (as your idea of not returning > 422), this would > preclude use of sessin timer if at least one UA doesn't > support it. Well, specifically, there would be no session timer unless the client supports it. That is how session timer worked way, way, way back when, and there was such a pushback against this, that I caved (I was a proponent of not worrying about this case) and now we have this complex morass of negotiation. > On the > other hand, I'm not all that convinced we have this nut > cracked anyhow. Can you be more specific? > > It strikes me that we could have made this whole mess > irrelevant by making > keepalives mandatory from the start and just using fixed (or > algorithmic > with a standard algorithm) timers rather than negotiated timers. > Debating what we should have originally done is pointless, and I'm not even sure I would have put this in bis. I also think that the negotiated timers will find quite some use, perhaps for things we've been arguing not to use it for. Caveat emptor... -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 17:48:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24769 for ; Wed, 22 Aug 2001 17:48:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02799; Wed, 22 Aug 2001 17:32:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02768 for ; Wed, 22 Aug 2001 17:32:34 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24474 for ; Wed, 22 Aug 2001 17:31:13 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MLVBrN019741 for ; Wed, 22 Aug 2001 17:31:11 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 17:31:59 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Wed, 22 Aug 2001 17:31:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Open Issue #7: CANCEL for non-INVITE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Folks, This is the first of a series of emails I am going to send in an attempt to resolve the open issues in bis. Time is running short, and we need to resolve these things in the next few months. So, I would strongly encourage active participants on the list to give priority to these threads, rather than the many other interesting, but ultimately unimportant ones. I myself am guilty of being baited all the time with these things.... I will start with those issues discussed at IETF 51. I will send notes for the ones we both agreed upon, and those we didn't. The agreed upon ones serve the important purpose of making sure the list itself concurs, since IETF policy is that decisions cannot get made at meetings, only on the lists. I suspect there will be no controversy on these. So, here is the first. Issue #7: CANCEL for non-INVITE. Issue description: Currently, bis allows for CANCEL for all methods, not just INVITE. This made sense way back when, before we recognized that all non-INVITE methods really need to complete immediately. However, if all INVITEs are supposed to complete right away (i.e., the server immediately generates a response, and shouldn't wait for user input), the usage of CANCEL becomes a race condition. Whether the response is cancelled or not depends on whether or not the CANCEL beats the server's generation of a response. The argument has been made, and its a good one, that specifying a mechanism thats ALWAYS a race condition is futile. What is the cost? Some have argued that its nothing, since its harder to special case INVITE. However, I suspect there is a real cost on the server side. It now must have logic that tells it how to undo anything it might have done for a particular method before sending the final response. Yuck. The one point of contention at the meeting was whether CANCEL is useful for stopping timed-out transactions. That is, I send a SUBSCRIBE, and never get a response. After 16s (or whatever it is), I send CANCEL to terminate it, because I never got a response. However, I think that this is not a good argument. Since the server is supposed to respond immediately anway, sending CANCEL won't help trigger a response, since there is clearly some big error thats preventing the response from coming anyway. Others argued that errors can happen for lots of reasons, so perhaps the CANCEL will help. My proposal was that we should deprecate CANCEL for non-INVITE. The benefit is not even quantifiable, at best, and the cost seems high. Of course, for backwards compatibility, a server should not complain if it gets a CANCEL for a non-invite, just respond 200 OK (or even 405 is OK) and thats it. It should have responded to the request anyway. There was mild consensus on this, but some key participants disagreed. Please, speak up and lets resolve this. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 18:01:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24939 for ; Wed, 22 Aug 2001 18:01:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03062; Wed, 22 Aug 2001 17:36:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03033 for ; Wed, 22 Aug 2001 17:36:53 -0400 (EDT) Received: from iex.iex.com (iex.iex.com [192.153.124.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAB24523 for ; Wed, 22 Aug 2001 17:35:31 -0400 (EDT) Received: from iexfw.iex.com ([192.153.124.100]) by iex.iex.com (8.9.1/8.9.3) with SMTP id QAA01629 for ; Wed, 22 Aug 2001 16:36:15 -0500 (CDT) Received: from mail.iex.com ([172.25.41.2]) by home.tx.tekelec.com (8.9.3/8.9.3) with ESMTP id QAA11500 for ; Wed, 22 Aug 2001 16:34:35 -0500 (CDT) Message-ID: <3B842794.DAC76A7D@mail.iex.com> Date: Wed, 22 Aug 2001 16:43:48 -0500 From: Doug Hurtig Reply-To: hurtig@iex.com Organization: IEX Corporation X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: sip@ietf.org Subject: RE: [SIP] Killing hung media streams Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, Why must the UAC send a bye when a 481 is received? I thought that the 481 implies that the call leg is terminated. Section 15.5 states that "A UAC receiving a 481 response for any mid-call request (INVITE or otherwise) MUST consider the call terminated." Doug > > > > -----Original Message----- > > From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com] > > Sent: Friday, August 10, 2001 4:52 PM > > To: sip@ietf.org > > Subject: RE: [SIP] Killing hung media streams > > > > > > > > Sorry to dredge up this thread again, but in reading through > > it, I didn't > > get the impression there was consensus on what to do, and > > didn't notice > > anything in bis-04 that addressed it. Getting back to the > > original issue > > that prompted it (though many varied needs were voiced), say > > we have a UA > > that gets media it is not expecting as it has no > > corresponding session. The > > early consensus seemed to be to send ICMPs. > > That has little to do with SIP, and will just happen in the OS since no one > is listening on that port anyway. > > > > > The desire of that UA is to get the sender to stop the > > stream. This is my > > main concern with this thread. The sender of the stream may desire to > > attempt to re-establish the session, or may desire to kill > > the session it > > believes was active and associated with the stream. This > > seems to be an > > implementation specific decision, though communicating that > > desire may be > > something that is a protocol issue. What should the UA > > sending the media do > > when it gets ICMPs in either case? > > My recommendation is this. If a UA is in a call, and begins getting ICMP > errors on a media stream, and wishes to continue with the call, it SHOULD > send a re-INVITE on that leg. > > As an orthogonal issue, if a UAC receives a 481 to a mid-call re-INVITE, it > SHOULD tear down the call by sending a BYE. > > For your case, the re-INVITE will trigger a 481 since the call is not known > and not wanted at this server (the Tag indicates its a re-invite), and thus > the call is torn down and the media stops. > > > > > In my envirenment, I could live with either action taken by > > the UA, but > > need some action(s) standardized, rather than the current > > inaction. In the > > first case (re-Invite), I would establish a new session which > > would likely > > be to a different media address/port, and expect the UAC to > > stop sending to > > the first port. In the second case, I would send a 481 if a BYE for a > > non-existent session was received. > > Well, as I mentioned above, the call is not likely to be established in the > general case (although it can if recovery is what is desired). > > > > > > Note that there was discussion in the thread of sending a > > 481 response to a > > re-Invite. At least in my environment, we would send the > > ICMPs because we > > have no session associated with the received stream. Hence > > we may not have > > state for that session, and would recognize the Invite as a > > new session and > > not a re-Invite, so could not be expected to send a 481. > > Tag in the To field = re-INVITE. The process is described in section 15.5 of > bis-04 (although it says nothing yet about sending a BYE after getting the > 481. Thats the proposal.) > > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 18:06:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25035 for ; Wed, 22 Aug 2001 18:06:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03147; Wed, 22 Aug 2001 17:41:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03116 for ; Wed, 22 Aug 2001 17:41:44 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24615 for ; Wed, 22 Aug 2001 17:40:23 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MLeMrN019848; Wed, 22 Aug 2001 17:40:23 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 17:41:10 -0400 Message-ID: From: Jonathan Rosenberg To: "'hurtig@iex.com'" , sip@ietf.org Subject: RE: [SIP] Killing hung media streams Date: Wed, 22 Aug 2001 17:41:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Doug Hurtig [mailto:hurtig@iex.com] > Sent: Wednesday, August 22, 2001 5:44 PM > To: sip@ietf.org > Subject: RE: [SIP] Killing hung media streams > > > Hi, > > Why must the UAC send a bye when a 481 is received? I > thought that the > 481 implies that the call leg is terminated. Section 15.5 > states that > "A UAC receiving a 481 response for any mid-call request > (INVITE or otherwise) > MUST consider the call terminated." Thats the problem. I think this text is wrong. It should send a BYE, and then consider the call terminated as a result. Why? Well, we have a general rule that a non-2xx response to a re-INVITE does not mean the call is dead. Only BYE terminates a call. I'd like to keep that rule, since it provides a single, consistent way for everyone to say/know whether the call is up or down. I feel very strongly about this one. Having multiple ways of signaling that a call is down is very bad, IMHO. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 18:07:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25048 for ; Wed, 22 Aug 2001 18:07:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03349; Wed, 22 Aug 2001 17:46:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03317 for ; Wed, 22 Aug 2001 17:46:12 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24704 for ; Wed, 22 Aug 2001 17:44:50 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MLiqrN019889 for ; Wed, 22 Aug 2001 17:44:52 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 17:45:40 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Wed, 22 Aug 2001 17:45:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Open Issue #10: Stripping maddr Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Issue: There has been debate in the past about whether a proxy strips a maddr from the r-uri when it uses that maddr to send the request. IN other words, a proxy receives a request, invokes a location service, and ends up with an r-uri that looks like: sip:user@foo.com;maddr=1.2.3.4 It therefore sends the request to 1.2.3.4:5060. When this is placed in the request URI, should that maddr be stripped or not? Points to consider: THe current text in Section 16.5 of bis-04 are clear that it should strip it. The text also results in things working fine even if its not stripped. However, there was little comment on this text, despite the large amounts of email that flew around on the issue itself. Some have argued that maddr should not be stripped, so that middleboxes can figure out where the request is going from the sip layer itself (of course, they can figure it out from the destination ip as well). I personally don't find this one very compelling. Proposal: Consensus at the meeting, without much discussion or objection, was that the current text is fine. Speak now or forever hold your peace. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 18:13:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25139 for ; Wed, 22 Aug 2001 18:13:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03545; Wed, 22 Aug 2001 17:57:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03520 for ; Wed, 22 Aug 2001 17:57:52 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24873 for ; Wed, 22 Aug 2001 17:56:32 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MLuYrN019991 for ; Wed, 22 Aug 2001 17:56:34 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 17:57:21 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Wed, 22 Aug 2001 17:57:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Open Issue #11: Record-routing non-INVITE mid-call Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Issue: Can a proxy record-route non-INVITE, mid-call requests, such as INFO? NOTIFY? Points to consider: Generally, its hard to argue that proxies should be disallowed to record-route. We want them to be able to record-route anything so that their operation can be method-independent. The issue is, what does the UA do with that information? For things in the middle of an INVITEd session, the UA does nothing. I think bis is clear on that. If one side has lost the state of the session, a re-INVITE is the only thing that can replace the lost route set. The complex issue comes up with "session things" that are not created by INVITE. The one and only example to date is SUBSCRIBE. Adam has proposed that a SUBSCRIBE can usefully fork, resulting in the creation of multiple subscriptions. However, because of non-INVITE response merging rules, the UAC will learn of only one of these. It learns of the others through NOTIFY. Proxies can record-route those NOTIFY's, and the result is that the subscriber will get NOTIFY requests with new call legs (but the same Call-ID). It can therefore recognize these as creating multiple "subscription-legs", much like multiple 200 OK create multiple call legs for INVITE. Now, like any other "leg", we need to establish a route set for it. The proposal is that for NOTIFY, the UA be allowed to construct a route set for that subscription-leg, using the Record-Route/Contact in the NOTIFY. The issue is therefore tightly coupled with forking of non-INVITE. There was consensus to allow forking of non-invite (message on this is pending), so the need for this is clear. In general, new methods which can usefully fork and construct state at multiple recipients will need a similar 4-way handshake used by SUBSCRIBE. The four-way handshake is a request-response in the forward direction, followed by a different request in the reverse direction, one for each entity that state was created on. For all such requests, construction of route sets for each "leg" makes sense, so there is definitely a general need here. Proposal: The proposal is that proxies MAY record-route any method. Whether the UA uses this to build a route set is method dependent. For bis, the only method where route sets are built from record-routes is INVITE. Other extensions which build upon a four-way handshake for some kind of session-establishment will likely need this, and can specify it on a method-by-method basis. Bis will discuss the issue in general, and explain why this is so. There was consensus for this proposal at the meeting. So, speak up now and object, or forever hold your peace. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 18:53:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25778 for ; Wed, 22 Aug 2001 18:53:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04448; Wed, 22 Aug 2001 18:32:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04417 for ; Wed, 22 Aug 2001 18:32:23 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25455 for ; Wed, 22 Aug 2001 18:31:03 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MMV5rN020328 for ; Wed, 22 Aug 2001 18:31:05 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 18:31:53 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Wed, 22 Aug 2001 18:31:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Open Issue #20: Mixing unicast/multicast in offer/answer Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Issue: Appendix B is silent on whether its allowed to send an SDP offer with a c line thats unicast, and answer with multicast. Same with the inverse: can you answer a multicast offer with unicast? Points for discussion: In general, it is my view that the answer SDP should always be something that the offerer is guaranteed to be able to use. That is a consequence of the two way offer/answer handshake. If an offer is unicast, answering multicast seems a bad thing, since you don't know whether the offerer can do unicast. The argument is a bit weaker for the inverse case, but there could be cases where one is being invited to an mbone session that is multicast, where responding unicast makes little sense. Furthermore, the semantics of mixed unicast/multicast in offer answer aren't entirely clear. Proposal: If the offer is unicast, so must be the answer. If the offer is multicast, the answer should mirror that address (i.e., use the same multicast group). If you want a particular stream to change from unicast to multicast, re-invite to update it. There was consensus on this proposal at IETF 51. Any list objections? Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 18:59:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25827 for ; Wed, 22 Aug 2001 18:59:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04670; Wed, 22 Aug 2001 18:43:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04639 for ; Wed, 22 Aug 2001 18:43:33 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25632 for ; Wed, 22 Aug 2001 18:42:13 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MMgFrN020406 for ; Wed, 22 Aug 2001 18:42:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 18:43:03 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Wed, 22 Aug 2001 18:43:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Open Issue #23: dynamic PT reuse Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Issue: Currently, bis says that if you use a dynamic PT once, you can't reuse it again for a different codec in a re-invite. In other words, lets say A invites B using GSM codec, dynamic PT number 88. Then A re-invites, changing that stream to use AMR, with PT 97. Now, A re-invites once more. If it wants to use a codec other than GSM, it cannot use PT 88. Is that a problem? Points of discussion: The reason for this is synchronization of the media and signaling. You absolutely cannot reuse a PT for a different codec until any packets using that PT have been guaranteed to have exited the network. Rather than worry about figuring out a number for this, we just disallow reuse. The result is that you cannot cycle through more than 127 codecs in one SIP call. This is a reasonable restriction, IMHO. Proposal: keep this restriction. There was consensus on this at IETF 51. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 19:22:20 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26139 for ; Wed, 22 Aug 2001 19:22:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05290; Wed, 22 Aug 2001 19:09:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05261 for ; Wed, 22 Aug 2001 19:09:34 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25951 for ; Wed, 22 Aug 2001 19:08:16 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MN8GrN020556 for ; Wed, 22 Aug 2001 19:08:16 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 19:09:04 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Wed, 22 Aug 2001 19:08:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Issue: A and B are in a SIP call. A re-invite's B, but includes no SDP in the INVITE. This triggers B to generate an offer, in the 2xx. A doesn't like the offer. How does it reject it? When an offer is sent in an INVITE, it is easily rejected with a 488. But, when the offer is sent in a 2xx, its not easy to reject. For an initial INVITE, you reject it by ACKing and then sending BYE. Thats not great, but works OK. For a re-INVITE, you don't want to BYE, you want to get back to the last-known-good SDP. So, the issue is: what to do? Points of discussion: One proposal is to ACK the 2xx, disabling all the streams. THen, re-INVITE with the old SDP, in an attempt to re-instantiate it. However, this re-INVITE may fail. Also, it results in a transitional period where you have no media, which is not good. Another, more outlandish proposal, is to define a NACK that works like ACK, but says "nah, forget about it". This isn't backwards compatible though. Dave Oran had suggested that you need something, somewhere, to say "please go back to where we were before". Whether this is a header in the ACK, or whether this is in the SDP, it needs to be somewhere. You want to avoid these transitional periods where the state is bad. You need a way to go back. There seemed to be agreement that this was reasonable, but its not clear how to do it exactly. More discussion is needed. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 19:22:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26161 for ; Wed, 22 Aug 2001 19:22:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05173; Wed, 22 Aug 2001 19:01:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05144 for ; Wed, 22 Aug 2001 19:01:23 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25853 for ; Wed, 22 Aug 2001 19:00:05 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MN05rN020514 for ; Wed, 22 Aug 2001 19:00:05 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 19:00:53 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Wed, 22 Aug 2001 19:00:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Open Issue #146: Re-use disabled streams Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Issue: Bis currently specifies that if a client disables a media stream (by setting its port to zero), it cannot remove that stream from the SDP. As such, a UA which constantly adds/removes media streams will cause the SDP to continually grow, and never shrink. You definitely cannot remove them (since the ordering is needed to match up streams between the offer/answer), but it can work for a client to re-use a disabled stream. That is, when it wants to add a new stream, it uses the "placeholder" held by the disabled stream. So, instead of adding a new m line, the disabled m line is replaced with the m line of the stream you want to add. This works because there is never any confusion about which streams correspond to which. Think of the sequence of m lines in an SDP as a TDM system, with each stream a "channel". Streams in the offer and answer are correlated when they sit in the same channel. Once a stream is in a channel, it can't move to another one, since then you lose correlation. When a stream is disabled, its channel becomes empty. You can then insert a new stream into that channel later on, and its clear that this is a new one (because it replaces a disabled stream). So, the question is this: do we allow reuse of disabled streams in this fashion? Points of discussion: Why do this at all? The only real reason is savings of bandwidth, since you can reduce the size of the SDP. This is not a very common case for general usage. However, the 3gpp guys are thinking about having the proxy disable streams (egads!) based on some network policy about what codecs to use. They don't want to be carrying around these zeroed out media streams. However, our recommended approach with issues like this has been compression (ala the signaling compression work in rohc). These streams will likely be compressed very well, so the overhead may be moot. Gonzalo pointed out that an alternative is to use FID, since that could provide a way to correlate the streams. In that case, you can remove disabled streams altogether if they can be correlated. However, it wasn't clear that FID actually allows for correlation of streams between offer and answer. Rather, its meant for association of streams within the same SDP. More investigation was needed. Proposal: There was no concrete proposal yet. My leaning is to disallow reuse, and stick with what we have. Comments? -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 19:28:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26212 for ; Wed, 22 Aug 2001 19:28:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05372; Wed, 22 Aug 2001 19:14:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05341 for ; Wed, 22 Aug 2001 19:14:55 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26030 for ; Wed, 22 Aug 2001 19:13:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7MNDarN020586 for ; Wed, 22 Aug 2001 19:13:36 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 19:14:24 -0400 Message-ID: From: Jonathan Rosenberg To: "'sip@ietf.org'" Date: Wed, 22 Aug 2001 19:14:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Open Issue #138: to fork, or not to fork Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Issue: Do we deprecate forking for INVITE? Do we deprecate forking for non-INVITE? Points of discussion: There was quick discussion on the first issue, followed by a hum of consensus. THere was strong consensus to keep forking of INVITE, with the notable exception of the esteemed chair, Mr. Willis. There was agreement to close on this so that we can stifle continued dsicussion of the subject on the list. The second one is more complex. Forking of non-INVITE is complex since the non-INVITE only generates a single response. Forking makes sense when the things you fork to are homogeneous and don't create state. Thus, speaking to any one is fine. If state is created by the non-INVITE, and this state needs to be managed, the non-INVITE has to have some companion method that allows the "called party" to send a request back towards the "caller" to indicate that a "leg" was created there. We have encountered a need for this for SUBSCRIBE. It appears to be useful to fork SUBSCRIBE, and so long as we use Adam's proposed approach of constructing route sets and leg state through the NOTIFY, it works fine. Proposal: Continue to allow forking of non-INVITE. There was consensus on this proposal. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 20:10:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26828 for ; Wed, 22 Aug 2001 20:10:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06593; Wed, 22 Aug 2001 19:55:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06501 for ; Wed, 22 Aug 2001 19:55:45 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26649 for ; Wed, 22 Aug 2001 19:54:26 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7MNtni29995 for ; Wed, 22 Aug 2001 18:55:49 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 Aug 2001 18:55:44 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 22 Aug 2001 18:55:43 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] RE: Encapsulating EPIC in UDPComp Date: Wed, 22 Aug 2001 18:55:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] RE: Encapsulating EPIC in UDPComp X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcErKtDOBnDgjpccEdWBSQBQi2X+DwALzNNA From: "Liu Zhigang.C (NRC/Dallas)" To: "'ext Jonathan Rosenberg'" , "'Price, Richard'" , , X-OriginalArrivalTime: 22 Aug 2001 23:55:43.0897 (UTC) FILETIME=[F4A10890:01C12B65] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA06502 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, Support for Huffman codes is clearly beneficial and the detailed discussion here cleared many confusions in my head. However, I hope we still keep simplicity in mind while stretching out for extreme compression efficiency. From byte array to list, to tree, to graph, each one can cover the previous one but at the price of higher complexity. Besides increasing compression ratio from the encoding point of view (which has been dwelt on with much detail in this thread), we should also remember other simple mechanisms that boost compression ratio even without complicated encoding, such as user-specific dictionary and cross session dictionary. The former puts redundancy in dictionary early so that they can be used right away, and the latter allows the dictionary (after "hard working" synchronization) to be used for later session. These are simple concepts that are orthogonal to encoding algorithms. Another useful mechanism is the "shared dictionary" (as Jan mentioned early). This fits especially well to the (approximately) zigzag pattern of SIP messages. It incurs some challenge to the dynamic assignment of Huffman codes in the tree structured dictionary. But I believe it is doable. In short, we should tackle the problem from all angles by combining capabilities as Jonathan said. As to find "the right sweet spot between compression efficiency and flexibility", I would like to add simplicity as another dimension. BR, Zhigang > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: August 22, 2001 11:51 AM > To: 'Price, Richard'; Jonathan Rosenberg; 'sip@ietf.org'; > 'rohc@cdt.luth.se' > Subject: [Sip] RE: Encapsulating EPIC in UDPComp > > > > -----Original Message----- > > From: Price, Richard [mailto:richard.price@roke.co.uk] > > Sent: Wednesday, August 22, 2001 8:27 AM > > To: 'Jonathan Rosenberg'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > > Subject: RE: Encapsulating EPIC in UDPComp > > > > > Richard is exactly correct that the cost of a general purpose > > > decompressor like this is a hit in overhead. With purely static > > > codebook indices, the overhead is quite large as the results > > > below show. I agree totally that some kind of Huffman coding is > > > needed. I have been thinking about this, and I have a proposal > > > that is different from what Richard is proposing. > > > > On the contrary, your proposal is exactly how I hoped Huffman > > coding would be introduced! > > Great! I had thought you were proposing that a pre-agreed > upon Huffman code > be referenced during startup time, or that it was downloaded > at startup > time. The proposal here is that the Huffman codes are > constructed as you go, > since you need that to support dynamic codebooks, which I > think we all agree > is needed. Of course, one can easily support downloading of > the codes at > start time if a primitive is defined which is "WRITE this, > but don't output > anything into a decompressed message". > > > > > > My proposal would be to make the support for huffman coding > > > very general purpose, and based on a tree-like structure where > > > the codes are dependent on previous elements. Such a hierarchical > > > structure is needed, I think, to support the TCCB and EPIC > > > algorithms. > > > > Yes. In EPIC, the Huffman codes are local to each dictionary item. > > I think that you will need such a thing in general to achieve > really good > compression. > > > > So, the idea is that when you write into the codebook, you > > > provide a bit which says whether this write takes place at the > > > current "level" in the hierarchy, or back at the top. Then, you > > > provide a bitstring that represents the huffman code for > the token, > > > followed by the token. > > > > I would propose to take this one step further, and make the Huffman > > code indicate not only the location of the dictionary item, but also > > the type of token (READ, WRITE etc.). > > Excellent idea! Our goal should ultimately be that the > encoder output is > always a series of huffman codes, with some extra stuff to > write the strings > into the codebooks that are not already there. Some more > thoughts on that > below. > > > > We could do this as follows: > > > > - Keep all of the existing token types (READ, WRITE, > > WRITE-REFERENCE) > > but prefix them with a large bit pattern, say "11111111". > > > > - Reserve the remaining prefix codes ("00000000" to > "11111110") for > > the Huffman codes. > > > > - When a token is sent explicitly, attach a "shorthand" > Huffman code > > that can be used to send the token in future. > > > > When we send the Huffman code, it implicitly specifies the > token type > > (READ, WRITE etc.) as well as the location of the item to be read or > > written. > > I agree with that, but I'm not sure that you want to use > these large bit > patterns to represent the initial commands. The result will > be that initial > WRITEs and READs are really, really large. You only need > these large codes > when there are lots of Huffman codes in any particular table. > That won't > always be the case at all. > > One way to solve this is to have a really nice way to > dynamically construct > the Huffman codes. Lets say you have a Huffman code > represented by some > tree. Adding a new string can be done in only one way. You > take an existing > vertex somewhere in the tree, and remove the subtree (if > present). Add two > new branches below that vertex. Add the subtree to the right > branch, and > place your new string to the the other. > > Here's an example Huffman tree. Assume 0 is left, 1 is right: > > > /\ > /\ A > B C > > THis corresponds to: > > 00 B > 01 C > 1 A > > Now, we wish to add D. TO do that, we send a command that > reads like: "WRITE > into the table, spltting at 00, and the value is D". So, the > decoder finds > the vertex 00. TO do this, it starts at the root, goes left, > and then left > again. This is the vertex which currently encodes B. It > removes B, adds two > branches, places B on the right, and the new element on the left: > > /\ > /\ A > /\ C > D B > > Now, this table looks like: > > 1 A > 01 C > 001 B > 000 D > > So, the idea is that we always start with a default table > that has two codes > in it, which says "WRITE" in one of the two places: > > initial table: > > Code output > ------------------- > 0 WRITE the string which follows by splitting the > indicated vertex > in the curren table > 1 WRITE the string which follows into the root table > (i.e, change > contexts) by splitting the indicated vertex > > This code would need to be followed by the identity of the > vertex, and then > the text itself. > > This way, you start off with very efficient codes that write > into the table. > As the table gets larger, you use the efficient codes for the common > strings, and the code for writing into the table gets longer. > > Rather than simply enclosing the text as a string, we should > either Huffman > encode that with a standardized table, or else take all of > the text in a > message, put them together, compress it as an independent > blob, and then > send that together. > > > > > > > The advantage of this approach is that schemes like EPIC and > > Lempel-Ziv > > only ever send Huffman codes when reading and writing entries in the > > dictionary. Once UDPComp has successfully transmitted these > > Huffman codes > > to the decompressor there is no need to send the tokens > explicitly any > > more. This makes the overhead of UDPComp negligible (in > fact, the only > > overhead is the reserved bit pattern "11111111" that we used to send > > the tokens explicitly in the first place). > > Right. My proposal above reduces that as well, since this > overhead is not > once per message, but once per new token. > > > > > > > It is the responsibility of the encoder to make sure that > each code > > > is a valid prefix code. When the encoder sends a read command, it > > > contains a bit which indicates whether the read is from the top of > > > the tree or the current position, followed by the code. > > > > Agreed. However we should make this indicator flag part of > the Huffman > > code as well, so that we don't have to send it explicitly > every time. > > Right, that is the proposal above. > > > > > An interesting improvement is that I can specify a command which > > > says "READ code XX, and then read the next N symbols in the tree > > > if the number of children at each node is 1, in which case you > > > have no choice about the next symbol anyway". This is useful for > > > trees that are really deep, as opposed to wide. If you think about > > > it, this covers LZSS, which can be viewed as a "hierarchical" > > > codebook where each node is a single character, and the tree > > > is one where each node has only one child, the next character. > > > > > > > A similar enhancement might be to allow 1 Huffman code to indicate > > several consecutive choices of branches on the tree. This is > > especially useful when there is a single very likely route through > > the tree, as we can specify this route using only a single short > > Huffman code. > > Hmm, interesting idea. You need to be careful about this, > though, since > management of this tangle of tables can be complex. It would > be really nice > to maintain a simple structure. > > I think the way to do what you are proposing is to define a > command which is > "WRITE into the current table, splitting the specified > vertex. The element > to write is found by reading from here with the following > huffman codes: > XXX, and then the next table is the existing one at the end > of the read". > > This turns the tree of tables into a more general purpose > digraph, which is > probably a really good idea. It can save a lot of overhead in > the management > of the table. Protocols, like SIP, have many "paths" through > the message > which can arrive at a common piece of data (for example, the > SIP URL). This > way, the encoding for the SIP URL appears only once in > memory, rather than > based on each path to get to it. > > Maybe time to start writing all of this up in an updated I-D > for UDPComp, > since its probably hard to get it from these terse emails.... > > -Jonathan R. > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 20:14:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26862 for ; Wed, 22 Aug 2001 20:14:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07099; Wed, 22 Aug 2001 20:01:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07070 for ; Wed, 22 Aug 2001 20:01:16 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26722 for ; Wed, 22 Aug 2001 19:59:57 -0400 (EDT) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7N00IB14590; Wed, 22 Aug 2001 20:00:18 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAI05049 (AUTH pkyzivat); Wed, 22 Aug 2001 20:01:32 -0400 (EDT) Message-ID: <3B84462F.4A9854FB@cisco.com> Date: Wed, 22 Aug 2001 19:54:24 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Colin Perkins'" , Gonzalo Camarillo , sip@ietf.org, mmusic Subject: Re: [Sip] Re: SDP hold References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > So, here is an important question on the inactive attribute. If a stream is > inactive, is RTCP sent? I think it probably should, actually... RTCP helps > to keep state alive in various places, and this session is still alive, just > suspended. The introduction of a=inactive in some sense supercedes the old c=0.0.0.0 for hold. But the potential for saying c=0.0.0.0 remains, probably must remain for backward compatibility, and is still useful even with a=inactive. It is appropriate when you simply don't have an address to offer, as might often come about in an invite-on-hold situation. So, obviously if you say both a=inactive and c=0.0.0.0 then RTCP ought not (can't) be sent. If a=inactive and c= a valid address, then perhaps it makes sense to send RTCP, but I am not sure. There will certainly be cases when it isn't feasible to send it - a call controller that invites on hold in anticipation of a reinvite may not have a media implementation available with which to send to the other end. Paul Kyzivat Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 22:36:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00260 for ; Wed, 22 Aug 2001 22:35:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11127; Wed, 22 Aug 2001 22:24:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11098 for ; Wed, 22 Aug 2001 22:24:57 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29229 for ; Wed, 22 Aug 2001 22:23:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7N2NbrN021299 for ; Wed, 22 Aug 2001 22:23:37 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 22:24:25 -0400 Message-ID: From: Rakesh Shah To: "SIPWG Mailing List (sip@ietf.org)" Date: Wed, 22 Aug 2001 22:24:19 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12B7A.B6765F60" Subject: [Sip] SIP WG - Last Call Weekly Status Update Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12B7A.B6765F60 Content-Type: text/plain This Working Group Last Call status update is being sent out to keep the list up-to-speed. Any questions about this information can be addressed to Rakesh Shah (rshah@dynamicsoft.com ). Last Call Calendar (http://www.softarmor.com/sipwg/lastcall/lccalendar.pl ). Drafts in some part of WGLC: draft-ietf-sip-serverfeatures-05.txt Awaiting comments from A. Mankin. WGLC completed. Draft was submitted to IESG, returned for updates and updates were made by authors. The draft was then passed on to AD for IESG submittal. draft-ietf-sip-session-timer-05.txt WGLC complete, but new issues opened after IETF-51. Authors actively trying to close issues on list. Once issues are closed and updated in draft we will submit to IESG. draft-ietf-sip-callerprefs-04.txt Last Call review started. Open list discussion announced and will be closed on 7Sep01. draft-ietf-sip-mib-03.txt LC reviewers contacted. Still waiting for response from two reviewers. draft-ietf-sip-manyfolks-resource-01.txt NITS review in progress. (Critical to 3GPP.) draft-ietf-sip-call-auth-01.txt NITS reviewer contacted. Awaiting reply. Queued up after callerprefs. (Critical for 3GPP.) Drafts queued up for WGLC: draft-ietf-sip-privacy-02.txt Will have a -03 issued. -03 will be ready for WGLC. Will generate a lot of debate. (3GPP interest.) draft-ietf-sip-state-01.txt Ready for WGLC. Queued up after call-auth. draft-ietf-sip-rfc2543bis-04.txt Authors actively trying to close issues. Authors (and others) undertaking rewrite to make draft easier to comprehend. WGLC process expected to begin in early October. draft-johnston-sip-osp-token-01.txt Progressing to WGLC. draft-ietf-sip-100rel-03.txt Feedback expected from A. Mankin. Dependency on "supported" (serverfeatures). All of this information is kept current on the SIP WG Supplemental Website (http://www.softarmor.com/sipwg ). Regards, Rakesh _________________________ Mr. Rakesh C. Shah Project Coordinator dynamicsoft Inc. 72 Eagle Rock Avenue 1st Floor East Hanover, N.J. 07936 (973) 952-5066 direct (201) 214-6084 cell (973) 952-5000 main (973) 952-5050 fax rshah@dynamicsoft.com ------_=_NextPart_001_01C12B7A.B6765F60 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

This Working = Group Last Call status update is being sent out to keep the list = up-to-speed.

 

Any = questions about this information can be addressed to = Rakesh Shah (rshah@dynamicsoft.com).=

 

Last Call = Calendar (http://ww= w.softarmor.com/sipwg/lastcall/lccalendar.pl).<= o:p>

 

Drafts in = some part of WGLC:

 

draft-ietf-si= p-serverfeatures-05.txt

Awaiting = comments from A. Mankin. WGLC = completed. Draft was submitted to IESG, returned for updates and updates were made by = authors. The draft was then passed on to AD for IESG = submittal.

 

draft-ietf-si= p-session-timer-05.txt

WGLC = complete, but new issues opened after IETF-51. Authors actively = trying to close issues on list. Once issues are closed and updated in draft we = will submit to IESG.

 

draft-ietf-si= p-callerprefs-04.txt

Last Call = review started. Open list discussion announced and will be closed on = 7Sep01.

 

draft-ietf-si= p-mib-03.txt

LC reviewers contacted. Still waiting for response from two = reviewers.

 

draft-ietf-si= p-manyfolks-resource-01.txt

NITS review = in progress. (Critical to = 3GPP.)

 

draft-ietf-si= p-call-auth-01.txt

NITS reviewer contacted. Awaiting = reply. Queued up after callerprefs. (Critical for 3GPP.)

 

Drafts = queued up for WGLC:

 

draft-ietf-si= p-privacy-02.txt

Will have a = -03 issued. -03 will be ready for WGLC. Will generate a = lot of debate. (3GPP = interest.)

 

draft-ietf-si= p-state-01.txt

Ready for = WGLC. Queued up after = call-auth.

 

draft-ietf-si= p-rfc2543bis-04.txt

Authors = actively trying to close issues. Authors (and others) undertaking rewrite to make draft easier to = comprehend. WGLC process expected to begin in early = October.

 

draft-johnsto= n-sip-osp-token-01.txt

Progressing = to WGLC.

 

draft-ietf-si= p-100rel-03.txt

Feedback = expected from A. Mankin. Dependency on "supported" = (serverfeatures).

 

All of this information is kept current on the SIP WG Supplemental Website (http://www.softarmor.com/sipwg).

 

 

Regards,

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

 

 

------_=_NextPart_001_01C12B7A.B6765F60-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 22 22:58:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00829 for ; Wed, 22 Aug 2001 22:58:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11933; Wed, 22 Aug 2001 22:51:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11842 for ; Wed, 22 Aug 2001 22:51:09 -0400 (EDT) Received: from maliwan.psu.ac.th (maliwan.psu.ac.th [192.100.77.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00524 for ; Wed, 22 Aug 2001 22:49:46 -0400 (EDT) Received: from oossy ([172.30.2.69]) by maliwan.psu.ac.th (8.11.4/8.11.4) with SMTP id f7N2oxI22416 for ; Thu, 23 Aug 2001 09:50:59 +0700 (ICT) Message-ID: <001c01c12b7f$3a6f7af0$45021eac@oossy> From: "Jatupong Arun" To: Date: Thu, 23 Aug 2001 09:56:38 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C12BB9.E6AFCE70" 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 Subject: [Sip] Not clear about Authorization Request Header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C12BB9.E6AFCE70 Content-Type: text/plain; charset="windows-874" Content-Transfer-Encoding: quoted-printable I'm not clear about authorization Request Header from rfc2617 3.2.2 The Authorization Request Header The client is expected to retry the request, passing an Authorization header line, which is defined according to the framework above, utilized as follows. credentials =3D "Digest" digest-response digest-response =3D 1#( username | realm | nonce | digest-uri | response | [ algorithm ] | [cnonce] | [opaque] | [message-qop] | [nonce-count] | [auth-param] ) username =3D "username" "=3D" username-value username-value =3D quoted-string digest-uri =3D "uri" "=3D" digest-uri-value digest-uri-value =3D request-uri ; As specified by HTTP/1.1 message-qop =3D "qop" "=3D" qop-value cnonce =3D "cnonce" "=3D" cnonce-value cnonce-value =3D nonce-value nonce-count =3D "nc" "=3D" nc-value nc-value =3D 8LHEX response =3D "response" "=3D" request-digest request-digest =3D <"> 32LHEX <"> LHEX =3D "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "a" | "b" | "c" | "d" | "e" | "f" request-digest =3D <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) = ><"> if =20 A1 =3D unq(username-value) ":" unq(realm-value) ":" passwd where passwd =3D < user's password > A2 =3D Method ":" digest-uri-value ???I don't understand=20 1.user and passwd i must recieve from server in the web site 2.what does it mean "KD" =20 ???if recieve response from server when register follow this message if i have user =3D "test1" and password =3D "test2" and request uri =3D = "sipaccount.wcom.com" if( 401 ) WWW-Authenticate: Digest realm=3D"MCI WorldCom SIP", = domain=3D"wcom.com", nonce=3D"ea9c8e88df84f1cec4341ae6cbe5a359", opaque=3D"", = stale=3D"FALSE", algorithm=3D"MD5" True or False compute md5 digest is: A1 =3Dtest1:MCI WorldCom SIP:test2 A2=3DMethod:sipaccount.wcom.com request-digeist: if( 407 ) Proxy-Authenticate: DIGEST = realm=3D"WCOM",nonce=3D"7594b47a612e7ff86d314aca4a58280e" True or False compute md5 digest is: A1 =3Dtest1:WCOM:test2 A2=3DMethod:sipaccount.wcom.com request-digeist: if have some suggestion for me please offer me thanks a lot oossy ------=_NextPart_000_0019_01C12BB9.E6AFCE70 Content-Type: text/html; charset="windows-874" Content-Transfer-Encoding: quoted-printable
I'm not clear about authorization = Request=20 Header
 
from rfc2617
3.2.2 The Authorization Request=20 Header

   The client is expected to retry the request, = passing=20 an Authorization
   header line, which is defined according = to the=20 framework above,
   utilized as follows.

       = credentials      =3D "Digest"=20 digest-response
       = digest-response  =3D=20 1#( username | realm | nonce |=20 digest-uri
          = ;            = =20 | response | [ algorithm ] | [cnonce]=20 |
           &n= bsp;          =20 [opaque] | [message-qop]=20 |
           &n= bsp;           &nb= sp;  =20 [nonce-count]  | [auth-param] = )

      =20 username         =3D "username" = "=3D"=20 username-value
      =20 username-value   =3D=20 quoted-string
      =20 digest-uri       =3D "uri" "=3D"=20 digest-uri-value
       = digest-uri-value =3D=20 request-uri   ; As specified by=20 HTTP/1.1
      =20 message-qop      =3D "qop" "=3D"=20 qop-value
      =20 cnonce           =3D = "cnonce"=20 "=3D" cnonce-value
      =20 cnonce-value     =3D=20 nonce-value
      =20 nonce-count      =3D "nc" "=3D"=20 nc-value
      =20 nc-value         =3D=20 8LHEX
      =20 response         =3D "response" = "=3D"=20 request-digest
       request-digest = =3D=20 <"> 32LHEX <">
      =20 LHEX           &nb= sp;=20 =3D  "0" | "1" | "2" | "3"=20 |
           &n= bsp;           &nb= sp;  =20 "4" | "5" | "6" | "7"=20 |
           &n= bsp;           &nb= sp;  =20 "8" | "9" | "a" | "b"=20 |
           &n= bsp;           &nb= sp;  =20 "c" | "d" | "e" | "f"
 
 
      request-digest  =3D <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) = )=20 ><">
     if   
    =    =20 A1       =3D unq(username-value) ":"=20 unq(realm-value) ":" passwd
  =20 where
      passwd   =3D < = user's=20 password >
     =20 A2       =3D Method ":"=20 digest-uri-value
???I don't understand=20
        1.user and = passwd=20 i must recieve from server in the web site
        = 2.what does=20 it mean "KD"
       
???if recieve response from = server when=20 register follow this message
if i have user =3D "test1" and password = =3D "test2" and=20 request uri =3D "sipaccount.wcom.com"
 
if( 401 )
WWW-Authenticate: Digest realm=3D"MCI = WorldCom SIP",=20 domain=3D"wcom.com",
   = nonce=3D"ea9c8e88df84f1cec4341ae6cbe5a359",=20 opaque=3D"", stale=3D"FALSE",
   = algorithm=3D"MD5"
 
True or=20 False compute md5 digest is:
A1 =3Dtest1:MCI WorldCom = SIP:test2
A2=3DMethod:sipaccount.wcom.com
request-digeist:<KD (=20 MD5(A1),"ea9c8e88df84f1cec4341ae6cbe5a359") ":" MD5(A2) = )>
 
 
 
if( 407 )
Proxy-Authenticate: DIGEST=20 realm=3D"WCOM",nonce=3D"7594b47a612e7ff86d314aca4a58280e"
 
True or=20 False compute md5 digest is:
A1 =3Dtest1:WCOM:test2
A2=3DMethod:sipaccount.wcom.com
request-digeist:<KD (=20 MD5(A1),"7594b47a612e7ff86d314aca4a58280e") ":" MD5(A2) = )>
 
 
 
 
if have some suggestion for me please offer me
 
thanks a lot
oossy
 
 
 

------=_NextPart_000_0019_01C12BB9.E6AFCE70-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 09:29:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23208 for ; Thu, 23 Aug 2001 09:29:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04721; Thu, 23 Aug 2001 09:01:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA04682 for ; Thu, 23 Aug 2001 09:00:55 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22901 for ; Thu, 23 Aug 2001 08:59:32 -0400 (EDT) Received: by RSYS002A with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 14:00:37 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9E2E@RSYS002A> From: "Price, Richard" To: "'Jonathan Rosenberg'" , "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Date: Thu, 23 Aug 2001 14:00:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Sip] UDPComp: parallels with header compression Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, The idea of pre-agreed upon Huffman codes is something we use in header compression, as part of our framework for writing new compression algorithms for new protocol stacks. I believe, however, that downloading the Huffman codes "on the fly" is more appropriate for SIP compression. In fact the framework we developed for header compression shares many ideas with UDPComp, so it might be worth comparing the two schemes to see how much we can reuse. Streamlining the terminology would be of particular benefit as it will help us header compression folks understand UDPComp all the more quickly. - UDPComp has a set of tokens (READ, WRITE etc.) for transmitting instructions from the compressor to the decompressor. The same system is employed in RFC3095, but the tokens are referred to as "encoding methods". - UDPComp uses a dictionary of indexed fields to store information at the compressor and decompressor. This is also done in RFC3095, but referred to as the "context". The job of the compression algorithm is to send enough tokens to correctly transmit each packet to the decompressor. In RFC3095 the instructions for which tokens to send at which point are hand-coded in the standard, which gives a high compression efficiency but is somewhat inflexible. In TCP compression (draft-ietf-rohc-tcp-epic-01.txt) we have the idea of standardising a new compression algorithm as a set of instructions, each containing an index to a dictionary item, followed by a type of token (READ, WRITE etc.) and a probability. For example: encode Traffic_Class as STATIC 99.9% or IRREGULAR(6) 0.1% encode ECT_Flag as STATIC 99.9% or IRREGULAR(1) 0.1% encode CE_Flag as VALUE(1,0) 99% or VALUE(1,1) 1% It may not be obvious at a first glance, but each line in the set of instructions corresponds precisely to the "longhand" form of a UDPComp token. The token type (STATIC, IRREGULAR, VALUE etc.) is given together with the dictionary entry that is to be read from or written to (note that we use names rather than numbers to index the dictionary entries). The probabilities are converted by the decompressor into a set of Huffman codes; the compressor need only send the Huffman code to invoke the corresponding token at the decompressor. The key difference between this scheme and UDPComp is how the set of instructions is given to the decompressor. For header compression the performance of the scheme must be optimal, so the set of instructions is programmed into the decompressor offline. In UDPComp however, the idea is to download the instruction set one line at a time whenever each line is needed. This is very useful for SIP compression because we can avoid standardising the compression algorithm altogether, and just leave it as a local implementation decision at the compressor. Since the two schemes are essentially identical save how the shorthand Huffman codes are communicated to the decompressor, it would be very useful to develop them in parallel. The best possible situation would be for the two schemes to share a common dictionary structure: in this case we would have a single unified framework for header and signalling compression! For each protocol we could choose to standardise the compression algorithm explicitly, or just leave it up to the implementers to download suitable Huffman codes to the decompressor on the fly. Streamlining the two documents shouldn't affect the deadline for standardising UDPComp: in fact it might help speed things along because we have a decent tree-based dictionary structure worked out already. More comments included inline. Richard P > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, August 22, 2001 5:51 PM > To: Price, Richard; Jonathan Rosenberg; 'sip@ietf.org'; > 'rohc@cdt.luth.se' > Subject: RE: Encapsulating EPIC in UDPComp > > > -----Original Message----- > > From: Price, Richard [mailto:richard.price@roke.co.uk] > > Sent: Wednesday, August 22, 2001 8:27 AM > > To: 'Jonathan Rosenberg'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > > Subject: RE: Encapsulating EPIC in UDPComp > > > > > Richard is exactly correct that the cost of a general purpose > > > decompressor like this is a hit in overhead. With purely static > > > codebook indices, the overhead is quite large as the results > > > below show. I agree totally that some kind of Huffman coding is > > > needed. I have been thinking about this, and I have a proposal > > > that is different from what Richard is proposing. > > > > On the contrary, your proposal is exactly how I hoped Huffman > > coding would be introduced! > > Great! I had thought you were proposing that a pre-agreed > upon Huffman code be referenced during startup time, or that it > was downloaded at startup time. The proposal here is that the > Huffman codes are constructed as you go, since you need that to > support dynamic codebooks, which I think we all agree is needed. > Of course, one can easily support downloading of the codes at > start time if a primitive is defined which is "WRITE this, > but don't output anything into a decompressed message". I believe that we could still have a dynamic dictionary even if we agree/download the Huffman codes offline. In fact, this is how we distribute the Huffman codes for header compression. However for SIP compression it is better to download the Huffman codes as they are needed, so that we can avoid standardising them in the Internet Draft. > > > > > My proposal would be to make the support for huffman coding > > > very general purpose, and based on a tree-like structure where > > > the codes are dependent on previous elements. Such a hierarchical > > > structure is needed, I think, to support the TCCB and EPIC > > > algorithms. > > > > Yes. In EPIC, the Huffman codes are local to each dictionary item. > > I think that you will need such a thing in general to achieve > really good compression. Agreed. Without a local set of Huffman codes we don't get any better performance than Lempel-Ziv. > > > > So, the idea is that when you write into the codebook, you > > > provide a bit which says whether this write takes place at the > > > current "level" in the hierarchy, or back at the top. Then, you > > > provide a bitstring that represents the huffman code for > the token, > > > followed by the token. > > > > I would propose to take this one step further, and make the Huffman > > code indicate not only the location of the dictionary item, but also > > the type of token (READ, WRITE etc.). > > Excellent idea! Our goal should ultimately be that the encoder output > is always a series of huffman codes, with some extra stuff to write > the strings into the codebooks that are not already there. Some more > thoughts on that below. > > > > We could do this as follows: > > > > - Keep all of the existing token types (READ, WRITE, > > WRITE-REFERENCE) > > but prefix them with a large bit pattern, say "11111111". > > > > - Reserve the remaining prefix codes ("00000000" to > "11111110") for > > the Huffman codes. > > > > - When a token is sent explicitly, attach a "shorthand" > Huffman code > > that can be used to send the token in future. > > > > When we send the Huffman code, it implicitly specifies the > token type > > (READ, WRITE etc.) as well as the location of the item to be read or > > written. > > I agree with that, but I'm not sure that you want to use these large > bit patterns to represent the initial commands. The result will be that > initial WRITEs and READs are really, really large. You only need these > large codes when there are lots of Huffman codes in any particular table. > That won't always be the case at all. > > One way to solve this is to have a really nice way to dynamically > construct the Huffman codes. Lets say you have a Huffman code > represented by some tree. Adding a new string can be done in only one > way. You take an existing vertex somewhere in the tree, and remove > the subtree (if present). Add two new branches below that vertex. Add > the subtree to the right branch, and place your new string to the the > other. > This is a particularly cunning method of sending the Huffman codes to the decompressor! > Here's an example Huffman tree. Assume 0 is left, 1 is right: > > > /\ > /\ A > B C > > THis corresponds to: > > 00 B > 01 C > 1 A > > Now, we wish to add D. TO do that, we send a command that > reads like: "WRITE into the table, spltting at 00, and the > value is D". So, the decoder finds the vertex 00. TO do this, > it starts at the root, goes left, and then left again. This > is the vertex which currently encodes B. It removes B, adds two > branches, places B on the right, and the new element on the left: > > /\ > /\ A > /\ C > D B > > Now, this table looks like: > > 1 A > 01 C > 001 B > 000 D > > So, the idea is that we always start with a default table that has > two codes in it, which says "WRITE" in one of the two places: > > initial table: > > Code output > ------------------- > 0 WRITE the string which follows by splitting the > indicated vertex > in the curren table > 1 WRITE the string which follows into the root table > (i.e, change > contexts) by splitting the indicated vertex > > This code would need to be followed by the identity of the > vertex, and then the text itself. > > This way, you start off with very efficient codes that write > into the table. > As the table gets larger, you use the efficient codes for the common > strings, and the code for writing into the table gets longer. > > Rather than simply enclosing the text as a string, we should > either Huffman encode that with a standardized table, or else take > all of the text in a message, put them together, compress it as an > independent blob, and then send that together. I believe that algorithms like EPIC and Lempel-Ziv do this anyway. In EPIC we send Huffman codes for the longest matching string we can find, where the string can be 1 character long if we can't find a better match. So when encapsulated in UDPComp we never send a WRITE token containing any more than 1 ASCII character. Everything else is done using READ and WRITE-REFERENCE. > > > > > > > The advantage of this approach is that schemes like EPIC and > > Lempel-Ziv > > only ever send Huffman codes when reading and writing entries in the > > dictionary. Once UDPComp has successfully transmitted these > > Huffman codes > > to the decompressor there is no need to send the tokens > explicitly any > > more. This makes the overhead of UDPComp negligible (in > fact, the only > > overhead is the reserved bit pattern "11111111" that we used to send > > the tokens explicitly in the first place). > > Right. My proposal above reduces that as well, since this > overhead is not > once per message, but once per new token. > > > > > > > It is the responsibility of the encoder to make sure that > each code > > > is a valid prefix code. When the encoder sends a read command, it > > > contains a bit which indicates whether the read is from the top of > > > the tree or the current position, followed by the code. > > > > Agreed. However we should make this indicator flag part of > the Huffman > > code as well, so that we don't have to send it explicitly > every time. > > Right, that is the proposal above. > > > > > An interesting improvement is that I can specify a command which > > > says "READ code XX, and then read the next N symbols in the tree > > > if the number of children at each node is 1, in which case you > > > have no choice about the next symbol anyway". This is useful for > > > trees that are really deep, as opposed to wide. If you think about > > > it, this covers LZSS, which can be viewed as a "hierarchical" > > > codebook where each node is a single character, and the tree > > > is one where each node has only one child, the next character. > > > > > > > A similar enhancement might be to allow 1 Huffman code to indicate > > several consecutive choices of branches on the tree. This is > > especially useful when there is a single very likely route through > > the tree, as we can specify this route using only a single short > > Huffman code. > > Hmm, interesting idea. You need to be careful about this, though, > since management of this tangle of tables can be complex. It would > be really nice to maintain a simple structure. As with all of the other ideas for improving the compression ratio, we need to weigh the performance gain vs the additional complexity. For this particular modification the improvement in compression ratio is just over 30%. > > I think the way to do what you are proposing is to define a > command which is "WRITE into the current table, splitting the > specified vertex. The element to write is found by reading from > here with the following huffman codes: XXX, and then the next table > is the existing one at the end of the read". > > This turns the tree of tables into a more general purpose > digraph, which is probably a really good idea. It can save a lot > of overhead in the management of the table. Protocols, like SIP, > have many "paths" through the message which can arrive at a common > piece of data (for example, the SIP URL). This way, the encoding > for the SIP URL appears only once in memory, rather than > based on each path to get to it. I believe this also improves the compression ratio, because the same URL can appear several times in a given SIP message. If we use a digraph then we can avoid sending the URL more than once. > > Maybe time to start writing all of this up in an updated I-D > for UDPComp, since its probably hard to get it from these terse > emails.... > > -Jonathan R. > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 10:02:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23690 for ; Thu, 23 Aug 2001 10:02:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05592; Thu, 23 Aug 2001 09:48:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05562 for ; Thu, 23 Aug 2001 09:48:09 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23443 for ; Thu, 23 Aug 2001 09:46:51 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 06:46:35 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: RE: [Sip] Discussion: Mixing unicast/multicast in offer/answer Date: Thu, 23 Aug 2001 06:46:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org No objection to this resolution. However I though I would point out that the Offer/Counter-offer/Answer SDP model suggested in the "Weakness in SIP offer/answer model" thread may be helpful in solving this problem without a re-invite. It falls into the general problem category of: Caller proposes some media configuration A which is disagreeable to callee, therefore, callee counter-proposes media configuration B back to caller. Additionally, the solution must avoid the situation where the caller believes the call is successfully answered but in fact the caller lacks the capability to support media configuration B. [Please reply to original thread to discuss solution details.] Robert. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, August 22, 2001 11:32 PM > To: 'sip@ietf.org' > Subject: [Sip] Open Issue #20: Mixing unicast/multicast in > offer/answer > > > Issue: > > Appendix B is silent on whether its allowed to send an SDP > offer with a c > line thats unicast, and answer with multicast. Same with the > inverse: can > you answer a multicast offer with unicast? > > Points for discussion: > > In general, it is my view that the answer SDP should always > be something > that the offerer is guaranteed to be able to use. That is a > consequence of > the two way offer/answer handshake. If an offer is unicast, answering > multicast seems a bad thing, since you don't know whether the > offerer can do > unicast. The argument is a bit weaker for the inverse case, > but there could > be cases where one is being invited to an mbone session that > is multicast, > where responding unicast makes little sense. > > Furthermore, the semantics of mixed unicast/multicast in > offer answer aren't > entirely clear. > > Proposal: > > If the offer is unicast, so must be the answer. If the offer > is multicast, > the answer should mirror that address (i.e., use the same > multicast group). > If you want a particular stream to change from unicast to multicast, > re-invite to update it. > > There was consensus on this proposal at IETF 51. Any list objections? > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 10:12:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23849 for ; Thu, 23 Aug 2001 10:12:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06040; Thu, 23 Aug 2001 09:58:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06012 for ; Thu, 23 Aug 2001 09:58:29 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23540 for ; Thu, 23 Aug 2001 09:57:11 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 06:56:55 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'sip@ietf.org'" Cc: "'jdrosen@dynamicsoft.com'" Subject: RE: [Sip] Weakness in SIP offer/answer model. Date: Thu, 23 Aug 2001 06:56:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Perhaps defining a SIP header value (valid in 1xx & 2xx INVITE responses) that simply states that the SDP is a counter offer is the best approach. This separates the handling of these issues from the early-media issues ? Content-Disposition seems like a logical place to do this ? For instance define a new token name to supplement the existing "session" disposition and use it with a "handling=required" disposition value. Comments/thoughts? Robert. > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Saturday, August 11, 2001 8:52 AM > To: 'sip@ietf.org' > Cc: 'jdrosen@dynamicsoft.com' > Subject: [Sip] Weakness in SIP offer/answer model. > > > > I perceive a strong weakness in the current SIP offer/answer model. > > The problem pertains to the fact that the callee has no way > of indicating > its media profile requirements. Consider the situation: > > A sends INVITE B with > m=audio 5454 RTP/AVP 0 > m=video 4444 RTP/AVP 31 > > However the server only supports (or requires for this call) > a different > profile, eg RTP/SAVP or some other transport profile > (RTP/AVP-USCTP or TLS > or something). > > There is no way that the callee has to communicate this > information to the > caller. This will be needed for proper deployment of SRTP on > servers and a > great many other things. > > - You cannot accept the call by setting the port to zero and > then sending a > re-INVITE as you cannot be sure that the client supports this profile. > Answering calls successfully when you really don't have the ability to > communicate is something that we want to avoid at all costs > (dead handset > syndrome). > > - It cannot be communicated in SIP headers as this is a layer > violation (and > just bad design). You are trying to use the session protocol > to signal he > required SDP transport paths. > > - You could send a 4xx error with an SDP indicate the > appropriate offer that > the caller should make to be successful. The requires more > messages, longer > call setup times and new parsing & analysis logic of the SDP > on the client > side. I don't like it. > > I have a proposal: I think what we need is to allow a > offer/counter-offer/answer model. Now this sounds very familiar -> > Jonathan's new Early Media model! SDP in INVITE, callee instead sends > counter-offer in reliable provisional response, to which the > caller either > accepts or rejects with the SDP in PRACK. When the 200 OK is > eventually sent > by the callee it is in answer to the SDP in the PRACK (rather > than original > INVITE). > > I would like to see this generalized such that it can also be > used with > local ringback (rather than removed as some have requested). > > Once again, I see this functionality as _absolutely_ crucial > to the proper > deployment of SRTP and other SDP transport profiles. This > also apples to the > situation where the callee needs to know whether the caller supports a > certain SDP capability (for instance, support for a particular SDP > attributes) - another very, very important case. > > Please suggest something else if you don't like this scheme. > > [Jonathan proposed an alternate solution in the open issues > section of his > early media draft: > > .... We would then need a token in the 1xx somewhere > which says "I ignored your offer of SDP in the INVITE, this > 2xx is an offer, not an answer". This token, perhaps a > require token, would be present in the original 1xx but not > 1xx in response to re-INVITEs. We could apply this to > INVITE/2xx/ACK as well. > > We should try to make any scheme consistent and as long as it > works I am not > bothered.] > > Regards, > > Robert. > > P.S. I'm going to be away for the next couple of weeks (good > duck and cover > tactic :-) > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 10:25:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24089 for ; Thu, 23 Aug 2001 10:25:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05955; Thu, 23 Aug 2001 09:55:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05928 for ; Thu, 23 Aug 2001 09:55:51 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23520 for ; Thu, 23 Aug 2001 09:54:33 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29191; Thu, 23 Aug 2001 09:55:19 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA02827; Thu, 23 Aug 2001 09:55:21 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Aug 2001 09:55:21 -0400 Message-ID: <313680C9A886D511A06000204840E1CF57BF9B@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jonathan Rosenberg'" , "'sip@ietf.org'" Subject: RE: [Sip] Open Issue #7: CANCEL for non-INVITE Date: Thu, 23 Aug 2001 09:55:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org In the interests of moving things along, the chairs will call consensus on these issues explicitly. If you object, PLEASE speak up, so that we can try to see if/when objectors are satisfied. Jonathan, poke us if we don't call consensus when you think we have it, but let us make the call. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, August 22, 2001 5:32 PM > To: 'sip@ietf.org' > Subject: [Sip] Open Issue #7: CANCEL for non-INVITE > > > Folks, > > This is the first of a series of emails I am going to send in > an attempt to > resolve the open issues in bis. Time is running short, and we need to > resolve these things in the next few months. So, I would > strongly encourage > active participants on the list to give priority to these > threads, rather > than the many other interesting, but ultimately unimportant > ones. I myself > am guilty of being baited all the time with these things.... > > I will start with those issues discussed at IETF 51. I will > send notes for > the ones we both agreed upon, and those we didn't. The agreed > upon ones > serve the important purpose of making sure the list itself > concurs, since > IETF policy is that decisions cannot get made at meetings, only on the > lists. I suspect there will be no controversy on these. > > So, here is the first. Issue #7: CANCEL for non-INVITE. > > Issue description: Currently, bis allows for CANCEL for all > methods, not > just INVITE. This made sense way back when, before we > recognized that all > non-INVITE methods really need to complete immediately. > However, if all > INVITEs are supposed to complete right away (i.e., the server > immediately > generates a response, and shouldn't wait for user input), the usage of > CANCEL becomes a race condition. Whether the response is > cancelled or not > depends on whether or not the CANCEL beats the server's > generation of a > response. The argument has been made, and its a good one, > that specifying a > mechanism thats ALWAYS a race condition is futile. > > What is the cost? Some have argued that its nothing, since > its harder to > special case INVITE. However, I suspect there is a real cost > on the server > side. It now must have logic that tells it how to undo > anything it might > have done for a particular method before sending the final > response. Yuck. > > The one point of contention at the meeting was whether CANCEL > is useful for > stopping timed-out transactions. That is, I send a SUBSCRIBE, > and never get > a response. After 16s (or whatever it is), I send CANCEL to > terminate it, > because I never got a response. However, I think that this is > not a good > argument. Since the server is supposed to respond immediately > anway, sending > CANCEL won't help trigger a response, since there is clearly > some big error > thats preventing the response from coming anyway. Others > argued that errors > can happen for lots of reasons, so perhaps the CANCEL will help. > > My proposal was that we should deprecate CANCEL for > non-INVITE. The benefit > is not even quantifiable, at best, and the cost seems high. > Of course, for > backwards compatibility, a server should not complain if it > gets a CANCEL > for a non-invite, just respond 200 OK (or even 405 is OK) and > thats it. It > should have responded to the request anyway. > > There was mild consensus on this, but some key participants disagreed. > Please, speak up and lets resolve this. > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 10:35:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24396 for ; Thu, 23 Aug 2001 10:35:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06926; Thu, 23 Aug 2001 10:18:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06837 for ; Thu, 23 Aug 2001 10:18:08 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23938 for ; Thu, 23 Aug 2001 10:16:49 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7NEI2v26835; Thu, 23 Aug 2001 16:18:03 +0200 (MEST) Received: from lmf.ericsson.se (rmt160216.am.ericsson.se [138.85.160.216]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA15869; Thu, 23 Aug 2001 16:17:55 +0200 (MET DST) Message-ID: <3B8513E5.625F03D5@lmf.ericsson.se> Date: Thu, 23 Aug 2001 17:32:05 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Sean Olson (EUS)" CC: "'Jonathan Rosenberg'" , "'Colin Perkins'" , "'sip@ietf.org'" , "'mmusic'" Subject: Re: [Sip] Re: SDP hold References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, "Sean Olson (EUS)" wrote: > > I thought the entire point of the inactive attribute > was to specify a stream that did not send RTP -or- RTCP. This attribute is used to put a call on hold. That is, when you put somebody on hold the stream will be "sendonly". If at that point of time you are put on hold as well, the media stream will be "inactive". Therefore, RTCP is still sent. > If we accept the following: > > 1) send-only: RTP one way, RTCP two way > 2) recv-only: RTP one way, RTCP two way > 3) send-recv: RTP two way, RTCP two way > 4) inactive: no RTP, RTCP two way Yes, bullet number 4 defines perfectly the semantics of the inactive attribute. > 5) XXX: no RTP, no RTCP ??? > > Then what is used to specify the fifth item > (no RTP, no RTCP)? This is currently defined by setting the port number to zero. That is, I offer you a particular media stream and you set its port to zero in the 200 OK. It means that no RTP and no RTCP will be sent over that media stream. This brings me to related topic: Right now, once you have answer with port=zero, you cannot re-use that stream during the session. That is, every re-INVITE you send will contain that media line with the port set to zero, but media will never flow to it. It has been brought up (by 3GPP among others) that it might be useful to be able to re-use that stream in a future. If I want to add a new media stream to the session, I can use that media line by changing the port number to a non-zero value in a re-INVITE. Well, I am triggering a new discussion here (I would like to see opinions on this), but I believe that the semantics of the inactive attribute are pretty clear. Regards, Gonzalo > /sean > > >-----Original Message----- > >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >Sent: Wednesday, August 22, 2001 1:30 PM > >To: 'Colin Perkins'; Gonzalo Camarillo > >Cc: Jonathan Rosenberg; sip@ietf.org; mmusic > >Subject: RE: [Sip] Re: SDP hold > > > > > >So, here is an important question on the inactive attribute. > >If a stream is > >inactive, is RTCP sent? I think it probably should, > >actually... RTCP helps > >to keep state alive in various places, and this session is > >still alive, just > >suspended. > > > >THoughts? > > > >-Jonathan R. > > > > > >--- > >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > >Chief Scientist First Floor > >dynamicsoft East Hanover, NJ 07936 > >jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >http://www.jdrosen.net PHONE: (973) 952-5000 > >http://www.dynamicsoft.com > > > > > >> -----Original Message----- > >> From: Colin Perkins [mailto:csp@purple.cs.ucl.ac.uk] > >> Sent: Wednesday, August 15, 2001 5:30 AM > >> To: Gonzalo Camarillo > >> Cc: Jonathan Rosenberg; sip@ietf.org; mmusic > >> Subject: Re: [Sip] Re: SDP hold > >> > >> >a=inactive > >> > This specifies that the tools should be started in inactive > >> > mode. This is necessary for interactive conferences > >> where users can > >> >put other users on hold. No media is sent over an inactive > >> media stream. > >> >It can be either a session or media attribute, and is not > >> dependent on > >> >charset. > > -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 10:57:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24796 for ; Thu, 23 Aug 2001 10:57:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07959; Thu, 23 Aug 2001 10:42:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07926 for ; Thu, 23 Aug 2001 10:42:06 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24521 for ; Thu, 23 Aug 2001 10:40:49 -0400 (EDT) Received: from dynamo.cs.columbia.edu (dynamo.cs.columbia.edu [128.59.16.4]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA11933; Thu, 23 Aug 2001 10:42:04 -0400 (EDT) Received: (from petkos@localhost) by dynamo.cs.columbia.edu (8.9.3+Sun/8.9.3) id KAA18989; Thu, 23 Aug 2001 10:42:03 -0400 (EDT) From: "Petri K. Koskelainen" Message-Id: <200108231442.KAA18989@dynamo.cs.columbia.edu> Subject: RE: [Sip] Issue #113, wrt Content Sequencing To: sip@ietf.org Date: Thu, 23 Aug 2001 10:42:03 -0400 (EDT) Cc: jdrosen@dynamicsoft.com, eburger@snowshore.com 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 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi, There are at least some use cases for that. For example, group messaging where large number of clients are sending (sessionless) instant MESSAGES to the group address in a server which generates new MESSAGEs to all group members. It makes no sense to wait until previous MESSAGE has been acknowledged since it takes too long. So, there will be overlapping MESSAGEs. The actual application may be e.g. instant message group, game or whatever sessionless application. In some applications (like games) it would be really useful to have the ordering (sequencing) information of the MESSAGEs. For more description and reasoning see http://search.ietf.org/internet-drafts/draft-koskelainen-sip-group-00.txt This feature would be enabled by a new header (set by the group server in the example above). In a similar application, this feature would be useful also between two endpoints. -- Petri > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Tuesday, August 07, 2001 6:14 AM > To: SIP List > Subject: [Sip] Issue #113, wrt Content Sequencing > > > On the one hand, I would love to find a generic mechanism for > ordering and > detecting loss in overlapped non-INVITE content. However, we > hashed over > this issue in the SIP-events discussion. Namely, content > sequencing and > recovery is inherently content-specific. Thus I would propose Strict > Sequencing (if needed) in the content, as Jonathan originally > proposed. I think the first question we need to ask is whether we even want to solve the problem of overlapping non-INVITE. One of the bigger motivating factors was the MESSAGE method. However, simple has converged upon NOT using MESSAGE for message transport in the session model. As a result, that need has disappeared. Are there other burning needs? This is one of those things where there may not be a need now, but it could be a big issue down the road when someone comes up with a need. Notifications for rapid presence changes, like second-granularity geo-loc updates, might be a need. A more radical view is that if you want second-granular presence updates, you are better off setting up the notifications as a "media stream" as we are doing for IM, and use just SUBSCRIBE as is to set it up.... THoughts? Lets resolve this. -Jonathan R. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 10:57:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24809 for ; Thu, 23 Aug 2001 10:57:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08007; Thu, 23 Aug 2001 10:42:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07978 for ; Thu, 23 Aug 2001 10:42:43 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24553 for ; Thu, 23 Aug 2001 10:41:26 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7NEghU02760; Thu, 23 Aug 2001 10:42:44 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA17713; Thu, 23 Aug 2001 09:42:42 -0500 (CDT) Message-ID: <3B851658.77A8432@lucent.com> Date: Thu, 23 Aug 2001 09:42:32 -0500 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'sip@ietf.org'" Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...[ > So, here is the first. Issue #7: CANCEL for non-INVITE. [...] > My proposal was that we should deprecate CANCEL for non-INVITE. Jonathan: If we have as a operating assumption (requirement?) that non-INVITE methods have to be responded to immediately, then deprectaing CANCEL for these methods is actually preferable. Even in the SUBSCRIBE case you mentioned in your email, if the UAS fielding the SUBSCRIBE "knows" that there maybe delay -- caused by ldap lookups, user authorization, whatever -- in responding with a 200 OK to the SUBSCRIBE, it still must send a 202 Accepted final response right away. So I see little utility in attempting to CANCEL a SUBSCRIBE. As I pointed out at the London IETF, this issue is somewhat related to Issue #138 (to fork or not to fork [non-INVITE requests]). Since the consensus on Issue 138 is that it is okay to fork non-INVITEs, -04bis should indicate (in Section 17.4, handling of 2xx responses) that a forking proxy need not CANCEL non-INVITE branches on getting a 200 OK for a non-INVITE request. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 11:43:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26125 for ; Thu, 23 Aug 2001 11:43:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09784; Thu, 23 Aug 2001 11:22:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09756 for ; Thu, 23 Aug 2001 11:22:07 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25593 for ; Thu, 23 Aug 2001 11:20:49 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7NFM8v24988; Thu, 23 Aug 2001 11:22:08 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA21742; Thu, 23 Aug 2001 10:22:06 -0500 (CDT) Message-ID: <3B851F93.DF8985F0@lucent.com> Date: Thu, 23 Aug 2001 10:21:55 -0500 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'sip@ietf.org'" Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan: Comments inline: Jonathan Rosenberg wrote: > > Issue: > > A and B are in a SIP call. A re-invite's B, but includes no SDP in the > INVITE. This triggers B to generate an offer, in the 2xx. A doesn't like > the offer. How does it reject it? When an offer is sent in an INVITE, it > is easily rejected with a 488. But, when the offer is sent in a 2xx, its > not easy to reject. For an initial INVITE, you reject it by ACKing and > then sending BYE. Thats not great, but works OK. For a re-INVITE, you > don't want to BYE, you want to get back to the last-known-good SDP. > > So, the issue is: what to do? > > Points of discussion: > > One proposal is to ACK the 2xx, disabling all the streams. THen, re-INVITE > with the old SDP, in an attempt to re-instantiate it. However, this > re-INVITE may fail. Also, it results in a transitional period where you > have no media, which is not good. > > Another, more outlandish proposal, is to define a NACK that works like > ACK, but says "nah, forget about it". This isn't backwards compatible > though. > > Dave Oran had suggested that you need something, somewhere, to say "please > go back to where we were before". Whether this is a header in the ACK, or > whether this is in the SDP, it needs to be somewhere. You want to avoid > these transitional periods where the state is bad. You need a way to go > back. > > There seemed to be agreement that this was reasonable, but its not clear > how to do it exactly. More discussion is needed. Adding a NACK will break backwards compatibility, so that rules it out. Adding a new header, while better than adding NACK, still means more code to add and one more header to keep track of. I like the first approach -- ACK the 2xx, disabling all media streams. The disadvantage it has over the new header option is that more signaling is needed in the form of a re-INVITE. However, I do not understand your concern on the re-INVITE failing? If the session was established successfully, and a subsequent attempt to renegotiate it failed, why will the re-INVITE fail if the same SDP as the successful session was being used in the re-INVITE? - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 12:08:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26553 for ; Thu, 23 Aug 2001 12:08:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10755; Thu, 23 Aug 2001 11:50:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10724 for ; Thu, 23 Aug 2001 11:50:55 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26209 for ; Thu, 23 Aug 2001 11:49:37 -0400 (EDT) Received: from mailhost.ubiquity.net by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 23 Aug 2001 15:50:56 UT Received: from ubiquity.net ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Thu, 23 Aug 2001 16:50:56 +0100 Message-ID: <3B85264A.7AA39FBB@ubiquity.net> Date: Thu, 23 Aug 2001 16:50:34 +0100 From: James Undery X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Petri K. Koskelainen" CC: sip@ietf.org Subject: Re: [Sip] Issue #113, wrt Content Sequencing References: <200108231442.KAA18989@dynamo.cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Aug 2001 15:50:56.0245 (UTC) FILETIME=[65735250:01C12BEB] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit "Petri K. Koskelainen" wrote: > > Hi, > > There are at least some use cases for that. > > For example, group messaging where large number > of clients are sending (sessionless) instant MESSAGES > to the group address in a server which generates new > MESSAGEs to all group members. > It makes no sense to wait until previous MESSAGE has been > acknowledged since it takes too long. So, there will be > overlapping MESSAGEs. I think you're confusing overlapping, in this example the resolution of the overlapping messages is a service in the server. i.e. the server recieves a message from A and sends it to all the recipients, all apart from B acknowledge, C then sends a message, the server sends it to every one apart from B, A sends another message, which again goes out to every one except B, when B acknowledges the first message, he gets sent the second message etc. > > The actual application may be e.g. instant message group, > game or whatever sessionless application. > > In some applications (like games) it would be really useful > to have the ordering (sequencing) information of the MESSAGEs. > For more description and reasoning see > > http://search.ietf.org/internet-drafts/draft-koskelainen-sip-group- > 00.txt If I was writting a game, I am not sure reliability and any ordering other strictly increasing would be an issue! > > This feature would be enabled by a new header (set by the group server > in the example above). > > In a similar application, this feature would be useful also > between two endpoints. > > -- > Petri > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Tuesday, August 07, 2001 6:14 AM > > To: SIP List > > Subject: [Sip] Issue #113, wrt Content Sequencing > > > > > > On the one hand, I would love to find a generic mechanism for > > ordering and > > detecting loss in overlapped non-INVITE content. However, we > > hashed over > > this issue in the SIP-events discussion. Namely, content > > sequencing and > > recovery is inherently content-specific. Thus I would propose Strict > > Sequencing (if needed) in the content, as Jonathan originally > > proposed. > > I think the first question we need to ask is whether we even want to solve > the problem of overlapping non-INVITE. I'd vote no, the only cases I can think of where it would be needed, SIP is inappropriate or it's a service issue. > > One of the bigger motivating factors was the MESSAGE method. However, simple > has converged upon NOT using MESSAGE for message transport in the session > model. As a result, that need has disappeared. > > Are there other burning needs? This is one of those things where there may > not be a need now, but it could be a big issue down the road when someone > comes up with a need. > > Notifications for rapid presence changes, like second-granularity geo-loc > updates, might be a need. > > A more radical view is that if you want second-granular presence updates, > you are better off setting up the notifications as a "media stream" as we > are doing for IM, and use just SUBSCRIBE as is to set it up.... I agree. I thought the consensus at Minneapolis was that sub/not wasn't a suitable mechanism for rapid updates, something like an RTP payload was more appropriate. James Undery _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 12:29:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26944 for ; Thu, 23 Aug 2001 12:29:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12437; Thu, 23 Aug 2001 12:15:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12407 for ; Thu, 23 Aug 2001 12:15:01 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26700 for ; Thu, 23 Aug 2001 12:13:43 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.156]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7NGDjrN024905; Thu, 23 Aug 2001 12:13:45 -0400 (EDT) Message-ID: <3B852BE8.284F1CAD@dynamicsoft.com> Date: Thu, 23 Aug 2001 12:14:32 -0400 From: Anders Kristensen X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'sip@ietf.org'" Subject: Re: [Sip] Open Issue #146: Re-use disabled streams References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit The idea of identifying m= streams using an explicit id rather than position in the session description is very old. It seems much better but is obviously backwards incompatible. Reusing disabled streams seems more likely to be work with existing clients and so (still) appears to be preferable. Anders Jonathan Rosenberg wrote: > > Issue: > > Bis currently specifies that if a client disables a media stream (by setting > its port to zero), it cannot remove that stream from the SDP. As such, a UA > which constantly adds/removes media streams will cause the SDP to > continually grow, and never shrink. You definitely cannot remove them (since > the ordering is needed to match up streams between the offer/answer), but it > can work for a client to re-use a disabled stream. That is, when it wants to > add a new stream, it uses the "placeholder" held by the disabled stream. So, > instead of adding a new m line, the disabled m line is replaced with the m > line of the stream you want to add. > > This works because there is never any confusion about which streams > correspond to which. Think of the sequence of m lines in an SDP as a TDM > system, with each stream a "channel". Streams in the offer and answer are > correlated when they sit in the same channel. Once a stream is in a channel, > it can't move to another one, since then you lose correlation. When a stream > is disabled, its channel becomes empty. You can then insert a new stream > into that channel later on, and its clear that this is a new one (because it > replaces a disabled stream). > > So, the question is this: do we allow reuse of disabled streams in this > fashion? > > Points of discussion: > > Why do this at all? The only real reason is savings of bandwidth, since you > can reduce the size of the SDP. This is not a very common case for general > usage. However, the 3gpp guys are thinking about having the proxy disable > streams (egads!) based on some network policy about what codecs to use. They > don't want to be carrying around these zeroed out media streams. However, > our recommended approach with issues like this has been compression (ala the > signaling compression work in rohc). These streams will likely be compressed > very well, so the overhead may be moot. > > Gonzalo pointed out that an alternative is to use FID, since that could > provide a way to correlate the streams. In that case, you can remove > disabled streams altogether if they can be correlated. However, it wasn't > clear that FID actually allows for correlation of streams between offer and > answer. Rather, its meant for association of streams within the same SDP. > More investigation was needed. > > Proposal: > > There was no concrete proposal yet. My leaning is to disallow reuse, and > stick with what we have. > > Comments? > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 13:05:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27394 for ; Thu, 23 Aug 2001 13:05:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13454; Thu, 23 Aug 2001 12:43:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA13421 for ; Thu, 23 Aug 2001 12:43:54 -0400 (EDT) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27098 for ; Thu, 23 Aug 2001 12:42:38 -0400 (EDT) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA19296; Thu, 23 Aug 2001 12:43:56 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3+Sun/8.9.3) with ESMTP id MAA06797; Thu, 23 Aug 2001 12:43:50 -0400 (EDT) Message-ID: <3B85573F.A07C6FBF@cs.columbia.edu> Date: Thu, 23 Aug 2001 12:19:27 -0700 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'eburger@snowshore.com'" , SIP List Subject: Re: [Sip] Issue #113, wrt Content Sequencing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit While an *average* rate of > 1/RTT probably calls for a real transport protocol, it would be really nice to be able to send an occasional message with a shorter spacing, particularly given the loss case (i.e., where it could be seconds before the answer comes back, thus delaying the second message). Thus, I agree with Jonathan, that dumping this feature could get us into trouble later. The increase in protocol complexity seems close to zero and the increase in implementation complexity modest. Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Tuesday, August 07, 2001 6:14 AM > > To: SIP List > > Subject: [Sip] Issue #113, wrt Content Sequencing > > > > > > On the one hand, I would love to find a generic mechanism for > > ordering and > > detecting loss in overlapped non-INVITE content. However, we > > hashed over > > this issue in the SIP-events discussion. Namely, content > > sequencing and > > recovery is inherently content-specific. Thus I would propose Strict > > Sequencing (if needed) in the content, as Jonathan originally > > proposed. > > I think the first question we need to ask is whether we even want to solve > the problem of overlapping non-INVITE. > > One of the bigger motivating factors was the MESSAGE method. However, simple > has converged upon NOT using MESSAGE for message transport in the session > model. As a result, that need has disappeared. > > Are there other burning needs? This is one of those things where there may > not be a need now, but it could be a big issue down the road when someone > comes up with a need. > > Notifications for rapid presence changes, like second-granularity geo-loc > updates, might be a need. > > A more radical view is that if you want second-granular presence updates, > you are better off setting up the notifications as a "media stream" as we > are doing for IM, and use just SUBSCRIBE as is to set it up.... > > THoughts? Lets resolve this. > > -Jonathan R. > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 13:26:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27692 for ; Thu, 23 Aug 2001 13:26:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14266; Thu, 23 Aug 2001 13:13:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14237 for ; Thu, 23 Aug 2001 13:13:18 -0400 (EDT) Received: from daimanta.ascend.com (daimanta.bos.ascend.com [152.148.40.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27493 for ; Thu, 23 Aug 2001 13:12:01 -0400 (EDT) Received: from reddog.casc.com (reddog.ascend.com [152.148.100.22]) by daimanta.ascend.com (8.9.3/8.9.3) with ESMTP id NAA29456; Thu, 23 Aug 2001 13:12:49 -0400 (EDT) Received: from lucent.com ([152.148.210.204]) by reddog.casc.com (8.8.8+Sun/8.8.8) with ESMTP id MAA29691; Thu, 23 Aug 2001 12:45:14 -0400 (EDT) Message-ID: <3B853990.92A26E8F@lucent.com> Date: Thu, 23 Aug 2001 13:12:48 -0400 From: Kim Liu Organization: Lucent Technologies X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'sip@ietf.org'" Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [deleted] > > So, here is the first. Issue #7: CANCEL for non-INVITE. > > Issue description: Currently, bis allows for CANCEL for all methods, not > just INVITE. This made sense way back when, before we recognized that all > non-INVITE methods really need to complete immediately. However, if all > INVITEs are supposed to complete right away (i.e., the server immediately > generates a response, and shouldn't wait for user input), the usage of > CANCEL becomes a race condition. Whether the response is cancelled or not > depends on whether or not the CANCEL beats the server's generation of a > response. The argument has been made, and its a good one, that specifying a > mechanism thats ALWAYS a race condition is futile. > > What is the cost? Some have argued that its nothing, since its harder to > special case INVITE. However, I suspect there is a real cost on the server > side. It now must have logic that tells it how to undo anything it might > have done for a particular method before sending the final response. Yuck. > > The one point of contention at the meeting was whether CANCEL is useful for > stopping timed-out transactions. That is, I send a SUBSCRIBE, and never get > a response. After 16s (or whatever it is), I send CANCEL to terminate it, > because I never got a response. However, I think that this is not a good > argument. Since the server is supposed to respond immediately anway, sending > CANCEL won't help trigger a response, since there is clearly some big error > thats preventing the response from coming anyway. Others argued that errors > can happen for lots of reasons, so perhaps the CANCEL will help. > > My proposal was that we should deprecate CANCEL for non-INVITE. The benefit > is not even quantifiable, at best, and the cost seems high. Of course, for > backwards compatibility, a server should not complain if it gets a CANCEL > for a non-invite, just respond 200 OK (or even 405 is OK) and thats it. It > should have responded to the request anyway. > > There was mild consensus on this, but some key participants disagreed. > Please, speak up and lets resolve this. Limit CANCEL for INVITE only. Trying to handle CANCELs for all/arbitrary methods otherwise is going to be prohibitively complex task -- it will end up as a bunch of special cases -- i.e. if CANCEL is allowed for all methods, how do you treat a CANCEL for a CANCEL? A CANCEL for a BYE? A CANCEL for an ACK? That's ridiculous -- you automatically end up with more special cases for handling CANCEL to handle CANCELs for methods where CANCEL makes no sense. It's a case of confusing an application specific signal (trying to stop a service/application started by another method) with a generic procotol level signal (CANCEL). Since only INVITE and BYE can start/change/stop a call, every other method almost has to be an application or service specific invocation, rather than session affecting -- if this assumption is made, then CANCEL, as a session level signal, is not apropriate for halting a service. Kim _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 13:55:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28131 for ; Thu, 23 Aug 2001 13:55:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15025; Thu, 23 Aug 2001 13:40:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14994 for ; Thu, 23 Aug 2001 13:40:45 -0400 (EDT) Received: from daimanta.ascend.com (daimanta.bos.ascend.com [152.148.40.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27887 for ; Thu, 23 Aug 2001 13:39:28 -0400 (EDT) Received: from reddog.casc.com (reddog.ascend.com [152.148.100.22]) by daimanta.ascend.com (8.9.3/8.9.3) with ESMTP id NAA29650; Thu, 23 Aug 2001 13:40:16 -0400 (EDT) Received: from lucent.com ([152.148.210.204]) by reddog.casc.com (8.8.8+Sun/8.8.8) with ESMTP id NAA00587; Thu, 23 Aug 2001 13:12:39 -0400 (EDT) Message-ID: <3B853FFB.C417F160@lucent.com> Date: Thu, 23 Aug 2001 13:40:11 -0400 From: Kim Liu Organization: Lucent Technologies X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'sip@ietf.org'" Subject: Re: [Sip] Open Issue #146: Re-use disabled streams References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [deleted] > So, the question is this: do we allow reuse of disabled streams in this > fashion? [snipped] > Proposal: > > There was no concrete proposal yet. My leaning is to disallow reuse, and > stick with what we have. > > Comments? My inclination is to allow reuse, but I don't think it can be done. Particularly given the restriction on dynamic PT reuse in issue #23. Since the INVITE with SDP is used for recovery, reusing/rewriting an old media stream slot in the SDP might erase/hide information about the previous state of the call (which dynamic PTs have been used, plus any endpoint, media, or application specific information associated with the closed media stream) though I am unaware of any application which is doing this today. Unfortunately, since the INVITE/200 + SDP is used for call recovery, that reuse will have to be avoided in order to maintain a full history/state of the call in case recovery is necessary. Kim _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 14:14:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28560 for ; Thu, 23 Aug 2001 14:14:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15355; Thu, 23 Aug 2001 13:59:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15325 for ; Thu, 23 Aug 2001 13:59:40 -0400 (EDT) Received: from daimanta.ascend.com (daimanta.bos.ascend.com [152.148.40.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28254 for ; Thu, 23 Aug 2001 13:58:23 -0400 (EDT) Received: from reddog.casc.com (reddog.ascend.com [152.148.100.22]) by daimanta.ascend.com (8.9.3/8.9.3) with ESMTP id NAA29841; Thu, 23 Aug 2001 13:59:12 -0400 (EDT) Received: from lucent.com ([152.148.210.204]) by reddog.casc.com (8.8.8+Sun/8.8.8) with ESMTP id NAA01305; Thu, 23 Aug 2001 13:31:38 -0400 (EDT) Message-ID: <3B85446E.DC5ACD8@lucent.com> Date: Thu, 23 Aug 2001 13:59:10 -0400 From: Kim Liu Organization: Lucent Technologies X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'sip@ietf.org'" Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Issue: > > A and B are in a SIP call. A re-invite's B, but includes no SDP in the > INVITE. This triggers B to generate an offer, in the 2xx. A doesn't like the > offer. How does it reject it? When an offer is sent in an INVITE, it is > easily rejected with a 488. But, when the offer is sent in a 2xx, its not > easy to reject. For an initial INVITE, you reject it by ACKing and then > sending BYE. Thats not great, but works OK. For a re-INVITE, you don't want > to BYE, you want to get back to the last-known-good SDP. > > So, the issue is: what to do? > > Points of discussion: > > One proposal is to ACK the 2xx, disabling all the streams. THen, re-INVITE > with the old SDP, in an attempt to re-instantiate it. However, this > re-INVITE may fail. Also, it results in a transitional period where you have > no media, which is not good. > > Another, more outlandish proposal, is to define a NACK that works like ACK, > but says "nah, forget about it". This isn't backwards compatible though. > > Dave Oran had suggested that you need something, somewhere, to say "please > go back to where we were before". Whether this is a header in the ACK, or > whether this is in the SDP, it needs to be somewhere. You want to avoid > these transitional periods where the state is bad. You need a way to go > back. > > There seemed to be agreement that this was reasonable, but its not clear how > to do it exactly. More discussion is needed. Mmm. I would probably say it needs to be in the SDP, probably as an attribute. The attribute should indicate what the desire behavior is in failure cases, perhaps on a per media stream basis. The behavior could be to fall back to the previous state, to go on hold pending further renegotiation, or to hang up/send a BYE if the stream cannot be established. (The last might be useful only in a handful of cases.) Having it on a per media stream would allow for re-INVITEs where the audio stream was marked to fall-back if there was a problem with negotiating the audio stream, but for the video stream to go on hold if there was a problem with the video stream. Being able to indicate to go on hold rather than falling back to the previous media stream state might be important in cases where the media stream is going down/changing immediately due to outside reasons, and that trying to re-establish an RTCP stream to the prior state could result in a network unreachable condition -- some endpoints might interpret that as an indication to hang up the call. If the call should be hung up if the new SDP cannot be accepted and because the old one is already known to be no longer useable, then that could be indicated by the explicit "Send BYE" as opposed to the "fall back" or "go on hold." Kim _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 15:22:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29737 for ; Thu, 23 Aug 2001 15:22:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18053; Thu, 23 Aug 2001 15:12:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18024 for ; Thu, 23 Aug 2001 15:12:06 -0400 (EDT) Received: from mail2.intervoice-brite.com (mail2.intervoice-brite.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29549 for ; Thu, 23 Aug 2001 15:10:48 -0400 (EDT) Received: from 172.16.16.64 (gwsmtpsrv.intervoice.com [172.16.16.64]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with SMTP id OAA09549 for ; Thu, 23 Aug 2001 14:16:42 -0500 Received: from bculpepperpc ([151.214.151.122]) by 172.16.16.64; Thu, 23 Aug 2001 14:11:36 -0500 From: "Bert Culpepper" To: "'Kim Liu'" , "'Jonathan Rosenberg'" Cc: Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Thu, 23 Aug 2001 15:11:24 -0400 Message-ID: <001e01c12c07$67643c20$7a97d697@orlando.brite.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <3B85446E.DC5ACD8@lucent.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit How can it happen that B provides an offer that is not acceptable to A provided the UA complies with the first paragraph of B.4 in bis-04? If B does want to change, it should issue the re-INVITE. A can reject this media with a 488 and the session remains as it was. Am I missing something here? (I'll admit, I don't know of a scenario off hand where a UA would re-INVITE without SDP to see what the other side will respond with.) regards, Bert > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > Of Kim Liu > Sent: Thursday, August 23, 2001 1:59 PM > To: Jonathan Rosenberg > Cc: 'sip@ietf.org' > Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx > > > Jonathan Rosenberg wrote: > > > > Issue: > > > > A and B are in a SIP call. A re-invite's B, but includes no > SDP in the > > INVITE. This triggers B to generate an offer, in the 2xx. A > doesn't like the > > offer. How does it reject it? When an offer is sent in an > INVITE, it is > > easily rejected with a 488. But, when the offer is sent in > a 2xx, its not > > easy to reject. For an initial INVITE, you reject it by > ACKing and then > > sending BYE. Thats not great, but works OK. For a > re-INVITE, you don't want > > to BYE, you want to get back to the last-known-good SDP. > > > > So, the issue is: what to do? > > > > Points of discussion: > > > > One proposal is to ACK the 2xx, disabling all the streams. > THen, re-INVITE > > with the old SDP, in an attempt to re-instantiate it. However, this > > re-INVITE may fail. Also, it results in a transitional > period where you have > > no media, which is not good. > > > > Another, more outlandish proposal, is to define a NACK that > works like ACK, > > but says "nah, forget about it". This isn't backwards > compatible though. > > > > Dave Oran had suggested that you need something, somewhere, > to say "please > > go back to where we were before". Whether this is a header > in the ACK, or > > whether this is in the SDP, it needs to be somewhere. You > want to avoid > > these transitional periods where the state is bad. You need > a way to go > > back. > > > > There seemed to be agreement that this was reasonable, but > its not clear how > > to do it exactly. More discussion is needed. > > Mmm. I would probably say it needs to be in the SDP, > probably as an attribute. The attribute should indicate > what the desire behavior is in failure cases, perhaps on > a per media stream basis. The behavior could be to fall > back to the previous state, to go on hold pending further > renegotiation, or to hang up/send a BYE if the stream > cannot be established. (The last might be useful only > in a handful of cases.) > > Having it on a per media stream would allow for > re-INVITEs where the audio stream was marked to > fall-back if there was a problem with negotiating > the audio stream, but for the video stream to > go on hold if there was a problem with the video > stream. > > Being able to indicate to go on hold rather than > falling back to the previous media stream state > might be important in cases where the media > stream is going down/changing immediately due > to outside reasons, and that trying to re-establish > an RTCP stream to the prior state could result > in a network unreachable condition -- some > endpoints might interpret that as an indication > to hang up the call. If the call should be > hung up if the new SDP cannot be accepted > and because the old one is already known to > be no longer useable, then that could be indicated > by the explicit "Send BYE" as opposed to the > "fall back" or "go on hold." > > Kim > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 15:22:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29752 for ; Thu, 23 Aug 2001 15:22:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18251; Thu, 23 Aug 2001 15:16:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18220 for ; Thu, 23 Aug 2001 15:16:19 -0400 (EDT) Received: from permissiononly.com (permissiononly.com [216.133.253.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29621 for ; Thu, 23 Aug 2001 15:15:01 -0400 (EDT) Received: (from mailman@localhost) by permissiononly.com (8.9.3/8.9.3) id LAA18020; Thu, 23 Aug 2001 11:36:54 -0700 Date: Thu, 23 Aug 2001 11:36:54 -0700 Message-Id: <200108231836.LAA18020@permissiononly.com> Content-type: text/html From: tpinkus@vitalstream.cc To: sip@ietf.org Subject: [Sip] Add Streaming Media to your Web Site Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org VitalStream
 
Now Showing
Free Streaming Kit
You Can Add Streaming Media to
Your Company's Web Site

Streaming Media is Easier Than You Think

I invite you to learn more about streaming media by reading our Free Streaming Kit on Live Streaming with Windows Media. It contains a step-by-step tutorial on how to stream media over the Internet with Windows Media technologies.

VitalStream specializes in customized streaming and hosting solutions for small to medium sized businesses.

VitalStream Delivers...

- Live and On-Demand Streaming
- Pay-Per-View Solutions
- 24 x 7 Live Technical Support
- 99.7% Guaranteed Uptime
- And More...

These companies use us
for their streaming needs.

Call today to see what
VitalStream can do for
your company's web site

 Windows Media Service Provider

Tom Pinkus
Account Representative
(800) 254-7554 x2038
tpinkus@vitalstream.cc

VitalStream
 


Click here if you received this message in error.

Microsoft, Windows Media, and the Windows Logo are trademarks or registered
trademarks of Microsoft Corporation in the United States and/or other countries.

_______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 15:39:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00005 for ; Thu, 23 Aug 2001 15:39:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18609; Thu, 23 Aug 2001 15:28:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18580 for ; Thu, 23 Aug 2001 15:28:31 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29796 for ; Thu, 23 Aug 2001 15:27:13 -0400 (EDT) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7NJRfB26126; Thu, 23 Aug 2001 15:27:41 -0400 (EDT) Received: from cisco.com (rtp-xdm2.cisco.com [64.102.17.79]) by dingdong.cisco.com (Mirapoint) with ESMTP id ABH13479 (AUTH shbhatna); Thu, 23 Aug 2001 15:27:59 -0400 (EDT) Message-ID: <3B85593B.603B7D16@cisco.com> Date: Thu, 23 Aug 2001 15:27:55 -0400 From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Kim Liu CC: Jonathan Rosenberg , "'sip@ietf.org'" Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE References: <3B853990.92A26E8F@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Kim Liu wrote: My take is that although CANCEL for non-INVITE is academic, it should be allowed. Main reason is to not make special checks in the state machine about original method and this CANCEL. > > Limit CANCEL for INVITE only. Trying to handle CANCELs > for all/arbitrary methods otherwise is going to be prohibitively > complex task -- it will end up as a bunch of special > cases -- i.e. if CANCEL is allowed for all methods, > how do you treat a CANCEL for a CANCEL? A CANCEL for > a BYE? A CANCEL for an ACK? That's ridiculous -- > you automatically end up with more special cases for > handling CANCEL to handle CANCELs for methods where > CANCEL makes no sense. > > It's a case of confusing an application specific > signal (trying to stop a service/application started > by another method) with a generic procotol level > signal (CANCEL). Since only INVITE and BYE can > start/change/stop a call, every other method almost > has to be an application or service specific > invocation, rather than session affecting -- if > this assumption is made, then CANCEL, as a session > level signal, is not apropriate for halting a > service. > > Kim > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 15:53:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00275 for ; Thu, 23 Aug 2001 15:53:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19658; Thu, 23 Aug 2001 15:47:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19569 for ; Thu, 23 Aug 2001 15:47:01 -0400 (EDT) Received: from daimanta.ascend.com (daimanta.bos.ascend.com [152.148.40.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00135 for ; Thu, 23 Aug 2001 15:45:43 -0400 (EDT) Received: from reddog.casc.com (reddog.ascend.com [152.148.100.22]) by daimanta.ascend.com (8.9.3/8.9.3) with ESMTP id PAA00956; Thu, 23 Aug 2001 15:46:32 -0400 (EDT) Received: from lucent.com ([152.148.210.204]) by reddog.casc.com (8.8.8+Sun/8.8.8) with ESMTP id PAA05249; Thu, 23 Aug 2001 15:18:57 -0400 (EDT) Message-ID: <3B855D97.9E640C10@lucent.com> Date: Thu, 23 Aug 2001 15:46:31 -0400 From: Kim Liu Organization: Lucent Technologies X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar CC: Jonathan Rosenberg , "'sip@ietf.org'" Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE References: <3B853990.92A26E8F@lucent.com> <3B85593B.603B7D16@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit What special check? if (cancel.method != INVITE) do_error_respose(); You would have to make checks in any case to validate the CANCEL from an authentication/authorization level, to see if the method the CANCEL was referring to actually existed, etc. There already have to be places in the message processing where a CANCEL can be rejected due to various reasons. Or, inversely, if CANCEL is allowed for non-INVITEs, then you have to make a special check to see if the original method was an INVITE, to send back the 487 until receiving an ACK, etc. Shail Bhatnagar wrote: > > Kim Liu wrote: > > My take is that although CANCEL for non-INVITE is academic, > it should be allowed. Main reason is to not make special checks > in the state machine about original method and this CANCEL. > > > > > Limit CANCEL for INVITE only. Trying to handle CANCELs > > for all/arbitrary methods otherwise is going to be prohibitively > > complex task -- it will end up as a bunch of special > > cases -- i.e. if CANCEL is allowed for all methods, > > how do you treat a CANCEL for a CANCEL? A CANCEL for > > a BYE? A CANCEL for an ACK? That's ridiculous -- > > you automatically end up with more special cases for > > handling CANCEL to handle CANCELs for methods where > > CANCEL makes no sense. > > > > It's a case of confusing an application specific > > signal (trying to stop a service/application started > > by another method) with a generic procotol level > > signal (CANCEL). Since only INVITE and BYE can > > start/change/stop a call, every other method almost > > has to be an application or service specific > > invocation, rather than session affecting -- if > > this assumption is made, then CANCEL, as a session > > level signal, is not apropriate for halting a > > service. > > > > Kim > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 16:39:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01239 for ; Thu, 23 Aug 2001 16:39:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21664; Thu, 23 Aug 2001 16:32:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21638 for ; Thu, 23 Aug 2001 16:32:27 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01062 for ; Thu, 23 Aug 2001 16:31:08 -0400 (EDT) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id UAA27315; Thu, 23 Aug 2001 20:32:27 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id UAA05149; Thu, 23 Aug 2001 20:32:26 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <3RFXVH09>; Thu, 23 Aug 2001 14:32:26 -0600 Message-ID: <17052388D394D411803900508BDFFAF601B36EC6@n0214idc1.oss.level3.com> To: jdrosen@dynamicsoft.com Cc: hurtig@iex.com, sip@ietf.org, Rich.Terpstra@Level3.com, Ken.Fischer@Level3.com Subject: RE: [SIP] Killing hung media streams Date: Thu, 23 Aug 2001 14:32:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > My recommendation is this. If a UA is in a call, and begins getting ICMP > errors on a media stream, and wishes to continue with the call, it SHOULD > send a re-INVITE on that leg. > > As an orthogonal issue, if a UAC receives a 481 to a mid-call re-INVITE, it > SHOULD tear down the call by sending a BYE. This sounds great. In addition, a recommedation for the case where a UA begins getting ICMP errors and does not wish to continue the call should also be noted. Sending a BYE in this case as well seems consistent with your position below. If there is no objection, can we get modified language in the bis indicating these behaviors? John Hearty Level 3 Communications, Inc. > -----Original Message----- > From: Doug Hurtig [mailto:hurtig@iex.com] > Sent: Wednesday, August 22, 2001 5:44 PM > To: sip@ietf.org > Subject: RE: [SIP] Killing hung media streams > > > Hi, > > Why must the UAC send a bye when a 481 is received? I > thought that the > 481 implies that the call leg is terminated. Section 15.5 > states that > "A UAC receiving a 481 response for any mid-call request > (INVITE or otherwise) > MUST consider the call terminated." Thats the problem. I think this text is wrong. It should send a BYE, and then consider the call terminated as a result. Why? Well, we have a general rule that a non-2xx response to a re-INVITE does not mean the call is dead. Only BYE terminates a call. I'd like to keep that rule, since it provides a single, consistent way for everyone to say/know whether the call is up or down. I feel very strongly about this one. Having multiple ways of signaling that a call is down is very bad, IMHO. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 18:45:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03348 for ; Thu, 23 Aug 2001 18:45:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26118; Thu, 23 Aug 2001 18:35:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26089 for ; Thu, 23 Aug 2001 18:35:54 -0400 (EDT) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03226 for ; Thu, 23 Aug 2001 18:34:36 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id WAA24552 for ; Thu, 23 Aug 2001 22:35:55 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001082315344606471 for ; Thu, 23 Aug 2001 15:34:46 -0700 Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 15:35:55 -0700 Message-ID: From: "Padhye, Chinmay" To: "'sip@ietf.org'" Date: Thu, 23 Aug 2001 15:35:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] The REFER Method - Link to the draft. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, In the draft, titled - 'SIP Call Control - Transfer draft-ietf-sip-cc-transfer-05' there is a reference to another draft for 'The REFER Method' (reference number 3). [3] Sparks, R., "The REFER Method", draft-ietf-sip-refer-00 (work in progress), July 2001. I could not locate this draft in the IETF web page. Can anyone please email me a link to this draft. Thanks, Chinmay _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 19:09:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03676 for ; Thu, 23 Aug 2001 19:09:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26648; Thu, 23 Aug 2001 18:57:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA26623 for ; Thu, 23 Aug 2001 18:57:26 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03485 for ; Thu, 23 Aug 2001 18:56:10 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.2) id f7NMvQ253309; Thu, 23 Aug 2001 18:57:27 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Padhye, Chinmay'" , Subject: RE: [Sip] The REFER Method - Link to the draft. Date: Thu, 23 Aug 2001 18:56:51 -0400 Message-ID: <008201c12c26$e5fff1e0$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-refer-00.txt > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf > Of Padhye, > Chinmay > Sent: Thursday, August 23, 2001 6:36 PM > To: 'sip@ietf.org' > Subject: [Sip] The REFER Method - Link to the draft. > > > Hello, > > In the draft, titled - 'SIP Call Control - Transfer > draft-ietf-sip-cc-transfer-05' there is a reference to > another draft for > 'The REFER Method' (reference number 3). > > [3] Sparks, R., "The REFER Method", draft-ietf-sip-refer-00 (work in > progress), July 2001. > > I could not locate this draft in the IETF web page. Can anyone > please email me a link to this draft. > > Thanks, > > Chinmay > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 23 21:18:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04831 for ; Thu, 23 Aug 2001 21:18:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29871; Thu, 23 Aug 2001 21:04:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29844 for ; Thu, 23 Aug 2001 21:04:14 -0400 (EDT) Received: from baucis.sc.intel.com (ns3.intel.com [143.183.152.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04708 for ; Thu, 23 Aug 2001 21:02:57 -0400 (EDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id BAA10175 for ; Fri, 24 Aug 2001 01:03:44 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 24 Aug 2001 01:03:44 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 18:03:43 -0700 Message-ID: From: "Padhye, Chinmay" To: "'sip@ietf.org'" Date: Thu, 23 Aug 2001 18:03:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] SIP Caller Preferences - Does registration contain 'Priority' inf ormation? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, In section 6.4.2 in the caller preferences draft, draft-ietf-sip-callerprefs-04.txt the third paragraph mentions - 'A contact entry may contain a priority member'. But the 'Priority' header is allowed only in the INVITE message (per table 5 in bis 04). So how will a registrar get a contact entry with a priority member? Should table 5 in bis 04 be updated to allow Priority member field for REGISTER? Or am I missing something? Regards, Chinmay _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 03:39:01 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26852 for ; Fri, 24 Aug 2001 03:39:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19947; Fri, 24 Aug 2001 03:20:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19914 for ; Fri, 24 Aug 2001 03:20:46 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26732 for ; Fri, 24 Aug 2001 03:19:29 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7O7JQrN000103; Fri, 24 Aug 2001 03:19:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 03:20:15 -0400 Message-ID: From: Jonathan Rosenberg To: "'Shail Bhatnagar'" , Kim Liu Cc: Jonathan Rosenberg , "'sip@ietf.org'" Subject: RE: [Sip] Open Issue #7: CANCEL for non-INVITE Date: Fri, 24 Aug 2001 03:20:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Shail Bhatnagar [mailto:shbhatna@cisco.com] > Sent: Thursday, August 23, 2001 3:28 PM > To: Kim Liu > Cc: Jonathan Rosenberg; 'sip@ietf.org' > Subject: Re: [Sip] Open Issue #7: CANCEL for non-INVITE > > > Kim Liu wrote: > > My take is that although CANCEL for non-INVITE is academic, > it should be allowed. Main reason is to not make special checks > in the state machine about original method and this CANCEL. This argument would be true if the cost of the CANCEL for non-INVITE was otherwise nil. But, thats not true. What happens if the CANCEL actually beats the server to sending the final response? Now, you have to actually cancel it. How does one CANCEL a SUBSCRIBE? A NOTIFY? An OPTIONS? Each method would need special code. Furthermore, since its usage is always a race condition, an entity that sends CANCEL would always need to handle the case where the cancel works and doesn't work. Thus, its extra work to do this. Note that I have stipulted that for backwards compatibility, if you get a CANCEL for non-INVITE, you still respond to it, but otherwise do nothing. In that sense, its "allowed", but we explicitly define it as a no-op. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 03:39:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26873 for ; Fri, 24 Aug 2001 03:39:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19814; Fri, 24 Aug 2001 03:15:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA19784 for ; Fri, 24 Aug 2001 03:15:48 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26683 for ; Fri, 24 Aug 2001 03:14:30 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7O7DvrN000088; Fri, 24 Aug 2001 03:13:57 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 03:14:46 -0400 Message-ID: From: Jonathan Rosenberg To: "'John.Hearty@Level3.com'" , Jonathan Rosenberg Cc: hurtig@iex.com, sip@ietf.org, Rich.Terpstra@Level3.com, Ken.Fischer@Level3.com Subject: RE: [SIP] Killing hung media streams Date: Fri, 24 Aug 2001 03:14:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: John.Hearty@Level3.com [mailto:John.Hearty@Level3.com] > Sent: Thursday, August 23, 2001 4:32 PM > To: jdrosen@dynamicsoft.com > Cc: hurtig@iex.com; sip@ietf.org; Rich.Terpstra@Level3.com; > Ken.Fischer@Level3.com > Subject: RE: [SIP] Killing hung media streams > > > > > My recommendation is this. If a UA is in a call, and begins > getting ICMP > > errors on a media stream, and wishes to continue with the > call, it SHOULD > > send a re-INVITE on that leg. > > > > As an orthogonal issue, if a UAC receives a 481 to a > mid-call re-INVITE, > it > > SHOULD tear down the call by sending a BYE. > > > This sounds great. In addition, a recommedation for the case > where a UA > begins getting ICMP errors and does not wish to continue the > call should > also be noted. Sending a BYE in this case as well seems > consistent with > your position below. Yes, thats fine. But, I want the text to be clear that this is only if you really have some other reason for not continuing. A triggered re-INVITE on ICMP errors does wonders for reconstituting state and providing fault tolerance. Most of the times, that is what you want. > If there is no objection, can we get > modified language > in the bis indicating these behaviors? Fine by me. Speak up folks, or the text is going in.... -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 03:42:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26912 for ; Fri, 24 Aug 2001 03:42:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20059; Fri, 24 Aug 2001 03:26:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20028 for ; Fri, 24 Aug 2001 03:26:21 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26762 for ; Fri, 24 Aug 2001 03:25:03 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7O7OvrN000121; Fri, 24 Aug 2001 03:24:57 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 03:25:46 -0400 Message-ID: From: Jonathan Rosenberg To: "'Gonzalo Camarillo'" , Sean Olson Cc: Jonathan Rosenberg , "'Colin Perkins'" , "'sip@ietf.org'" , "'mmusic'" Subject: RE: [Sip] Re: SDP hold Date: Fri, 24 Aug 2001 03:25:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, August 23, 2001 10:32 AM > To: Sean Olson (EUS) > Cc: 'Jonathan Rosenberg'; 'Colin Perkins'; 'sip@ietf.org'; 'mmusic' > Subject: Re: [Sip] Re: SDP hold > > > > 5) XXX: no RTP, no RTCP ??? > > > > Then what is used to specify the fifth item > > (no RTP, no RTCP)? > > This is currently defined by setting the port number to zero. > That is, I > offer you a particular media stream and you set its port to > zero in the > 200 OK. It means that no RTP and no RTCP will be sent over that media > stream. Well, this is a little bit different. Port zero means "tear down this stream". This would result, for example, in the closure of any windows that were popped up for video rendering of the stream. I think Sean's case is where we neither send RTP/RTCP, but the stream is only temporarily suspended and can be revived. A better question, is whether we really need this additional case. I'd rather limit them to things we really need. > > This brings me to related topic: > > Right now, once you have answer with port=zero, you cannot re-use that > stream during the session. That is, every re-INVITE you send will > contain that media line with the port set to zero, but media > will never > flow to it. > > It has been brought up (by 3GPP among others) that it might > be useful to > be able to re-use that stream in a future. If I want to add a > new media > stream to the session, I can use that media line by changing the port > number to a non-zero value in a re-INVITE. > > Well, I am triggering a new discussion here (I would like to see > opinions on this), but I believe that the semantics of the inactive > attribute are pretty clear. Hmm, I though I had sent out an email on this open issue as well.... I'll resend if I don't see it in the archives. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 09:23:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04437 for ; Fri, 24 Aug 2001 09:23:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28427; Fri, 24 Aug 2001 09:10:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28399 for ; Fri, 24 Aug 2001 09:10:06 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04226 for ; Fri, 24 Aug 2001 09:08:48 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7ODA3K26391; Fri, 24 Aug 2001 15:10:03 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.33]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7ODA2510121; Fri, 24 Aug 2001 16:10:02 +0300 (EET DST) Message-ID: <3B865220.A3E171C5@lmf.ericsson.se> Date: Fri, 24 Aug 2001 16:09:52 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Gonzalo Camarillo'" , Sean Olson , "'Colin Perkins'" , "'sip@ietf.org'" , "'mmusic'" Subject: Re: [Sip] Re: SDP hold References: Content-Type: multipart/mixed; boundary="------------6B0BF617707EAF3E476CFCB9" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------6B0BF617707EAF3E476CFCB9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I think it would be a good idea to bring this question to the Megaco mailing list. There are lots of people working on Media Gateways there, so maybe they have some kind of solution for this. I can write down a few lines, and also CC the mail to the SIP list (since I guess most of us aren't on the Megaco list...). Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Thursday, August 23, 2001 10:32 AM > > To: Sean Olson (EUS) > > Cc: 'Jonathan Rosenberg'; 'Colin Perkins'; 'sip@ietf.org'; 'mmusic' > > Subject: Re: [Sip] Re: SDP hold > > > > > > > 5) XXX: no RTP, no RTCP ??? > > > > > > Then what is used to specify the fifth item > > > (no RTP, no RTCP)? > > > > This is currently defined by setting the port number to zero. > > That is, I > > offer you a particular media stream and you set its port to > > zero in the > > 200 OK. It means that no RTP and no RTCP will be sent over that media > > stream. > > Well, this is a little bit different. Port zero means "tear down this > stream". This would result, for example, in the closure of any windows that > were popped up for video rendering of the stream. I think Sean's case is > where we neither send RTP/RTCP, but the stream is only temporarily suspended > and can be revived. A better question, is whether we really need this > additional case. I'd rather limit them to things we really need. > > > > > This brings me to related topic: > > > > Right now, once you have answer with port=zero, you cannot re-use that > > stream during the session. That is, every re-INVITE you send will > > contain that media line with the port set to zero, but media > > will never > > flow to it. > > > > It has been brought up (by 3GPP among others) that it might > > be useful to > > be able to re-use that stream in a future. If I want to add a > > new media > > stream to the session, I can use that media line by changing the port > > number to a non-zero value in a re-INVITE. > > > > Well, I am triggering a new discussion here (I would like to see > > opinions on this), but I believe that the semantics of the inactive > > attribute are pretty clear. > > Hmm, I though I had sent out an email on this open issue as well.... I'll > resend if I don't see it in the archives. > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------6B0BF617707EAF3E476CFCB9 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------6B0BF617707EAF3E476CFCB9-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 09:24:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04468 for ; Fri, 24 Aug 2001 09:24:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28568; Fri, 24 Aug 2001 09:14:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28531 for ; Fri, 24 Aug 2001 09:14:08 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04295; Fri, 24 Aug 2001 09:12:49 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7ODE7K28738; Fri, 24 Aug 2001 15:14:08 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.33]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7ODE7510307; Fri, 24 Aug 2001 16:14:07 +0300 (EET DST) Message-ID: <3B865316.8CAFB6CC@lmf.ericsson.se> Date: Fri, 24 Aug 2001 16:13:58 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: megaco@ietf.org CC: sip@ietf.org Content-Type: multipart/mixed; boundary="------------81406CA90037E90BB293CC6F" Subject: [Sip] Call hold using inactive mode Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------81406CA90037E90BB293CC6F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, There is a discussion on the SIP mailing list about call holding, and the possible use of the "inactive" mode. The question is: does inactive only put the RTP stream on hold, or both the RTP and the RTCP? And, is there any way to define if you want to put only the RTP, or both the RTP and the RTCP, streams on hold? Regards, Christer Holmberg Ericsson Finland --------------81406CA90037E90BB293CC6F Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------81406CA90037E90BB293CC6F-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 10:03:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05242 for ; Fri, 24 Aug 2001 10:03:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29699; Fri, 24 Aug 2001 09:56:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29663 for ; Fri, 24 Aug 2001 09:56:24 -0400 (EDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05111; Fri, 24 Aug 2001 09:55:06 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7ODtWp03842; Fri, 24 Aug 2001 09:55:32 -0400 (EDT) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.ca.nortel.com; Fri, 24 Aug 2001 09:55:32 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 09:55:35 -0400 Message-ID: <28560036253BD41191A10000F8BCBD110514FA4C@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Christer Holmberg'" , megaco@ietf.org Cc: sip@ietf.org Subject: RE: [Sip] Call hold using inactive mode Date: Fri, 24 Aug 2001 09:55:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12CA4.70F33410" X-Orig: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12CA4.70F33410 Content-Type: text/plain; charset="iso-8859-1" Certainly something I never thought about. I should point out that inactive mode is typically used at the start of a Megaco call flow, to prevent cut-through of the caller before charging has begun. If RTCP is running anyway, we have to think about any possibilities for fraud. -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Friday, August 24, 2001 9:14 AM To: megaco@ietf.org Cc: sip@ietf.org Subject: [Sip] Call hold using inactive mode Hi, There is a discussion on the SIP mailing list about call holding, and the possible use of the "inactive" mode. The question is: does inactive only put the RTP stream on hold, or both the RTP and the RTCP? And, is there any way to define if you want to put only the RTP, or both the RTP and the RTCP, streams on hold? Regards, Christer Holmberg Ericsson Finland ------_=_NextPart_001_01C12CA4.70F33410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] Call hold using inactive mode

Certainly something I never thought about.  I = should point out that inactive mode is typically used at the start of a = Megaco call flow, to prevent cut-through of the caller before charging = has begun.  If RTCP is running anyway, we have to think about any = possibilities for fraud.

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
Sent: Friday, August 24, 2001 9:14 AM
To: megaco@ietf.org
Cc: sip@ietf.org
Subject: [Sip] Call hold using inactive mode



Hi,

There is a discussion on the SIP mailing list about = call holding, and
the possible use of the "inactive" = mode.

The question is: does inactive only put the RTP = stream on hold, or both
the RTP and the RTCP? And, is there any way to = define if you want to put
only the RTP, or both the RTP and the RTCP, streams = on hold?

Regards,

Christer Holmberg
Ericsson Finland

------_=_NextPart_001_01C12CA4.70F33410-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 10:06:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05272 for ; Fri, 24 Aug 2001 10:06:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29833; Fri, 24 Aug 2001 09:59:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29801 for ; Fri, 24 Aug 2001 09:59:49 -0400 (EDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05148 for ; Fri, 24 Aug 2001 09:58:31 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 9A06D1E09A; Fri, 24 Aug 2001 09:59:50 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA19093; Fri, 24 Aug 2001 09:59:29 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id JAA42460; Fri, 24 Aug 2001 09:59:57 -0400 (EDT) Date: Fri, 24 Aug 2001 09:59:57 -0400 (EDT) Message-Id: <200108241359.JAA42460@fish.research.att.com> To: sip@ietf.org Cc: rfairlie@nuera.com, jdrosen@dynamicsoft.com Subject: [Sip] Re: Weakness in SIP offer/answer model Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org The offer/counter-offer/answer model also appears in the manyfolks draft. The specific case where it is essential is when the UAS reduces the preconditions requested by the UAC - the UAC needs a mechanism to drop a media stream from the session if the UAS will not agree to all of the preconditions for it. So an SDP is included in the PRACK in this case. There are at least two other situations where the offer/counter-offer/ answer model is a big improvement. If the UAC and UAS both support a large number of codecs, but with very few in common, it may take a while to find one in common. If the UAC sends an initial SDP with a single codec, which is not supported by UAS, the session would fail and the UAC would have to re-try with a different codec. This is true even if the UAS responds with an alternative in its answer SDP. The three-way handshake allows the UAC to insert _all_ of its supported codecs in the initial SDP, the UAS to indicate those it supports as well, and the UAC to then pick one of the common ones. Single round-trip codec negotiation, and minimal impact on post-dial-delay. The second situation relates to billing (that awful B-word). If the originating client will be paying for the session, he/she should have some control over the choice of codec out of the common pool. While it is certainly possible for a nasty UAS to thwart this (i.e. for a telemarketer call, I only support the $$$$/sec media streams), the final choice of media streams properly belongs to the UAC. Bill Marshall wtm@research.att.com -----original message----- From: "Fairlie-Cuninghame, Robert" To: "'sip@ietf.org'" Cc: "'jdrosen@dynamicsoft.com'" Date: Sat, 11 Aug 2001 00:51:42 -0700 I perceive a strong weakness in the current SIP offer/answer model. The problem pertains to the fact that the callee has no way of indicating its media profile requirements. Consider the situation: A sends INVITE B with m=audio 5454 RTP/AVP 0 m=video 4444 RTP/AVP 31 However the server only supports (or requires for this call) a different profile, eg RTP/SAVP or some other transport profile (RTP/AVP-USCTP or TLS or something). There is no way that the callee has to communicate this information to the caller. This will be needed for proper deployment of SRTP on servers and a great many other things. - You cannot accept the call by setting the port to zero and then sending a re-INVITE as you cannot be sure that the client supports this profile. Answering calls successfully when you really don't have the ability to communicate is something that we want to avoid at all costs (dead handset syndrome). - It cannot be communicated in SIP headers as this is a layer violation (and just bad design). You are trying to use the session protocol to signal he required SDP transport paths. - You could send a 4xx error with an SDP indicate the appropriate offer that the caller should make to be successful. The requires more messages, longer call setup times and new parsing & analysis logic of the SDP on the client side. I don't like it. I have a proposal: I think what we need is to allow a offer/counter-offer/answer model. Now this sounds very familiar -> Jonathan's new Early Media model! SDP in INVITE, callee instead sends counter-offer in reliable provisional response, to which the caller either accepts or rejects with the SDP in PRACK. When the 200 OK is eventually sent by the callee it is in answer to the SDP in the PRACK (rather than original INVITE). I would like to see this generalized such that it can also be used with local ringback (rather than removed as some have requested). Once again, I see this functionality as _absolutely_ crucial to the proper deployment of SRTP and other SDP transport profiles. This also apples to the situation where the callee needs to know whether the caller supports a certain SDP capability (for instance, support for a particular SDP attributes) - another very, very important case. Please suggest something else if you don't like this scheme. [Jonathan proposed an alternate solution in the open issues section of his early media draft: .... We would then need a token in the 1xx somewhere which says "I ignored your offer of SDP in the INVITE, this 2xx is an offer, not an answer". This token, perhaps a require token, would be present in the original 1xx but not 1xx in response to re-INVITEs. We could apply this to INVITE/2xx/ACK as well. We should try to make any scheme consistent and as long as it works I am not bothered.] Regards, Robert. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 10:53:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06313 for ; Fri, 24 Aug 2001 10:53:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01376; Fri, 24 Aug 2001 10:46:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01287 for ; Fri, 24 Aug 2001 10:46:45 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06142 for ; Fri, 24 Aug 2001 10:45:25 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7OEkbK22167; Fri, 24 Aug 2001 16:46:37 +0200 (MEST) Received: from lmf.ericsson.se (rmt160178.am.ericsson.se [138.85.160.178]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA29803; Fri, 24 Aug 2001 16:46:30 +0200 (MET DST) Message-ID: <3B866C1F.B5FE521F@lmf.ericsson.se> Date: Fri, 24 Aug 2001 18:00:47 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg CC: Jonathan Rosenberg , Sean Olson , "'Colin Perkins'" , "'sip@ietf.org'" , "'mmusic'" Subject: Re: [Sip] Re: SDP hold References: <3B865220.A3E171C5@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello Christer, Christer Holmberg wrote: > > Hi, > > I think it would be a good idea to bring this question to the Megaco > mailing list. There are lots of people working on Media Gateways there, > so maybe they have some kind of solution for this. Well, feel free to forward this mail to the MEGACO list. Regards, Gonzalo > > I can write down a few lines, and also CC the mail to the SIP list > (since I guess most of us aren't on the Megaco list...). > > Regards, > > Christer Holmberg > Ericsson Finland > > Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Thursday, August 23, 2001 10:32 AM > > > To: Sean Olson (EUS) > > > Cc: 'Jonathan Rosenberg'; 'Colin Perkins'; 'sip@ietf.org'; 'mmusic' > > > Subject: Re: [Sip] Re: SDP hold > > > > > > > > > > 5) XXX: no RTP, no RTCP ??? > > > > > > > > Then what is used to specify the fifth item > > > > (no RTP, no RTCP)? > > > > > > This is currently defined by setting the port number to zero. > > > That is, I > > > offer you a particular media stream and you set its port to > > > zero in the > > > 200 OK. It means that no RTP and no RTCP will be sent over that media > > > stream. > > > > Well, this is a little bit different. Port zero means "tear down this > > stream". This would result, for example, in the closure of any windows that > > were popped up for video rendering of the stream. I think Sean's case is > > where we neither send RTP/RTCP, but the stream is only temporarily suspended > > and can be revived. A better question, is whether we really need this > > additional case. I'd rather limit them to things we really need. > > > > > > > > This brings me to related topic: > > > > > > Right now, once you have answer with port=zero, you cannot re-use that > > > stream during the session. That is, every re-INVITE you send will > > > contain that media line with the port set to zero, but media > > > will never > > > flow to it. > > > > > > It has been brought up (by 3GPP among others) that it might > > > be useful to > > > be able to re-use that stream in a future. If I want to add a > > > new media > > > stream to the session, I can use that media line by changing the port > > > number to a non-zero value in a re-INVITE. > > > > > > Well, I am triggering a new discussion here (I would like to see > > > opinions on this), but I believe that the semantics of the inactive > > > attribute are pretty clear. > > > > Hmm, I though I had sent out an email on this open issue as well.... I'll > > resend if I don't see it in the archives. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 11:00:53 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06447 for ; Fri, 24 Aug 2001 11:00:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01581; Fri, 24 Aug 2001 10:53:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01551 for ; Fri, 24 Aug 2001 10:53:01 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06271 for ; Fri, 24 Aug 2001 10:51:41 -0400 (EDT) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7OEqkv18305; Fri, 24 Aug 2001 16:52:47 +0200 (MEST) Received: from lmf.ericsson.se (rmt160178.am.ericsson.se [138.85.160.178]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA00139; Fri, 24 Aug 2001 16:52:40 +0200 (MET DST) Message-ID: <3B866D91.66239CD2@lmf.ericsson.se> Date: Fri, 24 Aug 2001 18:06:57 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Sean Olson , "'Colin Perkins'" , "'sip@ietf.org'" , "'mmusic'" Subject: Re: [Sip] Re: SDP hold References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hello, Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Thursday, August 23, 2001 10:32 AM > > To: Sean Olson (EUS) > > Cc: 'Jonathan Rosenberg'; 'Colin Perkins'; 'sip@ietf.org'; 'mmusic' > > Subject: Re: [Sip] Re: SDP hold > > > > > > > 5) XXX: no RTP, no RTCP ??? > > > > > > Then what is used to specify the fifth item > > > (no RTP, no RTCP)? > > > > This is currently defined by setting the port number to zero. > > That is, I > > offer you a particular media stream and you set its port to > > zero in the > > 200 OK. It means that no RTP and no RTCP will be sent over that media > > stream. > > Well, this is a little bit different. Port zero means "tear down this > stream". This would result, for example, in the closure of any windows that > were popped up for video rendering of the stream. I think Sean's case is > where we neither send RTP/RTCP, but the stream is only temporarily suspended > and can be revived. A better question, is whether we really need this > additional case. I'd rather limit them to things we really need. Yes, I agree that we do not want to resolve theoretical problems. We have enough "real" problems to work on. Anyway, if we do not want to *receive* neither RTP nor RCTP we set c=0.0.0.0 If we do not want to *send* RTP we mark the stream as recvonly or inactive. We only have to figure out how to signal the fact that we will not *send* RCTP. If, as Jonathan suggested, somebody needs this capability (he or she should speak up) we can work on it. Regards, Gonzalo > > > > This brings me to related topic: > > > > Right now, once you have answer with port=zero, you cannot re-use that > > stream during the session. That is, every re-INVITE you send will > > contain that media line with the port set to zero, but media > > will never > > flow to it. > > > > It has been brought up (by 3GPP among others) that it might > > be useful to > > be able to re-use that stream in a future. If I want to add a > > new media > > stream to the session, I can use that media line by changing the port > > number to a non-zero value in a re-INVITE. > > > > Well, I am triggering a new discussion here (I would like to see > > opinions on this), but I believe that the semantics of the inactive > > attribute are pretty clear. > > Hmm, I though I had sent out an email on this open issue as well.... I'll > resend if I don't see it in the archives. > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 11:41:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07451 for ; Fri, 24 Aug 2001 11:41:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03187; Fri, 24 Aug 2001 11:33:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03160 for ; Fri, 24 Aug 2001 11:33:40 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07283 for ; Fri, 24 Aug 2001 11:32:20 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7OFWFrN002700; Fri, 24 Aug 2001 11:32:15 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 11:33:03 -0400 Message-ID: From: Jonathan Rosenberg To: "'brett@broadsoft.com'" , Jonathan Rosenberg , sip@ietf.org Subject: RE: [Sip] URGENT: session timer: new issues Date: Fri, 24 Aug 2001 11:33:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Tuesday, August 21, 2001 8:53 PM > To: 'Jonathan Rosenberg'; sip@ietf.org > Subject: RE: [Sip] URGENT: session timer: new issues > > > > Issue #1 > > -------- > > My fix for this is that the client uses the max of the Min-SE > > amongst all > > 422 in all responses for a particular CALL before any call legs are > > established. Once a call leg is established, it uses the max > > of the min-SE > > returned in all 422 responses for that call leg (i.e, with > > the same tag as > > the 2xx that created the leg). As a result, when the call is > > accepted, the > > max of the Min-SE is effectively "cleared", and then can be > > reset to the max > > of the Min-SE on the path of the call leg. This seems to work fine. > > Sounds good. OK, seems like consensus on this one. > > > > > ISSUE #2 > > -------- > > Another option (soln 2) is this. A proxy can insert both a > > Session-Expires > > and Min-SE into the request. If a proxy sees a request > > without a Supported > > header, but with a Session-Expires header below its minimum, > > it can insert a > > Min-SE header into the request before proxying it (although it can't > > increase the session timer). When this hits the UAS, if it sees a > > session-expires with a value lower than min-se, it uses the > value from > > min-se instead of the value in session-expires. > > Solution 2 sounds fine. The same solution works > for when the UAS thinks Session-Expires was too > small. The UAS would use its own Min-SE for the > Session-Expires instead of rejecting with a 422. > Yes, that is true. I will take this to mean consensus on this issue as well. I'll update the draft today and get it resubmitted with these changes. I think we are finally done! -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 11:59:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07918 for ; Fri, 24 Aug 2001 11:59:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03676; Fri, 24 Aug 2001 11:47:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03646 for ; Fri, 24 Aug 2001 11:47:34 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07564 for ; Fri, 24 Aug 2001 11:46:14 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7OFldi24346 for ; Fri, 24 Aug 2001 10:47:39 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 24 Aug 2001 10:47:34 -0500 content-class: urn:content-classes:message Date: Fri, 24 Aug 2001 10:47:24 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Some questions on SIP message encryption X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEss+FtXcBxd3OKT9+/F8qeKqDQvg== From: "Chan Tat (NRC/Boston)" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA03647 Subject: [Sip] Some questions on SIP message encryption Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, I have the following questions regarding encryption of SIP messages and I hope someone could help. 1. In rfc2543bis03, there are examples for using PGP for end-to-end encryption. Is there any other encryption scheme defined? One thing which confused me is that PGP is a collection of many schemes. So, for instance, if DES is to be used, are we supposed to use DES within PGP? Is it possible to specify the use of DES without PGP? 2. In section 18.1.4 of rfc2543bis03 about Hop-by-hop encryption, IPSec and TLS are mentioned. Does it imply that hop-by-hop encryption will not be performed in the applicaiton layer (encrypting the whole SIP message)? Thank you very much in advance. Any comments and related discussions are welcome. Best Regards, Tat Chan Senior Reserach Engineer Nokia Research Center NOKIA INC 5 Wayside Road, Burlington, MA 01803 Phone (781) 993-5776, Fax (781) 993-1907 tat.chan@nokia.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 15:24:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13238 for ; Fri, 24 Aug 2001 15:24:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10795; Fri, 24 Aug 2001 15:00:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10759 for ; Fri, 24 Aug 2001 15:00:22 -0400 (EDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12529 for ; Fri, 24 Aug 2001 14:59:03 -0400 (EDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7OJ0Qi15303 for ; Fri, 24 Aug 2001 14:00:26 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 24 Aug 2001 14:00:17 -0500 content-class: urn:content-classes:message Subject: RE: [Sip] Some questions on SIP message encryption Date: Fri, 24 Aug 2001 14:00:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [Sip] Some questions on SIP message encryption X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEstCES+bj5rJihEdWxLgAIx6TWeAAGifHw From: "Chan Tat (NRC/Boston)" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA10760 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi all, > -----Original Message----- > From: ext Chan Tat (NRC/Boston) [mailto:Tat.Chan@nokia.com] > Sent: August 24, 2001 11:47 AM > To: sip@ietf.org > Subject: [Sip] Some questions on SIP message encryption > > > Hi, > > I have the following questions regarding encryption of SIP > messages and > I hope someone could help. > > 1. In rfc2543bis03, there are examples for using PGP for end-to-end > encryption. Is there any other encryption scheme defined? One thing > which confused me is that PGP is a collection of many schemes. So, for > instance, if DES is to be used, are we supposed to use DES within PGP? > Is it possible to specify the use of DES without PGP? Just to clarify, instead of DES, the example I should have used is CAST, Triple-DES, or IDEA, which PGP supports. Are we supposed to use them within PGP? or is it possible to specify their use without PGP? > 2. In section 18.1.4 of rfc2543bis03 about Hop-by-hop > encryption, IPSec > and TLS are mentioned. Does it imply that hop-by-hop > encryption will not > be performed in the applicaiton layer (encrypting the whole SIP > message)? > > Thank you very much in advance. Any comments and related > discussions are > welcome. > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > Tat Chan Senior Reserach Engineer Nokia Research Center NOKIA INC 5 Wayside Road, Burlington, MA 01803 Phone (781) 993-5776, Fax (781) 993-1907 tat.chan@nokia.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 19:23:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16904 for ; Fri, 24 Aug 2001 19:23:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17382; Fri, 24 Aug 2001 19:08:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17354 for ; Fri, 24 Aug 2001 19:08:12 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16788 for ; Fri, 24 Aug 2001 19:06:54 -0400 (EDT) From: Jin-Gen.Wang@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id XAA19291 for ; Fri, 24 Aug 2001 23:08:11 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id XAA06604 for ; Fri, 24 Aug 2001 23:08:10 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <3RFXWDVM>; Fri, 24 Aug 2001 17:08:10 -0600 Message-ID: To: sip@ietf.org Date: Fri, 24 Aug 2001 17:04:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] issues on TCP support and Record-Route Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I am sorry if these issues have been discussed before. I have two issues concerning carrier grade SIP applications. (1) When using a stream based transport protocol, e.g., TCP, SIP poses several problems because SIP messages don't carry total length in a fixed position, e.g., the first 4 bytes of the messages: (a) Although the messages can be parsed in normal conditions, our tests showed that the performance of using current SIP spec is several times slower than carrying a total length in front of SIP messages. (b) There is no robust way to handle malformed messages coming from TCP without a total length in a fixed position. For example, a message doesn't have a correct end of message headers. So what is the reason that SIP doesn't specify a total message length in a fixed position. I propose to carry a total length of each message in the first 4 bytes for stream-based transport protocol. (2) The Record-Route header has been overloaded to be used by subsequent requests in both directions. This causes problems when one side of proxy uses TCP and the other side uses UDP, although bis-4 does allow Record-Route header to carry "transport=value" parameter. Some people have suggested to rewrite the Record-Route header for final responses. This suggestion posts performance overhead for all final responses. I propose to use different names when specify transport protocol parameters, e.g., transport_in = TCP;transport_out=UDP. Thank you in advance for your comments and suggestions. Jin-Gen Wang Level 3 Communications _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 19:40:48 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17031 for ; Fri, 24 Aug 2001 19:40:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17801; Fri, 24 Aug 2001 19:26:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17770 for ; Fri, 24 Aug 2001 19:26:45 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16925 for ; Fri, 24 Aug 2001 19:25:26 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 16:25:12 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'William Marshall'" , sip@ietf.org Cc: jdrosen@dynamicsoft.com Date: Fri, 24 Aug 2001 16:25:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: Weakness in SIP offer/answer model Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi William, Good comments. One nit thought, I think we should avoid using the term "three-way handshake" with respect to offer/counter-offer/answer. These words have certain connotations that may confuse people. Although _notionally_ it may in some way form a three way handshake (because the counter-offer may be formed based on the original offer), algorithmically the offer/counter-offer/answer is still a simple two-way handshake. The offer is completely replaced by the counter-offer. A three way handshake could also suggest that some confirmation of the answer is made by the receiver which is also not algorithmically true at the SDP layer. Not completely wrong but confusing I think. Regards, Robert. > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Friday, August 24, 2001 7:00 AM > To: sip@ietf.org > Cc: rfairlie@nuera.com; jdrosen@dynamicsoft.com > Subject: Re: Weakness in SIP offer/answer model > > > The offer/counter-offer/answer model also appears in the > manyfolks draft. > The specific case where it is essential is when the UAS reduces the > preconditions requested by the UAC - the UAC needs a mechanism to > drop a media stream from the session if the UAS will not agree to > all of the preconditions for it. So an SDP is included in the PRACK > in this case. > > There are at least two other situations where the offer/counter-offer/ > answer model is a big improvement. > > If the UAC and UAS both support a large number of codecs, but > with very > few in common, it may take a while to find one in common. If the UAC > sends an initial SDP with a single codec, which is not > supported by UAS, > the session would fail and the UAC would have to re-try with > a different > codec. This is true even if the UAS responds with an alternative in > its answer SDP. The three-way handshake allows the UAC to > insert _all_ > of its supported codecs in the initial SDP, the UAS to indicate those > it supports as well, and the UAC to then pick one of the common ones. > Single round-trip codec negotiation, and minimal impact on > post-dial-delay. > > The second situation relates to billing (that awful B-word). If the > originating client will be paying for the session, he/she should have > some control over the choice of codec out of the common pool. > While it > is certainly possible for a nasty UAS to thwart this (i.e. for a > telemarketer call, I only support the $$$$/sec media streams), the > final choice of media streams properly belongs to the UAC. > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: "Fairlie-Cuninghame, Robert" > To: "'sip@ietf.org'" > Cc: "'jdrosen@dynamicsoft.com'" > Date: Sat, 11 Aug 2001 00:51:42 -0700 > > I perceive a strong weakness in the current SIP offer/answer model. > > The problem pertains to the fact that the callee has no way > of indicating > its media profile requirements. Consider the situation: > > A sends INVITE B with > m=audio 5454 RTP/AVP 0 > m=video 4444 RTP/AVP 31 > > However the server only supports (or requires for this call) > a different > profile, eg RTP/SAVP or some other transport profile > (RTP/AVP-USCTP or TLS > or something). > > There is no way that the callee has to communicate this > information to the > caller. This will be needed for proper deployment of SRTP on > servers and a > great many other things. > > - You cannot accept the call by setting the port to zero and > then sending a > re-INVITE as you cannot be sure that the client supports this profile. > Answering calls successfully when you really don't have the ability to > communicate is something that we want to avoid at all costs > (dead handset > syndrome). > > - It cannot be communicated in SIP headers as this is a layer > violation (and > just bad design). You are trying to use the session protocol > to signal he > required SDP transport paths. > > - You could send a 4xx error with an SDP indicate the > appropriate offer that > the caller should make to be successful. The requires more > messages, longer > call setup times and new parsing & analysis logic of the SDP > on the client > side. I don't like it. > > I have a proposal: I think what we need is to allow a > offer/counter-offer/answer model. Now this sounds very familiar -> > Jonathan's new Early Media model! SDP in INVITE, callee instead sends > counter-offer in reliable provisional response, to which the > caller either > accepts or rejects with the SDP in PRACK. When the 200 OK is > eventually sent > by the callee it is in answer to the SDP in the PRACK (rather > than original > INVITE). > > I would like to see this generalized such that it can also be > used with > local ringback (rather than removed as some have requested). > > Once again, I see this functionality as _absolutely_ crucial > to the proper > deployment of SRTP and other SDP transport profiles. This > also apples to the > situation where the callee needs to know whether the caller supports a > certain SDP capability (for instance, support for a particular SDP > attributes) - another very, very important case. > > Please suggest something else if you don't like this scheme. > > [Jonathan proposed an alternate solution in the open issues > section of his > early media draft: > > .... We would then need a token in the 1xx somewhere > which says "I ignored your offer of SDP in the INVITE, this > 2xx is an offer, not an answer". This token, perhaps a > require token, would be present in the original 1xx but not > 1xx in response to re-INVITEs. We could apply this to > INVITE/2xx/ACK as well. > > We should try to make any scheme consistent and as long as it > works I am not > bothered.] > > Regards, > > Robert. > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 24 22:50:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20177 for ; Fri, 24 Aug 2001 22:50:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21059; Fri, 24 Aug 2001 22:06:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21030 for ; Fri, 24 Aug 2001 22:06:56 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18934 for ; Fri, 24 Aug 2001 22:05:36 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 19:05:23 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'William Marshall'" , sip@ietf.org Cc: jdrosen@dynamicsoft.com Subject: RE: [Sip] RE: Weakness in SIP offer/answer model Date: Fri, 24 Aug 2001 19:05:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi William, I just reread your post and came to the conclusion that we fell into the confusion I was talking about. It appears to me you _are_ talking about a true three-way handshake which is quite different to the offer/counter-offer/answer .... more like a offer/answer/refined-answer. This is a different discussion and needs to be separated. I might add that it has been previously proposed and rejected on the list. In the offer/counter-offer/answer model we are maintaining the _exact_ semantics of the basic SIP two-way offer/answer model described in bis. The offer and counter-offer are not algorithmically related at all - in fact this is where the real usefulness of the model is achieved. [Eg Caller offers RTP/AVP, callee counter-offers RTP/SAVP; or caller offers one bidirectional unicast stream, callee counter offers one unidirectional multicast stream and one-unidirectional unicast stream] If caller and callee have non-overlapping requirements/capabilities then you do not want to establish the session initially. Codec refinement can occur using re-INVITE but you want to ensure that the two UA's can communicate in _some_ manner before establishment. I hope this clarifies things. Robert. > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Friday, August 24, 2001 4:25 PM > To: 'William Marshall'; sip@ietf.org > Cc: jdrosen@dynamicsoft.com > Subject: [Sip] RE: Weakness in SIP offer/answer model > > > Hi William, > > Good comments. > > One nit thought, I think we should avoid using the term "three-way > handshake" with respect to offer/counter-offer/answer. These > words have > certain connotations that may confuse people. Although > _notionally_ it may > in some way form a three way handshake (because the > counter-offer may be > formed based on the original offer), algorithmically the > offer/counter-offer/answer is still a simple two-way > handshake. The offer is > completely replaced by the counter-offer. A three way > handshake could also > suggest that some confirmation of the answer is made by the > receiver which > is also not algorithmically true at the SDP layer. > > Not completely wrong but confusing I think. > > Regards, > > Robert. > > > -----Original Message----- > > From: William Marshall [mailto:wtm@research.att.com] > > Sent: Friday, August 24, 2001 7:00 AM > > To: sip@ietf.org > > Cc: rfairlie@nuera.com; jdrosen@dynamicsoft.com > > Subject: Re: Weakness in SIP offer/answer model > > > > > > The offer/counter-offer/answer model also appears in the > > manyfolks draft. > > The specific case where it is essential is when the UAS reduces the > > preconditions requested by the UAC - the UAC needs a mechanism to > > drop a media stream from the session if the UAS will not agree to > > all of the preconditions for it. So an SDP is included in the PRACK > > in this case. > > > > There are at least two other situations where the > offer/counter-offer/ > > answer model is a big improvement. > > > > If the UAC and UAS both support a large number of codecs, but > > with very > > few in common, it may take a while to find one in common. > If the UAC > > sends an initial SDP with a single codec, which is not > > supported by UAS, > > the session would fail and the UAC would have to re-try with > > a different > > codec. This is true even if the UAS responds with an alternative in > > its answer SDP. The three-way handshake allows the UAC to > > insert _all_ > > of its supported codecs in the initial SDP, the UAS to > indicate those > > it supports as well, and the UAC to then pick one of the > common ones. > > Single round-trip codec negotiation, and minimal impact on > > post-dial-delay. > > > > The second situation relates to billing (that awful B-word). If the > > originating client will be paying for the session, he/she > should have > > some control over the choice of codec out of the common pool. > > While it > > is certainly possible for a nasty UAS to thwart this (i.e. for a > > telemarketer call, I only support the $$$$/sec media streams), the > > final choice of media streams properly belongs to the UAC. > > > > Bill Marshall > > wtm@research.att.com > > > > -----original message----- > > From: "Fairlie-Cuninghame, Robert" > > To: "'sip@ietf.org'" > > Cc: "'jdrosen@dynamicsoft.com'" > > Date: Sat, 11 Aug 2001 00:51:42 -0700 > > > > I perceive a strong weakness in the current SIP offer/answer model. > > > > The problem pertains to the fact that the callee has no way > > of indicating > > its media profile requirements. Consider the situation: > > > > A sends INVITE B with > > m=audio 5454 RTP/AVP 0 > > m=video 4444 RTP/AVP 31 > > > > However the server only supports (or requires for this call) > > a different > > profile, eg RTP/SAVP or some other transport profile > > (RTP/AVP-USCTP or TLS > > or something). > > > > There is no way that the callee has to communicate this > > information to the > > caller. This will be needed for proper deployment of SRTP on > > servers and a > > great many other things. > > > > - You cannot accept the call by setting the port to zero and > > then sending a > > re-INVITE as you cannot be sure that the client supports > this profile. > > Answering calls successfully when you really don't have the > ability to > > communicate is something that we want to avoid at all costs > > (dead handset > > syndrome). > > > > - It cannot be communicated in SIP headers as this is a layer > > violation (and > > just bad design). You are trying to use the session protocol > > to signal he > > required SDP transport paths. > > > > - You could send a 4xx error with an SDP indicate the > > appropriate offer that > > the caller should make to be successful. The requires more > > messages, longer > > call setup times and new parsing & analysis logic of the SDP > > on the client > > side. I don't like it. > > > > I have a proposal: I think what we need is to allow a > > offer/counter-offer/answer model. Now this sounds very familiar -> > > Jonathan's new Early Media model! SDP in INVITE, callee > instead sends > > counter-offer in reliable provisional response, to which the > > caller either > > accepts or rejects with the SDP in PRACK. When the 200 OK is > > eventually sent > > by the callee it is in answer to the SDP in the PRACK (rather > > than original > > INVITE). > > > > I would like to see this generalized such that it can also be > > used with > > local ringback (rather than removed as some have requested). > > > > Once again, I see this functionality as _absolutely_ crucial > > to the proper > > deployment of SRTP and other SDP transport profiles. This > > also apples to the > > situation where the callee needs to know whether the caller > supports a > > certain SDP capability (for instance, support for a particular SDP > > attributes) - another very, very important case. > > > > Please suggest something else if you don't like this scheme. > > > > [Jonathan proposed an alternate solution in the open issues > > section of his > > early media draft: > > > > .... We would then need a token in the 1xx somewhere > > which says "I ignored your offer of SDP in the INVITE, this > > 2xx is an offer, not an answer". This token, perhaps a > > require token, would be present in the original 1xx but not > > 1xx in response to re-INVITEs. We could apply this to > > INVITE/2xx/ACK as well. > > > > We should try to make any scheme consistent and as long as it > > works I am not > > bothered.] > > > > Regards, > > > > Robert. > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Sat Aug 25 10:28:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11716 for ; Sat, 25 Aug 2001 10:28:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10863; Sat, 25 Aug 2001 09:54:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10832 for ; Sat, 25 Aug 2001 09:54:29 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11483 for ; Sat, 25 Aug 2001 09:53:12 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7PDsOv24273; Sat, 25 Aug 2001 15:54:24 +0200 (MEST) Received: from lmf.ericsson.se (lmf05397pc.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7PDsM527044; Sat, 25 Aug 2001 16:54:22 +0300 (EET DST) Message-ID: <3B87AE26.3B87C9B8@lmf.ericsson.se> Date: Sat, 25 Aug 2001 16:54:46 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: Jonathan Rosenberg , Sean Olson , "'Colin Perkins'" , "'sip@ietf.org'" , "'mmusic'" Subject: Re: [Sip] Re: SDP hold References: <3B866D91.66239CD2@lmf.ericsson.se> Content-Type: multipart/mixed; boundary="------------B84E29A9016054B195030B93" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------B84E29A9016054B195030B93 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am not sure I like the use of c=0.0.0.0 for putting RTCP on "hold", for the same reason I don't like it for putting RTP on hold: when people start sending RTP/RTCP using IPv6 we have to define a new mechanism anyway... So, I think we should define a long-term solution, which is not dependent on the IP version - or whatever protocol/network we use. One though could be to define the RTCP as a separate stream. But then I guess the problem is to "map" the RTCP to RTP, especially in an multistream environment. Regards, Christer Holmberg Ericsson Finland Gonzalo Camarillo wrote: > > Hello, > > Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Thursday, August 23, 2001 10:32 AM > > > To: Sean Olson (EUS) > > > Cc: 'Jonathan Rosenberg'; 'Colin Perkins'; 'sip@ietf.org'; 'mmusic' > > > Subject: Re: [Sip] Re: SDP hold > > > > > > > > > > 5) XXX: no RTP, no RTCP ??? > > > > > > > > Then what is used to specify the fifth item > > > > (no RTP, no RTCP)? > > > > > > This is currently defined by setting the port number to zero. > > > That is, I > > > offer you a particular media stream and you set its port to > > > zero in the > > > 200 OK. It means that no RTP and no RTCP will be sent over that media > > > stream. > > > > Well, this is a little bit different. Port zero means "tear down this > > stream". This would result, for example, in the closure of any windows that > > were popped up for video rendering of the stream. I think Sean's case is > > where we neither send RTP/RTCP, but the stream is only temporarily suspended > > and can be revived. A better question, is whether we really need this > > additional case. I'd rather limit them to things we really need. > > Yes, I agree that we do not want to resolve theoretical problems. We > have enough "real" problems to work on. > > Anyway, if we do not want to *receive* neither RTP nor RCTP we set > c=0.0.0.0 > If we do not want to *send* RTP we mark the stream as recvonly or > inactive. > We only have to figure out how to signal the fact that we will not > *send* RCTP. > > If, as Jonathan suggested, somebody needs this capability (he or she > should speak up) we can work on it. > > Regards, > > Gonzalo > > > > > > > This brings me to related topic: > > > > > > Right now, once you have answer with port=zero, you cannot re-use that > > > stream during the session. That is, every re-INVITE you send will > > > contain that media line with the port set to zero, but media > > > will never > > > flow to it. > > > > > > It has been brought up (by 3GPP among others) that it might > > > be useful to > > > be able to re-use that stream in a future. If I want to add a > > > new media > > > stream to the session, I can use that media line by changing the port > > > number to a non-zero value in a re-INVITE. > > > > > > Well, I am triggering a new discussion here (I would like to see > > > opinions on this), but I believe that the semantics of the inactive > > > attribute are pretty clear. > > > > Hmm, I though I had sent out an email on this open issue as well.... I'll > > resend if I don't see it in the archives. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------B84E29A9016054B195030B93 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------B84E29A9016054B195030B93-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 00:35:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20504 for ; Mon, 27 Aug 2001 00:35:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28016; Mon, 27 Aug 2001 00:25:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27987 for ; Mon, 27 Aug 2001 00:25:20 -0400 (EDT) Received: from maliwan.psu.ac.th (maliwan.psu.ac.th [192.100.77.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20405 for ; Mon, 27 Aug 2001 00:23:56 -0400 (EDT) Received: from oossy ([172.30.2.69]) by maliwan.psu.ac.th (8.11.4/8.11.4) with SMTP id f7R4P2I18073 for ; Mon, 27 Aug 2001 11:25:02 +0700 (ICT) Message-ID: <004901c12eb1$0a27bcb0$45021eac@oossy> From: "Oossy air" To: Date: Mon, 27 Aug 2001 11:30:45 +0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C12EEB.B65A2D80" 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 Subject: [Sip] about md5 algorithm for authorization header Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0046_01C12EEB.B65A2D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I read document in RFC 1321 . But i have some ploblem i don't understand in =20 request-digest =3D<"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) ><"> request-digest =3D "KD(H(A1),unq(nonce-value) ":" H(A2) )" A1 =3D unq(username-value) ":" unq(realm-value) ":" passwd A2 =3D Method ":" digest-uri-value what KD?,H? if i have user : "Mufasa" realm : "myhost@testrealm.com" passwd : "Circle Of Life" nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093" =20 I understand that A1 =3D Mufasa:myhost@testrealm.com:Circle Of Life A2 =3D GET:/dir/index.html request-digest =3D"6629fae49393a05397450978507c4ef1" =20 H(A1) =3D MD5(A1) --->=3D "a7a51364a1de242a70b8845e528a7cc1" H(A2) =3D MD5(A2)--->=3D "39aff3a2bab6126f332b942af96d3366" =20 so KD ( H(A1), unq(nonce-value) ":" H(A2)) =20 I think concat H(A1),unq(nonce-value) :H(A2) a7a51364a1de242a70b8845e528a7cc1,dcd98b7102dd2f0e8b11d0f600bfb0c093:39aff= 3a2bab6126f332b942af96d3366 and then KD(H(A1), unq(nonce-value) ":" H(A2)) =3D MD5(H (A1), unq(nonce-value) ":" H(A2)) =20 So = MD5(a7a51364a1de242a70b8845e528a7cc1,dcd98b7102dd2f0e8b11d0f600bfb0c093:3= 9aff3a2bab6126f332b942af96d3366) =3D d6f5a12596316a226554a4ce76d99026 but not correct =20 =20 if you have suggestion for me again will thanks a lot oossy ------=_NextPart_000_0046_01C12EEB.B65A2D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I read document in RFC = 1321 .
 But i have some ploblem i don't = understand=20 in
 
request-digest =20 =3D<"> < KD ( H(A1), unq(nonce-value) ":" H(A2) )=20 ><">
 

request-digest  =3D = "KD(H(A1),unq(nonce-value)=20 ":" H(A2) )"
 
A1 =3D unq(username-value) ":" = unq(realm-value) ":"=20 passwd
A2 =3D Method ":" digest-uri-value
 
what=20 KD?,H?

if i have
user : "Mufasa"
realm : "myhost@testrealm.com"
passwd : "Circle Of Life"
nonce=3D"dcd98b7102dd2f0e8b11d0f600bfb0c093"
 
 
I understand that
A1 =3D Mufasa:myhost@testreal= m.com:Circle=20 Of Life
A2 =3D = GET:/dir/index.html
request-digest =20 =3D"6629fae49393a05397450978507c4ef1"
=
 
H(A1) =3D = MD5(A1) --->=3D=20 "a7a51364a1de242a70b8845e528a7cc1"
H(A2) =3D=20 MD5(A2)--->=3D =20 "39aff3a2bab6126f332b942af96d3366"
  
so KD ( = H(A1),=20 unq(nonce-value) ":" H(A2)) 
I think concat = H(A1),unq(nonce-value) :H(A2)
 
a7a51364a1de242a70b8845e528a7cc1,dcd98b7102dd2f0e8b11d0f600bfb0c= 093:39aff3a2bab6126f332b942af96d3366
 
and then KD(H(A1), unq(nonce-value) ":" = H(A2)) =3D=20 MD5(H
 
(A1), unq(nonce-value) ":" = H(A2))
 
So MD5(a7a51364a1de242a70b8845e528a7cc1,dcd98b7102dd2f0e8b11d0f600bfb0c= 093:39aff3a2bab6126f332b942af96d3366)
=
    =3D=20 d6f5a12596316a226554a4ce76d99026 but not correct
 
 
 
if you have suggestion for me again = will thanks a=20 lot
oossy
------=_NextPart_000_0046_01C12EEB.B65A2D80-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 08:53:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15593 for ; Mon, 27 Aug 2001 08:53:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17950; Mon, 27 Aug 2001 08:34:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA17919 for ; Mon, 27 Aug 2001 08:34:05 -0400 (EDT) Received: from daimanta.ascend.com (daimanta.bos.ascend.com [152.148.40.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14313 for ; Mon, 27 Aug 2001 08:32:46 -0400 (EDT) Received: from reddog.casc.com (reddog.ascend.com [152.148.100.22]) by daimanta.ascend.com (8.9.3/8.9.3) with ESMTP id IAA19282; Mon, 27 Aug 2001 08:33:36 -0400 (EDT) Received: from lucent.com ([152.148.210.204]) by reddog.casc.com (8.8.8+Sun/8.8.8) with ESMTP id IAA13527; Mon, 27 Aug 2001 08:05:58 -0400 (EDT) Message-ID: <3B8A3E1F.F37E7FCB@lucent.com> Date: Mon, 27 Aug 2001 08:33:35 -0400 From: Kim Liu Organization: Lucent Technologies X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jin-Gen.Wang@level3.com CC: sip@ietf.org Subject: Re: [Sip] issues on TCP support and Record-Route References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jin-Gen.Wang@level3.com wrote: > > I am sorry if these issues have been discussed before. I have two issues > concerning carrier grade SIP applications. > > (1) When using a stream based transport protocol, e.g., TCP, SIP poses > several problems because SIP messages don't carry total length in a fixed > position, e.g., the first 4 bytes of the messages: > > (a) Although the messages can be parsed in normal conditions, our tests > showed that the performance of using current SIP spec is several times > slower than carrying a total length in front of SIP messages. > > (b) There is no robust way to handle malformed messages coming from TCP > without a total length in a fixed position. For example, a message doesn't > have a correct end of message headers. > > So what is the reason that SIP doesn't specify a total message length in a > fixed position. I propose to carry a total length of each message in the > first 4 bytes for stream-based transport protocol. Well, I agree with you whole-heartedly, but you won't be able to get this idea to fly with the current spec because it breaks too much. If you mean four bytes of binary data for length, then it breaks the readable text only idea people have. (i.e. 0x00 00 01 00 for 256 bytes.) To quote from the spec (bis-04, 10.18): The ability to omit Content-Length simplifies the creation of cgi-like scripts that dynamically generate responses. That is for UDP datagrams. Unfortunately, if you try to nail down a fixed content length location at the beginning of the message for TCP, you'll probably break the above for UDP. So, everyone must endure so that some can write simple scripts that don't have to worry about content length. :-) Cheers, Kim Liu Senior Software Engineer Lucent Technologies Clearwater, FL _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 09:12:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16622 for ; Mon, 27 Aug 2001 09:12:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18247; Mon, 27 Aug 2001 08:45:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18218 for ; Mon, 27 Aug 2001 08:45:27 -0400 (EDT) Received: from hotsip.com ([212.28.214.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15102 for ; Mon, 27 Aug 2001 08:44:07 -0400 (EDT) Received: from Hash ([195.238.204.173]) by hotsip.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 14:45:20 +0200 From: "Hisham Khartabil" To: Date: Mon, 27 Aug 2001 15:42:29 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 27 Aug 2001 12:45:20.0680 (UTC) FILETIME=[21C9F280:01C12EF6] Content-Transfer-Encoding: 7bit Subject: [Sip] 411 Length required response Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Why has it been removed from the BIS draft? I can't seen to recall a reason. Thanks Hisham www.hotsip.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 10:06:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19102 for ; Mon, 27 Aug 2001 10:06:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20450; Mon, 27 Aug 2001 09:56:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20419 for ; Mon, 27 Aug 2001 09:56:43 -0400 (EDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18657 for ; Mon, 27 Aug 2001 09:55:23 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 3863E1E021 for ; Mon, 27 Aug 2001 09:56:44 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA27265; Mon, 27 Aug 2001 09:56:41 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id JAA23100; Mon, 27 Aug 2001 09:57:56 -0400 (EDT) Date: Mon, 27 Aug 2001 09:57:56 -0400 (EDT) Message-Id: <200108271357.JAA23100@fish.research.att.com> To: sip@ietf.org Subject: [Sip] Review of draft-campbell-sip-e164-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Following are my comments from reviewing draft-campbell-sip-e164-00. Bill Marshall wtm@research.att.com NITS: 1) draft has expired, and may disappear at any time from the IETF internet-draft directory. It should be re-submitted to keep current. 2) draft is included in the sipt charter item of SIPPING. The draft name should be changed to draft-ietf-sipping-e164-00.txt 3) draft name in page header is incorrect, and includes several non-printable characters. 4) date in page header differs from date on first page of draft. They should be consistent. 5) should not include a reference in the abstract. Recommend dropping tail end of sentence ", as specified in [1]" 6) Two of the references ([1] and [3]) are to internet-drafts. Ref [1] should be to RFC2916, and Ref [3] should be to RFC2915. 7) The full copyright statement is missing from the end. SUBSTANTIVE: 1) document describes more than handling of E.164 numbers at a user agent. It also includes handling at proxies and at PSTN gateways. The introduction and abstract should be updated to includes these. 2) definite lack of spec language in the draft. While the abstract and introduction claim the document describes how a UA will use DNS to resolve E.164 urls, the only MUSTs are that the UA and proxy MUST NOT use "e164.arpa" for locally-scoped telephone numbers. Consider the following paragraph as a suggestion: The UA MAY send the request to a pre-configured proxy. Otherwise, the UA MUST perform a lookup/translation function on the destination URL. If a tel: URL, the UA MUST consult an ENUM database, as described in [1], and convert it to a sip: URL. If a sip: URL (or after conversion of the tel: URL via ENUM), the UA MUST examine the hostname - if different from the UA the UA MUST consult DNS and forward the request to that host. If the hostname matches the UA and the tag "user=phone" is attached to the URL, the UA MUST consult an ENUM database as described earlier for a tel: URL. 3) the draft allows a UA to send the request to a pre-configured proxy, rather than doing the DNS lookup in ENUM. The same should be allowed for a proxy - that it can send the request to a pre- configured proxy that has the ENUM interface. Otherwise, the draft is requiring all proxies to implement the interface to ENUM, which seems more than needed. In the suggested spec paragraph above, just change UA to proxy and include in the proxy procedures. 4) The indented paragraph starting "It is tempting to say that the tel URL and sip URL in the example..." should be moved to closely follow the example (not in the section after the example). Suggest putting it after the paragraph "Both example describe..." 5) Open Issues section should be dropped. RFC2916 is included by reference, and no need to duplicate its text in the current document. Questions for the SIP WG: 1) First paragraph in "User Agent Client" indicates a tel: URL may appear in a Contact header. I don't think this is valid. Is it? _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 14:05:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26126 for ; Mon, 27 Aug 2001 14:05:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28446; Mon, 27 Aug 2001 13:54:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA28415 for ; Mon, 27 Aug 2001 13:54:25 -0400 (EDT) Received: from chuckie.dgms.com (host-38-150-156-4.dgms.com [38.150.156.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25805 for ; Mon, 27 Aug 2001 13:53:04 -0400 (EDT) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id NAA09662 for ; Mon, 27 Aug 2001 13:54:23 -0400 (EDT) Message-ID: <3B8A88FE.815CCEE0@ulticom.com> Date: Mon, 27 Aug 2001 13:53:02 -0400 From: Vijaya Venkatachalam Organization: Ulticom, Inc. X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "'sip@ietf.org'" References: <3B8513E5.625F03D5@lmf.ericsson.se> Content-Type: multipart/mixed; boundary="------------C98DEE94A7770B25E3C9A54F" Subject: [Sip] 3gpp & sip Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------C98DEE94A7770B25E3C9A54F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Which all interfaces in 3GPP are using SIP? Thanks, Vijaya --------------C98DEE94A7770B25E3C9A54F Content-Type: text/x-vcard; charset=us-ascii; name="vijaya.vcf" Content-Description: Card for Vijaya Venkatachalam Content-Disposition: attachment; filename="vijaya.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Venkatachalam;Vijaya tel;fax:+1-856-866-2033 tel;work:+1-856-787-2853 x-mozilla-html:FALSE url:www.ulticom.com org:Ulticom, Inc.;Research & Development adr:;;1020 Briggs Rd;Mt. Laurel;NJ;08054;USA version:2.1 email;internet:vijaya@ulticom.com fn:Vijaya Venkatachalam end:vcard --------------C98DEE94A7770B25E3C9A54F-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 15:56:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28501 for ; Mon, 27 Aug 2001 15:56:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01020; Mon, 27 Aug 2001 15:28:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00991 for ; Mon, 27 Aug 2001 15:28:41 -0400 (EDT) Received: from newman.gte.com ([132.197.8.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27945 for ; Mon, 27 Aug 2001 15:27:21 -0400 (EDT) Received: from [132.197.71.195] (leidenmac.gte.com [132.197.71.195]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id PAA02771 for ; Mon, 27 Aug 2001 15:28:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: shl0@pophost.gte.com Message-Id: Date: Mon, 27 Aug 2001 15:27:52 -0400 To: sip@ietf.org From: Stevan Leiden Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Sip] SIP-T Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Does anyone know the status of SIP-T? Dr. Stevan H. Leiden Principal Member of the Technical Staff Verizon Technology Organization Waltham, Ma. 40 Sylvan Rd. 02451-1128 voice: 781-466-2415 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 18:06:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02120 for ; Mon, 27 Aug 2001 18:06:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06064; Mon, 27 Aug 2001 17:41:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06035 for ; Mon, 27 Aug 2001 17:41:09 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01389 for ; Mon, 27 Aug 2001 17:39:48 -0400 (EDT) Received: from oranlt ([161.44.238.60]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7RLav609599; Mon, 27 Aug 2001 14:36:57 -0700 (PDT) From: "David R. Oran" To: "'Jonathan Rosenberg'" , "'Colin Perkins'" , "'Gonzalo Camarillo'" Cc: , "'mmusic'" Subject: RE: [Sip] Re: SDP hold Date: Mon, 27 Aug 2001 17:43:26 -0400 Organization: Cisco Systems Message-ID: <006901c12f41$4e82a8d0$3cee2ca1@cisco.com> 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.2627 Importance: Normal In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2542.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I sure think RTCP should be sent. Dave. > -----Original Message----- > From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU] > On Behalf Of Jonathan Rosenberg > Sent: Wednesday, August 22, 2001 2:30 PM > To: 'Colin Perkins'; Gonzalo Camarillo > Cc: Jonathan Rosenberg; sip@ietf.org; mmusic > Subject: RE: [Sip] Re: SDP hold > > > So, here is an important question on the inactive attribute. > If a stream is inactive, is RTCP sent? I think it probably > should, actually... RTCP helps to keep state alive in various > places, and this session is still alive, just suspended. > > THoughts? > > -Jonathan R. > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Colin Perkins [mailto:csp@purple.cs.ucl.ac.uk] > > Sent: Wednesday, August 15, 2001 5:30 AM > > To: Gonzalo Camarillo > > Cc: Jonathan Rosenberg; sip@ietf.org; mmusic > > Subject: Re: [Sip] Re: SDP hold > > > > >a=inactive > > > This specifies that the tools should be started in inactive > > > mode. This is necessary for interactive conferences > > where users can > > >put other users on hold. No media is sent over an inactive > > media stream. > > >It can be either a session or media attribute, and is not > > dependent on > > >charset. > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 18:06:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02119 for ; Mon, 27 Aug 2001 18:06:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06282; Mon, 27 Aug 2001 17:46:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06251 for ; Mon, 27 Aug 2001 17:46:11 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01507 for ; Mon, 27 Aug 2001 17:44:49 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7RLinob015912 for ; Mon, 27 Aug 2001 17:44:49 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 17:45:40 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E539@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@ietf.org'" Date: Mon, 27 Aug 2001 17:45:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] draft-ietf-sip-refer-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I've submitted refer-00 to the internet-draft repository. While the submission is being processed, the draft is available at http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-refer-00.txt This is the draft as of the _beginning_ of August's meeting, and does not yet reflect the directions we've agreed to since. (in particular, removing the signature from the referred-by line in favor of a generic header protection mechanism). I should have those out in refer-01 shortly. RjS _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 18:16:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02512 for ; Mon, 27 Aug 2001 18:16:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07310; Mon, 27 Aug 2001 17:58:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07243 for ; Mon, 27 Aug 2001 17:58:18 -0400 (EDT) Received: from pine.il.neustar.com (pine.neustar.com [209.173.57.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01868 for ; Mon, 27 Aug 2001 17:56:57 -0400 (EDT) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.il.neustar.com (8.11.0/8.11.0) with ESMTP id f7RLwHK30421; Mon, 27 Aug 2001 16:58:17 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 16:56:57 -0500 Message-ID: <70565611B164D511957A001083FCDD56478A86@va02.va.neustar.com> From: "Peterson, Jon" To: "'Stevan Leiden'" , sip@ietf.org Subject: RE: [Sip] SIP-T Date: Mon, 27 Aug 2001 16:57:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org SIP-T is a working group item of the soon-to-be SIPPING WG (www.softarmor.com/sipping)- the SIP WG is now focusing on core protocol rather than applications of SIP, and hence it is no longer looking at SIP-T. Future correspondence about SIP-T should be directed to the SIPPING mailing list (sipping@ietf.org). That much said, the status of some of the work items (ones I happen to be involved with) is as follows: draft-ietf-sip-isup-mime-10: Complete. Should be issued its RFC number any day now. draft-ietf-sip-isup-02: Version -03 is complete and will come out of the I-D queue in a few days now. Nits/WG last call are forthcoming. draft-vemuri-sip-t-context-02: Renamed to 'draft-ietf-sipping-sipt-00', will come out soon. Past nits review, WGLC will follow shortly. draft-ietf-sip-isup-overlap-01: Just came out. Incorporates 490 status code (i.e. re-INVITE before 200 as per the early media draft) and a few other fixes. I also understand that Alan's call-flows-05 draft is undergoing WGLC in SIPPING at the moment. Jon Peterson NeuStar, Inc -----Original Message----- From: Stevan Leiden [mailto:steve.leiden@verizon.com] Sent: Monday, August 27, 2001 1:28 PM To: sip@ietf.org Subject: [Sip] SIP-T Does anyone know the status of SIP-T? Dr. Stevan H. Leiden Principal Member of the Technical Staff Verizon Technology Organization Waltham, Ma. 40 Sylvan Rd. 02451-1128 voice: 781-466-2415 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 18:21:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02906 for ; Mon, 27 Aug 2001 18:21:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08873; Mon, 27 Aug 2001 18:15:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08813 for ; Mon, 27 Aug 2001 18:15:48 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02476; Mon, 27 Aug 2001 18:14:25 -0400 (EDT) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f7RMGhD02398; Mon, 27 Aug 2001 17:16:43 -0500 Message-ID: <000c01c12f45$e001fc80$ad036e3f@flak> From: "Dean Willis" To: , "Sipping \(E-mail\)" Date: Mon, 27 Aug 2001 17:16:08 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C12F1B.F61A8480" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: [Sip] Problems with Supplemental Web Site Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C12F1B.F61A8480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It looks like something scrambled about half of the drafts on the = supplemental web site late on August 22. I've just discovered it and am = assessing the situation.=20 In the meantime, if you try and download a draft and get complete glorp, = don't be surprised. I think it's a filesystem problem involving an apparent reboot at about = the same time, but you never know. And yes, I have backups. Relatively complete, anyhow. -- Dean ------=_NextPart_000_0009_01C12F1B.F61A8480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It looks like something scrambled about = half of the=20 drafts on the supplemental web site late on August 22. I've just = discovered it=20 and am assessing the situation.
 
In the meantime, if you try and = download a draft=20 and get complete glorp, don't be surprised.
 
I think it's a filesystem problem = involving an=20 apparent reboot at about the same time, but you never know.
 
And yes, I have backups. Relatively = complete,=20 anyhow.
 
--
Dean
------=_NextPart_000_0009_01C12F1B.F61A8480-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 18:39:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03303 for ; Mon, 27 Aug 2001 18:39:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09933; Mon, 27 Aug 2001 18:23:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA09906 for ; Mon, 27 Aug 2001 18:23:16 -0400 (EDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02903 for ; Mon, 27 Aug 2001 18:21:54 -0400 (EDT) Received: from 157.54.9.100 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 27 Aug 2001 15:21:54 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 15:21:51 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 15:21:50 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 15:21:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Sip] Re: SDP hold Date: Mon, 27 Aug 2001 15:21:30 -0700 Message-ID: Thread-Topic: [Sip] Re: SDP hold Thread-Index: AcEvQQGiCVd4dgwfTXi4H6pVmhN8LwABVGZw From: "Christian Huitema" To: "David R. Oran" , "Jonathan Rosenberg" , "Colin Perkins" , "Gonzalo Camarillo" Cc: , "mmusic" X-OriginalArrivalTime: 27 Aug 2001 22:21:30.0940 (UTC) FILETIME=[9F44FFC0:01C12F46] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA09908 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Yep. In fact, if you consider things like NAT traversal, you probably want to also send a modicum of RTP packets for sessions that are on hold. Maybe some comfort noise, at a low bit rate. Otherwise, you are going to loose your mappings, and the "going off hold" will be tricky. -- Christian Huitema > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Monday, August 27, 2001 2:43 PM > To: 'Jonathan Rosenberg'; 'Colin Perkins'; 'Gonzalo Camarillo' > Cc: sip@ietf.org; 'mmusic' > Subject: RE: [Sip] Re: SDP hold > > I sure think RTCP should be sent. > > Dave. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 18:54:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02121 for ; Mon, 27 Aug 2001 18:06:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05939; Mon, 27 Aug 2001 17:38:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05910 for ; Mon, 27 Aug 2001 17:38:33 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01335 for ; Mon, 27 Aug 2001 17:37:12 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA29702 for ; Mon, 27 Aug 2001 14:38:33 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA14923 for ; Mon, 27 Aug 2001 14:38:33 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 27 Aug 2001 16:38:33 -0500 Message-ID: <796456A0F96AD511A0AC009027B0F74102049716@IL27EXM08.cig.mot.com> From: Ziyad Nigel-NZIYAD1 To: Vijaya Venkatachalam , "'sip@ietf.org'" Subject: RE: [Sip] 3gpp & sip Date: Mon, 27 Aug 2001 16:38:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Some information from Thursday's IETF 51 SIPPING meeting can be found at http://www.softarmor.com/sipping/meets/ietf51/slides/ Dr. Nigel A. Ziyad Senior Staff Engineer Motorola GTSS--Network Standards & Advanced Technology Phone: 847-632-2098 Fax: 847-632-7912 -----Original Message----- From: Vijaya Venkatachalam [mailto:vijaya@ulticom.com] Sent: Monday, August 27, 2001 12:53 PM To: 'sip@ietf.org' Subject: [Sip] 3gpp & sip Hi, Which all interfaces in 3GPP are using SIP? Thanks, Vijaya _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 18:54:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02118 for ; Mon, 27 Aug 2001 18:06:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06147; Mon, 27 Aug 2001 17:41:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06119 for ; Mon, 27 Aug 2001 17:41:43 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01403 for ; Mon, 27 Aug 2001 17:40:22 -0400 (EDT) Received: from oranlt ([161.44.238.60]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7RLbV609983; Mon, 27 Aug 2001 14:37:32 -0700 (PDT) From: "David R. Oran" To: , "'Jonathan Rosenberg'" , "'Colin Perkins'" , Cc: , "'mmusic'" Subject: RE: [Sip] Re: SDP hold Date: Mon, 27 Aug 2001 17:44:00 -0400 Organization: Cisco Systems Message-ID: <006a01c12f41$631d7860$3cee2ca1@cisco.com> 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.2627 Importance: Normal In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2542.0000 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-confctrl@ISI.EDU [mailto:owner-confctrl@ISI.EDU] > On Behalf Of sean.olson@ericsson.com > Sent: Wednesday, August 22, 2001 3:13 PM > To: 'Jonathan Rosenberg'; 'Colin Perkins'; Gonzalo Camarillo > Gonzalez (LMF) > Cc: sip@ietf.org; mmusic > Subject: RE: [Sip] Re: SDP hold > > > I thought the entire point of the inactive attribute > was to specify a stream that did not send RTP -or- RTCP. > > If we accept the following: > > 1) send-only: RTP one way, RTCP two way > 2) recv-only: RTP one way, RTCP two way > 3) send-recv: RTP two way, RTCP two way > 4) inactive: no RTP, RTCP two way > 5) XXX: no RTP, no RTCP ??? > > Then what is used to specify the fifth item > (no RTP, no RTCP)? > An SDP which does not include that media stream. > /sean > > > >-----Original Message----- > >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > >Sent: Wednesday, August 22, 2001 1:30 PM > >To: 'Colin Perkins'; Gonzalo Camarillo > >Cc: Jonathan Rosenberg; sip@ietf.org; mmusic > >Subject: RE: [Sip] Re: SDP hold > > > > > >So, here is an important question on the inactive attribute. > >If a stream is > >inactive, is RTCP sent? I think it probably should, > >actually... RTCP helps > >to keep state alive in various places, and this session is > >still alive, just > >suspended. > > > >THoughts? > > > >-Jonathan R. > > > > > >--- > >Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > >Chief Scientist First Floor > >dynamicsoft East Hanover, NJ 07936 > >jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >http://www.jdrosen.net PHONE: (973) 952-5000 > >http://www.dynamicsoft.com > > > > > >> -----Original Message----- > >> From: Colin Perkins [mailto:csp@purple.cs.ucl.ac.uk] > >> Sent: Wednesday, August 15, 2001 5:30 AM > >> To: Gonzalo Camarillo > >> Cc: Jonathan Rosenberg; sip@ietf.org; mmusic > >> Subject: Re: [Sip] Re: SDP hold > >> > >> >a=inactive > >> > This specifies that the tools should be started in inactive > >> > mode. This is necessary for interactive conferences > >> where users can > >> >put other users on hold. No media is sent over an inactive > >> media stream. > >> >It can be either a session or media attribute, and is not > >> dependent on > >> >charset. > > > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 19:18:33 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04054 for ; Mon, 27 Aug 2001 19:18:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10935; Mon, 27 Aug 2001 18:56:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10907 for ; Mon, 27 Aug 2001 18:56:34 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03570 for ; Mon, 27 Aug 2001 18:55:14 -0400 (EDT) Received: from flak (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f7RMvTD02543; Mon, 27 Aug 2001 17:57:29 -0500 Message-ID: <002f01c12f4b$91817e40$ad036e3f@flak> From: "Dean Willis" To: "Vijaya Venkatachalam" , References: <3B8513E5.625F03D5@lmf.ericsson.se> <3B8A88FE.815CCEE0@ulticom.com> Subject: Re: [Sip] 3gpp & sip Date: Mon, 27 Aug 2001 17:56:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit That's actually a question better asked in 3GPP SA2. They have a slew of interfaces, each with a symbolic name like "The Sh interface". There's also some debate between various 3GPP groups as to which interfaces exist and what to call them, for example "SIP+" and "ISC" interface(s). In general, SIP is used between UE and P-CSCF, P-CSCF and P-CSCF, P-CSCF and I-CSCF, I-CSCF and S-CSCF, S-CSCF and AS, and AS-AS, and of course the inverses of those. There's some debate about whether AS may also directly interface to other SIP nodes withot using S-CSCF and I-CSCF, or may go directly to I-CSCF or other firewall proxy without transiting S-CSCF. Mine can -- why pay extra for more S-CSCF than one really needs? But it's configurable so that people who really want to spend more money can do so . . . Free enterprise loves Darwin's dead-end branches if they're well-funded. There's also another edge-proxy node called a THIG that may appear in various locations and speaks SIP. -- Dean ----- Original Message ----- From: "Vijaya Venkatachalam" To: Sent: Monday, August 27, 2001 12:53 PM Subject: [Sip] 3gpp & sip > Hi, > > Which all interfaces in 3GPP are using SIP? > > Thanks, > Vijaya > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 19:45:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04446 for ; Mon, 27 Aug 2001 19:45:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12468; Mon, 27 Aug 2001 19:34:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12443 for ; Mon, 27 Aug 2001 19:34:40 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04282 for ; Mon, 27 Aug 2001 19:33:20 -0400 (EDT) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7RNHE613981; Mon, 27 Aug 2001 19:17:17 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAJ18477 (AUTH pkyzivat); Mon, 27 Aug 2001 19:18:28 -0400 (EDT) Message-ID: <3B8AD387.CF97874A@cisco.com> Date: Mon, 27 Aug 2001 19:11:03 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: "David R. Oran" , Jonathan Rosenberg , Colin Perkins , Gonzalo Camarillo , sip@ietf.org, mmusic Subject: Re: [Sip] Re: SDP hold References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > Yep. In fact, if you consider things like NAT traversal, you probably > want to also send a modicum of RTP packets for sessions that are on > hold. Maybe some comfort noise, at a low bit rate. Otherwise, you are > going to loose your mappings, and the "going off hold" will be tricky. This is not a nice thing. I believe the current plan is to represent going on hold changing SDP to a:sendonly or a:inactive. If you send me SDP that says a:sendonly, then I am obligated to respond a:recvonly. Once I have declared myself recvonly, do you really want me to send on the RTP port? That is certainly an interesting interpretation of "recvonly". I realize there are some important pragmatics going on here, but it is really doing violence to the terminology. Paul Kyzivat Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 19:51:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04487 for ; Mon, 27 Aug 2001 19:51:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11828; Mon, 27 Aug 2001 19:18:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11797 for ; Mon, 27 Aug 2001 19:18:16 -0400 (EDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04022 for ; Mon, 27 Aug 2001 19:16:56 -0400 (EDT) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7RNHE613981; Mon, 27 Aug 2001 19:17:17 -0400 (EDT) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAJ18477 (AUTH pkyzivat); Mon, 27 Aug 2001 19:18:28 -0400 (EDT) Message-ID: <3B8AD387.CF97874A@cisco.com> Date: Mon, 27 Aug 2001 19:11:03 -0400 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema CC: "David R. Oran" , Jonathan Rosenberg , Colin Perkins , Gonzalo Camarillo , sip@ietf.org, mmusic Subject: Re: [Sip] Re: SDP hold References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christian Huitema wrote: > > Yep. In fact, if you consider things like NAT traversal, you probably > want to also send a modicum of RTP packets for sessions that are on > hold. Maybe some comfort noise, at a low bit rate. Otherwise, you are > going to loose your mappings, and the "going off hold" will be tricky. This is not a nice thing. I believe the current plan is to represent going on hold changing SDP to a:sendonly or a:inactive. If you send me SDP that says a:sendonly, then I am obligated to respond a:recvonly. Once I have declared myself recvonly, do you really want me to send on the RTP port? That is certainly an interesting interpretation of "recvonly". I realize there are some important pragmatics going on here, but it is really doing violence to the terminology. Paul Kyzivat Cisco Systems _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Mon Aug 27 22:29:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07853 for ; Mon, 27 Aug 2001 22:29:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15984; Mon, 27 Aug 2001 21:51:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15953 for ; Mon, 27 Aug 2001 21:51:17 -0400 (EDT) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07191 for ; Mon, 27 Aug 2001 21:49:55 -0400 (EDT) Received: from 157.54.9.108 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 27 Aug 2001 18:49:57 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 18:49:57 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 18:49:51 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 18:49:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Sip] Issue #113, wrt Content Sequencing Date: Mon, 27 Aug 2001 18:49:36 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102BEF665@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [Sip] Issue #113, wrt Content Sequencing Thread-Index: AcEr8vzTlL3QLHlZTzGVUfcknn1P1wDcEL+Q From: "Ajay Chitturi" To: "Henning Schulzrinne" , "Jonathan Rosenberg" Cc: , "SIP List" X-OriginalArrivalTime: 28 Aug 2001 01:49:36.0784 (UTC) FILETIME=[B1699900:01C12F63] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA15954 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit I think INFO is an example where such sequencing is required. It would be good to have a generic mechanism for providing ordering. Ajay. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, August 23, 2001 12:19 PM To: Jonathan Rosenberg Cc: 'eburger@snowshore.com'; SIP List Subject: Re: [Sip] Issue #113, wrt Content Sequencing While an *average* rate of > 1/RTT probably calls for a real transport protocol, it would be really nice to be able to send an occasional message with a shorter spacing, particularly given the loss case (i.e., where it could be seconds before the answer comes back, thus delaying the second message). Thus, I agree with Jonathan, that dumping this feature could get us into trouble later. The increase in protocol complexity seems close to zero and the increase in implementation complexity modest. Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Eric Burger [mailto:eburger@snowshore.com] > > Sent: Tuesday, August 07, 2001 6:14 AM > > To: SIP List > > Subject: [Sip] Issue #113, wrt Content Sequencing > > > > > > On the one hand, I would love to find a generic mechanism for > > ordering and > > detecting loss in overlapped non-INVITE content. However, we > > hashed over > > this issue in the SIP-events discussion. Namely, content > > sequencing and > > recovery is inherently content-specific. Thus I would propose Strict > > Sequencing (if needed) in the content, as Jonathan originally > > proposed. > > I think the first question we need to ask is whether we even want to solve > the problem of overlapping non-INVITE. > > One of the bigger motivating factors was the MESSAGE method. However, simple > has converged upon NOT using MESSAGE for message transport in the session > model. As a result, that need has disappeared. > > Are there other burning needs? This is one of those things where there may > not be a need now, but it could be a big issue down the road when someone > comes up with a need. > > Notifications for rapid presence changes, like second-granularity geo-loc > updates, might be a need. > > A more radical view is that if you want second-granular presence updates, > you are better off setting up the notifications as a "media stream" as we > are doing for IM, and use just SUBSCRIBE as is to set it up.... > > THoughts? Lets resolve this. > > -Jonathan R. > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 03:12:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28697 for ; Tue, 28 Aug 2001 03:12:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02143; Tue, 28 Aug 2001 02:28:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02112 for ; Tue, 28 Aug 2001 02:28:16 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28100 for ; Tue, 28 Aug 2001 02:26:55 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7S6SBK27925; Tue, 28 Aug 2001 08:28:11 +0200 (MEST) Received: from lmf.ericsson.se (lmf00234pc.lmf.ericsson.se [131.160.30.33]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7S6SA421772; Tue, 28 Aug 2001 09:28:10 +0300 (EET DST) Message-ID: <3B8B39F9.F80A7962@lmf.ericsson.se> Date: Tue, 28 Aug 2001 09:28:09 +0300 From: Christer Holmberg <@lmf.ericsson.se> X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Christian Huitema , "David R. Oran" , Jonathan Rosenberg , Colin Perkins , Gonzalo Camarillo , sip@ietf.org, mmusic Subject: Re: [Sip] Re: SDP hold References: <3B8AD387.CF97874A@cisco.com> Content-Type: multipart/mixed; boundary="------------549D2443DE837A95C6483274" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------549D2443DE837A95C6483274 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, My question is: do we really care? To my understanding, the only thing that SIP is concerned about is to put the actual MEDIA on hold - period. The need, or no-need, of RTCP may then be depending on the network architecture etc, and it's a bearer level issue, so it could be configurable elsewhere. We should remember that even if we put media on hold, we still have a stream, and depending on the bearer network (IP, ATM,...) there may be some "stream signalling" (RTCP, for example). So, if one really wants to make sure that nothing is sent he/she may simply remove the stream completely... Regards, Christer Holmberg Ericsson Finland Paul Kyzivat wrote: > > Christian Huitema wrote: > > > > Yep. In fact, if you consider things like NAT traversal, you probably > > want to also send a modicum of RTP packets for sessions that are on > > hold. Maybe some comfort noise, at a low bit rate. Otherwise, you are > > going to loose your mappings, and the "going off hold" will be tricky. > > This is not a nice thing. I believe the current plan is to represent > going on hold changing SDP to a:sendonly or a:inactive. If you send me > SDP that says a:sendonly, then I am obligated to respond a:recvonly. > Once I have declared myself recvonly, do you really want me to send > on the RTP port? > > That is certainly an interesting interpretation of "recvonly". > I realize there are some important pragmatics going on here, but > it is really doing violence to the terminology. > > Paul Kyzivat > Cisco Systems > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------549D2443DE837A95C6483274 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------549D2443DE837A95C6483274-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 10:23:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11213 for ; Tue, 28 Aug 2001 10:23:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13019; Tue, 28 Aug 2001 09:37:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12992 for ; Tue, 28 Aug 2001 09:37:51 -0400 (EDT) Received: from cs.tut.fi (root@varis.cs.tut.fi [130.230.4.42]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10036 for ; Tue, 28 Aug 2001 09:36:30 -0400 (EDT) Received: from cs.tut.fi (root@kaarne.cs.tut.fi [130.230.4.11]) by cs.tut.fi (8.8.8/8.8.8) with ESMTP id QAA22034 for ; Tue, 28 Aug 2001 16:37:49 +0300 (EET DST) Message-ID: <3B8B9EAC.6050301@cs.tut.fi> Date: Tue, 28 Aug 2001 16:37:48 +0300 From: Sami Keski-Kasari User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010827 X-Accept-Language: en-us MIME-Version: 1.0 To: sip@ietf.org Subject: [Sip] 407 Proxy Authentication Required with ACK Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Can anyone say why it is possible to use Proxy Authentication with ACK? (rfc2543 page 41 table 5 or draft rfc2543-bis04 page 40 table 5 , mentioned as optional). We are trying to use Columbia University's sipd 1.18 with Cisco 7960 SIP-phones. After enabling Digest Authentication speech goes only from caller to callee because our sipd sends "407 Proxy Authentication Required" after receiving ACK and Cisco's SIP-phones doesn't support that. And they seems not to be willing fix it unless there are any good reason. As they said: "From a more practical point of view, at that poinnt the remote end's phone already ringed and the call has been answered, that means we are in CONNECTED and any the billing of the call is started. It makes little or no sense at all to worry about authorization when the call is up. On the contrary, the 407 should be sent back as answer to the INVITE." And I can't see any use of that either. -- Sami Keski-Kasari Research Assistant Tampere University of Technology/ Telecom lab. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 11:01:34 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12383 for ; Tue, 28 Aug 2001 11:01:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14232; Tue, 28 Aug 2001 10:25:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14142 for ; Tue, 28 Aug 2001 10:25:07 -0400 (EDT) Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11224 for ; Tue, 28 Aug 2001 10:23:48 -0400 (EDT) Received: from mailhost.ubiquity.net by drago1.ubiquity.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 28 Aug 2001 14:25:09 UT Received: from jundery ([193.195.52.206]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 28 Aug 2001 15:25:24 +0100 From: "James Undery" To: "Sami Keski-Kasari" , Subject: RE: [Sip] 407 Proxy Authentication Required with ACK Date: Tue, 28 Aug 2001 15:24:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <3B8B9EAC.6050301@cs.tut.fi> X-OriginalArrivalTime: 28 Aug 2001 14:25:24.0842 (UTC) FILETIME=[46F61CA0:01C12FCD] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit An ACK should never generate a response (section 5.1.1 paragraph 2) so any further discussion is really meaningless, the sipd is at fault if it responds to an ACK. However the tables 4 and 5 should really be changed so that all headers are marked as "-" in responses to ACKs. Paragraph 2 of section 5.1.1 perhaps also ought to be "The ACK request MUST NOT generate responses for any transport protocol.", just to make it absolutely explicit. James Undery -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Sami Keski-Kasari Sent: 28 August 2001 14:38 To: sip@ietf.org Subject: [Sip] 407 Proxy Authentication Required with ACK Can anyone say why it is possible to use Proxy Authentication with ACK? (rfc2543 page 41 table 5 or draft rfc2543-bis04 page 40 table 5 , mentioned as optional). We are trying to use Columbia University's sipd 1.18 with Cisco 7960 SIP-phones. After enabling Digest Authentication speech goes only from caller to callee because our sipd sends "407 Proxy Authentication Required" after receiving ACK and Cisco's SIP-phones doesn't support that. And they seems not to be willing fix it unless there are any good reason. As they said: "From a more practical point of view, at that poinnt the remote end's phone already ringed and the call has been answered, that means we are in CONNECTED and any the billing of the call is started. It makes little or no sense at all to worry about authorization when the call is up. On the contrary, the 407 should be sent back as answer to the INVITE." And I can't see any use of that either. -- Sami Keski-Kasari Research Assistant Tampere University of Technology/ Telecom lab. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 16:28:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20572 for ; Tue, 28 Aug 2001 16:28:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24859; Tue, 28 Aug 2001 16:10:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24830 for ; Tue, 28 Aug 2001 16:10:03 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20197 for ; Tue, 28 Aug 2001 16:08:43 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7SK7kob023630; Tue, 28 Aug 2001 16:07:46 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Aug 2001 16:08:37 -0400 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , Jonathan Rosenberg Cc: "'eburger@snowshore.com'" , SIP List Subject: RE: [Sip] Issue #113, wrt Content Sequencing Date: Tue, 28 Aug 2001 16:08:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, August 23, 2001 3:19 PM > To: Jonathan Rosenberg > Cc: 'eburger@snowshore.com'; SIP List > Subject: Re: [Sip] Issue #113, wrt Content Sequencing > > > While an *average* rate of > 1/RTT probably calls for a real transport > protocol, it would be really nice to be able to send an occasional > message with a shorter spacing, particularly given the loss > case (i.e., > where it could be seconds before the answer comes back, thus delaying > the second message). Thus, I agree with Jonathan, that dumping this > feature could get us into trouble later. The increase in protocol > complexity seems close to zero and the increase in implementation > complexity modest. Clearly, its a cost/benefit thing. There is some cost, and there is some benefit. The relative values of the costs and benefits will be entirely subjective without some more concrete information. So, I think a few questions still need to be answered: 1. Who has UA and/or proxy implementations which will be mightily upset at seeing overlapping non-INVITE transactions within a call leg (in theory, should be nobody, but I'm curious...) Is the complexity of buffering these at the sender higher than the complexity of buffering at the receiver to handle reordering? 2. What are some concrete use cases that people need? Can someone point out some PSTN cases using INFO where we will legitimately need to send a second INFO right away? Would performance really be hindered by buffering it? -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 16:43:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20984 for ; Tue, 28 Aug 2001 16:43:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25293; Tue, 28 Aug 2001 16:24:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25263 for ; Tue, 28 Aug 2001 16:24:32 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20453 for ; Tue, 28 Aug 2001 16:23:12 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7SKN8ob023765; Tue, 28 Aug 2001 16:23:09 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Aug 2001 16:23:59 -0400 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , Sami Keski-Kasari , sip@ietf.org Subject: RE: [Sip] 407 Proxy Authentication Required with ACK Date: Tue, 28 Aug 2001 16:23:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Tuesday, August 28, 2001 10:25 AM > To: Sami Keski-Kasari; sip@ietf.org > Subject: RE: [Sip] 407 Proxy Authentication Required with ACK > > > > An ACK should never generate a response (section 5.1.1 > paragraph 2) so any > further discussion is really meaningless, the sipd is at fault if it > responds to an ACK. > > However the tables 4 and 5 should really be changed so that > all headers are > marked as "-" in responses to ACKs. Good point. Fixed. > Paragraph 2 of section > 5.1.1 perhaps > also ought to be "The ACK request MUST NOT generate responses for any > transport protocol.", just to make it absolutely explicit. Yes, thats right. Fixed. In general, the use of MUST/MAY/SHOULD in many places needs to be improved. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 16:56:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21318 for ; Tue, 28 Aug 2001 16:56:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25991; Tue, 28 Aug 2001 16:46:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25964 for ; Tue, 28 Aug 2001 16:45:59 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21010 for ; Tue, 28 Aug 2001 16:44:38 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7SKiXob023982; Tue, 28 Aug 2001 16:44:34 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Aug 2001 16:45:25 -0400 Message-ID: From: Jonathan Rosenberg To: "'Bert Culpepper'" , "'Kim Liu'" , Jonathan Rosenberg Cc: sip@ietf.org Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Tue, 28 Aug 2001 16:45:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Bert Culpepper [mailto:bert.culpepper@intervoice-brite.com] > Sent: Thursday, August 23, 2001 3:11 PM > To: 'Kim Liu'; 'Jonathan Rosenberg' > Cc: sip@ietf.org > Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx > > > How can it happen that B provides an offer that is not acceptable to A > provided the UA complies with the first paragraph of B.4 in > bis-04? If > B does want to change, it should issue the re-INVITE. Well, the text does allow it to change. I suspect people might change the IP address and port, just to allow differentiation of media sent from the far side before and after the re-invite. In principal, that should not warrant a rejection. It may very well be that the simplest solution to this problem is simply to change this SHOULD to a MUST; i.e., in a mid-call re-INVITE w/o SDP, the 2xx MUST contain the "same" SDP as last provided to the peer, with the exception of being able to change the IP address/port if so desired. I'm quite happy to do that, and would propose this as probably the best and easiest solution. Objections? (I'll admit, I don't know of a scenario off > hand where > a UA would re-INVITE without SDP to see what the other side > will respond > with.) Its a classic third party call control scenario, and arises quite frequently, actually, in order to connect the user to different media sources during a call. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 17:04:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21478 for ; Tue, 28 Aug 2001 17:04:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26072; Tue, 28 Aug 2001 16:51:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26041 for ; Tue, 28 Aug 2001 16:51:15 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21093 for ; Tue, 28 Aug 2001 16:49:54 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7SKnmob024042; Tue, 28 Aug 2001 16:49:48 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Aug 2001 16:50:37 -0400 Message-ID: From: Jonathan Rosenberg To: "'Hisham Khartabil'" , sip@ietf.org Subject: RE: [Sip] 411 Length required response Date: Tue, 28 Aug 2001 16:50:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org From Appendix I, it was removed since its never needed. WIth UDP, if not present, the length is the remainder of the packet. With TCP, its until the connection is closed. As such, there are no conditions under which its needed. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] > Sent: Monday, August 27, 2001 8:42 AM > To: sip@ietf.org > Subject: [Sip] 411 Length required response > > > Why has it been removed from the BIS draft? I can't seen to > recall a reason. > > Thanks > Hisham > www.hotsip.com > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 17:29:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21883 for ; Tue, 28 Aug 2001 17:29:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26928; Tue, 28 Aug 2001 17:08:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA26899 for ; Tue, 28 Aug 2001 17:08:21 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21526 for ; Tue, 28 Aug 2001 17:07:00 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7SL6wob024261; Tue, 28 Aug 2001 17:07:00 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Aug 2001 17:07:47 -0400 Message-ID: From: Jonathan Rosenberg To: "'William Marshall'" , sip@ietf.org Subject: RE: [Sip] Review of draft-campbell-sip-e164-00 Date: Tue, 28 Aug 2001 17:07:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Monday, August 27, 2001 9:58 AM > To: sip@ietf.org > Subject: [Sip] Review of draft-campbell-sip-e164-00 > > > Following are my comments from reviewing draft-campbell-sip-e164-00. > > Bill Marshall > wtm@research.att.com > > > 5) Open Issues section should be dropped. RFC2916 is included > by reference, and no need to duplicate its text in the current > document. > > > Questions for the SIP WG: > > 1) First paragraph in "User Agent Client" indicates a tel: URL may > appear in a Contact header. I don't think this is valid. Is it? It is not valid. That must be a sip URL. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 17:32:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21958 for ; Tue, 28 Aug 2001 17:32:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27343; Tue, 28 Aug 2001 17:25:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27311 for ; Tue, 28 Aug 2001 17:25:20 -0400 (EDT) Received: from mail2.intervoice-brite.com (mail2.intervoice-brite.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21789 for ; Tue, 28 Aug 2001 17:23:58 -0400 (EDT) Received: from 172.16.16.64 (gwsmtpsrv.intervoice.com [172.16.16.64]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with SMTP id QAA06318 for ; Tue, 28 Aug 2001 16:30:08 -0500 Received: from bculpepperpc ([151.214.151.122]) by 172.16.16.64; Tue, 28 Aug 2001 16:24:35 -0500 From: "Bert Culpepper" To: "'Jonathan Rosenberg'" , "'Kim Liu'" Cc: Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx Date: Tue, 28 Aug 2001 17:24:25 -0400 Message-ID: <005001c13007$d091b980$7a97d697@orlando.brite.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit comments inline... > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, August 28, 2001 4:45 PM > To: 'Bert Culpepper'; 'Kim Liu'; Jonathan Rosenberg > Cc: sip@ietf.org > Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx > > > > > > > > -----Original Message----- > > From: Bert Culpepper [mailto:bert.culpepper@intervoice-brite.com] > > Sent: Thursday, August 23, 2001 3:11 PM > > To: 'Kim Liu'; 'Jonathan Rosenberg' > > Cc: sip@ietf.org > > Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx > > > > > > How can it happen that B provides an offer that is not > acceptable to A > > provided the UA complies with the first paragraph of B.4 in > > bis-04? If > > B does want to change, it should issue the re-INVITE. > > Well, the text does allow it to change. I suspect people > might change the IP > address and port, just to allow differentiation of media sent > from the far > side before and after the re-invite. In principal, that > should not warrant a > rejection. > I agree, changing media destination should not cause a rejection. And I realize SHOULD is currently specified in the text. > It may very well be that the simplest solution to this > problem is simply to > change this SHOULD to a MUST; i.e., in a mid-call re-INVITE > w/o SDP, the 2xx > MUST contain the "same" SDP as last provided to the peer, > with the exception > of being able to change the IP address/port if so desired. > > I'm quite happy to do that, and would propose this as > probably the best and > easiest solution. Objections? > I myself would like to see MUST, and agree that changing IP address/port is OK. > (I'll admit, I don't know of a scenario off > > hand where > > a UA would re-INVITE without SDP to see what the other side > > will respond > > with.) > > Its a classic third party call control scenario, and arises quite > frequently, actually, in order to connect the user to different media > sources during a call. > In these cases (3pcc), as the controller I would recommend a more "assertive" behavior. That is, send the desired SDP in the re-INVITE. Re-INTIVEing with no SDP (without the above restrictions) is asking for trouble in my opinion. (Just to be clear, I can see INVITE w/o SDP being very useful, but not re-INVITE.) regards, Bert > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 17:40:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22079 for ; Tue, 28 Aug 2001 17:40:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27835; Tue, 28 Aug 2001 17:31:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA27809 for ; Tue, 28 Aug 2001 17:31:32 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21927 for ; Tue, 28 Aug 2001 17:30:13 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7SLTdob024549; Tue, 28 Aug 2001 17:29:40 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Aug 2001 17:30:29 -0400 Message-ID: From: Jonathan Rosenberg To: "'Jin-Gen.Wang@Level3.com'" , sip@ietf.org Subject: RE: [Sip] issues on TCP support and Record-Route Date: Tue, 28 Aug 2001 17:30:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Jin-Gen.Wang@Level3.com [mailto:Jin-Gen.Wang@Level3.com] > Sent: Friday, August 24, 2001 7:05 PM > To: sip@ietf.org > Subject: [Sip] issues on TCP support and Record-Route > > > I am sorry if these issues have been discussed before. I have > two issues > concerning carrier grade SIP applications. > > (1) When using a stream based transport protocol, e.g., TCP, SIP poses > several problems because SIP messages don't carry total > length in a fixed > position, e.g., the first 4 bytes of the messages: > > (a) Although the messages can be parsed in normal conditions, > our tests > showed that the performance of using current SIP spec is several times > slower than carrying a total length in front of SIP messages. Several times! Yikes! Our performance results show a small decrease in performance (on the order for 10%), and we suspect that has a lot more to do with issues surrounding buffer sizing, delayed ACK, etc. Sounds like a problem with your implementation, rather than a fundamental problem with length indicators. > > (b) There is no robust way to handle malformed messages > coming from TCP > without a total length in a fixed position. For example, a > message doesn't > have a correct end of message headers. The spec talks about how to handle the case where the length is not present. If its wrong, you end up with an overly long or overly short payload, which results in an error being generated. All of this seems to work for HTTP, which supports persistent connections even, so I have a hard time believing its unworkable for SIP. > > So what is the reason that SIP doesn't specify a total > message length in a > fixed position. I propose to carry a total length of each > message in the > first 4 bytes for stream-based transport protocol. Well, this is more of a transport issue. Sounds like what you are asking for is message oriented connection transport. SCTP provides such a thing. > > (2) The Record-Route header has been overloaded to be used by > subsequent > requests in both directions. This causes problems when one > side of proxy > uses TCP and the other side uses UDP, although bis-4 does > allow Record-Route > header to carry "transport=value" parameter. Some people have > suggested to > rewrite the Record-Route header for final responses. This > suggestion posts > performance overhead for all final responses. Sure, but no more than any other response processing thats done in a proxy (like stripping a via header). Compared to the rest of the overall transaction processing, I suspect that the overall contribution to performance for rewriting the RR in a 2xx is tiny, so fixing this is not likely to do much for you. I propose to > use different > names when specify transport protocol parameters, e.g., transport_in = > TCP;transport_out=UDP. I'll also note that it is often necessary to specify a different port and IP address, so that this would not be sufficient. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 18:00:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22354 for ; Tue, 28 Aug 2001 18:00:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28323; Tue, 28 Aug 2001 17:44:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28291 for ; Tue, 28 Aug 2001 17:44:27 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22112 for ; Tue, 28 Aug 2001 17:43:08 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7SLgmob024706; Tue, 28 Aug 2001 17:42:48 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Aug 2001 17:43:37 -0400 Message-ID: From: Jonathan Rosenberg To: "'Christian Huitema'" , "David R. Oran" , Jonathan Rosenberg , Colin Perkins , Gonzalo Camarillo Cc: sip@ietf.org, mmusic Subject: RE: [Sip] Re: SDP hold Date: Tue, 28 Aug 2001 17:43:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: Monday, August 27, 2001 6:22 PM > To: David R. Oran; Jonathan Rosenberg; Colin Perkins; Gonzalo > Camarillo > Cc: sip@ietf.org; mmusic > Subject: RE: [Sip] Re: SDP hold > > > Yep. In fact, if you consider things like NAT traversal, you probably > want to also send a modicum of RTP packets for sessions that are on > hold. Maybe some comfort noise, at a low bit rate. Otherwise, you are > going to loose your mappings, and the "going off hold" will be tricky. In this case, you probably don't even want to implement "on hold" using the a=sendonly attribute. Rather, you would re-INVITE to switch to a comfort noise codec, or something like that. Remember, we are not standardizing on hold, we are standardizing a primitive that might be used to implement on hold. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 18:19:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22653 for ; Tue, 28 Aug 2001 18:19:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29135; Tue, 28 Aug 2001 18:06:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA29043 for ; Tue, 28 Aug 2001 18:06:46 -0400 (EDT) Received: from market0 ([208.158.105.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22449 for ; Tue, 28 Aug 2001 18:05:25 -0400 (EDT) From: promotion@market.gogocity.com Received: from mail pickup service by market0 with Microsoft SMTPSVC; Tue, 28 Aug 2001 15:03:27 -0700 To: Date: Tue, 28 Aug 2001 15:03:27 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_AF53C_01C12FD2.9793D490" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 28 Aug 2001 22:03:27.0778 (UTC) FILETIME=[44115820:01C1300D] Subject: [Sip] ADV: Cell Phone Accessories Blow Out Start @ $5.95 Free Shipping Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_AF53C_01C12FD2.9793D490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Big Saving from GoGoCity. If you'd rather not receive any future promotional E-mails from GoGoCity.com, please click --> Un-Subscribe My E-mai l International Order Welcome FREE SHIPPING NOT APPLY Cell Phone Accessories Blow out Sale...!! Save Up to 80%...!! ***** FREE SHIPPING (in US only) ***** Why pay more in Retail Store..??? 1. Antenna Booster for All Cell Phone (1pack) 9. Antenna Booster for All Cell Phone (5 pack) Antenna Booster for All Cell Phone (1pack) large image Retail Price: $19.95 Blow Out Price: $5.95 (save 75%) More Details... Buy it NOW !! Free Shipping Antenna Booster for All Cell Phone (5 pack) large image Retail Price: $99.75 Blow Out Price: $19.95 (save 80%) More Details... Buy it NOW !! Free Shipping 2. NOKIA 51xx/6xx Black Car Charger 10. Nokia 3310/3390 Data Cable NOKIA 51xx/6xx Black Car Charger large image Retail Price: $19.99 Blow Out Price: $5.49 (save 73%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Data Cable large image Retail Price: $79.99 Blow Out Price: $19.95 (save 75%) More Details... Buy it NOW !! Free Shipping 3. NOKIA 82xx/33xx Black Car Charger 11. Nokia 8260/8290 Li-ion 1200mAh 12 Lights Flashing & Vib Battery NOKIA 82xx/33xx Black Car Charger large image Retail Price: $19.99 Blow Out Price: $5.49 (save 73%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Li-ion 1200mAh 12 Lights Flashing & Vib Battery large image Retail Price: $65.99 Blow Out Price: $24.95 (save 62%) More Details... Buy it NOW !! Free Shipping 4. NOKIA 51xx/61xx Hands Free with on/off Switch 12. NOKIA 51xx/6xx Data Cable NOKIA 51xx/61xx Hands Free with on/off Switch large image Retail Price: $19.99 Blow Out Price: $5.99 (save 70%) More Details... Buy it NOW !! Free Shipping NOKIA 51xx/6xx Data Cable large image Retail Price: $69.99 Blow Out Price: $14.95 (save 79%) More Details... Buy it NOW !! Free Shipping 5. NOKIA 82xx/33xx Hands Free with on/off Switch 13. Nokia 8260/8290 Li-ion 1200mAh Vibrating Battery NOKIA 82xx/33xx Hands Free with on/off Switch large image Retail Price: $19.99 Blow Out Price: $5.99 (save 70%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Li-ion 1200mAh Vibrating Battery large image Retail Price: $45.99 Blow Out Price: $24.95 (save 46%) More Details... Buy it NOW !! Free Shipping 6. NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery 14.Nokia 51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery large image Retail Price: $79.99 Blow Out Price: $34.95 (save 56%) More Details... Buy it NOW !! Free Shipping Nokia 51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery large image Retail Price: $70.99 Blow Out Price: $29.95 (save 58%) More Details... Buy it NOW !! Free Shipping 7. NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery 15. Nokia 3310/3390 Vertical Leather Magnetic Button Pouch NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery large image Retail Price: $45.99 Blow Out Price: $14.95 (save 67%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch large image Retail Price: $24.99 Blow Out Price: $9.95 (save 60%) More Details... Buy it NOW !! Free Shipping 8. Nokia 8260/8290 Data Cable 16. Nokia 8260/8290 Vertical Leather Magnetic Button Pouch NOKIA 51xx/6xx Data Cable large image Retail Price: $79.99 Blow Out Price: $19.95 (save 75%) More Details... Buy it NOW !! Free Shipping Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch large image Retail Price: $24.99 Blow Out Price: $9.95 (save 60%) More Details... Buy it NOW !! Free Shipping ------=_NextPart_000_AF53C_01C12FD2.9793D490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=20


Big Saving = from GoGoCity.=20 If you'd rather not receive any future promotional E-mails from = GoGoCity.com,=20
please click --> Un-Subscribe=20 My E-mail
International=20 Order Welcome=20 FREE SHIPPING NOT APPLY

=20
=20
Cell=20 Phone Accessories
Blow out Sale...!!
Save Up to 80%...!!
***** FREE=20 SHIPPING (in=20 US only) *****
Why pay more in = Retail Store..???

=20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20
1.=20 Antenna Booster for All Cell Phone = (1pack) 9.=20 Antenna Booster for All Cell Phone (5 = pack)
=20 Retail=20 Price: $19.95
Blow Out Price: $5.95 = (save 75%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
=20 Retail=20 Price: $99.75
Blow Out Price: $19.95 (save = 80%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
2.=20 NOKIA=20 51xx/6xx Black Car Charger 10.=20 Nokia 3310/3390 Data Cable
=20 Retail=20 Price: $19.99
Blow Out Price: $5.49 (save = 73%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $79.99
Blow Out Price: $19.95 (save = 75%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
3.=20 NOKIA=20 82xx/33xx Black Car Charger
 11.=20 Nokia 8260/8290 Li-ion 1200mAh 12=20 Lights Flashing=20 & Vib Battery
=20 Retail=20 Price: $19.99
Blow Out Price: $5.49 (save = 73%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $65.99
Blow Out Price: $24.95 (save = 62%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
4.=20 NOKIA=20 51xx/61xx Hands Free with on/off = Switch 12.=20 NOKIA=20 51xx/6xx Data Cable
=20 Retail=20 Price: $19.99
Blow Out Price: $5.99 (save = 70%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $69.99
Blow Out Price: $14.95 (save = 79%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
5.=20 NOKIA=20 82xx/33xx Hands Free with on/off = Switch 13.=20 Nokia 8260/8290 Li-ion 1200mAh Vibrating = Battery
=20 Retail=20 Price: $19.99
Blow Out Price: $5.99 (save = 70%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $45.99
Blow Out Price: $24.95 (save = 46%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
6.=20 NOKIA=20 51xx/6xx Li-ion 3200mAh Vibrating = Battery 14.Nokia=20 51xx/6xx Super Slim Black Li-ion 1200mAh Vib = Battery
=20 Retail=20 Price: $79.99
Blow Out Price: $34.95 (save = 56%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $70.99
Blow Out Price: $29.95 (save = 58%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
7.=20 NOKIA=20 51xx/6xx Black NIMH-700mAh Vibrating = Battery 15.=20 Nokia 3310/3390 Vertical Leather Magnetic Button = Pouch
=20 Retail=20 Price: $45.99
Blow Out Price: $14.95 (save = 67%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
 =20 Retail=20 Price: $24.99
Blow Out Price: $9.95 (save = 60%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
8.=20 Nokia 8260/8290 Data Cable 16.=20 Nokia 8260/8290 Vertical Leather Magnetic Button = Pouch
=20 Retail=20 Price: $79.99
Blow Out Price: $19.95 (save = 75%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping		 =20 Retail=20 Price: $24.99
Blow Out Price: $9.95 (save = 60%)
More=20 Details...
Buy it = NOW !!=20 Free=20 Shipping
------=_NextPart_000_AF53C_01C12FD2.9793D490-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 19:11:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23544 for ; Tue, 28 Aug 2001 19:11:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00122; Tue, 28 Aug 2001 18:50:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00093 for ; Tue, 28 Aug 2001 18:50:05 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23013 for ; Tue, 28 Aug 2001 18:48:47 -0400 (EDT) From: Jin-Gen.Wang@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id WAA18232; Tue, 28 Aug 2001 22:49:52 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id WAA24704; Tue, 28 Aug 2001 22:49:42 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <3RFX7Q8H>; Tue, 28 Aug 2001 16:49:41 -0600 Message-ID: To: jdrosen@dynamicsoft.com Cc: sip@ietf.org Subject: RE: [Sip] issues on TCP support and Record-Route Date: Tue, 28 Aug 2001 16:46:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, August 28, 2001 3:30 PM To: Wang, Jin-Gen; sip@ietf.org Subject: RE: [Sip] issues on TCP support and Record-Route > -----Original Message----- > From: Jin-Gen.Wang@Level3.com [mailto:Jin-Gen.Wang@Level3.com] > Sent: Friday, August 24, 2001 7:05 PM > To: sip@ietf.org > Subject: [Sip] issues on TCP support and Record-Route > > > I am sorry if these issues have been discussed before. I have > two issues > concerning carrier grade SIP applications. > > (1) When using a stream based transport protocol, e.g., TCP, SIP poses > several problems because SIP messages don't carry total > length in a fixed > position, e.g., the first 4 bytes of the messages: > > (a) Although the messages can be parsed in normal conditions, > our tests > showed that the performance of using current SIP spec is several times > slower than carrying a total length in front of SIP messages. Several times! Yikes! Our performance results show a small decrease in performance (on the order for 10%), and we suspect that has a lot more to do with issues surrounding buffer sizing, delayed ACK, etc. Sounds like a problem with your implementation, rather than a fundamental problem with length indicators. [Jin-Gen Wang] I don't think this is related to buffer sizing, etc. I do agree that it's implementation related. I am not convinced it's a small overhead unless some people can show their results. Even 10% is not trivial. Again, I am talking about carrier grade software. If it has been raised several times before, it may indicate there is an issue. I am not sure how many applications using TCP are there in a high stress environment. Other people may raise this issue again in the future. > > (b) There is no robust way to handle malformed messages > coming from TCP > without a total length in a fixed position. For example, a > message doesn't > have a correct end of message headers. The spec talks about how to handle the case where the length is not present. If its wrong, you end up with an overly long or overly short payload, which results in an error being generated. All of this seems to work for HTTP, which supports persistent connections even, so I have a hard time believing its unworkable for SIP. [Jin-Gen Wang] If one message is missing end of headers or has incorrect end of headers, the next message will be skewed. This is not acceptable for processing phone calls. I am not sure how many people use HTTP to do phone calls. > > So what is the reason that SIP doesn't specify a total > message length in a > fixed position. I propose to carry a total length of each > message in the > first 4 bytes for stream-based transport protocol. Well, this is more of a transport issue. Sounds like what you are asking for is message oriented connection transport. SCTP provides such a thing. [Jin-Gen Wang] After all, SIP is message oriented. It happens that UDP packets encapsulate messages for you. But for TCP, it's different. I haven't seen a solid reason NOT to carry the message length in a fixed position. The protocols I have seen in telecommunications so far carry length in fixed positions. What damage will it cause if we do carry the message length in a fixed position? > > (2) The Record-Route header has been overloaded to be used by > subsequent > requests in both directions. This causes problems when one > side of proxy > uses TCP and the other side uses UDP, although bis-4 does > allow Record-Route > header to carry "transport=value" parameter. Some people have > suggested to > rewrite the Record-Route header for final responses. This > suggestion posts > performance overhead for all final responses. Sure, but no more than any other response processing thats done in a proxy (like stripping a via header). Compared to the rest of the overall transaction processing, I suspect that the overall contribution to performance for rewriting the RR in a 2xx is tiny, so fixing this is not likely to do much for you. [Jin-Gen Wang] I think you also need to do this rewriting for other final responses. But if we can avoid such overhead in a standard way, why not? I propose to > use different > names when specify transport protocol parameters, e.g., transport_in = > TCP;transport_out=UDP. I'll also note that it is often necessary to specify a different port and IP address, so that this would not be sufficient. [Jin-Gen Wang] I agree. I just want to bring up an example because we will still have a problem in the following scenario: UAC ---(UDP only) ---> PS1 --- TCP ---> PS2 --- UDP ---> UAS. Let's say PS2 rewrite Record-Route to use TCP for 2xx coming back from UAS. Now if PS1 does not record-route, UAC will see TCP as transport protocol to send BYE over which it cannot honor. I think there are issues regarding the use of Record-Route header in mixing transport protocol scenarios. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Tue Aug 28 19:58:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24160 for ; Tue, 28 Aug 2001 19:58:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02965; Tue, 28 Aug 2001 19:42:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02934 for ; Tue, 28 Aug 2001 19:42:35 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23998 for ; Tue, 28 Aug 2001 19:41:16 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f7SNgav01188 for ; Wed, 29 Aug 2001 01:42:36 +0200 (MEST) Received: FROM esealnt135.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Aug 29 01:42:35 2001 +0200 Received: by esealnt135.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Aug 2001 01:42:35 +0200 Message-ID: <1254192C94D3D411B8060008C7E6AEEB03F4D626@esealnt408> From: "Stephen Terrill (ERA)" To: Dean Willis , Vijaya Venkatachalam , sip@ietf.org Subject: RE: [Sip] 3gpp & sip Date: Wed, 29 Aug 2001 01:42:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, Thanks for the advertising Dean :-))I am confident that yours can do many other things as well. One aspect which was left of this was Cx interface - which is between the S-CSCF and the HSS - the interface is diameter. More information can be found within TS 23.228 and TS 23.002. The latest version of these documents can be found http://www.3gpp.org/ftp/Specs/2001-06/Rel-5/23_Series/ There may be more things that are left out as well. One warning though - there has been "changes" to this which have not been incorperated until they are approved in September. ..//Steve -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Tuesday, August 28, 2001 12:57 AM To: Vijaya Venkatachalam; sip@ietf.org Subject: Re: [Sip] 3gpp & sip That's actually a question better asked in 3GPP SA2. They have a slew of interfaces, each with a symbolic name like "The Sh interface". There's also some debate between various 3GPP groups as to which interfaces exist and what to call them, for example "SIP+" and "ISC" interface(s). In general, SIP is used between UE and P-CSCF, P-CSCF and P-CSCF, P-CSCF and I-CSCF, I-CSCF and S-CSCF, S-CSCF and AS, and AS-AS, and of course the inverses of those. There's some debate about whether AS may also directly interface to other SIP nodes withot using S-CSCF and I-CSCF, or may go directly to I-CSCF or other firewall proxy without transiting S-CSCF. Mine can -- why pay extra for more S-CSCF than one really needs? But it's configurable so that people who really want to spend more money can do so . . . Free enterprise loves Darwin's dead-end branches if they're well-funded. There's also another edge-proxy node called a THIG that may appear in various locations and speaks SIP. -- Dean ----- Original Message ----- From: "Vijaya Venkatachalam" To: Sent: Monday, August 27, 2001 12:53 PM Subject: [Sip] 3gpp & sip > Hi, > > Which all interfaces in 3GPP are using SIP? > > Thanks, > Vijaya > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 01:20:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01586 for ; Wed, 29 Aug 2001 01:20:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA13575; Wed, 29 Aug 2001 01:07:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA13535 for ; Wed, 29 Aug 2001 01:07:12 -0400 (EDT) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAB29568 for ; Wed, 29 Aug 2001 01:05:53 -0400 (EDT) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Aug 2001 22:05:19 -0700 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'sip@ietf.org'" Date: Tue, 28 Aug 2001 22:05:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] Offer/Counter-offer/answer changes. Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Okay let's see if this old trick can solicit some comment :) I propose the following text is added to the next RFC2543bis document to describe the important offer/counter-offer/answer model. The changed text is marked. [Note no changes are required to Appendix B.] 10.15 Content-Disposition Content-Disposition = "Content-Disposition" ":" disposition-type *( ";" disposition-param ) disposition-type = "render" | "session" | "icon" | "alert" | "newsession" ^^^^^^^^^^^^^^ | disp-extension-token disposition-param = "handling" "=" ( "optional" | "required" | other-handling ) | generic-param other-handling = token disp-extension-token = token The Content-Disposition header field describes how the message body or, in the case of multipart messages, a message body part is to be interpreted by the UAC or UAS. The SIP header extends the MIME Content-Type (RFC 1806 [33]). The value "session" indicates that the body part describes a session, for either calls or early (pre-call) media. The value "render" indicates that the body part should be displayed or otherwise rendered to the user. For backward-compatibility, if the Content- Disposition header is not missing, bodies of Content-Type ^^^ I don't think the "not" is supposed to be here application/sdp imply the disposition "session", while other content types imply "render". * The value "newsession" indicates that the message body describes a * session, however, it indicates that this message body is start of a new * session content negotiation. The "newsession" value may only be * used in INVITE 200 OK responses (and provisional INVITE responses if * explicitly allowed by extensions) when the original INVITE request contained a * message body of "session" disposition type. As such, the "newsession" value * means that the message body in the INVITE request is ignored. For * Content-Type application/sdp this means that the 200 OK contains a * new SDP offer and that the ACK must contain an SDP answer. There does not need * to be any correlation between the "newsession" message body and the message * body in the original INVITE. The "newsession" value should always be used with * the "handling=required" disposition parameter. If a UAC is unwilling or * unable to use the "newsession" message body it should simply treat the * message body as invalid. The disposition type "icon" indicates that the body part contains an image suitable as an iconic representation of the caller or callee. The value "alert" indicates that the body part contains information, such as an audio clip, that should be rendered instead of ring tone. The handling parameter, handling-parm, describes how the UAS should react if it receives a message body whose content type or disposition type it does not understand. If the parameter has the value "optional", the UAS MUST ignore the message body; if it has the value "required", the UAS MUST return 415 (Unsupported Media Type). If the handling parameter is missing, the value "required" is to be assumed. If this header field is missing, the MIME type determines the default content disposition. If there is none, "render" is assumed. ^^^^^^ isn't this paragraph repeating what was said in 2nd paragraph Comments? Robert. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 03:10:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17522 for ; Wed, 29 Aug 2001 03:10:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22599; Wed, 29 Aug 2001 02:59:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22570 for ; Wed, 29 Aug 2001 02:59:40 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAB17428 for ; Wed, 29 Aug 2001 02:58:22 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7T6xWv21857; Wed, 29 Aug 2001 08:59:32 +0200 (MEST) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.33]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7T6xWC23435; Wed, 29 Aug 2001 09:59:32 +0300 (EET DST) Message-ID: <3B8C92CF.4A0B1169@lmf.ericsson.se> Date: Wed, 29 Aug 2001 09:59:27 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Kim Liu CC: Jonathan Rosenberg , "'sip@ietf.org'" Subject: Re: [Sip] Open Issue #146: Re-use disabled streams References: <3B853FFB.C417F160@lucent.com> Content-Type: multipart/mixed; boundary="------------8E25C7BD0E1B52FD6DBAA61E" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------8E25C7BD0E1B52FD6DBAA61E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, How about using the FID (or something similar) as a stream identifier, identifying a stream for the whole session (not only within a specific SDP)? Then it would be very easy to add/remove/change/whatever streams. For example, assume a case where I set up a session with 5 streams. Then, later in the session, I want to add one stream and remove one of the old ones. By using identifiers one does not have to include any information about the streams that are not affected by the mid-session change. Regards, Christer Holmberg Ericsson Finland Kim Liu wrote: > > Jonathan Rosenberg wrote: > [deleted] > > So, the question is this: do we allow reuse of disabled streams in this > > fashion? > [snipped] > > Proposal: > > > > There was no concrete proposal yet. My leaning is to disallow reuse, and > > stick with what we have. > > > > Comments? > > My inclination is to allow reuse, but I don't think it can > be done. Particularly given the restriction on dynamic PT > reuse in issue #23. Since the INVITE with SDP is used for > recovery, reusing/rewriting an old media stream slot in the > SDP might erase/hide information about the previous state > of the call (which dynamic PTs have been used, plus any > endpoint, media, or application specific information > associated with the closed media stream) though I am unaware > of any application which is doing this today. Unfortunately, > since the INVITE/200 + SDP is used for call recovery, > that reuse will have to be avoided in order to maintain > a full history/state of the call in case recovery is > necessary. > > Kim > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------8E25C7BD0E1B52FD6DBAA61E Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------8E25C7BD0E1B52FD6DBAA61E-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 05:14:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18648 for ; Wed, 29 Aug 2001 05:14:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26027; Wed, 29 Aug 2001 05:01:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26002 for ; Wed, 29 Aug 2001 05:01:52 -0400 (EDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18510 for ; Wed, 29 Aug 2001 04:59:02 -0400 (EDT) Received: from f02n16e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 2.0) with ESMTP id f7T8uHT268702 for ; Wed, 29 Aug 2001 18:56:17 +1000 Received: from d23m0018.cn.ibm.com ([9.185.50.18]) by f02n16e.au.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7T8xaD132624 for ; Wed, 29 Aug 2001 18:59:36 +1000 Importance: Normal Subject: [Sip] Question on basic authentication of SIP To: sip@ietf.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: "Wei BJ Lu" Date: Wed, 29 Aug 2001 17:06:07 +0800 X-MIMETrack: Serialize by Router on d23m0018/23/M/IBM(Release 5.0.6 |December 14, 2000) at 29/08/2001 16:59:52 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hi, I have a question on basic authentication of SIP. To my understanding, SIP uses the HTTP basic and digest authentication mechanism. When using basic authentication, the server will chanllenge client with a "realm" parameter to indicate which server is in need of authentication. But the client only need to provide encoded form of "username:password" in credential. Since a SIP request may pass more than one server before it reaches the destination and all servers could require authentication, so a SIP request may contain more than one credentials. The result is that a server cannot distinguish which credential is corresponding to the chanllenge sent by it. I do not know whether there is already some ways to solve this problem. For the time being, I just let the server to compare all the passwords in all the credentials with passwords stored at server. But it is not efficient. My opinion is maybe we could add a "realm" parameter in credentials of basic authentication. Although this will bring difference between SIP and HTTP basic authentication, I think it is necessary if we consider the difference between SIP and HTTP --- a HTTP request will only pass(reach) one HTTP server while a SIP request will probably pass more than one SIP server. Dr. Lu Wei Staff Research Member, Infrastructure Technology IBM China Research Lab. 4/F, HaoHai Building, No.7, 5th Street, Shangdi, Beijing 100085 Phone: (8610)62986677-549 Tie-line: 905-549 Fax: (8610)82899633/82899634 Email: luw@cn.ibm.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 07:31:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20453 for ; Wed, 29 Aug 2001 07:31:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28532; Wed, 29 Aug 2001 07:21:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28508 for ; Wed, 29 Aug 2001 07:21:54 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20081; Wed, 29 Aug 2001 07:20:33 -0400 (EDT) Message-Id: <200108291120.HAA20081@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 29 Aug 2001 07:20:33 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-nat-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Extensions for NAT Traversal Author(s) : J. Rosenberg, J. Weinberger, H. Schulzrinne Filename : draft-ietf-sip-nat-00.txt Pages : 13 Date : 28-Aug-01 In this draft, we discuss how SIP can traverse existing, non-SIP aware NATs. Our approach is to make SIP 'NAT friendly' with two minor extensions. The first allows for responses to UDP requests to go back to the source port of the request. The second allows a registrar to use the source IP address and port instead of the Contact in a REGIS- TER. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-nat-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-nat-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-nat-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: <20010828120947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-nat-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-nat-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010828120947.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 07:33:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20491 for ; Wed, 29 Aug 2001 07:33:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28573; Wed, 29 Aug 2001 07:22:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28545 for ; Wed, 29 Aug 2001 07:22:00 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20102; Wed, 29 Aug 2001 07:20:40 -0400 (EDT) Message-Id: <200108291120.HAA20102@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 29 Aug 2001 07:20:40 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : The Refer Method Author(s) : R. Sparks Filename : draft-ietf-sip-refer-00.txt Pages : 14 Date : 28-Aug-01 This document defines the REFER method. This SIP extension requests that the recipient REFER to a resource provided in the request. This can be used to enable many applications, including Call Transfer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-refer-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-refer-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: <20010828120957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-refer-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-refer-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010828120957.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 08:12:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22211 for ; Wed, 29 Aug 2001 08:12:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29992; Wed, 29 Aug 2001 08:01:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29903 for ; Wed, 29 Aug 2001 08:01:19 -0400 (EDT) Received: from rsys000a.roke.co.uk ([193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21597 for ; Wed, 29 Aug 2001 07:59:58 -0400 (EDT) Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Aug 2001 12:59:56 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4186F9E3C@rsys002a.roke.co.uk> From: "Price, Richard" To: "'Jonathan Rosenberg'" , "'sip@ietf.org'" , "'rohc@cdt.luth.se'" Date: Wed, 29 Aug 2001 12:59:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [Sip] RE: Encapsulating EPIC in UDPComp Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Hi, A few more thoughts on the dictionary structure enclosed inline. Regards, Richard P > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, August 22, 2001 5:51 PM > To: Price, Richard; Jonathan Rosenberg; 'sip@ietf.org'; > 'rohc@cdt.luth.se' > Subject: RE: Encapsulating EPIC in UDPComp > > > -----Original Message----- > > From: Price, Richard [mailto:richard.price@roke.co.uk] > > Sent: Wednesday, August 22, 2001 8:27 AM > > To: 'Jonathan Rosenberg'; 'sip@ietf.org'; 'rohc@cdt.luth.se' > > Subject: RE: Encapsulating EPIC in UDPComp > > > > > Richard is exactly correct that the cost of a general purpose > > > decompressor like this is a hit in overhead. With purely static > > > codebook indices, the overhead is quite large as the results > > > below show. I agree totally that some kind of Huffman coding is > > > needed. I have been thinking about this, and I have a proposal > > > that is different from what Richard is proposing. > > > > On the contrary, your proposal is exactly how I hoped Huffman > > coding would be introduced! > > Great! I had thought you were proposing that a pre-agreed > upon Huffman code > be referenced during startup time, or that it was downloaded > at startup > time. The proposal here is that the Huffman codes are > constructed as you go, > since you need that to support dynamic codebooks, which I > think we all agree > is needed. Of course, one can easily support downloading of > the codes at > start time if a primitive is defined which is "WRITE this, > but don't output > anything into a decompressed message". > > > > > > My proposal would be to make the support for huffman coding > > > very general purpose, and based on a tree-like structure where > > > the codes are dependent on previous elements. Such a hierarchical > > > structure is needed, I think, to support the TCCB and EPIC > > > algorithms. > > > > Yes. In EPIC, the Huffman codes are local to each dictionary item. > > I think that you will need such a thing in general to achieve > really good > compression. > > > > So, the idea is that when you write into the codebook, you > > > provide a bit which says whether this write takes place at the > > > current "level" in the hierarchy, or back at the top. Then, you > > > provide a bitstring that represents the huffman code for > the token, > > > followed by the token. > > > > I would propose to take this one step further, and make the Huffman > > code indicate not only the location of the dictionary item, but also > > the type of token (READ, WRITE etc.). > > Excellent idea! Our goal should ultimately be that the > encoder output is > always a series of huffman codes, with some extra stuff to > write the strings > into the codebooks that are not already there. Some more > thoughts on that > below. > > > > We could do this as follows: > > > > - Keep all of the existing token types (READ, WRITE, > > WRITE-REFERENCE) > > but prefix them with a large bit pattern, say "11111111". > > > > - Reserve the remaining prefix codes ("00000000" to > "11111110") for > > the Huffman codes. > > > > - When a token is sent explicitly, attach a "shorthand" > Huffman code > > that can be used to send the token in future. > > > > When we send the Huffman code, it implicitly specifies the > token type > > (READ, WRITE etc.) as well as the location of the item to be read or > > written. > > I agree with that, but I'm not sure that you want to use > these large bit > patterns to represent the initial commands. The result will > be that initial > WRITEs and READs are really, really large. You only need > these large codes > when there are lots of Huffman codes in any particular table. > That won't > always be the case at all. > > One way to solve this is to have a really nice way to > dynamically construct > the Huffman codes. Lets say you have a Huffman code > represented by some > tree. Adding a new string can be done in only one way. You > take an existing > vertex somewhere in the tree, and remove the subtree (if > present). Add two > new branches below that vertex. Add the subtree to the right > branch, and > place your new string to the the other. > > Here's an example Huffman tree. Assume 0 is left, 1 is right: > > > /\ > /\ A > B C > > THis corresponds to: > > 00 B > 01 C > 1 A > > Now, we wish to add D. TO do that, we send a command that > reads like: "WRITE > into the table, spltting at 00, and the value is D". So, the > decoder finds > the vertex 00. TO do this, it starts at the root, goes left, > and then left > again. This is the vertex which currently encodes B. It > removes B, adds two > branches, places B on the right, and the new element on the left: > > /\ > /\ A > /\ C > D B > > Now, this table looks like: > > 1 A > 01 C > 001 B > 000 D > > So, the idea is that we always start with a default table > that has two codes > in it, which says "WRITE" in one of the two places: > > initial table: > > Code output > ------------------- > 0 WRITE the string which follows by splitting the > indicated vertex > in the curren table > 1 WRITE the string which follows into the root table > (i.e, change > contexts) by splitting the indicated vertex > > This code would need to be followed by the identity of the > vertex, and then > the text itself. > > This way, you start off with very efficient codes that write > into the table. > As the table gets larger, you use the efficient codes for the common > strings, and the code for writing into the table gets longer. This is a very nice idea but I'm not sure how to make it robust against misordering or packet loss between the compressor and decompressor. The compressor will need to continue sending the explicit form of the token until it receives confirmation that it has arrived at the decompressor, after which it can switch to the more efficient Huffman code for the token. Using the above technique, can we make sure that writing the same Huffman code into the table more than once will not cause problems? > > Rather than simply enclosing the text as a string, we should > either Huffman > encode that with a standardized table, or else take all of > the text in a > message, put them together, compress it as an independent > blob, and then > send that together. > > > > > > > The advantage of this approach is that schemes like EPIC and > > Lempel-Ziv > > only ever send Huffman codes when reading and writing entries in the > > dictionary. Once UDPComp has successfully transmitted these > > Huffman codes > > to the decompressor there is no need to send the tokens > explicitly any > > more. This makes the overhead of UDPComp negligible (in > fact, the only > > overhead is the reserved bit pattern "11111111" that we used to send > > the tokens explicitly in the first place). > > Right. My proposal above reduces that as well, since this > overhead is not > once per message, but once per new token. > > > > > > > It is the responsibility of the encoder to make sure that > each code > > > is a valid prefix code. When the encoder sends a read command, it > > > contains a bit which indicates whether the read is from the top of > > > the tree or the current position, followed by the code. > > > > Agreed. However we should make this indicator flag part of > the Huffman > > code as well, so that we don't have to send it explicitly > every time. > > Right, that is the proposal above. > > > > > An interesting improvement is that I can specify a command which > > > says "READ code XX, and then read the next N symbols in the tree > > > if the number of children at each node is 1, in which case you > > > have no choice about the next symbol anyway". This is useful for > > > trees that are really deep, as opposed to wide. If you think about > > > it, this covers LZSS, which can be viewed as a "hierarchical" > > > codebook where each node is a single character, and the tree > > > is one where each node has only one child, the next character. > > > > > > > A similar enhancement might be to allow 1 Huffman code to indicate > > several consecutive choices of branches on the tree. This is > > especially useful when there is a single very likely route through > > the tree, as we can specify this route using only a single short > > Huffman code. > > Hmm, interesting idea. You need to be careful about this, > though, since > management of this tangle of tables can be complex. It would > be really nice > to maintain a simple structure. > > I think the way to do what you are proposing is to define a > command which is > "WRITE into the current table, splitting the specified > vertex. The element > to write is found by reading from here with the following > huffman codes: > XXX, and then the next table is the existing one at the end > of the read". > > This turns the tree of tables into a more general purpose > digraph, which is > probably a really good idea. It can save a lot of overhead in > the management > of the table. Protocols, like SIP, have many "paths" through > the message > which can arrive at a common piece of data (for example, the > SIP URL). This > way, the encoding for the SIP URL appears only once in > memory, rather than > based on each path to get to it. Once the decompressor arrives at the common piece of data (say the SIP URL), how should it decide where to go next? Algorithms like EPIC and TCCB automatically jump back to the dictionary item which preceded the SIP URL and keep going from there. Alternatively we could just link the SIP URL to every possible dictionary item that might follow it. This is simpler but less efficient - the decompressor "forgets" which part of the SIP message happened to contain the SIP URL and needs to be sent this information again. > > Maybe time to start writing all of this up in an updated I-D > for UDPComp, > since its probably hard to get it from these terse emails.... > > -Jonathan R. > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="RMRL-Disclaimer.txt" Content-Disposition: attachment; filename="RMRL-Disclaimer.txt" Content-Transfer-Encoding: 7bit The information contained in this e-mail and any attachments is confidential to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 11:51:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01784 for ; Wed, 29 Aug 2001 11:51:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06557; Wed, 29 Aug 2001 11:33:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06528 for ; Wed, 29 Aug 2001 11:32:55 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01287 for ; Wed, 29 Aug 2001 11:31:34 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7TFUqob028401; Wed, 29 Aug 2001 11:30:52 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Aug 2001 11:31:43 -0400 Message-ID: From: Jonathan Rosenberg To: "'Jin-Gen.Wang@Level3.com'" Cc: sip@ietf.org Subject: RE: [Sip] issues on TCP support and Record-Route Date: Wed, 29 Aug 2001 11:31:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Jin-Gen.Wang@Level3.com [mailto:Jin-Gen.Wang@Level3.com] > Sent: Tuesday, August 28, 2001 6:46 PM > To: jdrosen@dynamicsoft.com > Cc: sip@ietf.org > Subject: RE: [Sip] issues on TCP support and Record-Route > > > > -----Original Message----- > > From: Jin-Gen.Wang@Level3.com [mailto:Jin-Gen.Wang@Level3.com] > > Sent: Friday, August 24, 2001 7:05 PM > > To: sip@ietf.org > > Subject: [Sip] issues on TCP support and Record-Route > > > > > Several times! Yikes! Our performance results show a small decrease in > performance (on the order for 10%), and we suspect that has a > lot more to do > with issues surrounding buffer sizing, delayed ACK, etc. Sounds like a > problem with your implementation, rather than a fundamental > problem with > length indicators. > > [Jin-Gen Wang] I don't think this is related to buffer > sizing, etc. Do you have concrete proof that says that the overhead of not having a length indicator is going to be the primary source of the reduction in throughput? > I do > agree that it's implementation related. I am not convinced > it's a small > overhead unless some people can show their results. Those are our results. Whether you choose to believe me or not is your own choice. > > > > (b) There is no robust way to handle malformed messages > > coming from TCP > > without a total length in a fixed position. For example, a > > message doesn't > > have a correct end of message headers. > > The spec talks about how to handle the case where the length > is not present. > If its wrong, you end up with an overly long or overly short > payload, which > results in an error being generated. > > All of this seems to work for HTTP, which supports persistent > connections > even, so I have a hard time believing its unworkable for SIP. > > [Jin-Gen Wang] If one message is missing end of headers or > has incorrect end > of headers, the next message will be skewed. This is not > acceptable for > processing phone calls. I am not sure how many people use > HTTP to do phone > calls. If the length field you are proposing is too long, not present, or too short, the next message will also be skewed. The failure cases seem identical. > > > > > So what is the reason that SIP doesn't specify a total > > message length in a > > fixed position. I propose to carry a total length of each > > message in the > > first 4 bytes for stream-based transport protocol. > > Well, this is more of a transport issue. Sounds like what you > are asking for > is message oriented connection transport. SCTP provides such a thing. > > [Jin-Gen Wang] After all, SIP is message oriented. It happens that UDP > packets encapsulate messages for you. But for TCP, it's > different. I haven't > seen a solid reason NOT to carry the message length in a > fixed position. The > protocols I have seen in telecommunications so far carry > length in fixed > positions. > > What damage will it cause if we do carry the message length in a fixed > position? Total destruction of backwards compatibility with every single TCP enabled SIP element? Re-invention of message-oriented connection oriented transports? My question still remains - if you think this is such a problem, what is wrong with using SCTP which does what you are asking for? > Sure, but no more than any other response processing thats > done in a proxy > (like stripping a via header). Compared to the rest of the overall > transaction processing, I suspect that the overall contribution to > performance for rewriting the RR in a 2xx is tiny, so fixing > this is not > likely to do much for you. > > [Jin-Gen Wang] I think you also need to do this rewriting for > other final > responses. But if we can avoid such overhead in a standard > way, why not? Because it breaks backwards compatibility. Because it is not clear it provides any concrete benefits. Unkown benefit + high cost - how is that a wise design choice? > I'll also note that it is often necessary to specify a > different port and IP > address, so that this would not be sufficient. > > [Jin-Gen Wang] I agree. I just want to bring up an example > because we will > still have a problem in the following scenario: > > UAC ---(UDP only) ---> PS1 --- TCP ---> PS2 --- UDP ---> UAS. > > Let's say PS2 rewrite Record-Route to use TCP for 2xx coming > back from UAS. > Now if PS1 does not record-route, UAC will see TCP as > transport protocol to > send BYE over which it cannot honor. I think there are issues > regarding the > use of Record-Route header in mixing transport protocol scenarios. This is a well known problem, for which text in -04 already discusses. I have improved this text further in -05, and the issue has already been discussed extensively on the list. You cannot RR with a transport param not equal to UDP unless you are in a private network where you know the transport capabilities of the hop that RR's on the side you wish to use a different transport. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 12:32:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02684 for ; Wed, 29 Aug 2001 12:32:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08245; Wed, 29 Aug 2001 12:20:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08222 for ; Wed, 29 Aug 2001 12:20:22 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02369 for ; Wed, 29 Aug 2001 12:19:01 -0400 (EDT) From: Jin-Gen.Wang@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id QAA24469; Wed, 29 Aug 2001 16:20:21 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id QAA11211; Wed, 29 Aug 2001 16:20:13 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <3RFX88XG>; Wed, 29 Aug 2001 10:20:12 -0600 Message-ID: To: jdrosen@dynamicsoft.com Cc: sip@ietf.org Subject: RE: [Sip] issues on TCP support and Record-Route Date: Wed, 29 Aug 2001 10:16:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, August 29, 2001 9:32 AM To: Wang, Jin-Gen Cc: sip@ietf.org Subject: RE: [Sip] issues on TCP support and Record-Route > -----Original Message----- > From: Jin-Gen.Wang@Level3.com [mailto:Jin-Gen.Wang@Level3.com] > Sent: Tuesday, August 28, 2001 6:46 PM > To: jdrosen@dynamicsoft.com > Cc: sip@ietf.org > Subject: RE: [Sip] issues on TCP support and Record-Route > > > > -----Original Message----- > > From: Jin-Gen.Wang@Level3.com [mailto:Jin-Gen.Wang@Level3.com] > > Sent: Friday, August 24, 2001 7:05 PM > > To: sip@ietf.org > > Subject: [Sip] issues on TCP support and Record-Route > > > > > Several times! Yikes! Our performance results show a small decrease in > performance (on the order for 10%), and we suspect that has a > lot more to do > with issues surrounding buffer sizing, delayed ACK, etc. Sounds like a > problem with your implementation, rather than a fundamental > problem with > length indicators. > > [Jin-Gen Wang] I don't think this is related to buffer > sizing, etc. Do you have concrete proof that says that the overhead of not having a length indicator is going to be the primary source of the reduction in throughput? > I do > agree that it's implementation related. I am not convinced > it's a small > overhead unless some people can show their results. Those are our results. Whether you choose to believe me or not is your own choice. [Jin-Gen Wang] Again, our tests showed this is the reason. Again, I agree the percentage of reduction is implementation related. However, even in your implementation, 10% drop is not trivial. One disadvantage of the design (no length field in a fixed position) is that we have to mix message parsing with each TCP connection. This limits the choice of implementations. > > > > (b) There is no robust way to handle malformed messages > > coming from TCP > > without a total length in a fixed position. For example, a > > message doesn't > > have a correct end of message headers. > > The spec talks about how to handle the case where the length > is not present. > If its wrong, you end up with an overly long or overly short > payload, which > results in an error being generated. > > All of this seems to work for HTTP, which supports persistent > connections > even, so I have a hard time believing its unworkable for SIP. > > [Jin-Gen Wang] If one message is missing end of headers or > has incorrect end > of headers, the next message will be skewed. This is not > acceptable for > processing phone calls. I am not sure how many people use > HTTP to do phone > calls. If the length field you are proposing is too long, not present, or too short, the next message will also be skewed. The failure cases seem identical. [Jin-Gen Wang] I agree. This is the same if the content length in the current spec is mal-formed. However, when the message length is correct, we can catch all sorts of mal-formed SIP messages without affecting the next message, which is much more robust in my opinion. Again, I am talking about carrier grade software (at least four 9s reliability). > > > > > So what is the reason that SIP doesn't specify a total > > message length in a > > fixed position. I propose to carry a total length of each > > message in the > > first 4 bytes for stream-based transport protocol. > > Well, this is more of a transport issue. Sounds like what you > are asking for > is message oriented connection transport. SCTP provides such a thing. > > [Jin-Gen Wang] After all, SIP is message oriented. It happens that UDP > packets encapsulate messages for you. But for TCP, it's > different. I haven't > seen a solid reason NOT to carry the message length in a > fixed position. The > protocols I have seen in telecommunications so far carry > length in fixed > positions. > > What damage will it cause if we do carry the message length in a fixed > position? Total destruction of backwards compatibility with every single TCP enabled SIP element? Re-invention of message-oriented connection oriented transports? My question still remains - if you think this is such a problem, what is wrong with using SCTP which does what you are asking for? [Jin-Gen Wang] The backward compatibility is a very legitimate concern. However, that doesn't mean we shouldn't change anything. I am trying to understand the protocol design idea behind missing message length in a fixed position. I haven't seen a solid reason yet. It seems to me that to force people using SCTP in our case is against "the transport protocol neutral principal" of using SIP. > Sure, but no more than any other response processing thats > done in a proxy > (like stripping a via header). Compared to the rest of the overall > transaction processing, I suspect that the overall contribution to > performance for rewriting the RR in a 2xx is tiny, so fixing > this is not > likely to do much for you. > > [Jin-Gen Wang] I think you also need to do this rewriting for > other final > responses. But if we can avoid such overhead in a standard > way, why not? Because it breaks backwards compatibility. Because it is not clear it provides any concrete benefits. Unkown benefit + high cost - how is that a wise design choice? > I'll also note that it is often necessary to specify a > different port and IP > address, so that this would not be sufficient. > > [Jin-Gen Wang] I agree. I just want to bring up an example > because we will > still have a problem in the following scenario: > > UAC ---(UDP only) ---> PS1 --- TCP ---> PS2 --- UDP ---> UAS. > > Let's say PS2 rewrite Record-Route to use TCP for 2xx coming > back from UAS. > Now if PS1 does not record-route, UAC will see TCP as > transport protocol to > send BYE over which it cannot honor. I think there are issues > regarding the > use of Record-Route header in mixing transport protocol scenarios. This is a well known problem, for which text in -04 already discusses. I have improved this text further in -05, and the issue has already been discussed extensively on the list. You cannot RR with a transport param not equal to UDP unless you are in a private network where you know the transport capabilities of the hop that RR's on the side you wish to use a different transport. [Jin-Gen Wang] Again, it seems to me that this is against "the transport protocol neutral" principle of using SIP. If it is a well known problem, doesn't that mean the Record-Route idea needs to be looked again? -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 12:54:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03062 for ; Wed, 29 Aug 2001 12:54:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08746; Wed, 29 Aug 2001 12:37:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08717 for ; Wed, 29 Aug 2001 12:37:13 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02751 for ; Wed, 29 Aug 2001 12:35:54 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7TGauK00705; Wed, 29 Aug 2001 18:36:56 +0200 (MEST) Received: from ericsson.com (ppp9.lmf.ericsson.se [131.160.102.9]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7TGarr11350; Wed, 29 Aug 2001 19:36:54 +0300 (EET DST) Message-ID: <3B8D1A24.9372F1E7@ericsson.com> Date: Wed, 29 Aug 2001 19:36:52 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Dean Willis CC: Vijaya Venkatachalam , sip@ietf.org Subject: Re: [Sip] 3gpp & sip References: <3B8513E5.625F03D5@lmf.ericsson.se> <3B8A88FE.815CCEE0@ulticom.com> <002f01c12f4b$91817e40$ad036e3f@flak> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Just to add a few more interfaces using SIP in 3GPP. The S-CSCF and BGCF, BGCF and BGCF, BGCF and MGCF, and S-CSCF and MRF. /Miguel Dean Willis wrote: > > That's actually a question better asked in 3GPP SA2. They have a slew of > interfaces, each with a symbolic name like "The Sh interface". There's also > some debate between various 3GPP groups as to which interfaces exist and > what to call them, for example "SIP+" and "ISC" interface(s). > > In general, SIP is used between UE and P-CSCF, P-CSCF and P-CSCF, P-CSCF > and I-CSCF, I-CSCF and S-CSCF, S-CSCF and AS, and AS-AS, and of course the > inverses of those. There's some debate about whether AS may also directly > interface to other SIP nodes withot using S-CSCF and I-CSCF, or may go > directly to I-CSCF or other firewall proxy without transiting S-CSCF. Mine > can -- why pay extra for more S-CSCF than one really needs? But it's > configurable so that people who really want to spend more money can do so . > . . Free enterprise loves Darwin's dead-end branches if they're well-funded. > There's also another edge-proxy node called a THIG that may appear in > various locations and speaks SIP. > > -- > Dean > > ----- Original Message ----- > From: "Vijaya Venkatachalam" > To: > Sent: Monday, August 27, 2001 12:53 PM > Subject: [Sip] 3gpp & sip > > > Hi, > > > > Which all interfaces in 3GPP are using SIP? > > > > Thanks, > > Vijaya > > > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 13:13:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03418 for ; Wed, 29 Aug 2001 13:13:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09487; Wed, 29 Aug 2001 13:01:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09457 for ; Wed, 29 Aug 2001 13:01:24 -0400 (EDT) Received: from chuckie.dgms.com (host-38-150-156-4.ulticom.com [38.150.156.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03183 for ; Wed, 29 Aug 2001 13:00:04 -0400 (EDT) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id NAA18818; Wed, 29 Aug 2001 13:01:13 -0400 (EDT) Message-ID: <3B8D1F8B.B7B303C8@ulticom.com> Date: Wed, 29 Aug 2001 12:59:55 -0400 From: Vijaya Venkatachalam Organization: Ulticom, Inc. X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] 3gpp & sip References: <3B8513E5.625F03D5@lmf.ericsson.se> <3B8A88FE.815CCEE0@ulticom.com> <002f01c12f4b$91817e40$ad036e3f@flak> <3B8D1A24.9372F1E7@ericsson.com> Content-Type: multipart/mixed; boundary="------------136E45A547535DEB6ECD4608" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------136E45A547535DEB6ECD4608 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Miguel, For the BGCF to BGCF and the BGCF to MGCF, isn't TRIP a better choice than SIP. Vijaya "Miguel A. Garcia" wrote: > Just to add a few more interfaces using SIP in 3GPP. > The S-CSCF and BGCF, BGCF and BGCF, BGCF and MGCF, and S-CSCF and MRF. > > /Miguel > > Dean Willis wrote: > > > > That's actually a question better asked in 3GPP SA2. They have a slew of > > interfaces, each with a symbolic name like "The Sh interface". There's also > > some debate between various 3GPP groups as to which interfaces exist and > > what to call them, for example "SIP+" and "ISC" interface(s). > > > > In general, SIP is used between UE and P-CSCF, P-CSCF and P-CSCF, P-CSCF > > and I-CSCF, I-CSCF and S-CSCF, S-CSCF and AS, and AS-AS, and of course the > > inverses of those. There's some debate about whether AS may also directly > > interface to other SIP nodes withot using S-CSCF and I-CSCF, or may go > > directly to I-CSCF or other firewall proxy without transiting S-CSCF. Mine > > can -- why pay extra for more S-CSCF than one really needs? But it's > > configurable so that people who really want to spend more money can do so . > > . . Free enterprise loves Darwin's dead-end branches if they're well-funded. > > There's also another edge-proxy node called a THIG that may appear in > > various locations and speaks SIP. > > > > -- > > Dean > > > > ----- Original Message ----- > > From: "Vijaya Venkatachalam" > > To: > > Sent: Monday, August 27, 2001 12:53 PM > > Subject: [Sip] 3gpp & sip > > > > > Hi, > > > > > > Which all interfaces in 3GPP are using SIP? > > > > > > Thanks, > > > Vijaya > > > > > > > > > > _______________________________________________ > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 --------------136E45A547535DEB6ECD4608 Content-Type: text/x-vcard; charset=us-ascii; name="vijaya.vcf" Content-Description: Card for Vijaya Venkatachalam Content-Disposition: attachment; filename="vijaya.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Venkatachalam;Vijaya tel;fax:+1-856-866-2033 tel;work:+1-856-787-2853 x-mozilla-html:FALSE url:www.ulticom.com org:Ulticom, Inc.;Research & Development adr:;;1020 Briggs Rd;Mt. Laurel;NJ;08054;USA version:2.1 email;internet:vijaya@ulticom.com fn:Vijaya Venkatachalam end:vcard --------------136E45A547535DEB6ECD4608-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 14:43:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05834 for ; Wed, 29 Aug 2001 14:43:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11847; Wed, 29 Aug 2001 14:28:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11815 for ; Wed, 29 Aug 2001 14:28:31 -0400 (EDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05309 for ; Wed, 29 Aug 2001 14:27:10 -0400 (EDT) Received: from 157.54.7.67 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Aug 2001 11:28:04 -0700 Received: from red-msg-12.redmond.corp.microsoft.com ([157.54.2.26]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 Aug 2001 11:28:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Date: Wed, 29 Aug 2001 11:27:57 -0700 Message-ID: Thread-Topic: SDP in REFER triggered INVITE Thread-Index: AcEwuFOWgL+AuUhbQd6lFo+2DbY5wg== From: "Aaron Lo" To: X-OriginalArrivalTime: 29 Aug 2001 18:28:02.0325 (UTC) FILETIME=[564F7C50:01C130B8] Subject: [Sip] SDP in REFER triggered INVITE Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C130B8.537BAA76" ------_=_NextPart_001_01C130B8.537BAA76 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I have a question for REFER outside of existing call-legs.=20 =20 Consider this: =20 A sends a REFER to B referring to C. How does B know from the REFER what kind of session to establish, i.e. audio/IM/etc, and what to include in the SDP body?=20 =20 Thanks. =20 Aaron =20 =20 ------_=_NextPart_001_01C130B8.537BAA76 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have a question for REFER outside of existing = call-legs.

 

Consider this:

 

A sends a REFER to B referring to C. How does B know = from the REFER what kind of session to establish, i.e. audio/IM/etc, and what = to include in the SDP body?

 

Thanks.

 

Aaron

 

 

------_=_NextPart_001_01C130B8.537BAA76-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 14:55:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06056 for ; Wed, 29 Aug 2001 14:55:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12437; Wed, 29 Aug 2001 14:48:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12407 for ; Wed, 29 Aug 2001 14:48:15 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05900 for ; Wed, 29 Aug 2001 14:46:54 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.2) id f7TIm8V43649; Wed, 29 Aug 2001 14:48:11 -0400 (EDT) Reply-To: From: "Brett Tate" To: "'Aaron Lo'" , Subject: RE: [Sip] SDP in REFER triggered INVITE Date: Wed, 29 Aug 2001 14:47:39 -0400 Message-ID: <002701c130bb$13e61d30$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > I have a question for REFER outside of > existing call-legs. > > Consider this: > > A sends a REFER to B referring to C. > How does B know from the REFER what kind > of session to establish, i.e. audio/IM/etc, > and what to include in the SDP body? The REFER doesn't indicate it. B decides what sort of session it wishes to establish with C. A similar decision is made for INVITE without SDP situations. _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 17:04:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10056 for ; Wed, 29 Aug 2001 17:04:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16680; Wed, 29 Aug 2001 16:53:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16650 for ; Wed, 29 Aug 2001 16:53:01 -0400 (EDT) Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09292 for ; Wed, 29 Aug 2001 16:51:39 -0400 (EDT) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id UAA29496; Wed, 29 Aug 2001 20:52:13 GMT Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 29 Aug 2001 20:52:13 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Aug 2001 13:52:11 -0700 Message-ID: From: "Padhye, Chinmay" To: "'Jonathan Rosenberg'" , "'brett@broadsoft.com'" , sip@ietf.org Subject: RE: [Sip] URGENT: session timer: new issues Date: Wed, 29 Aug 2001 13:25:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello, I have a question w.r.t Issue 2 mentioned in the email below. Consider the following case - UAC ---- P-A ---- P-B ---- P-C ---- UAS UAC - Does not support session timer. P-A, P-B, P-C and UAS supports session timers. P-A has a preferred session timeout of 15 minutes, P-B has a preferred session timeout of 20 minutes and P-C with a preferred session timeout of 25 minutes. 1. UA sends an INVITE to P-A. This does not contain any session-expires header. 2. P-A inserts a session-expires header - Session-Expires: 900 and forwards it to P-B. 3. P-B finds the value too small. But instead of sending a 422 it inserts a MinSE with a value of 1200. (This is as per the proposed solution to Issue #2) 4. The INVITE reaches P-C. P-C finds that the MAX(Session-Expires, MinSE) is less than 1500. My question is what should P-C do? a) Send a 422 - Wont solve the problem. b) Add another MinSE. Is this allowed? Regards, Chinmay -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, August 24, 2001 8:33 AM To: 'brett@broadsoft.com'; Jonathan Rosenberg; sip@ietf.org Subject: RE: [Sip] URGENT: session timer: new issues > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Tuesday, August 21, 2001 8:53 PM > To: 'Jonathan Rosenberg'; sip@ietf.org > Subject: RE: [Sip] URGENT: session timer: new issues > > > > Issue #1 > > -------- > > My fix for this is that the client uses the max of the Min-SE > > amongst all > > 422 in all responses for a particular CALL before any call legs are > > established. Once a call leg is established, it uses the max > > of the min-SE > > returned in all 422 responses for that call leg (i.e, with > > the same tag as > > the 2xx that created the leg). As a result, when the call is > > accepted, the > > max of the Min-SE is effectively "cleared", and then can be > > reset to the max > > of the Min-SE on the path of the call leg. This seems to work fine. > > Sounds good. OK, seems like consensus on this one. > > > > > ISSUE #2 > > -------- > > Another option (soln 2) is this. A proxy can insert both a > > Session-Expires > > and Min-SE into the request. If a proxy sees a request > > without a Supported > > header, but with a Session-Expires header below its minimum, > > it can insert a > > Min-SE header into the request before proxying it (although it can't > > increase the session timer). When this hits the UAS, if it sees a > > session-expires with a value lower than min-se, it uses the > value from > > min-se instead of the value in session-expires. > > Solution 2 sounds fine. The same solution works > for when the UAS thinks Session-Expires was too > small. The UAS would use its own Min-SE for the > Session-Expires instead of rejecting with a 422. > Yes, that is true. I will take this to mean consensus on this issue as well. I'll update the draft today and get it resubmitted with these changes. I think we are finally done! -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 17:13:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10339 for ; Wed, 29 Aug 2001 17:13:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17798; Wed, 29 Aug 2001 17:03:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17767 for ; Wed, 29 Aug 2001 17:03:33 -0400 (EDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09735 for ; Wed, 29 Aug 2001 17:02:11 -0400 (EDT) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TL4jI18691 for ; Wed, 29 Aug 2001 16:04:45 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 Aug 2001 16:03:31 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 Aug 2001 16:03:31 -0500 content-class: urn:content-classes:message Date: Wed, 29 Aug 2001 16:03:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: signaling message compression - speed up X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEwzh12y+4JrZxiEdWaKQAQpIbXLw== From: "Liu Zhigang.C (NRC/Dallas)" To: Cc: X-OriginalArrivalTime: 29 Aug 2001 21:03:31.0542 (UTC) FILETIME=[0EF50760:01C130CE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA17768 Subject: [Sip] signaling message compression - speed up Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 8bit Hi, Three weeks has past since the last IETF meeting. Is there any news on the official change of ROHC charter to include the work of signaling compression? The schedule of this work item (from what I heard) is quite aggressive. To achieve that, should we start to piece good ideas from different proposals together and create a new draft? From there, we can proceed with a few cycles to refine it. Specifically, besides the current discussion on Huffman encoding and tree structured dictionary, we should also consider the following: 1) User specific dictionary (seems every agreed during the discussion) 2) Maintain dynamic dictionary across session. It is reasonable not to throw away the synchronized dictionary. 3) Shared mode. Should help, especially for SIP messages. 4) Make sure the dictionary synchronization is robust against packet loss/misordering. Complexity may be affected by dictionary structure. 5) Concurrency issue (re dictionary updates) in shared mode. 6) Make sure a misordered message can still be decompressed correctly (related to 4 and 5 but a different issue) 7) Protocol is generic. E.g. if tree structured dictionary is used, should make sure Lempel-Ziv is still possible and not penalized. Also, should not depend on SIP-specific knowledge (although is should work well compressing SIP). 8) Template encoding. Very useful for simple low-end terminals, which are probably the majority during the introduction of SIP to cellular. 9) Anything else? Above are just some tools we already have and can be used to tackle the problem. Most of them are simple. It would be good if we put them together and then tune the protocol to reach a good tradeoff between compression efficiency, complexity and flexibility. Comments? BR, Zhigang _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 17:18:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10538 for ; Wed, 29 Aug 2001 17:18:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18122; Wed, 29 Aug 2001 17:09:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18091 for ; Wed, 29 Aug 2001 17:09:26 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10136 for ; Wed, 29 Aug 2001 17:08:03 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7TL7lob001285; Wed, 29 Aug 2001 17:07:47 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Aug 2001 17:08:37 -0400 Message-ID: From: Jonathan Rosenberg To: "'Padhye, Chinmay'" , Jonathan Rosenberg , "'brett@broadsoft.com'" , sip@ietf.org Subject: RE: [Sip] URGENT: session timer: new issues Date: Wed, 29 Aug 2001 17:08:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Responses inline. > -----Original Message----- > From: Padhye, Chinmay [mailto:c_padhye@trillium.com] > Sent: Wednesday, August 29, 2001 4:26 PM > To: 'Jonathan Rosenberg'; 'brett@broadsoft.com'; sip@ietf.org > Subject: RE: [Sip] URGENT: session timer: new issues > > > Hello, > > I have a question w.r.t Issue 2 mentioned in the email below. > > Consider the following case - > > UAC ---- P-A ---- P-B ---- P-C ---- UAS > > UAC - Does not support session timer. > P-A, P-B, P-C and UAS supports session timers. > > P-A has a preferred session timeout of 15 minutes, > P-B has a preferred session timeout of 20 minutes and > P-C with a preferred session timeout of 25 minutes. > > 1. UA sends an INVITE to P-A. This does not contain any > session-expires > header. > 2. P-A inserts a session-expires header - Session-Expires: 900 and > forwards it to P-B. > 3. P-B finds the value too small. But instead of sending a 422 it > inserts a MinSE with a value of 1200. (This is as per the > proposed solution > to Issue #2) It has to also increase the session-expires to 1200. > 4. The INVITE reaches P-C. P-C finds that the > MAX(Session-Expires, MinSE) is > less than 1500. > > My question is what should P-C do? Same as P-B. Increase Min-SE to 1500 (assuming that you are saying that P-C's minimum is 1500) and also increase S-E to 1500. > > a) Send a 422 - Wont solve the problem. > b) Add another MinSE. Is this allowed? No, but it can increase the existing one. I have just submitted an updated version of session timer which incorporates this new algorithm. It should appear shortly, but in the mean time, you can pick it up at: http://www.jdrosen.net/papers/draft-ietf-sip-session-timer-06.txt Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 17:34:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10980 for ; Wed, 29 Aug 2001 17:34:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18795; Wed, 29 Aug 2001 17:24:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18720 for ; Wed, 29 Aug 2001 17:24:22 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10672 for ; Wed, 29 Aug 2001 17:22:59 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7TLMOob001442; Wed, 29 Aug 2001 17:22:25 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Aug 2001 17:23:14 -0400 Message-ID: From: Jonathan Rosenberg To: "'Jin-Gen.Wang@Level3.com'" Cc: sip@ietf.org Subject: RE: [Sip] issues on TCP support and Record-Route Date: Wed, 29 Aug 2001 17:23:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Jin-Gen.Wang@Level3.com [mailto:Jin-Gen.Wang@Level3.com] > Sent: Wednesday, August 29, 2001 12:17 PM > To: jdrosen@dynamicsoft.com > Cc: sip@ietf.org > Subject: RE: [Sip] issues on TCP support and Record-Route > > > One disadvantage of the design (no length field in a fixed > position) is that > we have to mix message parsing with each TCP connection. This > limits the > choice of implementations. So? > If the length field you are proposing is too long, not present, or too > short, the next message will also be skewed. The failure cases seem > identical. > > [Jin-Gen Wang] I agree. This is the same if the content length in the > current spec is mal-formed. However, when the message length > is correct, we > can catch all sorts of mal-formed SIP messages without > affecting the next > message, which is much more robust in my opinion. Again, I am > talking about > carrier grade software (at least four 9s reliability). The class of malformed SIP messages which can be caught by your proposal, but not the current approach, assuming the Content-Length itself is formed correctly, is only ONE. That one case is where there is no double CRLF after the last line (unless your parser is really bad, but breaking the protocol to handle the inability of people to build a good parser is not a good design choice). I am curious how frequently you are seeing implementations not include that double CRLF. I have never seen it. Let us please discuss real problems. Perhaps you can point to some real data that says that for HTTP, this "problem" occurs some reasonable percentage of the time? > Total destruction of backwards compatibility with every > single TCP enabled > SIP element? Re-invention of message-oriented connection oriented > transports? My question still remains - if you think this is > such a problem, > what is wrong with using SCTP which does what you are asking for? > > [Jin-Gen Wang] The backward compatibility is a very > legitimate concern. > However, that doesn't mean we shouldn't change anything. I am > trying to > understand the protocol design idea behind missing message > length in a > fixed position. I haven't seen a solid reason yet. > > It seems to me that to force people using SCTP in our case is > against "the > transport protocol neutral principal" of using SIP. Different transports provide different benefits. SIP works with stream and message transports. You are saying that you like message transports that provide a lower layer length indication. OK, so use one. > This is a well known problem, for which text in -04 already > discusses. I > have improved this text further in -05, and the issue has already been > discussed extensively on the list. You cannot RR with a > transport param not > equal to UDP unless you are in a private network where you know the > transport capabilities of the hop that RR's on the side you > wish to use a > different transport. > > [Jin-Gen Wang] Again, it seems to me that this is against > "the transport > protocol neutral" principle of using SIP. If it is a well > known problem, > doesn't that mean the Record-Route idea needs to be looked again? It is a well known problem with documented solutions in bis-04. You questioned the design decision by proposing a "better" solution that breaks all backwards compatibility, in the interests of carrier grade. I have argued that there is no proof that the current design decision cannot work in carrier grade environments. Just because something requires "processing" to be done, says nothing about whether eliminating or speeding up that processing improves overall performance. Amdahls law, remember.... -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 18:44:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12788 for ; Wed, 29 Aug 2001 18:44:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28123; Wed, 29 Aug 2001 18:36:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA28071 for ; Wed, 29 Aug 2001 18:36:33 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12592 for ; Wed, 29 Aug 2001 18:35:12 -0400 (EDT) From: Jin-Gen.Wang@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id WAA15453; Wed, 29 Aug 2001 22:36:32 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id WAA06907; Wed, 29 Aug 2001 22:36:25 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <3RFX96JB>; Wed, 29 Aug 2001 16:36:24 -0600 Message-ID: To: jdrosen@dynamicsoft.com Cc: sip@ietf.org Subject: RE: [Sip] issues on TCP support and Record-Route Date: Wed, 29 Aug 2001 16:32:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, August 29, 2001 3:23 PM To: Wang, Jin-Gen Cc: sip@ietf.org Subject: RE: [Sip] issues on TCP support and Record-Route > -----Original Message----- > From: Jin-Gen.Wang@Level3.com [mailto:Jin-Gen.Wang@Level3.com] > Sent: Wednesday, August 29, 2001 12:17 PM > To: jdrosen@dynamicsoft.com > Cc: sip@ietf.org > Subject: RE: [Sip] issues on TCP support and Record-Route > > > One disadvantage of the design (no length field in a fixed > position) is that > we have to mix message parsing with each TCP connection. This > limits the > choice of implementations. So? [Jin-Gen Wang] (1) A good protocol/architecture design should leave the implementation enough freedom. (2) In general, this is against component software design to implement SIP. I don't think it's a wise decision. > If the length field you are proposing is too long, not present, or too > short, the next message will also be skewed. The failure cases seem > identical. > > [Jin-Gen Wang] I agree. This is the same if the content length in the > current spec is mal-formed. However, when the message length > is correct, we > can catch all sorts of mal-formed SIP messages without > affecting the next > message, which is much more robust in my opinion. Again, I am > talking about > carrier grade software (at least four 9s reliability). The class of malformed SIP messages which can be caught by your proposal, but not the current approach, assuming the Content-Length itself is formed correctly, is only ONE. That one case is where there is no double CRLF after the last line (unless your parser is really bad, but breaking the protocol to handle the inability of people to build a good parser is not a good design choice). I am curious how frequently you are seeing implementations not include that double CRLF. I have never seen it. Let us please discuss real problems. Perhaps you can point to some real data that says that for HTTP, this "problem" occurs some reasonable percentage of the time? [Jin-Gen Wang] Let's face the reality. The best parser is to parse the stream once, do you agree? If a start line is mal-formed, e.g., no spaces to separate different fields. What are you going to do? One option is to read in all lines and find Content-Length to locate the end of message. Then re-parse the read-in buffer to indicate the mal-formed start line. This requires multiple passes through the byte stream. For one pass parsing, the mal-formed start line should be caught in the first pass and discard the message. My proposal (actually a common sense proposal for using stream based transport protocol) will make one pass parsing work reliably. The current spec requires multiple passes to handle such mal-formed messages which adds a lot of overhead. To deal with such mal-formed SIP messages is a reality for programmers. > Total destruction of backwards compatibility with every > single TCP enabled > SIP element? Re-invention of message-oriented connection oriented > transports? My question still remains - if you think this is > such a problem, > what is wrong with using SCTP which does what you are asking for? > > [Jin-Gen Wang] The backward compatibility is a very > legitimate concern. > However, that doesn't mean we shouldn't change anything. I am > trying to > understand the protocol design idea behind missing message > length in a > fixed position. I haven't seen a solid reason yet. > > It seems to me that to force people using SCTP in our case is > against "the > transport protocol neutral principal" of using SIP. Different transports provide different benefits. SIP works with stream and message transports. You are saying that you like message transports that provide a lower layer length indication. OK, so use one. [Jin-Gen Wang] I am not sure what you mean. The message length is on the application level. I am hoping that the problem can be addressed in a standard way. Otherwise, people will find their own ways to solve the problem. > This is a well known problem, for which text in -04 already > discusses. I > have improved this text further in -05, and the issue has already been > discussed extensively on the list. You cannot RR with a > transport param not > equal to UDP unless you are in a private network where you know the > transport capabilities of the hop that RR's on the side you > wish to use a > different transport. > > [Jin-Gen Wang] Again, it seems to me that this is against > "the transport > protocol neutral" principle of using SIP. If it is a well > known problem, > doesn't that mean the Record-Route idea needs to be looked again? It is a well known problem with documented solutions in bis-04. You questioned the design decision by proposing a "better" solution that breaks all backwards compatibility, in the interests of carrier grade. I have argued that there is no proof that the current design decision cannot work in carrier grade environments. Just because something requires "processing" to be done, says nothing about whether eliminating or speeding up that processing improves overall performance. Amdahls law, remember.... [Jin-Gen Wang] Well, it doesn't work in our environment. I am not in a position to present our environment. You may say our environment is skewed. The only thing I know is that the Record-Route is not working well in mixed-transport protocol scenarios. I didn't say my solution is a better solution. I just want to see if people have suggestions for fixing the problem other than those in bis-04 which are not satisfactory. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Wed Aug 29 20:48:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14083 for ; Wed, 29 Aug 2001 20:48:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01362; Wed, 29 Aug 2001 20:39:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01336 for ; Wed, 29 Aug 2001 20:39:51 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14006 for ; Wed, 29 Aug 2001 20:38:30 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.2) id f7U0dok12097; Wed, 29 Aug 2001 20:39:50 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [SIP] Killing hung media streams Date: Wed, 29 Aug 2001 20:39:19 -0400 Message-ID: <000501c130ec$34fa5280$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > > Why must the UAC send a bye when a 481 is received? I > > thought that the > > 481 implies that the call leg is terminated. Section 15.5 > > states that > > "A UAC receiving a 481 response for any mid-call request > > (INVITE or otherwise) > > MUST consider the call terminated." > > Thats the problem. I think this text is wrong. It should send > a BYE, and > then consider the call terminated as a result. > > Why? Well, we have a general rule that a non-2xx response to > a re-INVITE > does not mean the call is dead. Only BYE terminates a call. > I'd like to keep > that rule, since it provides a single, consistent way for everyone to > say/know whether the call is up or down. > > I feel very strongly about this one. Having multiple ways of > signaling that > a call is down is very bad, IMHO. I thought that this issue was closed per IETF 49 with a 481 meaning that the call-leg is dead; thus no need to send a BYE. http://www.softarmor.com/sipwg/meets/ietf49/minutes/minutes-sip-49.htm I realize that call-stateful proxies might want to avoid snooping for a 481. However based upon the captured minutes and the hum at the meeting, I assume that many UA's would have to be modified to start sending the BYE for dead call-legs. No matter the decision, hopefully we can close this issue permanently this time. :) _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 00:47:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19325 for ; Thu, 30 Aug 2001 00:47:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06310; Thu, 30 Aug 2001 00:34:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA06281 for ; Thu, 30 Aug 2001 00:34:55 -0400 (EDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19241 for ; Thu, 30 Aug 2001 00:33:33 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f7U4Ypv09601; Thu, 30 Aug 2001 06:34:52 +0200 (MEST) Received: from ericsson.com (ppp22.lmf.ericsson.se [131.160.102.22]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7U4Ynr19716; Thu, 30 Aug 2001 07:34:50 +0300 (EET DST) Message-ID: <3B8DC267.190EC55F@ericsson.com> Date: Thu, 30 Aug 2001 07:34:47 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: Vijaya Venkatachalam CC: Dean Willis , sip@ietf.org Subject: Re: [Sip] 3gpp & sip References: <3B8513E5.625F03D5@lmf.ericsson.se> <3B8A88FE.815CCEE0@ulticom.com> <002f01c12f4b$91817e40$ad036e3f@flak> <3B8D1A24.9372F1E7@ericsson.com> <3B8D1F8B.B7B303C8@ulticom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Vijaya Venkatachalam wrote: > > Hi Miguel, > > For the BGCF to BGCF and the BGCF to MGCF, isn't TRIP > a better choice than SIP. > No, they are complementary protocols: SIP is the session control protocol, whereas TRIP is good to exchange routes to the PSTN. Definitely it is possible to run TRIP across BGCFs and TRIP for gateways between the MGCF and the BGCF. These are not part of 3GPP Release 5, but certainly it is a possibility to explore for future releases. But still you need SIP to route the session. /Miguel > Vijaya > > "Miguel A. Garcia" wrote: > > > Just to add a few more interfaces using SIP in 3GPP. > > The S-CSCF and BGCF, BGCF and BGCF, BGCF and MGCF, and S-CSCF and MRF. > > > > /Miguel > > > > Dean Willis wrote: > > > > > > That's actually a question better asked in 3GPP SA2. They have a slew of > > > interfaces, each with a symbolic name like "The Sh interface". There's also > > > some debate between various 3GPP groups as to which interfaces exist and > > > what to call them, for example "SIP+" and "ISC" interface(s). > > > > > > In general, SIP is used between UE and P-CSCF, P-CSCF and P-CSCF, P-CSCF > > > and I-CSCF, I-CSCF and S-CSCF, S-CSCF and AS, and AS-AS, and of course the > > > inverses of those. There's some debate about whether AS may also directly > > > interface to other SIP nodes withot using S-CSCF and I-CSCF, or may go > > > directly to I-CSCF or other firewall proxy without transiting S-CSCF. Mine > > > can -- why pay extra for more S-CSCF than one really needs? But it's > > > configurable so that people who really want to spend more money can do so . > > > . . Free enterprise loves Darwin's dead-end branches if they're well-funded. > > > There's also another edge-proxy node called a THIG that may appear in > > > various locations and speaks SIP. > > > > > > -- > > > Dean > > > > > > ----- Original Message ----- > > > From: "Vijaya Venkatachalam" > > > To: > > > Sent: Monday, August 27, 2001 12:53 PM > > > Subject: [Sip] 3gpp & sip > > > > > > > Hi, > > > > > > > > Which all interfaces in 3GPP are using SIP? > > > > > > > > Thanks, > > > > Vijaya > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > > Miguel-Angel Garcia Oy LM Ericsson AB > > Jorvas, Finland > > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 01:15:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20885 for ; Thu, 30 Aug 2001 01:15:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA07078; Thu, 30 Aug 2001 01:04:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA07047 for ; Thu, 30 Aug 2001 01:04:46 -0400 (EDT) Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19473 for ; Thu, 30 Aug 2001 01:03:27 -0400 (EDT) Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.2) id f7U54lp55090; Thu, 30 Aug 2001 01:04:47 -0400 (EDT) Reply-To: From: "Brett Tate" To: Subject: RE: [Sip] Open Issue #7: CANCEL for non-INVITE Date: Thu, 30 Aug 2001 01:04:16 -0400 Message-ID: <000601c13111$38b42660$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit > My proposal was that we should deprecate CANCEL for > non-INVITE. The benefit > is not even quantifiable, at best, and the cost seems high. > Of course, for > backwards compatibility, a server should not complain if it > gets a CANCEL > for a non-invite, just respond 200 OK (or even 405 is OK) and > thats it. It > should have responded to the request anyway. The proposal sounds good to me. If the request was not important, just quit sending retries for the request and mark the delivery status as unknown/who-cares. If the request was important, the UAC would have had to indefinitely continue to send the request or an alternative query to find out if the CANCEL actually worked. If the success or cancellation status of a request is deemed important enough, how about a new DISCARDORNOTIFY method to ensure that the request will be discarded if received or a notification sent if positively acknowledged? :) _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 10:14:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17789 for ; Thu, 30 Aug 2001 10:14:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27650; Thu, 30 Aug 2001 09:22:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27622 for ; Thu, 30 Aug 2001 09:22:20 -0400 (EDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15764 for ; Thu, 30 Aug 2001 09:20:52 -0400 (EDT) Received: from bemail01.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f7UDLLN12488 for ; Thu, 30 Aug 2001 15:21:36 +0200 (MET DST) Received: from alcatel.be ([138.203.67.193]) by bemail01.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C1256AB8.00495863; Thu, 30 Aug 2001 15:21:07 +0200 Message-ID: <3B8E3DC1.1E87069C@alcatel.be> Date: Thu, 30 Aug 2001 15:21:05 +0200 From: Timothy SOETENS Organization: Alcatel X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip mailing list Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] To and Request URI Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Hi All, We are currently working on an implementation of SIP. There is however an issue we have not been able to resolve. Apparently, the routing of SIP messages by a SIP proxy is done entirely based on the Request URI if no Route header is present. However, I always had the impression that the To URI indicated the callee, so routing should be based on the To URI. This raised a couple of questions: 1. If routing is done based on the Request URI, what is the function of the To URI? Do intermediate Proxies look at the To URI? 2. If the Proxy determines the Request URI based on the TO URI, why do we have to include the Request URI in the message? If it has been discussed before, I am sorry, then please point me to some relevant documents. Thanks, -- Timothy Soetens _________________________________________ From the Network Strategy Group @ Alcatel Tel. +32-3-240.42.11 Fax +32-3-240.48.88 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 11:33:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19708 for ; Thu, 30 Aug 2001 11:33:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00529; Thu, 30 Aug 2001 11:13:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00500 for ; Thu, 30 Aug 2001 11:13:30 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19277 for ; Thu, 30 Aug 2001 11:12:10 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7UFBhob006136; Thu, 30 Aug 2001 11:11:43 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 11:12:35 -0400 Message-ID: From: Jonathan Rosenberg To: "'Ngo, Dai (c)'" , "'simple@mailman.dynamicsoft.com'" Cc: "Adam Roach (E-mail)" , "'sip@ietf.org'" Date: Thu, 30 Aug 2001 11:12:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] RE: [Simple] INVITE or BYE Clarification Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@wcom.com] Sent: Thursday, August 30, 2001 10:59 AM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] INVITE or BYE Clarification >Hi All, >In section 3, "Overview of Operation" of the draft-ietf-simple-presence-01.txt it states, >"The SUBSCRIBE message effectively establishes a session with the > presence agent. As a result, the SUBSCRIBE can be record-routed, and > rules for tag handling and Contact processing mirror those for > INVITE. " >However, in section 5, "Node Behavior" of draft-ietf-sip-events-00.txt it states, >"Unless noted otherwise, SUBSCRIBE and NOTIFY requests follow the > same protocol rules governing the usage of tags, Route, > Record-Route, Via handling, retransmission, reliability, CSeq > handling, Contact handling, provisional responses, and message > formatting as those defined in RFC 2543 [1] for BYE." >Please note the difference of INVITE in the first draft versus BYE in the second draft. >Which one is correct? Please clarify. I believe the behavior should mirror INVITE. I believe I pointed this out to Adam but don't recall whether he concurred. This obviously needs to be resolved asap. Adam? -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 12:26:21 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21080 for ; Thu, 30 Aug 2001 12:26:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02641; Thu, 30 Aug 2001 12:09:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02612 for ; Thu, 30 Aug 2001 12:09:06 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAB20429 for ; Thu, 30 Aug 2001 12:07:45 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f7UG96H21682; Thu, 30 Aug 2001 19:09:06 +0300 Date: Thu, 30 Aug 2001 19:09:06 +0300 Message-Id: <200108301609.f7UG96H21682@lohi.eng.telia.fi> From: Juha Heinanen To: sip@ietf.org Subject: [Sip] MUST 200 OK contain SDP? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org 12.1 says: 1xx responses to INVITE requests MAY contain session descriptions. ... 2xx responses to INVITE requests contain session descriptions. at least one vendor is interpreting the lack of MUST in the second sentence to mean that since the sdp already was in 180 ringing, they don't need to repeat it in 200 ok. that interpretation, however, is not liked by some other sip phones. the former interpretation may be correct, since according to ietf rules, only MUST means must. -- juha _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 14:33:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24704 for ; Thu, 30 Aug 2001 14:33:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05809; Thu, 30 Aug 2001 14:09:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05782 for ; Thu, 30 Aug 2001 14:09:11 -0400 (EDT) Received: from exmail.lboard.com (16.node.lboard.com [204.17.219.16] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24023 for ; Thu, 30 Aug 2001 14:07:51 -0400 (EDT) Received: by exmail.lboard.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 11:07:52 -0700 Message-ID: From: Subir Saha To: sip@ietf.org Date: Thu, 30 Aug 2001 11:07:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] draft-ietf-sip-srv-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Draft (draft-ietf-sip-srv-02.txt)is in morgue. Any new developement in this respect? Thanks, Subir Saha, Ph.D. Senior Product Architect LongBoard Inc. -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: Wednesday, August 29, 2001 9:35 PM To: Vijaya Venkatachalam Cc: Dean Willis; sip@ietf.org Subject: Re: [Sip] 3gpp & sip Vijaya Venkatachalam wrote: > > Hi Miguel, > > For the BGCF to BGCF and the BGCF to MGCF, isn't TRIP > a better choice than SIP. > No, they are complementary protocols: SIP is the session control protocol, whereas TRIP is good to exchange routes to the PSTN. Definitely it is possible to run TRIP across BGCFs and TRIP for gateways between the MGCF and the BGCF. These are not part of 3GPP Release 5, but certainly it is a possibility to explore for future releases. But still you need SIP to route the session. /Miguel > Vijaya > > "Miguel A. Garcia" wrote: > > > Just to add a few more interfaces using SIP in 3GPP. > > The S-CSCF and BGCF, BGCF and BGCF, BGCF and MGCF, and S-CSCF and MRF. > > > > /Miguel > > > > Dean Willis wrote: > > > > > > That's actually a question better asked in 3GPP SA2. They have a slew of > > > interfaces, each with a symbolic name like "The Sh interface". There's also > > > some debate between various 3GPP groups as to which interfaces exist and > > > what to call them, for example "SIP+" and "ISC" interface(s). > > > > > > In general, SIP is used between UE and P-CSCF, P-CSCF and P-CSCF, P-CSCF > > > and I-CSCF, I-CSCF and S-CSCF, S-CSCF and AS, and AS-AS, and of course the > > > inverses of those. There's some debate about whether AS may also directly > > > interface to other SIP nodes withot using S-CSCF and I-CSCF, or may go > > > directly to I-CSCF or other firewall proxy without transiting S-CSCF. Mine > > > can -- why pay extra for more S-CSCF than one really needs? But it's > > > configurable so that people who really want to spend more money can do so . > > > . . Free enterprise loves Darwin's dead-end branches if they're well-funded. > > > There's also another edge-proxy node called a THIG that may appear in > > > various locations and speaks SIP. > > > > > > -- > > > Dean > > > > > > ----- Original Message ----- > > > From: "Vijaya Venkatachalam" > > > To: > > > Sent: Monday, August 27, 2001 12:53 PM > > > Subject: [Sip] 3gpp & sip > > > > > > > Hi, > > > > > > > > Which all interfaces in 3GPP are using SIP? > > > > > > > > Thanks, > > > > Vijaya > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > > Miguel-Angel Garcia Oy LM Ericsson AB > > Jorvas, Finland > > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 15:04:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25556 for ; Thu, 30 Aug 2001 15:04:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06913; Thu, 30 Aug 2001 14:45:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06891 for ; Thu, 30 Aug 2001 14:45:26 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25001 for ; Thu, 30 Aug 2001 14:44:06 -0400 (EDT) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7UIjQ001595 for ; Thu, 30 Aug 2001 14:45:26 -0400 (EDT) Received: from lucent.com (pctla2 [135.3.130.26]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id OAA15394 for ; Thu, 30 Aug 2001 14:45:21 -0400 (EDT) Message-ID: <3B8E8942.52E5226F@lucent.com> Date: Thu, 30 Aug 2001 14:43:14 -0400 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: SIP Mailing List Content-Type: multipart/mixed; boundary="------------D326AE42406840505CCB6F83" Subject: [Sip] use of outbound proxies Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------D326AE42406840505CCB6F83 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit draft-ietf-sip-rfc2543bis-04 appears to have contradictory rule on routing of subsequent requests. 15.4 (next to last paragraph) appears to say that whenever UAC is configured with an outbound proxy, it sends all subsequent requests there regardless of Request-URI (and so regardless of route list). But 16.4.1 appears to say the UAC does this only if there are no Route headers or UA has no support for DNS. Which is the intended behavior? 1) always route to outbound proxy 2) use outbound proxy only as last resort, for subsequent requests and shouldn't one of these be edited so that they agree. -- Waiting for the other shoe to drop but hoping its a one legged man. ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------D326AE42406840505CCB6F83 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / Integrated Network Solutions;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;-4752 fn:Terry L Anderson end:vcard --------------D326AE42406840505CCB6F83-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 15:05:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25639 for ; Thu, 30 Aug 2001 15:05:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07114; Thu, 30 Aug 2001 14:48:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA07084 for ; Thu, 30 Aug 2001 14:47:59 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25097 for ; Thu, 30 Aug 2001 14:46:39 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7UIlxK10765; Thu, 30 Aug 2001 20:47:59 +0200 (MEST) Received: from lmf.ericsson.se (lmf05397pc.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7UIlwr13583; Thu, 30 Aug 2001 21:47:58 +0300 (EET DST) Message-ID: <3B8E8A60.59C48D02@lmf.ericsson.se> Date: Thu, 30 Aug 2001 21:48:00 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: sip@ietf.org Subject: Re: [Sip] MUST 200 OK contain SDP? References: <200108301609.f7UG96H21682@lohi.eng.telia.fi> Content-Type: multipart/mixed; boundary="------------A243439ACBEF7A89F47F52F4" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------A243439ACBEF7A89F47F52F4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, The spec is correct - the 2xx MUST contain a session description. For example, you may receive multiple 18x provisional responses, from different users, and all with different session descriptions, and you don't always know (if there aren't any tags) which "belongs" to the 200. Regards, Christer Holmberg Ericsson Finland Juha Heinanen wrote: > > 12.1 says: > > 1xx responses to INVITE requests MAY contain session descriptions. > ... > 2xx responses to INVITE requests contain session descriptions. > > at least one vendor is interpreting the lack of MUST in the second > sentence to mean that since the sdp already was in 180 ringing, they > don't need to repeat it in 200 ok. that interpretation, however, is not > liked by some other sip phones. > > the former interpretation may be correct, since according to > ietf rules, only MUST means must. > > -- juha > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip --------------A243439ACBEF7A89F47F52F4 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------A243439ACBEF7A89F47F52F4-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 15:31:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26276 for ; Thu, 30 Aug 2001 15:31:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08055; Thu, 30 Aug 2001 15:09:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08021 for ; Thu, 30 Aug 2001 15:09:50 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25742 for ; Thu, 30 Aug 2001 15:08:30 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f7UJ9jl22287; Thu, 30 Aug 2001 22:09:45 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15246.36728.587861.558058@lohi.eng.telia.fi> Date: Thu, 30 Aug 2001 22:09:44 +0300 (EEST) To: Christer Holmberg Cc: sip@ietf.org Subject: Re: [Sip] MUST 200 OK contain SDP? In-Reply-To: <3B8E8A60.59C48D02@lmf.ericsson.se> References: <200108301609.f7UG96H21682@lohi.eng.telia.fi> <3B8E8A60.59C48D02@lmf.ericsson.se> X-Mailer: VM 6.75 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Christer Holmberg writes: > The spec is correct - the 2xx MUST contain a session description. the spec is not correct before the word MUST appears in the the 2xx sentence. -- juha _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 15:31:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26275 for ; Thu, 30 Aug 2001 15:31:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07712; Thu, 30 Aug 2001 15:01:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07687 for ; Thu, 30 Aug 2001 15:01:07 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25433 for ; Thu, 30 Aug 2001 14:59:47 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7UJ16K12608; Thu, 30 Aug 2001 21:01:07 +0200 (MEST) Received: from lmf.ericsson.se (lmf05397pc.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7UJ15r13749; Thu, 30 Aug 2001 22:01:05 +0300 (EET DST) Message-ID: <3B8E8D73.56B89EB9@lmf.ericsson.se> Date: Thu, 30 Aug 2001 22:01:07 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson CC: SIP Mailing List Subject: Re: [Sip] use of outbound proxies References: <3B8E8942.52E5226F@lucent.com> Content-Type: multipart/mixed; boundary="------------7EE197D0F742ABB3721A5832" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------7EE197D0F742ABB3721A5832 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This issue was raised on a list a while ago, but after the IETF meeting I haven't heard anything. I don't even know if it was discussed there (at least it was not, if I remember correct, on Jonathan's list of open issues). Regards, Christer Holmberg Ericsson Finland Terry L Anderson wrote: > > draft-ietf-sip-rfc2543bis-04 appears to have contradictory rule on > routing of subsequent requests. 15.4 (next to last paragraph) appears > to say that whenever UAC is configured with an outbound proxy, it sends > all subsequent requests there regardless of Request-URI (and so > regardless of route list). > > But 16.4.1 appears to say the UAC does this only if there are no Route > headers or UA has no support for DNS. > > Which is the intended behavior? > 1) always route to outbound proxy > 2) use outbound proxy only as last resort, for subsequent requests > > and shouldn't one of these be edited so that they agree. > > -- > Waiting for the other shoe to drop but hoping its a one legged man. > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Lucent Technologies/INS/Voice Over IP Access Networks > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------7EE197D0F742ABB3721A5832 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------7EE197D0F742ABB3721A5832-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 15:44:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26509 for ; Thu, 30 Aug 2001 15:44:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08333; Thu, 30 Aug 2001 15:18:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08303 for ; Thu, 30 Aug 2001 15:18:46 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25996 for ; Thu, 30 Aug 2001 15:17:25 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7UJIiK14676; Thu, 30 Aug 2001 21:18:45 +0200 (MEST) Received: from lmf.ericsson.se (lmf05397pc.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7UJIir14088; Thu, 30 Aug 2001 22:18:44 +0300 (EET DST) Message-ID: <3B8E9196.7495BD39@lmf.ericsson.se> Date: Thu, 30 Aug 2001 22:18:46 +0300 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen CC: sip@ietf.org Subject: Re: [Sip] MUST 200 OK contain SDP? References: <200108301609.f7UG96H21682@lohi.eng.telia.fi> <3B8E8A60.59C48D02@lmf.ericsson.se> <15246.36728.587861.558058@lohi.eng.telia.fi> Content-Type: multipart/mixed; boundary="------------4C0C1FAEF6591CC0203BF250" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This is a multi-part message in MIME format. --------------4C0C1FAEF6591CC0203BF250 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit True. Christer (lmfchh) Juha Heinanen wrote: > > Christer Holmberg writes: > > > The spec is correct - the 2xx MUST contain a session description. > > the spec is not correct before the word MUST appears in the the 2xx > sentence. > > -- juha --------------4C0C1FAEF6591CC0203BF250 Content-Type: text/x-vcard; charset=us-ascii; name="christer.holmberg.vcf" Content-Description: Card for Christer Holmberg Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Holmberg;Christer tel;cell:+358-40-5604412 tel;work:+358-9-2992943 x-mozilla-html:FALSE org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory adr:;;;;;; version:2.1 email;internet:christer.holmberg@lmf.ericsson.se title:System Designer fn:Christer Holmberg end:vcard --------------4C0C1FAEF6591CC0203BF250-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 17:29:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28420 for ; Thu, 30 Aug 2001 17:29:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11210; Thu, 30 Aug 2001 17:06:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA11182 for ; Thu, 30 Aug 2001 17:06:10 -0400 (EDT) Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28138 for ; Thu, 30 Aug 2001 17:04:50 -0400 (EDT) Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7UL6BZ00727 for ; Thu, 30 Aug 2001 17:06:11 -0400 (EDT) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Aug 2001 17:05:48 -0400 Message-ID: From: "Ghai, Rajat (Rajat)" To: sip mailing list Subject: RE: [Sip] To and Request URI Date: Thu, 30 Aug 2001 17:05:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Typically TO & Req URI would be the same when the request originates (there are cases when this is not true, that's why "typically"). However, at some point, the Req URI will be re-written (mostly towards desination) but To will remain unchanged. For example, TO & Req URI could initiate as However, once the request reaches "sip.acme.com" proxy, it could dynamically rewrite the req URI to while TO still points to thanks Rajat Ghai > >-----Original Message----- > >From: Timothy SOETENS [mailto:timothy.soetens@alcatel.be] > >Sent: Thursday, August 30, 2001 9:21 AM > >To: sip mailing list > >Subject: [Sip] To and Request URI > > > > > >Hi All, > > > >We are currently working on an implementation of SIP. There > >is however > >an issue we have not been able to resolve. > >Apparently, the routing of SIP messages by a SIP proxy is > >done entirely > >based on the Request URI if no Route header is present. However, I > >always had the impression that the To URI indicated the callee, so > >routing should be based on the To URI. This raised a couple of > >questions: > >1. If routing is done based on the Request URI, what is the > >function of > >the To URI? Do intermediate Proxies look at the To URI? > >2. If the Proxy determines the Request URI based on the TO > >URI, why do > >we have to include the Request URI in the message? > > > >If it has been discussed before, I am sorry, then please point me to > >some relevant documents. Thanks, > >-- > >Timothy Soetens > >_________________________________________ > > > >From the Network Strategy Group @ Alcatel > > > >Tel. +32-3-240.42.11 > >Fax +32-3-240.48.88 > > > >_______________________________________________ > >Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 19:06:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29767 for ; Thu, 30 Aug 2001 19:06:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13204; Thu, 30 Aug 2001 18:35:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13175 for ; Thu, 30 Aug 2001 18:35:16 -0400 (EDT) Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29369 for ; Thu, 30 Aug 2001 18:33:52 -0400 (EDT) Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id WAA25449 for ; Thu, 30 Aug 2001 22:35:14 GMT Received: from fmsmsx18.intel.com ([132.233.233.232]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001083014251712602 ; Thu, 30 Aug 2001 14:25:17 -0700 Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 14:25:18 -0700 Message-ID: From: "Padhye, Chinmay" To: "'Subir Saha'" , sip@ietf.org Subject: RE: [Sip] draft-ietf-sip-srv-02.txt Date: Thu, 30 Aug 2001 14:23:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Hello Subir, The srv-02 draft defines the term "Outbound Proxy" and updates the reference RFC 2052 to RFC 2782. These changes are in bis-02 already. Regards, Chinmay -----Original Message----- From: Subir Saha [mailto:ssaha@longboard.com] Sent: Thursday, August 30, 2001 11:08 AM To: sip@ietf.org Subject: [Sip] draft-ietf-sip-srv-02.txt Draft (draft-ietf-sip-srv-02.txt)is in morgue. Any new developement in this respect? Thanks, Subir Saha, Ph.D. Senior Product Architect LongBoard Inc. -----Original Message----- From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] Sent: Wednesday, August 29, 2001 9:35 PM To: Vijaya Venkatachalam Cc: Dean Willis; sip@ietf.org Subject: Re: [Sip] 3gpp & sip Vijaya Venkatachalam wrote: > > Hi Miguel, > > For the BGCF to BGCF and the BGCF to MGCF, isn't TRIP > a better choice than SIP. > No, they are complementary protocols: SIP is the session control protocol, whereas TRIP is good to exchange routes to the PSTN. Definitely it is possible to run TRIP across BGCFs and TRIP for gateways between the MGCF and the BGCF. These are not part of 3GPP Release 5, but certainly it is a possibility to explore for future releases. But still you need SIP to route the session. /Miguel > Vijaya > > "Miguel A. Garcia" wrote: > > > Just to add a few more interfaces using SIP in 3GPP. > > The S-CSCF and BGCF, BGCF and BGCF, BGCF and MGCF, and S-CSCF and MRF. > > > > /Miguel > > > > Dean Willis wrote: > > > > > > That's actually a question better asked in 3GPP SA2. They have a slew of > > > interfaces, each with a symbolic name like "The Sh interface". There's also > > > some debate between various 3GPP groups as to which interfaces exist and > > > what to call them, for example "SIP+" and "ISC" interface(s). > > > > > > In general, SIP is used between UE and P-CSCF, P-CSCF and P-CSCF, P-CSCF > > > and I-CSCF, I-CSCF and S-CSCF, S-CSCF and AS, and AS-AS, and of course the > > > inverses of those. There's some debate about whether AS may also directly > > > interface to other SIP nodes withot using S-CSCF and I-CSCF, or may go > > > directly to I-CSCF or other firewall proxy without transiting S-CSCF. Mine > > > can -- why pay extra for more S-CSCF than one really needs? But it's > > > configurable so that people who really want to spend more money can do so . > > > . . Free enterprise loves Darwin's dead-end branches if they're well-funded. > > > There's also another edge-proxy node called a THIG that may appear in > > > various locations and speaks SIP. > > > > > > -- > > > Dean > > > > > > ----- Original Message ----- > > > From: "Vijaya Venkatachalam" > > > To: > > > Sent: Monday, August 27, 2001 12:53 PM > > > Subject: [Sip] 3gpp & sip > > > > > > > Hi, > > > > > > > > Which all interfaces in 3GPP are using SIP? > > > > > > > > Thanks, > > > > Vijaya > > > > > > > > > > > > > > _______________________________________________ > > > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the application of sip > > > > -- > > Miguel-Angel Garcia Oy LM Ericsson AB > > Jorvas, Finland > > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 21:05:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01415 for ; Thu, 30 Aug 2001 21:05:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16334; Thu, 30 Aug 2001 20:30:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA16231 for ; Thu, 30 Aug 2001 20:30:50 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01071 for ; Thu, 30 Aug 2001 20:29:30 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7V0TUob010236 for ; Thu, 30 Aug 2001 20:29:30 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 20:30:21 -0400 Message-ID: From: Rakesh Shah To: "SIPWG Mailing List (sip@ietf.org)" Date: Thu, 30 Aug 2001 20:30:19 -0400 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C131B4.1CE887C0" Subject: [Sip] SIP WG - Last Call Weekly Status Update Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C131B4.1CE887C0 Content-Type: text/plain Dear SIP Working Group Members, This Working Group Last Call status is being sent out to keep the you up-to-speed. Any questions about this information can be addressed to Rakesh Shah (mailto:rshah@dynamicsoft.com ). Drafts in WGLC draft-ietf-sip-serverfeatures-05.txt Awaiting comments from A. Mankin. WGLC completed. Draft was submitted to IESG, returned for updates and updates were made by authors. The draft was then passed on to AD for IESG submittal. draft-ietf-sip-session-timer-06.txt WGLC complete. Chairs being polled to send this on to IESG. There will be IESG changes and internal changes can be made at that time. draft-ietf-sip-callerprefs-04.txt Last Call review started. Open list discussion announced and will be closed on 7Sep01. draft-ietf-sip-mib-03.txt LC reviewers contacted. Delay in finding LC reviewers. Will cause date slide. Dates updated. draft-ietf-sip-manyfolks-resource-01.txt NITS review complete. Looking for LC reviewers. (Critical to 3GPP.) draft-ietf-sip-call-auth-01.txt NITS review started. Awaiting reply. Queued up after callerprefs. (Critical for 3GPP.) Drafts Queued for WGLC draft-ietf-sip-privacy-02.txt Will have a -03 issued. -03 will be ready for WGLC. Will generate a lot of debate. (3GPP interest.) draft-ietf-sip-state-01.txt Ready for WGLC. Queued up after call-auth. draft-ietf-sip-rfc2543bis-04.txt Authors actively trying to close issues. Authors (and others) undertaking rewrite to make draft easier to comprehend. WGLC process expected to begin in early October. draft-johnston-sip-osp-token-01.txt Progressing to WGLC. draft-ietf-sip-100rel-03.txt Feedback expected from A. Mankin. Dependency on "supported" (serverfeatures). This information is kept up-to-date on the supplemental SIP WG Web site (link below). Links Last Call Calendar - http://www.softarmor.com/sipwg/lastcall/lccalendar.pl Supplemental SIP WG Web site - http://www.softarmor.com/sipwg Regards, Rakesh ______________________________ Mr. Rakesh C. Shah Project Coordinator dynamicsoft Inc. 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 (973) 952-5000 main (973) 952-5066 direct (201) 214-6084 mobile (973) 952-5050 fax rshah@dynamicsoft.com www.dynamicsoft.com ------_=_NextPart_001_01C131B4.1CE887C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Dear SIP = Working Group Members,

 

This Working Group Last Call status is being sent out to keep the you up-to-speed.

 

Any questions about this information can be addressed to Rakesh Shah (mailto:rshah@dynamicsoft.com).=

 

Drafts in = WGLC

 

draft-ietf-si= p-serverfeatures-05.txt

Awaiting = comments from A. Mankin= . WGLC completed. Draft was submitted to IESG, returned for updates and = updates were made by authors. The draft was then passed on to AD for IESG = submittal.

 

draft-ietf-si= p-session-timer-06.txt

WGLC = complete. Chairs being polled to send this on to = IESG. There will be IESG changes and internal changes can be made at that = time.

 

draft-ietf-si= p-callerprefs-04.txt

Last Call = review started. Open list discussion announced and will be closed on = 7Sep01.

 

draft-ietf-si= p-mib-03.txt

LC reviewers contacted. Delay in finding LC reviewers. Will cause date slide. Dates = updated.

 

draft-ietf-si= p-manyfolks-resource-01.txt

NITS review = complete. Looking for LC reviewers. (Critical to 3GPP.)

 

draft-ietf-si= p-call-auth-01.txt

NITS review = started. Awaiting reply. Queued up = after callerprefs. (Critical = for 3GPP.)

 

Drafts = Queued for WGLC

 

draft-ietf-si= p-privacy-02.txt

Will have a = -03 issued. -03 will be ready for WGLC. Will generate a = lot of debate. (3GPP = interest.)

 

draft-ietf-si= p-state-01.txt

Ready for = WGLC. Queued up after = call-auth.

 

draft-ietf-si= p-rfc2543bis-04.txt

Authors = actively trying to close issues. Authors (and others) undertaking rewrite to make draft easier to = comprehend. WGLC process expected to begin in early = October.

 

draft-johnsto= n-sip-osp-token-01.txt

Progressing = to WGLC.

 

draft-ietf-si= p-100rel-03.txt

Feedback = expected from A. Mankin. Dependency on "supported" = (serverfeatures).

 

This information is kept up-to-date on the supplemental SIP WG Web site = (link below).

 

Links

 

Last Call = Calendar - http://ww= w.softarmor.com/sipwg/lastcall/lccalendar.pl

Supplemental = SIP WG Web site - http://www.softarmor.com/sipwg

 

Regards,

 

Rakesh

______________________________

Mr. Rakesh C. Shah

Project Coordinator

dynamicsoft Inc.

72 Eagle Rock = Avenue

First Floor

East Hanover, NJ = 07936

(973) 952-5000 main

(973) 952-5066 direct

(201) 214-6084 mobile

(973) 952-5050 fax

rshah@d= ynamicsoft.com

www.dyn= amicsoft.com

 

------_=_NextPart_001_01C131B4.1CE887C0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 23:48:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05453 for ; Thu, 30 Aug 2001 23:48:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20008; Thu, 30 Aug 2001 23:29:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA19981 for ; Thu, 30 Aug 2001 23:29:08 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04802 for ; Thu, 30 Aug 2001 23:27:47 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7V3Rfob010718; Thu, 30 Aug 2001 23:27:41 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 23:28:32 -0400 Message-ID: From: Jonathan Rosenberg To: "'brett@broadsoft.com'" , sip@ietf.org Subject: RE: [SIP] Killing hung media streams Date: Thu, 30 Aug 2001 23:28:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Wednesday, August 29, 2001 8:39 PM > To: sip@ietf.org > Subject: RE: [SIP] Killing hung media streams > > > > > Why must the UAC send a bye when a 481 is received? I > > > thought that the > > > 481 implies that the call leg is terminated. Section 15.5 > > > states that > > > "A UAC receiving a 481 response for any mid-call request > > > (INVITE or otherwise) > > > MUST consider the call terminated." > > > > Thats the problem. I think this text is wrong. It should send > > a BYE, and > > then consider the call terminated as a result. > > > > Why? Well, we have a general rule that a non-2xx response to > > a re-INVITE > > does not mean the call is dead. Only BYE terminates a call. > > I'd like to keep > > that rule, since it provides a single, consistent way for > everyone to > > say/know whether the call is up or down. > > > > I feel very strongly about this one. Having multiple ways of > > signaling that > > a call is down is very bad, IMHO. > > I thought that this issue was closed per IETF 49 > with a 481 meaning that the call-leg is dead; > thus no need to send a BYE. > > http://www.softarmor.com/sipwg/meets/ietf49/minutes/minutes-sip-49.htm Wow... my recollection is exactly the opposite. Possibly thats biased by my own opinion on the correct solution, but I could have sworn that people concurred that we were going to stick with the rule that 4xx response to re-INVITE did not terminate a call. > > I realize that call-stateful proxies might want > to avoid snooping for a 481. However based upon > the captured minutes and the hum at the meeting, > I assume that many UA's would have to be modified > to start sending the BYE for dead call-legs. Well, someone needs to change. Either UA's change to send BYE, or proxies and other elements change to support 481 indicated call termination. I generall prefer pushing intelligence out towards the edge. Let us definitely resolve this quickly. Please, if you have an opinion, POST! -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Thu Aug 30 23:54:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05512 for ; Thu, 30 Aug 2001 23:54:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20408; Thu, 30 Aug 2001 23:35:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20375 for ; Thu, 30 Aug 2001 23:35:20 -0400 (EDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05211 for ; Thu, 30 Aug 2001 23:33:58 -0400 (EDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id A4DE61E067 for ; Thu, 30 Aug 2001 23:35:20 -0400 (EDT) Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id XAA10412 for ; Thu, 30 Aug 2001 23:35:19 -0400 (EDT) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id XAA82343 for sip@ietf.org; Thu, 30 Aug 2001 23:36:14 -0400 (EDT) Date: Thu, 30 Aug 2001 23:36:14 -0400 (EDT) Message-Id: <200108310336.XAA82343@fish.research.att.com> To: sip@ietf.org Subject: [Sip] Updated dcsgroup drafts Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Several of the dcsgroup internet-drafts are due to expire this month. I have submitted updated versions of them to internet-drafts@ietf.org draft-dcsgroup-sip-arch-05.txt draft-dcsgroup-sip-proxy-proxy-05.txt draft-ietf-sip-call-auth-02.txt draft-ietf-sip-manyfolks-resource-02.txt draft-ietf-sip-state-02.txt In all cases the most major change was the expiration date. I also took the opportunity to fold in the various nits and corrections that have appeared on the list, and also those corrections which have been sent to me directly. Until they appear in the normal place, they may be obtained from ftp://ftp.research.att.com/dist/wtm/draft-..... Also in that same directory are the MSWord .doc files, FYI, which contain the tracked changes since the last submitted version. Bill Marshall wtm@research.att.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 00:04:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05584 for ; Fri, 31 Aug 2001 00:04:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20701; Thu, 30 Aug 2001 23:53:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20672 for ; Thu, 30 Aug 2001 23:53:32 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05489 for ; Thu, 30 Aug 2001 23:52:11 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7V3q1ob010791; Thu, 30 Aug 2001 23:52:01 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 23:52:53 -0400 Message-ID: From: Jonathan Rosenberg To: "'Christer Holmberg'" , Juha Heinanen Cc: sip@ietf.org Subject: RE: [Sip] MUST 200 OK contain SDP? Date: Thu, 30 Aug 2001 23:52:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Thursday, August 30, 2001 3:19 PM > To: Juha Heinanen > Cc: sip@ietf.org > Subject: Re: [Sip] MUST 200 OK contain SDP? > > > > True. > > Christer (lmfchh) > > Juha Heinanen wrote: > > > > Christer Holmberg writes: > > > > > The spec is correct - the 2xx MUST contain a session description. > > > > the spec is not correct before the word MUST appears in the the 2xx > > sentence. > > > > -- juha > Well, the wording since bis-03 at least is crystal clear in this regard. From Appendix B: The usage of SDP within SIP follows an "offer-answer" model. One side offers an SDP that provides their view of the session, and the other side answers the SDP with a matching one. The offer-answer model MAY occur in two ways. The offer MAY be placed in an INVITE, in which case the the answer MUST be in a 200 class response, and the ACK MUST NOT contain SDP. Or, the INVITE MAY contain no SDP, in which case the offer MUST be in the 200 class response, and the ACK MUST contain the answer. Thats pretty darn clear. Both of the two allowed conditions have a MUST for the 2xx to contain SDP. I will fix the inconsistency with section 12.1. In any case, since 18x is optional and not even reliable, it would make no sense to just "skip" the SDP in the 2xx because it was sent in the 1xx. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 00:28:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08001 for ; Fri, 31 Aug 2001 00:28:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA21355; Fri, 31 Aug 2001 00:08:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA21325 for ; Fri, 31 Aug 2001 00:08:54 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05601 for ; Fri, 31 Aug 2001 00:07:35 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.156]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7V47Sob010833; Fri, 31 Aug 2001 00:07:28 -0400 (EDT) Message-ID: <3B8F0DB3.6CA650A9@dynamicsoft.com> Date: Fri, 31 Aug 2001 00:08:19 -0400 From: Anders Kristensen X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'brett@broadsoft.com'" , sip@ietf.org Subject: Re: [SIP] Killing hung media streams References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Well, someone needs to change. Either UA's change to send BYE, or proxies > and other elements change to support 481 indicated call termination. I > generall prefer pushing intelligence out towards the edge. > > Let us definitely resolve this quickly. Please, if you have an opinion, > POST! Seems more regular to insist on having UACs always send BYE. Consider this a HUM in favor of that approach. Hummmm. Anders _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 07:21:05 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28704 for ; Fri, 31 Aug 2001 07:21:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08210; Fri, 31 Aug 2001 07:00:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA08184 for ; Fri, 31 Aug 2001 07:00:34 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27959; Fri, 31 Aug 2001 06:59:12 -0400 (EDT) Message-Id: <200108311059.GAA27959@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 31 Aug 2001 06:59:11 -0400 Subject: [Sip] I-D ACTION:draft-ietf-sip-session-timer-06.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Session Timer Author(s) : S. Donovan, J. Rosenberg Filename : draft-ietf-sip-session-timer-06.txt Pages : 30 Date : 30-Aug-01 This document proposes an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE. The refresh allows both user agents and proxies to determine if the SIP session is still active. The extension defines two new general headers, Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-session-timer-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-session-timer-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010830111659.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-session-timer-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-session-timer-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010830111659.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 10:53:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07216 for ; Fri, 31 Aug 2001 10:53:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13128; Fri, 31 Aug 2001 10:36:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13012 for ; Fri, 31 Aug 2001 10:36:02 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06790; Fri, 31 Aug 2001 10:34:39 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA16232; Fri, 31 Aug 2001 09:35:20 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Fri, 31 Aug 2001 09:36:02 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Aug 2001 09:35:15 -0500 Message-ID: <9A9367D1556AD21182C40000F80930AB04411D71@crchy28b.us.nortel.com> From: "Sriram Parameswar" To: "'sip@ietf.org'" , "'sipping@ietf.org'" Date: Fri, 31 Aug 2001 09:35:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1322A.21E9A4E0" Subject: [Sip] SIP Negotiate Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1322A.21E9A4E0 Content-Type: text/plain; charset="iso-8859-1" Hi, We have just submitted a new I-D on negotiation of meta-session parameters for SIP sessions. Until the draft appears in the archives, you can pick up a copy at: http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt We invite your comments, the abstract is included below for your perusal. Thanks, Sriram Parameswar Brian Stucker -------------------------------------------------------------- Abstract: There is a need to negotiate a multitude of parameters, settings, and algorithms when setting up sessions using Session Initiated Protocol (SIP). While SIP itself provides mechanisms for negotiation of these parameters on a per-session basis through the use of the INVITE method, it does not provide a ready mechanism for meta-session negotiation. The closest mechanism provided is the REGISTER method, however, this method is directed towards the registrar alone, and cannot be used to conduct negotiation of parameters between any two arbitrary SIP nodes. Examples of parameters that may need to be negotiated (and thus, the ready impetus for providing a simple mechanism to handle this) include: compression algorithms, code book size, message integrity mechanisms, encryption algorithms, etc. Many of these parameters are not always eligible for use in an INVITE method, for two reasons: - The INVITE method describes the parameters for initiation of a particular session. Once the session is over, the negotiated settings (such as the RTP profile used, in the case of SDP) are invalidated for future re-use. It would be inefficient to have to renegotiate parameters that are the same from session to session, or have to transmit large quantities of persistent data (such as a code book) each time. - Many meta-session applications (and therefore their attendant negotiable parameters) are best utilized if they can be applied for the first message of a session. An example of this would be header compression. If the INVITE were compressed, then the header that identifies the type of compression in use would also be compressed, and therefore unintelligible (assuming no shim mechanism). This document seeks to solve these problems by introducing a SIP extension that allows for meta-session parameters to be negotiated in a generic manner. This negotiation would take place prior to session establishment, between any two SIP entities (User Agents, Proxies etc.). __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com ------_=_NextPart_001_01C1322A.21E9A4E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP Negotiate

Hi,

We have just submitted a new I-D on = negotiation of meta-session parameters for SIP sessions. Until the = draft appears in the archives, you can pick up a copy at:

http://www.obsidian97.com/draft-spbs-sip-negotiate-00.= txt

We invite your comments, the abstract = is included below for your perusal.

Thanks,

Sriram Parameswar
Brian Stucker
--------------------------------------------------------------
Abstract:
There is a need to negotiate a = multitude of parameters, settings, and algorithms when setting up = sessions using Session Initiated Protocol (SIP). While SIP itself = provides mechanisms for negotiation of these parameters on a = per-session basis through the use of the INVITE method, it does not = provide a ready mechanism for meta-session negotiation. The closest = mechanism provided is the REGISTER method, however, this method is = directed towards the registrar alone, and cannot be used to conduct = negotiation of parameters between any two arbitrary SIP nodes. Examples = of parameters that may need to be negotiated (and thus, the ready = impetus for providing a simple mechanism to handle this) include: = compression algorithms, code book size, message integrity mechanisms, = encryption algorithms, etc. Many of these parameters are not always = eligible for use in an INVITE method, for two reasons:

    - The INVITE method describes the = parameters for initiation of a particular session. Once the session is = over, the negotiated settings (such as the RTP profile used, in the = case of SDP) are invalidated for future re-use. It would be inefficient = to have to renegotiate parameters that are the same from session to = session, or have to transmit large quantities of persistent data (such = as a code book) each time.

    - Many meta-session applications (and = therefore their attendant negotiable parameters) are best utilized if = they can be applied for the first message of a session. An example of = this would be header compression. If the INVITE were compressed, then = the header that identifies the type of compression in use would also be = compressed, and therefore unintelligible (assuming no shim mechanism). =

This document seeks to solve these = problems by introducing a SIP extension that allows for meta-session = parameters to be negotiated in a generic manner. This negotiation would = take place prior to session establishment, between any two SIP entities = (User Agents, Proxies etc.).

__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: = 972-685-8540
Interactive Multimedia Server (IMS) = Fax: 972-685-3563
Nortel Networks, Richardson = USA  Email: = sriramp@nortelnetworks.com

------_=_NextPart_001_01C1322A.21E9A4E0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 11:02:36 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07391 for ; Fri, 31 Aug 2001 11:02:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13222; Fri, 31 Aug 2001 10:41:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA13191 for ; Fri, 31 Aug 2001 10:41:36 -0400 (EDT) Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06910 for ; Fri, 31 Aug 2001 10:40:14 -0400 (EDT) From: John.Hearty@Level3.com Received: from f1ee40-19.idc1.level3.com (hme1.f1ee40-19.idc1.oss.level3.com [10.1.146.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id OAA12913; Fri, 31 Aug 2001 14:41:35 GMT Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id OAA20770; Fri, 31 Aug 2001 14:41:25 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2653.19) id <3RFYCHS7>; Fri, 31 Aug 2001 08:41:24 -0600 Message-ID: <17052388D394D411803900508BDFFAF601B36EE0@n0214idc1.oss.level3.com> To: akristensen@dynamicsoft.com, jdrosen@dynamicsoft.com Cc: brett@broadsoft.com, sip@ietf.org Subject: RE: [SIP] Killing hung media streams Date: Fri, 31 Aug 2001 08:41:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Agreed. Most of the intelligence belongs at the edge. Hummm. -----Original Message----- From: Anders Kristensen [mailto:akristensen@dynamicsoft.com] Sent: Thursday, August 30, 2001 10:08 PM To: Jonathan Rosenberg Cc: 'brett@broadsoft.com'; sip@ietf.org Subject: Re: [SIP] Killing hung media streams Jonathan Rosenberg wrote: > > Well, someone needs to change. Either UA's change to send BYE, or proxies > and other elements change to support 481 indicated call termination. I > generall prefer pushing intelligence out towards the edge. > > Let us definitely resolve this quickly. Please, if you have an opinion, > POST! Seems more regular to insist on having UACs always send BYE. Consider this a HUM in favor of that approach. Hummmm. Anders _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 11:18:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07633 for ; Fri, 31 Aug 2001 11:18:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14102; Fri, 31 Aug 2001 11:01:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14074 for ; Fri, 31 Aug 2001 11:01:36 -0400 (EDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07356 for ; Fri, 31 Aug 2001 11:00:14 -0400 (EDT) Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7VF1WL20125; Fri, 31 Aug 2001 11:01:32 -0400 (EDT) Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA23132; Fri, 31 Aug 2001 10:01:31 -0500 (CDT) Message-ID: <3B8FA6C9.698017C0@lucent.com> Date: Fri, 31 Aug 2001 10:01:29 -0500 From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org Subject: Re: [SIP] Killing hung media streams References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] > Wow... my recollection is exactly the opposite. Possibly thats biased by > my own opinion on the correct solution, but I could have sworn that people > concurred that we were going to stick with the rule that 4xx response to > re-INVITE did not terminate a call. Jonathan: I recall having a similar discussion with you on the list in the context of the call reconstitution I-D. The gist of the discussion is that the BYE is is needed. Going into the discussion I was unsure why this is so, but have changed my mind since then. The reasons why BYE is preferred are listed in http://www1.ietf.org/mail-archive/working-groups/sip/current/msg00559.html - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 11:21:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07673 for ; Fri, 31 Aug 2001 11:21:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14204; Fri, 31 Aug 2001 11:06:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14173 for ; Fri, 31 Aug 2001 11:06:21 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07427 for ; Fri, 31 Aug 2001 11:04:58 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7VF6Kp29197 for ; Fri, 31 Aug 2001 10:06:20 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7VF6KY12159 for ; Fri, 31 Aug 2001 10:06:20 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Fri Aug 31 10:06:19 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Aug 2001 10:06:19 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Sriram Parameswar'" , "'sip@ietf.org'" , "'sipping@ietf.org'" Date: Fri, 31 Aug 2001 10:06:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1322E.7CFCC7F0" Subject: [Sip] RE: [Sipping] SIP Negotiate Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1322E.7CFCC7F0 Content-Type: text/plain; charset="iso-8859-1" Hello, I have a few immediate comments. First, I agree that such a mechanism is needed. My comments really are directed at the details of your proposal. 1) Do we need to define a named extension "negotiate"? It seems the Allow: header and the 405 response give you everything you need in this regard. 2) Would it be possible to use the OPTIONS method instead? I realize this is a bit of a twist on OPTIONS. Alternatively, a nested INVITE might work. 3) It seems that some of the information that you are negotiating should be applied on a per-session basis and should not necessarily be used across sessions (e.g keys). Do you anticipate sending a NEGOTIATE request before every INVITE? The Expires: header doesn't really give you the level of control that I'm talking about. 4) For stateless proxy operation, it seems more appropriate to include/reiterate the meta session parameters in the INVITE. That is, I wouldn't expect a stateless proxy to use parameters in the NEGOTIATE for the "next" INVITE. Naturally, there are some parameters that will be completely meaningless to a stateless proxy. Compression may be one example. 5) I would treat NEGOTIATE exactly like SUBSCRIBE with respect to forking proxies. 6) In your MD5 hash description, you convert the To/From URL to all uppercase. This is a bit pedantic, but wouldn't you want to preserve the case of at least the userinfo portion of those URLs for uniqueness? Regards, Sean Olson Ericsson Inc. -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Friday, August 31, 2001 9:35 AM To: 'sip@ietf.org'; 'sipping@ietf.org' Subject: [Sipping] SIP Negotiate Hi, We have just submitted a new I-D on negotiation of meta-session parameters for SIP sessions. Until the draft appears in the archives, you can pick up a copy at: http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt We invite your comments, the abstract is included below for your perusal. Thanks, Sriram Parameswar Brian Stucker ------_=_NextPart_001_01C1322E.7CFCC7F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] SIP Negotiate

Hello,

I have a few immediate comments. First, I agree that = such
a mechanism is needed. My comments really are =
directed at the details of your proposal.

1) Do we need to define a named extension = "negotiate"?
   It seems the Allow: header and the 405 = response give
   you everything you need in this = regard.

2) Would it be possible to use the OPTIONS method = instead?
   I realize this is a bit of a twist on = OPTIONS.

   Alternatively, a nested INVITE might = work.

3) It seems that some of the information that = you
   are negotiating should be applied on a = per-session
   basis and should not necessarily be = used across
   sessions (e.g keys). Do you anticipate = sending a
   NEGOTIATE request before every INVITE? = The Expires:
   header doesn't really give you the = level of control
   that I'm talking about.

4) For stateless proxy operation, it seems more = appropriate
   to include/reiterate the meta session = parameters in the
   INVITE. That is, I wouldn't expect a = stateless proxy
   to use parameters in the NEGOTIATE for = the "next" INVITE.
   Naturally, there are some parameters = that will be completely
   meaningless to a stateless proxy. = Compression may be one
   example.

5) I would treat NEGOTIATE exactly like SUBSCRIBE = with
   respect to forking proxies.

6) In your MD5 hash description, you convert the = To/From URL
   to all uppercase. This is a bit = pedantic, but wouldn't
   you want to preserve the case of at = least the userinfo
   portion of those URLs for = uniqueness?

Regards,
Sean Olson
Ericsson Inc.


-----Original Message-----
From: Sriram Parameswar [mailto:sriramp@nortelnetworks= .com]
Sent: Friday, August 31, 2001 9:35 AM
To: 'sip@ietf.org'; 'sipping@ietf.org'
Subject: [Sipping] SIP Negotiate


Hi,
We have just submitted a new I-D on negotiation of = meta-session parameters for SIP sessions. Until the draft appears in = the archives, you can pick up a copy at:

http://www.obsidian97.com/draft-spbs-sip-negotiate-00.= txt
We invite your comments, the abstract is included = below for your perusal.
Thanks,
Sriram Parameswar
Brian Stucker

------_=_NextPart_001_01C1322E.7CFCC7F0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 11:28:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07871 for ; Fri, 31 Aug 2001 11:28:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14740; Fri, 31 Aug 2001 11:18:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14612 for ; Fri, 31 Aug 2001 11:17:54 -0400 (EDT) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07610; Fri, 31 Aug 2001 11:16:32 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA26713; Fri, 31 Aug 2001 11:17:21 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10004; Fri, 31 Aug 2001 11:17:23 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 31 Aug 2001 11:17:20 -0400 Message-ID: <313680C9A886D511A06000204840E1CF57C064@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sean Olson (EUS)'" , "'Sriram Parameswar'" , "'sip@ietf.org'" , "'sipping@ietf.org'" Subject: RE: [Sip] RE: [Sipping] SIP Negotiate Date: Fri, 31 Aug 2001 11:17:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13230.06D843E0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13230.06D843E0 Content-Type: text/plain; charset="iso-8859-1" Would future responders to this thread PLEASE remove the copy to sipping. If this were to be adopted as a work item based on this draft, it would be a work item for sip. It's conceivable we could take a step back and ask sipping to do a requirements document. For the moment, let's keep the comments on the sip list ONLY. In general NEVER post the same message to sip and sipping. If you have a doubt, ask a chair near you. Brian -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Friday, August 31, 2001 11:06 AM To: 'Sriram Parameswar'; 'sip@ietf.org'; 'sipping@ietf.org' Subject: [Sip] RE: [Sipping] SIP Negotiate Hello, I have a few immediate comments. First, I agree that such a mechanism is needed. My comments really are directed at the details of your proposal. 1) Do we need to define a named extension "negotiate"? It seems the Allow: header and the 405 response give you everything you need in this regard. 2) Would it be possible to use the OPTIONS method instead? I realize this is a bit of a twist on OPTIONS. Alternatively, a nested INVITE might work. 3) It seems that some of the information that you are negotiating should be applied on a per-session basis and should not necessarily be used across sessions (e.g keys). Do you anticipate sending a NEGOTIATE request before every INVITE? The Expires: header doesn't really give you the level of control that I'm talking about. 4) For stateless proxy operation, it seems more appropriate to include/reiterate the meta session parameters in the INVITE. That is, I wouldn't expect a stateless proxy to use parameters in the NEGOTIATE for the "next" INVITE. Naturally, there are some parameters that will be completely meaningless to a stateless proxy. Compression may be one example. 5) I would treat NEGOTIATE exactly like SUBSCRIBE with respect to forking proxies. 6) In your MD5 hash description, you convert the To/From URL to all uppercase. This is a bit pedantic, but wouldn't you want to preserve the case of at least the userinfo portion of those URLs for uniqueness? Regards, Sean Olson Ericsson Inc. -----Original Message----- From: Sriram Parameswar [ mailto:sriramp@nortelnetworks.com ] Sent: Friday, August 31, 2001 9:35 AM To: 'sip@ietf.org'; 'sipping@ietf.org' Subject: [Sipping] SIP Negotiate Hi, We have just submitted a new I-D on negotiation of meta-session parameters for SIP sessions. Until the draft appears in the archives, you can pick up a copy at: http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt We invite your comments, the abstract is included below for your perusal. Thanks, Sriram Parameswar Brian Stucker ------_=_NextPart_001_01C13230.06D843E0 Content-Type: text/html; charset="iso-8859-1" RE: [Sipping] SIP Negotiate
Would future responders to this thread PLEASE remove
the copy to sipping.  If this were to be adopted as a work
item based on this draft, it would be a work item for sip.
It's conceivable we could take a step back and ask
sipping to do a requirements document.  For the
moment, let's keep the comments on the sip list ONLY.
 
In general NEVER post the same message to sip and
sipping.  If you have a doubt, ask a chair near you.
 
Brian
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Friday, August 31, 2001 11:06 AM
To: 'Sriram Parameswar'; 'sip@ietf.org'; 'sipping@ietf.org'
Subject: [Sip] RE: [Sipping] SIP Negotiate

Hello,

I have a few immediate comments. First, I agree that such
a mechanism is needed. My comments really are
directed at the details of your proposal.

1) Do we need to define a named extension "negotiate"?
   It seems the Allow: header and the 405 response give
   you everything you need in this regard.

2) Would it be possible to use the OPTIONS method instead?
   I realize this is a bit of a twist on OPTIONS.

   Alternatively, a nested INVITE might work.

3) It seems that some of the information that you
   are negotiating should be applied on a per-session
   basis and should not necessarily be used across
   sessions (e.g keys). Do you anticipate sending a
   NEGOTIATE request before every INVITE? The Expires:
   header doesn't really give you the level of control
   that I'm talking about.

4) For stateless proxy operation, it seems more appropriate
   to include/reiterate the meta session parameters in the
   INVITE. That is, I wouldn't expect a stateless proxy
   to use parameters in the NEGOTIATE for the "next" INVITE.
   Naturally, there are some parameters that will be completely
   meaningless to a stateless proxy. Compression may be one
   example.

5) I would treat NEGOTIATE exactly like SUBSCRIBE with
   respect to forking proxies.

6) In your MD5 hash description, you convert the To/From URL
   to all uppercase. This is a bit pedantic, but wouldn't
   you want to preserve the case of at least the userinfo
   portion of those URLs for uniqueness?

Regards,
Sean Olson
Ericsson Inc.


-----Original Message-----
From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: Friday, August 31, 2001 9:35 AM
To: 'sip@ietf.org'; 'sipping@ietf.org'
Subject: [Sipping] SIP Negotiate


Hi,
We have just submitted a new I-D on negotiation of meta-session parameters for SIP sessions. Until the draft appears in the archives, you can pick up a copy at:

http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt
We invite your comments, the abstract is included below for your perusal.
Thanks,
Sriram Parameswar
Brian Stucker

------_=_NextPart_001_01C13230.06D843E0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 12:06:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08884 for ; Fri, 31 Aug 2001 12:06:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15718; Fri, 31 Aug 2001 11:54:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15690 for ; Fri, 31 Aug 2001 11:54:01 -0400 (EDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08358 for ; Fri, 31 Aug 2001 11:52:38 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f7VFrsK14314; Fri, 31 Aug 2001 17:53:55 +0200 (MEST) Received: from ericsson.com (ppp15.lmf.ericsson.se [131.160.102.15]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f7VFrqb10833; Fri, 31 Aug 2001 18:53:52 +0300 (EET DST) Message-ID: <3B8FB30E.6450DDFB@ericsson.com> Date: Fri, 31 Aug 2001 18:53:50 +0300 From: "Miguel A. Garcia" Organization: OY LM Ericsson AB X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: es,en MIME-Version: 1.0 To: sip@ietf.org, Gonzalo Camarillo CC: jdrosen@dynamicsoft.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] New book on SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I am pleased to announce a new book on SIP. "SIP demystified" is written by Gonzalo Camarillo and prefaced by Jonathan Rosenberg. More information is available at: http://www.amazon.com/exec/obidos/ASIN/0071373403/qid%3D987979441/104-4016612-5783104 /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 5140002 _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 12:26:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09521 for ; Fri, 31 Aug 2001 12:26:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17510; Fri, 31 Aug 2001 12:15:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17480 for ; Fri, 31 Aug 2001 12:15:33 -0400 (EDT) Received: from rautu.eng.telia.fi (root@rautu.eng.telia.fi [195.10.149.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09165 for ; Fri, 31 Aug 2001 12:14:10 -0400 (EDT) Received: from rautu.eng.telia.fi (mail@localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f7VGFFCx000671; Fri, 31 Aug 2001 19:15:16 +0300 Received: (from jh@localhost) by rautu.eng.telia.fi (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f7V6jkDP000518; Fri, 31 Aug 2001 09:45:46 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15247.12954.241829.183733@rautu.eng.telia.fi> Date: Fri, 31 Aug 2001 09:45:46 +0300 To: Terry L Anderson Cc: SIP Mailing List Subject: [Sip] use of outbound proxies In-Reply-To: <3B8E8942.52E5226F@lucent.com> References: <3B8E8942.52E5226F@lucent.com> X-Mailer: VM 6.92 under Emacs 19.34.1 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Terry L Anderson writes: > draft-ietf-sip-rfc2543bis-04 appears to have contradictory rule on > routing of subsequent requests. 15.4 (next to last paragraph) appears > to say that whenever UAC is configured with an outbound proxy, it sends > all subsequent requests there regardless of Request-URI (and so > regardless of route list). > > But 16.4.1 appears to say the UAC does this only if there are no Route > headers or UA has no support for DNS. > > Which is the intended behavior? > 1) always route to outbound proxy > 2) use outbound proxy only as last resort, for subsequent requests i brought this same issue up before the london ietf. i don't think that there is any conclusion yet. if a firewall restricts sip traffic only to the outbound proxy, then 1) is the only possible choice. one could argue that in that case the outbound proxy should record route, which would make the problem go away. on the other hand, the outbound proxy may not be controlled by the same entity as the firewall and may not want to record route. -- juha _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 12:41:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09921 for ; Fri, 31 Aug 2001 12:41:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18110; Fri, 31 Aug 2001 12:26:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18079 for ; Fri, 31 Aug 2001 12:26:45 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09475 for ; Fri, 31 Aug 2001 12:25:21 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA04245 for ; Fri, 31 Aug 2001 11:25:54 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Fri, 31 Aug 2001 11:15:28 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Aug 2001 11:21:43 -0500 Message-ID: <9A9367D1556AD21182C40000F80930AB04411D78@crchy28b.us.nortel.com> From: "Sriram Parameswar" To: "'Sean Olson (EUS)'" , "'sip@ietf.org'" Date: Fri, 31 Aug 2001 11:21:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13239.015FBA20" X-Orig: Subject: [Sip] RE: [Sipping] SIP Negotiate Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13239.015FBA20 Content-Type: text/plain; charset="iso-8859-1" Sean, Thanks for you comments. My reply in-line prefaced by [SP]. Best Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Friday, August 31, 2001 10:06 AM To: Parameswar, Sriram [NGB:B658:EXCH]; 'sip@ietf.org'; 'sipping@ietf.org' Subject: RE: [Sipping] SIP Negotiate Hello, I have a few immediate comments. First, I agree that such a mechanism is needed. My comments really are directed at the details of your proposal. 1) Do we need to define a named extension "negotiate"? It seems the Allow: header and the 405 response give you everything you need in this regard. [SP] Allow typically handles SIP Methods, we were looking at session parameters - Code Book size, Compression Algorithms, QoS mechanisms etc. If we extended Allow to perform a Negotiation type role we would have backward compatability issues, also it would be session specific. We are looking for a mechanism that applies across sessions. 2) Would it be possible to use the OPTIONS method instead? I realize this is a bit of a twist on OPTIONS. [SP] we considered OPTIONS when we started this work and it is our opinion that it would break backwards compatability. Alternatively, a nested INVITE might work. [SP] If I understand ths correctly you would use the INVITE to perform negotiations. I see two problems with this approach (please correct me if I have mis-understood): ** this would add to delays in setting up sessions ** Again an INVITE would do this on a session-by-session basis it was our intentions that Negotiated parameters apply across sessions. 3) It seems that some of the information that you are negotiating should be applied on a per-session basis and should not necessarily be used across sessions (e.g keys). Do you anticipate sending a NEGOTIATE request before every INVITE? The Expires: header doesn't really give you the level of control that I'm talking about. [SP] Agreed certain parameters may need to be negotiated on a per session basis. You *could* use Negotiate for such situations too, in this case the Expires header does not have the same value. As an example we are looking at meta-session parameters that you could negotiate that would last across sessions like: compression to your Local Outbound Proxy. 4) For stateless proxy operation, it seems more appropriate to include/reiterate the meta session parameters in the INVITE. That is, I wouldn't expect a stateless proxy to use parameters in the NEGOTIATE for the "next" INVITE. Naturally, there are some parameters that will be completely meaningless to a stateless proxy. Compression may be one example. [SP] Agreed there are problems with Stateless proxies and we do note that in the document. 5) I would treat NEGOTIATE exactly like SUBSCRIBE with respect to forking proxies. [SP] Thanks we will include that in future updates of the document. 6) In your MD5 hash description, you convert the To/From URL to all uppercase. This is a bit pedantic, but wouldn't you want to preserve the case of at least the userinfo portion of those URLs for uniqueness? [SP] Its my initial reaction that we should have uniqueness even with the conversion to uppercase. But will definitely consider removing it if otherwise. Regards, Sean Olson Ericsson Inc. -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Friday, August 31, 2001 9:35 AM To: 'sip@ietf.org'; 'sipping@ietf.org' Subject: [Sipping] SIP Negotiate Hi, We have just submitted a new I-D on negotiation of meta-session parameters for SIP sessions. Until the draft appears in the archives, you can pick up a copy at: http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt We invite your comments, the abstract is included below for your perusal. Thanks, Sriram Parameswar Brian Stucker ------_=_NextPart_001_01C13239.015FBA20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] SIP Negotiate

Sean,

Thanks for you comments. My reply in-line prefaced by = [SP].

Best Regards,

Sriram
__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-685-3563
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Friday, August 31, 2001 10:06 AM
To: Parameswar, Sriram [NGB:B658:EXCH]; = 'sip@ietf.org'; 'sipping@ietf.org'
Subject: RE: [Sipping] SIP Negotiate


Hello,
I have a few immediate comments. First, I agree that = such
a mechanism is needed. My comments really are =
directed at the details of your proposal.
1) Do we need to define a named extension = "negotiate"?
   It seems the Allow: header and the 405 = response give
   you everything you need in this regard. =

[SP] Allow typically handles SIP Methods, we were = looking at session
     parameters - Code Book = size, Compression Algorithms, QoS mechanisms etc.
     If we extended Allow to = perform a Negotiation type role we would have
     backward compatability = issues, also it would be session specific. We are looking
     for a mechanism that = applies across sessions.

2) Would it be possible to use the OPTIONS method = instead?
   I realize this is a bit of a twist on = OPTIONS.

[SP] we considered OPTIONS when we started this work = and
     it is our opinion that it = would break backwards compatability.

   Alternatively, a nested INVITE might = work.

[SP] If I understand ths correctly you would use = the
     INVITE to perform = negotiations. I see two problems with
     this approach (please = correct me if I have mis-understood):
       ** this would = add to delays in setting up sessions
       ** Again an = INVITE would do this on a session-by-session basis
          it was = our intentions that Negotiated parameters apply across
          = sessions.

3) It seems that some of the information that you =
   are negotiating should be applied on a = per-session
   basis and should not necessarily be = used across
   sessions (e.g keys). Do you anticipate = sending a
   NEGOTIATE request before every INVITE? = The Expires:
   header doesn't really give you the = level of control
   that I'm talking about.

[SP] Agreed certain parameters may need to be = negotiated on
     a per session basis. You = *could* use Negotiate for such
     situations too, in this = case the Expires header does
     not have the same value. As = an example we are looking
     at meta-session parameters = that you could negotiate that
     would last across sessions = like: compression to your Local
     Outbound Proxy.

4) For stateless proxy operation, it seems more = appropriate
   to include/reiterate the meta session = parameters in the
   INVITE. That is, I wouldn't expect a = stateless proxy
   to use parameters in the NEGOTIATE for = the "next" INVITE.
   Naturally, there are some parameters = that will be completely
   meaningless to a stateless proxy. = Compression may be one
   example.
[SP] Agreed there are problems with Stateless = proxies and we
     do note that in the = document.

5) I would treat NEGOTIATE exactly like SUBSCRIBE = with
   respect to forking proxies.
[SP] Thanks we will include that in future updates = of the document.

6) In your MD5 hash description, you convert the = To/From URL
   to all uppercase. This is a bit = pedantic, but wouldn't
   you want to preserve the case of at = least the userinfo
   portion of those URLs for uniqueness? =
[SP] Its my initial reaction that we should have = uniqueness even
     with the conversion to = uppercase. But will definitely consider
     removing it if = otherwise.

Regards,
Sean Olson
Ericsson Inc.


-----Original Message-----
From: Sriram Parameswar [mailto:sriramp@nortelnetworks= .com]
Sent: Friday, August 31, 2001 9:35 AM
To: 'sip@ietf.org'; 'sipping@ietf.org'
Subject: [Sipping] SIP Negotiate


Hi,
We have just submitted a new I-D on negotiation of = meta-session parameters for SIP sessions. Until the draft appears in = the archives, you can pick up a copy at:

http://www.obsidian97.com/draft-spbs-sip-negotiate-00.= txt
We invite your comments, the abstract is included = below for your perusal.
Thanks,
Sriram Parameswar
Brian Stucker

------_=_NextPart_001_01C13239.015FBA20-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 13:15:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10928 for ; Fri, 31 Aug 2001 13:15:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19046; Fri, 31 Aug 2001 12:56:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA19019 for ; Fri, 31 Aug 2001 12:56:48 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (zrc2s03g.nortelnetworks.com [47.103.122.66]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10207 for ; Fri, 31 Aug 2001 12:55:25 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA15640 for ; Fri, 31 Aug 2001 11:55:23 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Fri, 31 Aug 2001 11:47:23 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Aug 2001 11:53:37 -0500 Message-ID: <85AA7486A2C1D411BCA20000F8073E430346D3FB@crchy271.us.nortel.com> From: "Brian Stucker" To: "Sriram Parameswar" , "'Sean Olson (EUS)'" , "'sip@ietf.org'" Subject: RE: [Sip] RE: [Sipping] SIP Negotiate Date: Fri, 31 Aug 2001 11:53:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1323D.7B4703D0" X-Orig: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1323D.7B4703D0 Content-Type: text/plain; charset="iso-8859-1" Sean, For your last question, about the MD5, the reason that we specified all uppercase prior to the MD5 hash was because there is no requirement that we're aware of that says that any given SIP node (proxy, UA, etc) has to be case sensitive, or preserve the case of SIP message headers as they traverse the network. So, if we didn't specify a case in the algorithm, the two nodes could come up with two different hash values for the same set of headers. As always, thanks for your comments. Brian -----Original Message----- From: Parameswar, Sriram [NGB:B658:EXCH] Sent: Friday, August 31, 2001 11:22 AM To: 'Sean Olson (EUS)'; 'sip@ietf.org' Subject: [Sip] RE: [Sipping] SIP Negotiate Sean, Thanks for you comments. My reply in-line prefaced by [SP]. Best Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Sean Olson (EUS) [ mailto:sean.olson@ericsson.com ] Sent: Friday, August 31, 2001 10:06 AM To: Parameswar, Sriram [NGB:B658:EXCH]; 'sip@ietf.org'; 'sipping@ietf.org' Subject: RE: [Sipping] SIP Negotiate Hello, I have a few immediate comments. First, I agree that such a mechanism is needed. My comments really are directed at the details of your proposal. 1) Do we need to define a named extension "negotiate"? It seems the Allow: header and the 405 response give you everything you need in this regard. [SP] Allow typically handles SIP Methods, we were looking at session parameters - Code Book size, Compression Algorithms, QoS mechanisms etc. If we extended Allow to perform a Negotiation type role we would have backward compatability issues, also it would be session specific. We are looking for a mechanism that applies across sessions. 2) Would it be possible to use the OPTIONS method instead? I realize this is a bit of a twist on OPTIONS. [SP] we considered OPTIONS when we started this work and it is our opinion that it would break backwards compatability. Alternatively, a nested INVITE might work. [SP] If I understand ths correctly you would use the INVITE to perform negotiations. I see two problems with this approach (please correct me if I have mis-understood): ** this would add to delays in setting up sessions ** Again an INVITE would do this on a session-by-session basis it was our intentions that Negotiated parameters apply across sessions. 3) It seems that some of the information that you are negotiating should be applied on a per-session basis and should not necessarily be used across sessions (e.g keys). Do you anticipate sending a NEGOTIATE request before every INVITE? The Expires: header doesn't really give you the level of control that I'm talking about. [SP] Agreed certain parameters may need to be negotiated on a per session basis. You *could* use Negotiate for such situations too, in this case the Expires header does not have the same value. As an example we are looking at meta-session parameters that you could negotiate that would last across sessions like: compression to your Local Outbound Proxy. 4) For stateless proxy operation, it seems more appropriate to include/reiterate the meta session parameters in the INVITE. That is, I wouldn't expect a stateless proxy to use parameters in the NEGOTIATE for the "next" INVITE. Naturally, there are some parameters that will be completely meaningless to a stateless proxy. Compression may be one example. [SP] Agreed there are problems with Stateless proxies and we do note that in the document. 5) I would treat NEGOTIATE exactly like SUBSCRIBE with respect to forking proxies. [SP] Thanks we will include that in future updates of the document. 6) In your MD5 hash description, you convert the To/From URL to all uppercase. This is a bit pedantic, but wouldn't you want to preserve the case of at least the userinfo portion of those URLs for uniqueness? [SP] Its my initial reaction that we should have uniqueness even with the conversion to uppercase. But will definitely consider removing it if otherwise. Regards, Sean Olson Ericsson Inc. -----Original Message----- From: Sriram Parameswar [ mailto:sriramp@nortelnetworks.com ] Sent: Friday, August 31, 2001 9:35 AM To: 'sip@ietf.org'; 'sipping@ietf.org' Subject: [Sipping] SIP Negotiate Hi, We have just submitted a new I-D on negotiation of meta-session parameters for SIP sessions. Until the draft appears in the archives, you can pick up a copy at: http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt We invite your comments, the abstract is included below for your perusal. Thanks, Sriram Parameswar Brian Stucker ------_=_NextPart_001_01C1323D.7B4703D0 Content-Type: text/html; charset="iso-8859-1" RE: [Sipping] SIP Negotiate
Sean,
 
For your last question, about the MD5, the reason that we specified all uppercase prior to the MD5 hash was because there is no requirement that we're aware of that says that any given SIP node (proxy, UA, etc) has to be case sensitive, or preserve the case of SIP message headers as they traverse the network. So, if we didn't specify a case in the algorithm, the two nodes could come up with two different hash values for the same set of headers.
 
As always, thanks for your comments.
 
Brian
 
-----Original Message-----
From: Parameswar, Sriram [NGB:B658:EXCH]
Sent: Friday, August 31, 2001 11:22 AM
To: 'Sean Olson (EUS)'; 'sip@ietf.org'
Subject: [Sip] RE: [Sipping] SIP Negotiate

Sean,

Thanks for you comments. My reply in-line prefaced by [SP].

Best Regards,

Sriram
__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Friday, August 31, 2001 10:06 AM
To: Parameswar, Sriram [NGB:B658:EXCH]; 'sip@ietf.org'; 'sipping@ietf.org'
Subject: RE: [Sipping] SIP Negotiate


Hello,
I have a few immediate comments. First, I agree that such
a mechanism is needed. My comments really are
directed at the details of your proposal.
1) Do we need to define a named extension "negotiate"?
   It seems the Allow: header and the 405 response give
   you everything you need in this regard.

[SP] Allow typically handles SIP Methods, we were looking at session
     parameters - Code Book size, Compression Algorithms, QoS mechanisms etc.
     If we extended Allow to perform a Negotiation type role we would have
     backward compatability issues, also it would be session specific. We are looking
     for a mechanism that applies across sessions.

2) Would it be possible to use the OPTIONS method instead?
   I realize this is a bit of a twist on OPTIONS.

[SP] we considered OPTIONS when we started this work and
     it is our opinion that it would break backwards compatability.

   Alternatively, a nested INVITE might work.

[SP] If I understand ths correctly you would use the
     INVITE to perform negotiations. I see two problems with
     this approach (please correct me if I have mis-understood):
       ** this would add to delays in setting up sessions
       ** Again an INVITE would do this on a session-by-session basis
          it was our intentions that Negotiated parameters apply across
          sessions.

3) It seems that some of the information that you
   are negotiating should be applied on a per-session
   basis and should not necessarily be used across
   sessions (e.g keys). Do you anticipate sending a
   NEGOTIATE request before every INVITE? The Expires:
   header doesn't really give you the level of control
   that I'm talking about.

[SP] Agreed certain parameters may need to be negotiated on
     a per session basis. You *could* use Negotiate for such
     situations too, in this case the Expires header does
     not have the same value. As an example we are looking
     at meta-session parameters that you could negotiate that
     would last across sessions like: compression to your Local
     Outbound Proxy.

4) For stateless proxy operation, it seems more appropriate
   to include/reiterate the meta session parameters in the
   INVITE. That is, I wouldn't expect a stateless proxy
   to use parameters in the NEGOTIATE for the "next" INVITE.
   Naturally, there are some parameters that will be completely
   meaningless to a stateless proxy. Compression may be one
   example.
[SP] Agreed there are problems with Stateless proxies and we
     do note that in the document.

5) I would treat NEGOTIATE exactly like SUBSCRIBE with
   respect to forking proxies.
[SP] Thanks we will include that in future updates of the document.

6) In your MD5 hash description, you convert the To/From URL
   to all uppercase. This is a bit pedantic, but wouldn't
   you want to preserve the case of at least the userinfo
   portion of those URLs for uniqueness?
[SP] Its my initial reaction that we should have uniqueness even
     with the conversion to uppercase. But will definitely consider
     removing it if otherwise.

Regards,
Sean Olson
Ericsson Inc.


-----Original Message-----
From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: Friday, August 31, 2001 9:35 AM
To: 'sip@ietf.org'; 'sipping@ietf.org'
Subject: [Sipping] SIP Negotiate


Hi,
We have just submitted a new I-D on negotiation of meta-session parameters for SIP sessions. Until the draft appears in the archives, you can pick up a copy at:

http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt
We invite your comments, the abstract is included below for your perusal.
Thanks,
Sriram Parameswar
Brian Stucker

------_=_NextPart_001_01C1323D.7B4703D0-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 17:06:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16120 for ; Fri, 31 Aug 2001 17:06:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24244; Fri, 31 Aug 2001 16:54:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24158 for ; Fri, 31 Aug 2001 16:54:12 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15915 for ; Fri, 31 Aug 2001 16:52:48 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f7VKrf502367 for ; Fri, 31 Aug 2001 15:53:41 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7VKrei22847 for ; Fri, 31 Aug 2001 15:53:40 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Fri Aug 31 15:53:32 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Aug 2001 15:53:32 -0500 Message-ID: From: "Sean Olson (EUS)" To: "'Brian Stucker'" , Sriram Parameswar , "'sip@ietf.org'" Subject: RE: [Sip] RE: [Sipping] SIP Negotiate Date: Fri, 31 Aug 2001 15:53:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1325E.FE6C9C90" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1325E.FE6C9C90 Content-Type: text/plain; charset="iso-8859-1" Take a look at section 2.1 of the bis draft dealing with SIP URL comparison. The user portion of the SIP URL is case-sensitive. This should be taken into account when determining the call leg (based on To:/From: URLs). For example, "sip:BOB@network.com" is not the same as "sip:bob@network.com" It is a very minor nit. My recommendation would be to include the user portion in its original case and everything else in lowercase. This is not strictly correct either. I don't have a perfect solution in mind. Just something to think about. /sean -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Friday, August 31, 2001 11:54 AM To: Sriram Parameswar; 'Sean Olson (EUS)'; 'sip@ietf.org' Subject: RE: [Sip] RE: [Sipping] SIP Negotiate Sean, For your last question, about the MD5, the reason that we specified all uppercase prior to the MD5 hash was because there is no requirement that we're aware of that says that any given SIP node (proxy, UA, etc) has to be case sensitive, or preserve the case of SIP message headers as they traverse the network. So, if we didn't specify a case in the algorithm, the two nodes could come up with two different hash values for the same set of headers. As always, thanks for your comments. Brian -----Original Message----- From: Parameswar, Sriram [NGB:B658:EXCH] Sent: Friday, August 31, 2001 11:22 AM To: 'Sean Olson (EUS)'; 'sip@ietf.org' Subject: [Sip] RE: [Sipping] SIP Negotiate Sean, Thanks for you comments. My reply in-line prefaced by [SP]. Best Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Sean Olson (EUS) [ mailto:sean.olson@ericsson.com ] Sent: Friday, August 31, 2001 10:06 AM To: Parameswar, Sriram [NGB:B658:EXCH]; 'sip@ietf.org'; 'sipping@ietf.org' Subject: RE: [Sipping] SIP Negotiate Hello, I have a few immediate comments. First, I agree that such a mechanism is needed. My comments really are directed at the details of your proposal. 1) Do we need to define a named extension "negotiate"? It seems the Allow: header and the 405 response give you everything you need in this regard. [SP] Allow typically handles SIP Methods, we were looking at session parameters - Code Book size, Compression Algorithms, QoS mechanisms etc. If we extended Allow to perform a Negotiation type role we would have backward compatability issues, also it would be session specific. We are looking for a mechanism that applies across sessions. 2) Would it be possible to use the OPTIONS method instead? I realize this is a bit of a twist on OPTIONS. [SP] we considered OPTIONS when we started this work and it is our opinion that it would break backwards compatability. Alternatively, a nested INVITE might work. [SP] If I understand ths correctly you would use the INVITE to perform negotiations. I see two problems with this approach (please correct me if I have mis-understood): ** this would add to delays in setting up sessions ** Again an INVITE would do this on a session-by-session basis it was our intentions that Negotiated parameters apply across sessions. 3) It seems that some of the information that you are negotiating should be applied on a per-session basis and should not necessarily be used across sessions (e.g keys). Do you anticipate sending a NEGOTIATE request before every INVITE? The Expires: header doesn't really give you the level of control that I'm talking about. [SP] Agreed certain parameters may need to be negotiated on a per session basis. You *could* use Negotiate for such situations too, in this case the Expires header does not have the same value. As an example we are looking at meta-session parameters that you could negotiate that would last across sessions like: compression to your Local Outbound Proxy. 4) For stateless proxy operation, it seems more appropriate to include/reiterate the meta session parameters in the INVITE. That is, I wouldn't expect a stateless proxy to use parameters in the NEGOTIATE for the "next" INVITE. Naturally, there are some parameters that will be completely meaningless to a stateless proxy. Compression may be one example. [SP] Agreed there are problems with Stateless proxies and we do note that in the document. 5) I would treat NEGOTIATE exactly like SUBSCRIBE with respect to forking proxies. [SP] Thanks we will include that in future updates of the document. 6) In your MD5 hash description, you convert the To/From URL to all uppercase. This is a bit pedantic, but wouldn't you want to preserve the case of at least the userinfo portion of those URLs for uniqueness? [SP] Its my initial reaction that we should have uniqueness even with the conversion to uppercase. But will definitely consider removing it if otherwise. Regards, Sean Olson Ericsson Inc. -----Original Message----- From: Sriram Parameswar [ mailto:sriramp@nortelnetworks.com ] Sent: Friday, August 31, 2001 9:35 AM To: 'sip@ietf.org'; 'sipping@ietf.org' Subject: [Sipping] SIP Negotiate Hi, We have just submitted a new I-D on negotiation of meta-session parameters for SIP sessions. Until the draft appears in the archives, you can pick up a copy at: http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt We invite your comments, the abstract is included below for your perusal. Thanks, Sriram Parameswar Brian Stucker ------_=_NextPart_001_01C1325E.FE6C9C90 Content-Type: text/html; charset="iso-8859-1" RE: [Sipping] SIP Negotiate
Take a look at section 2.1 of the bis draft dealing with SIP URL
comparison. The user portion of the SIP URL is case-sensitive.
This should be taken into account when determining the call
leg (based on To:/From: URLs). For example,
"sip:BOB@network.com" is not the same as "sip:bob@network.com"
 
It is a very minor nit. My recommendation would be to include the
user portion in its original case and everything else in lowercase.
This is not strictly correct either. I don't have a perfect solution
in mind. Just something to think about.
 
/sean
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Friday, August 31, 2001 11:54 AM
To: Sriram Parameswar; 'Sean Olson (EUS)'; 'sip@ietf.org'
Subject: RE: [Sip] RE: [Sipping] SIP Negotiate

Sean,
 
For your last question, about the MD5, the reason that we specified all uppercase prior to the MD5 hash was because there is no requirement that we're aware of that says that any given SIP node (proxy, UA, etc) has to be case sensitive, or preserve the case of SIP message headers as they traverse the network. So, if we didn't specify a case in the algorithm, the two nodes could come up with two different hash values for the same set of headers.
 
As always, thanks for your comments.
 
Brian
 
-----Original Message-----
From: Parameswar, Sriram [NGB:B658:EXCH]
Sent: Friday, August 31, 2001 11:22 AM
To: 'Sean Olson (EUS)'; 'sip@ietf.org'
Subject: [Sip] RE: [Sipping] SIP Negotiate

Sean,

Thanks for you comments. My reply in-line prefaced by [SP].

Best Regards,

Sriram
__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Friday, August 31, 2001 10:06 AM
To: Parameswar, Sriram [NGB:B658:EXCH]; 'sip@ietf.org'; 'sipping@ietf.org'
Subject: RE: [Sipping] SIP Negotiate


Hello,
I have a few immediate comments. First, I agree that such
a mechanism is needed. My comments really are
directed at the details of your proposal.
1) Do we need to define a named extension "negotiate"?
   It seems the Allow: header and the 405 response give
   you everything you need in this regard.

[SP] Allow typically handles SIP Methods, we were looking at session
     parameters - Code Book size, Compression Algorithms, QoS mechanisms etc.
     If we extended Allow to perform a Negotiation type role we would have
     backward compatability issues, also it would be session specific. We are looking
     for a mechanism that applies across sessions.

2) Would it be possible to use the OPTIONS method instead?
   I realize this is a bit of a twist on OPTIONS.

[SP] we considered OPTIONS when we started this work and
     it is our opinion that it would break backwards compatability.

   Alternatively, a nested INVITE might work.

[SP] If I understand ths correctly you would use the
     INVITE to perform negotiations. I see two problems with
     this approach (please correct me if I have mis-understood):
       ** this would add to delays in setting up sessions
       ** Again an INVITE would do this on a session-by-session basis
          it was our intentions that Negotiated parameters apply across
          sessions.

3) It seems that some of the information that you
   are negotiating should be applied on a per-session
   basis and should not necessarily be used across
   sessions (e.g keys). Do you anticipate sending a
   NEGOTIATE request before every INVITE? The Expires:
   header doesn't really give you the level of control
   that I'm talking about.

[SP] Agreed certain parameters may need to be negotiated on
     a per session basis. You *could* use Negotiate for such
     situations too, in this case the Expires header does
     not have the same value. As an example we are looking
     at meta-session parameters that you could negotiate that
     would last across sessions like: compression to your Local
     Outbound Proxy.

4) For stateless proxy operation, it seems more appropriate
   to include/reiterate the meta session parameters in the
   INVITE. That is, I wouldn't expect a stateless proxy
   to use parameters in the NEGOTIATE for the "next" INVITE.
   Naturally, there are some parameters that will be completely
   meaningless to a stateless proxy. Compression may be one
   example.
[SP] Agreed there are problems with Stateless proxies and we
     do note that in the document.

5) I would treat NEGOTIATE exactly like SUBSCRIBE with
   respect to forking proxies.
[SP] Thanks we will include that in future updates of the document.

6) In your MD5 hash description, you convert the To/From URL
   to all uppercase. This is a bit pedantic, but wouldn't
   you want to preserve the case of at least the userinfo
   portion of those URLs for uniqueness?
[SP] Its my initial reaction that we should have uniqueness even
     with the conversion to uppercase. But will definitely consider
     removing it if otherwise.

Regards,
Sean Olson
Ericsson Inc.


-----Original Message-----
From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: Friday, August 31, 2001 9:35 AM
To: 'sip@ietf.org'; 'sipping@ietf.org'
Subject: [Sipping] SIP Negotiate


Hi,
We have just submitted a new I-D on negotiation of meta-session parameters for SIP sessions. Until the draft appears in the archives, you can pick up a copy at:

http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt
We invite your comments, the abstract is included below for your perusal.
Thanks,
Sriram Parameswar
Brian Stucker

------_=_NextPart_001_01C1325E.FE6C9C90-- _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 17:51:04 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16817 for ; Fri, 31 Aug 2001 17:51:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25422; Fri, 31 Aug 2001 17:33:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25395 for ; Fri, 31 Aug 2001 17:33:28 -0400 (EDT) Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16499 for ; Fri, 31 Aug 2001 17:32:05 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f7VLW7ob016331 for ; Fri, 31 Aug 2001 17:32:07 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 Aug 2001 17:32:58 -0400 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E568@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@ietf.org'" Date: Fri, 31 Aug 2001 17:32:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] draft-sparks-sip-mimetypes-00 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org I've submitted a stab at a registration document for message/sip and message/sipfrag to the repository. Until it shows up, it is available at http://www.nostrum.com/~rjsparks/draft-sparks-sip-mimetypes-00.txt RjS _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 19:41:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17785 for ; Fri, 31 Aug 2001 19:41:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27526; Fri, 31 Aug 2001 19:30:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27497 for ; Fri, 31 Aug 2001 19:30:44 -0400 (EDT) Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17573 for ; Fri, 31 Aug 2001 19:29:23 -0400 (EDT) Received: from BobP [63.67.143.2] by acmepacket.com (SMTPD32-6.05) id AE21AF1001CC; Fri, 31 Aug 2001 19:30:41 -0400 Message-ID: <003801c13274$2fef6da0$2300000a@acmepacket.com> From: "Bob Penfield" To: "Sean Olson \(EUS\)" , "'Brian Stucker'" , "Sriram Parameswar" , References: Subject: Re: [Sip] RE: [Sipping] SIP Negotiate Date: Fri, 31 Aug 2001 19:25:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit I agree with Sean that you don't want to change the content of the headers, but it is probably wise to normalize the header labels. In 2543bis (section 18.2), one is required to use the full & correct forms of the header labels as input when cryptographically signing part of a SIP message. (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 bpenfield@acmepacket.com ----- Original Message ----- From: "Sean Olson (EUS)" To: "'Brian Stucker'" ; "Sriram Parameswar" ; Sent: Friday, August 31, 2001 4:53 PM Subject: RE: [Sip] RE: [Sipping] SIP Negotiate > Take a look at section 2.1 of the bis draft dealing with SIP URL > comparison. The user portion of the SIP URL is case-sensitive. > This should be taken into account when determining the call > leg (based on To:/From: URLs). For example, > "sip:BOB@network.com" is not the same as "sip:bob@network.com" > > It is a very minor nit. My recommendation would be to include the > user portion in its original case and everything else in lowercase. > This is not strictly correct either. I don't have a perfect solution > in mind. Just something to think about. > > /sean > > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortelnetworks.com] > Sent: Friday, August 31, 2001 11:54 AM > To: Sriram Parameswar; 'Sean Olson (EUS)'; 'sip@ietf.org' > Subject: RE: [Sip] RE: [Sipping] SIP Negotiate > > > Sean, > > For your last question, about the MD5, the reason that we specified all uppercase prior to the MD5 hash was because there is no requirement that we're aware of that says that any given SIP node (proxy, UA, etc) has to be case sensitive, or preserve the case of SIP message headers as they traverse the network. So, if we didn't specify a case in the algorithm, the two nodes could come up with two different hash values for the same set of headers. > > As always, thanks for your comments. > > Brian > > > -----Original Message----- > From: Parameswar, Sriram [NGB:B658:EXCH] > Sent: Friday, August 31, 2001 11:22 AM > To: 'Sean Olson (EUS)'; 'sip@ietf.org' > Subject: [Sip] RE: [Sipping] SIP Negotiate > > > > Sean, > > Thanks for you comments. My reply in-line prefaced by [SP]. > > Best Regards, > > Sriram > __________________________________________ > Sriram Parameswar Phone: 972-685-8540 > Interactive Multimedia Server (IMS) Fax: 972-685-3563 > Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com > -----Original Message----- > From: Sean Olson (EUS) [ mailto:sean.olson@ericsson.com ] > Sent: Friday, August 31, 2001 10:06 AM > To: Parameswar, Sriram [NGB:B658:EXCH]; 'sip@ietf.org'; 'sipping@ietf.org' > Subject: RE: [Sipping] SIP Negotiate > > > Hello, > I have a few immediate comments. First, I agree that such > a mechanism is needed. My comments really are > directed at the details of your proposal. > 1) Do we need to define a named extension "negotiate"? > It seems the Allow: header and the 405 response give > you everything you need in this regard. > > [SP] Allow typically handles SIP Methods, we were looking at session > parameters - Code Book size, Compression Algorithms, QoS mechanisms etc. > If we extended Allow to perform a Negotiation type role we would have > backward compatability issues, also it would be session specific. We are looking > for a mechanism that applies across sessions. > > 2) Would it be possible to use the OPTIONS method instead? > I realize this is a bit of a twist on OPTIONS. > > [SP] we considered OPTIONS when we started this work and > it is our opinion that it would break backwards compatability. > > Alternatively, a nested INVITE might work. > > [SP] If I understand ths correctly you would use the > INVITE to perform negotiations. I see two problems with > this approach (please correct me if I have mis-understood): > ** this would add to delays in setting up sessions > ** Again an INVITE would do this on a session-by-session basis > it was our intentions that Negotiated parameters apply across > sessions. > > 3) It seems that some of the information that you > are negotiating should be applied on a per-session > basis and should not necessarily be used across > sessions (e.g keys). Do you anticipate sending a > NEGOTIATE request before every INVITE? The Expires: > header doesn't really give you the level of control > that I'm talking about. > > [SP] Agreed certain parameters may need to be negotiated on > a per session basis. You *could* use Negotiate for such > situations too, in this case the Expires header does > not have the same value. As an example we are looking > at meta-session parameters that you could negotiate that > would last across sessions like: compression to your Local > Outbound Proxy. > > 4) For stateless proxy operation, it seems more appropriate > to include/reiterate the meta session parameters in the > INVITE. That is, I wouldn't expect a stateless proxy > to use parameters in the NEGOTIATE for the "next" INVITE. > Naturally, there are some parameters that will be completely > meaningless to a stateless proxy. Compression may be one > example. > [SP] Agreed there are problems with Stateless proxies and we > do note that in the document. > > 5) I would treat NEGOTIATE exactly like SUBSCRIBE with > respect to forking proxies. > [SP] Thanks we will include that in future updates of the document. > > 6) In your MD5 hash description, you convert the To/From URL > to all uppercase. This is a bit pedantic, but wouldn't > you want to preserve the case of at least the userinfo > portion of those URLs for uniqueness? > [SP] Its my initial reaction that we should have uniqueness even > with the conversion to uppercase. But will definitely consider > removing it if otherwise. > > Regards, > Sean Olson > Ericsson Inc. > > > -----Original Message----- > From: Sriram Parameswar [ mailto:sriramp@nortelnetworks.com ] > Sent: Friday, August 31, 2001 9:35 AM > To: 'sip@ietf.org'; 'sipping@ietf.org' > Subject: [Sipping] SIP Negotiate > > > Hi, > We have just submitted a new I-D on negotiation of meta-session parameters for SIP sessions. Until the draft appears in the archives, you can pick up a copy at: > > http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt > We invite your comments, the abstract is included below for your perusal. > Thanks, > Sriram Parameswar > Brian Stucker > > _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-admin@ietf.org Fri Aug 31 23:13:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22654 for ; Fri, 31 Aug 2001 23:13:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA02001; Fri, 31 Aug 2001 22:55:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA01970 for ; Fri, 31 Aug 2001 22:55:02 -0400 (EDT) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22172 for ; Fri, 31 Aug 2001 22:53:38 -0400 (EDT) Received: from blazer (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id f812u2D11263 for ; Fri, 31 Aug 2001 21:56:02 -0500 Message-ID: <00ca01c13291$24be1bd0$55fa403f@blazer> From: "Dean Willis" To: Date: Fri, 31 Aug 2001 21:52:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [Sip] SIP To: or Not SIP To:, Route is the Question? Was ( To and Request URI) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol X-BeenThere: sip@ietf.org Content-Transfer-Encoding: 7bit Please excuse me for recycling part of a note from another conversation and for abusing Hamlet's line. Orry, it's been one of those weeks . . . The To: field can be envisioned as an indicator TO THE USER (or agents thereof) of the "intent" or "original target" of a call. For example: Let's say my boss goes out of town and forward his phone calls to me. Somewhere, there's a proxy replacing the RequestURI of his phone with one that delivers INVITEs to my phone instead. But when the call shows up at my phone, the To: field is still "boss" (Ok, sip:boss@neuroses.org) . So when I look at my GUI before answering a call, I know that the call was originally to my boss, and has just been delivered to me because of some sort of call forwarding. I may choose to give this call higher (or lower) priority than I might otherwise, or do some sort of different handling as I think appropriate, like not answer "WHASSSUP!!!" at the top of my voice. Or, software in my phone (or proxy) could do something with this information. For example, I might have a script in my phone that says "If a call is To: my boss, play distinctive ring #4, even when I'm in no-ring mode." This isn't really "routing" of the call -- it's more "application processing using supplemental information". -- Dean _______________________________________________ Sip mailing list http://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip