From sip-admin@lists.bell-labs.com Thu Feb 1 01:08:56 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07669 for ; Thu, 1 Feb 2001 01:08:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8141C4434A; Thu, 1 Feb 2001 00:09:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from f1ee40-20.idc1.level3.com (machine77.Level3.com [209.244.4.106]) by lists.bell-labs.com (Postfix) with ESMTP id 6658A4433A for ; Thu, 1 Feb 2001 00:08:18 -0500 (EST) Received: from n0195idc1.oss.level3.com (localhost.l3.com [127.0.0.1] (may be forged)) by f1ee40-20.idc1.level3.com (8.9.3/8.9.3) with ESMTP id GAA11954; Thu, 1 Feb 2001 06:07:57 GMT From: Jon.Peterson@Level3.com Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id <1C2JKLJD>; Wed, 31 Jan 2001 23:10:05 -0700 Message-ID: <6384220893BCD411BDFE0008C791B79C232D5D@N0228IDC1.oss.level3.com> To: chsharp@cisco.com, sip@lists.bell-labs.com Subject: RE: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 31 Jan 2001 23:06:21 -0700 I think it was the hope of the authors that all of the meaningful values for 'base' would be characterized in the document. Since 'base' reflects the lowest common dominator (or, to coin a phrase, least specific ancestor) variant of the ISUP version in question, the authors hoped that given the backwards compatibility mechanism in ITU-T 1992 Q.76x, itu92 would be the proper base for forthcoming ISUP versions (new versions of ANSI following the 2000 issue support this mechanism, even). That much said, if there are potential 'base' values which are of use to the community that cannot be said to derive from itu92, the authors would certainly like to be made aware of them. Is there anything out there that the ISUP MIME draft misses? In the face of serious concerns that useful new 'bases' might come to light subsequent to the publication of an RFC, I suppose management of 'base' by IANA could be introduced, but personally I'd rather not trouble IANA with this additional responsibility if there isn't a substantial risk. Was there anything specific you had in mind? Jon Peterson Level(3) Communications -----Original Message----- From: Chip Sharp [mailto:chsharp@cisco.com] Sent: Tuesday, January 30, 2001 10:50 AM To: sip@lists.bell-labs.com Subject: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt Currently, the IANA considerations section of draft-ietf-sip-isup-mime-07.txt describes how to define new "version" fields, but does not describe how to define new "base" fields. Given that new base protocols may be identified, shouldn't there be a description on how IANA assigns new "base" values? Chip ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems ------------------------------------------------------------------- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 01:45:57 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12021 for ; Thu, 1 Feb 2001 01:45:57 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BFC7B44363; Thu, 1 Feb 2001 00:46:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207]) by lists.bell-labs.com (Postfix) with ESMTP id 0C9264435C for ; Thu, 1 Feb 2001 00:45:27 -0500 (EST) Received: (from siplist@localhost) by fdd.com (8.10.1/8.10.1) id f116jE523038; Thu, 1 Feb 2001 00:45:14 -0600 (CST) From: Rick Dean To: Rohan Mahy Cc: Ben Campbell , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt Message-ID: <20010201004513.A25002@fdd.com> References: <9BF66EBF6BEFD942915B4D4D45C051F309B1@DYN-TX-EXCH-001.dynam <4.1.20010131080406.00b509c0@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010131080406.00b509c0@imop.cisco.com>; from rohan@cisco.com on Wed, Jan 31, 2001 at 08:32:43AM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 00:45:13 -0600 On Wed, Jan 31, 2001 at 08:32:43AM -0800, Rohan Mahy wrote: > Rick Dean wrote: > >> > > We confess, our goal is to build a transfer which works exactly > >> > > like the existing phone system, but happens to use SIP. When > >> > > we complete this task, feel free to build a phone system > >> > > which works differently. We hope you find some customers. > > A couple years ago we went through the feature books of the leading PBX > brands, and asked the question "What was the customer need behind this > feature?". For all the user-initiated features, we came up with some > pretty hideous interfaces to invoke these features (that we do not want to > reproduce), but concluded that customers still need/want to setup many of > the same call-leg relationships. Agreed. For many advanced PBX features the switchhook+DTMF interface sucks. In this case the legacy PSTN paradigm is not DTMF. Digital PBX phones use additional keys and a display. -- Rick > > We absolutely want beter ways (UIs) to invoke features (and I have found > customers); we want general primitives instead of a monolithic blob of > "features"; but the customer experience of what happens when someone > invokes the "transfer" thing should be familiar. > > Rick is right about one critical element--prompting. A basic philosophy of > a call is that you get to change your end of the call as much as you like. > The other parties can stay in the call, disconnect, or change their end as > well. Real-time prompting is not/should not be a part of equation. Note > that this doesn't have anything to do with the method name. A prompt for a > REFER is just as scary as a prompt for a HANDOFF. Rick and Billy didn't > like my REFER Music on Hold flow because it took back a call. According to > the current philosophy this should be fine in certain > circumstances--without prompting. If you don't agree that prompting is an > impediment, try turning on manual cookie prompting for about an hour of web > surfing. > > We should ask the question, "Why am I asking the user for permission?" If > wecan come up with default rules of fair play for UA, the user should only > be prompted in extraordinary circumstances, or not at all. > > thanks, > -rohan > > >> > > Yes, proxies should be able to administratively block > >> > > HANDOFF requests like any other. Good point. Do we need another > >> > > sentence to cover this? Are you proposing a special header or > >> > > response code to indicate the proxy and not the end UA blocked it? > >> > > Does it make a difference to the HANDOFF sending UA? > >> > > > >> > > We already have another method which is "prompt the remote human". > >> > > REFER to a web page does this best. An audible > >> > > question does not need a SIP extension. > >> > > > >> > > Wouldn't the REFER request to a web page need two promptings? > >> > > The first one is do you want to follow the URL and the > >> second is the > >> > > question on the web page. I can do more damage > >> > > with a HTTP GET than a SIP INVITE, but most browsers follow > >> > > 302 redirects automatically anyway. > >> > > > >> > > BTW, I am scared of what > >> > > a REFER with method=REFER prompt would look like to an end > >> > > user. Clearly, the designers don't intend this. > >> > > > >> > > Yes, sophisticated UA's with 19" monitors in expert mode will > >> > > defy the > >> > > draft and prompt the user. It is their choice, and the IETF > >> > > tries hard > >> > > not to mandate this behavior outside the protocol. Hopefully the > >> > > UA will prompt after the HANDOFF final response, but before the > >> > > handoff-status, for timing reasons as you stated. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 04:07:04 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22242 for ; Thu, 1 Feb 2001 04:06:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B7334434A; Thu, 1 Feb 2001 03:07:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by lists.bell-labs.com (Postfix) with ESMTP id E53884433A for ; Thu, 1 Feb 2001 03:06:00 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 1 Feb 2001 09:05:42 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id JAA11747; Thu, 1 Feb 2001 09:05:43 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569E6.0031E96C ; Thu, 1 Feb 2001 09:05:10 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: "Tom-PT Taylor" Cc: sip@lists.bell-labs.com, "Joshua Moloney" Message-ID: <802569E6.0031E2DB.00@marconicomms.com> Subject: RE: [SIP] Overlap call setup Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=vR3EsyeFVTfvZMOXn6HFQNMJ6C1XP6RiymoTE0WBcmK8IQM2jEFAgXfc" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 09:04:46 +0000 --0__=vR3EsyeFVTfvZMOXn6HFQNMJ6C1XP6RiymoTE0WBcmK8IQM2jEFAgXfc Content-type: text/plain; charset=us-ascii Content-Disposition: inline If the SIP side of the gateway is retaining state then the UAS side has to know that the subsequent digits have to be sent to the same call state machine (on the ISUP side) as the original digits. If you choose a different UAS, and the INVITE containing susequent digits is treated as a new call attempt by this UAS, how does it know which state machine on the ISUP side to send the digits to. I'm thinking of a configuration where there exists a farm of UAS for scalability and load distribution. Originally, I did say that sending 484 and completely forgetting about the call would work, I just don't think it is the best way; the original state machine on the ISUP side would probably time out if it received no further digits and a new state machine created by the subsequent INVITE would now handle the call. In the case of 11.3 in the sip-isup document, then the subsequent INVITEs must arrive at the same gateway, otherwise unnecessary IAMs are generated. This is pointed out in the text. Regards, K. Robinson "Tom-PT Taylor" on 31/01/2001 18:31:11 To: Keith Robinson/MAIN/MC1@MCMAIN cc: sip@lists.bell-labs.com, "Joshua Moloney" Subject: RE: [SIP] Overlap call setup I think you've made one assumption I might question. Assuming that subsequent INVITEs are being sent, containing all of the digits so far collected, so that they are self-contained: why is it necessary that each ends up at the same UAS? When the 484 is sent back, call state should be cleared all along the path, even in the SIP-UAC side of the ingress gateway. Only the ISUP side of that gateway and, I suppose, the ISUP-SIP interworking function, should retain call state. > -----Original Message----- > From: Keith Robinson [mailto:Keith.Robinson@marconi.com] > Sent: Wednesday, January 31, 2001 11:34 AM > To: Moloney, Joshua [MDN05:CT07:EXCH] > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Overlap call setup > > > > > I have recently been trying to get clarification on the > implemenation of > overlap sending; see attached for the discussion that has taken place > so far. > > Certainly, the mechanism outlined (very sketchily) in > RFC2543bis-02 sect 4.2.1 > is fundamentally flawed. The Request-URI cannot be used to > carry extra digits > as the Record-Route/Route mechanism would end up overwriting the R-URI > and therefore the subsequent digits would be lost. > > This then leads to the idea of using the TO field as described in > sip-isup-00-00.txt; > however, I have the following issues with the mechanisms > described in this > document : > > As the TO field is different on each subsequent INVITE, then > it is a new call > leg > on an existing call id; RFC2543bis-02 sect. 11.5 does not > state what a UAS > should make of this. If you follow the logic in 11.5 you get > to case (3), but > here it only defines the behaviour if the TO and FROM fields match. > > The 484 sent backwards kills that call attempt (but not the > state for that > Call-Id - > is this problematic for intermediate proxies ?) so subsequent > INVITEs will > actually be initial INVITEs. As these INVITEs must get to the > same terminating > UAS, > the originating UAC will have to create a ROUTE header in an > initial INVITE > using , > at least the CONTACT address from the 484. This implies the > use of source > routing, an > issue that I don't believe has been fully resolved, and even > if it is and > becomes part > of the base protocol some administrations may be reluctant to > admit initial > INVITEs > which try to circumvent their routing policy, so may reject > such INVITEs. > > Also on the above point, the CONTACT address in the 484 must > have the same > semantics as that in a 200 response so that a ROUTE header > can be built; however > RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in > 4XX responses > indicates a location where additional error information can > be found. Indeed, in > a recent > thread entitled Announcements in SIP (401 & 407 Contact) J. > Rosenberg believes > that > Record-Route does not make sense in any non-200 response. > > I would raise the question of whether the 484 response has > any use in overlap > sending > (certainly in the case of ISUP) at all. If a node receives > insufficient digits > to decode than it will wait until it receives some more from > the preceding node > (or end of > dialling timers mature). If the preceding node receives > subsequent digits and > end of dialling > has not been detected then it will pass them on. If the 484 > indicated the > minimum number of > digits before a decode could take place, then it would be > useful in cutting down > the number > of subseqent messages sent. > > Indeed, isup-sip-00.txt does cover the mechanism where a 183 > is sent, and not a > 484. > The case in point is covered in sect. 11.3 (Example of SIP > bridging and overlap > signalling); > However, I have the following issues with this mechanism: > > As before relies on source routing. > > Relies on proxies sending requests on new call legs but > existing call-ids to the > same > downstream server; fine if you administer these proxies, what > if you don't ? > (Lots of > wasted IAMs generated). The mechanism should not send 5 > (subsequent INVITE) > until it has received an acknowledgement (probably not 100) > from the first. > Alternatively, > the Reason-Phrase could detail more specifically the exact > progress of the call > ("Decoding Address" > in this case ?) so that the ACM is not generated unconditionally. > > Sect. 11.2 encourages gateways "to return a183 Session > Progress with a Contact > header as soon as they receive an INVITE that they are going > to handle and might > contain > an incomplete number". Presumably this is to allow the UAC to > build a ROUTE so > that subsequent > INVITEs get to the appropriate UAS. Sect 7.2.3 indicates that > a node receiving a > 183 prior to generating > an ACM should generate an ACM. Applied together these rules > may cause a prior > node to never > send on any subsequent digits and overlap sending would fail. > > I think an approach is required whereby subsequent digits are > sent on the same > call leg as the > initial INVITE; either multiple INVITEs are allowed before > 200 OK (already > suggested by J. Rosenberg > in a different context) , or the INFO method is used. In both > cases the TO field > will have to remain the > same so a new header (or message body type) is required to > convey the digits. > Also, replace the 484 > with, say, 18X indicating the minimum number of digits > required, perhaps in the > Reason-Phrase header. > > Regards, > > Keith Robinson. > > > > > > > > > > > > > > > > > > > > > > > "Joshua Moloney" on 31/01/2001 10:49:33 > > > > > > > > > > > > To: sip@lists.bell-labs.com > > cc: (bcc: Keith Robinson/MAIN/MC1) > > > > Subject: [SIP] Overlap call setup > > > > > > > > > Greetings, > > I would like to ask for clarification regarding the implementation of > Overlap. > > I'll begin by referring to paragraph 3, section 6.1.2 of > "draft-ietf-isup-sip-00": > > It is stated that INVITEs sent after the first one > (containing extra digits > in the 'To' field) are to be treated as new Call-Legs, seeing as the > contents of their 'To' headers differ. As such, there is no > relationship > between their CSeq values. > > If this is the case, how is it possible to ensure correct > digit ordering > over an 'unreliable' transport layer like UDP? It would seem > logical that > the call originator _would_ use contiguous CSeq values, as it would be > 'aware' of the fact that the INVITEs are for the same call. > > I believe that this issue was raised on the SIP list on 19 > November 1999 by > Gonzalo C and Jonathan R. The subject of the messages was > "Re: Comments on > draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of > the exchange > appeared to be an agreement that CSeq ordering should be employed. > > However, does this in any way imply that under such circumstances the > INVITEs would/should belong to the same Call-Leg? After all, > the concept of > Overlap does not seem to 'fit in' with the concept behind > multiple Call-Legs > anyway. > > If there has been a change in thinking behind the problem, > and the latest > draft is correct, please could you explain how the ordering > problem will be > overcome. If not, perhaps the draft needs modification to > include these > considerations... > > > Regards, > > Josh Moloney > > --0__=vR3EsyeFVTfvZMOXn6HFQNMJ6C1XP6RiymoTE0WBcmK8IQM2jEFAgXfc Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1Mi4zNSI+DQo8VElUTEU+UkU6IFtT SVBdIE92ZXJsYXAgY2FsbCBzZXR1cDwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZP TlQgU0laRT0yPkkgdGhpbmsgeW91J3ZlIG1hZGUgb25lIGFzc3VtcHRpb24gSSBtaWdodCBxdWVz dGlvbi4mbmJzcDsgQXNzdW1pbmcgdGhhdCBzdWJzZXF1ZW50IElOVklURXMgYXJlIGJlaW5nIHNl bnQsIGNvbnRhaW5pbmcgYWxsIG9mIHRoZSBkaWdpdHMgc28gZmFyIGNvbGxlY3RlZCwgc28gdGhh dCB0aGV5IGFyZSBzZWxmLWNvbnRhaW5lZDogd2h5IGlzIGl0IG5lY2Vzc2FyeSB0aGF0IGVhY2gg ZW5kcyB1cCBhdCB0aGUgc2FtZSBVQVM/Jm5ic3A7IFdoZW4gdGhlIDQ4NCBpcyBzZW50IGJhY2ss IGNhbGwgc3RhdGUgc2hvdWxkIGJlIGNsZWFyZWQgYWxsIGFsb25nIHRoZSBwYXRoLCBldmVuIGlu IHRoZSBTSVAtVUFDIHNpZGUgb2YgdGhlIGluZ3Jlc3MgZ2F0ZXdheS4mbmJzcDsgT25seSB0aGUg SVNVUCBzaWRlIG9mIHRoYXQgZ2F0ZXdheSBhbmQsIEkgc3VwcG9zZSwgdGhlIElTVVAtU0lQIGlu dGVyd29ya2luZyBmdW5jdGlvbiwgc2hvdWxkIHJldGFpbiBjYWxsIHN0YXRlLjwvRk9OVD48L1A+ DQoNCjxQPjxGT05UIFNJWkU9Mj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEZyb206IEtlaXRoIFJvYmluc29uIFs8QSBIUkVGPSJt YWlsdG86S2VpdGguUm9iaW5zb25AbWFyY29uaS5jb20iPm1haWx0bzpLZWl0aC5Sb2JpbnNvbkBt YXJjb25pLmNvbTwvQT5dPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFNlbnQ6IFdlZG5l c2RheSwgSmFudWFyeSAzMSwgMjAwMSAxMTozNCBBTTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyBUbzogTW9sb25leSwgSm9zaHVhIFtNRE4wNTpDVDA3OkVYQ0hdPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj4mZ3Q7IENjOiBzaXBAbGlzdHMuYmVsbC1sYWJzLmNvbTwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyBTdWJqZWN0OiBSZTogW1NJUF0gT3ZlcmxhcCBjYWxsIHNldHVwPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0 OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBJIGhhdmUgcmVjZW50bHkgYmVl biB0cnlpbmcgdG8gZ2V0IGNsYXJpZmljYXRpb24gb24gdGhlIDwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyBpbXBsZW1lbmF0aW9uIG9mPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 IG92ZXJsYXAgc2VuZGluZzsgc2VlIGF0dGFjaGVkIGZvciB0aGUgZGlzY3Vzc2lvbiB0aGF0IGhh cyB0YWtlbiBwbGFjZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBzbyBmYXIuPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBD ZXJ0YWlubHksIHRoZSBtZWNoYW5pc20gb3V0bGluZWQgKHZlcnkgc2tldGNoaWx5KSBpbiA8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgUkZDMjU0M2Jpcy0wMiBzZWN0IDQuMi4xPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGlzIGZ1bmRhbWVudGFsbHkgZmxhd2VkLiBUaGUgUmVx dWVzdC1VUkkgY2Fubm90IGJlIHVzZWQgdG8gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 IGNhcnJ5IGV4dHJhIGRpZ2l0czwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBhcyB0aGUg UmVjb3JkLVJvdXRlL1JvdXRlIG1lY2hhbmlzbSB3b3VsZCBlbmQgdXAgb3ZlcndyaXRpbmcgdGhl IFItVVJJPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGFuZCB0aGVyZWZvcmUgdGhlIHN1 YnNlcXVlbnQgZGlnaXRzIHdvdWxkIGJlIGxvc3QuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m Z3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBUaGlzIHRoZW4gbGVhZHMgdG8gdGhl IGlkZWEgb2YgdXNpbmcgdGhlIFRPIGZpZWxkIGFzIGRlc2NyaWJlZCBpbjwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyBzaXAtaXN1cC0wMC0wMC50eHQ7PC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IGhvd2V2ZXIsIEkgaGF2ZSB0aGUgZm9sbG93aW5nIGlzc3VlcyB3aXRoIHRoZSBt ZWNoYW5pc21zIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBkZXNjcmliZWQgaW4gdGhp czwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBkb2N1bWVudCA6PC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBBcyB0aGUgVE8g ZmllbGQgaXMgZGlmZmVyZW50IG9uIGVhY2ggc3Vic2VxdWVudCBJTlZJVEUsIHRoZW4gPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGl0IGlzIGEgbmV3IGNhbGw8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgbGVnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IG9uIGFuIGV4 aXN0aW5nIGNhbGwgaWQ7IFJGQzI1NDNiaXMtMDIgc2VjdC4gMTEuNSBkb2VzIG5vdCA8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgc3RhdGUgd2hhdCBhIFVBUzwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyBzaG91bGQgbWFrZSBvZiB0aGlzLiBJZiB5b3UgZm9sbG93IHRoZSBsb2dp YyBpbiAxMS41IHlvdSBnZXQgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRvIGNhc2Ug KDMpLCBidXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgaGVyZSBpdCBvbmx5IGRlZmlu ZXMgdGhlIGJlaGF2aW91ciZuYnNwOyBpZiB0aGUgVE8gYW5kIEZST00gZmllbGRzIG1hdGNoLjwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsgVGhlIDQ4NCBzZW50IGJhY2t3YXJkcyBraWxscyB0aGF0IGNhbGwgYXR0ZW1wdCAoYnV0IG5v dCB0aGUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHN0YXRlIGZvciB0aGF0PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IENhbGwtSWQgLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jmd0OyBpcyB0aGlzIHByb2JsZW1hdGljIGZvciBpbnRlcm1lZGlhdGUgcHJveGllcyA/KSBz byBzdWJzZXF1ZW50IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBJTlZJVEVzIHdpbGw8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYWN0dWFsbHkgYmUgaW5pdGlhbCBJTlZJVEVz LiBBcyB0aGVzZSBJTlZJVEVzIG11c3QgZ2V0IHRvIHRoZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsgc2FtZSB0ZXJtaW5hdGluZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBV QVMsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRoZSBvcmlnaW5hdGluZyZuYnNwOyBV QUMgd2lsbCBoYXZlIHRvIGNyZWF0ZSBhIFJPVVRFIGhlYWRlciBpbiBhbiA8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZndDsgaW5pdGlhbCBJTlZJVEU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgdXNpbmcgLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBhdCBsZWFzdCB0aGUg Q09OVEFDVCBhZGRyZXNzIGZyb20gdGhlIDQ4NC4gVGhpcyBpbXBsaWVzIHRoZSA8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsgdXNlIG9mIHNvdXJjZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jmd0OyByb3V0aW5nLCBhbjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBpc3N1ZSB0 aGF0IEkgZG9uJ3QgYmVsaWV2ZSBoYXMgYmVlbiBmdWxseSByZXNvbHZlZCwgYW5kIGV2ZW4gPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGlmIGl0IGlzIGFuZDwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyBiZWNvbWVzIHBhcnQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg b2YgdGhlIGJhc2UgcHJvdG9jb2wgc29tZSBhZG1pbmlzdHJhdGlvbnMgbWF5IGJlIHJlbHVjdGFu dCB0byA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYWRtaXQgaW5pdGlhbDwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBJTlZJVEVzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m Z3Q7IHdoaWNoIHRyeSB0byBjaXJjdW12ZW50IHRoZWlyIHJvdXRpbmcgcG9saWN5LCBzbyBtYXkg cmVqZWN0IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBzdWNoIElOVklURXMuPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBB bHNvIG9uIHRoZSBhYm92ZSBwb2ludCwgdGhlIENPTlRBQ1QgYWRkcmVzcyBpbiB0aGUgNDg0IG11 c3QgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGhhdmUgdGhlIHNhbWU8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsgc2VtYW50aWNzIGFzIHRoYXQgaW4gYSAyMDAgcmVzcG9uc2Ug c28gdGhhdCBhIFJPVVRFIGhlYWRlciA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgY2Fu IGJlIGJ1aWx0OyBob3dldmVyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFJGQzI1NDNi aXMtMDIgc2VjdC4gNi4xNCBzcGVjaWZpZXMgdGhhdCBhIENPTlRBQ1QgYWRkcmVzcyBpbiA8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgNFhYIHJlc3BvbnNlczwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyBpbmRpY2F0ZXMgYSBsb2NhdGlvbiB3aGVyZSBhZGRpdGlvbmFsIGVycm9y IGluZm9ybWF0aW9uIGNhbiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYmUgZm91bmQu IEluZGVlZCwgaW48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYSByZWNlbnQ8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgdGhyZWFkIGVudGl0bGVkIEFubm91bmNlbWVudHMgaW4g U0lQICg0MDEgJmFtcDsgNDA3IENvbnRhY3QpIEouIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyBSb3NlbmJlcmcgYmVsaWV2ZXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgdGhh dDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBSZWNvcmQtUm91dGUgZG9lcyBub3QgbWFr ZSBzZW5zZSBpbiBhbnkgbm9uLTIwMCByZXNwb25zZS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEkgd291bGQgcmFpc2UgdGhlIHF1 ZXN0aW9uIG9mIHdoZXRoZXIgdGhlIDQ4NCByZXNwb25zZSBoYXMgPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IGFueSB1c2UgaW4gb3ZlcmxhcDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyBzZW5kaW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IChjZXJ0YWlubHkgaW4g dGhlIGNhc2Ugb2YgSVNVUCkgYXQgYWxsLiBJZiBhIG5vZGUgcmVjZWl2ZXMgPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7IGluc3VmZmljaWVudCBkaWdpdHM8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDsgdG8gZGVjb2RlIHRoYW4gaXQgd2lsbCB3YWl0IHVudGlsIGl0IHJlY2VpdmVz IHNvbWUgbW9yZSBmcm9tIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0aGUgcHJlY2Vk aW5nIG5vZGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgKG9yIGVuZCBvZjwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBkaWFsbGluZyB0aW1lcnMgbWF0dXJlKS4gSWYgdGhlIHBy ZWNlZGluZyBub2RlIHJlY2VpdmVzIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBzdWJz ZXF1ZW50IGRpZ2l0cyBhbmQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZW5kIG9mIGRp YWxsaW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGhhcyBub3QgYmVlbiBkZXRlY3Rl ZCB0aGVuIGl0IHdpbGwgcGFzcyB0aGVtIG9uLiBJZiB0aGUgNDg0IDwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyBpbmRpY2F0ZWQgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 IG1pbmltdW0gbnVtYmVyIG9mPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRpZ2l0cyBi ZWZvcmUgYSBkZWNvZGUgY291bGQgdGFrZSBwbGFjZSwgdGhlbiBpdCB3b3VsZCBiZSA8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgdXNlZnVsIGluIGN1dHRpbmcgZG93bjwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyB0aGUgbnVtYmVyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m Z3Q7IG9mIHN1YnNlcWVudCBtZXNzYWdlcyBzZW50LjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgSW5kZWVkLCBpc3VwLXNpcC0wMC50 eHQgZG9lcyBjb3ZlciB0aGUgbWVjaGFuaXNtIHdoZXJlIGEgMTgzIDwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyBpcyBzZW50LCBhbmQgbm90IGE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgNDg0LjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBUaGUgY2FzZSBpbiBwb2lu dCBpcyBjb3ZlcmVkIGluIHNlY3QuIDExLjMgKEV4YW1wbGUgb2YgU0lQIDwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyBicmlkZ2luZyBhbmQgb3ZlcmxhcDwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyBzaWduYWxsaW5nKTs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgSG93 ZXZlciwgSSBoYXZlIHRoZSBmb2xsb3dpbmcgaXNzdWVzIHdpdGggdGhpcyBtZWNoYW5pc206PC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0 OyBBcyBiZWZvcmUgcmVsaWVzIG9uIHNvdXJjZSByb3V0aW5nLjwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgUmVsaWVzIG9uIHByb3hp ZXMgc2VuZGluZyByZXF1ZXN0cyBvbiBuZXcgY2FsbCBsZWdzIGJ1dCA8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgZXhpc3RpbmcgY2FsbC1pZHMgdG8gdGhlPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IHNhbWU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZG93bnN0cmVh bSBzZXJ2ZXI7IGZpbmUgaWYgeW91IGFkbWluaXN0ZXIgdGhlc2UgcHJveGllcywgd2hhdCA8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgaWYgeW91IGRvbid0ID88L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgKExvdHMgb2Y8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgd2Fz dGVkIElBTXMgZ2VuZXJhdGVkKS4gVGhlIG1lY2hhbmlzbSBzaG91bGQgbm90IHNlbmQgNSA8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgKHN1YnNlcXVlbnQgSU5WSVRFKTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyB1bnRpbCBpdCBoYXMgcmVjZWl2ZWQgYW4gYWNrbm93bGVkZ2Vt ZW50IChwcm9iYWJseSBub3QgMTAwKSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZnJv bSB0aGUgZmlyc3QuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEFsdGVybmF0aXZlbHks PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRoZSBSZWFzb24tUGhyYXNlIGNvdWxkIGRl dGFpbCBtb3JlIHNwZWNpZmljYWxseSB0aGUgZXhhY3QgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mZ3Q7IHByb2dyZXNzIG9mIHRoZSBjYWxsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 ICgmcXVvdDtEZWNvZGluZyBBZGRyZXNzJnF1b3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m Z3Q7IGluIHRoaXMgY2FzZSA/KSBzbyB0aGF0IHRoZSBBQ00gaXMgbm90IGdlbmVyYXRlZCB1bmNv bmRpdGlvbmFsbHkuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyBTZWN0LiAxMS4yIGVuY291cmFnZXMgZ2F0ZXdheXMgJnF1b3Q7dG8g cmV0dXJuIGExODMgU2Vzc2lvbiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgUHJvZ3Jl c3Mgd2l0aCBhIENvbnRhY3Q8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgaGVhZGVyIGFz IHNvb24gYXMgdGhleSByZWNlaXZlIGFuIElOVklURSB0aGF0IHRoZXkgYXJlIGdvaW5nIDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0byBoYW5kbGUgYW5kIG1pZ2h0PC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7IGNvbnRhaW48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg YW4gaW5jb21wbGV0ZSBudW1iZXImcXVvdDsuIFByZXN1bWFibHkgdGhpcyBpcyB0byBhbGxvdyB0 aGUgVUFDIHRvIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBidWlsZCBhIFJPVVRFIHNv PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRoYXQgc3Vic2VxdWVudDwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyBJTlZJVEVzIGdldCB0byB0aGUgYXBwcm9wcmlhdGUgVUFTLiBT ZWN0IDcuMi4zIGluZGljYXRlcyB0aGF0IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBh IG5vZGUgcmVjZWl2aW5nIGE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgMTgzIHByaW9y IHRvIGdlbmVyYXRpbmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYW4gQUNNIHNob3Vs ZCBnZW5lcmF0ZSBhbiBBQ00uIEFwcGxpZWQgdG9nZXRoZXIgdGhlc2UgcnVsZXMmbmJzcDsgPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IG1heSBjYXVzZSBhIHByaW9yPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7IG5vZGUgdG8gbmV2ZXI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgc2VuZCBvbiBhbnkgc3Vic2VxdWVudCBkaWdpdHMgYW5kIG92ZXJsYXAgc2VuZGluZyB3 b3VsZCBmYWlsLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgSSB0aGluayBhbiBhcHByb2FjaCBpcyByZXF1aXJlZCB3aGVyZWJ5IHN1 YnNlcXVlbnQgZGlnaXRzIGFyZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgc2VudCBv biB0aGUgc2FtZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBjYWxsIGxlZyBhcyB0aGU8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgaW5pdGlhbCBJTlZJVEU7IGVpdGhlciBtdWx0 aXBsZSBJTlZJVEVzIGFyZSBhbGxvd2VkIGJlZm9yZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgMjAwIE9LIChhbHJlYWR5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHN1Z2dl c3RlZCBieSBKLiBSb3NlbmJlcmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgaW4gYSBk aWZmZXJlbnQgY29udGV4dCkgLCBvciB0aGUgSU5GTyBtZXRob2QgaXMgdXNlZC4gSW4gYm90aCA8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgY2FzZXMgdGhlIFRPIGZpZWxkPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHdpbGwgaGF2ZSB0byByZW1haW4gdGhlPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7IHNhbWUgc28gYSBuZXcgaGVhZGVyIChvciBtZXNzYWdlIGJvZHkg dHlwZSkgaXMgcmVxdWlyZWQgdG8gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGNvbnZl eSB0aGUgZGlnaXRzLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBBbHNvLCByZXBsYWNl IHRoZSA0ODQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgd2l0aCwgc2F5LCAxOFggaW5k aWNhdGluZyB0aGUgbWluaW11bSBudW1iZXIgb2YgZGlnaXRzIDwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyByZXF1aXJlZCwgcGVyaGFwcyBpbiB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsgUmVhc29uLVBocmFzZSBoZWFkZXIuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m Z3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBSZWdhcmRzLDwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgS2VpdGggUm9i aW5zb24uPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m Z3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmcXVvdDtKb3NodWEgTW9sb25leSZx dW90OyAmbHQ7am1vbG9uZXlAbm9ydGVsbmV0d29ya3MuY29tJmd0OyBvbiAzMS8wMS8yMDAxIDEw OjQ5OjMzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsgVG86Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHNpcEBsaXN0cy5iZWxsLWxhYnMuY29tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsmbmJzcDsgY2M6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChiY2M6IEtl aXRoIFJvYmluc29uL01BSU4vTUMxKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsgU3ViamVjdDogW1NJUF0gT3ZlcmxhcCBjYWxsIHNl dHVwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m Z3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7IEdyZWV0aW5ncyw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEkgd291bGQgbGlrZSB0byBhc2sgZm9y IGNsYXJpZmljYXRpb24gcmVnYXJkaW5nIHRoZSBpbXBsZW1lbnRhdGlvbiBvZjwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyBPdmVybGFwLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0 OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgSSdsbCBiZWdpbiBieSByZWZlcnJpbmcg dG8gcGFyYWdyYXBoIDMsIHNlY3Rpb24gNi4xLjIgb2Y8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgJnF1b3Q7ZHJhZnQtaWV0Zi1pc3VwLXNpcC0wMCZxdW90Ozo8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEl0IGlzIHN0YXRl ZCB0aGF0IElOVklURXMgc2VudCBhZnRlciB0aGUgZmlyc3Qgb25lIDwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyAoY29udGFpbmluZyBleHRyYSBkaWdpdHM8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDsgaW4gdGhlICdUbycgZmllbGQpIGFyZSB0byBiZSB0cmVhdGVkIGFzIG5ldyBD YWxsLUxlZ3MsIHNlZWluZyBhcyB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgY29u dGVudHMgb2YgdGhlaXIgJ1RvJyBoZWFkZXJzIGRpZmZlci4gQXMgc3VjaCwgdGhlcmUgaXMgbm8g PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHJlbGF0aW9uc2hpcDwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyBiZXR3ZWVuIHRoZWlyIENTZXEgdmFsdWVzLjwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgSWYgdGhpcyBp cyB0aGUgY2FzZSwgaG93IGlzIGl0IHBvc3NpYmxlIHRvIGVuc3VyZSBjb3JyZWN0IDwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBkaWdpdCBvcmRlcmluZzwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyBvdmVyIGFuICd1bnJlbGlhYmxlJyB0cmFuc3BvcnQgbGF5ZXIgbGlrZSBVRFA/ IEl0IHdvdWxkIHNlZW0gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGxvZ2ljYWwgdGhh dDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0aGUgY2FsbCBvcmlnaW5hdG9yIF93b3Vs ZF8gdXNlIGNvbnRpZ3VvdXMgQ1NlcSB2YWx1ZXMsIGFzIGl0IHdvdWxkIGJlPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7ICdhd2FyZScgb2YgdGhlIGZhY3QgdGhhdCB0aGUgSU5WSVRFcyBh cmUgZm9yIHRoZSBzYW1lIGNhbGwuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBJIGJlbGlldmUgdGhhdCB0aGlzIGlzc3VlIHdhcyBy YWlzZWQgb24gdGhlIFNJUCBsaXN0IG9uIDE5IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0 OyBOb3ZlbWJlciAxOTk5IGJ5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEdvbnphbG8g QyBhbmQgSm9uYXRoYW4gUi4gVGhlIHN1YmplY3Qgb2YgdGhlIG1lc3NhZ2VzIHdhcyA8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJnF1b3Q7UmU6IENvbW1lbnRzIG9uPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7IGRyYWZ0LWNhbWFyaWxsby1tbXVzaWMtc2lwLWlzdXAtYmNwLTAw LnR4dCZxdW90Oy4gVGhlIG91dGNvbWUgb2YgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 IHRoZSBleGNoYW5nZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBhcHBlYXJlZCB0byBi ZSBhbiBhZ3JlZW1lbnQgdGhhdCBDU2VxIG9yZGVyaW5nIHNob3VsZCBiZSBlbXBsb3llZC48L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 IEhvd2V2ZXIsIGRvZXMgdGhpcyBpbiBhbnkgd2F5IGltcGx5IHRoYXQgdW5kZXIgc3VjaCBjaXJj dW1zdGFuY2VzIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBJTlZJVEVzIHdvdWxk L3Nob3VsZCBiZWxvbmcgdG8gdGhlIHNhbWUgQ2FsbC1MZWc/IEFmdGVyIGFsbCwgPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRoZSBjb25jZXB0IG9mPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IE92ZXJsYXAgZG9lcyBub3Qgc2VlbSB0byAnZml0IGluJyB3aXRoIHRoZSBjb25j ZXB0IGJlaGluZCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgbXVsdGlwbGUgQ2FsbC1M ZWdzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGFueXdheS48L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IElmIHRoZXJlIGhh cyBiZWVuIGEgY2hhbmdlIGluIHRoaW5raW5nIGJlaGluZCB0aGUgcHJvYmxlbSwgPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGFuZCB0aGUgbGF0ZXN0PC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IGRyYWZ0IGlzIGNvcnJlY3QsIHBsZWFzZSBjb3VsZCB5b3UgZXhwbGFpbiBob3cg dGhlIG9yZGVyaW5nIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBwcm9ibGVtIHdpbGwg YmU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgb3ZlcmNvbWUuIElmIG5vdCwgcGVyaGFw cyB0aGUgZHJhZnQgbmVlZHMgbW9kaWZpY2F0aW9uIHRvIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jmd0OyBpbmNsdWRlIHRoZXNlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGNvbnNp ZGVyYXRpb25zLi4uPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgUmVnYXJkcyw8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m Z3Q7IEpvc2ggTW9sb25leTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+DQo= --0__=vR3EsyeFVTfvZMOXn6HFQNMJ6C1XP6RiymoTE0WBcmK8IQM2jEFAgXfc-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 04:23:53 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22308 for ; Thu, 1 Feb 2001 04:23:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B9EB744371; Thu, 1 Feb 2001 03:24:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 72D5D4433A for ; Thu, 1 Feb 2001 03:23:43 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id EAA11798; Thu, 1 Feb 2001 04:26:22 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Feb 2001 04:19:53 -0500 Message-ID: From: Jonathan Rosenberg To: "'Michael Thomas'" , "Henning G. Schulzrinne" Cc: Patrice Calhoun , christopher.a.martin@wcom.com, Anders Kristensen , "'David Frascone'" , sip@lists.bell-labs.com Subject: RE: [SIP] T2 and 182 Queued MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 04:19:50 -0500 > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Sunday, January 28, 2001 4:18 PM > To: Henning G. Schulzrinne > Cc: Michael Thomas; Patrice Calhoun; christopher.a.martin@wcom.com; > 'Anders Kristensen'; 'David Frascone'; sip@lists.bell-labs.com > Subject: Re: [SIP] T2 and 182 Queued > > > > Digest is worse than nothing at all (Basic at > > > least doesn't cop an attitude that it's anything > > > less than inadequate): as currently -- and likely > > > forever -- implemented does not provide basic > > > security features like replay protection, > > > > You keep repeating this, but that still doesn't make it correct. > > \/\/hatever. Be my guest. Build insecure boxes for > specious reasons. Declare the problem intractable > and substitute non-scalable fake security instead. > Maybe we can have a great big group hug after we > properly fawn over the emperor's new cloths. I suspect I sit somewhere between Henning and Mike in my attitude towards crypto; I've found myself becoming a strong advocate of TLS for inter-proxy communication, but I'm still not sure I believe its going to solve the problems to client to proxy authentication/confidentiality (lack of client certs being a real problem). There, digest has, for better or for worse, been used by many vendors. So, from a purely educational standpoint, I'd like additional clarification on its weaknesses, and why it is "worse than nothing". As far as I can tell, it does prevent replays (since it uses nonces which rotate frequently), does not expose plaintext passwords, etc. It is possible to modify messages in transit to change headers not covered, I'll give you that. Digest in 2617 does allow for the hash to cover the body, though, so this helps some. 2617 also does allow for response hashes, although I have not used it and don't know what problems it has. Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 04:42:52 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22416 for ; Thu, 1 Feb 2001 04:42:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4705E44375; Thu, 1 Feb 2001 03:43:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id A5E064436F for ; Thu, 1 Feb 2001 03:42:31 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 1 Feb 2001 09:42:18 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id JAA25860; Thu, 1 Feb 2001 09:41:00 GMT From: "Jo Hornsby" To: "William Marshall" , Cc: Subject: RE: [SIP] Some idea on Stateful SIP Proxy for Card Service Message-ID: <003401c08c33$154ad3a0$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 In-reply-to: <200101312209.RAA84628@fish-ha.research.att.com> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 09:40:59 -0000 Content-Transfer-Encoding: 7bit William Marshall wrote: > Consider a simple voicemail service, implemented by a service provider. > The UAS receives an INVITE, sends 180-Ringing, then 4xx/6xx and gives up. > The proxy changes the 4xx/6xx into a 302-Redirect with a Contact header > of the voicemail server. > > But, a proxy can't do this. So it is a B2BUA. There is nothing about > state storage needed, nothing extra for fault tolerance and scale; > in fact this "proxy" is probably simpler than most "stateful proxies". > But its need to change the response from 4xx/6xx to 3xx makes it a B2BUA. I disagree with this. I think it is fine for a proxy to pull responses "out of the air". What's it's not allowed to do is modify fundamental transaction-identifying headers (From, To, Call-ID, CSeq, Via immediately spring to mind). > Second example is any kind of subscription-based service to the proxy. > Subscriptions expire. The proxy, if it is maintaining any call state > as a "stateful proxy", will want to terminate any pending connections > rather than continue to provide free service. So it generates a BYE. > Not a proxy any longer, now a B2BUA. But not any more complex than > any other stateful proxy, (except possibly for remembering the Record- > Route header value for the active sessions). The fault tolerance and > scale problems are the same as the stateful proxy. Okay, I would agree that this -- the way that you describe it, anyway -- cannot be done without a B2BUA. However, Session Timer might go some way towards achieving similar goals.... > I'm not familiar with CPL, so maybe those can be done with > stateful proxies. > Can a CPL type of service re-write error responses, like a 4xx to a 3xx? > Can a CPL type of service re-write header values, like a Contact header > for forwarding? Can a CPL type of service look at the SDP to pick an > appropriate destination based on the media being requested? All simple > transformations, but all require a B2BUA. Base CPL does not offer a way to describe how to achieve all of these things; however, I would say that it is still acceptable for a proxy to do any of them. > Maybe I overstated the case by saying "a 'stateful proxy' will never > exist". My suspician is that a typical session will have a proxy at each > end (providing service for the UAC/UAS), and several stateless proxies > in the middle. My suspician is still that the proxy providing service > to the endpoints will not meet the restrictions of a proxy, and will > need to be classified a B2BUA. But this does not make this element > any more complex than a "stateful proxy". That maybe so. I must admit that I'm not sure knowing that something is a proxy or a B2BUA is helpful anyway. I don't really care what it is, as long as it performs the services I think are neat. Cheers, - Jo. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 05:27:53 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23125 for ; Thu, 1 Feb 2001 05:27:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 806264436F; Thu, 1 Feb 2001 04:28:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 4ACC04433A for ; Thu, 1 Feb 2001 04:27:11 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 1 Feb 2001 10:26:58 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA13415; Thu, 1 Feb 2001 10:25:46 GMT Message-ID: <3A7939A8.27FD7E2E@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] Some idea on Stateful SIP Proxy for Card Service References: <200101312209.RAA84628@fish-ha.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 01 Feb 2001 10:25:44 +0000 Content-Transfer-Encoding: 7bit William Marshall wrote: > > > > P is clearly a back-to-back-UA, since it speaks SIP to > > > both user B and terminal C. However, its need to initiate > > > a BYE doesn't fit the profile of a proxy. Just a B2BUA. > > > > > > In looking at various enhanced services, it is not clear > > > to me that a "stateful proxy" will ever exist. They will > > > all be B2BUAs for some case or another. > > > > > > > No. > > > > You only want to be a B2BUA if that is the only way. The requirements for > > fault tolerance and scale are much harder with a B2BUA (on part with a UA, > > not a surprise). Stateful proxies can record-route and insert vias with > > domain names, and the result is that these devices can still fail and the > > calls can be recovered by routing the request/response to an alternate. Not > > so for a B2BUA, which has state that now needs to be replicated in some way > > (I realize State header is another possibility, its still just a form of > > state replication). > > > > Many services require only a stateful proxy. Many personal mobility services > > fall into this category, as do all CPL types of services. This isn't > > everything, but its a decent number. > > > > -Jonathan R. > > I think I agree with all the points you make, but disagree with the > conclusion. > > Consider a simple voicemail service, implemented by a service provider. > The UAS receives an INVITE, sends 180-Ringing, then 4xx/6xx and gives up. > The proxy changes the 4xx/6xx into a 302-Redirect with a Contact header > of the voicemail server. > > But, a proxy can't do this. So it is a B2BUA. There is nothing about > state storage needed, nothing extra for fault tolerance and scale; > in fact this "proxy" is probably simpler than most "stateful proxies". > But its need to change the response from 4xx/6xx to 3xx makes it a B2BUA. This is not a B2BUA as it does not require a UAS|UAC state machine. This is a stateful proxy operating in the same way that it does to filter multiple responses after forking. Where the 3xx arrives at the proxy from is irrelevant. > Second example is any kind of subscription-based service to the proxy. > Subscriptions expire. The proxy, if it is maintaining any call state > as a "stateful proxy", will want to terminate any pending connections > rather than continue to provide free service. So it generates a BYE. > Not a proxy any longer, now a B2BUA. But not any more complex than > any other stateful proxy, (except possibly for remembering the Record- > Route header value for the active sessions). The fault tolerance and > scale problems are the same as the stateful proxy. > > I'm not familiar with CPL, so maybe those can be done with stateful proxies. > Can a CPL type of service re-write error responses, like a 4xx to a 3xx? > Can a CPL type of service re-write header values, like a Contact header > for forwarding? Can a CPL type of service look at the SDP to pick an > appropriate destination based on the media being requested? All simple > transformations, but all require a B2BUA. Forwarding to voicemail on 4xx/6xx is trivial with CPL. It can direct the proxy to send the INVITE on to the VM server, this avoid having to send back a 3xx. > Maybe I overstated the case by saying "a 'stateful proxy' will never > exist". My suspician is that a typical session will have a proxy at each > end (providing service for the UAC/UAS), and several stateless proxies > in the middle. My suspician is still that the proxy providing service > to the endpoints will not meet the restrictions of a proxy, and will > need to be classified a B2BUA. But this does not make this element > any more complex than a "stateful proxy". You have referred to this model before but never explained what the additional stateless proxies in the middle are needed for? Also this is not the model that I recall seeing in the DCS drafts. In that things like the privacy reqs that could be better guaranteed through B2BUAs were being required of proxies. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From extest-admin@lists.bell-labs.com Thu Feb 1 06:17:17 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23508 for ; Thu, 1 Feb 2001 06:17:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3DAE644B90 for ; Thu, 1 Feb 2001 05:06:00 -0500 (EST) Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: sip-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20010201100600.3DAE644B90@lists.bell-labs.com> Date: Thu, 1 Feb 2001 05:06:00 -0500 (EST) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, sip-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for sip-archive@lists.ietf.org: List Password // URL ---- -------- sip@lists.bell-labs.com TDGd http://lists.bell-labs.com/mailman/options/sip/sip-archive%40lists.ietf.org From sip-admin@lists.bell-labs.com Thu Feb 1 09:13:03 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27523 for ; Thu, 1 Feb 2001 09:12:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B1A074433E; Thu, 1 Feb 2001 08:13:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id A70584433A for ; Thu, 1 Feb 2001 08:12:07 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 1 Feb 2001 09:10:57 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 1 Feb 2001 09:08:37 -0500 Message-ID: <28560036253BD41191A10000F8BCBD11038E3AD3@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Keith Robinson Cc: sip@lists.bell-labs.com, "Joshua Moloney" Subject: RE: [SIP] Overlap call setup MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08C58.76E9FA30" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 09:08:34 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08C58.76E9FA30 Content-Type: text/plain; charset="ISO-8859-1" I see the disconnect here. You are assuming that the first IAM gets propagated through the egress gateway, so an ISUP state machine is set into play. I think the synthesis of our thinking is this: (1) The first problem is to receive enough digits so an egress gateway can be selected. Until that happens, the digits have to be accumulated into successive initial INVITE messages. (2) Once an egress gateway has been selected, call routing is complete as far as the SIP domain is concerned. Hence it is legitimate to use the INFO method to carry subsequent digits. > -----Original Message----- > From: Keith Robinson [mailto:Keith.Robinson@marconi.com] > Sent: Thursday, February 01, 2001 4:05 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: sip@lists.bell-labs.com; Moloney, Joshua [MDN05:CT07:EXCH] > Subject: RE: [SIP] Overlap call setup > > > > > If the SIP side of the gateway is retaining state then the > UAS side has to know > that the subsequent > digits have to be sent to the same call state machine (on the > ISUP side) as the > original digits. If you > choose a different UAS, and the INVITE containing susequent > digits is treated as > a new call attempt > by this UAS, how does it know which state machine on the ISUP > side to send the > digits to. I'm thinking > of a configuration where there exists a farm of UAS for > scalability and load > distribution. > > Originally, I did say that sending 484 and completely > forgetting about the call > would work, I just don't think > it is the best way; the original state machine on the ISUP > side would probably > time out if it received no > further digits and a new state machine created by the > subsequent INVITE would > now handle the call. > > In the case of 11.3 in the sip-isup document, then the > subsequent INVITEs must > arrive at the same gateway, > otherwise unnecessary IAMs are generated. This is pointed out > in the text. > > Regards, > > K. Robinson > > > > > > > > "Tom-PT Taylor" on 31/01/2001 18:31:11 > > > > > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > cc: sip@lists.bell-labs.com, "Joshua Moloney" > > > > > Subject: RE: [SIP] Overlap call setup > > > > > > > > > I think you've made one assumption I might question. Assuming that > subsequent INVITEs are being sent, containing all of the digits so far > collected, so that they are self-contained: why is it > necessary that each > ends up at the same UAS? When the 484 is sent back, call > state should be > cleared all along the path, even in the SIP-UAC side of the > ingress gateway. > Only the ISUP side of that gateway and, I suppose, the > ISUP-SIP interworking > function, should retain call state. > > > -----Original Message----- > > From: Keith Robinson [mailto:Keith.Robinson@marconi.com] > > Sent: Wednesday, January 31, 2001 11:34 AM > > To: Moloney, Joshua [MDN05:CT07:EXCH] > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > I have recently been trying to get clarification on the > > implemenation of > > overlap sending; see attached for the discussion that has > taken place > > so far. > > > > Certainly, the mechanism outlined (very sketchily) in > > RFC2543bis-02 sect 4.2.1 > > is fundamentally flawed. The Request-URI cannot be used to > > carry extra digits > > as the Record-Route/Route mechanism would end up > overwriting the R-URI > > and therefore the subsequent digits would be lost. > > > > This then leads to the idea of using the TO field as described in > > sip-isup-00-00.txt; > > however, I have the following issues with the mechanisms > > described in this > > document : > > > > As the TO field is different on each subsequent INVITE, then > > it is a new call > > leg > > on an existing call id; RFC2543bis-02 sect. 11.5 does not > > state what a UAS > > should make of this. If you follow the logic in 11.5 you get > > to case (3), but > > here it only defines the behaviour if the TO and FROM fields match. > > > > The 484 sent backwards kills that call attempt (but not the > > state for that > > Call-Id - > > is this problematic for intermediate proxies ?) so subsequent > > INVITEs will > > actually be initial INVITEs. As these INVITEs must get to the > > same terminating > > UAS, > > the originating UAC will have to create a ROUTE header in an > > initial INVITE > > using , > > at least the CONTACT address from the 484. This implies the > > use of source > > routing, an > > issue that I don't believe has been fully resolved, and even > > if it is and > > becomes part > > of the base protocol some administrations may be reluctant to > > admit initial > > INVITEs > > which try to circumvent their routing policy, so may reject > > such INVITEs. > > > > Also on the above point, the CONTACT address in the 484 must > > have the same > > semantics as that in a 200 response so that a ROUTE header > > can be built; however > > RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in > > 4XX responses > > indicates a location where additional error information can > > be found. Indeed, in > > a recent > > thread entitled Announcements in SIP (401 & 407 Contact) J. > > Rosenberg believes > > that > > Record-Route does not make sense in any non-200 response. > > > > I would raise the question of whether the 484 response has > > any use in overlap > > sending > > (certainly in the case of ISUP) at all. If a node receives > > insufficient digits > > to decode than it will wait until it receives some more from > > the preceding node > > (or end of > > dialling timers mature). If the preceding node receives > > subsequent digits and > > end of dialling > > has not been detected then it will pass them on. If the 484 > > indicated the > > minimum number of > > digits before a decode could take place, then it would be > > useful in cutting down > > the number > > of subseqent messages sent. > > > > Indeed, isup-sip-00.txt does cover the mechanism where a 183 > > is sent, and not a > > 484. > > The case in point is covered in sect. 11.3 (Example of SIP > > bridging and overlap > > signalling); > > However, I have the following issues with this mechanism: > > > > As before relies on source routing. > > > > Relies on proxies sending requests on new call legs but > > existing call-ids to the > > same > > downstream server; fine if you administer these proxies, what > > if you don't ? > > (Lots of > > wasted IAMs generated). The mechanism should not send 5 > > (subsequent INVITE) > > until it has received an acknowledgement (probably not 100) > > from the first. > > Alternatively, > > the Reason-Phrase could detail more specifically the exact > > progress of the call > > ("Decoding Address" > > in this case ?) so that the ACM is not generated unconditionally. > > > > Sect. 11.2 encourages gateways "to return a183 Session > > Progress with a Contact > > header as soon as they receive an INVITE that they are going > > to handle and might > > contain > > an incomplete number". Presumably this is to allow the UAC to > > build a ROUTE so > > that subsequent > > INVITEs get to the appropriate UAS. Sect 7.2.3 indicates that > > a node receiving a > > 183 prior to generating > > an ACM should generate an ACM. Applied together these rules > > may cause a prior > > node to never > > send on any subsequent digits and overlap sending would fail. > > > > I think an approach is required whereby subsequent digits are > > sent on the same > > call leg as the > > initial INVITE; either multiple INVITEs are allowed before > > 200 OK (already > > suggested by J. Rosenberg > > in a different context) , or the INFO method is used. In both > > cases the TO field > > will have to remain the > > same so a new header (or message body type) is required to > > convey the digits. > > Also, replace the 484 > > with, say, 18X indicating the minimum number of digits > > required, perhaps in the > > Reason-Phrase header. > > > > Regards, > > > > Keith Robinson. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Joshua Moloney" on > 31/01/2001 10:49:33 > > > > > > > > > > > > > > > > > > > > > > > > To: sip@lists.bell-labs.com > > > > cc: (bcc: Keith Robinson/MAIN/MC1) > > > > > > > > Subject: [SIP] Overlap call setup > > > > > > > > > > > > > > > > > > Greetings, > > > > I would like to ask for clarification regarding the > implementation of > > Overlap. > > > > I'll begin by referring to paragraph 3, section 6.1.2 of > > "draft-ietf-isup-sip-00": > > > > It is stated that INVITEs sent after the first one > > (containing extra digits > > in the 'To' field) are to be treated as new Call-Legs, seeing as the > > contents of their 'To' headers differ. As such, there is no > > relationship > > between their CSeq values. > > > > If this is the case, how is it possible to ensure correct > > digit ordering > > over an 'unreliable' transport layer like UDP? It would seem > > logical that > > the call originator _would_ use contiguous CSeq values, as > it would be > > 'aware' of the fact that the INVITEs are for the same call. > > > > I believe that this issue was raised on the SIP list on 19 > > November 1999 by > > Gonzalo C and Jonathan R. The subject of the messages was > > "Re: Comments on > > draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of > > the exchange > > appeared to be an agreement that CSeq ordering should be employed. > > > > However, does this in any way imply that under such > circumstances the > > INVITEs would/should belong to the same Call-Leg? After all, > > the concept of > > Overlap does not seem to 'fit in' with the concept behind > > multiple Call-Legs > > anyway. > > > > If there has been a change in thinking behind the problem, > > and the latest > > draft is correct, please could you explain how the ordering > > problem will be > > overcome. If not, perhaps the draft needs modification to > > include these > > considerations... > > > > > > Regards, > > > > Josh Moloney > > > > > > ------_=_NextPart_001_01C08C58.76E9FA30 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Overlap call setup

I see the disconnect here.  You are assuming = that the first IAM gets propagated through the egress gateway, so an = ISUP state machine is set into play.  I think the synthesis of our = thinking is this:

(1) The first problem is to receive enough digits so = an egress gateway can be selected.  Until that happens, the digits = have to be accumulated into successive initial INVITE = messages.

(2) Once an egress gateway has been selected, call = routing is complete as far as the SIP domain is concerned.  Hence = it is legitimate to use the INFO method to carry subsequent = digits.

> -----Original Message-----
> From: Keith Robinson [mailto:Keith.Robinson@marconi= .com]
> Sent: Thursday, February 01, 2001 4:05 = AM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: sip@lists.bell-labs.com; Moloney, Joshua = [MDN05:CT07:EXCH]
> Subject: RE: [SIP] Overlap call setup
>
>
>
>
> If the SIP side of the gateway is retaining = state then the
> UAS side has to know
> that the subsequent
> digits have to be sent to the same call state = machine (on the
> ISUP side) as the
> original digits. If you
> choose a different UAS, and the INVITE = containing susequent
> digits is treated as
> a new call attempt
> by this UAS, how does it know which state = machine on the ISUP
> side to send the
> digits to. I'm thinking
> of a configuration where there exists a farm of = UAS for
> scalability and load
> distribution.
>
> Originally, I did say that sending 484 and = completely
> forgetting about the call
> would work, I just don't think
> it is the best way; the original state machine = on the ISUP
> side would probably
> time out if it received no
> further digits and a new state machine created = by the
> subsequent INVITE would
> now handle the call.
>
> In the case of 11.3 in the sip-isup document, = then the
> subsequent INVITEs must
> arrive at the same gateway,
> otherwise unnecessary IAMs are generated. This = is pointed out
> in the text.
>
> Regards,
>
> K. Robinson
>
>
>
>
>
>
>
> "Tom-PT Taylor" = <taylor@nortelnetworks.com> on 31/01/2001 18:31:11
>          = ;            = ;            = ;            = ;            = ;    
>          = ;        
>          = ;            = ;            = ;            = ;            = ;    
>          = ;        
>          = ;            = ;            = ;            = ;            = ;    
>          = ;        
>
>
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>  To:      Keith = Robinson/MAIN/MC1@MCMAIN        =             =  
>          = ;            = ;            = ;            = ;            = ;    
>  cc:      = sip@lists.bell-labs.com, "Joshua = Moloney"          = ;
>          = ; = <jmoloney@nortelnetworks.com>      &= nbsp;           &= nbsp;   
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>  Subject: RE: [SIP] Overlap call = setup           &= nbsp;            =
>          = ;            = ;            = ;            = ;            = ;    
>
>
>
>
>
>
>
> I think you've made one assumption I might = question.  Assuming that
> subsequent INVITEs are being sent, containing = all of the digits so far
> collected, so that they are self-contained: why = is it
> necessary that each
> ends up at the same UAS?  When the 484 is = sent back, call
> state should be
> cleared all along the path, even in the SIP-UAC = side of the
> ingress gateway.
> Only the ISUP side of that gateway and, I = suppose, the
> ISUP-SIP interworking
> function, should retain call state.
>
> > -----Original Message-----
> > From: Keith Robinson [mailto:Keith.Robinson@marconi= .com]
> > Sent: Wednesday, January 31, 2001 11:34 = AM
> > To: Moloney, Joshua = [MDN05:CT07:EXCH]
> > Cc: sip@lists.bell-labs.com
> > Subject: Re: [SIP] Overlap call = setup
> >
> >
> >
> >
> > I have recently been trying to get = clarification on the
> > implemenation of
> > overlap sending; see attached for the = discussion that has
> taken place
> > so far.
> >
> > Certainly, the mechanism outlined (very = sketchily) in
> > RFC2543bis-02 sect 4.2.1
> > is fundamentally flawed. The Request-URI = cannot be used to
> > carry extra digits
> > as the Record-Route/Route mechanism would = end up
> overwriting the R-URI
> > and therefore the subsequent digits would = be lost.
> >
> > This then leads to the idea of using the = TO field as described in
> > sip-isup-00-00.txt;
> > however, I have the following issues with = the mechanisms
> > described in this
> > document :
> >
> > As the TO field is different on each = subsequent INVITE, then
> > it is a new call
> > leg
> > on an existing call id; RFC2543bis-02 = sect. 11.5 does not
> > state what a UAS
> > should make of this. If you follow the = logic in 11.5 you get
> > to case (3), but
> > here it only defines the behaviour  = if the TO and FROM fields match.
> >
> > The 484 sent backwards kills that call = attempt (but not the
> > state for that
> > Call-Id -
> > is this problematic for intermediate = proxies ?) so subsequent
> > INVITEs will
> > actually be initial INVITEs. As these = INVITEs must get to the
> > same terminating
> > UAS,
> > the originating  UAC will have to = create a ROUTE header in an
> > initial INVITE
> > using ,
> > at least the CONTACT address from the 484. = This implies the
> > use of source
> > routing, an
> > issue that I don't believe has been fully = resolved, and even
> > if it is and
> > becomes part
> > of the base protocol some administrations = may be reluctant to
> > admit initial
> > INVITEs
> > which try to circumvent their routing = policy, so may reject
> > such INVITEs.
> >
> > Also on the above point, the CONTACT = address in the 484 must
> > have the same
> > semantics as that in a 200 response so = that a ROUTE header
> > can be built; however
> > RFC2543bis-02 sect. 6.14 specifies that a = CONTACT address in
> > 4XX responses
> > indicates a location where additional = error information can
> > be found. Indeed, in
> > a recent
> > thread entitled Announcements in SIP (401 = & 407 Contact) J.
> > Rosenberg believes
> > that
> > Record-Route does not make sense in any = non-200 response.
> >
> > I would raise the question of whether the = 484 response has
> > any use in overlap
> > sending
> > (certainly in the case of ISUP) at all. If = a node receives
> > insufficient digits
> > to decode than it will wait until it = receives some more from
> > the preceding node
> > (or end of
> > dialling timers mature). If the preceding = node receives
> > subsequent digits and
> > end of dialling
> > has not been detected then it will pass = them on. If the 484
> > indicated the
> > minimum number of
> > digits before a decode could take place, = then it would be
> > useful in cutting down
> > the number
> > of subseqent messages sent.
> >
> > Indeed, isup-sip-00.txt does cover the = mechanism where a 183
> > is sent, and not a
> > 484.
> > The case in point is covered in sect. 11.3 = (Example of SIP
> > bridging and overlap
> > signalling);
> > However, I have the following issues with = this mechanism:
> >
> > As before relies on source routing.
> >
> > Relies on proxies sending requests on new = call legs but
> > existing call-ids to the
> > same
> > downstream server; fine if you administer = these proxies, what
> > if you don't ?
> > (Lots of
> > wasted IAMs generated). The mechanism = should not send 5
> > (subsequent INVITE)
> > until it has received an acknowledgement = (probably not 100)
> > from the first.
> > Alternatively,
> > the Reason-Phrase could detail more = specifically the exact
> > progress of the call
> > ("Decoding Address"
> > in this case ?) so that the ACM is not = generated unconditionally.
> >
> > Sect. 11.2 encourages gateways "to = return a183 Session
> > Progress with a Contact
> > header as soon as they receive an INVITE = that they are going
> > to handle and might
> > contain
> > an incomplete number". Presumably = this is to allow the UAC to
> > build a ROUTE so
> > that subsequent
> > INVITEs get to the appropriate UAS. Sect = 7.2.3 indicates that
> > a node receiving a
> > 183 prior to generating
> > an ACM should generate an ACM. Applied = together these rules
> > may cause a prior
> > node to never
> > send on any subsequent digits and overlap = sending would fail.
> >
> > I think an approach is required whereby = subsequent digits are
> > sent on the same
> > call leg as the
> > initial INVITE; either multiple INVITEs = are allowed before
> > 200 OK (already
> > suggested by J. Rosenberg
> > in a different context) , or the INFO = method is used. In both
> > cases the TO field
> > will have to remain the
> > same so a new header (or message body = type) is required to
> > convey the digits.
> > Also, replace the 484
> > with, say, 18X indicating the minimum = number of digits
> > required, perhaps in the
> > Reason-Phrase header.
> >
> > Regards,
> >
> > Keith Robinson.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > "Joshua Moloney" = <jmoloney@nortelnetworks.com> on
> 31/01/2001 10:49:33
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >  To:      = sip@lists.bell-labs.com
> >
> >  cc:      = (bcc: Keith Robinson/MAIN/MC1)
> >
> >
> >
> >  Subject: [SIP] Overlap call = setup
> >
> >
> >
> >
> >
> >
> >
> >
> > Greetings,
> >
> > I would like to ask for clarification = regarding the
> implementation of
> > Overlap.
> >
> > I'll begin by referring to paragraph 3, = section 6.1.2 of
> > "draft-ietf-isup-sip-00":
> >
> > It is stated that INVITEs sent after the = first one
> > (containing extra digits
> > in the 'To' field) are to be treated as = new Call-Legs, seeing as the
> > contents of their 'To' headers differ. As = such, there is no
> > relationship
> > between their CSeq values.
> >
> > If this is the case, how is it possible to = ensure correct
> > digit ordering
> > over an 'unreliable' transport layer like = UDP? It would seem
> > logical that
> > the call originator _would_ use contiguous = CSeq values, as
> it would be
> > 'aware' of the fact that the INVITEs are = for the same call.
> >
> > I believe that this issue was raised on = the SIP list on 19
> > November 1999 by
> > Gonzalo C and Jonathan R. The subject of = the messages was
> > "Re: Comments on
> > = draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of
> > the exchange
> > appeared to be an agreement that CSeq = ordering should be employed.
> >
> > However, does this in any way imply that = under such
> circumstances the
> > INVITEs would/should belong to the same = Call-Leg? After all,
> > the concept of
> > Overlap does not seem to 'fit in' with the = concept behind
> > multiple Call-Legs
> > anyway.
> >
> > If there has been a change in thinking = behind the problem,
> > and the latest
> > draft is correct, please could you explain = how the ordering
> > problem will be
> > overcome. If not, perhaps the draft needs = modification to
> > include these
> > considerations...
> >
> >
> > Regards,
> >
> > Josh Moloney
> >
> >
>
>

------_=_NextPart_001_01C08C58.76E9FA30-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 09:33:53 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27970 for ; Thu, 1 Feb 2001 09:33:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CAC5944348; Thu, 1 Feb 2001 08:34:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from telesoft.indts.com (unknown [164.164.71.52]) by lists.bell-labs.com (Postfix) with ESMTP id BF8774433A for ; Thu, 1 Feb 2001 08:33:40 -0500 (EST) Received: from indts_fs.indts.com (indts_fs [201.64.64.29]) by telesoft.indts.com (8.8.7/8.8.7) with ESMTP id UAA26242 for ; Thu, 1 Feb 2001 20:21:01 +0530 Received: by INDTS_FS with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Feb 2001 20:06:46 +0530 Message-ID: <3939481A31CFD411B9630040056E879617B411@INDTS_FS> From: Nitin Kumar To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Difference between SIP and MGCP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 20:06:46 +0530 Hi, I am writing for the first time on this mailing list. So, hoping to get the answer. I have a very basic question. I understand SIP is useful for inter-MGC communication as well as for tunneling of PSTN signalling across IP network. But when we talk about SIP phone or residential gateways... Is SIP better than MGCP or Megaco? If yes, then how ? Is there any document which goes into detail about SIP and MGCP/Megaco comparison? Moreover, Is there any work going on for SIP trunking gateway? regards -nitin _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 10:12:05 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28961 for ; Thu, 1 Feb 2001 10:12:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BDA304435F; Thu, 1 Feb 2001 09:12:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 1B59C4434C for ; Thu, 1 Feb 2001 09:11:59 -0500 (EST) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f11FBR100483; Thu, 1 Feb 2001 10:11:27 -0500 (EST) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA06267; Thu, 1 Feb 2001 10:10:29 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Feb 2001 10:11:26 -0500 Message-ID: From: "Lebovits, Doris S, ALCOO" To: "'Jon.Peterson@Level3.com'" Cc: sip@lists.bell-labs.com, chsharp@cisco.com Subject: RE: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 10:11:20 -0500 Jon, I do not agree with your comments. I think ITU-T ISUP 2000 should be the base, as it is the base going forward. ITU-T ISUP 2000 is backwards compatible with previous versions such as ISUP '92. The options in ITU-T ISUP 2000 that would not need to be specified for this activity could be highlighted as not mandatory. The ANSI version of ISUP is T1.113 and has been updated to the ITU-T ISUP 2000 level and is in the final stages for publication. Doris Lebovits AT&T dlebovits@att.com ========================================================== -----Original Message----- From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com] Sent: Thursday, February 01, 2001 1:06 AM To: chsharp@cisco.com; sip@lists.bell-labs.com Subject: RE: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt I think it was the hope of the authors that all of the meaningful values for 'base' would be characterized in the document. Since 'base' reflects the lowest common dominator (or, to coin a phrase, least specific ancestor) variant of the ISUP version in question, the authors hoped that given the backwards compatibility mechanism in ITU-T 1992 Q.76x, itu92 would be the proper base for forthcoming ISUP versions (new versions of ANSI following the 2000 issue support this mechanism, even). That much said, if there are potential 'base' values which are of use to the community that cannot be said to derive from itu92, the authors would certainly like to be made aware of them. Is there anything out there that the ISUP MIME draft misses? In the face of serious concerns that useful new 'bases' might come to light subsequent to the publication of an RFC, I suppose management of 'base' by IANA could be introduced, but personally I'd rather not trouble IANA with this additional responsibility if there isn't a substantial risk. Was there anything specific you had in mind? Jon Peterson Level(3) Communications -----Original Message----- From: Chip Sharp [mailto:chsharp@cisco.com] Sent: Tuesday, January 30, 2001 10:50 AM To: sip@lists.bell-labs.com Subject: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt Currently, the IANA considerations section of draft-ietf-sip-isup-mime-07.txt describes how to define new "version" fields, but does not describe how to define new "base" fields. Given that new base protocols may be identified, shouldn't there be a description on how IANA assigns new "base" values? Chip ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems ------------------------------------------------------------------- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 10:20:51 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29150 for ; Thu, 1 Feb 2001 10:20:47 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DDC0E4434C; Thu, 1 Feb 2001 09:15:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 27CAC4434C for ; Thu, 1 Feb 2001 09:14:06 -0500 (EST) 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 f11F9nC23955; Thu, 1 Feb 2001 16:09:49 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA02573; Thu, 1 Feb 2001 17:09:48 +0200 (EET) Message-ID: <3A797C3A.C8DF7163@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor Cc: Keith Robinson , sip@lists.bell-labs.com, Joshua Moloney Subject: Re: [SIP] Overlap call setup References: <28560036253BD41191A10000F8BCBD11038E3AD3@zcard00g.ca.nortel.com> Content-Type: multipart/mixed; boundary="------------0F424C7291C4325EDD9A8C27" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 01 Feb 2001 17:09:46 +0200 This is a multi-part message in MIME format. --------------0F424C7291C4325EDD9A8C27 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >I see the disconnect here. You are assuming that the first IAM gets >propagated through the egress gateway, so an ISUP state machine is set >into play. I think the synthesis of our thinking is this: > >(1) The first problem is to receive enough digits so an egress gateway >can be selected. Until that happens, the digits have to be >accumulated into successive initial INVITE messages. > >(2) Once an egress gateway has been selected, call routing is complete >as far as the SIP domain is concerned. Hence it is legitimate to use >the INFO method to carry subsequent digits. Let's assume the following case (hopefully I understood you correctly): You want to call 12345 on the PSTN side, and in the first INVITE you only send the first digit, ie. INVITE 1@pstnGW.com The GW returns 484, which you ACK. Then you start sending digits with INFO, ie. INFO 1@pstnGW.com more-digit: 23 The GW returns 200, and we may send more INFOs with the rest of the digits. Now: 1. How do we know when the call is established? Since we have sent a final response to the INVITE, we can't send a 200 OK to it. 2. When all the digits have reached the PSTN network, there may be some early media/alerting messages etc. to be sent, but again - since the GW has sent a final response to the INVITE, 18x provisional responses can't be sent. What do you think about the following: Instead of sending 484, the GW sends some provisional response (ie. 186 More digits needed). Then we use INFO messages(s) to provide the rest of the digits, and when all digits have reached the PSTN side, and the call can be established, we receive the 200 OK to the INVITE. Regards, Christer Holmberg Ericsson Finland > > > -----Original Message----- > > From: Keith Robinson [mailto:Keith.Robinson@marconi.com] > > Sent: Thursday, February 01, 2001 4:05 AM > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: sip@lists.bell-labs.com; Moloney, Joshua [MDN05:CT07:EXCH] > > Subject: RE: [SIP] Overlap call setup > > > > > > > > > > If the SIP side of the gateway is retaining state then the > > UAS side has to know > > that the subsequent > > digits have to be sent to the same call state machine (on the > > ISUP side) as the > > original digits. If you > > choose a different UAS, and the INVITE containing susequent > > digits is treated as > > a new call attempt > > by this UAS, how does it know which state machine on the ISUP > > side to send the > > digits to. I'm thinking > > of a configuration where there exists a farm of UAS for > > scalability and load > > distribution. > > > > Originally, I did say that sending 484 and completely > > forgetting about the call > > would work, I just don't think > > it is the best way; the original state machine on the ISUP > > side would probably > > time out if it received no > > further digits and a new state machine created by the > > subsequent INVITE would > > now handle the call. > > > > In the case of 11.3 in the sip-isup document, then the > > subsequent INVITEs must > > arrive at the same gateway, > > otherwise unnecessary IAMs are generated. This is pointed out > > in the text. > > > > Regards, > > > > K. Robinson > > > > > > > > > > > > > > > > "Tom-PT Taylor" on 31/01/2001 18:31:11 > > > > > > > > > > > > > > > > > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > > > cc: sip@lists.bell-labs.com, "Joshua Moloney" > > > > > > > > > > Subject: RE: [SIP] Overlap call setup > > > > > > > > > > > > > > > > > > I think you've made one assumption I might question. Assuming that > > subsequent INVITEs are being sent, containing all of the digits so > far > > collected, so that they are self-contained: why is it > > necessary that each > > ends up at the same UAS? When the 484 is sent back, call > > state should be > > cleared all along the path, even in the SIP-UAC side of the > > ingress gateway. > > Only the ISUP side of that gateway and, I suppose, the > > ISUP-SIP interworking > > function, should retain call state. > > > > > -----Original Message----- > > > From: Keith Robinson [mailto:Keith.Robinson@marconi.com] > > > Sent: Wednesday, January 31, 2001 11:34 AM > > > To: Moloney, Joshua [MDN05:CT07:EXCH] > > > Cc: sip@lists.bell-labs.com > > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > > > > > > I have recently been trying to get clarification on the > > > implemenation of > > > overlap sending; see attached for the discussion that has > > taken place > > > so far. > > > > > > Certainly, the mechanism outlined (very sketchily) in > > > RFC2543bis-02 sect 4.2.1 > > > is fundamentally flawed. The Request-URI cannot be used to > > > carry extra digits > > > as the Record-Route/Route mechanism would end up > > overwriting the R-URI > > > and therefore the subsequent digits would be lost. > > > > > > This then leads to the idea of using the TO field as described in > > > sip-isup-00-00.txt; > > > however, I have the following issues with the mechanisms > > > described in this > > > document : > > > > > > As the TO field is different on each subsequent INVITE, then > > > it is a new call > > > leg > > > on an existing call id; RFC2543bis-02 sect. 11.5 does not > > > state what a UAS > > > should make of this. If you follow the logic in 11.5 you get > > > to case (3), but > > > here it only defines the behaviour if the TO and FROM fields > match. > > > > > > The 484 sent backwards kills that call attempt (but not the > > > state for that > > > Call-Id - > > > is this problematic for intermediate proxies ?) so subsequent > > > INVITEs will > > > actually be initial INVITEs. As these INVITEs must get to the > > > same terminating > > > UAS, > > > the originating UAC will have to create a ROUTE header in an > > > initial INVITE > > > using , > > > at least the CONTACT address from the 484. This implies the > > > use of source > > > routing, an > > > issue that I don't believe has been fully resolved, and even > > > if it is and > > > becomes part > > > of the base protocol some administrations may be reluctant to > > > admit initial > > > INVITEs > > > which try to circumvent their routing policy, so may reject > > > such INVITEs. > > > > > > Also on the above point, the CONTACT address in the 484 must > > > have the same > > > semantics as that in a 200 response so that a ROUTE header > > > can be built; however > > > RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in > > > 4XX responses > > > indicates a location where additional error information can > > > be found. Indeed, in > > > a recent > > > thread entitled Announcements in SIP (401 & 407 Contact) J. > > > Rosenberg believes > > > that > > > Record-Route does not make sense in any non-200 response. > > > > > > I would raise the question of whether the 484 response has > > > any use in overlap > > > sending > > > (certainly in the case of ISUP) at all. If a node receives > > > insufficient digits > > > to decode than it will wait until it receives some more from > > > the preceding node > > > (or end of > > > dialling timers mature). If the preceding node receives > > > subsequent digits and > > > end of dialling > > > has not been detected then it will pass them on. If the 484 > > > indicated the > > > minimum number of > > > digits before a decode could take place, then it would be > > > useful in cutting down > > > the number > > > of subseqent messages sent. > > > > > > Indeed, isup-sip-00.txt does cover the mechanism where a 183 > > > is sent, and not a > > > 484. > > > The case in point is covered in sect. 11.3 (Example of SIP > > > bridging and overlap > > > signalling); > > > However, I have the following issues with this mechanism: > > > > > > As before relies on source routing. > > > > > > Relies on proxies sending requests on new call legs but > > > existing call-ids to the > > > same > > > downstream server; fine if you administer these proxies, what > > > if you don't ? > > > (Lots of > > > wasted IAMs generated). The mechanism should not send 5 > > > (subsequent INVITE) > > > until it has received an acknowledgement (probably not 100) > > > from the first. > > > Alternatively, > > > the Reason-Phrase could detail more specifically the exact > > > progress of the call > > > ("Decoding Address" > > > in this case ?) so that the ACM is not generated unconditionally. > > > > > > Sect. 11.2 encourages gateways "to return a183 Session > > > Progress with a Contact > > > header as soon as they receive an INVITE that they are going > > > to handle and might > > > contain > > > an incomplete number". Presumably this is to allow the UAC to > > > build a ROUTE so > > > that subsequent > > > INVITEs get to the appropriate UAS. Sect 7.2.3 indicates that > > > a node receiving a > > > 183 prior to generating > > > an ACM should generate an ACM. Applied together these rules > > > may cause a prior > > > node to never > > > send on any subsequent digits and overlap sending would fail. > > > > > > I think an approach is required whereby subsequent digits are > > > sent on the same > > > call leg as the > > > initial INVITE; either multiple INVITEs are allowed before > > > 200 OK (already > > > suggested by J. Rosenberg > > > in a different context) , or the INFO method is used. In both > > > cases the TO field > > > will have to remain the > > > same so a new header (or message body type) is required to > > > convey the digits. > > > Also, replace the 484 > > > with, say, 18X indicating the minimum number of digits > > > required, perhaps in the > > > Reason-Phrase header. > > > > > > Regards, > > > > > > Keith Robinson. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Joshua Moloney" on > > 31/01/2001 10:49:33 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: sip@lists.bell-labs.com > > > > > > cc: (bcc: Keith Robinson/MAIN/MC1) > > > > > > > > > > > > Subject: [SIP] Overlap call setup > > > > > > > > > > > > > > > > > > > > > > > > > > > Greetings, > > > > > > I would like to ask for clarification regarding the > > implementation of > > > Overlap. > > > > > > I'll begin by referring to paragraph 3, section 6.1.2 of > > > "draft-ietf-isup-sip-00": > > > > > > It is stated that INVITEs sent after the first one > > > (containing extra digits > > > in the 'To' field) are to be treated as new Call-Legs, seeing as > the > > > contents of their 'To' headers differ. As such, there is no > > > relationship > > > between their CSeq values. > > > > > > If this is the case, how is it possible to ensure correct > > > digit ordering > > > over an 'unreliable' transport layer like UDP? It would seem > > > logical that > > > the call originator _would_ use contiguous CSeq values, as > > it would be > > > 'aware' of the fact that the INVITEs are for the same call. > > > > > > I believe that this issue was raised on the SIP list on 19 > > > November 1999 by > > > Gonzalo C and Jonathan R. The subject of the messages was > > > "Re: Comments on > > > draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of > > > the exchange > > > appeared to be an agreement that CSeq ordering should be employed. > > > > > > > However, does this in any way imply that under such > > circumstances the > > > INVITEs would/should belong to the same Call-Leg? After all, > > > the concept of > > > Overlap does not seem to 'fit in' with the concept behind > > > multiple Call-Legs > > > anyway. > > > > > > If there has been a change in thinking behind the problem, > > > and the latest > > > draft is correct, please could you explain how the ordering > > > problem will be > > > overcome. If not, perhaps the draft needs modification to > > > include these > > > considerations... > > > > > > > > > Regards, > > > > > > Josh Moloney > > > > > > > > > > --------------0F424C7291C4325EDD9A8C27 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 --------------0F424C7291C4325EDD9A8C27-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 10:44:15 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29578 for ; Thu, 1 Feb 2001 10:44:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 520D64434A; Thu, 1 Feb 2001 09:44:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 38BBE4434F for ; Thu, 1 Feb 2001 09:42:45 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 1 Feb 2001 10:36:46 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 1 Feb 2001 10:36:22 -0500 Message-ID: <28560036253BD41191A10000F8BCBD11038E3D36@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Christer Holmberg Cc: Keith Robinson , sip@lists.bell-labs.com, "Joshua Moloney" Subject: RE: [SIP] Overlap call setup MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08C64.B28F7C20" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 10:36:08 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08C64.B28F7C20 Content-Type: text/plain; charset="ISO-8859-1" Your flow is not what I had in mind. I'll try to make myself clearer by commenting on your flow. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Thursday, February 01, 2001 10:10 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > [MDN05:CT07:EXCH] > Subject: Re: [SIP] Overlap call setup > > > > Hi, > > >I see the disconnect here. You are assuming that the first IAM gets > >propagated through the egress gateway, so an ISUP state > machine is set > >into play. I think the synthesis of our thinking is this: > > > >(1) The first problem is to receive enough digits so an > egress gateway > >can be selected. Until that happens, the digits have to be > >accumulated into successive initial INVITE messages. > > > >(2) Once an egress gateway has been selected, call routing > is complete > >as far as the SIP domain is concerned. Hence it is legitimate to use > >the INFO method to carry subsequent digits. > > Let's assume the following case (hopefully I understood you > correctly): > > You want to call 12345 on the PSTN side, and in the first INVITE you > only send the first digit, ie. > > INVITE 1@pstnGW.com > > The GW returns 484, which you ACK. [PTT] No. The GW NEVER sends 484 because as far as SIP is concerned, call routing was successful if the call got as far as the GW. Instead, a proxy returns 484. > Then you start sending digits with INFO, ie. > > INFO 1@pstnGW.com > more-digit: 23 [PTT] Assuming it was a proxy that returned the 484, instead I send another initial INVITE: INVITE 123@pstnGW.com > > The GW returns 200, and we may send more INFOs with the rest of the > digits. [PTT] Assume this time there were enough digits to route the call successfully to a UAS at the GW. It would return something like a 183 Session Progress to provide a Contact and establish the call state machine. The ingress GW would send additional digits (and possibly encapsulated SAM messages) via INFO. The egress GW would start propagating the SAM messages once it had enough digits to select next hop, but this process would be invisible to the ingress GW. The ACM would be sent back in a 180 or 183 interim response as appropriate, and ANM would come back in the 200 OK. > > Now: > > 1. How do we know when the call is established? Since we have sent a > final response to the INVITE, we can't send a 200 OK to it. > > 2. When all the digits have reached the PSTN network, there > may be some > early media/alerting messages etc. to be sent, but again - > since the GW > has sent a final response to the INVITE, 18x provisional > responses can't > be sent. > > What do you think about the following: Instead of sending 484, the GW > sends some provisional response (ie. 186 More digits needed). Then we > use INFO messages(s) to provide the rest of the digits, and when all > digits have reached the PSTN side, and the call can be established, we > receive the 200 OK to the INVITE. > > > Regards, > > Christer Holmberg > Ericsson Finland > > ------_=_NextPart_001_01C08C64.B28F7C20 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Overlap call setup

Your flow is not what I had in mind.  I'll try = to make myself clearer by commenting on your flow.

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: Thursday, February 01, 2001 10:10 = AM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: Keith Robinson; sip@lists.bell-labs.com; = Moloney, Joshua
> [MDN05:CT07:EXCH]
> Subject: Re: [SIP] Overlap call setup
>
>
>
> Hi,
>
> >I see the disconnect here.  You are = assuming that the first IAM gets
> >propagated through the egress gateway, so = an ISUP state
> machine is set
> >into play.  I think the synthesis of = our thinking is this:
> >
> >(1) The first problem is to receive enough = digits so an
> egress gateway
> >can be selected.  Until that happens, = the digits have to be
> >accumulated into successive initial INVITE = messages.
> >
> >(2) Once an egress gateway has been = selected, call routing
> is complete
> >as far as the SIP domain is = concerned.  Hence it is legitimate to use
> >the INFO method to carry subsequent = digits.
>
> Let's assume the following case (hopefully I = understood you
> correctly):
>
> You want to call 12345 on the PSTN side, and in = the first INVITE you
> only send the first digit, ie.
>
> INVITE 1@pstnGW.com
>
> The GW returns 484, which you ACK.

[PTT]
No.  The GW NEVER sends 484 because as far as = SIP is concerned, call routing was successful if the call got as far as = the GW.  Instead, a proxy returns 484.

> Then you start sending digits with INFO, ie. =
>
> INFO 1@pstnGW.com
> more-digit: 23

[PTT]
Assuming it was a proxy that returned the 484, = instead I send another initial INVITE:

  INVITE 123@pstnGW.com
>
> The GW returns 200, and we may send more INFOs = with the rest of the
> digits.

[PTT]
Assume this time there were enough digits to route = the call successfully to a UAS at the GW.  It would return = something like a 183 Session Progress to provide a Contact and = establish the call state machine.  The ingress GW would send = additional digits (and possibly encapsulated SAM messages) via INFO.&nbs= p; The egress GW would start propagating the SAM messages once it had = enough digits to select next hop, but this process would be invisible = to the ingress GW.  The ACM would be sent back in a 180 or 183 = interim response as appropriate, and ANM would come back in the 200 = OK.

>
> Now:
>
> 1. How do we know when the call is established? = Since we have sent a
> final response to the INVITE, we can't send a = 200 OK to it.
>
> 2. When all the digits have reached the PSTN = network, there
> may be some
> early media/alerting messages etc. to be sent, = but again -
> since the GW
> has sent a final response to the INVITE, 18x = provisional
> responses can't
> be sent.
>
> What do you think about the following: Instead = of sending 484, the GW
> sends some provisional response (ie. 186 More = digits needed). Then we
> use INFO messages(s) to provide the rest of the = digits, and when all
> digits have reached the PSTN side, and the call = can be established, we
> receive the 200 OK to the INVITE.
>
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>

------_=_NextPart_001_01C08C64.B28F7C20-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 10:58:01 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29744 for ; Thu, 1 Feb 2001 10:57:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6E9654437C; Thu, 1 Feb 2001 09:51:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id A9FB644341 for ; Thu, 1 Feb 2001 09:50:33 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qhars002.nortel.com; Thu, 1 Feb 2001 15:49:31 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Feb 2001 15:49:29 -0000 Message-ID: From: "Mark Watson" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08C66.8D215A60" Subject: [SIP] SIP Privacy Draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 15:49:24 -0000 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_01C08C66.8D215A60 Content-Type: text/plain; charset="iso-8859-1" All, I sent some comments on this draft to the list in December. Below is an update to these comments based on some off-line discussions. (The draft itself is at http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-00.txt) Five enhancements to the draft are proposed: 1) to provide full support for European regulatory requirements (which are doubtless duplicated in other markets) relating to Caller Identity 2) to include identity information relating to multiple types of party involved in the session 3) to include multiple types of identity information about each party 4) to make privacy handling generic 5) to include location information The basic object is to make Remote-Party-ID a general purpose header which can be used for any type of identity information requiring standard privacy and authenticity handling. More details are below. If there is support for these kind of enhancements, I will come up with a detailed proposal. 1) Regulatory requirements It's required in some markets to make a distinction between identity information which the user has explicitly requested be kept secret, and identity information which cannot be released for some other reason (usually Data Protection). It's proposed to add this distinction by having two 'witheld' indications, one for 'user witheld' and another for 'network witheld'. 2)Types of Party There are many types of party that could be involved in a call/session. We should be capable of providing information about any/all of them and be easily able to add more if required. Support for the following types is suggested as a starting point: i) Calling Party ii) Called Party (whose terminal is alerting) iii) Connected party (who answers the call) Whilst these three types of party can be derived from the context (INVITE implies (i), 1xx => (ii) and 2xx => (iii)), it would be valuable to include an explicit indication of the party type so that new types can easily be added in future. For example, diversion services could use this header to indicate the redirecting and redirecting-to parties thereby taking advantage of generic privacy/authenticity handling (see (4) below). These other identity types could be addressed in the appropriate I-D defining the diversion service. 3) Types of identity A party involved in a session may have several kinds of identity. Support should be provided for signalling any/all of them: i) Subscriber identity - who owns the network subscription under which the session is being established ii) User identity - a human being iii) Display/Alias identity - the identity that the party wishes to be known as iv) Return identity - the identity to be used to contact the party (e.g. to establish a return call/session) v) Terminal identity In many practical scenarios one or all of these identities are in fact the same and the same as the User identity, and so all do not need to be signalled separately. In any given application scenario it should be specified what these identities refer to. 4) Handling of privacy requirements The above implies that the Remote-Party-ID header could be repeated to specify multiple parties and multiple types of identity for each party. Because of this the privacy handling should be on a per-Remote-Party-ID basis - i.e. by tags in the header, not a separate Anonymity header. Privacy handling can also be carried out by proxies without an understanding of the party type or identity type. Basically, if the message is to be sent to an 'untrusted' entity, private information is encrypted or removed. If it is to be sent to a 'trusted' entity, the information is forwarded unchanged. So, the header becomes a generic mechanism for any identity information with privacy requirements. We can add new identity types as these become necessary for new services, and get the privacy handling for free. Similarly, authenticity handling can be made generic. Specifically, if information is received from an untrusted source, the proxy marks it 'verified' or 'unverified' based on its own ability to verify the information. If information is received from a trusted source, the verification markings are left unchanged. 5) Location Information A further type of Party information is the physical location of the Party. This is useful for calls to emergency service centers and for geographic routing services. There is apparantly a URL format for geographic location, so this could be used for this purpose. Regards, Mark Watson Nortel Networks mwatson@nortelnetworks.com ------_=_NextPart_001_01C08C66.8D215A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP Privacy Draft

All,

I sent some comments on this = draft to the list in December. Below is an update to these comments = based on some off-line discussions. (The draft itself is at http://www.ietf.org/internet-drafts/draft-ietf-sip-pri= vacy-00.txt)

Five enhancements to the draft = are proposed:
1) to provide full support for = European regulatory requirements (which are doubtless duplicated in = other markets) relating to Caller Identity

2) to include identity = information relating to multiple types of party involved in the = session
3) to include multiple types of = identity information about each party
4) to make privacy handling = generic
5) to include location = information

The basic object is to make = Remote-Party-ID a general purpose header which can be used for any type = of identity information requiring standard privacy and authenticity = handling.

More details are below. If there = is support for these kind of enhancements, I will come up with a = detailed proposal.

1) Regulatory = requirements

It's required in some markets to = make a distinction between identity information which the user has = explicitly requested be kept secret, and identity information which = cannot be released for some other reason (usually Data Protection). = It's proposed to add this distinction by having two 'witheld' = indications, one for 'user witheld' and another for 'network = witheld'.

2)Types of Party

There are many types of party = that could be involved in a call/session. We should be capable of = providing information about any/all of them and be easily able to add = more if required. Support for the following types is suggested as a = starting point:

i) Calling Party
ii) Called Party (whose = terminal is alerting)
iii) Connected party (who = answers the call)

Whilst these three types of = party can be derived from the context (INVITE implies (i), 1xx =3D> = (ii) and 2xx =3D> (iii)), it would be valuable to include an = explicit indication of the party type so that new types can easily be = added in future.

For example, diversion services = could use this header to indicate the redirecting and redirecting-to = parties thereby taking advantage of generic privacy/authenticity = handling (see (4) below). These other identity types could be addressed = in the appropriate I-D defining the diversion service.

3) Types of identity

A party involved in a session = may have several kinds of identity. Support should be provided for = signalling any/all of them:

i) Subscriber identity - who = owns the network subscription under which the session is being = established
ii) User identity - a human = being
iii) Display/Alias identity - = the identity that the party wishes to be known as
iv) Return identity - the = identity to be used to contact the party (e.g. to establish a return = call/session)
v) Terminal identity

In many practical scenarios one = or all of these identities are in fact the same and the same as the = User identity, and so all do not need to be signalled separately. In = any given application scenario it should be specified what these = identities refer to.

4) Handling of privacy = requirements

The above implies that the = Remote-Party-ID header could be repeated to specify multiple parties = and multiple types of identity for each party. Because of this the = privacy handling should be on a per-Remote-Party-ID basis - i.e. by = tags in the header, not a separate Anonymity header.

Privacy handling can also be = carried out by proxies without an understanding of the party type or = identity type. Basically, if the message is to be sent to an = 'untrusted' entity, private information is encrypted or removed. If it = is to be sent to a 'trusted' entity, the information is forwarded = unchanged.

So, the header becomes a generic = mechanism for any identity information with privacy requirements. We = can add new identity types as these become necessary for new services, = and get the privacy handling for free.

Similarly, authenticity handling = can be made generic. Specifically, if information is received from an = untrusted source, the proxy marks it 'verified' or 'unverified' based = on its own ability to verify the information. If information is = received from a trusted source, the verification markings are left = unchanged.

5) Location Information

A further type of Party = information is the physical location of the Party. This is useful for = calls to emergency service centers and for geographic routing services. = There is apparantly a URL format for geographic location, so this could = be used for this purpose.

Regards,

Mark Watson
Nortel Networks
mwatson@nortelnetworks.com

------_=_NextPart_001_01C08C66.8D215A60-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 11:11:42 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00149 for ; Thu, 1 Feb 2001 11:11:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 803464439E; Thu, 1 Feb 2001 10:01:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53]) by lists.bell-labs.com (Postfix) with ESMTP id D722444341 for ; Thu, 1 Feb 2001 10:00:09 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 1 Feb 2001 15:59:29 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id PAA22231; Thu, 1 Feb 2001 15:59:45 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569E6.0057D46A ; Thu, 1 Feb 2001 15:59:20 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: "Tom-PT Taylor" Cc: sip@lists.bell-labs.com, "Joshua Moloney" Message-ID: <802569E6.0057D2BB.00@marconicomms.com> Subject: RE: [SIP] Overlap call setup Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=oHScFeRjpHXvXx5L4tzssZyYUX2GnhVfLCuFC0eln3phR8ITjDMv5Ikv" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 15:59:25 +0000 --0__=oHScFeRjpHXvXx5L4tzssZyYUX2GnhVfLCuFC0eln3phR8ITjDMv5Ikv Content-type: text/plain; charset=us-ascii Content-Disposition: inline I agree with both of your statements. In case (1), I do think it would be useful if the 484 message could indicate the minimum number of subsequent digits required, and perhaps the maximum, if the UAS knew such things. This would cut down the number of subsequent initial INVITEs. In case (2), we need to specify the message that goes back to the ingress gateway indicating that SIP routing is complete so subsequent digits may be sent in INFO messages. I don't think this can be 200 OK as the call is not yet established, so a 1XX response seems the most appropriate. This mechanism differs from that detailed in sip-isup-00.txt, but I do believe it is more appropriate. Regards, K. Robinson "Tom-PT Taylor" on 01/02/2001 14:08:34 To: Keith Robinson/MAIN/MC1@MCMAIN cc: sip@lists.bell-labs.com, "Joshua Moloney" Subject: RE: [SIP] Overlap call setup I see the disconnect here. You are assuming that the first IAM gets propagated through the egress gateway, so an ISUP state machine is set into play. I think the synthesis of our thinking is this: (1) The first problem is to receive enough digits so an egress gateway can be selected. Until that happens, the digits have to be accumulated into successive initial INVITE messages. (2) Once an egress gateway has been selected, call routing is complete as far as the SIP domain is concerned. Hence it is legitimate to use the INFO method to carry subsequent digits. > -----Original Message----- > From: Keith Robinson [mailto:Keith.Robinson@marconi.com] > Sent: Thursday, February 01, 2001 4:05 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: sip@lists.bell-labs.com; Moloney, Joshua [MDN05:CT07:EXCH] > Subject: RE: [SIP] Overlap call setup > > > > > If the SIP side of the gateway is retaining state then the > UAS side has to know > that the subsequent > digits have to be sent to the same call state machine (on the > ISUP side) as the > original digits. If you > choose a different UAS, and the INVITE containing susequent > digits is treated as > a new call attempt > by this UAS, how does it know which state machine on the ISUP > side to send the > digits to. I'm thinking > of a configuration where there exists a farm of UAS for > scalability and load > distribution. > > Originally, I did say that sending 484 and completely > forgetting about the call > would work, I just don't think > it is the best way; the original state machine on the ISUP > side would probably > time out if it received no > further digits and a new state machine created by the > subsequent INVITE would > now handle the call. > > In the case of 11.3 in the sip-isup document, then the > subsequent INVITEs must > arrive at the same gateway, > otherwise unnecessary IAMs are generated. This is pointed out > in the text. > > Regards, > > K. Robinson > > > > > > > > "Tom-PT Taylor" on 31/01/2001 18:31:11 > > > > > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > cc: sip@lists.bell-labs.com, "Joshua Moloney" > > > > > Subject: RE: [SIP] Overlap call setup > > > > > > > > > I think you've made one assumption I might question. Assuming that > subsequent INVITEs are being sent, containing all of the digits so far > collected, so that they are self-contained: why is it > necessary that each > ends up at the same UAS? When the 484 is sent back, call > state should be > cleared all along the path, even in the SIP-UAC side of the > ingress gateway. > Only the ISUP side of that gateway and, I suppose, the > ISUP-SIP interworking > function, should retain call state. > > > -----Original Message----- > > From: Keith Robinson [mailto:Keith.Robinson@marconi.com] > > Sent: Wednesday, January 31, 2001 11:34 AM > > To: Moloney, Joshua [MDN05:CT07:EXCH] > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > I have recently been trying to get clarification on the > > implemenation of > > overlap sending; see attached for the discussion that has > taken place > > so far. > > > > Certainly, the mechanism outlined (very sketchily) in > > RFC2543bis-02 sect 4.2.1 > > is fundamentally flawed. The Request-URI cannot be used to > > carry extra digits > > as the Record-Route/Route mechanism would end up > overwriting the R-URI > > and therefore the subsequent digits would be lost. > > > > This then leads to the idea of using the TO field as described in > > sip-isup-00-00.txt; > > however, I have the following issues with the mechanisms > > described in this > > document : > > > > As the TO field is different on each subsequent INVITE, then > > it is a new call > > leg > > on an existing call id; RFC2543bis-02 sect. 11.5 does not > > state what a UAS > > should make of this. If you follow the logic in 11.5 you get > > to case (3), but > > here it only defines the behaviour if the TO and FROM fields match. > > > > The 484 sent backwards kills that call attempt (but not the > > state for that > > Call-Id - > > is this problematic for intermediate proxies ?) so subsequent > > INVITEs will > > actually be initial INVITEs. As these INVITEs must get to the > > same terminating > > UAS, > > the originating UAC will have to create a ROUTE header in an > > initial INVITE > > using , > > at least the CONTACT address from the 484. This implies the > > use of source > > routing, an > > issue that I don't believe has been fully resolved, and even > > if it is and > > becomes part > > of the base protocol some administrations may be reluctant to > > admit initial > > INVITEs > > which try to circumvent their routing policy, so may reject > > such INVITEs. > > > > Also on the above point, the CONTACT address in the 484 must > > have the same > > semantics as that in a 200 response so that a ROUTE header > > can be built; however > > RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in > > 4XX responses > > indicates a location where additional error information can > > be found. Indeed, in > > a recent > > thread entitled Announcements in SIP (401 & 407 Contact) J. > > Rosenberg believes > > that > > Record-Route does not make sense in any non-200 response. > > > > I would raise the question of whether the 484 response has > > any use in overlap > > sending > > (certainly in the case of ISUP) at all. If a node receives > > insufficient digits > > to decode than it will wait until it receives some more from > > the preceding node > > (or end of > > dialling timers mature). If the preceding node receives > > subsequent digits and > > end of dialling > > has not been detected then it will pass them on. If the 484 > > indicated the > > minimum number of > > digits before a decode could take place, then it would be > > useful in cutting down > > the number > > of subseqent messages sent. > > > > Indeed, isup-sip-00.txt does cover the mechanism where a 183 > > is sent, and not a > > 484. > > The case in point is covered in sect. 11.3 (Example of SIP > > bridging and overlap > > signalling); > > However, I have the following issues with this mechanism: > > > > As before relies on source routing. > > > > Relies on proxies sending requests on new call legs but > > existing call-ids to the > > same > > downstream server; fine if you administer these proxies, what > > if you don't ? > > (Lots of > > wasted IAMs generated). The mechanism should not send 5 > > (subsequent INVITE) > > until it has received an acknowledgement (probably not 100) > > from the first. > > Alternatively, > > the Reason-Phrase could detail more specifically the exact > > progress of the call > > ("Decoding Address" > > in this case ?) so that the ACM is not generated unconditionally. > > > > Sect. 11.2 encourages gateways "to return a183 Session > > Progress with a Contact > > header as soon as they receive an INVITE that they are going > > to handle and might > > contain > > an incomplete number". Presumably this is to allow the UAC to > > build a ROUTE so > > that subsequent > > INVITEs get to the appropriate UAS. Sect 7.2.3 indicates that > > a node receiving a > > 183 prior to generating > > an ACM should generate an ACM. Applied together these rules > > may cause a prior > > node to never > > send on any subsequent digits and overlap sending would fail. > > > > I think an approach is required whereby subsequent digits are > > sent on the same > > call leg as the > > initial INVITE; either multiple INVITEs are allowed before > > 200 OK (already > > suggested by J. Rosenberg > > in a different context) , or the INFO method is used. In both > > cases the TO field > > will have to remain the > > same so a new header (or message body type) is required to > > convey the digits. > > Also, replace the 484 > > with, say, 18X indicating the minimum number of digits > > required, perhaps in the > > Reason-Phrase header. > > > > Regards, > > > > Keith Robinson. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Joshua Moloney" on > 31/01/2001 10:49:33 > > > > > > > > > > > > > > > > > > > > > > > > To: sip@lists.bell-labs.com > > > > cc: (bcc: Keith Robinson/MAIN/MC1) > > > > > > > > Subject: [SIP] Overlap call setup > > > > > > > > > > > > > > > > > > Greetings, > > > > I would like to ask for clarification regarding the > implementation of > > Overlap. > > > > I'll begin by referring to paragraph 3, section 6.1.2 of > > "draft-ietf-isup-sip-00": > > > > It is stated that INVITEs sent after the first one > > (containing extra digits > > in the 'To' field) are to be treated as new Call-Legs, seeing as the > > contents of their 'To' headers differ. As such, there is no > > relationship > > between their CSeq values. > > > > If this is the case, how is it possible to ensure correct > > digit ordering > > over an 'unreliable' transport layer like UDP? It would seem > > logical that > > the call originator _would_ use contiguous CSeq values, as > it would be > > 'aware' of the fact that the INVITEs are for the same call. > > > > I believe that this issue was raised on the SIP list on 19 > > November 1999 by > > Gonzalo C and Jonathan R. The subject of the messages was > > "Re: Comments on > > draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of > > the exchange > > appeared to be an agreement that CSeq ordering should be employed. > > > > However, does this in any way imply that under such > circumstances the > > INVITEs would/should belong to the same Call-Leg? After all, > > the concept of > > Overlap does not seem to 'fit in' with the concept behind > > multiple Call-Legs > > anyway. > > > > If there has been a change in thinking behind the problem, > > and the latest > > draft is correct, please could you explain how the ordering > > problem will be > > overcome. If not, perhaps the draft needs modification to > > include these > > considerations... > > > > > > Regards, > > > > Josh Moloney > > > > > > --0__=oHScFeRjpHXvXx5L4tzssZyYUX2GnhVfLCuFC0eln3phR8ITjDMv5Ikv Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1Mi4zNSI+DQo8VElUTEU+UkU6IFtT SVBdIE92ZXJsYXAgY2FsbCBzZXR1cDwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZP TlQgU0laRT0yPkkgc2VlIHRoZSBkaXNjb25uZWN0IGhlcmUuJm5ic3A7IFlvdSBhcmUgYXNzdW1p bmcgdGhhdCB0aGUgZmlyc3QgSUFNIGdldHMgcHJvcGFnYXRlZCB0aHJvdWdoIHRoZSBlZ3Jlc3Mg Z2F0ZXdheSwgc28gYW4gSVNVUCBzdGF0ZSBtYWNoaW5lIGlzIHNldCBpbnRvIHBsYXkuJm5ic3A7 IEkgdGhpbmsgdGhlIHN5bnRoZXNpcyBvZiBvdXIgdGhpbmtpbmcgaXMgdGhpczo8L0ZPTlQ+PC9Q Pg0KDQo8UD48Rk9OVCBTSVpFPTI+KDEpIFRoZSBmaXJzdCBwcm9ibGVtIGlzIHRvIHJlY2VpdmUg ZW5vdWdoIGRpZ2l0cyBzbyBhbiBlZ3Jlc3MgZ2F0ZXdheSBjYW4gYmUgc2VsZWN0ZWQuJm5ic3A7 IFVudGlsIHRoYXQgaGFwcGVucywgdGhlIGRpZ2l0cyBoYXZlIHRvIGJlIGFjY3VtdWxhdGVkIGlu dG8gc3VjY2Vzc2l2ZSBpbml0aWFsIElOVklURSBtZXNzYWdlcy48L0ZPTlQ+PC9QPg0KDQo8UD48 Rk9OVCBTSVpFPTI+KDIpIE9uY2UgYW4gZWdyZXNzIGdhdGV3YXkgaGFzIGJlZW4gc2VsZWN0ZWQs IGNhbGwgcm91dGluZyBpcyBjb21wbGV0ZSBhcyBmYXIgYXMgdGhlIFNJUCBkb21haW4gaXMgY29u Y2VybmVkLiZuYnNwOyBIZW5jZSBpdCBpcyBsZWdpdGltYXRlIHRvIHVzZSB0aGUgSU5GTyBtZXRo b2QgdG8gY2Fycnkgc3Vic2VxdWVudCBkaWdpdHMuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0la RT0yPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsgRnJvbTogS2VpdGggUm9iaW5zb24gWzxBIEhSRUY9Im1haWx0bzpLZWl0aC5Sb2Jp bnNvbkBtYXJjb25pLmNvbSI+bWFpbHRvOktlaXRoLlJvYmluc29uQG1hcmNvbmkuY29tPC9BPl08 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDAx LCAyMDAxIDQ6MDUgQU08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgVG86IFRheWxvciwg VG9tLVBUIFtOT1JTRTpCOTAxOkVYQ0hdPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IENj OiBzaXBAbGlzdHMuYmVsbC1sYWJzLmNvbTsgTW9sb25leSwgSm9zaHVhIFtNRE4wNTpDVDA3OkVY Q0hdPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFN1YmplY3Q6IFJFOiBbU0lQXSBPdmVy bGFwIGNhbGwgc2V0dXA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IElm IHRoZSBTSVAgc2lkZSBvZiB0aGUgZ2F0ZXdheSBpcyByZXRhaW5pbmcgc3RhdGUgdGhlbiB0aGUg PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFVBUyBzaWRlIGhhcyB0byBrbm93PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHRoYXQgdGhlIHN1YnNlcXVlbnQ8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZndDsgZGlnaXRzIGhhdmUgdG8gYmUgc2VudCB0byB0aGUgc2FtZSBjYWxs IHN0YXRlIG1hY2hpbmUgKG9uIHRoZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgSVNV UCBzaWRlKSBhcyB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgb3JpZ2luYWwgZGln aXRzLiBJZiB5b3U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgY2hvb3NlIGEgZGlmZmVy ZW50IFVBUywgYW5kIHRoZSBJTlZJVEUgY29udGFpbmluZyBzdXNlcXVlbnQgPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7IGRpZ2l0cyBpcyB0cmVhdGVkIGFzPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IGEgbmV3IGNhbGwgYXR0ZW1wdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyBieSB0aGlzIFVBUywgaG93IGRvZXMgaXQga25vdyB3aGljaCBzdGF0ZSBtYWNoaW5lIG9u IHRoZSBJU1VQIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBzaWRlIHRvIHNlbmQgdGhl PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRpZ2l0cyB0by4gSSdtIHRoaW5raW5nPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IG9mIGEgY29uZmlndXJhdGlvbiB3aGVyZSB0aGVy ZSBleGlzdHMgYSBmYXJtIG9mIFVBUyBmb3IgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 IHNjYWxhYmlsaXR5IGFuZCBsb2FkPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRpc3Ry aWJ1dGlvbi48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IE9yaWdpbmFsbHksIEkgZGlkIHNheSB0aGF0IHNlbmRpbmcgNDg0IGFuZCBj b21wbGV0ZWx5IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBmb3JnZXR0aW5nIGFib3V0 IHRoZSBjYWxsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHdvdWxkIHdvcmssIEkganVz dCBkb24ndCB0aGluazwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBpdCBpcyB0aGUgYmVz dCB3YXk7IHRoZSBvcmlnaW5hbCBzdGF0ZSBtYWNoaW5lIG9uIHRoZSBJU1VQIDwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyBzaWRlIHdvdWxkIHByb2JhYmx5PC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IHRpbWUgb3V0IGlmIGl0IHJlY2VpdmVkIG5vPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IGZ1cnRoZXIgZGlnaXRzIGFuZCBhIG5ldyBzdGF0ZSBtYWNoaW5lIGNyZWF0 ZWQgYnkgdGhlIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBzdWJzZXF1ZW50IElOVklU RSB3b3VsZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBub3cgaGFuZGxlIHRoZSBjYWxs LjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgSW4gdGhlIGNhc2Ugb2YgMTEuMyBpbiB0aGUgc2lwLWlzdXAgZG9jdW1lbnQsIHRoZW4g dGhlIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBzdWJzZXF1ZW50IElOVklURXMgbXVz dDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBhcnJpdmUgYXQgdGhlIHNhbWUgZ2F0ZXdh eSw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgb3RoZXJ3aXNlIHVubmVjZXNzYXJ5IElB TXMgYXJlIGdlbmVyYXRlZC4gVGhpcyBpcyBwb2ludGVkIG91dCA8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDsgaW4gdGhlIHRleHQuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBSZWdhcmRzLDwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgSy4gUm9iaW5zb248L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj4mZ3Q7ICZxdW90O1RvbS1QVCBUYXlsb3ImcXVvdDsgJmx0O3RheWxvckBub3J0 ZWxuZXR3b3Jrcy5jb20mZ3Q7IG9uIDMxLzAxLzIwMDEgMTg6MzE6MTE8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyZuYnNwOyBUbzombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgS2VpdGggUm9iaW5z b24vTUFJTi9NQzFATUNNQUlOJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsmbmJzcDsgY2M6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNpcEBsaXN0 cy5iZWxsLWxhYnMuY29tLCAmcXVvdDtKb3NodWEgTW9sb25leSZxdW90OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2ptb2xvbmV5QG5vcnRlbG5ldHdvcmtzLmNvbSZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mZ3Q7Jm5ic3A7IFN1YmplY3Q6IFJFOiBbU0lQXSBPdmVybGFwIGNhbGwgc2V0dXAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgSSB0aGluayB5b3UndmUg bWFkZSBvbmUgYXNzdW1wdGlvbiBJIG1pZ2h0IHF1ZXN0aW9uLiZuYnNwOyBBc3N1bWluZyB0aGF0 PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHN1YnNlcXVlbnQgSU5WSVRFcyBhcmUgYmVp bmcgc2VudCwgY29udGFpbmluZyBhbGwgb2YgdGhlIGRpZ2l0cyBzbyBmYXI8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZndDsgY29sbGVjdGVkLCBzbyB0aGF0IHRoZXkgYXJlIHNlbGYtY29udGFp bmVkOiB3aHkgaXMgaXQgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IG5lY2Vzc2FyeSB0 aGF0IGVhY2g8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZW5kcyB1cCBhdCB0aGUgc2Ft ZSBVQVM/Jm5ic3A7IFdoZW4gdGhlIDQ4NCBpcyBzZW50IGJhY2ssIGNhbGwgPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7IHN0YXRlIHNob3VsZCBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jmd0OyBjbGVhcmVkIGFsbCBhbG9uZyB0aGUgcGF0aCwgZXZlbiBpbiB0aGUgU0lQLVVBQyBz aWRlIG9mIHRoZSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgaW5ncmVzcyBnYXRld2F5 LjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBPbmx5IHRoZSBJU1VQIHNpZGUgb2YgdGhh dCBnYXRld2F5IGFuZCwgSSBzdXBwb3NlLCB0aGUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m Z3Q7IElTVVAtU0lQIGludGVyd29ya2luZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBm dW5jdGlvbiwgc2hvdWxkIHJldGFpbiBjYWxsIHN0YXRlLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IEZyb206IEtl aXRoIFJvYmluc29uIFs8QSBIUkVGPSJtYWlsdG86S2VpdGguUm9iaW5zb25AbWFyY29uaS5jb20i Pm1haWx0bzpLZWl0aC5Sb2JpbnNvbkBtYXJjb25pLmNvbTwvQT5dPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7ICZndDsgU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDMxLCAyMDAxIDExOjM0 IEFNPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgVG86IE1vbG9uZXksIEpvc2h1 YSBbTUROMDU6Q1QwNzpFWENIXTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IENj OiBzaXBAbGlzdHMuYmVsbC1sYWJzLmNvbTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAm Z3Q7IFN1YmplY3Q6IFJlOiBbU0lQXSBPdmVybGFwIGNhbGwgc2V0dXA8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IEkgaGF2ZSByZWNl bnRseSBiZWVuIHRyeWluZyB0byBnZXQgY2xhcmlmaWNhdGlvbiBvbiB0aGU8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZndDsgJmd0OyBpbXBsZW1lbmF0aW9uIG9mPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7ICZndDsgb3ZlcmxhcCBzZW5kaW5nOyBzZWUgYXR0YWNoZWQgZm9yIHRoZSBk aXNjdXNzaW9uIHRoYXQgaGFzIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB0YWtlbiBw bGFjZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IHNvIGZhci48L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAm Z3Q7IENlcnRhaW5seSwgdGhlIG1lY2hhbmlzbSBvdXRsaW5lZCAodmVyeSBza2V0Y2hpbHkpIGlu PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgUkZDMjU0M2Jpcy0wMiBzZWN0IDQu Mi4xPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgaXMgZnVuZGFtZW50YWxseSBm bGF3ZWQuIFRoZSBSZXF1ZXN0LVVSSSBjYW5ub3QgYmUgdXNlZCB0bzwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyAmZ3Q7IGNhcnJ5IGV4dHJhIGRpZ2l0czwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyAmZ3Q7IGFzIHRoZSBSZWNvcmQtUm91dGUvUm91dGUgbWVjaGFuaXNtIHdvdWxk IGVuZCB1cCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgb3ZlcndyaXRpbmcgdGhlIFIt VVJJPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgYW5kIHRoZXJlZm9yZSB0aGUg c3Vic2VxdWVudCBkaWdpdHMgd291bGQgYmUgbG9zdC48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IFRoaXMgdGhlbiBs ZWFkcyB0byB0aGUgaWRlYSBvZiB1c2luZyB0aGUgVE8gZmllbGQgYXMgZGVzY3JpYmVkIGluPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgc2lwLWlzdXAtMDAtMDAudHh0OzwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGhvd2V2ZXIsIEkgaGF2ZSB0aGUgZm9sbG93 aW5nIGlzc3VlcyB3aXRoIHRoZSBtZWNoYW5pc21zPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m Z3Q7ICZndDsgZGVzY3JpYmVkIGluIHRoaXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg Jmd0OyBkb2N1bWVudCA6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBBcyB0aGUgVE8gZmllbGQgaXMgZGlmZmVyZW50 IG9uIGVhY2ggc3Vic2VxdWVudCBJTlZJVEUsIHRoZW48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgJmd0OyBpdCBpcyBhIG5ldyBjYWxsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 ICZndDsgbGVnPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgb24gYW4gZXhpc3Rp bmcgY2FsbCBpZDsgUkZDMjU0M2Jpcy0wMiBzZWN0LiAxMS41IGRvZXMgbm90PC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgc3RhdGUgd2hhdCBhIFVBUzwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyAmZ3Q7IHNob3VsZCBtYWtlIG9mIHRoaXMuIElmIHlvdSBmb2xsb3cgdGhl IGxvZ2ljIGluIDExLjUgeW91IGdldDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7 IHRvIGNhc2UgKDMpLCBidXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBoZXJl IGl0IG9ubHkgZGVmaW5lcyB0aGUgYmVoYXZpb3VyJm5ic3A7IGlmIHRoZSBUTyBhbmQgRlJPTSBm aWVsZHMgbWF0Y2guPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBUaGUgNDg0IHNlbnQgYmFja3dhcmRzIGtpbGxzIHRo YXQgY2FsbCBhdHRlbXB0IChidXQgbm90IHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0 OyAmZ3Q7IHN0YXRlIGZvciB0aGF0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsg Q2FsbC1JZCAtPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgaXMgdGhpcyBwcm9i bGVtYXRpYyBmb3IgaW50ZXJtZWRpYXRlIHByb3hpZXMgPykgc28gc3Vic2VxdWVudDwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IElOVklURXMgd2lsbDwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyAmZ3Q7IGFjdHVhbGx5IGJlIGluaXRpYWwgSU5WSVRFcy4gQXMgdGhlc2Ug SU5WSVRFcyBtdXN0IGdldCB0byB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0 OyBzYW1lIHRlcm1pbmF0aW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgVUFT LDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IHRoZSBvcmlnaW5hdGluZyZuYnNw OyBVQUMgd2lsbCBoYXZlIHRvIGNyZWF0ZSBhIFJPVVRFIGhlYWRlciBpbiBhbjwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGluaXRpYWwgSU5WSVRFPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7ICZndDsgdXNpbmcgLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAm Z3Q7IGF0IGxlYXN0IHRoZSBDT05UQUNUIGFkZHJlc3MgZnJvbSB0aGUgNDg0LiBUaGlzIGltcGxp ZXMgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgdXNlIG9mIHNvdXJjZTwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IHJvdXRpbmcsIGFuPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgaXNzdWUgdGhhdCBJIGRvbid0IGJlbGlldmUgaGFzIGJl ZW4gZnVsbHkgcmVzb2x2ZWQsIGFuZCBldmVuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 ICZndDsgaWYgaXQgaXMgYW5kPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgYmVj b21lcyBwYXJ0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgb2YgdGhlIGJhc2Ug cHJvdG9jb2wgc29tZSBhZG1pbmlzdHJhdGlvbnMgbWF5IGJlIHJlbHVjdGFudCB0bzwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGFkbWl0IGluaXRpYWw8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgJmd0OyBJTlZJVEVzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 ICZndDsgd2hpY2ggdHJ5IHRvIGNpcmN1bXZlbnQgdGhlaXIgcm91dGluZyBwb2xpY3ksIHNvIG1h eSByZWplY3Q8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBzdWNoIElOVklURXMu PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsgJmd0OyBBbHNvIG9uIHRoZSBhYm92ZSBwb2ludCwgdGhlIENPTlRBQ1QgYWRkcmVz cyBpbiB0aGUgNDg0IG11c3Q8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBoYXZl IHRoZSBzYW1lPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgc2VtYW50aWNzIGFz IHRoYXQgaW4gYSAyMDAgcmVzcG9uc2Ugc28gdGhhdCBhIFJPVVRFIGhlYWRlcjwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGNhbiBiZSBidWlsdDsgaG93ZXZlcjwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IFJGQzI1NDNiaXMtMDIgc2VjdC4gNi4xNCBzcGVjaWZp ZXMgdGhhdCBhIENPTlRBQ1QgYWRkcmVzcyBpbjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0 OyAmZ3Q7IDRYWCByZXNwb25zZXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBp bmRpY2F0ZXMgYSBsb2NhdGlvbiB3aGVyZSBhZGRpdGlvbmFsIGVycm9yIGluZm9ybWF0aW9uIGNh bjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGJlIGZvdW5kLiBJbmRlZWQsIGlu PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgYSByZWNlbnQ8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZndDsgJmd0OyB0aHJlYWQgZW50aXRsZWQgQW5ub3VuY2VtZW50cyBpbiBT SVAgKDQwMSAmYW1wOyA0MDcgQ29udGFjdCkgSi48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsgJmd0OyBSb3NlbmJlcmcgYmVsaWV2ZXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg Jmd0OyB0aGF0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgUmVjb3JkLVJvdXRl IGRvZXMgbm90IG1ha2Ugc2Vuc2UgaW4gYW55IG5vbi0yMDAgcmVzcG9uc2UuPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0 OyBJIHdvdWxkIHJhaXNlIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHRoZSA0ODQgcmVzcG9uc2Ug aGFzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgYW55IHVzZSBpbiBvdmVybGFw PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgc2VuZGluZzwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IChjZXJ0YWlubHkgaW4gdGhlIGNhc2Ugb2YgSVNVUCkgYXQg YWxsLiBJZiBhIG5vZGUgcmVjZWl2ZXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0 OyBpbnN1ZmZpY2llbnQgZGlnaXRzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsg dG8gZGVjb2RlIHRoYW4gaXQgd2lsbCB3YWl0IHVudGlsIGl0IHJlY2VpdmVzIHNvbWUgbW9yZSBm cm9tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgdGhlIHByZWNlZGluZyBub2Rl PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgKG9yIGVuZCBvZjwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGRpYWxsaW5nIHRpbWVycyBtYXR1cmUpLiBJZiB0aGUg cHJlY2VkaW5nIG5vZGUgcmVjZWl2ZXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0 OyBzdWJzZXF1ZW50IGRpZ2l0cyBhbmQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0 OyBlbmQgb2YgZGlhbGxpbmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBoYXMg bm90IGJlZW4gZGV0ZWN0ZWQgdGhlbiBpdCB3aWxsIHBhc3MgdGhlbSBvbi4gSWYgdGhlIDQ4NDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGluZGljYXRlZCB0aGU8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBtaW5pbXVtIG51bWJlciBvZjwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGRpZ2l0cyBiZWZvcmUgYSBkZWNvZGUgY291bGQgdGFrZSBw bGFjZSwgdGhlbiBpdCB3b3VsZCBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7 IHVzZWZ1bCBpbiBjdXR0aW5nIGRvd248L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0 OyB0aGUgbnVtYmVyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgb2Ygc3Vic2Vx ZW50IG1lc3NhZ2VzIHNlbnQuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBJbmRlZWQsIGlzdXAtc2lwLTAwLnR4dCBk b2VzIGNvdmVyIHRoZSBtZWNoYW5pc20gd2hlcmUgYSAxODM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsgJmd0OyBpcyBzZW50LCBhbmQgbm90IGE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgJmd0OyA0ODQuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgVGhlIGNh c2UgaW4gcG9pbnQgaXMgY292ZXJlZCBpbiBzZWN0LiAxMS4zIChFeGFtcGxlIG9mIFNJUDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGJyaWRnaW5nIGFuZCBvdmVybGFwPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgc2lnbmFsbGluZyk7PC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj4mZ3Q7ICZndDsgSG93ZXZlciwgSSBoYXZlIHRoZSBmb2xsb3dpbmcgaXNzdWVz IHdpdGggdGhpcyBtZWNoYW5pc206PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBBcyBiZWZvcmUgcmVsaWVzIG9uIHNv dXJjZSByb3V0aW5nLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgUmVsaWVzIG9uIHByb3hpZXMgc2VuZGluZyByZXF1 ZXN0cyBvbiBuZXcgY2FsbCBsZWdzIGJ1dDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAm Z3Q7IGV4aXN0aW5nIGNhbGwtaWRzIHRvIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0 OyAmZ3Q7IHNhbWU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBkb3duc3RyZWFt IHNlcnZlcjsgZmluZSBpZiB5b3UgYWRtaW5pc3RlciB0aGVzZSBwcm94aWVzLCB3aGF0PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgaWYgeW91IGRvbid0ID88L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZndDsgJmd0OyAoTG90cyBvZjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyAmZ3Q7IHdhc3RlZCBJQU1zIGdlbmVyYXRlZCkuIFRoZSBtZWNoYW5pc20gc2hvdWxkIG5v dCBzZW5kIDU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAoc3Vic2VxdWVudCBJ TlZJVEUpPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgdW50aWwgaXQgaGFzIHJl Y2VpdmVkIGFuIGFja25vd2xlZGdlbWVudCAocHJvYmFibHkgbm90IDEwMCk8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZndDsgJmd0OyBmcm9tIHRoZSBmaXJzdC48L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDsgJmd0OyBBbHRlcm5hdGl2ZWx5LDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyAmZ3Q7IHRoZSBSZWFzb24tUGhyYXNlIGNvdWxkIGRldGFpbCBtb3JlIHNwZWNpZmljYWxs eSB0aGUgZXhhY3Q8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBwcm9ncmVzcyBv ZiB0aGUgY2FsbDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICgmcXVvdDtEZWNv ZGluZyBBZGRyZXNzJnF1b3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgaW4g dGhpcyBjYXNlID8pIHNvIHRoYXQgdGhlIEFDTSBpcyBub3QgZ2VuZXJhdGVkIHVuY29uZGl0aW9u YWxseS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyAmZ3Q7IFNlY3QuIDExLjIgZW5jb3VyYWdlcyBnYXRld2F5cyAmcXVvdDt0 byByZXR1cm4gYTE4MyBTZXNzaW9uPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsg UHJvZ3Jlc3Mgd2l0aCBhIENvbnRhY3Q8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0 OyBoZWFkZXIgYXMgc29vbiBhcyB0aGV5IHJlY2VpdmUgYW4gSU5WSVRFIHRoYXQgdGhleSBhcmUg Z29pbmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyB0byBoYW5kbGUgYW5kIG1p Z2h0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgY29udGFpbjwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGFuIGluY29tcGxldGUgbnVtYmVyJnF1b3Q7LiBQcmVz dW1hYmx5IHRoaXMgaXMgdG8gYWxsb3cgdGhlIFVBQyB0bzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jmd0OyAmZ3Q7IGJ1aWxkIGEgUk9VVEUgc288L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsgJmd0OyB0aGF0IHN1YnNlcXVlbnQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0 OyBJTlZJVEVzIGdldCB0byB0aGUgYXBwcm9wcmlhdGUgVUFTLiBTZWN0IDcuMi4zIGluZGljYXRl cyB0aGF0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgYSBub2RlIHJlY2Vpdmlu ZyBhPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgMTgzIHByaW9yIHRvIGdlbmVy YXRpbmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBhbiBBQ00gc2hvdWxkIGdl bmVyYXRlIGFuIEFDTS4gQXBwbGllZCB0b2dldGhlciB0aGVzZSBydWxlczwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IG1heSBjYXVzZSBhIHByaW9yPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7ICZndDsgbm9kZSB0byBuZXZlcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyAmZ3Q7IHNlbmQgb24gYW55IHN1YnNlcXVlbnQgZGlnaXRzIGFuZCBvdmVybGFwIHNlbmRp bmcgd291bGQgZmFpbC48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IEkgdGhpbmsgYW4gYXBwcm9hY2ggaXMgcmVxdWly ZWQgd2hlcmVieSBzdWJzZXF1ZW50IGRpZ2l0cyBhcmU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgJmd0OyBzZW50IG9uIHRoZSBzYW1lPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 ICZndDsgY2FsbCBsZWcgYXMgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsg aW5pdGlhbCBJTlZJVEU7IGVpdGhlciBtdWx0aXBsZSBJTlZJVEVzIGFyZSBhbGxvd2VkIGJlZm9y ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IDIwMCBPSyAoYWxyZWFkeTwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IHN1Z2dlc3RlZCBieSBKLiBSb3NlbmJlcmc8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBpbiBhIGRpZmZlcmVudCBjb250ZXh0 KSAsIG9yIHRoZSBJTkZPIG1ldGhvZCBpcyB1c2VkLiBJbiBib3RoPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7ICZndDsgY2FzZXMgdGhlIFRPIGZpZWxkPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7ICZndDsgd2lsbCBoYXZlIHRvIHJlbWFpbiB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDsgJmd0OyBzYW1lIHNvIGEgbmV3IGhlYWRlciAob3IgbWVzc2FnZSBib2R5IHR5 cGUpIGlzIHJlcXVpcmVkIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgY29u dmV5IHRoZSBkaWdpdHMuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgQWxzbywg cmVwbGFjZSB0aGUgNDg0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgd2l0aCwg c2F5LCAxOFggaW5kaWNhdGluZyB0aGUgbWluaW11bSBudW1iZXIgb2YgZGlnaXRzPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgcmVxdWlyZWQsIHBlcmhhcHMgaW4gdGhlPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgUmVhc29uLVBocmFzZSBoZWFkZXIuPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsgJmd0OyBSZWdhcmRzLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgS2VpdGggUm9iaW5zb24uPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0 OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7 PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg Jmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyAmcXVv dDtKb3NodWEgTW9sb25leSZxdW90OyAmbHQ7am1vbG9uZXlAbm9ydGVsbmV0d29ya3MuY29tJmd0 OyBvbiA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgMzEvMDEvMjAwMSAxMDo0OTozMzwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZn dDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0 OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgJmd0OyZuYnNwOyBUbzombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgc2lwQGxpc3RzLmJlbGwtbGFicy5jb208L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg Jmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7Jm5ic3A7IGNjOiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoYmNjOiBLZWl0aCBSb2JpbnNvbi9NQUlOL01DMSk8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZndDsgJmd0OyZuYnNwOyBTdWJqZWN0OiBbU0lQXSBPdmVybGFwIGNhbGwg c2V0dXA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7 PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgR3JlZXRpbmdzLDwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZn dDsgSSB3b3VsZCBsaWtlIHRvIGFzayBmb3IgY2xhcmlmaWNhdGlvbiByZWdhcmRpbmcgdGhlIDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBpbXBsZW1lbnRhdGlvbiBvZjwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IE92ZXJsYXAuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBJJ2xsIGJlZ2lu IGJ5IHJlZmVycmluZyB0byBwYXJhZ3JhcGggMywgc2VjdGlvbiA2LjEuMiBvZjwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZxdW90O2RyYWZ0LWlldGYtaXN1cC1zaXAtMDAmcXVv dDs6PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDsgJmd0OyBJdCBpcyBzdGF0ZWQgdGhhdCBJTlZJVEVzIHNlbnQgYWZ0ZXIgdGhl IGZpcnN0IG9uZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IChjb250YWluaW5n IGV4dHJhIGRpZ2l0czwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGluIHRoZSAn VG8nIGZpZWxkKSBhcmUgdG8gYmUgdHJlYXRlZCBhcyBuZXcgQ2FsbC1MZWdzLCBzZWVpbmcgYXMg dGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgY29udGVudHMgb2YgdGhlaXIg J1RvJyBoZWFkZXJzIGRpZmZlci4gQXMgc3VjaCwgdGhlcmUgaXMgbm88L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgJmd0OyByZWxhdGlvbnNoaXA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgJmd0OyBiZXR3ZWVuIHRoZWlyIENTZXEgdmFsdWVzLjwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgSWYgdGhp cyBpcyB0aGUgY2FzZSwgaG93IGlzIGl0IHBvc3NpYmxlIHRvIGVuc3VyZSBjb3JyZWN0PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgZGlnaXQgb3JkZXJpbmc8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZndDsgJmd0OyBvdmVyIGFuICd1bnJlbGlhYmxlJyB0cmFuc3BvcnQgbGF5 ZXIgbGlrZSBVRFA/IEl0IHdvdWxkIHNlZW08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg Jmd0OyBsb2dpY2FsIHRoYXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyB0aGUg Y2FsbCBvcmlnaW5hdG9yIF93b3VsZF8gdXNlIGNvbnRpZ3VvdXMgQ1NlcSB2YWx1ZXMsIGFzIDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBpdCB3b3VsZCBiZTwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyAmZ3Q7ICdhd2FyZScgb2YgdGhlIGZhY3QgdGhhdCB0aGUgSU5WSVRFcyBh cmUgZm9yIHRoZSBzYW1lIGNhbGwuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDs8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBJIGJlbGlldmUgdGhhdCB0aGlzIGlz c3VlIHdhcyByYWlzZWQgb24gdGhlIFNJUCBsaXN0IG9uIDE5PC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7ICZndDsgTm92ZW1iZXIgMTk5OSBieTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyAmZ3Q7IEdvbnphbG8gQyBhbmQgSm9uYXRoYW4gUi4gVGhlIHN1YmplY3Qgb2YgdGhlIG1l c3NhZ2VzIHdhczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7ICZxdW90O1JlOiBD b21tZW50cyBvbjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IGRyYWZ0LWNhbWFy aWxsby1tbXVzaWMtc2lwLWlzdXAtYmNwLTAwLnR4dCZxdW90Oy4gVGhlIG91dGNvbWUgb2Y8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyB0aGUgZXhjaGFuZ2U8L0ZPTlQ+DQo8QlI+ PEZPTlQgU0laRT0yPiZndDsgJmd0OyBhcHBlYXJlZCB0byBiZSBhbiBhZ3JlZW1lbnQgdGhhdCBD U2VxIG9yZGVyaW5nIHNob3VsZCBiZSBlbXBsb3llZC48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IEhvd2V2ZXIsIGRv ZXMgdGhpcyBpbiBhbnkgd2F5IGltcGx5IHRoYXQgdW5kZXIgc3VjaCA8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgY2lyY3Vtc3RhbmNlcyB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PiZndDsgJmd0OyBJTlZJVEVzIHdvdWxkL3Nob3VsZCBiZWxvbmcgdG8gdGhlIHNhbWUgQ2FsbC1M ZWc/IEFmdGVyIGFsbCw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyB0aGUgY29u Y2VwdCBvZjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IE92ZXJsYXAgZG9lcyBu b3Qgc2VlbSB0byAnZml0IGluJyB3aXRoIHRoZSBjb25jZXB0IGJlaGluZDwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IG11bHRpcGxlIENhbGwtTGVnczwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyAmZ3Q7IGFueXdheS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg Jmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IElmIHRoZXJlIGhhcyBiZWVu IGEgY2hhbmdlIGluIHRoaW5raW5nIGJlaGluZCB0aGUgcHJvYmxlbSw8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgJmd0OyBhbmQgdGhlIGxhdGVzdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jmd0OyAmZ3Q7IGRyYWZ0IGlzIGNvcnJlY3QsIHBsZWFzZSBjb3VsZCB5b3UgZXhwbGFpbiBo b3cgdGhlIG9yZGVyaW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgcHJvYmxl bSB3aWxsIGJlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgb3ZlcmNvbWUuIElm IG5vdCwgcGVyaGFwcyB0aGUgZHJhZnQgbmVlZHMgbW9kaWZpY2F0aW9uIHRvPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgaW5jbHVkZSB0aGVzZTwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyAmZ3Q7IGNvbnNpZGVyYXRpb25zLi4uPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7IFJlZ2FyZHMsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9 Mj4mZ3Q7ICZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyBKb3NoIE1vbG9u ZXk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OzwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyAmZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg== --0__=oHScFeRjpHXvXx5L4tzssZyYUX2GnhVfLCuFC0eln3phR8ITjDMv5Ikv-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 11:28:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00578 for ; Thu, 1 Feb 2001 11:28:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C00884434C; Thu, 1 Feb 2001 10:12:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id B15BC4434A for ; Thu, 1 Feb 2001 10:10:55 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA19629; Thu, 1 Feb 2001 08:10:00 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT11746; Thu, 1 Feb 2001 08:09:57 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA29638; Thu, 1 Feb 2001 08:09:57 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14969.35413.204002.806655@thomasm-u1.cisco.com> To: "Henning G. Schulzrinne" Cc: Michael Thomas , William Marshall , jdrosen@dynamicsoft.com, sip@lists.bell-labs.com Subject: Re: [SIP] Some idea on Stateful SIP Proxy for Card Service In-Reply-To: <3A789636.E50C6A15@cs.columbia.edu> References: <200101312209.RAA84628@fish-ha.research.att.com> <14968.37115.842736.948940@thomasm-u1.cisco.com> <3A789636.E50C6A15@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 08:09:57 -0800 (PST) Content-Transfer-Encoding: 7bit Henning G. Schulzrinne writes: > The answering service model can also easily be accomplished by a > ("virtual") UAS that is parallel-forked in the proxy. Thus, even for > those services, a B2BUA is not strictly necessary. [Duh bulb goes on] Yes, I like this idea a lot. > B2BUA, like proxies, can, but don't have to modify SDP. Proxies serving > as part of NAT ALGs may need to, for example. The advantage to what you suggest above is that you cons up a UAS as necessary which still preserves the e2e semantics. This still allows you to authenticate e2e which seems advantageous. While it doesn't mean that the consed up UAS couldn't turn itself into a B2BUA and thus break the e2e semantics, modeling initially as a B2BUA explicitly encourages that which seems like a bad precedent to me. Mike _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 11:36:40 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00761 for ; Thu, 1 Feb 2001 11:36:39 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3518C4439A; Thu, 1 Feb 2001 10:14:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53]) by lists.bell-labs.com (Postfix) with ESMTP id 2747F44394 for ; Thu, 1 Feb 2001 10:12:15 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 1 Feb 2001 16:11:39 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id QAA28444; Thu, 1 Feb 2001 16:11:56 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569E6.0058F184 ; Thu, 1 Feb 2001 16:11:29 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: "Tom-PT Taylor" Cc: Christer Holmberg , sip@lists.bell-labs.com, "Joshua Moloney" Message-ID: <802569E6.0058F0C1.00@marconicomms.com> Subject: RE: [SIP] Overlap call setup Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=x3DwqAZECJbxjMGdDKiITJLEb3PPEBcbkQTX0oxcjFc3Iw5tupPMVqab" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 16:11:38 +0000 --0__=x3DwqAZECJbxjMGdDKiITJLEb3PPEBcbkQTX0oxcjFc3Iw5tupPMVqab Content-type: text/plain; charset=us-ascii Content-Disposition: inline I think there is a general consensus of opinion here (for case (2)); the question is what informational response to send back to the ingress when an egress has been selected. The problem I have with 183 is that following the text in 7.2.3 of sip-isup-00.txt would cause an ACM to be generated at the ingress which I don't think is what we want o do at this point. Regards, K. Robinson "Tom-PT Taylor" on 01/02/2001 15:36:08 To: Christer Holmberg cc: Keith Robinson/MAIN/MC1@MCMAIN, sip@lists.bell-labs.com, "Joshua Moloney" Subject: RE: [SIP] Overlap call setup Your flow is not what I had in mind. I'll try to make myself clearer by commenting on your flow. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Thursday, February 01, 2001 10:10 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > [MDN05:CT07:EXCH] > Subject: Re: [SIP] Overlap call setup > > > > Hi, > > >I see the disconnect here. You are assuming that the first IAM gets > >propagated through the egress gateway, so an ISUP state > machine is set > >into play. I think the synthesis of our thinking is this: > > > >(1) The first problem is to receive enough digits so an > egress gateway > >can be selected. Until that happens, the digits have to be > >accumulated into successive initial INVITE messages. > > > >(2) Once an egress gateway has been selected, call routing > is complete > >as far as the SIP domain is concerned. Hence it is legitimate to use > >the INFO method to carry subsequent digits. > > Let's assume the following case (hopefully I understood you > correctly): > > You want to call 12345 on the PSTN side, and in the first INVITE you > only send the first digit, ie. > > INVITE 1@pstnGW.com > > The GW returns 484, which you ACK. [PTT] No. The GW NEVER sends 484 because as far as SIP is concerned, call routing was successful if the call got as far as the GW. Instead, a proxy returns 484. > Then you start sending digits with INFO, ie. > > INFO 1@pstnGW.com > more-digit: 23 [PTT] Assuming it was a proxy that returned the 484, instead I send another initial INVITE: INVITE 123@pstnGW.com > > The GW returns 200, and we may send more INFOs with the rest of the > digits. [PTT] Assume this time there were enough digits to route the call successfully to a UAS at the GW. It would return something like a 183 Session Progress to provide a Contact and establish the call state machine. The ingress GW would send additional digits (and possibly encapsulated SAM messages) via INFO. The egress GW would start propagating the SAM messages once it had enough digits to select next hop, but this process would be invisible to the ingress GW. The ACM would be sent back in a 180 or 183 interim response as appropriate, and ANM would come back in the 200 OK. > > Now: > > 1. How do we know when the call is established? Since we have sent a > final response to the INVITE, we can't send a 200 OK to it. > > 2. When all the digits have reached the PSTN network, there > may be some > early media/alerting messages etc. to be sent, but again - > since the GW > has sent a final response to the INVITE, 18x provisional > responses can't > be sent. > > What do you think about the following: Instead of sending 484, the GW > sends some provisional response (ie. 186 More digits needed). Then we > use INFO messages(s) to provide the rest of the digits, and when all > digits have reached the PSTN side, and the call can be established, we > receive the 200 OK to the INVITE. > > > Regards, > > Christer Holmberg > Ericsson Finland > > --0__=x3DwqAZECJbxjMGdDKiITJLEb3PPEBcbkQTX0oxcjFc3Iw5tupPMVqab Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1Mi4zNSI+DQo8VElUTEU+UkU6IFtT SVBdIE92ZXJsYXAgY2FsbCBzZXR1cDwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZP TlQgU0laRT0yPllvdXIgZmxvdyBpcyBub3Qgd2hhdCBJIGhhZCBpbiBtaW5kLiZuYnNwOyBJJ2xs IHRyeSB0byBtYWtlIG15c2VsZiBjbGVhcmVyIGJ5IGNvbW1lbnRpbmcgb24geW91ciBmbG93Ljwv Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgRnJvbTogQ2hyaXN0ZXIgSG9sbWJl cmcgWzxBIEhSRUY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0BsbWYuZXJpY3Nzb24uc2UiPm1h aWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0BsbWYuZXJpY3Nzb24uc2U8L0E+XTwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDEsIDIwMDEgMTA6MTAg QU08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgVG86IFRheWxvciwgVG9tLVBUIFtOT1JT RTpCOTAxOkVYQ0hdPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IENjOiBLZWl0aCBSb2Jp bnNvbjsgc2lwQGxpc3RzLmJlbGwtbGFicy5jb207IE1vbG9uZXksIEpvc2h1YTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Jmd0OyBbTUROMDU6Q1QwNzpFWENIXTwvRk9OVD4NCjxCUj48Rk9OVCBT SVpFPTI+Jmd0OyBTdWJqZWN0OiBSZTogW1NJUF0gT3ZlcmxhcCBjYWxsIHNldHVwPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 IEhpLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsgJmd0O0kgc2VlIHRoZSBkaXNjb25uZWN0IGhlcmUuJm5ic3A7IFlvdSBhcmUgYXNz dW1pbmcgdGhhdCB0aGUgZmlyc3QgSUFNIGdldHM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsgJmd0O3Byb3BhZ2F0ZWQgdGhyb3VnaCB0aGUgZWdyZXNzIGdhdGV3YXksIHNvIGFuIElTVVAg c3RhdGUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IG1hY2hpbmUgaXMgc2V0PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDtpbnRvIHBsYXkuJm5ic3A7IEkgdGhpbmsgdGhl IHN5bnRoZXNpcyBvZiBvdXIgdGhpbmtpbmcgaXMgdGhpczo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsgJmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OygxKSBUaGUg Zmlyc3QgcHJvYmxlbSBpcyB0byByZWNlaXZlIGVub3VnaCBkaWdpdHMgc28gYW4gPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGVncmVzcyBnYXRld2F5PC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7ICZndDtjYW4gYmUgc2VsZWN0ZWQuJm5ic3A7IFVudGlsIHRoYXQgaGFwcGVucywg dGhlIGRpZ2l0cyBoYXZlIHRvIGJlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDth Y2N1bXVsYXRlZCBpbnRvIHN1Y2Nlc3NpdmUgaW5pdGlhbCBJTlZJVEUgbWVzc2FnZXMuPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4m Z3Q7ICZndDsoMikgT25jZSBhbiBlZ3Jlc3MgZ2F0ZXdheSBoYXMgYmVlbiBzZWxlY3RlZCwgY2Fs bCByb3V0aW5nIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBpcyBjb21wbGV0ZTwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7YXMgZmFyIGFzIHRoZSBTSVAgZG9tYWluIGlz IGNvbmNlcm5lZC4mbmJzcDsgSGVuY2UgaXQgaXMgbGVnaXRpbWF0ZSB0byB1c2U8L0ZPTlQ+DQo8 QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0O3RoZSBJTkZPIG1ldGhvZCB0byBjYXJyeSBzdWJzZXF1 ZW50IGRpZ2l0cy48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj4mZ3Q7IExldCdzIGFzc3VtZSB0aGUgZm9sbG93aW5nIGNhc2UgKGhvcGVmdWxs eSBJIHVuZGVyc3Rvb2QgeW91IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBjb3JyZWN0 bHkpOjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsgWW91IHdhbnQgdG8gY2FsbCAxMjM0NSBvbiB0aGUgUFNUTiBzaWRlLCBhbmQgaW4g dGhlIGZpcnN0IElOVklURSB5b3U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgb25seSBz ZW5kIHRoZSBmaXJzdCBkaWdpdCwgaWUuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBJTlZJVEUgMUBwc3RuR1cuY29tIDwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgVGhl IEdXIHJldHVybnMgNDg0LCB3aGljaCB5b3UgQUNLLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yPltQVFRdPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Oby4mbmJzcDsgVGhlIEdXIE5F VkVSIHNlbmRzIDQ4NCBiZWNhdXNlIGFzIGZhciBhcyBTSVAgaXMgY29uY2VybmVkLCBjYWxsIHJv dXRpbmcgd2FzIHN1Y2Nlc3NmdWwgaWYgdGhlIGNhbGwgZ290IGFzIGZhciBhcyB0aGUgR1cuJm5i c3A7IEluc3RlYWQsIGEgcHJveHkgcmV0dXJucyA0ODQuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yPiZndDsgVGhlbiB5b3Ugc3RhcnQgc2VuZGluZyBkaWdpdHMgd2l0aCBJTkZPLCBpZS4g PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyBJTkZPIDFAcHN0bkdXLmNvbTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBtb3Jl LWRpZ2l0OiAyMzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPltQVFRdPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj5Bc3N1bWluZyBpdCB3YXMgYSBwcm94eSB0aGF0IHJldHVybmVkIHRo ZSA0ODQsIGluc3RlYWQgSSBzZW5kIGFub3RoZXIgaW5pdGlhbCBJTlZJVEU6PC9GT05UPg0KPC9Q Pg0KDQo8UD48Rk9OVCBTSVpFPTI+Jm5ic3A7IElOVklURSAxMjNAcHN0bkdXLmNvbTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgVGhl IEdXIHJldHVybnMgMjAwLCBhbmQgd2UgbWF5IHNlbmQgbW9yZSBJTkZPcyB3aXRoIHRoZSByZXN0 IG9mIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBkaWdpdHMuPC9GT05UPg0KPC9Q Pg0KDQo8UD48Rk9OVCBTSVpFPTI+W1BUVF08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPkFzc3Vt ZSB0aGlzIHRpbWUgdGhlcmUgd2VyZSBlbm91Z2ggZGlnaXRzIHRvIHJvdXRlIHRoZSBjYWxsIHN1 Y2Nlc3NmdWxseSB0byBhIFVBUyBhdCB0aGUgR1cuJm5ic3A7IEl0IHdvdWxkIHJldHVybiBzb21l dGhpbmcgbGlrZSBhIDE4MyBTZXNzaW9uIFByb2dyZXNzIHRvIHByb3ZpZGUgYSBDb250YWN0IGFu ZCBlc3RhYmxpc2ggdGhlIGNhbGwgc3RhdGUgbWFjaGluZS4mbmJzcDsgVGhlIGluZ3Jlc3MgR1cg d291bGQgc2VuZCBhZGRpdGlvbmFsIGRpZ2l0cyAoYW5kIHBvc3NpYmx5IGVuY2Fwc3VsYXRlZCBT QU0gbWVzc2FnZXMpIHZpYSBJTkZPLiZuYnNwOyBUaGUgZWdyZXNzIEdXIHdvdWxkIHN0YXJ0IHBy b3BhZ2F0aW5nIHRoZSBTQU0gbWVzc2FnZXMgb25jZSBpdCBoYWQgZW5vdWdoIGRpZ2l0cyB0byBz ZWxlY3QgbmV4dCBob3AsIGJ1dCB0aGlzIHByb2Nlc3Mgd291bGQgYmUgaW52aXNpYmxlIHRvIHRo ZSBpbmdyZXNzIEdXLiZuYnNwOyBUaGUgQUNNIHdvdWxkIGJlIHNlbnQgYmFjayBpbiBhIDE4MCBv ciAxODMgaW50ZXJpbSByZXNwb25zZSBhcyBhcHByb3ByaWF0ZSwgYW5kIEFOTSB3b3VsZCBjb21l IGJhY2sgaW4gdGhlIDIwMCBPSy48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+Jmd0OyA8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgTm93OjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgMS4gSG93IGRvIHdlIGtub3cg d2hlbiB0aGUgY2FsbCBpcyBlc3RhYmxpc2hlZD8gU2luY2Ugd2UgaGF2ZSBzZW50IGE8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgZmluYWwgcmVzcG9uc2UgdG8gdGhlIElOVklURSwgd2Ug Y2FuJ3Qgc2VuZCBhIDIwMCBPSyB0byBpdC48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDIuIFdoZW4gYWxsIHRoZSBkaWdpdHMgaGF2 ZSByZWFjaGVkIHRoZSBQU1ROIG5ldHdvcmssIHRoZXJlIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jmd0OyBtYXkgYmUgc29tZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBlYXJseSBt ZWRpYS9hbGVydGluZyBtZXNzYWdlcyBldGMuIHRvIGJlIHNlbnQsIGJ1dCBhZ2FpbiAtIDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBzaW5jZSB0aGUgR1c8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yPiZndDsgaGFzIHNlbnQgYSBmaW5hbCByZXNwb25zZSB0byB0aGUgSU5WSVRFLCAxOHgg cHJvdmlzaW9uYWwgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHJlc3BvbnNlcyBjYW4n dDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBiZSBzZW50LjwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgV2hhdCBkbyB5b3Ug dGhpbmsgYWJvdXQgdGhlIGZvbGxvd2luZzogSW5zdGVhZCBvZiBzZW5kaW5nIDQ4NCwgdGhlIEdX PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHNlbmRzIHNvbWUgcHJvdmlzaW9uYWwgcmVz cG9uc2UgKGllLiAxODYgTW9yZSBkaWdpdHMgbmVlZGVkKS4gVGhlbiB3ZTwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyB1c2UgSU5GTyBtZXNzYWdlcyhzKSB0byBwcm92aWRlIHRoZSByZXN0 IG9mIHRoZSBkaWdpdHMsIGFuZCB3aGVuIGFsbDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0 OyBkaWdpdHMgaGF2ZSByZWFjaGVkIHRoZSBQU1ROIHNpZGUsIGFuZCB0aGUgY2FsbCBjYW4gYmUg ZXN0YWJsaXNoZWQsIHdlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHJlY2VpdmUgdGhl IDIwMCBPSyB0byB0aGUgSU5WSVRFLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 IFJlZ2FyZHMsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyBDaHJpc3RlciBIb2xtYmVyZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyBFcmljc3NvbiBGaW5sYW5kPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRN TD4NCg== --0__=x3DwqAZECJbxjMGdDKiITJLEb3PPEBcbkQTX0oxcjFc3Iw5tupPMVqab-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 11:50:48 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01632 for ; Thu, 1 Feb 2001 11:50:47 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 03486443AF; Thu, 1 Feb 2001 10:24:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 41A60443AE for ; Thu, 1 Feb 2001 10:23:25 -0500 (EST) 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 f11GLeC13926; Thu, 1 Feb 2001 17:21:40 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id SAA06590; Thu, 1 Feb 2001 18:21:39 +0200 (EET) Message-ID: <3A798D11.C9D310FC@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: Tom-PT Taylor , sip@lists.bell-labs.com, Joshua Moloney Subject: Re: [SIP] Overlap call setup References: <802569E6.0058F0C1.00@marconicomms.com> Content-Type: multipart/mixed; boundary="------------DE96877C18B2941B6F6D6C01" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 01 Feb 2001 18:21:37 +0200 This is a multi-part message in MIME format. --------------DE96877C18B2941B6F6D6C01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, In this case I still think we could use another provisional response (eg. 186, or whatever available...), which would not generate an ISUP message, to inform the ingress GW that the call leg has been routed to the egress GW, but that additional digits are needed. Then, when all the digits are sent, and the call has reached its destination on the PSTN side, 183 messages etc can be generated. I am not sure a GW would generate 183 messages by itself anyway, unless it "triggered" by an ISUP message, but 186 could be triggered by the GW. Regards, Christer Holmberg Ericsson Finland >I think there is a general consensus of opinion here (for case (2)); the >question is what informational response to send back to the ingress when an egress has >been selected. The problem I have with 183 is that following the text in 7.2.3 >of sip-isup-00.txt would cause an ACM to be generated at the ingress which I don't think is what we >want o do at this point. > > Regards, > > K. Robinson > > "Tom-PT Taylor" on 01/02/2001 15:36:08 > > > > > > > > To: Christer Holmberg > > > cc: Keith Robinson/MAIN/MC1@MCMAIN, > sip@lists.bell-labs.com, "Joshua Moloney" > > > > > Subject: RE: [SIP] Overlap call setup > > > Your flow is not what I had in mind. I'll try to make myself clearer by > commenting on your flow. > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Thursday, February 01, 2001 10:10 AM > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > > [MDN05:CT07:EXCH] > > Subject: Re: [SIP] Overlap call setup > > > > > > > > Hi, > > > > >I see the disconnect here. You are assuming that the first IAM gets > > >propagated through the egress gateway, so an ISUP state > > machine is set > > >into play. I think the synthesis of our thinking is this: > > > > > >(1) The first problem is to receive enough digits so an > > egress gateway > > >can be selected. Until that happens, the digits have to be > > >accumulated into successive initial INVITE messages. > > > > > >(2) Once an egress gateway has been selected, call routing > > is complete > > >as far as the SIP domain is concerned. Hence it is legitimate to use > > >the INFO method to carry subsequent digits. > > > > Let's assume the following case (hopefully I understood you > > correctly): > > > > You want to call 12345 on the PSTN side, and in the first INVITE you > > only send the first digit, ie. > > > > INVITE 1@pstnGW.com > > > > The GW returns 484, which you ACK. > > [PTT] > No. The GW NEVER sends 484 because as far as SIP is concerned, call routing > was successful if the call got as far as the GW. Instead, a proxy returns > 484. > > > Then you start sending digits with INFO, ie. > > > > INFO 1@pstnGW.com > > more-digit: 23 > > [PTT] > Assuming it was a proxy that returned the 484, instead I send another > initial INVITE: > > INVITE 123@pstnGW.com > > > > The GW returns 200, and we may send more INFOs with the rest of the > > digits. > > [PTT] > Assume this time there were enough digits to route the call successfully to > a UAS at the GW. It would return something like a 183 Session Progress to > provide a Contact and establish the call state machine. The ingress GW > would send additional digits (and possibly encapsulated SAM messages) via > INFO. The egress GW would start propagating the SAM messages once it had > enough digits to select next hop, but this process would be invisible to the > ingress GW. The ACM would be sent back in a 180 or 183 interim response as > appropriate, and ANM would come back in the 200 OK. > > > > > Now: > > > > 1. How do we know when the call is established? Since we have sent a > > final response to the INVITE, we can't send a 200 OK to it. > > > > 2. When all the digits have reached the PSTN network, there > > may be some > > early media/alerting messages etc. to be sent, but again - > > since the GW > > has sent a final response to the INVITE, 18x provisional > > responses can't > > be sent. > > > > What do you think about the following: Instead of sending 484, the GW > > sends some provisional response (ie. 186 More digits needed). Then we > > use INFO messages(s) to provide the rest of the digits, and when all > > digits have reached the PSTN side, and the call can be established, we > > receive the 200 OK to the INVITE. > > > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64 > Description: Internet HTML --------------DE96877C18B2941B6F6D6C01 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 --------------DE96877C18B2941B6F6D6C01-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 12:01:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03229 for ; Thu, 1 Feb 2001 12:01:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 37D6F443B5; Thu, 1 Feb 2001 10:34:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id 053044439B for ; Thu, 1 Feb 2001 10:33:55 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id B7CA64CEF9 for ; Thu, 1 Feb 2001 11:33:36 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA25913 for ; Thu, 1 Feb 2001 11:33:35 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (SGI-8.9.3/8.8.5) id LAA64884 for sip@lists.bell-labs.com; Thu, 1 Feb 2001 11:35:30 -0500 (EST) Message-Id: <200102011635.LAA64884@fish-ha.research.att.com> Subject: [SIP] SIP Privacy Draft To: sip@lists.bell-labs.com Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 11:35:30 -0500 (EST) Mark Watson's update on the privacy draft discussions reminded me that I had an action item to bring to the list, regarding multiple 180 responses in a SIP session. When a SIP call is delivered to a PSTN gateway, and thus to a PSTN endpoint (B), B may have call forwarding established to (C). In some cases (which I admit to not understanding completely) the SS7 signaling could identify endpoint B as a destination that is ringing, and later identify endpoint C as an updated destination that is ringing. Presumably if C forwards to D, and D forwards to E, etc etc etc, there could be a whole sequence of indications received by the PSTN gateway about ringing endpoints. The question is whether these {may/should/shouldnot} result in multiple 180-Ringing SIP responses. I don't see anything in 2543 or 2543bis that limits a UAS to sending a single 180 response, but it doesn't seem like expected behavior. So, {should/must} a standard UAC handle multiple 180 responses? Bill Marshall wtm@research.att.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 12:10:26 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03423 for ; Thu, 1 Feb 2001 12:10:22 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4338F443BA; Thu, 1 Feb 2001 10:40:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 046EC443B9 for ; Thu, 1 Feb 2001 10:39:23 -0500 (EST) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f11Gcp120607; Thu, 1 Feb 2001 11:38:52 -0500 (EST) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id LAA10619; Thu, 1 Feb 2001 11:37:53 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Feb 2001 11:38:50 -0500 Message-ID: From: "Roy, Radhika R, ALCOO" To: "'Jon.Peterson@Level3.com'" Cc: sip@lists.bell-labs.com, chsharp@cisco.com Subject: RE: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 11:38:44 -0500 Hi, Jon: In addition, I have one more (indirect) question. Your draft also refers to the ISUP to SIP Mapping I-D (draft-ietf-sip-isup-00.txt). The call flows of this draft may also need to be revisited with respect the call flows provided in the I-D draft-ietf-sip-call-flows-02. It might be different issues, but may be relevant later because a lot of unresolved issues mentioned in you draft may also be addressed in the future. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Lebovits, Doris S, ALCOO Sent: Thursday, February 01, 2001 10:11 AM To: 'Jon.Peterson@Level3.com' Cc: sip@lists.bell-labs.com; chsharp@cisco.com Subject: RE: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt Jon, I do not agree with your comments. I think ITU-T ISUP 2000 should be the base, as it is the base going forward. ITU-T ISUP 2000 is backwards compatible with previous versions such as ISUP '92. The options in ITU-T ISUP 2000 that would not need to be specified for this activity could be highlighted as not mandatory. The ANSI version of ISUP is T1.113 and has been updated to the ITU-T ISUP 2000 level and is in the final stages for publication. Doris Lebovits AT&T dlebovits@att.com ========================================================== -----Original Message----- From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com] Sent: Thursday, February 01, 2001 1:06 AM To: chsharp@cisco.com; sip@lists.bell-labs.com Subject: RE: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt I think it was the hope of the authors that all of the meaningful values for 'base' would be characterized in the document. Since 'base' reflects the lowest common dominator (or, to coin a phrase, least specific ancestor) variant of the ISUP version in question, the authors hoped that given the backwards compatibility mechanism in ITU-T 1992 Q.76x, itu92 would be the proper base for forthcoming ISUP versions (new versions of ANSI following the 2000 issue support this mechanism, even). That much said, if there are potential 'base' values which are of use to the community that cannot be said to derive from itu92, the authors would certainly like to be made aware of them. Is there anything out there that the ISUP MIME draft misses? In the face of serious concerns that useful new 'bases' might come to light subsequent to the publication of an RFC, I suppose management of 'base' by IANA could be introduced, but personally I'd rather not trouble IANA with this additional responsibility if there isn't a substantial risk. Was there anything specific you had in mind? Jon Peterson Level(3) Communications -----Original Message----- From: Chip Sharp [mailto:chsharp@cisco.com] Sent: Tuesday, January 30, 2001 10:50 AM To: sip@lists.bell-labs.com Subject: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt Currently, the IANA considerations section of draft-ietf-sip-isup-mime-07.txt describes how to define new "version" fields, but does not describe how to define new "base" fields. Given that new base protocols may be identified, shouldn't there be a description on how IANA assigns new "base" values? Chip ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems ------------------------------------------------------------------- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 12:30:35 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03860 for ; Thu, 1 Feb 2001 12:30:30 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5AD6E443BF; Thu, 1 Feb 2001 10:45:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04e (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by lists.bell-labs.com (Postfix) with ESMTP id 472B1443BE for ; Thu, 1 Feb 2001 10:44:28 -0500 (EST) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e; Thu, 1 Feb 2001 11:37:11 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 1 Feb 2001 11:37:13 -0500 Message-ID: <28560036253BD41191A10000F8BCBD11038E3EB9@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Christer Holmberg , Keith Robinson Cc: sip@lists.bell-labs.com, "Joshua Moloney" Subject: RE: [SIP] Overlap call setup MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08C6D.3667A560" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 11:37:05 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08C6D.3667A560 Content-Type: text/plain; charset="ISO-8859-1" A new response code would obviously be unambiguous, and may be necessary. The problem doesn't arise in the tandem case, since you could have a rule that ACM is sent back at the ingress side only when an encapsulated ACM is received from the egress side. The problem is to figure out appropriate rules for generating ACM when the termination is to the SIP network. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Thursday, February 01, 2001 11:22 AM > To: Keith Robinson > Cc: Taylor, Tom-PT [NORSE:B901:EXCH]; > sip@lists.bell-labs.com; Moloney, > Joshua [MDN05:CT07:EXCH] > Subject: Re: [SIP] Overlap call setup > > > > Hi, > > In this case I still think we could use another provisional response > (eg. 186, or whatever available...), which would not generate an ISUP > message, to inform the ingress GW that the call leg has been routed to > the egress GW, but that additional digits are needed. > > Then, when all the digits are sent, and the call has reached its > destination on the PSTN side, 183 messages etc can be generated. I am > not sure a GW would generate 183 messages by itself anyway, unless it > "triggered" by an ISUP message, but 186 could be triggered by the GW. > > Regards, > > Christer Holmberg > Ericsson Finland > > > >I think there is a general consensus of opinion here (for > case (2)); the > >question is what informational response to send back to the > ingress when an egress has > >been selected. The problem I have with 183 is that following > the text in 7.2.3 > >of sip-isup-00.txt would cause an ACM to be generated at the > ingress which I don't think is what we > >want o do at this point. > > > > Regards, > > > > K. Robinson > > > > "Tom-PT Taylor" on 01/02/2001 15:36:08 > > > > > > > > > > > > > > > > To: Christer Holmberg > > > > > > cc: Keith Robinson/MAIN/MC1@MCMAIN, > > sip@lists.bell-labs.com, "Joshua Moloney" > > > > > > > > > > Subject: RE: [SIP] Overlap call setup > > > > > > Your flow is not what I had in mind. I'll try to make > myself clearer by > > commenting on your flow. > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Thursday, February 01, 2001 10:10 AM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > > > [MDN05:CT07:EXCH] > > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > > > Hi, > > > > > > >I see the disconnect here. You are assuming that the > first IAM gets > > > >propagated through the egress gateway, so an ISUP state > > > machine is set > > > >into play. I think the synthesis of our thinking is this: > > > > > > > >(1) The first problem is to receive enough digits so an > > > egress gateway > > > >can be selected. Until that happens, the digits have to be > > > >accumulated into successive initial INVITE messages. > > > > > > > >(2) Once an egress gateway has been selected, call routing > > > is complete > > > >as far as the SIP domain is concerned. Hence it is > legitimate to use > > > >the INFO method to carry subsequent digits. > > > > > > Let's assume the following case (hopefully I understood you > > > correctly): > > > > > > You want to call 12345 on the PSTN side, and in the first > INVITE you > > > only send the first digit, ie. > > > > > > INVITE 1@pstnGW.com > > > > > > The GW returns 484, which you ACK. > > > > [PTT] > > No. The GW NEVER sends 484 because as far as SIP is > concerned, call routing > > was successful if the call got as far as the GW. Instead, > a proxy returns > > 484. > > > > > Then you start sending digits with INFO, ie. > > > > > > INFO 1@pstnGW.com > > > more-digit: 23 > > > > [PTT] > > Assuming it was a proxy that returned the 484, instead I > send another > > initial INVITE: > > > > INVITE 123@pstnGW.com > > > > > > The GW returns 200, and we may send more INFOs with the > rest of the > > > digits. > > > > [PTT] > > Assume this time there were enough digits to route the call > successfully to > > a UAS at the GW. It would return something like a 183 > Session Progress to > > provide a Contact and establish the call state machine. > The ingress GW > > would send additional digits (and possibly encapsulated SAM > messages) via > > INFO. The egress GW would start propagating the SAM > messages once it had > > enough digits to select next hop, but this process would be > invisible to the > > ingress GW. The ACM would be sent back in a 180 or 183 > interim response as > > appropriate, and ANM would come back in the 200 OK. > > > > > > > > Now: > > > > > > 1. How do we know when the call is established? Since we > have sent a > > > final response to the INVITE, we can't send a 200 OK to it. > > > > > > 2. When all the digits have reached the PSTN network, there > > > may be some > > > early media/alerting messages etc. to be sent, but again - > > > since the GW > > > has sent a final response to the INVITE, 18x provisional > > > responses can't > > > be sent. > > > > > > What do you think about the following: Instead of sending > 484, the GW > > > sends some provisional response (ie. 186 More digits > needed). Then we > > > use INFO messages(s) to provide the rest of the digits, > and when all > > > digits have reached the PSTN side, and the call can be > established, we > > > receive the 200 OK to the INVITE. > > > > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > -------------------------------------------------------------- > ---------- > > Name: att1.htm > > att1.htm Type: Hypertext Markup Language (text/html) > > Encoding: base64 > > Description: Internet HTML > ------_=_NextPart_001_01C08C6D.3667A560 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Overlap call setup

A new response code would obviously be unambiguous, = and may be necessary.  The problem doesn't arise in the tandem = case, since you could have a rule that ACM is sent back at the ingress = side only when an encapsulated ACM is received from the egress = side.  The problem is to figure out appropriate rules for = generating ACM when the termination is to the SIP network.

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: Thursday, February 01, 2001 11:22 = AM
> To: Keith Robinson
> Cc: Taylor, Tom-PT [NORSE:B901:EXCH];
> sip@lists.bell-labs.com; Moloney,
> Joshua [MDN05:CT07:EXCH]
> Subject: Re: [SIP] Overlap call setup
>
>
>
> Hi,
>
> In this case I still think we could use another = provisional response
> (eg. 186, or whatever available...), which = would not generate an ISUP
> message, to inform the ingress GW that the call = leg has been routed to
> the egress GW, but that additional digits are = needed.
>
> Then, when all the digits are sent, and the = call has reached its
> destination on the PSTN side, 183 messages etc = can be generated. I am
> not sure a GW would generate 183 messages by = itself anyway, unless it
> "triggered" by an ISUP message, but = 186 could be triggered by the GW.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
> >I think there is a general consensus of = opinion here (for
> case (2)); the
> >question is what informational response to = send back to the
> ingress when an egress has
> >been selected. The problem I have with 183 = is that following
> the text in 7.2.3
> >of sip-isup-00.txt would cause an ACM to be = generated at the
> ingress which I don't think is what we
> >want o do at this point.
> >
> > Regards,
> >
> > K. Robinson
> >
> > "Tom-PT Taylor" = <taylor@nortelnetworks.com> on 01/02/2001 15:36:08
> >
> >
> >
> >
> >
> >
> >
> >  To:      = Christer Holmberg
> >       &n= bsp;   <christer.holmberg@lmf.ericsson.se>
> >
> >  cc:      = Keith Robinson/MAIN/MC1@MCMAIN,
> = >           = sip@lists.bell-labs.com, "Joshua Moloney"
> = >           = <jmoloney@nortelnetworks.com>
> >
> >
> >
> >  Subject: RE: [SIP] Overlap call = setup
> >
> >
> > Your flow is not what I had in mind.  = I'll try to make
> myself clearer by
> > commenting on your flow.
> >
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > > Sent: Thursday, February 01, 2001 = 10:10 AM
> > > To: Taylor, Tom-PT = [NORSE:B901:EXCH]
> > > Cc: Keith Robinson; = sip@lists.bell-labs.com; Moloney, Joshua
> > > [MDN05:CT07:EXCH]
> > > Subject: Re: [SIP] Overlap call = setup
> > >
> > >
> > >
> > > Hi,
> > >
> > > >I see the disconnect here.  = You are assuming that the
> first IAM gets
> > > >propagated through the egress = gateway, so an ISUP state
> > > machine is set
> > > >into play.  I think the = synthesis of our thinking is this:
> > > >
> > > >(1) The first problem is to = receive enough digits so an
> > > egress gateway
> > > >can be selected.  Until that = happens, the digits have to be
> > > >accumulated into successive = initial INVITE messages.
> > > >
> > > >(2) Once an egress gateway has = been selected, call routing
> > > is complete
> > > >as far as the SIP domain is = concerned.  Hence it is
> legitimate to use
> > > >the INFO method to carry = subsequent digits.
> > >
> > > Let's assume the following case = (hopefully I understood you
> > > correctly):
> > >
> > > You want to call 12345 on the PSTN = side, and in the first
> INVITE you
> > > only send the first digit, ie.
> > >
> > > INVITE 1@pstnGW.com
> > >
> > > The GW returns 484, which you = ACK.
> >
> > [PTT]
> > No.  The GW NEVER sends 484 because = as far as SIP is
> concerned, call routing
> > was successful if the call got as far as = the GW.  Instead,
> a proxy returns
> > 484.
> >
> > > Then you start sending digits with = INFO, ie.
> > >
> > > INFO 1@pstnGW.com
> > > more-digit: 23
> >
> > [PTT]
> > Assuming it was a proxy that returned the = 484, instead I
> send another
> > initial INVITE:
> >
> >   INVITE 123@pstnGW.com
> > >
> > > The GW returns 200, and we may send = more INFOs with the
> rest of the
> > > digits.
> >
> > [PTT]
> > Assume this time there were enough digits = to route the call
> successfully to
> > a UAS at the GW.  It would return = something like a 183
> Session Progress to
> > provide a Contact and establish the call = state machine. 
> The ingress GW
> > would send additional digits (and possibly = encapsulated SAM
> messages) via
> > INFO.  The egress GW would start = propagating the SAM
> messages once it had
> > enough digits to select next hop, but this = process would be
> invisible to the
> > ingress GW.  The ACM would be sent = back in a 180 or 183
> interim response as
> > appropriate, and ANM would come back in = the 200 OK.
> >
> > >
> > > Now:
> > >
> > > 1. How do we know when the call is = established? Since we
> have sent a
> > > final response to the INVITE, we = can't send a 200 OK to it.
> > >
> > > 2. When all the digits have reached = the PSTN network, there
> > > may be some
> > > early media/alerting messages etc. to = be sent, but again -
> > > since the GW
> > > has sent a final response to the = INVITE, 18x provisional
> > > responses can't
> > > be sent.
> > >
> > > What do you think about the = following: Instead of sending
> 484, the GW
> > > sends some provisional response (ie. = 186 More digits
> needed). Then we
> > > use INFO messages(s) to provide the = rest of the digits,
> and when all
> > > digits have reached the PSTN side, = and the call can be
> established, we
> > > receive the 200 OK to the = INVITE.
> > >
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > >
> >
> >  
> = --------------------------------------------------------------
> ----------
> = >           &n= bsp;       Name: att1.htm
> >    = att1.htm       Type: Hypertext Markup = Language (text/html)
> = >           &n= bsp;   Encoding: base64
> = >            = Description: Internet HTML
>

------_=_NextPart_001_01C08C6D.3667A560-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 13:36:16 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06305 for ; Thu, 1 Feb 2001 13:36:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 800844433E; Thu, 1 Feb 2001 12:36:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id 17A804433A for ; Thu, 1 Feb 2001 12:35:13 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Thu, 1 Feb 2001 18:34:20 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Feb 2001 18:34:18 -0000 Message-ID: From: "Mark Watson" To: sip@lists.bell-labs.com Subject: RE: [SIP] SIP Privacy Draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08C7D.97159AB0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 18:34:19 -0000 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_01C08C7D.97159AB0 Content-Type: text/plain; charset="iso-8859-1" In the scenario described, the PSTN returns an ACM message when the call originally terminates at (B). If (B) has Call Forwarding on No Reply (say), then when the No Reply timer expires, a CPG (Call Progress) will be returned indicating that diversion is taking place. Subsequent diversions will cause further CPG messages. It would be desireably to map these to 1xx responses in the SIP network, as they can provide the caller with information as to where the call has been forwarded. Mark Watson Nortel Networks > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: 01 February 2001 16:36 > To: sip@lists.bell-labs.com > Subject: [SIP] SIP Privacy Draft > > > Mark Watson's update on the privacy draft discussions reminded me > that I had an action item to bring to the list, regarding multiple > 180 responses in a SIP session. > > When a SIP call is delivered to a PSTN gateway, and thus to a PSTN > endpoint (B), B may have call forwarding established to (C). In some > cases (which I admit to not understanding completely) the SS7 > signaling > could identify endpoint B as a destination that is ringing, and later > identify endpoint C as an updated destination that is ringing. > Presumably if C forwards to D, and D forwards to E, etc etc etc, there > could be a whole sequence of indications received by the PSTN gateway > about ringing endpoints. > > The question is whether these {may/should/shouldnot} result > in multiple > 180-Ringing SIP responses. I don't see anything in 2543 or 2543bis > that limits a UAS to sending a single 180 response, but it doesn't > seem like expected behavior. So, {should/must} a standard UAC handle > multiple 180 responses? > > Bill Marshall > wtm@research.att.com > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > ------_=_NextPart_001_01C08C7D.97159AB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] SIP Privacy Draft

In the scenario described, the PSTN returns an ACM = message when the call originally terminates at (B). If (B) has Call = Forwarding on No Reply (say), then when the No Reply timer expires, a = CPG (Call Progress) will be returned indicating that diversion is = taking place.

Subsequent diversions will cause further CPG = messages.

It would be desireably to map these to 1xx responses = in the SIP network, as they can provide the caller with information as = to where the call has been forwarded.

Mark Watson
Nortel Networks

> -----Original Message-----
> From: William Marshall [mailto:wtm@research.att.com]
> Sent: 01 February 2001 16:36
> To: sip@lists.bell-labs.com
> Subject: [SIP] SIP Privacy Draft
>
>
> Mark Watson's update on the privacy draft = discussions reminded me
> that I had an action item to bring to the list, = regarding multiple
> 180 responses in a SIP session.
>
> When a SIP call is delivered to a PSTN gateway, = and thus to a PSTN
> endpoint (B), B may have call forwarding = established to (C).  In some
> cases (which I admit to not understanding = completely) the SS7
> signaling
> could identify endpoint B as a destination that = is ringing, and later
> identify endpoint C as an updated destination = that is ringing.
> Presumably if C forwards to D, and D forwards = to E, etc etc etc, there
> could be a whole sequence of indications = received by the PSTN gateway
> about ringing endpoints.
>
> The question is whether these = {may/should/shouldnot} result
> in multiple
> 180-Ringing SIP responses.  I don't see = anything in 2543 or 2543bis
> that limits a UAS to sending a single 180 = response, but it doesn't
> seem like expected behavior.  So, = {should/must} a standard UAC handle
> multiple 180 responses?
>
> Bill Marshall
> wtm@research.att.com
>
> = _______________________________________________
> This list is for continuing development of the = SIP protocol.
> The sip-implementer's list is the place to = discuss implementation,
> and to receive advice on understanding existing = sip.
> To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the = body.
>

------_=_NextPart_001_01C08C7D.97159AB0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 13:46:15 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06912 for ; Thu, 1 Feb 2001 13:46:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E308E44371; Thu, 1 Feb 2001 12:43:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id D775944358 for ; Thu, 1 Feb 2001 12:41:38 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Thu, 1 Feb 2001 18:38:54 +0000 Received: from nwcwi1a.europe.nortel.com ([47.30.176.175]) by znsgd00t.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id D0VT1DY9; Thu, 1 Feb 2001 18:38:52 -0000 Received: from nwcwi1a.europe.nortel.com ([47.30.176.175]) by nwcwi1a.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1C0RFKH8; Thu, 1 Feb 2001 18:38:55 -0000 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2650.21) id <1C0RFKH7>; Thu, 1 Feb 2001 18:38:55 -0000 Message-ID: From: "Mark Watson" To: "'sip@lists.bell-labs.com'" , "'Lebovits, Doris S, ALCOO'" Subject: RE: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08C7E.3BBB9150" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 18:38:56 -0000 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_01C08C7E.3BBB9150 Content-Type: text/plain; charset="ISO-8859-1" It doesn't really matter which version of ITU-T ISUP we reference - because after 1992 they are all backwards compatible with each other. The point was that there only needs to be a single 'base' value for post-1992 ITU-T ISUPs. As soon as the ISUP processor sees this, it knows that it can handle unrecognised information according to the compatibility procedure and so can sucessfully process the message. Given this, ISUP 1992 was chosen because it was the first version with the compatibility mechanism. It would be arbitrary to choose another version - why not 1997 or 2004 ?? The intent of this 'base' value is to imply that the encapsulated signalling is based on an ITU-T ISUP version 1992 or later, so it covers ISUP 2000. Regards, Mark Watson > -----Original Message----- > From: Lebovits, Doris S, ALCOO [mailto:dlebovits@att.com] > Sent: 01 February 2001 15:11 > To: 'Jon.Peterson@Level3.com' > Cc: ; chsharp@cisco.com > Subject: RE: [SIP] Question on "base" in > draft-ietf-sip-isup-mime-07.txt > > > > Jon, > I do not agree with your comments. I think ITU-T ISUP 2000 > should be the > base, > as it is the base going forward. ITU-T ISUP 2000 is backwards > compatible > with > previous versions such as ISUP '92. The options in ITU-T ISUP > 2000 that > would > not need to be specified for this activity could be highlighted as not > mandatory. > The ANSI version of ISUP is T1.113 and has been updated to > the ITU-T ISUP > 2000 > level and is in the final stages for publication. > > Doris Lebovits > AT&T > dlebovits@att.com > ========================================================== > > -----Original Message----- > From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com] > Sent: Thursday, February 01, 2001 1:06 AM > To: chsharp@cisco.com; sip@lists.bell-labs.com > Subject: RE: [SIP] Question on "base" in > draft-ietf-sip-isup-mime-07.txt > > > I think it was the hope of the authors that all of the > meaningful values for > 'base' would be characterized in the document. Since 'base' > reflects the > lowest common dominator (or, to coin a phrase, least specific > ancestor) > variant of the ISUP version in question, the authors hoped > that given the > backwards compatibility mechanism in ITU-T 1992 Q.76x, itu92 > would be the > proper base for forthcoming ISUP versions (new versions of > ANSI following > the 2000 issue support this mechanism, even). > > That much said, if there are potential 'base' values which > are of use to the > community that cannot be said to derive from itu92, the authors would > certainly like to be made aware of them. Is there anything > out there that > the ISUP MIME draft misses? > > In the face of serious concerns that useful new 'bases' might > come to light > subsequent to the publication of an RFC, I suppose management > of 'base' by > IANA could be introduced, but personally I'd rather not > trouble IANA with > this additional responsibility if there isn't a substantial > risk. Was there > anything specific you had in mind? > > Jon Peterson > Level(3) Communications > > -----Original Message----- > From: Chip Sharp [mailto:chsharp@cisco.com] > Sent: Tuesday, January 30, 2001 10:50 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt > > > Currently, the IANA considerations section of > draft-ietf-sip-isup-mime-07.txt describes how to define new "version" > fields, but does not describe how to define new "base" fields. > > Given that new base protocols may be identified, shouldn't there be a > description on how IANA assigns new "base" values? > > Chip > > ------------------------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems > ------------------------------------------------------------------- > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > ------_=_NextPart_001_01C08C7E.3BBB9150 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Question on "base" in = draft-ietf-sip-isup-mime-07.txt

It doesn't really matter which version of ITU-T ISUP = we reference - because after 1992 they are all backwards compatible = with each other.

The point was that there only needs to be a single = 'base' value for post-1992 ITU-T ISUPs. As soon as the ISUP processor = sees this, it knows that it can handle unrecognised information = according to the compatibility procedure and so can sucessfully process = the message.

Given this, ISUP 1992 was chosen because it was the = first version with the compatibility mechanism. It would be arbitrary = to choose another version - why not 1997 or 2004 ??

The intent of this 'base' value is to imply that the = encapsulated signalling is based on an ITU-T ISUP version 1992 or = later, so it covers ISUP 2000.

Regards,

Mark Watson

> -----Original Message-----
> From: Lebovits, Doris S, ALCOO [mailto:dlebovits@att.com]
> Sent: 01 February 2001 15:11
> To: 'Jon.Peterson@Level3.com'
> Cc: ; chsharp@cisco.com
> Subject: RE: [SIP] Question on "base" = in
> draft-ietf-sip-isup-mime-07.txt
>
>
>
> Jon,
> I do not agree with your comments. I think = ITU-T ISUP 2000
> should be the
> base,
> as it is the base going forward. ITU-T ISUP = 2000 is backwards
> compatible
> with
> previous versions such as ISUP '92. The options = in ITU-T ISUP
> 2000 that
> would
> not need to be specified for this activity = could be highlighted as not
> mandatory.
> The ANSI version of ISUP is T1.113 and has been = updated to
> the ITU-T ISUP
> 2000
> level and is in the final stages for = publication.
>
> Doris Lebovits
> AT&T
> dlebovits@att.com
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> -----Original Message-----
> From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com]
> Sent: Thursday, February 01, 2001 1:06 = AM
> To: chsharp@cisco.com; = sip@lists.bell-labs.com
> Subject: RE: [SIP] Question on "base" = in
> draft-ietf-sip-isup-mime-07.txt
>
>
> I think it was the hope of the authors that all = of the
> meaningful values for
> 'base' would be characterized in the document. = Since 'base'
> reflects the
> lowest common dominator (or, to coin a phrase, = least specific
> ancestor)
> variant of the ISUP version in question, the = authors hoped
> that given the
> backwards compatibility mechanism in ITU-T 1992 = Q.76x, itu92
> would be the
> proper base for forthcoming ISUP versions (new = versions of
> ANSI following
> the 2000 issue support this mechanism, = even).
>
> That much said, if there are potential 'base' = values which
> are of use to the
> community that cannot be said to derive from = itu92, the authors would
> certainly like to be made aware of them. Is = there anything
> out there that
> the ISUP MIME draft misses?
>
> In the face of serious concerns that useful new = 'bases' might
> come to light
> subsequent to the publication of an RFC, I = suppose management
> of 'base' by
> IANA could be introduced, but personally I'd = rather not
> trouble IANA with
> this additional responsibility if there isn't a = substantial
> risk. Was there
> anything specific you had in mind?
>
> Jon Peterson
> Level(3) Communications
>
> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Tuesday, January 30, 2001 10:50 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Question on "base" in = draft-ietf-sip-isup-mime-07.txt
>
>
> Currently, the IANA considerations section of =
> draft-ietf-sip-isup-mime-07.txt describes how = to define new "version"
> fields, but does not describe how to define new = "base" fields.
>
> Given that new base protocols may be = identified, shouldn't there be a
> description on how IANA assigns new = "base" values?
>
> Chip
>
> = -------------------------------------------------------------------
> Chip = Sharp           &= nbsp;           = Consulting Engineering
> Cisco Systems
> = -------------------------------------------------------------------
>
>
> = _______________________________________________
> This list is for continuing development of the = SIP protocol.
> The sip-implementer's list is the place to = discuss implementation,
> and to receive advice on understanding existing = sip.
> To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the = body.
>
> = _______________________________________________
> This list is for continuing development of the = SIP protocol.
> The sip-implementer's list is the place to = discuss implementation,
> and to receive advice on understanding existing = sip.
> To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the = body.
>
> = _______________________________________________
> This list is for continuing development of the = SIP protocol.
> The sip-implementer's list is the place to = discuss implementation,
> and to receive advice on understanding existing = sip.
> To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the = body.
>

------_=_NextPart_001_01C08C7E.3BBB9150-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 14:41:16 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09695 for ; Thu, 1 Feb 2001 14:41:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A95F14434C; Thu, 1 Feb 2001 13:41:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id D63EF4433E for ; Thu, 1 Feb 2001 13:40:32 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f11JeD124804; Thu, 1 Feb 2001 14:40:14 -0500 (EST) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id OAA18297; Thu, 1 Feb 2001 14:39:07 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Feb 2001 14:40:09 -0500 Message-ID: From: "Lebovits, Doris S, ALCOO" To: "'Mark Watson'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 14:40:07 -0500 Mark, My concern is the ability to handle the new ISUP messages and parameters. Insure that these do not end up as unrecognized messages and parameters. Also there is a need for the new application transport message (APM) and new application transport parameter (APP) supporting APM. It is not arbitrary to select ITU-T ISUP 2000 as it is the last significant version.Having the 'base' value to encapsulated signalling based on ITU-T ISUP 2000, also covers ISUP 92, from a compatibility point of view. Doris Lebovits dlebovits@att.com ---------------------------------------------------------------------------- --------------------- -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Thursday, February 01, 2001 1:39 PM To: 'sip@lists.bell-labs.com'; Lebovits, Doris S, ALCOO Subject: RE: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt It doesn't really matter which version of ITU-T ISUP we reference - because after 1992 they are all backwards compatible with each other. The point was that there only needs to be a single 'base' value for post-1992 ITU-T ISUPs. As soon as the ISUP processor sees this, it knows that it can handle unrecognised information according to the compatibility procedure and so can sucessfully process the message. Given this, ISUP 1992 was chosen because it was the first version with the compatibility mechanism. It would be arbitrary to choose another version - why not 1997 or 2004 ?? The intent of this 'base' value is to imply that the encapsulated signalling is based on an ITU-T ISUP version 1992 or later, so it covers ISUP 2000. Regards, Mark Watson > -----Original Message----- > From: Lebovits, Doris S, ALCOO [ mailto:dlebovits@att.com ] > Sent: 01 February 2001 15:11 > To: 'Jon.Peterson@Level3.com' > Cc: ; chsharp@cisco.com > Subject: RE: [SIP] Question on "base" in > draft-ietf-sip-isup-mime-07.txt > > > > Jon, > I do not agree with your comments. I think ITU-T ISUP 2000 > should be the > base, > as it is the base going forward. ITU-T ISUP 2000 is backwards > compatible > with > previous versions such as ISUP '92. The options in ITU-T ISUP > 2000 that > would > not need to be specified for this activity could be highlighted as not > mandatory. > The ANSI version of ISUP is T1.113 and has been updated to > the ITU-T ISUP > 2000 > level and is in the final stages for publication. > > Doris Lebovits > AT&T > dlebovits@att.com > ========================================================== > > -----Original Message----- > From: Jon.Peterson@Level3.com [ mailto:Jon.Peterson@Level3.com ] > Sent: Thursday, February 01, 2001 1:06 AM > To: chsharp@cisco.com; sip@lists.bell-labs.com > Subject: RE: [SIP] Question on "base" in > draft-ietf-sip-isup-mime-07.txt > > > I think it was the hope of the authors that all of the > meaningful values for > 'base' would be characterized in the document. Since 'base' > reflects the > lowest common dominator (or, to coin a phrase, least specific > ancestor) > variant of the ISUP version in question, the authors hoped > that given the > backwards compatibility mechanism in ITU-T 1992 Q.76x, itu92 > would be the > proper base for forthcoming ISUP versions (new versions of > ANSI following > the 2000 issue support this mechanism, even). > > That much said, if there are potential 'base' values which > are of use to the > community that cannot be said to derive from itu92, the authors would > certainly like to be made aware of them. Is there anything > out there that > the ISUP MIME draft misses? > > In the face of serious concerns that useful new 'bases' might > come to light > subsequent to the publication of an RFC, I suppose management > of 'base' by > IANA could be introduced, but personally I'd rather not > trouble IANA with > this additional responsibility if there isn't a substantial > risk. Was there > anything specific you had in mind? > > Jon Peterson > Level(3) Communications > > -----Original Message----- > From: Chip Sharp [ mailto:chsharp@cisco.com ] > Sent: Tuesday, January 30, 2001 10:50 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt > > > Currently, the IANA considerations section of > draft-ietf-sip-isup-mime-07.txt describes how to define new "version" > fields, but does not describe how to define new "base" fields. > > Given that new base protocols may be identified, shouldn't there be a > description on how IANA assigns new "base" values? > > Chip > > ------------------------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems > ------------------------------------------------------------------- > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 15:06:06 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10468 for ; Thu, 1 Feb 2001 15:06:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 776E34434C; Thu, 1 Feb 2001 14:06:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 263F64433A for ; Thu, 1 Feb 2001 14:05:37 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 1 Feb 2001 15:05:04 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 1 Feb 2001 15:05:01 -0500 Message-ID: <28560036253BD41191A10000F8BCBD11038E428C@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Christer Holmberg , Keith Robinson Cc: sip@lists.bell-labs.com, "Joshua Moloney" Subject: RE: [SIP] Overlap call setup MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08C8A.3C4F7670" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 15:04:51 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08C8A.3C4F7670 Content-Type: text/plain; charset="ISO-8859-1" I've had another thought. If the UAS returns Accept-Content: application/isup, it could be a signal to the ingress gateway to hold its ACM until it receives one encapsulated from the egress gateway. In the absence of that signal, the ingress gateway would assume that call routing was complete upon receipt of the first 1xx response. -----Original Message----- From: Taylor, Tom-PT [NORSE:B901:EXCH] Sent: Thursday, February 01, 2001 11:37 AM To: Christer Holmberg; Keith Robinson Cc: sip@lists.bell-labs.com; Moloney, Joshua [MDN05:CT07:EXCH] Subject: RE: [SIP] Overlap call setup A new response code would obviously be unambiguous, and may be necessary. The problem doesn't arise in the tandem case, since you could have a rule that ACM is sent back at the ingress side only when an encapsulated ACM is received from the egress side. The problem is to figure out appropriate rules for generating ACM when the termination is to the SIP network. > -----Original Message----- > From: Christer Holmberg [ mailto:christer.holmberg@lmf.ericsson.se ] > Sent: Thursday, February 01, 2001 11:22 AM > To: Keith Robinson > Cc: Taylor, Tom-PT [NORSE:B901:EXCH]; > sip@lists.bell-labs.com; Moloney, > Joshua [MDN05:CT07:EXCH] > Subject: Re: [SIP] Overlap call setup > > > > Hi, > > In this case I still think we could use another provisional response > (eg. 186, or whatever available...), which would not generate an ISUP > message, to inform the ingress GW that the call leg has been routed to > the egress GW, but that additional digits are needed. > > Then, when all the digits are sent, and the call has reached its > destination on the PSTN side, 183 messages etc can be generated. I am > not sure a GW would generate 183 messages by itself anyway, unless it > "triggered" by an ISUP message, but 186 could be triggered by the GW. > > Regards, > > Christer Holmberg > Ericsson Finland > > > >I think there is a general consensus of opinion here (for > case (2)); the > >question is what informational response to send back to the > ingress when an egress has > >been selected. The problem I have with 183 is that following > the text in 7.2.3 > >of sip-isup-00.txt would cause an ACM to be generated at the > ingress which I don't think is what we > >want o do at this point. > > > > Regards, > > > > K. Robinson > > > > "Tom-PT Taylor" on 01/02/2001 15:36:08 > > > > > > > > > > > > > > > > To: Christer Holmberg > > > > > > cc: Keith Robinson/MAIN/MC1@MCMAIN, > > sip@lists.bell-labs.com, "Joshua Moloney" > > > > > > > > > > Subject: RE: [SIP] Overlap call setup > > > > > > Your flow is not what I had in mind. I'll try to make > myself clearer by > > commenting on your flow. > > > > > -----Original Message----- > > > From: Christer Holmberg [ mailto:christer.holmberg@lmf.ericsson.se ] > > > Sent: Thursday, February 01, 2001 10:10 AM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > > > [MDN05:CT07:EXCH] > > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > > > Hi, > > > > > > >I see the disconnect here. You are assuming that the > first IAM gets > > > >propagated through the egress gateway, so an ISUP state > > > machine is set > > > >into play. I think the synthesis of our thinking is this: > > > > > > > >(1) The first problem is to receive enough digits so an > > > egress gateway > > > >can be selected. Until that happens, the digits have to be > > > >accumulated into successive initial INVITE messages. > > > > > > > >(2) Once an egress gateway has been selected, call routing > > > is complete > > > >as far as the SIP domain is concerned. Hence it is > legitimate to use > > > >the INFO method to carry subsequent digits. > > > > > > Let's assume the following case (hopefully I understood you > > > correctly): > > > > > > You want to call 12345 on the PSTN side, and in the first > INVITE you > > > only send the first digit, ie. > > > > > > INVITE 1@pstnGW.com > > > > > > The GW returns 484, which you ACK. > > > > [PTT] > > No. The GW NEVER sends 484 because as far as SIP is > concerned, call routing > > was successful if the call got as far as the GW. Instead, > a proxy returns > > 484. > > > > > Then you start sending digits with INFO, ie. > > > > > > INFO 1@pstnGW.com > > > more-digit: 23 > > > > [PTT] > > Assuming it was a proxy that returned the 484, instead I > send another > > initial INVITE: > > > > INVITE 123@pstnGW.com > > > > > > The GW returns 200, and we may send more INFOs with the > rest of the > > > digits. > > > > [PTT] > > Assume this time there were enough digits to route the call > successfully to > > a UAS at the GW. It would return something like a 183 > Session Progress to > > provide a Contact and establish the call state machine. > The ingress GW > > would send additional digits (and possibly encapsulated SAM > messages) via > > INFO. The egress GW would start propagating the SAM > messages once it had > > enough digits to select next hop, but this process would be > invisible to the > > ingress GW. The ACM would be sent back in a 180 or 183 > interim response as > > appropriate, and ANM would come back in the 200 OK. > > > > > > > > Now: > > > > > > 1. How do we know when the call is established? Since we > have sent a > > > final response to the INVITE, we can't send a 200 OK to it. > > > > > > 2. When all the digits have reached the PSTN network, there > > > may be some > > > early media/alerting messages etc. to be sent, but again - > > > since the GW > > > has sent a final response to the INVITE, 18x provisional > > > responses can't > > > be sent. > > > > > > What do you think about the following: Instead of sending > 484, the GW > > > sends some provisional response (ie. 186 More digits > needed). Then we > > > use INFO messages(s) to provide the rest of the digits, > and when all > > > digits have reached the PSTN side, and the call can be > established, we > > > receive the 200 OK to the INVITE. > > > > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > -------------------------------------------------------------- > ---------- > > Name: att1.htm > > att1.htm Type: Hypertext Markup Language (text/html) > > Encoding: base64 > > Description: Internet HTML > ------_=_NextPart_001_01C08C8A.3C4F7670 Content-Type: text/html; charset="ISO-8859-1" RE: [SIP] Overlap call setup
I've had another thought.  If the UAS returns Accept-Content: application/isup, it could be a signal to the ingress gateway to hold its ACM until it receives one encapsulated from the egress gateway.  In the absence of that signal, the ingress gateway would assume that call routing was complete upon receipt of the first 1xx response.
-----Original Message-----
From: Taylor, Tom-PT [NORSE:B901:EXCH]
Sent: Thursday, February 01, 2001 11:37 AM
To: Christer Holmberg; Keith Robinson
Cc: sip@lists.bell-labs.com; Moloney, Joshua [MDN05:CT07:EXCH]
Subject: RE: [SIP] Overlap call setup

A new response code would obviously be unambiguous, and may be necessary.  The problem doesn't arise in the tandem case, since you could have a rule that ACM is sent back at the ingress side only when an encapsulated ACM is received from the egress side.  The problem is to figure out appropriate rules for generating ACM when the termination is to the SIP network.

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Thursday, February 01, 2001 11:22 AM
> To: Keith Robinson
> Cc: Taylor, Tom-PT [NORSE:B901:EXCH];
> sip@lists.bell-labs.com; Moloney,
> Joshua [MDN05:CT07:EXCH]
> Subject: Re: [SIP] Overlap call setup
>
>
>
> Hi,
>
> In this case I still think we could use another provisional response
> (eg. 186, or whatever available...), which would not generate an ISUP
> message, to inform the ingress GW that the call leg has been routed to
> the egress GW, but that additional digits are needed.
>
> Then, when all the digits are sent, and the call has reached its
> destination on the PSTN side, 183 messages etc can be generated. I am
> not sure a GW would generate 183 messages by itself anyway, unless it
> "triggered" by an ISUP message, but 186 could be triggered by the GW.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
> >I think there is a general consensus of opinion here (for
> case (2)); the
> >question is what informational response to send back to the
> ingress when an egress has
> >been selected. The problem I have with 183 is that following
> the text in 7.2.3
> >of sip-isup-00.txt would cause an ACM to be generated at the
> ingress which I don't think is what we
> >want o do at this point.
> >
> > Regards,
> >
> > K. Robinson
> >
> > "Tom-PT Taylor" <taylor@nortelnetworks.com> on 01/02/2001 15:36:08
> >
> >
> >
> >
> >
> >
> >
> >  To:      Christer Holmberg
> >           <christer.holmberg@lmf.ericsson.se>
> >
> >  cc:      Keith Robinson/MAIN/MC1@MCMAIN,
> >           sip@lists.bell-labs.com, "Joshua Moloney"
> >           <jmoloney@nortelnetworks.com>
> >
> >
> >
> >  Subject: RE: [SIP] Overlap call setup
> >
> >
> > Your flow is not what I had in mind.  I'll try to make
> myself clearer by
> > commenting on your flow.
> >
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> > > Sent: Thursday, February 01, 2001 10:10 AM
> > > To: Taylor, Tom-PT [NORSE:B901:EXCH]
> > > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua
> > > [MDN05:CT07:EXCH]
> > > Subject: Re: [SIP] Overlap call setup
> > >
> > >
> > >
> > > Hi,
> > >
> > > >I see the disconnect here.  You are assuming that the
> first IAM gets
> > > >propagated through the egress gateway, so an ISUP state
> > > machine is set
> > > >into play.  I think the synthesis of our thinking is this:
> > > >
> > > >(1) The first problem is to receive enough digits so an
> > > egress gateway
> > > >can be selected.  Until that happens, the digits have to be
> > > >accumulated into successive initial INVITE messages.
> > > >
> > > >(2) Once an egress gateway has been selected, call routing
> > > is complete
> > > >as far as the SIP domain is concerned.  Hence it is
> legitimate to use
> > > >the INFO method to carry subsequent digits.
> > >
> > > Let's assume the following case (hopefully I understood you
> > > correctly):
> > >
> > > You want to call 12345 on the PSTN side, and in the first
> INVITE you
> > > only send the first digit, ie.
> > >
> > > INVITE 1@pstnGW.com
> > >
> > > The GW returns 484, which you ACK.
> >
> > [PTT]
> > No.  The GW NEVER sends 484 because as far as SIP is
> concerned, call routing
> > was successful if the call got as far as the GW.  Instead,
> a proxy returns
> > 484.
> >
> > > Then you start sending digits with INFO, ie.
> > >
> > > INFO 1@pstnGW.com
> > > more-digit: 23
> >
> > [PTT]
> > Assuming it was a proxy that returned the 484, instead I
> send another
> > initial INVITE:
> >
> >   INVITE 123@pstnGW.com
> > >
> > > The GW returns 200, and we may send more INFOs with the
> rest of the
> > > digits.
> >
> > [PTT]
> > Assume this time there were enough digits to route the call
> successfully to
> > a UAS at the GW.  It would return something like a 183
> Session Progress to
> > provide a Contact and establish the call state machine. 
> The ingress GW
> > would send additional digits (and possibly encapsulated SAM
> messages) via
> > INFO.  The egress GW would start propagating the SAM
> messages once it had
> > enough digits to select next hop, but this process would be
> invisible to the
> > ingress GW.  The ACM would be sent back in a 180 or 183
> interim response as
> > appropriate, and ANM would come back in the 200 OK.
> >
> > >
> > > Now:
> > >
> > > 1. How do we know when the call is established? Since we
> have sent a
> > > final response to the INVITE, we can't send a 200 OK to it.
> > >
> > > 2. When all the digits have reached the PSTN network, there
> > > may be some
> > > early media/alerting messages etc. to be sent, but again -
> > > since the GW
> > > has sent a final response to the INVITE, 18x provisional
> > > responses can't
> > > be sent.
> > >
> > > What do you think about the following: Instead of sending
> 484, the GW
> > > sends some provisional response (ie. 186 More digits
> needed). Then we
> > > use INFO messages(s) to provide the rest of the digits,
> and when all
> > > digits have reached the PSTN side, and the call can be
> established, we
> > > receive the 200 OK to the INVITE.
> > >
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > >
> >
> >  
> --------------------------------------------------------------
> ----------
> >                   Name: att1.htm
> >    att1.htm       Type: Hypertext Markup Language (text/html)
> >               Encoding: base64
> >            Description: Internet HTML
>

------_=_NextPart_001_01C08C8A.3C4F7670-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 17:32:52 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13318 for ; Thu, 1 Feb 2001 17:32:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 723924433E; Thu, 1 Feb 2001 16:33:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id 678F94433A for ; Thu, 1 Feb 2001 16:32:29 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 558B34CE24 for ; Thu, 1 Feb 2001 17:32:12 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA12248 for ; Thu, 1 Feb 2001 17:32:11 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (SGI-8.9.3/8.8.5) id RAA89898 for sip@lists.bell-labs.com; Thu, 1 Feb 2001 17:34:22 -0500 (EST) Message-Id: <200102012234.RAA89898@fish-ha.research.att.com> To: sip@lists.bell-labs.com Subject: [SIP] 3pcc open issue with manyfolks draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 17:34:22 -0500 (EST) In San Diego, third party call control was brought up again as an issue with the manyfolks draft. I believe it is covered by the draft as it exists today, and offer the following call flow to demonstrate this. A is attempting to call B. Proxy in the middle, CC, decides that a transcoder, T, is needed in the call. Resulting call is A<->T and T<->B, with CC being the 3rd party controller of T<->B. T is assumed to not need to ring, and it will respond immediately with a 200-OK when the INVITE preconditions are satisfied. In all cases below, item n+1 in a grouping is enabled by item n. Where independent sequences start, a note indicates where the first item in the group overlaps with the previous. There is no question that this call flow is complex, and has lots of messages with the third party call controller. However, it has the very nice property that each endpoint follows exactly the same resource reservation procedures whether there is a 3pcc involved or not. All of the special handling is done by CC. Bill Marshall wtm@research.att.com 1. A --INVITE-> CC a=qos: required sendrecv 2. CC ---INVITE--> T a=qos: required sr confirm 3. CC <----183---- T a=qos: required sr confirm 4. A <---183--- CC 5. A ====RSVP=================> T 6. A --COMET--> CC a=qos: success send note that CC used a Record-Route in the 183 to force the PRACK and COMET to go through CC. This is independent of the use of a Record-Route in the 200-OK for future signaling. (also in response to the 183 message (4) above) 5. A --PRACK--> CC ---PRACK---> T 6. A <===RSVP================== T 7. CC <--COMET---- T a=qos: success send note that T is now stalled, waiting for CC to send a COMET to T. (also in response to the INVITE message (1) above) 2. CC ---INVITE--> T w/o SDP 3. CC <----183---- T a=qos: required sr confirm 4. CC -----------------INVITE----> B a=qos: required sr confirm 5. CC <------------------183------ B a=qos: required sr confirm 6. CC ------------------PRACK----> B 7. T <===RSVP===== B 8. CC <----COMET------------------ B a=qos: success send note that B is now stalled, waiting for CC to send a COMET to B (also in response to the 183 message (3) immediately above) 4. CC ---PRACK---> T a=qos: required sr confirm 5. CC T ====RSVP====> B 6. CC <--COMET---- T a=qos: success send At this point, CC knows that resources are available from A->T, from T->A, from T->B, and B->T. It is "safe" to let the call proceed. 7. CC ---COMET-------------------> B a=qos: success send 8. CC <---180--------------------- B (CC generates a 180 response for the A<->T call, knowing that T doesn't ring) 9. A <---180--- CC 10 CC <---200--------------------- B 11 CC ---COMET---> T a=qos: success send 12 CC <---200----- T 13 A <---200--- CC completes call from A<->T (also in response to the 200-OK from B, received in (10) above) 11 CC ----200----> T completes call from T<->B _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 17:43:52 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13511 for ; Thu, 1 Feb 2001 17:43:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3894044384; Thu, 1 Feb 2001 16:44:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from f1ee40-20.idc1.level3.com (machine77.Level3.com [209.244.4.106]) by lists.bell-labs.com (Postfix) with ESMTP id B154C4434F for ; Thu, 1 Feb 2001 16:43:27 -0500 (EST) Received: from n0195idc1.oss.level3.com (localhost.l3.com [127.0.0.1] (may be forged)) by f1ee40-20.idc1.level3.com (8.9.3/8.9.3) with ESMTP id WAA14694; Thu, 1 Feb 2001 22:29:11 GMT From: Jon.Peterson@Level3.com Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id <1C2JK863>; Thu, 1 Feb 2001 15:31:18 -0700 Message-ID: <6384220893BCD411BDFE0008C791B79C232D61@N0228IDC1.oss.level3.com> To: dlebovits@att.com, mwatson@nortelnetworks.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 15:27:27 -0700 This could be accomodated by having ISUP 2000 registered as a -version- with IANA, but using itu92 as a -base-. This has come up a couple of times now. Clearly, the most compatible ISUP variant characterization should appear in the base string, and version characterizations that identify additional features/options above and beyond the base should be identified in the version string. Entities that recognize the version will preserve all of the features present in ISUP 2000. I don't see why that can't work for your case. Is the version/base distinction in the draft unclear on these sorts of points? Also please do note that WG last call for this document ended some weeks ago now. Jon Peterson Level(3) Communications -----Original Message----- From: Lebovits, Doris S, ALCOO [mailto:dlebovits@att.com] Sent: Thursday, February 01, 2001 12:40 PM To: 'Mark Watson' Cc: 'sip@lists.bell-labs.com' Subject: RE: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt Mark, My concern is the ability to handle the new ISUP messages and parameters. Insure that these do not end up as unrecognized messages and parameters. Also there is a need for the new application transport message (APM) and new application transport parameter (APP) supporting APM. It is not arbitrary to select ITU-T ISUP 2000 as it is the last significant version.Having the 'base' value to encapsulated signalling based on ITU-T ISUP 2000, also covers ISUP 92, from a compatibility point of view. Doris Lebovits dlebovits@att.com ---------------------------------------------------------------------------- --------------------- -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Thursday, February 01, 2001 1:39 PM To: 'sip@lists.bell-labs.com'; Lebovits, Doris S, ALCOO Subject: RE: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt It doesn't really matter which version of ITU-T ISUP we reference - because after 1992 they are all backwards compatible with each other. The point was that there only needs to be a single 'base' value for post-1992 ITU-T ISUPs. As soon as the ISUP processor sees this, it knows that it can handle unrecognised information according to the compatibility procedure and so can sucessfully process the message. Given this, ISUP 1992 was chosen because it was the first version with the compatibility mechanism. It would be arbitrary to choose another version - why not 1997 or 2004 ?? The intent of this 'base' value is to imply that the encapsulated signalling is based on an ITU-T ISUP version 1992 or later, so it covers ISUP 2000. Regards, Mark Watson > -----Original Message----- > From: Lebovits, Doris S, ALCOO [ mailto:dlebovits@att.com ] > Sent: 01 February 2001 15:11 > To: 'Jon.Peterson@Level3.com' > Cc: ; chsharp@cisco.com > Subject: RE: [SIP] Question on "base" in > draft-ietf-sip-isup-mime-07.txt > > > > Jon, > I do not agree with your comments. I think ITU-T ISUP 2000 > should be the > base, > as it is the base going forward. ITU-T ISUP 2000 is backwards > compatible > with > previous versions such as ISUP '92. The options in ITU-T ISUP > 2000 that > would > not need to be specified for this activity could be highlighted as not > mandatory. > The ANSI version of ISUP is T1.113 and has been updated to > the ITU-T ISUP > 2000 > level and is in the final stages for publication. > > Doris Lebovits > AT&T > dlebovits@att.com > ========================================================== > > -----Original Message----- > From: Jon.Peterson@Level3.com [ mailto:Jon.Peterson@Level3.com ] > Sent: Thursday, February 01, 2001 1:06 AM > To: chsharp@cisco.com; sip@lists.bell-labs.com > Subject: RE: [SIP] Question on "base" in > draft-ietf-sip-isup-mime-07.txt > > > I think it was the hope of the authors that all of the > meaningful values for > 'base' would be characterized in the document. Since 'base' > reflects the > lowest common dominator (or, to coin a phrase, least specific > ancestor) > variant of the ISUP version in question, the authors hoped > that given the > backwards compatibility mechanism in ITU-T 1992 Q.76x, itu92 > would be the > proper base for forthcoming ISUP versions (new versions of > ANSI following > the 2000 issue support this mechanism, even). > > That much said, if there are potential 'base' values which > are of use to the > community that cannot be said to derive from itu92, the authors would > certainly like to be made aware of them. Is there anything > out there that > the ISUP MIME draft misses? > > In the face of serious concerns that useful new 'bases' might > come to light > subsequent to the publication of an RFC, I suppose management > of 'base' by > IANA could be introduced, but personally I'd rather not > trouble IANA with > this additional responsibility if there isn't a substantial > risk. Was there > anything specific you had in mind? > > Jon Peterson > Level(3) Communications > > -----Original Message----- > From: Chip Sharp [ mailto:chsharp@cisco.com ] > Sent: Tuesday, January 30, 2001 10:50 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt > > > Currently, the IANA considerations section of > draft-ietf-sip-isup-mime-07.txt describes how to define new "version" > fields, but does not describe how to define new "base" fields. > > Given that new base protocols may be identified, shouldn't there be a > description on how IANA assigns new "base" values? > > Chip > > ------------------------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems > ------------------------------------------------------------------- > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 17:45:44 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13552 for ; Thu, 1 Feb 2001 17:45:44 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 90D5D4439B; Thu, 1 Feb 2001 16:45:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 4459644398 for ; Thu, 1 Feb 2001 16:44:48 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA09550 for ; Thu, 1 Feb 2001 14:44:49 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f11Mido00887 for ; Thu, 1 Feb 2001 14:44:39 -0800 (PST) Received: from chsharp-w2k.cisco.com (chsharp-isdn.cisco.com [10.83.117.81]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id OAA03280 for ; Thu, 1 Feb 2001 14:44:32 -0800 (PST) Message-Id: <4.3.2.7.2.20010201173404.01a3af38@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: sip@lists.bell-labs.com From: Chip Sharp In-Reply-To: <20010201190701.0C3C744390@lists.bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 01 Feb 2001 17:44:10 -0500 At 02:07 PM 2/1/2001, mwatson@nortelnetworks.com wrote: >It doesn't really matter which version of ITU-T ISUP we reference - >because after 1992 they are all backwards compatible with each other. > >The point was that there only needs to be a single 'base' value for >post-1992 ITU-T ISUPs. As soon as the ISUP processor sees this, it knows >that it can handle unrecognised information according to the compatibility >procedure and so can sucessfully process the message. > >Given this, ISUP 1992 was chosen because it was the first version with the >compatibility mechanism. It would be arbitrary to choose another version - >why not 1997 or 2004 ?? > >The intent of this 'base' value is to imply that the encapsulated >signalling is based on an ITU-T ISUP version 1992 or later, so it covers >ISUP 2000. ...snip... A few questions on this: 1) Does this cover BICC (Q.1901)? 2) Does it cover forward compatibility? 3) The current bases cover ITU, USA, ETSI and Japan. What about the rest of the world? 4) What about countries that use TUP or some other non-ISUP, SS7 signaling (e.g., NUP)? I don't really think everything needs to be defined today, but what is the extension procedure when a new base needs to be defined? Or is it just hacked into a new version registered in IANA. For examle: Content-Type: application/ISUP; version=q1901; base=itu-t92+ I guess after all, base is optional so I'm not sure it matters if it is done this way. ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems ------------------------------------------------------------------- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 18:22:52 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14295 for ; Thu, 1 Feb 2001 18:22:51 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6B55A4433E; Thu, 1 Feb 2001 17:23:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from f1ee40-20.idc1.level3.com (machine77.Level3.com [209.244.4.106]) by lists.bell-labs.com (Postfix) with ESMTP id 8F9CC4433A for ; Thu, 1 Feb 2001 17:22:47 -0500 (EST) Received: from n0195idc1.oss.level3.com (localhost.l3.com [127.0.0.1] (may be forged)) by f1ee40-20.idc1.level3.com (8.9.3/8.9.3) with ESMTP id XAA03879; Thu, 1 Feb 2001 23:22:26 GMT From: Jon.Peterson@Level3.com Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id <1C2JK0G6>; Thu, 1 Feb 2001 16:24:34 -0700 Message-ID: <6384220893BCD411BDFE0008C791B79C232D62@N0228IDC1.oss.level3.com> To: chsharp@cisco.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 16:20:47 -0700 I would argue that the 'base' parameter exists pretty much to cater to the compatibility mechanism present in ITU-T 92 (which is in essence a forward compatibility mechanism from the perspective of that issue). If other ISUP variants unrelated to itu92 have independent compatibility mechanisms, then this is perhaps something we should consider, but I don't think the authors of the draft are aware of any. As you point out, 'base' is optional - I believe that outside of strongly ITU-grounded networks, it will not see substantial use. And is it just me, or is the idea that BICC will be encapsulated in SIP somewhat counterintuitive? Are there any services today that require that? Anyway, if there is interest I'd be inclined to say that BICC should have it's own MIME type which should be discussed on its own merits. Jon Peterson Level(3) Communications -----Original Message----- From: Chip Sharp [mailto:chsharp@cisco.com] Sent: Thursday, February 01, 2001 3:44 PM To: sip@lists.bell-labs.com Subject: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs At 02:07 PM 2/1/2001, mwatson@nortelnetworks.com wrote: >It doesn't really matter which version of ITU-T ISUP we reference - >because after 1992 they are all backwards compatible with each other. > >The point was that there only needs to be a single 'base' value for >post-1992 ITU-T ISUPs. As soon as the ISUP processor sees this, it knows >that it can handle unrecognised information according to the compatibility >procedure and so can sucessfully process the message. > >Given this, ISUP 1992 was chosen because it was the first version with the >compatibility mechanism. It would be arbitrary to choose another version - >why not 1997 or 2004 ?? > >The intent of this 'base' value is to imply that the encapsulated >signalling is based on an ITU-T ISUP version 1992 or later, so it covers >ISUP 2000. ...snip... A few questions on this: 1) Does this cover BICC (Q.1901)? 2) Does it cover forward compatibility? 3) The current bases cover ITU, USA, ETSI and Japan. What about the rest of the world? 4) What about countries that use TUP or some other non-ISUP, SS7 signaling (e.g., NUP)? I don't really think everything needs to be defined today, but what is the extension procedure when a new base needs to be defined? Or is it just hacked into a new version registered in IANA. For examle: Content-Type: application/ISUP; version=q1901; base=itu-t92+ I guess after all, base is optional so I'm not sure it matters if it is done this way. ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems ------------------------------------------------------------------- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 20:54:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16963 for ; Thu, 1 Feb 2001 20:54:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 76B304433E; Thu, 1 Feb 2001 19:55:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id E6A424433A for ; Thu, 1 Feb 2001 19:54:35 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id <1DWCS31T>; Thu, 1 Feb 2001 17:54:12 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Henning G. Schulzrinne'" , "'kns10@cs.columbia.edu'" Cc: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08CBB.0A1F2480" Subject: [SIP] Interworking Between SIP/SDP and H.323 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 1 Feb 2001 17:54:12 -0800 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_01C08CBB.0A1F2480 Content-Type: text/plain; charset="iso-8859-1" Hi Henning & Kundan, I have a query with regards to draft-singh-sip-h323-01.txt. The draft states that the destination information from the H.323 call be derived from the To URL in a new INVITE (see A.1.2). It seems that the request-URI is ignored entirely (despite the fact that some of the call flows are annotated with "INVITE sip:kns10@cs.columbia.edu"). I do not see how this will work when a SIP UA or proxy redirects (or proxies with updating the request) call to a H.323 device. For example: INVITE sip:rfairlie@nuera.com SIP/2.0 To: "Robert Fairlie-Cuninghame" is sent to the proxy at nuera.com which responds with a SIP/2.0 302 Temp Moved Contact: How will this work if the IWF ignores the Request-URI ? If the IWF instead uses the request URI in the H323 SETUP destinationInfo, is there anythign wrong with it using the display name from the To? Unless a 380 Alternate Service is issued then the display name should still be correct. On a related note in the base SIP spec, if a 380 Alternate Service is issued (which requires user interaction), the spec needs to be clarified whether the new call attempt will use a new call-leg with the To field changed apprpriately. Cheers, Robert. ------_=_NextPart_001_01C08CBB.0A1F2480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Interworking Between SIP/SDP and H.323

Hi Henning & Kundan,

I have a query with regards to = draft-singh-sip-h323-01.txt.

The draft states that the destination information = from the H.323 call be derived from the To URL in a new INVITE (see = A.1.2). It seems that the request-URI is ignored entirely (despite the = fact that some of the call flows are annotated with "INVITE = sip:kns10@cs.columbia.edu").

I do not see how this will work when a SIP UA or = proxy redirects (or proxies with updating the request) call to a H.323 = device.

For example:

INVITE sip:rfairlie@nuera.com SIP/2.0
To: "Robert Fairlie-Cuninghame" = <sip:rfairlie@nuera.com>

is sent to the proxy at nuera.com which responds with = a SIP/2.0 302 Temp Moved
Contact: = <sip:1000@h323-gatekeeper.nuera.com;maddr=3Dh323-iwf.nuera.com>

How will this work if the IWF ignores the Request-URI = ?

If the IWF instead uses the request URI in the H323 = SETUP destinationInfo, is there anythign wrong with it using the = display name from the To? Unless a 380 Alternate Service is issued then = the display name should still be correct.

On a related note in the base SIP spec, if a 380 = Alternate Service is issued (which requires user interaction), the spec = needs to be clarified whether the new call attempt will use a new = call-leg with the To field changed apprpriately.

Cheers,

Robert.

------_=_NextPart_001_01C08CBB.0A1F2480-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 1 22:49:53 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19631 for ; Thu, 1 Feb 2001 22:49:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 43AAE44341; Thu, 1 Feb 2001 21:50:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 50E974433A for ; Thu, 1 Feb 2001 21:49:10 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id TAA27105; Thu, 1 Feb 2001 19:48:36 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f12334i17860; Thu, 1 Feb 2001 19:03:05 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id TAA14213; Thu, 1 Feb 2001 19:02:51 -0800 (PST) Message-ID: <3A7A240A.E38BDC88@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] SIP Privacy Draft References: Content-Type: multipart/alternative; boundary="------------6648975632985FC3CB913ACE" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 01 Feb 2001 22:05:46 -0500 --------------6648975632985FC3CB913ACE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Watson wrote: > > > 4) Handling of privacy requirements > > The above implies that the Remote-Party-ID header could be repeated to > specify multiple parties and multiple types of identity for each > party. Because of this the privacy handling should be on a > per-Remote-Party-ID basis - i.e. by tags in the header, not a separate > Anonymity header. Just to clarify, we still need the Anonymity header for the IP-address privacy case. -- Flemming -- Flemming Andreasen Cisco Systems --------------6648975632985FC3CB913ACE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Mark Watson wrote:

<snip>

 

4) Handling of privacy requirements

The above implies that the Remote-Party-ID header could be repeated to specify multiple parties and multiple types of identity for each party. Because of this the privacy handling should be on a per-Remote-Party-ID basis - i.e. by tags in the header, not a separate Anonymity header.


Just to clarify, we still need the Anonymity header for the IP-address privacy case.
 

-- Flemming
 

--
Flemming Andreasen
Cisco Systems
  --------------6648975632985FC3CB913ACE-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 01:17:53 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22391 for ; Fri, 2 Feb 2001 01:17:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E794F4433A; Fri, 2 Feb 2001 00:18:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 2A9CD44336 for ; Fri, 2 Feb 2001 00:17:07 -0500 (EST) 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 f126GnC17480; Fri, 2 Feb 2001 07:16:49 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA05482; Fri, 2 Feb 2001 08:16:48 +0200 (EET) Message-ID: <3A7A50CB.4BA990CF@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor Cc: Keith Robinson , sip@lists.bell-labs.com, Joshua Moloney Subject: Re: [SIP] Overlap call setup References: <28560036253BD41191A10000F8BCBD11038E428C@zcard00g.ca.nortel.com> Content-Type: multipart/mixed; boundary="------------19C6A82B9D14FB5D09EE1301" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 02 Feb 2001 08:16:43 +0200 This is a multi-part message in MIME format. --------------19C6A82B9D14FB5D09EE1301 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I see a couple of issues here. 1. Even if the UAS returns Accept-Encoding: application/isup, it doesn't mean that it is going to send an encapsulated ACM. 2. Even if it the UAS GW would send an encapsulated ACM, it is not sure that the UAC GW supports ISUP transparency in the first place. It may support only ISUP/SIP mapping, for example. I think that part of the problem, which is not related only to overlap dialling, is that a SIP/PSTN GW from a SIP point of view is an SIP UA, and from a SIP point of view should act like an SIP UA. Maybe it should be considered as a SIP node of its own, with GW specific functional requirements. The only thing we have now is how to map between ISUP and SIP, but that is obviously not enough. ??? Regards, Christer Holmberg Ericsson Finland --------------19C6A82B9D14FB5D09EE1301 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 --------------19C6A82B9D14FB5D09EE1301-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 01:39:55 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25213 for ; Fri, 2 Feb 2001 01:39:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 14BE84434B; Fri, 2 Feb 2001 00:40:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id D5A6044348 for ; Fri, 2 Feb 2001 00:39:44 -0500 (EST) 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 f126dTd23658; Fri, 2 Feb 2001 07:39:29 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA07826; Fri, 2 Feb 2001 08:39:29 +0200 (EET) Message-ID: <3A7A561C.9C1E6F42@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Henning G. Schulzrinne'" , "'Grant McSheffrey'" , Sip List Subject: Re: [SIP] Timestamp header References: Content-Type: multipart/mixed; boundary="------------468D6E11650BFFDD1FD1AFC4" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 02 Feb 2001 08:39:24 +0200 This is a multi-part message in MIME format. --------------468D6E11650BFFDD1FD1AFC4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This has probably been discussed before, but I will give my comment anyway. If a UAC only wants to know the time between a request and a response (provisional or final, depending on what the UAC wants to know) I see no reason to add a header which only has to be echoed. Instead, the UAC could save the request-sent-time together with the rest of the transaction data, and then calculate the time when the response is received. And, if any other node, for some reason, really needs the time, it could send an "Extension required" response. Of course, the UAC could choose to always include the Timestamp header in every request, but it shouldn't be mandatory to echo it. From a SIP standard point of view this is not a big issue, but I am only trying to keep the network packages as small as possible :) Regards, Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, January 16, 2001 10:25 AM > > To: Jonathan Rosenberg > > Cc: 'Grant McSheffrey'; Sip List > > Subject: Re: [SIP] Timestamp header > > > > > > Jonathan Rosenberg wrote: > > > > > > The spec is not clear on this, saying simply that it should > > be echoed. I > > > would imagine placing it in all responses, provisional and > > final, makes the > > > most sense. > > > > Note that because of the different origins, the delay for the 100 may > > differ from the other 1xx and the final response. > > Hmm. This brings up some more issues. > > If the purpose of the Timestamp header is to determine RTT for > retransmission rates, then what you really want is the delay between the UAC > and the *first stateful entity* (be it stateful proxy or UAS/redirect) on > the call path, since retransmissions terminate there. The final responses > are from UAS to UAC, which is going to have an RTT much higher than the UAC > to first stateful proxy. In fact, in this case, the 100 response is the ONLY > place that Timestamp would be useful. > > Other applications of timestamp (not sure what they are, though) might make > an end to end measurement useful. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. --------------468D6E11650BFFDD1FD1AFC4 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 --------------468D6E11650BFFDD1FD1AFC4-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 09:08:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09152 for ; Fri, 2 Feb 2001 09:08:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6DFE444340; Fri, 2 Feb 2001 08:09:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id D1DAD44336 for ; Fri, 2 Feb 2001 08:08:30 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA28865; Fri, 2 Feb 2001 09:08:14 -0500 (EST) Message-ID: <3A7ABF4D.6389491C@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: Jonathan Rosenberg , "'Grant McSheffrey'" , Sip List Subject: Re: [SIP] Timestamp header References: <3A7A561C.9C1E6F42@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 02 Feb 2001 09:08:13 -0500 Content-Transfer-Encoding: 7bit The timestamp header is needed to distinguish between retransmissions of the same request, which will otherwise look identical. Determining the round-trip and the ACK ambiguity is a classical TCP problem. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 09:17:53 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09615 for ; Fri, 2 Feb 2001 09:17:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 258F444350; Fri, 2 Feb 2001 08:18:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 9DC1244343 for ; Fri, 2 Feb 2001 08:17:45 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 2 Feb 2001 09:12:42 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 2 Feb 2001 09:12:42 -0500 Message-ID: <28560036253BD41191A10000F8BCBD1103928EC9@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Christer Holmberg Cc: Keith Robinson , sip@lists.bell-labs.com, "Joshua Moloney" Subject: RE: [SIP] Overlap call setup MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D22.3367A990" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 2 Feb 2001 09:12:39 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08D22.3367A990 Content-Type: text/plain; charset="ISO-8859-1" Replies below. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Friday, February 02, 2001 1:17 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > [MDN05:CT07:EXCH] > Subject: Re: [SIP] Overlap call setup > > > > Hi, > > I see a couple of issues here. > > 1. Even if the UAS returns Accept-Encoding: application/isup, > it doesn't > mean that it is going to send an encapsulated ACM. [PTT] Agreed, and that is a nasty point. It's related to the next one. > > 2. Even if it the UAS GW would send an encapsulated ACM, it > is not sure > that the UAC GW supports ISUP transparency in the first place. It may > support only ISUP/SIP mapping, for example. [PTT] That one is easily solved, in two ways. First, by hypothesis the UAC GW has encapsulated the IAM in the initial INVITE. It can also include an Accept-Content: header. In fact, this is essential so that the two ends can negotiate stuff like ISUP version or the fact that one of them really wants to propagate Q.931. So, given that the UAS GW has received an encapsulated IAM, the Accept-Content: header indicates that it did or did not find the encapsulated content acceptable. If it did find it acceptable, how do we oblige it to keep up its end of the conversation? I expect the behaviour has to be specified in the SIP-T umbrella document, and SIP/GSTN gateway products have to indicate their conformity to that document. > > I think that part of the problem, which is not related only to overlap > dialling, is that a SIP/PSTN GW from a SIP point of view is an SIP UA, > and from a SIP point of view should act like an SIP UA. Maybe > it should > be considered as a SIP node of its own, with GW specific functional > requirements. The only thing we have now is how to map > between ISUP and > SIP, but that is obviously not enough. ??? > > Regards, > > Christer Holmberg > Ericsson Finland > ------_=_NextPart_001_01C08D22.3367A990 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Overlap call setup

Replies below.

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: Friday, February 02, 2001 1:17 AM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: Keith Robinson; sip@lists.bell-labs.com; = Moloney, Joshua
> [MDN05:CT07:EXCH]
> Subject: Re: [SIP] Overlap call setup
>
>
>
> Hi,
>
> I see a couple of issues here.
>
> 1. Even if the UAS returns Accept-Encoding: = application/isup,
> it doesn't
> mean that it is going to send an encapsulated = ACM.

[PTT]
Agreed, and that is a nasty point.  It's = related to the next one.

>
> 2. Even if it the UAS GW would send an = encapsulated ACM, it
> is not sure
> that the UAC GW supports ISUP transparency in = the first place. It may
> support only ISUP/SIP mapping, for = example.

[PTT]
That one is easily solved, in two ways.  First, = by hypothesis the UAC GW has encapsulated the IAM in the initial = INVITE.  It can also include an Accept-Content: header.  In = fact, this is essential so that the two ends can negotiate stuff like = ISUP version or the fact that one of them really wants to propagate = Q.931.

So, given that the UAS GW has received an = encapsulated IAM, the Accept-Content: header indicates that it did or = did not find the encapsulated content acceptable.  If it did find = it acceptable, how do we oblige it to keep up its end of the = conversation?  I expect the behaviour has to be specified in the = SIP-T umbrella document, and SIP/GSTN gateway products have to indicate = their conformity to that document.

>
> I think that part of the problem, which is not = related only to overlap
> dialling, is that a SIP/PSTN GW from a SIP = point of view is an SIP UA,
> and from a SIP point of view should act like an = SIP UA. Maybe
> it should
> be considered as a SIP node of its own, with GW = specific functional
> requirements. The only thing we have now is how = to map
> between ISUP and
> SIP, but that is obviously not enough. = ???
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>

------_=_NextPart_001_01C08D22.3367A990-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 09:28:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10097 for ; Fri, 2 Feb 2001 09:28:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 41D324436A; Fri, 2 Feb 2001 08:29:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 0ADA244368 for ; Fri, 2 Feb 2001 08:28:37 -0500 (EST) 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 JAA22377; Fri, 2 Feb 2001 09:28:21 -0500 (EST) 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 JAA11469; Fri, 2 Feb 2001 09:28:24 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Feb 2001 09:28:11 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EE16@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jon.Peterson@Level3.com'" , chsharp@cisco.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 2 Feb 2001 09:28:21 -0500 > And is it just me, or is the idea that BICC will be > encapsulated in SIP > somewhat counterintuitive? Are there any services today that > require that? > Anyway, if there is interest I'd be inclined to say that BICC > should have > it's own MIME type which should be discussed on its own merits. So, SIP-T is used for, among other things, ISUP-SIP-ISUP. You don't think anyone wants to do BICC-SIP-BICC when SIP is one operator's network, and the BICCs are two other operators? I also see BICC-SIP-ISUP and of course ISUP-BICC-SIP-ISUP and variations. Brian _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 10:13:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11406 for ; Fri, 2 Feb 2001 10:13:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 97B1244352; Fri, 2 Feb 2001 09:14:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id 2340B44336 for ; Fri, 2 Feb 2001 09:13:03 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qhars002.nortel.com; Fri, 2 Feb 2001 15:11:18 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Feb 2001 15:11:15 -0000 Message-ID: From: "Michael O'Doherty" To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D2A.60011380" Subject: [SIP] SIP in small adhoc and Pico networks Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 2 Feb 2001 15:11:10 -0000 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_01C08D2A.60011380 Content-Type: text/plain; charset="iso-8859-1" Hi, The draft below has been submitted and is now available online. It discusses the use of SIP in small adhoc and Pico networks. The intention is not to imply that using SIP for session control in these type of networks is necessarily a use of SIP that leverages the strengths of the protocol, rather to recognize that there may be SIP based applications that a user wants to use in the usual way between locally available clients without any changes to his application while attached to such networks. Comments or feedback would be welcome. Cheers, Mick O'Doherty Nortel Networks -----------------------> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Pico SIP Author(s) : M. O'Doherty Filename : draft-odoherty-pico-sip-00.txt Pages : 8 Date : 30-Jan-01 This document defines an extension to the SIP protocol to allow it be used in adhoc networks or Pico Networks. It leverages the direct, client to client session initiation capabilities of SIP, although there may be applications where the redirect and proxying abilities will be important also. Note the intention is not to imply that SIP is inherently the best protocol for such networks, but to recognize that there will likely be many SIP based applications in existence and that it would be good to allow these applications work with as little change as possible in this different type of network. A URL for this Internet-Draft is: 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-odoherty-pico-sip-00.txt". A list of Internet-Drafts directories can be found in or Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-odoherty-pico-sip-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. draft-odoherty-pico-sip-00.txt ------_=_NextPart_001_01C08D2A.60011380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP in small adhoc and Pico networks

Hi,

The draft below has been = submitted and is now available online. It discusses the use of SIP in = small adhoc and Pico networks.

The intention is not to imply = that using SIP for session control in these type of networks is = necessarily a use of SIP that leverages the strengths of the protocol, = rather to recognize that there may be SIP based applications that a = user wants to use in the usual way  between locally available = clients without any changes to his application while attached to such = networks.

Comments or feedback would be = welcome.

Cheers,

Mick O'Doherty
Nortel Networks

----------------------->

A New Internet-Draft is = available from the on-line Internet-Drafts directories.


        Title   =         : Pico SIP
        Author(s)       : M. = O'Doherty
        Filename        = : draft-odoherty-pico-sip-00.txt
        Pages   =         : 8
        Date    =         : 30-Jan-01
       =20
This document defines an = extension to the SIP protocol to allow
it be used in adhoc networks or = Pico Networks. It leverages the
direct, client to client = session initiation capabilities of SIP,
although there may be = applications where the redirect and
proxying abilities will be = important also. Note the intention is
not to imply that SIP is = inherently the best protocol for such
networks, but to recognize that = there will likely be many SIP
based applications in existence = and that it would be good to
allow these applications work = with as little change as possible
in this different type of = network.

A URL for this Internet-Draft = is:
<http://www.ietf.org/internet-drafts/draft-odoherty-pic= o-sip-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-odoherty-pico-sip-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-odoherty-pico-sip-00.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will = enable a MIME compliant mail reader
implementation to automatically = retrieve the ASCII version of the
Internet-Draft.
draft-odoherty-pico-sip-00.txt <bin00056.bin>

------_=_NextPart_001_01C08D2A.60011380-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 13:21:55 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20203 for ; Fri, 2 Feb 2001 13:21:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C01024435B; Fri, 2 Feb 2001 12:22:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 6651F44348 for ; Fri, 2 Feb 2001 12:21:24 -0500 (EST) Received: from cisalpino.cs.columbia.edu (cisalpino.cs.columbia.edu [128.59.19.194]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA13884; Fri, 2 Feb 2001 13:21:10 -0500 (EST) Received: from localhost (kns10@localhost) by cisalpino.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA15464; Fri, 2 Feb 2001 13:21:05 -0500 (EST) From: Kundan Singh To: "Fairlie-Cuninghame, Robert" Cc: , Subject: Re: [SIP] Interworking Between SIP/SDP and H.323 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 2 Feb 2001 13:21:05 -0500 (EST) > Hi Henning & Kundan, > > I have a query with regards to draft-singh-sip-h323-01.txt. > > The draft states that the destination information from the H.323 call be > derived from the To URL in a new INVITE (see A.1.2). It seems that the > request-URI is ignored entirely (despite the fact that some of the call This is an error. The signaling gateway should use the Request-URI instead of To: URL. This occurs at more than one place in the draft. We will correct this in the next version. Thanks for pointing out the mistake. Kundan > flows are annotated with "INVITE sip:kns10@cs.columbia.edu"). > > I do not see how this will work when a SIP UA or proxy redirects (or proxies > with updating the request) call to a H.323 device. > > For example: > > INVITE sip:rfairlie@nuera.com SIP/2.0 > To: "Robert Fairlie-Cuninghame" > > is sent to the proxy at nuera.com which responds with a SIP/2.0 302 Temp > Moved > Contact: > > How will this work if the IWF ignores the Request-URI ? > > If the IWF instead uses the request URI in the H323 SETUP destinationInfo, > is there anythign wrong with it using the display name from the To? Unless a > 380 Alternate Service is issued then the display name should still be > correct. > > On a related note in the base SIP spec, if a 380 Alternate Service is issued > (which requires user interaction), the spec needs to be clarified whether > the new call attempt will use a new call-leg with the To field changed > apprpriately. > > Cheers, > > Robert. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 13:30:53 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20735 for ; Fri, 2 Feb 2001 13:30:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C7B34434F; Fri, 2 Feb 2001 12:31:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 8421044336 for ; Fri, 2 Feb 2001 12:30:05 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA13195; Fri, 2 Feb 2001 13:10:57 -0500 (EST) Message-ID: <3A7AF830.C4850A4E@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Michael O'Doherty" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP in small adhoc and Pico networks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 02 Feb 2001 13:10:56 -0500 Content-Transfer-Encoding: 7bit Interesting idea. I would think that REGISTER, in peer-to-peer mode effectively, would fit pretty well. In a sense, every piconet member is a registrar. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 14:09:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22882 for ; Fri, 2 Feb 2001 14:09:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 899084435C; Fri, 2 Feb 2001 13:10:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange.NeTrue.com (unknown [207.104.210.242]) by lists.bell-labs.com (Postfix) with ESMTP id 2D98F44348 for ; Fri, 2 Feb 2001 13:09:17 -0500 (EST) Received: from rchen (rchen.netrue.com [207.104.210.210]) by exchange.NeTrue.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1167KVV2; Fri, 2 Feb 2001 11:09:55 -0800 Message-ID: <048e01c08d4b$666fcb00$d2d268cf@netrue.com> From: "Robert Chen" To: "Henning G. Schulzrinne" , "Michael O'Doherty" Cc: , "SIPMailingList" References: <3A7AF830.C4850A4E@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [SIP] Please help me about implement a simple SIP proxy server Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 2 Feb 2001 11:07:31 -0800 Content-Transfer-Encoding: 7bit hi, We do not want have a database. We do not want to implement Register messages. How can I location? For example, a message from our company out to sip:bob@lucent.com , how can I get the IP address of bob@lucent.com , some articles say use DNS. But I do not know how to implement this with DNS. I have no experience about this. Please help!!! Best wishes! Yours sincerely, Robert Chen ___________________________________ Cisco Certified Network Associate Oracle Certified Professional DBA SUN Certified Solaris7 System Administrator SUN Certified Solaris7 Network Administrator ----- Original Message ----- From: "Henning G. Schulzrinne" To: "Michael O'Doherty" Cc: Sent: Friday, February 02, 2001 10:10 AM Subject: Re: [SIP] SIP in small adhoc and Pico networks > Interesting idea. I would think that REGISTER, in peer-to-peer mode > effectively, would fit pretty well. In a sense, every piconet member is > a registrar. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 14:39:52 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24048 for ; Fri, 2 Feb 2001 14:39:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A24C4437C; Fri, 2 Feb 2001 13:40:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx1pya.telcordia.com (dnsmx1pya.telcordia.com [128.96.20.31]) by lists.bell-labs.com (Postfix) with ESMTP id 58B2444336 for ; Fri, 2 Feb 2001 13:39:12 -0500 (EST) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id OAA14970; Fri, 2 Feb 2001 14:19:29 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852569E7.006A2373 ; Fri, 2 Feb 2001 14:19:18 -0500 X-Lotus-FromDomain: TELCORDIA From: "Ashutosh Dutta" To: "Michael O'Doherty" Cc: sip@lists.bell-labs.com Message-ID: <852569E7.006A2312.00@notes949.cc.telcordia.com> Subject: Re: [SIP] SIP in small adhoc and Pico networks Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 2 Feb 2001 14:18:50 -0500 Michael, would you assume each Piconet member in the same subnet (broadcast domain), can we define a well defined multicast address to get the listing of the users with SIP UA enabled in the neighborhood, and their contact address, may be by using something like SAP/SDP. Thanks Ashutosh _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 14:56:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24912 for ; Fri, 2 Feb 2001 14:56:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 91DAD44376; Fri, 2 Feb 2001 13:57:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id C402A44343 for ; Fri, 2 Feb 2001 13:56:18 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA19950; Fri, 2 Feb 2001 14:56:05 -0500 (EST) Message-ID: <3A7B10D4.D65A424B@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP Privacy Draft References: <200102011635.LAA64884@fish-ha.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 02 Feb 2001 14:56:04 -0500 Content-Transfer-Encoding: 7bit William Marshall wrote: > > Mark Watson's update on the privacy draft discussions reminded me > that I had an action item to bring to the list, regarding multiple > 180 responses in a SIP session. > > When a SIP call is delivered to a PSTN gateway, and thus to a PSTN > endpoint (B), B may have call forwarding established to (C). In some > cases (which I admit to not understanding completely) the SS7 signaling > could identify endpoint B as a destination that is ringing, and later > identify endpoint C as an updated destination that is ringing. > Presumably if C forwards to D, and D forwards to E, etc etc etc, there > could be a whole sequence of indications received by the PSTN gateway > about ringing endpoints. > > The question is whether these {may/should/shouldnot} result in multiple > 180-Ringing SIP responses. I don't see anything in 2543 or 2543bis > that limits a UAS to sending a single 180 response, but it doesn't > seem like expected behavior. So, {should/must} a standard UAC handle > multiple 180 responses? > There are no restrictions on any 1xx responses, in terms of number, ordering and type. Thus, any combination and sequence of 1xx has to be handled correctly, including several 1xx with the same status code. The spec says: A server {\MAY} issue zero or more 1xx responses, with no restriction on their ordering or uniqueness. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 17:37:24 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03074 for ; Fri, 2 Feb 2001 17:37:24 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4757844346; Fri, 2 Feb 2001 16:37:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 421F144336 for ; Fri, 2 Feb 2001 16:36:52 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA12389 for ; Fri, 2 Feb 2001 17:39:37 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 2 Feb 2001 17:33:05 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F304759F@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C08D68.1BA78D4D" Subject: [SIP] REFER revision Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 2 Feb 2001 17:33:03 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C08D68.1BA78D4D Content-Type: text/plain Here is REFER using NOTIFYs from implicit Subscriptions to get around the transaction timeout problem. I've submitted this to the draft repository, but wanted to get it into the hands of those attending next week's meeting as early as I could. RjS ------_=_NextPart_000_01C08D68.1BA78D4D Content-Type: text/plain; name="draft-ietf-sip-cc-transfer-03.txt" Content-Disposition: attachment; filename="draft-ietf-sip-cc-transfer-03.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= Internet Engineering Task Force R. = Sparks=0A= Internet-Draft = dynamicsoft=0A= Expires: August 3, 2001 February 2, = 2001=0A= =0A= =0A= SIP Call Control - Transfer=0A= draft-sip-cc-transfer-03=0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance = with=0A= all provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as=0A= Internet-Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six=0A= months and may be updated, replaced, or obsoleted by other = documents=0A= at any time. It is inappropriate to use Internet-Drafts as = reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on August 3, 2001.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2001). All Rights Reserved.=0A= =0A= Abstract=0A= =0A= This document defines a SIP extension within the Call Control=0A= Framework and demonstrates its use to provide Call Transfer=0A= capabilities. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 1]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . = 3=0A= 2. Changes from draft-sparks-sip-cc-transfer-02 . . . . . . . . = 3=0A= 3. The REFER Method . . . . . . . . . . . . . . . . . . . . . . = 3=0A= 3.1 The Refer-To Header . . . . . . . . . . . . . . . . . . . . = 3=0A= 3.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . = 4=0A= 3.2 The Referred-By Header . . . . . . . . . . . . . . . . . . . = 4=0A= 3.2.1 A PGP based signature-scheme . . . . . . . . . . . . . . . . = 5=0A= 3.2.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . = 5=0A= 3.3 Header Field Support for the REFER Method . . . . . . . . . = 6=0A= 3.4 Message Body Inclusion . . . . . . . . . . . . . . . . . . . = 7=0A= 3.5 Responses within the REFER transaction . . . . . . . . . . . = 7=0A= 3.6 Behavior of SIP User Agents . . . . . . . . . . . . . . . . = 7=0A= 3.6.1 Accessing the referred-to resource . . . . . . . . . . . . . = 7=0A= 3.6.2 Reporting on the results of the reference . . . . . . . . . = 8=0A= 3.7 Behavior of SIP Registrars/Redirect Servers . . . . . . . . = 8=0A= 3.8 Behavior of SIP Proxies . . . . . . . . . . . . . . . . . . = 8=0A= 3.9 Prototypical REFER callflow . . . . . . . . . . . . . . . . = 9=0A= 3.10 Security Considerations . . . . . . . . . . . . . . . . . . = 9=0A= 4. Call Transfer . . . . . . . . . . . . . . . . . . . . . . . = 9=0A= 4.1 Actors and Roles . . . . . . . . . . . . . . . . . . . . . . = 9=0A= 4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . = 10=0A= 4.3 Using REFER to achieve Call Transfer . . . . . . . . . . . . = 10=0A= 4.4 Unattended Transfer . . . . . . . . . . . . . . . . . . . . = 11=0A= 4.4.1 Successful Unattended Transfer . . . . . . . . . . . . . . . = 12=0A= 4.4.2 Failed Unattended Transfer . . . . . . . . . . . . . . . . . = 13=0A= 4.5 Unattended Transfer with Consultation Hold . . . . . . . . . = 13=0A= 4.5.1 Variation 1 : Exposes transfer target . . . . . . . . . . . = 14=0A= 4.5.2 Variation 2 : Protects transfer target . . . . . . . . . . . = 15=0A= 4.5.3 Consultation Hold in the presence of forking proxies . . . . = 15=0A= 4.6 Attended Transfer . . . . . . . . . . . . . . . . . . . . . = 16=0A= 4.7 Transfer with multiple parties . . . . . . . . . . . . . . . = 16=0A= 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . = 17=0A= 5.1 200 vs 202 . . . . . . . . . . . . . . . . . . . . . . . . . = 17=0A= 5.2 Should REFER expire? . . . . . . . . . . . . . . . . . . . . = 17=0A= 5.3 REFER is now dependent on sip-events . . . . . . . . . . . . = 17=0A= 5.4 Registering the events with IANA . . . . . . . . . . . . . . = 18=0A= 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . = 18=0A= References . . . . . . . . . . . . . . . . . . . . . . . . . = 18=0A= Author's Address . . . . . . . . . . . . . . . . . . . . . . = 18=0A= Full Copyright Statement . . . . . . . . . . . . . . . . . . = 19=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 2]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 1. Overview=0A= =0A= This document defines a SIP[1] extension and details its use to=0A= provide Call Transfer capabilities. This is part of a family of = Call=0A= Control extensions described in the Call Control Framework[2]=0A= document. =0A= =0A= The mechanisms discussed here are most closely related to=0A= traditional unattended and consultation hold transfers. = Discussion=0A= of attended transfer (where all parties are briefly in a = conference)=0A= is deferred until the conferencing features in this framework are=0A= addressed. =0A= =0A= This work has roots in draft-ietf-sip-cc-01[4] but some basic=0A= semantics are different. In particular, transfers are achieved=0A= through a new method that does not terminate the original = signaling=0A= relationship. By disassociating transfers from the processing of=0A= BYE, these changes facilitate recovery of failed transfers and=0A= clarify state management in the participating entities. =0A= =0A= 2. Changes from draft-sparks-sip-cc-transfer-02=0A= o Changed the REFER response to be immediate instead of waiting = for=0A= the referred action to complete=0A= o Added use of NOTIFY to deliver the result of the referred = action=0A= o Removed the claim of easy migration from BYE/ALSO=0A= =0A= 3. The REFER Method=0A= =0A= REFER is a SIP method as defined by RFC2543[1]. The REFER method=0A= indicates that the recipient should contact a third party using = the=0A= contact information provided in the method. A success response=0A= indicates that the recipient was able to contact the third party.=0A= The REFER method follows the session's current signaling path. In=0A= particular, the Request-URI of the REFER method identifies the=0A= recipient. =0A= =0A= Unless stated otherwise, the protocol for emitting and responding = to=0A= a REFER request are identical to those for a BYE request in [1]. = The=0A= behavior of SIP entities not implementing the REFER (or any other=0A= unknown) method is explicitly defined in [1] and is not discussed=0A= further here. =0A= =0A= 3.1 The Refer-To Header=0A= =0A= Refer-To is a request-header as defined by [1]. It may only = appear=0A= in a REFER request. =0A= =0A= Refer-To =3D ("Refer-To" | "r") ":" URL =0A= =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 3]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= A REFER method MUST contain exactly one Refer-To header. =0A= =0A= The Refer-To header MAY be encrypted as part of end-end encryption. = =0A= =0A= The Contact header is an important part of the=0A= Route/Record-Route mechanism and is not available=0A= for this task.=0A= =0A= 3.1.1 Examples=0A= =0A= Refer-To: sip:alice@atlanta.com=0A= =0A= Refer-To:=0A= sip:bob@biloxi.com?Accept-Contact=3Dsip:bobsdesk.biloxi.com?Ca=0A= ll-ID=3D55432@alicepc.atlanta.com=0A= =0A= Refer-To: sip:carol@cleveland.com;method=3DSUBSCRIBE=0A= =0A= Refer-To: http://www.ietf.org=0A= =0A= 3.2 The Referred-By Header=0A= =0A= Referred-By is a request-header as defined by [1]. It can appear = in=0A= any request. It conveys the identity of the original REFERrer to = the=0A= referred-to party, optionally proving the identity and that the=0A= REFERrer actually issued this reference. =0A= =0A= =0A= Referred-By =3D ("Referred-By" | "b") ":" referrer-url = ";"=0A= ( referenced-url=0A= | ( referenced-url ";" ref-signature = )=0A= | ( ref-signature ";" referenced-url = )=0A= )=0A= referrer-url =3D ( name-addr | addr-spec )=0A= referenced-url =3D "ref" "=3D" "<" URL ">"=0A= ref-signature =3D signature-scheme *( ";" sig-scheme-params = )=0A= signature-scheme =3D "scheme" "=3D" token=0A= sig-scheme-parms =3D token "=3D" ( token | quoted-string )=0A= =0A= The referrer-url contains the SIP URL of the party sending the = REFER=0A= request. The referenced-url contains a copy of the URL placed in = the=0A= Refer-To: header. Any occurrences of < or > in the referenced-url=0A= MUST be escaped. The ref-signature contains a signature over the=0A= concatenation of referrer-url and referenced-url. An example=0A= signature scheme is given in section 3.1.2. =0A= =0A= A REFER request MUST contain exactly one Referred-By header. =0A= =0A= (Open Issue: Should Refer Expire? (Section 5.2).) =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 4]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= The Referred-By header SHOULD be signed to help detection of = REFERs=0A= from unauthorized third parties. A signed Referred-By header = SHOULD=0A= include a Date header in the referrer-url to facilitate detection = of=0A= replay attacks. =0A= =0A= A UA MAY reject a request containing an unsigned Referred-By = header.=0A= A UA SHOULD verify the signature on any Referred-By header it=0A= receives. =0A= =0A= The Referred-By header MAY be encrypted as part of end-end=0A= encryption. =0A= =0A= 3.2.1 A PGP based signature-scheme=0A= =0A= One signature-scheme for Referred-By headers uses PGP as follows: = =0A= =0A= signature-scheme =3D "scheme" "=3D" "pgp"=0A= sig-scheme-parms =3D pgp-version | signed-by | pgp-signature=0A= =0A= pgp-version, signed-by and pgp-signature are defined in section = 15.1=0A= of RFC2543, with the modification that the signature is computed=0A= across the concatenation of the referrer-url and the referenced-url. = =0A= =0A= 3.2.2 Examples=0A= =0A= Referred-By: sip:alice@atlanta.com;ref=3D =0A= =0A= Referred-By: "Bob"=0A= = ;ref=3D;scheme=3Dpgp;pgp-vers= ion=3D"5.0";signature=3D"the signature"=0A= =0A= =0A= (Note that in the last example, the signature would be over = the=0A= string "sip:bob@biloxi.comsip:alice@atlanta.com") =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 5]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 3.3 Header Field Support for the REFER Method=0A= =0A= This table adds a column to tables 4 and 5 in [1], describing = header=0A= presence in a REFER method. See [1] for a key for the symbols = used.=0A= A row for the Refer-To: and Referred-By request-header should be=0A= inferred, each mandatory for REFER. Refer-To is not applicable = for=0A= all other methods. Referred-By is a general Request header. The = enc=0A= and e-e columns in [1] apply to the REFER method unmodified. =0A= =0A= Header Where REFER=0A= Accept R -=0A= Accept-Encoding R -=0A= Accept-Language R o=0A= Allow R -=0A= Allow 405 m=0A= Authorization R o=0A= Call-ID gc m=0A= Contact R o=0A= Contact 1xx -=0A= Contact 2-6xx o=0A= Content-Encoding e -=0A= Content-Length e o=0A= Content-Type e -=0A= CSeq gc m=0A= Date g o=0A= Encryption g o=0A= Expires R o=0A= From gc m=0A= Hide R o=0A= Max-Forwards R o=0A= Organization g o=0A= Priority R -=0A= Proxy-Authenticate 407 o=0A= Proxy-Authorization R o=0A= Proxy-Require R o=0A= Require R o=0A= Retry-After R -=0A= Retry-After 404,480,486 o=0A= Retry-After 503 o=0A= Retry-After 600,603 o=0A= Response-Key R o=0A= Record-Route R o=0A= Record-Route 2xx o=0A= Route R o=0A= Server r o=0A= Subject R -=0A= Timestamp g o=0A= To gc(1) m=0A= Unsupported 420 o=0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 6]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= User-Agent g o=0A= Via gc(2) m=0A= Warning r o=0A= WWW-Authenticate 401 o=0A= =0A= 3.4 Message Body Inclusion=0A= =0A= A REFER method may contain a body which SHOULD be processed=0A= according to its Content-Type. =0A= =0A= 3.5 Responses within the REFER transaction=0A= =0A= An agent responding to a REFER Method MUST return a 400 Bad = Request=0A= if the request contained zero or more than one Refer-To headers. = An=0A= agent responding to a REFER Method MUST return a 400 Bad Request = if=0A= the request contained zero or more than one Referred-By headers. = An=0A= agent (including proxies generating local responses) MAY return a=0A= 100 Trying or any appropriate 400-600 class response as = prescribed=0A= by [1]. If the recipient's agent decides to contact the resource = in=0A= the Refer-To header, a 200 OK response MUST be returned before = the=0A= REFER transaction expires. (Open Issue: Should this be a 202=0A= Accepted?) (Section 5.1)=0A= =0A= Editor's note - The previous version of this draft required the=0A= agent responding to REFER to wait until the referred action=0A= completed before sending a final response to the REFER. That = final=0A= response reflected the success or failure of the referred action.=0A= This was infeasible due to the transaction timeout rules defined = for=0A= non-INVITE requests in [1]. A REFER must always receive an = immediate=0A= (within the lifetime of a non-INVITE transaction) final response. = =0A= =0A= 3.6 Behavior of SIP User Agents=0A= =0A= 3.6.1 Accessing the referred-to resource=0A= =0A= A UA receiving a well-formed REFER request SHOULD request = approval=0A= from the user to proceed (this request could be interactive or=0A= through configuration). Upon receiving approval from the user, = the=0A= UA MUST contact the resource identified by the URL in the = Refer-To:=0A= header. Note that if the URL is a SIP URL, it could contain = header=0A= fields such as Call-Id that will be used to form the resulting=0A= request. If the URL is a SIP URL, the Referred-By header in the=0A= REFER request should be copied into the request sent to the=0A= referred-to resource. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 7]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 3.6.2 Reporting on the results of the reference=0A= =0A= Once it is known whether the reference succeeded or failed, the = UA=0A= receiving the REFER SHOULD notify the agent sending the refer = using=0A= the NOTIFY mechanism defined in Event Notification in SIP[3] as = if=0A= the the REFER had established a subscription. In particular: =0A= =0A= o The NOTIFY should reflect the To:, From:, and Call-ID headers=0A= from the REFER as if they had arrived in a SUBSCRIBE. =0A= =0A= o If the reference succeeded, the NOTIFY MUST contain Event:=0A= refersuccess =0A= =0A= o If the reference failed for any reason, or was not attempted=0A= after being accepted, the NOTIFY MUST contain Event: referfailure = =0A= =0A= o The notifying UA SHOULD send exactly one NOTIFY with an event=0A= from the profile {refersuccess,referfailure}. If multiple=0A= notifications are sent, perhaps including events from other=0A= extension drafts, the UA MUST NOT send both refersuccess and=0A= referfailure events. =0A= =0A= o Analogous to the case for SUBSCRIBE described in [3], the = agent=0A= that issued the REFER MUST be prepared to receive a NOTIFY = before=0A= the REFER transaction completes. =0A= =0A= Open Issue: This makes REFER dependent on sip-events (Section = 5.3)=0A= =0A= Open Issue: The events will need to be registered with IANA = (Section=0A= 5.4)=0A= =0A= 3.7 Behavior of SIP Registrars/Redirect Servers=0A= =0A= Registrars and Redirect Servers SHOULD return a 603 to a REFER=0A= request, unless they are also playing some other SIP role. =0A= =0A= 3.8 Behavior of SIP Proxies=0A= =0A= SIP Proxies do not require modification to support the REFER = method.=0A= Specifically, as required by [1], a proxy should process a REFER=0A= request the same way it processes an OPTIONS request. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 8]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 3.9 Prototypical REFER callflow=0A= =0A= Agent A Agent B=0A= | |=0A= | REFER |=0A= |----------------------->|=0A= | 200 OK |=0A= |<-----------------------|=0A= | |=0A= | |------->=0A= | | (whatever)=0A= | |<------=0A= | |=0A= | NOTIFY |=0A= |<-----------------------|=0A= | 200 OK |=0A= |----------------------->|=0A= | |=0A= | |=0A= =0A= 3.10 Security Considerations=0A= =0A= The security requirements of [1] apply to the REFER method. =0A= =0A= This mechanism relies on providing contact information for the=0A= referred-to resource to the party being referred. Care should be=0A= taken to provide a suitably restricted URI if the referred to=0A= resource should be protected. =0A= =0A= Care should be taken when implementing the logic that determines=0A= whether or not to accept the REFER request. A UA not capable of=0A= accessing non-SIP URLs SHOULD NOT accept REFER requests to them. =0A= =0A= 4. Call Transfer=0A= =0A= 4.1 Actors and Roles=0A= =0A= There are three actors in a given transfer event, each playing = one=0A= of the following roles: =0A= =0A= Transferee - the party being transferred to the = Transfer=0A= Target.=0A= =0A= Transferor - the party initiating the transfer=0A= =0A= Transfer Target - the new party being introduced into a call = with=0A= the Transferee.=0A= =0A= The following roles are used to describe transfer requirements = and=0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 9]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= scenarios: =0A= =0A= Originator - wishes to place a call to the Recipient. This = actor=0A= is the source of the first INVITE in a session, = to=0A= either a Facilitator or a Screener.=0A= =0A= Facilitator - receives a call or out-of-band request from = the=0A= Originator, establishes a call to the = Recipient=0A= through the Screener, and connects the Originator = to=0A= the Recipient.=0A= =0A= Screener - receives a call ultimately intended for the = Recipient=0A= and transfers the calling party to the Recipient = if=0A= appropriate.=0A= =0A= Recipient - the party the Originator is ultimately connected = to.=0A= =0A= 4.2 Requirements=0A= 1. Any party in a SIP session MUST be able to transfer any other=0A= party in that session at any point in that session.=0A= 2. The Transferor and the Transferee MUST NOT be removed from a=0A= session as part of a transfer transaction.=0A= =0A= At first glance, requirement 2 may seem to indicate=0A= that the user experience in a transfer must be=0A= significantly different from what a current PBX or=0A= Centrex user expects. As the call-flows in this=0A= document show, this is not the case. A client MAY=0A= preserve the current experience. In fact, without=0A= this requirement, some forms of the current=0A= experience (ringback on unattended transfer failure=0A= for instance) will be lost.=0A= =0A= 3. The Transferor MUST know whether or not the transfer was=0A= successful (this is significantly different from the=0A= requirements of draft-ietf-sip-cc-01).=0A= =0A= 4.3 Using REFER to achieve Call Transfer=0A= =0A= A REFER can be issued by the Transferor to cause the Transferee = to=0A= issue an INVITE to the Transfer-Target. Note that a successful = REFER=0A= transaction does not terminate the session between the Transferor=0A= and the Transferee. If those parties wish to terminate their=0A= session, they must do so with a subsequent BYE request. The media=0A= negotiated between the transferee and the transfer target is not=0A= affected by the media that had been negotiated between the=0A= transferor and the transferee. In particular, the INVITE issued = by=0A= the Transferee will have the same SDP body it would have if he=0A= Transferee had initiated that INVITE on its own. Further, the=0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 10]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= disposition of the media streams between the Transferor and the=0A= Transferee is not altered by the REFER method. Agents may alter a=0A= session's media through additional signaling. For example, they = may=0A= make use of the SIP hold re-INVITE [1] or the conferencing=0A= extensions provided by this framework. =0A= =0A= 4.4 Unattended Transfer=0A= =0A= Unattended Transfer consists of the Transferor providing the=0A= Transfer Target's contact to the Transferee. The Transferee = attempts=0A= to establish a session using that contact and reports the results = of=0A= that attempt to the Transferor. The signaling relationship = between=0A= the Transferor and Transferee is not terminated, so the call is=0A= recoverable if the Transfer Target cannot be reached. Note that = the=0A= Transfer Target's contact information has been exposed to the=0A= Transferee. The provided contact can be used to make new calls in=0A= the future. The diagrams below show indicate the first line of = each=0A= message. All messages in a particular diagram share the same=0A= Call-ID. In these diagrams, media is managed through reINVITE = holds,=0A= but other mechanisms (mixing multiple media streams at the UA or=0A= using the conferencing extensions for example) are valid. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 11]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 4.4.1 Successful Unattended Transfer=0A= =0A= Transferor Transferee Transfer=0A= | | Target=0A= | INVITE | |=0A= |<-------------------| |=0A= | 200 OK | |=0A= |------------------->| |=0A= | ACK | |=0A= |<-------------------| |=0A= | INVITE (hold) | |=0A= |------------------->| |=0A= | 200 OK | |=0A= |<-------------------| |=0A= | ACK | |=0A= |------------------->| |=0A= | REFER | |=0A= |------------------->| |=0A= | 200 OK | |=0A= |<-------------------| |=0A= | | INVITE |=0A= | |------------------->|=0A= | | 200 OK |=0A= | |<-------------------|=0A= | | ACK |=0A= | |------------------->|=0A= | NOTIFY (refersuccess) |=0A= |<-------------------| |=0A= | 200 OK | |=0A= |------------------->| |=0A= | BYE | |=0A= |------------------->| |=0A= | 200 OK | |=0A= |<-------------------| |=0A= | | BYE |=0A= | |<-------------------|=0A= | | 200 OK |=0A= | |------------------->|=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 12]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 4.4.2 Failed Unattended Transfer=0A= =0A= Transferor Transferee Transfer=0A= | | Target=0A= | | |=0A= | INVITE | |=0A= |<-------------------| |=0A= | 200 OK | |=0A= |------------------->| |=0A= | ACK | |=0A= |<-------------------| |=0A= | INVITE (hold) | |=0A= |------------------->| |=0A= | 200 OK | |=0A= |<-------------------| |=0A= | ACK | |=0A= |------------------->| |=0A= | REFER | |=0A= |------------------->| |=0A= | 200 OK | |=0A= |<-------------------| |=0A= | | INVITE |=0A= | |------------------->|=0A= | | 486 Busy Here |=0A= | |<-------------------|=0A= | | ACK |=0A= | |------------------->|=0A= | NOTIFY (referfailure) |=0A= |<-------------------| |=0A= | 200 OK | |=0A= |------------------->| |=0A= | INVITE (unhold) | |=0A= |------------------->| |=0A= | 200 OK | |=0A= |<-------------------| |=0A= | ACK | |=0A= |------------------->| |=0A= | BYE | |=0A= |------------------->| |=0A= | 200 OK | |=0A= |<-------------------| |=0A= =0A= 4.5 Unattended Transfer with Consultation Hold=0A= =0A= Transfer with Consultation Hold involves a session between the=0A= transferor and the transfer target before the transfer actually=0A= takes place. This is implemented with SIP Hold and Unattended=0A= Transfer as described above. =0A= =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 13]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 4.5.1 Variation 1 : Exposes transfer target=0A= =0A= The transferor places the transferee on hold, establishes a call=0A= with the transfer target to alert them to the impending transfer,=0A= terminates the connection with the transfer target, then proceeds=0A= with unattended transfer as above. This variation can be used to=0A= provide an experience similar to that expected by current PBX and=0A= Centrex users. =0A= =0A= To (hopefully) improve clarity, non-REFER transactions have been=0A= collapsed into one indicator with the arrow showing the direction = of=0A= the request. =0A= =0A= Transferor Transferee Transfer=0A= | | Target=0A= | | |=0A= Call-ID:1 | INVITE/200 OK/ACK | |=0A= |<-------------------| |=0A= Call-ID:1 | INVITE (hold)/200 OK/ACK |=0A= |------------------->| |=0A= Call-ID:2 | INVITE/200 OK/ACK | |=0A= |---------------------------------------->|=0A= Call-ID:2 | BYE/200 OK | |=0A= |---------------------------------------->|=0A= Call-ID:1 | REFER | |=0A= |------------------->| |=0A= | 200 OK | |=0A= |<-------------------| |=0A= Call-ID:1 | | INVITE/200 OK/ACK |=0A= | |------------------->|=0A= Call-ID:1 | NOTIFY (refersuccess) |=0A= |<-------------------| |=0A= | 200 OK | |=0A= |------------------->| |=0A= Call-ID:1 | BYE/200 OK | |=0A= |------------------->| |=0A= Call-ID:1 | | BYE/200 OK |=0A= | |<-------------------|=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 14]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 4.5.2 Variation 2 : Protects transfer target=0A= =0A= The transferor places the transferee on hold, establishes a call=0A= with the transfer target and then reverses their roles, = transferring=0A= the original transfer target to the original transferee. This has=0A= the advantage of hiding information about the original transfer=0A= target from the original transferee. On the other hand, the=0A= Transferee's experience is different that in current systems. The=0A= Transferee is effectively "called back" by the Transfer Target. =0A= =0A= Transferor Transferee Transfer=0A= | | Target=0A= | | |=0A= Call-ID:1 | INVITE/200 OK/ACK | |=0A= |<-------------------| |=0A= Call-ID:1 | INVITE (hold)/200 OK/ACK |=0A= |------------------->| |=0A= Call-ID:2 | INVITE/200 OK/ACK | |=0A= |---------------------------------------->|=0A= Call-ID:2 | INVITE (hold)/200 OK/ACK |=0A= |---------------------------------------->|=0A= Call-ID:2 | REFER | |=0A= |---------------------------------------->|=0A= | 200 Trying | |=0A= |<----------------------------------------|=0A= Call-ID:2 | | INVITE/200 OK/ACK |=0A= | |<-------------------|=0A= Call-ID:2 | NOTIFY (refersuccess) |=0A= |<----------------------------------------|=0A= | 200 OK | |=0A= |------------------->| |=0A= Call-ID:1 | BYE/200 OK | |=0A= |------------------->| |=0A= Call-ID:2 | BYE/200 OK | |=0A= |---------------------------------------->|=0A= Call-ID:2 | | BYE/200 OK |=0A= | |------------------->|=0A= =0A= 4.5.3 Consultation Hold in the presence of forking proxies=0A= =0A= It is worth noting that the examples given above abstract away = any=0A= proxies that might be between the three parties. In 4.5.1 for=0A= example, the URL used to reach the Transfer Target may go through = a=0A= forking proxy. There is no guarantee that the Transferee's and=0A= Transferor's invitations to the Transfer Target will reach the = same=0A= endpoint. If the proxy forked in parallel, both invitations could=0A= cause multiple endpoints to ring. To increase the probability of = the=0A= desired behavior of having the referred invite reach and ring = only=0A= the same endpoint as the consultation invite, the Transferor = SHOULD=0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 15]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= issue the REFER request with the Refer-To: header containing the=0A= Contact the Transfer Target provided in its 200 OK to the=0A= Transferor's INVITE. If that REFER fails, the Transferor SHOULD=0A= issue another REFER with the Refer-To: header containing the URL = it=0A= used to reach the Transfer Target, augmented with an = Accept-Contact=0A= header containing the Contact the Transfer Target provided. =0A= =0A= 4.6 Attended Transfer=0A= =0A= In an attended transfer, the three actors participate in an = ad-hoc=0A= conference as part of the event. Discussion of the implementation = of=0A= attended transfer is thus deferred until the conferencing portion = of=0A= the Call Control framework has been addressed. =0A= =0A= 4.7 Transfer with multiple parties=0A= =0A= In this example the Originator places call to the Facilitator who=0A= reaches the Recipient through the Screener. The Recipient's = contact=0A= information is exposed to the Facilitator and the Originator. = This=0A= example is provided for clarification of the semantics of the = REFER=0A= method only and should not be used as the design of an=0A= implementation. =0A= =0A= Originator Facilitator Screener Recipient=0A= Call-ID | | | |=0A= 1 |INVITE/200 OK/ACK | |"Get Fred for = me!"=0A= |----------->| | | "Right = away!"=0A= 1 |INVITE (hold)/200 OK/ACK | |=0A= |<-----------| | |=0A= 2 | |INVITE/200 OK/ACK |"I have a = call=0A= | |----------->| |from Mary for = Fred"=0A= 2 | |INVITE (hold)/200 OK/ACK "Hold = please"=0A= | |<-----------| |=0A= 3 | | |INVITE/200 OK/ACK=0A= | | |--------->|"You have a = call=0A= | | | |from Mary"=0A= | | | | "Put her = through"=0A= 3 | | |INVITE (hold)/200 OK/ACK=0A= | | |--------->|=0A= 2 | |REFER | |=0A= | |<-----------| |=0A= | |200 OK | |=0A= | |----------->| |=0A= 2 | |INVITE/200 OK/ACK |=0A= | |---------------------->|"This is = Fred"=0A= 2 | |NOTIFY (refersuccess) | "Please hold = for=0A= | |----------->| | = Mary"=0A= | |200 OK | |=0A= | |<-----------| |=0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 16]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 2 | |BYE/200 OK | |=0A= | |<-----------| |=0A= 3 | | |BYE/200 OK|=0A= | | |--------->|=0A= 2 | |INVITE (hold)/200 OK/ACK=0A= | |---------------------->|=0A= 1 |REFER | | |=0A= |<-----------| | |=0A= |200 OK | | |=0A= |----------->| | |=0A= 1 |INVITE/200 OK/ACK | |=0A= |----------------------------------->| "Hey Fred"=0A= 1 |NOTIFY (refersuccess) | | "Hello = Mary"=0A= |----------->| | |=0A= |200 OK | | |=0A= |<-----------| | |=0A= 1 |BYE/200 OK | | |=0A= |<-----------| | |=0A= 2 | |BYE/200 OK | |=0A= | |---------------------->|=0A= 1 |BYE/200 OK | | |=0A= |<-----------------------------------| "See you = later"=0A= =0A= 5. Open Issues=0A= =0A= 5.1 200 vs 202=0A= =0A= Should an agent accepting a NOTIFY request return a 200 OK or a = 202=0A= Accepted? =0A= =0A= 5.2 Should REFER expire?=0A= =0A= Since REFER is effectively establishing a Subscription per [3],=0A= should the REFER request be required to contain an Expires: = header?=0A= This would allow REFERer to specify how long he's willing to wait=0A= for the reference to complete. If the referred action exceeds = that=0A= time, the agent processing the refer could return referfailure, = stop=0A= trying, and free the state it needed for that processing. Without=0A= this or a similar mechanism, both agents involved in a REFER=0A= transaction could be forced to hold state indefinitely. =0A= =0A= 5.3 REFER is now dependent on sip-events=0A= =0A= By introducing NOTIFY, this work is prevented from moving to RFC=0A= until the sip-events draft moves to that level (that work is=0A= currently an individual submission). What needs to happen to our=0A= deliverable schedule to allow for completing the sip-events work? = =0A= =0A= =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 17]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 5.4 Registering the events with IANA=0A= =0A= When we near the end of the process, the events we agree to use = for=0A= this purpose (currently proposed as refersuccess and = referfailure)=0A= will need to be registered with IANA per [3].=0A= =0A= 6. Acknowledgments=0A= =0A= This draft is a collaborative product of the SIP working group. = The=0A= editor thanks the following for their early contributions to this=0A= work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan = Johnston,=0A= Kevin Summers and Dean Willis. =0A= =0A= References=0A= =0A= [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,=0A= "SIP: Session Initiation Protocol", RFC 2543, March 1999.=0A= =0A= [2] Campbell, B., "Framework for SIP Call Control Extensions",=0A= draft-ietf-sip-cc-framework-00 (work in progress), March = 2000.=0A= =0A= [3] Roach, A., "Event Notification in SIP",=0A= draft-roach-sip-subscibe-notify-02 (work in progress), = November=0A= 2000.=0A= =0A= [4] Schulzrinne, H. and J. Rosenberg, "SIP Call Control = Services",=0A= draft-ietf-sip-cc-01 (work in progress - expired), June = 1999.=0A= =0A= =0A= Author's Address=0A= =0A= Robert J. Sparks=0A= dynamicsoft=0A= 5100 Tennyson Parkway=0A= Suite 1200=0A= Plano, TX 75024=0A= =0A= email: rsparks@dynamicsoft.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 18]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2001). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished = to=0A= others, and derivative works that comment on or otherwise explain = it=0A= or assist in its implementation may be prepared, copied, = published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph=0A= are included on all such copies and derivative works. However, = this=0A= document itself may not be modified in any way, such as by = removing=0A= the copyright notice or references to the Internet Society or = other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other = than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not = be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on = an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Acknowledgement=0A= =0A= Funding for the RFC editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 3, 2001 [Page = 19]=0A= =0C=0A= ------_=_NextPart_000_01C08D68.1BA78D4D-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 20:03:52 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07961 for ; Fri, 2 Feb 2001 20:03:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E2D844354; Fri, 2 Feb 2001 19:04:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange.NeTrue.com (unknown [207.104.210.242]) by lists.bell-labs.com (Postfix) with ESMTP id 1FB624434C for ; Fri, 2 Feb 2001 19:03:41 -0500 (EST) Received: from rchen (rchen.netrue.com [207.104.210.210]) by exchange.NeTrue.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1167KWAL; Fri, 2 Feb 2001 17:04:08 -0800 Message-ID: <05ed01c08d7c$e1e53550$d2d268cf@netrue.com> From: "Robert Chen" To: "Henning G. Schulzrinne" , "Michael O'Doherty" , "Kevin Wang" Cc: , "SIPMailingList" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [SIP] again, how can the SIP proxy server get the next proxy server(hop)? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 2 Feb 2001 17:01:46 -0800 Content-Transfer-Encoding: 7bit hi, I want to ask this question again. How can the SIP proxy server get the next proxy server(hpo)? DNS can only get those SIP servers like, sip.domain.com If a sip server address like this, sip:siphappens.com, DNS can not get the address! So how can the my SIP proxy server get the next hop? This question may seems easy for your expert, but I really need your help. Thanks. Best wishes! Yours sincerely, Robert Chen _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 2 20:05:39 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08060 for ; Fri, 2 Feb 2001 20:05:38 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6502344388; Fri, 2 Feb 2001 19:05:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id E520244388 for ; Fri, 2 Feb 2001 19:04:43 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id <1DWCSR4V>; Fri, 2 Feb 2001 17:04:18 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Kundan Singh'" Cc: sip@lists.bell-labs.com, sip-h323@egroups.com Subject: RE: [SIP] Interworking Between SIP/SDP and H.323 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D7D.3B4F8730" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 2 Feb 2001 17:04:17 -0800 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_01C08D7D.3B4F8730 Content-Type: text/plain; charset="iso-8859-1" Hi Kundan, Do you see any problems with forming the destination h323-id with the display name from the To: and the SIP URL from the Request-URL? Robert. > -----Original Message----- > From: Kundan Singh [mailto:kns10@cs.columbia.edu] > Sent: Saturday, February 03, 2001 5:21 AM > To: Fairlie-Cuninghame, Robert > Cc: sip@lists.bell-labs.com; sip-h323@egroups.com > Subject: Re: [SIP] Interworking Between SIP/SDP and H.323 > > > > > Hi Henning & Kundan, > > > > I have a query with regards to draft-singh-sip-h323-01.txt. > > > > The draft states that the destination information from the > H.323 call be > > derived from the To URL in a new INVITE (see A.1.2). It > seems that the > > request-URI is ignored entirely (despite the fact that some > of the call > > This is an error. The signaling gateway should use > the Request-URI instead of To: URL. This occurs at more than > one place in the draft. > > We will correct this in the next version. > > Thanks for pointing out the mistake. > > Kundan > > > flows are annotated with "INVITE sip:kns10@cs.columbia.edu"). > > > > I do not see how this will work when a SIP UA or proxy > redirects (or proxies > > with updating the request) call to a H.323 device. > > > > For example: > > > > INVITE sip:rfairlie@nuera.com SIP/2.0 > > To: "Robert Fairlie-Cuninghame" > > > > is sent to the proxy at nuera.com which responds with a > SIP/2.0 302 Temp > > Moved > > Contact: > > > > > How will this work if the IWF ignores the Request-URI ? > > > > If the IWF instead uses the request URI in the H323 SETUP > destinationInfo, > > is there anythign wrong with it using the display name from > the To? Unless a > > 380 Alternate Service is issued then the display name > should still be > > correct. > > > > On a related note in the base SIP spec, if a 380 Alternate > Service is issued > > (which requires user interaction), the spec needs to be > clarified whether > > the new call attempt will use a new call-leg with the To > field changed > > apprpriately. > > > > Cheers, > > > > Robert. > > > ------_=_NextPart_001_01C08D7D.3B4F8730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Interworking Between SIP/SDP and H.323

Hi Kundan,

Do you see any problems with forming the destination = h323-id with the display name from the To: and the SIP URL from the = Request-URL?

Robert.

> -----Original Message-----
> From: Kundan Singh [mailto:kns10@cs.columbia.edu]<= /FONT>
> Sent: Saturday, February 03, 2001 5:21 = AM
> To: Fairlie-Cuninghame, Robert
> Cc: sip@lists.bell-labs.com; = sip-h323@egroups.com
> Subject: Re: [SIP] Interworking Between SIP/SDP = and H.323
>
>
>
> > Hi Henning & Kundan,
> >
> > I have a query with regards to = draft-singh-sip-h323-01.txt.
> >
> > The draft states that the destination = information from the
> H.323 call be
> > derived from the To URL in a new INVITE = (see A.1.2). It
> seems that the
> > request-URI is ignored entirely (despite = the fact that some
> of the call
>
> This is an error. The signaling gateway should = use
> the Request-URI instead of To: URL. This occurs = at more than
> one place in the draft.
>
> We will correct this in the next = version.
>
> Thanks for pointing out the mistake.
>
> Kundan
>
> > flows are annotated with "INVITE = sip:kns10@cs.columbia.edu").
> >
> > I do not see how this will work when a SIP = UA or proxy
> redirects (or proxies
> > with updating the request) call to a H.323 = device.
> >
> > For example:
> >
> > INVITE sip:rfairlie@nuera.com = SIP/2.0
> > To: "Robert Fairlie-Cuninghame" = <sip:rfairlie@nuera.com>
> >
> > is sent to the proxy at nuera.com which = responds with a
> SIP/2.0 302 Temp
> > Moved
> > Contact:
> = <sip:1000@h323-gatekeeper.nuera.com;maddr=3Dh323-iwf.nuera.com>
> >
> > How will this work if the IWF ignores the = Request-URI ?
> >
> > If the IWF instead uses the request URI in = the H323 SETUP
> destinationInfo,
> > is there anythign wrong with it using the = display name from
> the To? Unless a
> > 380 Alternate Service is issued then the = display name
> should still be
> > correct.
> >
> > On a related note in the base SIP spec, if = a 380 Alternate
> Service is issued
> > (which requires user interaction), the = spec needs to be
> clarified whether
> > the new call attempt will use a new = call-leg with the To
> field changed
> > apprpriately.
> >
> > Cheers,
> >
> > Robert.
> >
>

------_=_NextPart_001_01C08D7D.3B4F8730-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 3 16:54:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12485 for ; Sat, 3 Feb 2001 16:54:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA72E4433D; Sat, 3 Feb 2001 15:55:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id A87AC44336 for ; Sat, 3 Feb 2001 15:54:47 -0500 (EST) Received: from fokus.gmd.de (dhcp012 [195.37.78.140]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id WAA08303; Sat, 3 Feb 2001 22:54:29 +0100 (MET) Message-ID: <3A7C7CAE.EDC78A75@fokus.gmd.de> From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson Cc: "'sip@lists.bell-labs.com'" Subject: Location information (was Re: [SIP] SIP Privacy Draft) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 03 Feb 2001 22:48:30 +0100 Content-Transfer-Encoding: 7bit > Mark Watson wrote: [...] > 5) Location Information > > A further type of Party information is the physical location of the Party. This is useful for calls to emergency service centers and for geographic routing services. There is apparantly a URL format for geographic location, so this could be used for this purpose. Where is the URL format specified? I agree that URL is a good place to accomodate geographical location and it would be useful to have a standardized notation. draft-daviel-http-geo-header-02.txt specifies header fields for conveying location in HTTP. However as the position identifies services and may be used with more protocols than just HTTP I would prefer conveying it in URLs. Henning's 911 draft also addresses many of related issues. Is there interest in going ahead with such URLs? Jiri ------------ P.S. It seems to me there are some geo-service points on which some folks like to disagree. Let me give a couple of more details from my perspective so that we can save a couple of RTTs if there is interest in discussing this. - URL format for conveying geo-info is a URL format and nothing else. There are three orthogonal jobs: 1) determining geo-info, 2) finding a server providing location-base services and 3) conveying the geo-info to it. Geo-info in URLs would make only the third job. - The geo-info may be gained from anywhere: access providers, from GPS provider, typed-in by sextant-equipped user, from IPv6 address, etc. It does not have to indicate your current position; for example, when planning a trip a travelling agent may want to get connected to a hotel nearby his client's destination. - Both end-devices and proxies (if they know it) may insert geo-info. The latter case may be subject to privacy issues -- users may not be always happy to disseminate geo-info. - No limitations are put on how to find location-based services. They may be located at an outbound proxy discovered automatically using DHCP but they may be at Jeff's pizza server advertised in newspaper as well. - No assumptions are made about what the services are; it is service providers' discretion to implement "conntact a Pizza Inc. rep in caller's proximity", "notify my parents whenever I move", "emergency", etc. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 3 20:54:02 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00431 for ; Sat, 3 Feb 2001 20:54:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D9EA244343; Sat, 3 Feb 2001 19:51:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4]) by lists.bell-labs.com (Postfix) with SMTP id 911FB44336 for ; Sat, 3 Feb 2001 19:50:01 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Sat, 03 Feb 2001 17:49:02 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Sat, 3 Feb 2001 17:49:02 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD2CF3DE@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "Robert Sparks" , sip@lists.bell-labs.com Subject: RE: [SIP] REFER revision MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 16626A8488402-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 3 Feb 2001 17:48:52 -0800 Content-Transfer-Encoding: 7bit To start with, a couple of small oversights in the document. Call flow 4.5.2 : Protects transfer target. 1/ I would think that the 200 level response for REFER issued by Transfer Target should read 200 OK (it says 200 trying). 2/ The response for NOTIFY (refersuccess) should go to the transfer target and not to the transferee. I had some questions for which some clarifications would help. Section 4.2 Requirements: I think the statement saying "the draft preserves current transfer experience" is not totally true. I do see that end user experiences are indeed quite different in the two cases First of all, todays transfer don't request the transferee if it should proceed with a transfer request(although the doc says that one might over-ride this with configuration). Two, as regards billing (I am sure that this statement is going to cause people to beat me up, but nevertheless here I go :-)), the transferee ends up paying for the transferred call leg, quite untrue in the current PSTN world....... Three, based on the type of transfer (protect target, exposes target) et al, call flows/messages exchanged are totally different, so I would imagine that an UA would have to prompt the end user what type of transfer he/she intends to perform, protect transfer target, expose transfer target et al, unless an UA is hardcoded to perform only one type of transfer "all" the time(which is again different in current transfer call scenarios where a user can perform any type of transfer that he/she desires to, and may be convert that to a conference later). So also, in the call flow where the transfer target's number is not protected, the transfer target first gets a call from the transferor, he/she has to hang up and then a answer a new call from the transferree to get connected, not quite the way current PSTN transfers work. I don't know how an UA "may" preserve the end user experience here? So, based on all of these, I think we should remove the paragraph which says "call flows preserve current end user experience" ! Finally, I wouldn't know how one would implement the the same, if gateways that spoke SIP on one end, and provided analog end points on the other were on the transferee side of the call(or on the transfer target side in case where the transfer target was to be protected). Meaning, would gateways be able to preserve end user experience? Manage multiple sessions, speech paths, et al for a single call? Think Rohan said he knows of one that does it :-), but just getting a re-assurance from others on this list as well.... Just my two cents. Venkatesh -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Friday, February 02, 2001 2:33 PM To: sip@lists.bell-labs.com Subject: [SIP] REFER revision Here is REFER using NOTIFYs from implicit Subscriptions to get around the transaction timeout problem. I've submitted this to the draft repository, but wanted to get it into the hands of those attending next week's meeting as early as I could. RjS _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 3 22:54:52 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10709 for ; Sat, 3 Feb 2001 22:54:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A295044344; Sat, 3 Feb 2001 21:55:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.pingtel.com (mail.pingtel.com [216.91.1.131]) by lists.bell-labs.com (Postfix) with ESMTP id 9094D44336 for ; Sat, 3 Feb 2001 21:54:38 -0500 (EST) Received: from pingtel.com (h0080c7f24588.ne.mediaone.net [24.91.187.178]) by mail.pingtel.com (8.9.3/8.9.3) with ESMTP id WAA31015 for ; Sat, 3 Feb 2001 22:51:12 -0500 Message-ID: <3A7CD37D.15C14C55@pingtel.com> From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] SIP UA configuration framework requirements Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 03 Feb 2001 22:58:53 -0500 Content-Transfer-Encoding: 7bit Here is a very terse set of of requirements for a configuration framework. This intended to help us move towards a standard way SIP user agents can be configured automatically and updated on demand. I have submitted this draft, but I wanted to get it asap to people for consideration or discussion as part of the configuration topic on the agenda at next week's interim meeting. Cheers, Dan http://www.pingtel.com/docs/draft-petrie-sip-config-framewk-reqs-00.txt _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sun Feb 4 09:09:02 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08790 for ; Sun, 4 Feb 2001 09:09:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2BA6F44337; Sun, 4 Feb 2001 08:09:16 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3F80D44336 for ; Sun, 4 Feb 2001 08:08:26 -0500 (EST) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G8800MARKLN8W@firewall.mcit.com> for sip@lists.bell-labs.com; Sun, 4 Feb 2001 14:08:12 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8800J01KLL4D@pmismtp01.wcomnet.com>; Sun, 04 Feb 2001 14:08:11 +0000 (GMT) Received: from hsinnreich ([166.44.57.220]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G88004XZKJFS3@pmismtp01.wcomnet.com>; Sun, 04 Feb 2001 14:08:03 +0000 (GMT) From: Henry Sinnreich In-reply-to: To: sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [SIP] SIP Conference-Discovering Participants Identities Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 04 Feb 2001 08:07:40 -0600 Content-Transfer-Encoding: 7bit Have a problem with the strict requirements that for secure and confidential business conferences, the identity of all authenticated participants should be clearly be known and preferably displayed at all times during the conference. However, the I-D on "Models for Multi-Party Conferencing in SIP" states: >4.5 Discovering Participant Identities > The identities of other participants in the conference are > NOT known through SIP. Using RTP to display user identities seems broken, since an unwanted listener can have no RTP packets sent. http://ietf.org/internet-drafts/draft-rosenberg-sip-conferencing-models-00.t xt Any other solution to display all participants? How could a conference bridge signal to users who else in participating? Thanks, Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sun Feb 4 09:58:01 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09071 for ; Sun, 4 Feb 2001 09:58:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 62A1E44358; Sun, 4 Feb 2001 08:58:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 858AE44336 for ; Sun, 4 Feb 2001 08:57:36 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA10870; Sun, 4 Feb 2001 09:57:22 -0500 (EST) Message-ID: <3A7D6DD1.EC9B9F18@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Henry Sinnreich Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP Conference-Discovering Participants Identities References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 04 Feb 2001 09:57:21 -0500 Content-Transfer-Encoding: 7bit Henry Sinnreich wrote: > > Have a problem with the strict requirements that for secure and confidential > business conferences, the identity of all authenticated participants should > be clearly be known and preferably displayed at all times during the > conference. > > However, the I-D on "Models for Multi-Party Conferencing in SIP" states: > >4.5 Discovering Participant Identities > > The identities of other participants in the conference are > > NOT known through SIP. > > Using RTP to display user identities seems broken, since an unwanted > listener can have no RTP packets sent. > http://ietf.org/internet-drafts/draft-rosenberg-sip-conferencing-models-00.t > xt > > Any other solution to display all participants? > How could a conference bridge signal to users who else in participating? > SUBSCRIBE/NOTIFY may be an appropriate mechanism. However, nothing prevents a participant from having others listening in, so this isn't a foolproof mechanism. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sun Feb 4 22:14:55 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15474 for ; Sun, 4 Feb 2001 22:14:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9E8984435E; Sun, 4 Feb 2001 21:15:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 1296B44339 for ; Sun, 4 Feb 2001 21:14:40 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id <1HT841VJ>; Sun, 4 Feb 2001 19:13:57 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Kundan Singh'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Interworking Between SIP/SDP and H.323 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F21.ACD16270" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 4 Feb 2001 19:13:56 -0800 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_01C08F21.ACD16270 Content-Type: text/plain; charset="iso-8859-1" Kundan, There also seems to be other discrepancies in the H.323 - SIP address conversion. For instance, Section 6.1.2 says that if a tel url contains "w" then it cannot be converted into an e164-id alias address. The draft however makes no mention of the digits A, B, C & D which are allowed in tel URL's but not allowed in e164-id (according to the draft). What is the correct action here? In the same section, the visual separators "(" & ")" should be mentioned for completeness. The draft also makes no mention with regards to the "+" character when converting a e164-id to a SIP URL (or tel: URL). Is this an intentional omission? I also wished to point out that acoording to http://www.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt has expired (and hence is unavilable). Robert. > -----Original Message----- > From: Kundan Singh [mailto:kns10@cs.columbia.edu] > Sent: Saturday, February 03, 2001 5:21 AM > To: Fairlie-Cuninghame, Robert > Cc: sip@lists.bell-labs.com; sip-h323@egroups.com > Subject: Re: [SIP] Interworking Between SIP/SDP and H.323 > > > > > Hi Henning & Kundan, > > > > I have a query with regards to draft-singh-sip-h323-01.txt. > > > > The draft states that the destination information from the > H.323 call be > > derived from the To URL in a new INVITE (see A.1.2). It > seems that the > > request-URI is ignored entirely (despite the fact that some > of the call > > This is an error. The signaling gateway should use > the Request-URI instead of To: URL. This occurs at more than > one place in the draft. > > We will correct this in the next version. > > Thanks for pointing out the mistake. > > Kundan > > > flows are annotated with "INVITE sip:kns10@cs.columbia.edu"). > > > > I do not see how this will work when a SIP UA or proxy > redirects (or proxies > > with updating the request) call to a H.323 device. > > > > For example: > > > > INVITE sip:rfairlie@nuera.com SIP/2.0 > > To: "Robert Fairlie-Cuninghame" > > > > is sent to the proxy at nuera.com which responds with a > SIP/2.0 302 Temp > > Moved > > Contact: > > > > > How will this work if the IWF ignores the Request-URI ? > > > > If the IWF instead uses the request URI in the H323 SETUP > destinationInfo, > > is there anythign wrong with it using the display name from > the To? Unless a > > 380 Alternate Service is issued then the display name > should still be > > correct. > > > > On a related note in the base SIP spec, if a 380 Alternate > Service is issued > > (which requires user interaction), the spec needs to be > clarified whether > > the new call attempt will use a new call-leg with the To > field changed > > apprpriately. > > > > Cheers, > > > > Robert. > > > ------_=_NextPart_001_01C08F21.ACD16270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Interworking Between SIP/SDP and H.323

Kundan,

There also seems to be other discrepancies in the = H.323 - SIP address conversion. For instance, Section 6.1.2 says that = if a tel url contains "w" then it cannot be converted into an = e164-id alias address. The draft however makes no mention of the digits = A, B, C & D which are allowed in tel URL's but not allowed in = e164-id (according to the draft). What is the correct action = here?

In the same section, the visual separators = "(" & ")" should be mentioned for = completeness.

The draft also makes no mention with regards to the = "+" character when converting a e164-id to a SIP URL (or tel: = URL). Is this an intentional omission?

I also wished to point out that acoording to http://www.ietf.org/internet-drafts/draft-singh-sip-h3= 23-01.txt has expired (and hence is unavilable).

Robert.

> -----Original Message-----
> From: Kundan Singh [mailto:kns10@cs.columbia.edu]<= /FONT>
> Sent: Saturday, February 03, 2001 5:21 = AM
> To: Fairlie-Cuninghame, Robert
> Cc: sip@lists.bell-labs.com; = sip-h323@egroups.com
> Subject: Re: [SIP] Interworking Between SIP/SDP = and H.323
>
>
>
> > Hi Henning & Kundan,
> >
> > I have a query with regards to = draft-singh-sip-h323-01.txt.
> >
> > The draft states that the destination = information from the
> H.323 call be
> > derived from the To URL in a new INVITE = (see A.1.2). It
> seems that the
> > request-URI is ignored entirely (despite = the fact that some
> of the call
>
> This is an error. The signaling gateway should = use
> the Request-URI instead of To: URL. This occurs = at more than
> one place in the draft.
>
> We will correct this in the next = version.
>
> Thanks for pointing out the mistake.
>
> Kundan
>
> > flows are annotated with "INVITE = sip:kns10@cs.columbia.edu").
> >
> > I do not see how this will work when a SIP = UA or proxy
> redirects (or proxies
> > with updating the request) call to a H.323 = device.
> >
> > For example:
> >
> > INVITE sip:rfairlie@nuera.com = SIP/2.0
> > To: "Robert Fairlie-Cuninghame" = <sip:rfairlie@nuera.com>
> >
> > is sent to the proxy at nuera.com which = responds with a
> SIP/2.0 302 Temp
> > Moved
> > Contact:
> = <sip:1000@h323-gatekeeper.nuera.com;maddr=3Dh323-iwf.nuera.com>
> >
> > How will this work if the IWF ignores the = Request-URI ?
> >
> > If the IWF instead uses the request URI in = the H323 SETUP
> destinationInfo,
> > is there anythign wrong with it using the = display name from
> the To? Unless a
> > 380 Alternate Service is issued then the = display name
> should still be
> > correct.
> >
> > On a related note in the base SIP spec, if = a 380 Alternate
> Service is issued
> > (which requires user interaction), the = spec needs to be
> clarified whether
> > the new call attempt will use a new = call-leg with the To
> field changed
> > apprpriately.
> >
> > Cheers,
> >
> > Robert.
> >
>

------_=_NextPart_001_01C08F21.ACD16270-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sun Feb 4 22:24:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15517 for ; Sun, 4 Feb 2001 22:24:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3478544375; Sun, 4 Feb 2001 21:25:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8404D44374 for ; Sun, 4 Feb 2001 21:24:25 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA01857; Sun, 4 Feb 2001 22:27:00 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 4 Feb 2001 22:20:23 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30475A0@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Venkatesh Venkataramanan'" , sip@lists.bell-labs.com Subject: RE: [SIP] REFER revision MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 4 Feb 2001 22:20:17 -0500 > From: Venkatesh Venkataramanan > > To start with, a couple of small oversights in the document. > > Call flow 4.5.2 : Protects transfer target. > > 1/ I would think that the 200 level response for REFER issued > by Transfer > Target should read 200 OK (it says 200 trying). > > 2/ The response for NOTIFY (refersuccess) should go to the > transfer target > and not to the transferee. Fixed - thanks! RjS _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 03:55:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02507 for ; Mon, 5 Feb 2001 03:55:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 39BE044349; Mon, 5 Feb 2001 02:56:06 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 365FD44339 for ; Mon, 5 Feb 2001 02:55:47 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Feb 5 03:53:33 EST 2001 Received: by lists.bell-labs.com (Postfix) id BFD0444380; Mon, 5 Feb 2001 03:41:55 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ihgp.ih.lucent.com (ihgp.ih.lucent.com [135.1.53.23]) by lists.bell-labs.com (Postfix) with ESMTP id 4582D4437D for ; Mon, 5 Feb 2001 03:41:55 -0500 (EST) Received: by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id CAA14945; Mon, 5 Feb 2001 02:41:54 -0600 (CST) Cc: sip@lists.bell-labs.com Received: from lucent.com by ihgp.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id CAA14932; Mon, 5 Feb 2001 02:41:51 -0600 (CST) Message-ID: <3A7E674F.8A2F23F6@lucent.com> From: Michel de Boer Organization: Lucent Technologies X-Mailer: Mozilla 4.7 [en]C-EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] SIP Privacy Draft References: <200102011635.LAA64884@fish-ha.research.att.com> <3A7B10D4.D65A424B@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 05 Feb 2001 09:41:51 +0100 Content-Transfer-Encoding: 7bit William Marshall wrote: > > When a SIP call is delivered to a PSTN gateway, and thus to a PSTN > endpoint (B), B may have call forwarding established to (C). In some > cases (which I admit to not understanding completely) the SS7 signaling > could identify endpoint B as a destination that is ringing, and later > identify endpoint C as an updated destination that is ringing. > Presumably if C forwards to D, and D forwards to E, etc etc etc, there > could be a whole sequence of indications received by the PSTN gateway > about ringing endpoints. SS7 identifies B as ringing and then forwards the call to C in the case of call forwarding on no answer. A calls B. B rings several times but does not answer the call. Then the call is forwarded to C. This is a common way to implement a voice mailbox. You forward your call on no-answer to your voice mail. -- Michel de Boer Lucent Technologies Phone: +31 35 687 3803 Fax: +31 35 687 5822 E-mail: michelboer@lucent.com Room: BF203 (HVS) _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 04:55:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02756 for ; Mon, 5 Feb 2001 04:55:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AAD7B44345; Mon, 5 Feb 2001 03:56:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53]) by lists.bell-labs.com (Postfix) with ESMTP id BCE5844339 for ; Mon, 5 Feb 2001 03:55:37 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 5 Feb 2001 09:54:56 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id JAA20354; Mon, 5 Feb 2001 09:55:20 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569EA.00353E90 ; Mon, 5 Feb 2001 09:41:34 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: "Tom-PT Taylor" Cc: Christer Holmberg , sip@lists.bell-labs.com, "Joshua Moloney" Message-ID: <802569EA.00353A0A.00@marconicomms.com> Subject: RE: [SIP] Overlap call setup Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=acvwRf5wAFkzZEsfUqbY3jWkYpiNCcVCQDj6PlmkzI79TUzKsZoyqv3r" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 5 Feb 2001 09:41:31 +0000 --0__=acvwRf5wAFkzZEsfUqbY3jWkYpiNCcVCQDj6PlmkzI79TUzKsZoyqv3r Content-type: text/plain; charset=us-ascii Content-Disposition: inline In the absence of receiving an encapsulated ACM, the ingress gateway could generate its own ACM when it receives a 180 Alerting; this response must mean it is safe to assume call routing is complete and caters for terminations within a SIP network. Thought needs to be given to scenarios where a non-200 final response is received, say 486 Busy, as in these cases 180 Alerting, probably, wouldn't be generated. Regards, Keith. "Tom-PT Taylor" on 02/02/2001 14:12:39 To: Christer Holmberg cc: Keith Robinson/MAIN/MC1@MCMAIN, sip@lists.bell-labs.com, "Joshua Moloney" Subject: RE: [SIP] Overlap call setup Replies below. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Friday, February 02, 2001 1:17 AM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > [MDN05:CT07:EXCH] > Subject: Re: [SIP] Overlap call setup > > > > Hi, > > I see a couple of issues here. > > 1. Even if the UAS returns Accept-Encoding: application/isup, > it doesn't > mean that it is going to send an encapsulated ACM. [PTT] Agreed, and that is a nasty point. It's related to the next one. > > 2. Even if it the UAS GW would send an encapsulated ACM, it > is not sure > that the UAC GW supports ISUP transparency in the first place. It may > support only ISUP/SIP mapping, for example. [PTT] That one is easily solved, in two ways. First, by hypothesis the UAC GW has encapsulated the IAM in the initial INVITE. It can also include an Accept-Content: header. In fact, this is essential so that the two ends can negotiate stuff like ISUP version or the fact that one of them really wants to propagate Q.931. So, given that the UAS GW has received an encapsulated IAM, the Accept-Content: header indicates that it did or did not find the encapsulated content acceptable. If it did find it acceptable, how do we oblige it to keep up its end of the conversation? I expect the behaviour has to be specified in the SIP-T umbrella document, and SIP/GSTN gateway products have to indicate their conformity to that document. > > I think that part of the problem, which is not related only to overlap > dialling, is that a SIP/PSTN GW from a SIP point of view is an SIP UA, > and from a SIP point of view should act like an SIP UA. Maybe > it should > be considered as a SIP node of its own, with GW specific functional > requirements. The only thing we have now is how to map > between ISUP and > SIP, but that is obviously not enough. ??? > > Regards, > > Christer Holmberg > Ericsson Finland > --0__=acvwRf5wAFkzZEsfUqbY3jWkYpiNCcVCQDj6PlmkzI79TUzKsZoyqv3r Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1Mi4zNSI+DQo8VElUTEU+UkU6IFtT SVBdIE92ZXJsYXAgY2FsbCBzZXR1cDwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZP TlQgU0laRT0yPlJlcGxpZXMgYmVsb3cuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+ Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ Jmd0OyBGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyBbPEEgSFJFRj0ibWFpbHRvOmNocmlzdGVyLmhv bG1iZXJnQGxtZi5lcmljc3Nvbi5zZSI+bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGxtZi5lcmlj c3Nvbi5zZTwvQT5dPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFNlbnQ6IEZyaWRheSwg RmVicnVhcnkgMDIsIDIwMDEgMToxNyBBTTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBU bzogVGF5bG9yLCBUb20tUFQgW05PUlNFOkI5MDE6RVhDSF08L0ZPTlQ+DQo8QlI+PEZPTlQgU0la RT0yPiZndDsgQ2M6IEtlaXRoIFJvYmluc29uOyBzaXBAbGlzdHMuYmVsbC1sYWJzLmNvbTsgTW9s b25leSwgSm9zaHVhPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFtNRE4wNTpDVDA3OkVY Q0hdPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFN1YmplY3Q6IFJlOiBbU0lQXSBPdmVy bGFwIGNhbGwgc2V0dXA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJS PjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+ DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgSGksPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBJIHNlZSBhIGNvdXBsZSBvZiBpc3N1ZXMg aGVyZS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IDEuIEV2ZW4gaWYgdGhlIFVBUyByZXR1cm5zIEFjY2VwdC1FbmNvZGluZzogYXBw bGljYXRpb24vaXN1cCwgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGl0IGRvZXNuJ3Q8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgbWVhbiB0aGF0IGl0IGlzIGdvaW5nIHRvIHNl bmQgYW4gZW5jYXBzdWxhdGVkIEFDTS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5b UFRUXTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+QWdyZWVkLCBhbmQgdGhhdCBpcyBhIG5hc3R5 IHBvaW50LiZuYnNwOyBJdCdzIHJlbGF0ZWQgdG8gdGhlIG5leHQgb25lLjwvRk9OVD4NCjwvUD4N Cg0KPFA+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDIu IEV2ZW4gaWYgaXQgdGhlIFVBUyBHVyB3b3VsZCBzZW5kIGFuIGVuY2Fwc3VsYXRlZCBBQ00sIGl0 IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBpcyBub3Qgc3VyZTwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTI+Jmd0OyB0aGF0IHRoZSBVQUMgR1cgc3VwcG9ydHMgSVNVUCB0cmFuc3BhcmVu Y3kgaW4gdGhlIGZpcnN0IHBsYWNlLiBJdCBtYXk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsgc3VwcG9ydCBvbmx5IElTVVAvU0lQIG1hcHBpbmcsIGZvciBleGFtcGxlLjwvRk9OVD4NCjwv UD4NCg0KPFA+PEZPTlQgU0laRT0yPltQVFRdPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5UaGF0 IG9uZSBpcyBlYXNpbHkgc29sdmVkLCBpbiB0d28gd2F5cy4mbmJzcDsgRmlyc3QsIGJ5IGh5cG90 aGVzaXMgdGhlIFVBQyBHVyBoYXMgZW5jYXBzdWxhdGVkIHRoZSBJQU0gaW4gdGhlIGluaXRpYWwg SU5WSVRFLiZuYnNwOyBJdCBjYW4gYWxzbyBpbmNsdWRlIGFuIEFjY2VwdC1Db250ZW50OiBoZWFk ZXIuJm5ic3A7IEluIGZhY3QsIHRoaXMgaXMgZXNzZW50aWFsIHNvIHRoYXQgdGhlIHR3byBlbmRz IGNhbiBuZWdvdGlhdGUgc3R1ZmYgbGlrZSBJU1VQIHZlcnNpb24gb3IgdGhlIGZhY3QgdGhhdCBv bmUgb2YgdGhlbSByZWFsbHkgd2FudHMgdG8gcHJvcGFnYXRlIFEuOTMxLjwvRk9OVD48L1A+DQoN CjxQPjxGT05UIFNJWkU9Mj5TbywgZ2l2ZW4gdGhhdCB0aGUgVUFTIEdXIGhhcyByZWNlaXZlZCBh biBlbmNhcHN1bGF0ZWQgSUFNLCB0aGUgQWNjZXB0LUNvbnRlbnQ6IGhlYWRlciBpbmRpY2F0ZXMg dGhhdCBpdCBkaWQgb3IgZGlkIG5vdCBmaW5kIHRoZSBlbmNhcHN1bGF0ZWQgY29udGVudCBhY2Nl cHRhYmxlLiZuYnNwOyBJZiBpdCBkaWQgZmluZCBpdCBhY2NlcHRhYmxlLCBob3cgZG8gd2Ugb2Js aWdlIGl0IHRvIGtlZXAgdXAgaXRzIGVuZCBvZiB0aGUgY29udmVyc2F0aW9uPyZuYnNwOyBJIGV4 cGVjdCB0aGUgYmVoYXZpb3VyIGhhcyB0byBiZSBzcGVjaWZpZWQgaW4gdGhlIFNJUC1UIHVtYnJl bGxhIGRvY3VtZW50LCBhbmQgU0lQL0dTVE4gZ2F0ZXdheSBwcm9kdWN0cyBoYXZlIHRvIGluZGlj YXRlIHRoZWlyIGNvbmZvcm1pdHkgdG8gdGhhdCBkb2N1bWVudC48L0ZPTlQ+PC9QPg0KDQo8UD48 Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgSSB0aGluayB0 aGF0IHBhcnQgb2YgdGhlIHByb2JsZW0sIHdoaWNoIGlzIG5vdCByZWxhdGVkIG9ubHkgdG8gb3Zl cmxhcDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBkaWFsbGluZywgaXMgdGhhdCBhIFNJ UC9QU1ROIEdXIGZyb20gYSBTSVAgcG9pbnQgb2YgdmlldyBpcyBhbiBTSVAgVUEsPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGFuZCBmcm9tIGEgU0lQIHBvaW50IG9mIHZpZXcgc2hvdWxk IGFjdCBsaWtlIGFuIFNJUCBVQS4gTWF5YmUgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7 IGl0IHNob3VsZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBiZSBjb25zaWRlcmVkIGFz IGEgU0lQIG5vZGUgb2YgaXRzIG93biwgd2l0aCBHVyBzcGVjaWZpYyBmdW5jdGlvbmFsPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHJlcXVpcmVtZW50cy4gVGhlIG9ubHkgdGhpbmcgd2Ug aGF2ZSBub3cgaXMgaG93IHRvIG1hcCA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYmV0 d2VlbiBJU1VQIGFuZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBTSVAsIGJ1dCB0aGF0 IGlzIG9idmlvdXNseSBub3QgZW5vdWdoLiA/Pz88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZn dDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IFJlZ2FyZHMsPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBDaHJpc3RlciBI b2xtYmVyZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBFcmljc3NvbiBGaW5sYW5kPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IDwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9I VE1MPg== --0__=acvwRf5wAFkzZEsfUqbY3jWkYpiNCcVCQDj6PlmkzI79TUzKsZoyqv3r-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 05:51:53 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03097 for ; Mon, 5 Feb 2001 05:51:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 84E044434E; Mon, 5 Feb 2001 04:52:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f196.pav1.hotmail.com [64.4.31.196]) by lists.bell-labs.com (Postfix) with ESMTP id 29BDD44339 for ; Mon, 5 Feb 2001 04:51:39 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Feb 2001 02:51:25 -0800 Received: from 164.164.6.31 by pv1fd.pav1.hotmail.msn.com with HTTP; Mon, 05 Feb 2001 10:51:24 GMT X-Originating-IP: [164.164.6.31] From: "Rakesh Jain" To: sip@lists.bell-labs.com Cc: sip-implementors@cs.columbia.edu Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Feb 2001 10:51:25.0054 (UTC) FILETIME=[9594F1E0:01C08F61] Subject: [SIP] few questions... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 05 Feb 2001 10:51:24 -0000 Hi, I am having few questions..... I am sorry if these questions have been asked already. 1. From rfc2543bis-02, section 4.2.3, "A server SHOULD return Allow, Accept, Accept-Encoding, Accept- Language and Supported header fields. The response MAY contain a message body indicating the capabilities of the end system(rather than properties of any existing call)." My question is, Is there any provision to request for particular field, like Allow or just message body, using OPTION request. I could not locate this type of features in rfc2543bis-02. 2. Is there any example where message body will be used with BYE request/responce. 3. From section " Not all of the SIP request or response can be encrypted end-to- end because header fields such as To and Via need to be visible to proxies so that the SIP request can be routed correctly" When, To field will be used by the proxy to route the request. What I understood from the RFC is that proxy will look Request- URI to route the request. thanks in advance. rakesh _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 06:11:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03223 for ; Mon, 5 Feb 2001 06:11:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A8D244383; Mon, 5 Feb 2001 05:12:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 4E57844382 for ; Mon, 5 Feb 2001 05:11:15 -0500 (EST) 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 f15BAqd26027; Mon, 5 Feb 2001 12:10:52 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA24555; Mon, 5 Feb 2001 13:10:50 +0200 (EET) Message-ID: <3A7E8A39.A1D82EBB@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: Tom-PT Taylor , sip@lists.bell-labs.com, Joshua Moloney Subject: Re: [SIP] Overlap call setup References: <802569EA.00353A0A.00@marconicomms.com> Content-Type: multipart/mixed; boundary="------------26153D767E3983BC0234913D" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 05 Feb 2001 13:10:49 +0200 This is a multi-part message in MIME format. --------------26153D767E3983BC0234913D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Again, we assume that the GWs support ISUP transparency, because if the GW only supports ISUP/SIP mapping it will not be able to know if to generate an ACM when the 18x is received - even if the GW would be smart enough to notice that there is SOME ISUP message in the 180 response. Personally, I still think that a separate provisional response code (I've been using 186 as an example) should be used, and any UAC (SIP phone or PSTN GW) supporting overlap dialing must understand the response. And, if the UAC knows it has already sent all digits, receiving a 186 could, for example, cause it to send a CANCEL to the INVITE, instead of waiting for the ISUP digit timers to expire and receive a 486 final response. Regards, Christer Holmberg Ericsson Finland Keith Robinson wrote: > > In the absence of receiving an encapsulated ACM, the ingress > gateway could generate its own ACM when it receives a 180 Alerting; this > response must mean it is safe to assume call routing is complete > and caters for terminations within a SIP network. Thought needs to be > given to scenarios where a non-200 final response is received, say 486 > Busy, as in these cases 180 Alerting, probably, wouldn't be generated. > > Regards, > > Keith. > > "Tom-PT Taylor" on 02/02/2001 14:12:39 > > > > > > > > To: Christer Holmberg > > > cc: Keith Robinson/MAIN/MC1@MCMAIN, > sip@lists.bell-labs.com, "Joshua Moloney" > > > > > Subject: RE: [SIP] Overlap call setup > > > Replies below. > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Friday, February 02, 2001 1:17 AM > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > > [MDN05:CT07:EXCH] > > Subject: Re: [SIP] Overlap call setup > > > > > > > > Hi, > > > > I see a couple of issues here. > > > > 1. Even if the UAS returns Accept-Encoding: application/isup, > > it doesn't > > mean that it is going to send an encapsulated ACM. > > [PTT] > Agreed, and that is a nasty point. It's related to the next one. > > > > > 2. Even if it the UAS GW would send an encapsulated ACM, it > > is not sure > > that the UAC GW supports ISUP transparency in the first place. It may > > support only ISUP/SIP mapping, for example. > > [PTT] > That one is easily solved, in two ways. First, by hypothesis the UAC GW has > encapsulated the IAM in the initial INVITE. It can also include an > Accept-Content: header. In fact, this is essential so that the two ends can > negotiate stuff like ISUP version or the fact that one of them really wants > to propagate Q.931. > > So, given that the UAS GW has received an encapsulated IAM, the > Accept-Content: header indicates that it did or did not find the > encapsulated content acceptable. If it did find it acceptable, how do we > oblige it to keep up its end of the conversation? I expect the behaviour > has to be specified in the SIP-T umbrella document, and SIP/GSTN gateway > products have to indicate their conformity to that document. > > > > > I think that part of the problem, which is not related only to overlap > > dialling, is that a SIP/PSTN GW from a SIP point of view is an SIP UA, > > and from a SIP point of view should act like an SIP UA. Maybe > > it should > > be considered as a SIP node of its own, with GW specific functional > > requirements. The only thing we have now is how to map > > between ISUP and > > SIP, but that is obviously not enough. ??? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64 > Description: Internet HTML --------------26153D767E3983BC0234913D 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 --------------26153D767E3983BC0234913D-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 06:47:56 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03390 for ; Mon, 5 Feb 2001 06:47:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3E3C344355; Mon, 5 Feb 2001 05:48:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 18EA544339 for ; Mon, 5 Feb 2001 05:47:07 -0500 (EST) 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 f15Bkqd22341 for ; Mon, 5 Feb 2001 12:46:52 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA26755 for ; Mon, 5 Feb 2001 13:46:50 +0200 (EET) Message-ID: <3A7E92A9.8C492AF0@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------AC6CF72A2F370BDDB6189CB0" Subject: [SIP] Operlap dialing within a SIP network Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 05 Feb 2001 13:46:49 +0200 This is a multi-part message in MIME format. --------------AC6CF72A2F370BDDB6189CB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, The discussion about overlap dialing has been pretty much about calls from SIP to PSTN, or PSTN-SIP-PSTN. Consider the following scenario. PSTN PHONE GW SIP SERVER SIP UAS ----------------------------------------------------------- --- 1 ---> -- IAM -> | -- INVITE --> | | <- 18x ------ | --- 2 ---> -- SAM -> | -- INFO ----> | | <- 200 (INFO) | | <- 18x ------ | --- 3 ---> -- SAM -> | -- INFO ----> | | <- 200 (INFO) | -- INVITE --> | <- 200 (INVITE)| <- 200 ------ In this case, the SIP server (note that I am not using the word 'proxy') must collect digits, sent from the PSTN side using overlap dialing, to be able to find the SIP UAS, and INFO is used to provide the digits after the INVITE has been sent. My question is, should a SIP server (proxy, if you like) be allowed to behave like this, or MUST it send 486s, and receive new INVITEs, until it is able to find the UAS? Regards, Christer Holmberg Ericsson Finland --------------AC6CF72A2F370BDDB6189CB0 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 --------------AC6CF72A2F370BDDB6189CB0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 07:14:56 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03759 for ; Mon, 5 Feb 2001 07:14:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E9C4C44382; Mon, 5 Feb 2001 06:15:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 168B04437D for ; Mon, 5 Feb 2001 06:14:37 -0500 (EST) 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 f15CEMC09461 for ; Mon, 5 Feb 2001 13:14:22 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA28678 for ; Mon, 5 Feb 2001 14:14:22 +0200 (EET) Message-ID: <3A7E991D.1642DD6D@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: <3A7E92A9.8C492AF0@lmf.ericsson.se> Content-Type: multipart/mixed; boundary="------------F5EB3D8C316F3873FE86F917" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 05 Feb 2001 14:14:21 +0200 This is a multi-part message in MIME format. --------------F5EB3D8C316F3873FE86F917 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would like to clarify the scenario a little. The SIP server is NOT a normal proxy in the SIP network, via which the INVITE is routed to the UAS (if it was, we would use 486 responses until the proxy can route the call to the UAS, like Tom proposed earlier in the Operlap Dialing thread). Instead, the server could be some kind of automatic phone switch, for example connected to a VPN. The difference from a NAT would be that it is connected directly to a number of UAS, so it needs the digits to be able to find the correct UAS. If the UAS would be, for example, a PSTN phone, the SIP server would be a PSTN GW, so then it would be allowed, but what is it wants to use the same logic to route a call to another network using SIP (or, maybe another VoIP protocol). Regards, Christer Holmberg Ericsson Finland > Hi, > > The discussion about overlap dialing has been pretty much about calls > from SIP to PSTN, or PSTN-SIP-PSTN. > > Consider the following scenario. > > PSTN PHONE GW SIP SERVER SIP UAS > ----------------------------------------------------------- > > --- 1 ---> -- IAM -> | -- INVITE --> | > | <- 18x ------ | > --- 2 ---> -- SAM -> | -- INFO ----> | > | <- 200 (INFO) | > | <- 18x ------ | > --- 3 ---> -- SAM -> | -- INFO ----> | > | <- 200 (INFO) | -- INVITE > --> > | <- 200 (INVITE)| <- 200 ------ > > In this case, the SIP server (note that I am not using the word 'proxy') > must collect digits, sent from the PSTN side using overlap dialing, to > be able to find the SIP UAS, and INFO is used to provide the digits > after the INVITE has been sent. > > My question is, should a SIP server (proxy, if you like) be allowed to > behave like this, or MUST it send 486s, and receive new INVITEs, until > it is able to find the UAS? > > Regards, > > Christer Holmberg > Ericsson Finland --------------F5EB3D8C316F3873FE86F917 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 --------------F5EB3D8C316F3873FE86F917-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 08:34:57 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05122 for ; Mon, 5 Feb 2001 08:34:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C8AB4435D; Mon, 5 Feb 2001 07:35:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53]) by lists.bell-labs.com (Postfix) with ESMTP id CFAD644338 for ; Mon, 5 Feb 2001 07:34:26 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 5 Feb 2001 13:33:46 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id NAA15215; Mon, 5 Feb 2001 13:34:09 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569EA.004A81A5 ; Mon, 5 Feb 2001 13:33:48 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Christer Holmberg Cc: sip@lists.bell-labs.com Message-ID: <802569EA.004A7E70.00@marconicomms.com> Subject: Re: [SIP] Operlap dialing within a SIP network Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C9fGIVg8PoIo29p4hT0yHlTEQorSmfWHEmeg4yM6CAfwvFp2Zj6VC8ZE" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 5 Feb 2001 13:33:50 +0000 --0__=C9fGIVg8PoIo29p4hT0yHlTEQorSmfWHEmeg4yM6CAfwvFp2Zj6VC8ZE Content-type: text/plain; charset=us-ascii Content-Disposition: inline In your text do you mean 484 and not 486 ? If it is legal for a gateway interworking with the PSTN to gather digits using the INFO message and responding with some 18X response then I don't see why it can't be legal for the server you have defined in this scenario. Such a server now has two choices for collecting digits; it either issues a 18X and waits for further digits in the INFO message, or it issues 484 and waits for the subsequent INVITE. The choice will probably be dictated by the implementationof the digit decode. If the implementation for decoding digits is more efficiently used by starting it off and then passing it subsequent digits, the 484 method would be inefficient as this would mean clearing down the algorithm state between INVITEs and starting it off again on the subsequent initial INVITE (as otherwise there is a problem with the subsequent initial INVITEs getting to the same server as I have previously highlighted); if the implemtation is equally efficient whether it decodes anew each time or on a digit string by digit string basis, then the 484 method would be the best. Regards, K. Robinson. Christer Holmberg on 05/02/2001 12:14:21 To: sip@lists.bell-labs.com cc: (bcc: Keith Robinson/MAIN/MC1) Subject: Re: [SIP] Operlap dialing within a SIP network I would like to clarify the scenario a little. The SIP server is NOT a normal proxy in the SIP network, via which the INVITE is routed to the UAS (if it was, we would use 486 responses until the proxy can route the call to the UAS, like Tom proposed earlier in the Operlap Dialing thread). Instead, the server could be some kind of automatic phone switch, for example connected to a VPN. The difference from a NAT would be that it is connected directly to a number of UAS, so it needs the digits to be able to find the correct UAS. If the UAS would be, for example, a PSTN phone, the SIP server would be a PSTN GW, so then it would be allowed, but what is it wants to use the same logic to route a call to another network using SIP (or, maybe another VoIP protocol). Regards, Christer Holmberg Ericsson Finland > Hi, > > The discussion about overlap dialing has been pretty much about calls > from SIP to PSTN, or PSTN-SIP-PSTN. > > Consider the following scenario. > > PSTN PHONE GW SIP SERVER SIP UAS > ----------------------------------------------------------- > > --- 1 ---> -- IAM -> | -- INVITE --> | > | <- 18x ------ | > --- 2 ---> -- SAM -> | -- INFO ----> | > | <- 200 (INFO) | > | <- 18x ------ | > --- 3 ---> -- SAM -> | -- INFO ----> | > | <- 200 (INFO) | -- INVITE > --> > | <- 200 (INVITE)| <- 200 ------ > > In this case, the SIP server (note that I am not using the word 'proxy') > must collect digits, sent from the PSTN side using overlap dialing, to > be able to find the SIP UAS, and INFO is used to provide the digits > after the INVITE has been sent. > > My question is, should a SIP server (proxy, if you like) be allowed to > behave like this, or MUST it send 486s, and receive new INVITEs, until > it is able to find the UAS? > > Regards, > > Christer Holmberg > Ericsson Finland --0__=C9fGIVg8PoIo29p4hT0yHlTEQorSmfWHEmeg4yM6CAfwvFp2Zj6VC8ZE Content-type: application/octet-stream; name="christer.holmberg.vcf" Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOkhvbG1iZXJnO0NocmlzdGVyDQp0ZWw7Y2VsbDorMzU4LTQwLTU2MDQ0 MTINCnRlbDt3b3JrOiszNTgtOS0yOTkyOTQzDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnOkVy aWNzc29uO0lQIE11bHRpbWVkaWEgLyBBZHZhbmNlZCBTaWduYWxsaW5nIFJlc2VhcmNoIExhYm9y YXRvcnkNCmFkcjo7Ozs7OzsNCnZlcnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpjaHJpc3Rlci5o b2xtYmVyZ0BsbWYuZXJpY3Nzb24uc2UNCnRpdGxlOlN5c3RlbSBEZXNpZ25lcg0KZm46Q2hyaXN0 ZXIgSG9sbWJlcmcNCmVuZDp2Y2FyZA0KDQo= --0__=C9fGIVg8PoIo29p4hT0yHlTEQorSmfWHEmeg4yM6CAfwvFp2Zj6VC8ZE-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 08:43:56 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05253 for ; Mon, 5 Feb 2001 08:43:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6F71A44386; Mon, 5 Feb 2001 07:44:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 771DB4437D for ; Mon, 5 Feb 2001 07:43:29 -0500 (EST) 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 f15DhCd00862; Mon, 5 Feb 2001 14:43:13 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA04353; Mon, 5 Feb 2001 15:43:10 +0200 (EET) Message-ID: <3A7EADED.12692FB0@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: <802569EA.004A7E70.00@marconicomms.com> Content-Type: multipart/mixed; boundary="------------A73F7BD2BD241A534E4A2000" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 05 Feb 2001 15:43:09 +0200 This is a multi-part message in MIME format. --------------A73F7BD2BD241A534E4A2000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I meant 484. Sorry. :) Christer Holmberg Ericsson Finland Keith Robinson wrote: > > In your text do you mean 484 and not 486 ? > > If it is legal for a gateway interworking with the PSTN to gather > digits using the INFO message and responding with some 18X response > then I don't see why it can't be legal for the server you have defined in this > scenario. > > Such a server now has two choices for collecting digits; it either issues a 18X > and > waits for further digits in the INFO message, or it issues 484 and waits for the > subsequent INVITE. > > The choice will probably be dictated by the implementationof the digit decode. > If the implementation for > decoding digits is more efficiently used by starting it off and then passing it > subsequent digits, the 484 method would be inefficient as this would mean > clearing > down the algorithm state between INVITEs and starting it off again on the > subsequent > initial INVITE (as otherwise there is a problem with the subsequent initial > INVITEs > getting to the same server as I have previously highlighted); if the > implemtation is equally > efficient whether it decodes anew each time or on a digit string by digit > string basis, then the 484 > method would be the best. > > Regards, > > K. Robinson. > > Christer Holmberg on 05/02/2001 12:14:21 > > > > > > > > To: sip@lists.bell-labs.com > > cc: (bcc: Keith Robinson/MAIN/MC1) > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > I would like to clarify the scenario a little. > > The SIP server is NOT a normal proxy in the SIP network, via which the > INVITE is routed to the UAS (if it was, we would use 486 responses until > the proxy can route the call to the UAS, like Tom proposed earlier in > the Operlap Dialing thread). > > Instead, the server could be some kind of automatic phone switch, for > example connected to a VPN. The difference from a NAT would be that it > is connected directly to a number of UAS, so it needs the digits to be > able to find the correct UAS. > > If the UAS would be, for example, a PSTN phone, the SIP server would be > a PSTN GW, so then it would be allowed, but what is it wants to use the > same logic to route a call to another network using SIP (or, maybe > another VoIP protocol). > > Regards, > > Christer Holmberg > Ericsson Finland > > > Hi, > > > > The discussion about overlap dialing has been pretty much about calls > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > Consider the following scenario. > > > > PSTN PHONE GW SIP SERVER SIP UAS > > ----------------------------------------------------------- > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > | <- 18x ------ | > > --- 2 ---> -- SAM -> | -- INFO ----> | > > | <- 200 (INFO) | > > | <- 18x ------ | > > --- 3 ---> -- SAM -> | -- INFO ----> | > > | <- 200 (INFO) | -- INVITE > > --> > > | <- 200 (INVITE)| <- 200 ------ > > > > In this case, the SIP server (note that I am not using the word 'proxy') > > must collect digits, sent from the PSTN side using overlap dialing, to > > be able to find the SIP UAS, and INFO is used to provide the digits > > after the INVITE has been sent. > > > > My question is, should a SIP server (proxy, if you like) be allowed to > > behave like this, or MUST it send 486s, and receive new INVITEs, until > > it is able to find the UAS? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland --------------A73F7BD2BD241A534E4A2000 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 --------------A73F7BD2BD241A534E4A2000-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 09:09:57 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06070 for ; Mon, 5 Feb 2001 09:09:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 223CE44372; Mon, 5 Feb 2001 08:10:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53]) by lists.bell-labs.com (Postfix) with ESMTP id 10E6444339 for ; Mon, 5 Feb 2001 08:09:04 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 5 Feb 2001 14:08:21 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id OAA02314; Mon, 5 Feb 2001 14:08:47 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569EA.004DAE5E ; Mon, 5 Feb 2001 14:08:29 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Christer Holmberg Cc: Tom-PT Taylor , sip@lists.bell-labs.com, Joshua Moloney Message-ID: <802569EA.004DAB73.00@marconicomms.com> Subject: Re: [SIP] Overlap call setup Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=uwzrXRFIeYaDsf6jlbJHwPNssnkXMs5z9EpDTuuThEiKTs2wyqSWXSnA" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 5 Feb 2001 14:08:19 +0000 --0__=uwzrXRFIeYaDsf6jlbJHwPNssnkXMs5z9EpDTuuThEiKTs2wyqSWXSnA Content-type: text/plain; charset=us-ascii Content-Disposition: inline Christer wrote ; >Again, we assume that the GWs support ISUP transparency, because if the >GW only supports ISUP/SIP mapping it will not be able to know if to >generate an ACM when the 18x is received - even if the GW would be smart >enough to notice that there is SOME ISUP message in the 180 response. Surely, if a GW is mapping ISUP to SIP (and vice versa) then there must be rules to dictate which SIP messages map to which ISUP messages and in what context. In fact, aren't these the rules we are debating ? The point being that even if a GW is ONLY performing SIP/ISUP/SIP mapping then it STILL MUST know when to genrate the ACM as part of the mapping function, REGARDLESS of transparency. Regards, K. Robinson. Christer Holmberg on 05/02/2001 11:10:49 To: Keith Robinson/MAIN/MC1@MCMAIN cc: Tom-PT Taylor , sip@lists.bell-labs.com, Joshua Moloney Subject: Re: [SIP] Overlap call setup Hi, Again, we assume that the GWs support ISUP transparency, because if the GW only supports ISUP/SIP mapping it will not be able to know if to generate an ACM when the 18x is received - even if the GW would be smart enough to notice that there is SOME ISUP message in the 180 response. Personally, I still think that a separate provisional response code (I've been using 186 as an example) should be used, and any UAC (SIP phone or PSTN GW) supporting overlap dialing must understand the response. And, if the UAC knows it has already sent all digits, receiving a 186 could, for example, cause it to send a CANCEL to the INVITE, instead of waiting for the ISUP digit timers to expire and receive a 486 final response. Regards, Christer Holmberg Ericsson Finland Keith Robinson wrote: > > In the absence of receiving an encapsulated ACM, the ingress > gateway could generate its own ACM when it receives a 180 Alerting; this > response must mean it is safe to assume call routing is complete > and caters for terminations within a SIP network. Thought needs to be > given to scenarios where a non-200 final response is received, say 486 > Busy, as in these cases 180 Alerting, probably, wouldn't be generated. > > Regards, > > Keith. > > "Tom-PT Taylor" on 02/02/2001 14:12:39 > > > > > > > > To: Christer Holmberg > > > cc: Keith Robinson/MAIN/MC1@MCMAIN, > sip@lists.bell-labs.com, "Joshua Moloney" > > > > > Subject: RE: [SIP] Overlap call setup > > > Replies below. > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Friday, February 02, 2001 1:17 AM > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > > [MDN05:CT07:EXCH] > > Subject: Re: [SIP] Overlap call setup > > > > > > > > Hi, > > > > I see a couple of issues here. > > > > 1. Even if the UAS returns Accept-Encoding: application/isup, > > it doesn't > > mean that it is going to send an encapsulated ACM. > > [PTT] > Agreed, and that is a nasty point. It's related to the next one. > > > > > 2. Even if it the UAS GW would send an encapsulated ACM, it > > is not sure > > that the UAC GW supports ISUP transparency in the first place. It may > > support only ISUP/SIP mapping, for example. > > [PTT] > That one is easily solved, in two ways. First, by hypothesis the UAC GW has > encapsulated the IAM in the initial INVITE. It can also include an > Accept-Content: header. In fact, this is essential so that the two ends can > negotiate stuff like ISUP version or the fact that one of them really wants > to propagate Q.931. > > So, given that the UAS GW has received an encapsulated IAM, the > Accept-Content: header indicates that it did or did not find the > encapsulated content acceptable. If it did find it acceptable, how do we > oblige it to keep up its end of the conversation? I expect the behaviour > has to be specified in the SIP-T umbrella document, and SIP/GSTN gateway > products have to indicate their conformity to that document. > > > > > I think that part of the problem, which is not related only to overlap > > dialling, is that a SIP/PSTN GW from a SIP point of view is an SIP UA, > > and from a SIP point of view should act like an SIP UA. Maybe > > it should > > be considered as a SIP node of its own, with GW specific functional > > requirements. The only thing we have now is how to map > > between ISUP and > > SIP, but that is obviously not enough. ??? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64 > Description: Internet HTML --0__=uwzrXRFIeYaDsf6jlbJHwPNssnkXMs5z9EpDTuuThEiKTs2wyqSWXSnA Content-type: application/octet-stream; name="christer.holmberg.vcf" Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOkhvbG1iZXJnO0NocmlzdGVyDQp0ZWw7Y2VsbDorMzU4LTQwLTU2MDQ0 MTINCnRlbDt3b3JrOiszNTgtOS0yOTkyOTQzDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnOkVy aWNzc29uO0lQIE11bHRpbWVkaWEgLyBBZHZhbmNlZCBTaWduYWxsaW5nIFJlc2VhcmNoIExhYm9y YXRvcnkNCmFkcjo7Ozs7OzsNCnZlcnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpjaHJpc3Rlci5o b2xtYmVyZ0BsbWYuZXJpY3Nzb24uc2UNCnRpdGxlOlN5c3RlbSBEZXNpZ25lcg0KZm46Q2hyaXN0 ZXIgSG9sbWJlcmcNCmVuZDp2Y2FyZA0KDQo= --0__=uwzrXRFIeYaDsf6jlbJHwPNssnkXMs5z9EpDTuuThEiKTs2wyqSWXSnA-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 09:21:56 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06376 for ; Mon, 5 Feb 2001 09:21:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8CB264438F; Mon, 5 Feb 2001 08:22:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 77C5E4437A for ; Mon, 5 Feb 2001 08:21:43 -0500 (EST) 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 f15EKUC24482; Mon, 5 Feb 2001 15:20:30 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA06725; Mon, 5 Feb 2001 16:20:28 +0200 (EET) Message-ID: <3A7EB6A9.9C22F2BF@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: Tom-PT Taylor , sip@lists.bell-labs.com, Joshua Moloney Subject: Re: [SIP] Overlap call setup References: <802569EA.004DAB73.00@marconicomms.com> Content-Type: multipart/mixed; boundary="------------801A0C21821CD086A45CCEC0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 05 Feb 2001 16:20:25 +0200 This is a multi-part message in MIME format. --------------801A0C21821CD086A45CCEC0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Keith Robinson wrote: > >Christer wrote ; > >>Again, we assume that the GWs support ISUP transparency, because if the >>GW only supports ISUP/SIP mapping it will not be able to know if to >>generate an ACM when the 18x is received - even if the GW would be smart >>enough to notice that there is SOME ISUP message in the 180 response. > >Surely, if a GW is mapping ISUP to SIP (and vice versa) then there must >be rules to dictate which SIP messages map to which ISUP messages and in >what context. In fact, aren't these the rules we are debating ? The point >being that even if a GW is ONLY performing SIP/ISUP/SIP mapping >then it STILL MUST know when to genrate the ACM as part of the mapping >function, REGARDLESS of transparency. Yes, and since it may not be possible to have rules when a 180 should generate a ACM, and when it should not. So, in the case of overlap dialing, when the 18x is only used to "ask" for more digits, my suggestion was to use a specific provisional response code that would not generate an ACM. Then, when we want an ACM to be generated, no matter if ISUP transparency is supported or not, we would send a 180 Alerting. Regards, Christer Holmberg Ericsson Finland > > Regards, > > K. Robinson. > > Christer Holmberg on 05/02/2001 11:10:49 > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > cc: Tom-PT Taylor , > sip@lists.bell-labs.com, Joshua Moloney > > > > > Subject: Re: [SIP] Overlap call setup > > > Hi, > > Again, we assume that the GWs support ISUP transparency, because if the > GW only supports ISUP/SIP mapping it will not be able to know if to > generate an ACM when the 18x is received - even if the GW would be smart > enough to notice that there is SOME ISUP message in the 180 response. > > Personally, I still think that a separate provisional response code > (I've been using 186 as an example) should be used, and any UAC (SIP > phone or PSTN GW) supporting overlap dialing must understand the > response. And, if the UAC knows it has already sent all digits, > receiving a 186 could, for example, cause it to send a CANCEL to the > INVITE, instead of waiting for the ISUP digit timers to expire and > receive a 486 final response. > > Regards, > > Christer Holmberg > Ericsson Finland > > Keith Robinson wrote: > > > > In the absence of receiving an encapsulated ACM, the ingress > > gateway could generate its own ACM when it receives a 180 Alerting; this > > response must mean it is safe to assume call routing is complete > > and caters for terminations within a SIP network. Thought needs to be > > given to scenarios where a non-200 final response is received, say 486 > > Busy, as in these cases 180 Alerting, probably, wouldn't be generated. > > > > Regards, > > > > Keith. > > > > "Tom-PT Taylor" on 02/02/2001 14:12:39 > > > > > > > > > > > > > > > > To: Christer Holmberg > > > > > > cc: Keith Robinson/MAIN/MC1@MCMAIN, > > sip@lists.bell-labs.com, "Joshua Moloney" > > > > > > > > > > Subject: RE: [SIP] Overlap call setup > > > > > > Replies below. > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Friday, February 02, 2001 1:17 AM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > > > [MDN05:CT07:EXCH] > > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > > > Hi, > > > > > > I see a couple of issues here. > > > > > > 1. Even if the UAS returns Accept-Encoding: application/isup, > > > it doesn't > > > mean that it is going to send an encapsulated ACM. > > > > [PTT] > > Agreed, and that is a nasty point. It's related to the next one. > > > > > > > > 2. Even if it the UAS GW would send an encapsulated ACM, it > > > is not sure > > > that the UAC GW supports ISUP transparency in the first place. It may > > > support only ISUP/SIP mapping, for example. > > > > [PTT] > > That one is easily solved, in two ways. First, by hypothesis the UAC GW has > > encapsulated the IAM in the initial INVITE. It can also include an > > Accept-Content: header. In fact, this is essential so that the two ends can > > negotiate stuff like ISUP version or the fact that one of them really wants > > to propagate Q.931. > > > > So, given that the UAS GW has received an encapsulated IAM, the > > Accept-Content: header indicates that it did or did not find the > > encapsulated content acceptable. If it did find it acceptable, how do we > > oblige it to keep up its end of the conversation? I expect the behaviour > > has to be specified in the SIP-T umbrella document, and SIP/GSTN gateway > > products have to indicate their conformity to that document. > > > > > > > > I think that part of the problem, which is not related only to overlap > > > dialling, is that a SIP/PSTN GW from a SIP point of view is an SIP UA, > > > and from a SIP point of view should act like an SIP UA. Maybe > > > it should > > > be considered as a SIP node of its own, with GW specific functional > > > requirements. The only thing we have now is how to map > > > between ISUP and > > > SIP, but that is obviously not enough. ??? > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > ------------------------------------------------------------------------ > > Name: att1.htm > > att1.htm Type: Hypertext Markup Language (text/html) > > Encoding: base64 > > Description: Internet HTML --------------801A0C21821CD086A45CCEC0 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 --------------801A0C21821CD086A45CCEC0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 10:45:55 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09833 for ; Mon, 5 Feb 2001 10:45:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F12234437A; Mon, 5 Feb 2001 09:46:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 04A4D44339 for ; Mon, 5 Feb 2001 09:45:15 -0500 (EST) 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 KAA14598; Mon, 5 Feb 2001 10:44:58 -0500 (EST) 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 KAA28598; Mon, 5 Feb 2001 10:44:57 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <1H2LAVPK>; Mon, 5 Feb 2001 10:44:52 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EE5F@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Jiri Kuthan'" , Mark Watson Cc: "'sip@lists.bell-labs.com'" Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 5 Feb 2001 10:44:54 -0500 There was an effort started several IETFs ago to define a PROTOCOL to exchange geographic location. That was shot down. There is still a low level effort to define a format for exchanging such information. Before starting another effort, you might want to look at the prior work (spatial). You also MUST forthrightly face up to the privacy concerns that have stymied other efforts. The security implications of knowing where you are can be VERY daunting, and in general discussions on the issues have yielded more problems than answers.' Brian > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Saturday, February 03, 2001 4:49 PM > To: Mark Watson > Cc: 'sip@lists.bell-labs.com' > Subject: Location information (was Re: [SIP] SIP Privacy Draft) > > > > Mark Watson wrote: > [...] > > 5) Location Information > > > > A further type of Party information is the physical > location of the Party. This is useful for calls to emergency > service centers and for geographic routing services. There is > apparantly a URL format for geographic location, so this > could be used for this purpose. > > Where is the URL format specified? > > I agree that URL is a good place to accomodate geographical > location and it > would be useful to have a standardized notation. > draft-daviel-http-geo-header-02.txt > specifies header fields for conveying location in HTTP. > However as the position > identifies services and may be used with more protocols than > just HTTP I would > prefer conveying it in URLs. > > Henning's 911 draft also addresses many of related issues. > > Is there interest in going ahead with such URLs? > > Jiri > > > > ------------ > P.S. It seems to me there are some geo-service points on > which some folks > like to disagree. Let me give a couple of more details from > my perspective > so that we can save a couple of RTTs if there is interest in > discussing this. > - URL format for conveying geo-info is a URL format and > nothing else. There > are three orthogonal jobs: 1) determining geo-info, 2) > finding a server > providing location-base services and 3) conveying the > geo-info to it. > Geo-info in URLs would make only the third job. > - The geo-info may be gained from anywhere: access providers, > from GPS provider, > typed-in by sextant-equipped user, from IPv6 address, etc. > It does not have to > indicate your current position; for example, when planning > a trip a travelling > agent may want to get connected to a hotel nearby his > client's destination. > - Both end-devices and proxies (if they know it) may insert > geo-info. The latter > case may be subject to privacy issues -- users may not be > always happy to > disseminate geo-info. > - No limitations are put on how to find location-based > services. They may be > located at an outbound proxy discovered automatically using > DHCP but they > may be at Jeff's pizza server advertised in newspaper as well. > - No assumptions are made about what the services are; it is > service providers' > discretion to implement "conntact a Pizza Inc. rep in > caller's proximity", > "notify my parents whenever I move", "emergency", etc. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 11:38:56 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11395 for ; Mon, 5 Feb 2001 11:38:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3AE4844399; Mon, 5 Feb 2001 10:39:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id 095DD44339 for ; Mon, 5 Feb 2001 10:38:01 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 200754CE27; Mon, 5 Feb 2001 11:37:47 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA15330; Mon, 5 Feb 2001 11:37:43 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (SGI-8.9.3/8.8.5) id LAA57244; Mon, 5 Feb 2001 11:39:57 -0500 (EST) Message-Id: <200102051639.LAA57244@fish-ha.research.att.com> To: brian.rosen@marconi.com Cc: sip@lists.bell-labs.com Subject: [SIP] Re: Location information Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 5 Feb 2001 11:39:57 -0500 (EST) Brian, It seems that the privacy draft faces up squarely to the privacy concerns. The draft already deals with all the regulatory requirements about verification of identity, hiding of identity, etc. The security implications of knowing who you are are just as daunting as knowing where you are. In some places regulations already cover location info, and the framework in the privacy draft deals with them. As with the subscriber identity - the UA may insert it, and may demand (via a tag and a Proxy-Require) that it be kept private. The proxies may verify the identity, and mark it verified, or mark it unverified, and must delete the information if privacy was requested. The procedures are all there in the privacy draft, and just need some minor extensions to handle multiple identity types, and per-identity privacy requests. The previous efforts (spatial) generated a string giving location information. Sip uses "name-addr | addr-spec" everywhere, which includes a display-name string; however a URL format would be nicer. I was sure I had heard about a URL format with this information, but can't find any reference to it. Bill Marshall wtm@research.att.com -----original message----- From: "Rosen, Brian" Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft) Date: Mon, 5 Feb 2001 10:44:54 -0500 There was an effort started several IETFs ago to define a PROTOCOL to exchange geographic location. That was shot down. There is still a low level effort to define a format for exchanging such information. Before starting another effort, you might want to look at the prior work (spatial). You also MUST forthrightly face up to the privacy concerns that have stymied other efforts. The security implications of knowing where you are can be VERY daunting, and in general discussions on the issues have yielded more problems than answers.' Brian _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 12:03:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11954 for ; Mon, 5 Feb 2001 12:03:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 43E7F4436D; Mon, 5 Feb 2001 11:03:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id DA61944336 for ; Mon, 5 Feb 2001 11:02:04 -0500 (EST) 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 MAA22523; Mon, 5 Feb 2001 12:01:49 -0500 (EST) 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 MAA21974; Mon, 5 Feb 2001 12:01:50 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <1H2LA57T>; Mon, 5 Feb 2001 12:01:46 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EE68@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'William Marshall'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 5 Feb 2001 12:01:48 -0500 The problem that location presents that is different from the privacy draft (unless I missed it) is that an emergency call must yield location information. There is not an option for the user to suppress this, by law. The path by which a user might connect to an emergency center cannot be pre-arranged. I believe that it will take creation of a cryptographically secure infrastructure to allow such a system to have the desired property that the user can control location information, but when required it can be securely delivered. I also think that location is not an "all or nothing" kind of thing. The privacy draft presupposes that the world is bifurcated into trusted and untrusted domains, and privacy is secured when venturing into an untrusted domain. This is not the behavior I really want. The desired behavior I want is: Accuracy (precision) of location is variable I may want to give some people precise information, others less precise. There will be multiple levels Time (and motion) variability - if I am mobile, then where I am changes over time. I need to express this somehow, but I also need to control it (not everyone can be told that I am mobile) What we learned in the spatial effort is that the whole location thing is more complex that you would like it to be, and it is hard to get an implementable subset that has enough functionality to be interesting. We also learned the difficulties in reaching consensus on issues that involve privacy. Brian > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Monday, February 05, 2001 11:40 AM > To: brian.rosen@marconi.com > Cc: sip@lists.bell-labs.com > Subject: [SIP] Re: Location information > > > Brian, > > It seems that the privacy draft faces up squarely to the privacy > concerns. The draft already deals with all the regulatory > requirements > about verification of identity, hiding of identity, etc. The security > implications of knowing who you are are just as daunting as knowing > where you are. In some places regulations already cover > location info, > and the framework in the privacy draft deals with them. > > As with the subscriber identity - the UA may insert it, and may > demand (via a tag and a Proxy-Require) that it be kept private. > The proxies may verify the identity, and mark it verified, or mark > it unverified, and must delete the information if privacy was > requested. > The procedures are all there in the privacy draft, and just need > some minor extensions to handle multiple identity types, and > per-identity > privacy requests. > > The previous efforts (spatial) generated a string giving location > information. Sip uses "name-addr | addr-spec" everywhere, which > includes a display-name string; however a URL format would be nicer. > I was sure I had heard about a URL format with this information, but > can't find any reference to it. > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: "Rosen, Brian" > Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft) > Date: Mon, 5 Feb 2001 10:44:54 -0500 > > There was an effort started several IETFs ago to define a PROTOCOL > to exchange geographic location. That was shot down. There is still > a low level effort to define a format for exchanging such information. > > Before starting another effort, you might want to look at the prior > work (spatial). You also MUST forthrightly face up to the privacy > concerns that have stymied other efforts. The security > implications of > knowing where you are can be VERY daunting, and in general discussions > on the issues have yielded more problems than answers.' > > Brian > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 12:05:31 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12005 for ; Mon, 5 Feb 2001 12:05:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8F712443AB; Mon, 5 Feb 2001 11:04:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id F2483443A9 for ; Mon, 5 Feb 2001 11:03:55 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 5 Feb 2001 09:27:48 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 5 Feb 2001 09:27:49 -0500 Message-ID: <28560036253BD41191A10000F8BCBD1103970FED@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Christer Holmberg , Keith Robinson Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F7F.C4948460" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 5 Feb 2001 09:27:28 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08F7F.C4948460 Content-Type: text/plain; charset="ISO-8859-1" I think if we view the SIP Server as a B2BUA, the same reasoning does apply as for the egress gateway to the PSTN: once the initial SIP call reaches the SIP Server, the subsequent digits do not directly affect the state of that initial call, and may therefore be carried in INFO messages. I guess it's time to run through call flows and see whether the ingress gateway can behave properly regardless of the signalling protocol beyond the SIP Server. I suspect Christer is right, and a 1xx response code indicating that an onward call needs more digits is desirable. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Monday, February 05, 2001 8:43 AM > To: Keith Robinson > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > I meant 484. Sorry. :) > > Christer Holmberg > Ericsson Finland > > > Keith Robinson wrote: > > > > In your text do you mean 484 and not 486 ? > > > > If it is legal for a gateway interworking with the PSTN to gather > > digits using the INFO message and responding with some 18X response > > then I don't see why it can't be legal for the server you > have defined in this > > scenario. > > > > Such a server now has two choices for collecting digits; it > either issues a 18X > > and > > waits for further digits in the INFO message, or it issues > 484 and waits for the > > subsequent INVITE. > > > > The choice will probably be dictated by the > implementationof the digit decode. > > If the implementation for > > decoding digits is more efficiently used by starting it off > and then passing it > > subsequent digits, the 484 method would be inefficient as > this would mean > > clearing > > down the algorithm state between INVITEs and starting it > off again on the > > subsequent > > initial INVITE (as otherwise there is a problem with the > subsequent initial > > INVITEs > > getting to the same server as I have previously highlighted); if the > > implemtation is equally > > efficient whether it decodes anew each time or on a digit > string by digit > > string basis, then the 484 > > method would be the best. > > > > Regards, > > > > K. Robinson. > > > > Christer Holmberg on > 05/02/2001 12:14:21 > > > > > > > > > > > > > > > > To: sip@lists.bell-labs.com > > > > cc: (bcc: Keith Robinson/MAIN/MC1) > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > I would like to clarify the scenario a little. > > > > The SIP server is NOT a normal proxy in the SIP network, > via which the > > INVITE is routed to the UAS (if it was, we would use 486 > responses until > > the proxy can route the call to the UAS, like Tom proposed > earlier in > > the Operlap Dialing thread). > > > > Instead, the server could be some kind of automatic phone > switch, for > > example connected to a VPN. The difference from a NAT would > be that it > > is connected directly to a number of UAS, so it needs the > digits to be > > able to find the correct UAS. > > > > If the UAS would be, for example, a PSTN phone, the SIP > server would be > > a PSTN GW, so then it would be allowed, but what is it > wants to use the > > same logic to route a call to another network using SIP (or, maybe > > another VoIP protocol). > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > Hi, > > > > > > The discussion about overlap dialing has been pretty much > about calls > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > Consider the following scenario. > > > > > > PSTN PHONE GW SIP SERVER SIP UAS > > > ----------------------------------------------------------- > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > | <- 18x ------ | > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > | <- 200 (INFO) | > > > | <- 18x ------ | > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > | <- 200 (INFO) | -- INVITE > > > --> > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > In this case, the SIP server (note that I am not using > the word 'proxy') > > > must collect digits, sent from the PSTN side using > overlap dialing, to > > > be able to find the SIP UAS, and INFO is used to provide > the digits > > > after the INVITE has been sent. > > > > > > My question is, should a SIP server (proxy, if you like) > be allowed to > > > behave like this, or MUST it send 486s, and receive new > INVITEs, until > > > it is able to find the UAS? > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > ------_=_NextPart_001_01C08F7F.C4948460 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Operlap dialing within a SIP network

I think if we view the SIP Server as a B2BUA, the = same reasoning does apply as for the egress gateway to the PSTN: once = the initial SIP call reaches the SIP Server, the subsequent digits do = not directly affect the state of that initial call, and may therefore = be carried in INFO messages.

I guess it's time to run through call flows and see = whether the ingress gateway can behave properly regardless of the = signalling protocol beyond the SIP Server.  I suspect Christer is = right, and a 1xx response code indicating that an onward call needs = more digits is desirable.

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: Monday, February 05, 2001 8:43 AM
> To: Keith Robinson
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] Operlap dialing within a SIP = network
>
>
>
>
> I meant 484. Sorry. :)
>
> Christer Holmberg
> Ericsson Finland
>
>
> Keith Robinson wrote:
> >
> > In your text  do you mean 484 and not = 486 ?
> >
> > If it is legal for a gateway interworking = with the PSTN to gather
> > digits using the INFO message and = responding with some 18X response
> > then I don't see why it can't be legal for = the server you
> have defined in this
> > scenario.
> >
> > Such a server now has two choices for = collecting digits; it
> either issues a 18X
> > and
> > waits for further digits in the INFO = message, or it issues
> 484 and waits for the
> > subsequent INVITE.
> >
> > The choice will probably be dictated by = the
> implementationof the digit decode.
> > If the implementation for
> > decoding digits is more efficiently used = by starting it off
> and then passing it
> > subsequent digits, the 484 method would be = inefficient as
> this would mean
> > clearing
> > down the algorithm state between INVITEs = and starting it
> off again on the
> > subsequent
> > initial INVITE (as otherwise there is a = problem with the
> subsequent initial
> > INVITEs
> > getting to the same server as I have = previously highlighted); if the
> > implemtation is equally
> > efficient whether it decodes anew each = time or on a digit
> string  by digit
> > string basis, then the 484
> > method would be the best.
> >
> > Regards,
> >
> > K. Robinson.
> >
> > Christer Holmberg = <christer.holmberg@lmf.ericsson.se> on
> 05/02/2001 12:14:21
> >
> >
> >
> >
> >
> >
> >
> >  To:      = sip@lists.bell-labs.com
> >
> >  cc:      = (bcc: Keith Robinson/MAIN/MC1)
> >
> >
> >
> >  Subject: Re: [SIP] Operlap dialing = within a SIP network
> >
> >
> > I would like to clarify the scenario a = little.
> >
> > The SIP server is NOT a normal proxy in = the SIP network,
> via which the
> > INVITE is routed to the UAS (if it was, we = would use 486
> responses until
> > the proxy can route the call to the UAS, = like Tom proposed
> earlier in
> > the Operlap Dialing thread).
> >
> > Instead, the server could be some kind of = automatic phone
> switch, for
> > example connected to a VPN. The difference = from a NAT would
> be that it
> > is connected directly to a number of UAS, = so it needs the
> digits to be
> > able to find the correct UAS.
> >
> > If the UAS would be, for example, a PSTN = phone, the SIP
> server would be
> > a PSTN GW, so then it would be allowed, = but what is it
> wants to use the
> > same logic to route a call to another = network using SIP (or, maybe
> > another VoIP protocol).
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> > > Hi,
> > >
> > > The discussion about overlap dialing = has been pretty much
> about calls
> > > from SIP to PSTN, or = PSTN-SIP-PSTN.
> > >
> > > Consider the following = scenario.
> > >
> > > PSTN = PHONE           &= nbsp; GW           = SIP SERVER      SIP UAS
> > > = -----------------------------------------------------------
> > >
> > > --- 1 --->    -- = IAM -> | -- INVITE -->  |
> > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > --- 2 --->    -- = SAM -> | -- INFO ---->  |
> > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |
> > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > --- 3 --->    -- = SAM -> | -- INFO ---->  |
> > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |   -- INVITE
> > > -->
> > = >           &n= bsp;           &n= bsp; | <- 200 (INVITE)|   <- 200 ------
> > >
> > > In this case, the SIP server (note = that I am not using
> the word 'proxy')
> > > must collect digits, sent from the = PSTN side using
> overlap dialing, to
> > > be able to find the SIP UAS, and INFO = is used to provide
> the digits
> > > after the INVITE has been = sent.
> > >
> > > My question is, should a SIP server = (proxy, if you like)
> be allowed to
> > > behave like this, or MUST it send = 486s, and receive new
> INVITEs, until
> > > it is able to find the UAS?
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
>

------_=_NextPart_001_01C08F7F.C4948460-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 12:09:47 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12109 for ; Mon, 5 Feb 2001 12:09:43 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 575E9443B1; Mon, 5 Feb 2001 11:04:16 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 12AE3443AA for ; Mon, 5 Feb 2001 11:03:56 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 5 Feb 2001 09:17:34 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 5 Feb 2001 09:17:34 -0500 Message-ID: <28560036253BD41191A10000F8BCBD1103970FA9@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Christer Holmberg , sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08F7E.6115BE00" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 5 Feb 2001 09:17:32 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08F7E.6115BE00 Content-Type: text/plain; charset="ISO-8859-1" I see a few more messages in this thread, but I'll note now that your "SIP Server" must be a back-to-back UA. I'm not sure why it would send a 18x response before it knew how to route the call to its final destination. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Monday, February 05, 2001 6:47 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Operlap dialing within a SIP network > > > > Hi, > > The discussion about overlap dialing has been pretty much about calls > from SIP to PSTN, or PSTN-SIP-PSTN. > > Consider the following scenario. > > PSTN PHONE GW SIP SERVER SIP UAS > ----------------------------------------------------------- > > --- 1 ---> -- IAM -> | -- INVITE --> | > | <- 18x ------ | > --- 2 ---> -- SAM -> | -- INFO ----> | > | <- 200 (INFO) | > | <- 18x ------ | > --- 3 ---> -- SAM -> | -- INFO ----> | > | <- 200 (INFO) | -- INVITE > --> > | <- 200 (INVITE)| <- 200 ------ > > In this case, the SIP server (note that I am not using the > word 'proxy') > must collect digits, sent from the PSTN side using overlap dialing, to > be able to find the SIP UAS, and INFO is used to provide the digits > after the INVITE has been sent. > > My question is, should a SIP server (proxy, if you like) be allowed to > behave like this, or MUST it send 486s, and receive new INVITEs, until > it is able to find the UAS? > > > Regards, > > Christer Holmberg > Ericsson Finland > ------_=_NextPart_001_01C08F7E.6115BE00 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Operlap dialing within a SIP network

I see a few more messages in this thread, but I'll = note now that your "SIP Server" must be a back-to-back = UA.  I'm not sure why it would send a 18x response before it knew = how to route the call to its final destination.

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: Monday, February 05, 2001 6:47 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Operlap dialing within a SIP = network
>
>
>
> Hi,
>
> The discussion about overlap dialing has been = pretty much about calls
> from SIP to PSTN, or PSTN-SIP-PSTN.
>
> Consider the following scenario.
>
> PSTN = PHONE           &= nbsp; GW           = SIP SERVER      SIP UAS
> = -----------------------------------------------------------
>
> --- 1 --->    -- IAM -> | = -- INVITE -->  |
>          = ;            = ;   | <- 18x ------  |
> --- 2 --->    -- SAM -> | = -- INFO ---->  |
>          = ;            = ;   | <- 200 (INFO)  |
>          = ;            = ;   | <- 18x ------  |
> --- 3 --->    -- SAM -> | = -- INFO ---->  |
>          = ;            = ;   | <- 200 (INFO)  |   -- INVITE
> = -->           =             =             =         
>          = ;            = ;   | <- 200 (INVITE)|   <- 200 ------ =
>
> In this case, the SIP server (note that I am = not using the
> word 'proxy')
> must collect digits, sent from the PSTN side = using overlap dialing, to
> be able to find the SIP UAS, and INFO is used = to provide the digits
> after the INVITE has been sent.
>
> My question is, should a SIP server (proxy, if = you like) be allowed to
> behave like this, or MUST it send 486s, and = receive new INVITEs, until
> it is able to find the UAS?
>
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>

------_=_NextPart_001_01C08F7E.6115BE00-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 13:23:56 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13562 for ; Mon, 5 Feb 2001 13:23:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 079C644339; Mon, 5 Feb 2001 12:24:06 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id A9DF344336 for ; Mon, 5 Feb 2001 12:23:47 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Feb 5 13:20:02 EST 2001 Received: by lists.bell-labs.com (Postfix) id 35F0244380; Mon, 5 Feb 2001 13:08:24 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id C02F84437D for ; Mon, 5 Feb 2001 13:08:23 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 18:08:23 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00BD0D3@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Jiri Kuthan'" , Mark Watson , "'Rosen, Brian'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 5 Feb 2001 18:08:21 -0000 There is however a requirement in existing protocols for passing this information around within network entities. Therefore you will see support in ISUP, MAP, INAP and CAMEL for such an identifier. I believe that there is requirement to be able to carry this identifier within SIP, although not in "clear" to the user entities. Work done in ITU-T and in ETSI, both in the services area and in the ISUP area, defined this identifier as another form of calling line identity. The usage in these protocols is all based on the same set of underlying variants, of which the best definition in protocol independent terms is probably in the following 3GPP reference TS 23.032. 3rd Generation Partnership Project; Technical Specification Group Core Network; Universal Geographical Area Description (GAD) and which may be found at the following URL ftp://ftp.3gpp.org/Specs/2000-12/R1999/23_series/23032-310.zip Due to the need to interwork between SIP and other protocols, it would appear to be essential to maintain the same number and type of parameters within the SIP encoding, although some difference will obviously have to exist at the transfer level to allow a text encoding in SIP, while the other protocols use a binary encoding. This is not a matter of telling the IETF what to do, it is merely that every other signalling protocol in the world appears to use a subset of these formats. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Rosen, Brian[SMTP:Brian.Rosen@marconi.com] > Sent: 05 February 2001 15:44 > To: 'Jiri Kuthan'; Mark Watson > Cc: 'sip@lists.bell-labs.com' > Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft) > > There was an effort started several IETFs ago to define a PROTOCOL > to exchange geographic location. That was shot down. There is still > a low level effort to define a format for exchanging such information. > > Before starting another effort, you might want to look at the prior > work (spatial). You also MUST forthrightly face up to the privacy > concerns that have stymied other efforts. The security implications of > knowing where you are can be VERY daunting, and in general discussions > on the issues have yielded more problems than answers.' > > Brian > > > -----Original Message----- > > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > > Sent: Saturday, February 03, 2001 4:49 PM > > To: Mark Watson > > Cc: 'sip@lists.bell-labs.com' > > Subject: Location information (was Re: [SIP] SIP Privacy Draft) > > > > > > > Mark Watson wrote: > > [...] > > > 5) Location Information > > > > > > A further type of Party information is the physical > > location of the Party. This is useful for calls to emergency > > service centers and for geographic routing services. There is > > apparantly a URL format for geographic location, so this > > could be used for this purpose. > > > > Where is the URL format specified? > > > > I agree that URL is a good place to accomodate geographical > > location and it > > would be useful to have a standardized notation. > > draft-daviel-http-geo-header-02.txt > > specifies header fields for conveying location in HTTP. > > However as the position > > identifies services and may be used with more protocols than > > just HTTP I would > > prefer conveying it in URLs. > > > > Henning's 911 draft also addresses many of related issues. > > > > Is there interest in going ahead with such URLs? > > > > Jiri > > > > > > > > ------------ > > P.S. It seems to me there are some geo-service points on > > which some folks > > like to disagree. Let me give a couple of more details from > > my perspective > > so that we can save a couple of RTTs if there is interest in > > discussing this. > > - URL format for conveying geo-info is a URL format and > > nothing else. There > > are three orthogonal jobs: 1) determining geo-info, 2) > > finding a server > > providing location-base services and 3) conveying the > > geo-info to it. > > Geo-info in URLs would make only the third job. > > - The geo-info may be gained from anywhere: access providers, > > from GPS provider, > > typed-in by sextant-equipped user, from IPv6 address, etc. > > It does not have to > > indicate your current position; for example, when planning > > a trip a travelling > > agent may want to get connected to a hotel nearby his > > client's destination. > > - Both end-devices and proxies (if they know it) may insert > > geo-info. The latter > > case may be subject to privacy issues -- users may not be > > always happy to > > disseminate geo-info. > > - No limitations are put on how to find location-based > > services. They may be > > located at an outbound proxy discovered automatically using > > DHCP but they > > may be at Jeff's pizza server advertised in newspaper as well. > > - No assumptions are made about what the services are; it is > > service providers' > > discretion to implement "conntact a Pizza Inc. rep in > > caller's proximity", > > "notify my parents whenever I move", "emergency", etc. > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 13:28:56 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13731 for ; Mon, 5 Feb 2001 13:28:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0580C443AA; Mon, 5 Feb 2001 12:29:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 950F0443A9 for ; Mon, 5 Feb 2001 12:28:20 -0500 (EST) 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 NAA29647; Mon, 5 Feb 2001 13:28:04 -0500 (EST) 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 NAA12971; Mon, 5 Feb 2001 13:28:05 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <1H2LA05X>; Mon, 5 Feb 2001 13:28:01 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EE6D@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Drage, Keith (Keith)'" , "'Jiri Kuthan'" , Mark Watson Cc: "'sip@lists.bell-labs.com'" Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 5 Feb 2001 13:28:04 -0500 The cited proposal uses WGS84, which is the accepted standard for world coordinates. I know that there is some variability in the precise ellipsoid definitions that have some national variation. I'm not enough of an expert to know which version this represents, but it appears to offer no variation, so they probably picked one and went on; a position I favor. It also seems to have all of the variables one might want (including motion vectors). So, I would agree that we want to have something very closely aligned with this format in terms of parameters. I didn't see anything having to do with intentional degrading of accuracy, so that is one missing capability. Brian > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Monday, February 05, 2001 1:08 PM > To: 'Jiri Kuthan'; Mark Watson; 'Rosen, Brian' > Cc: 'sip@lists.bell-labs.com' > Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft) > > > There is however a requirement in existing protocols for passing this > information around within network entities. Therefore you > will see support > in ISUP, MAP, INAP and CAMEL for such an identifier. I > believe that there is > requirement to be able to carry this identifier within SIP, > although not in > "clear" to the user entities. Work done in ITU-T and in ETSI, > both in the > services area and in the ISUP area, defined this identifier > as another form > of calling line identity. > > The usage in these protocols is all based on the same set of > underlying > variants, of which the best definition in protocol > independent terms is > probably in the following 3GPP reference > > TS 23.032. > > 3rd Generation Partnership Project; > Technical Specification Group Core Network; > Universal Geographical Area Description (GAD) > > and which may be found at the following URL > > ftp://ftp.3gpp.org/Specs/2000-12/R1999/23_series/23032-310.zip > > Due to the need to interwork between SIP and other protocols, it would > appear to be essential to maintain the same number and type > of parameters > within the SIP encoding, although some difference will > obviously have to > exist at the transfer level to allow a text encoding in SIP, > while the other > protocols use a binary encoding. > > This is not a matter of telling the IETF what to do, it is > merely that every > other signalling protocol in the world appears to use a > subset of these > formats. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > ---------- > > From: Rosen, Brian[SMTP:Brian.Rosen@marconi.com] > > Sent: 05 February 2001 15:44 > > To: 'Jiri Kuthan'; Mark Watson > > Cc: 'sip@lists.bell-labs.com' > > Subject: RE: Location information (was Re: [SIP] SIP > Privacy Draft) > > > > There was an effort started several IETFs ago to define a PROTOCOL > > to exchange geographic location. That was shot down. > There is still > > a low level effort to define a format for exchanging such > information. > > > > Before starting another effort, you might want to look at the prior > > work (spatial). You also MUST forthrightly face up to the privacy > > concerns that have stymied other efforts. The security > implications of > > knowing where you are can be VERY daunting, and in general > discussions > > on the issues have yielded more problems than answers.' > > > > Brian > > > > > -----Original Message----- > > > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > > > Sent: Saturday, February 03, 2001 4:49 PM > > > To: Mark Watson > > > Cc: 'sip@lists.bell-labs.com' > > > Subject: Location information (was Re: [SIP] SIP Privacy Draft) > > > > > > > > > > Mark Watson wrote: > > > [...] > > > > 5) Location Information > > > > > > > > A further type of Party information is the physical > > > location of the Party. This is useful for calls to emergency > > > service centers and for geographic routing services. There is > > > apparantly a URL format for geographic location, so this > > > could be used for this purpose. > > > > > > Where is the URL format specified? > > > > > > I agree that URL is a good place to accomodate geographical > > > location and it > > > would be useful to have a standardized notation. > > > draft-daviel-http-geo-header-02.txt > > > specifies header fields for conveying location in HTTP. > > > However as the position > > > identifies services and may be used with more protocols than > > > just HTTP I would > > > prefer conveying it in URLs. > > > > > > Henning's 911 draft also addresses many of related issues. > > > > > > Is there interest in going ahead with such URLs? > > > > > > Jiri > > > > > > > > > > > > ------------ > > > P.S. It seems to me there are some geo-service points on > > > which some folks > > > like to disagree. Let me give a couple of more details from > > > my perspective > > > so that we can save a couple of RTTs if there is interest in > > > discussing this. > > > - URL format for conveying geo-info is a URL format and > > > nothing else. There > > > are three orthogonal jobs: 1) determining geo-info, 2) > > > finding a server > > > providing location-base services and 3) conveying the > > > geo-info to it. > > > Geo-info in URLs would make only the third job. > > > - The geo-info may be gained from anywhere: access providers, > > > from GPS provider, > > > typed-in by sextant-equipped user, from IPv6 address, etc. > > > It does not have to > > > indicate your current position; for example, when planning > > > a trip a travelling > > > agent may want to get connected to a hotel nearby his > > > client's destination. > > > - Both end-devices and proxies (if they know it) may insert > > > geo-info. The latter > > > case may be subject to privacy issues -- users may not be > > > always happy to > > > disseminate geo-info. > > > - No limitations are put on how to find location-based > > > services. They may be > > > located at an outbound proxy discovered automatically using > > > DHCP but they > > > may be at Jeff's pizza server advertised in newspaper as well. > > > - No assumptions are made about what the services are; it is > > > service providers' > > > discretion to implement "conntact a Pizza Inc. rep in > > > caller's proximity", > > > "notify my parents whenever I move", "emergency", etc. > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > > > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 13:32:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13856 for ; Mon, 5 Feb 2001 13:32:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7449C443BA; Mon, 5 Feb 2001 12:30:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id 0C9D4443A9 for ; Mon, 5 Feb 2001 12:29:26 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 32C814CE79; Mon, 5 Feb 2001 13:29:12 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA19794; Mon, 5 Feb 2001 13:29:08 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (SGI-8.9.3/8.8.5) id NAA81646; Mon, 5 Feb 2001 13:31:03 -0500 (EST) Message-Id: <200102051831.NAA81646@fish-ha.research.att.com> To: brian.rosen@marconi.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 5 Feb 2001 13:31:03 -0500 (EST) An ordinary call must yield subscriber information. There is not an option for the user to suppress this, by law (although the user may request this information not be given to the destination). However, the destination can always identify the caller, for purposes of tracing an obscene or harassing call. Accuracy of location is certainly variable, and it is possible the UA may permit delivery of less precise information, but suppress accurate information. Multiple levels are just like multiple identities; the privacy draft as described by Mark in previous email allows separate anonymity requirements to be attached to each. Bill Marshall wtm@research.att.com -----original message----- From: "Rosen, Brian" To: "'William Marshall'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information Date: Mon, 5 Feb 2001 12:01:48 -0500 The problem that location presents that is different from the privacy draft (unless I missed it) is that an emergency call must yield location information. There is not an option for the user to suppress this, by law. The path by which a user might connect to an emergency center cannot be pre-arranged. I believe that it will take creation of a cryptographically secure infrastructure to allow such a system to have the desired property that the user can control location information, but when required it can be securely delivered. I also think that location is not an "all or nothing" kind of thing. The privacy draft presupposes that the world is bifurcated into trusted and untrusted domains, and privacy is secured when venturing into an untrusted domain. This is not the behavior I really want. The desired behavior I want is: Accuracy (precision) of location is variable I may want to give some people precise information, others less precise. There will be multiple levels Time (and motion) variability - if I am mobile, then where I am changes over time. I need to express this somehow, but I also need to control it (not everyone can be told that I am mobile) What we learned in the spatial effort is that the whole location thing is more complex that you would like it to be, and it is hard to get an implementable subset that has enough functionality to be interesting. We also learned the difficulties in reaching consensus on issues that involve privacy. Brian > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Monday, February 05, 2001 11:40 AM > To: brian.rosen@marconi.com > Cc: sip@lists.bell-labs.com > Subject: [SIP] Re: Location information > > > Brian, > > It seems that the privacy draft faces up squarely to the privacy > concerns. The draft already deals with all the regulatory > requirements > about verification of identity, hiding of identity, etc. The security > implications of knowing who you are are just as daunting as knowing > where you are. In some places regulations already cover > location info, > and the framework in the privacy draft deals with them. > > As with the subscriber identity - the UA may insert it, and may > demand (via a tag and a Proxy-Require) that it be kept private. > The proxies may verify the identity, and mark it verified, or mark > it unverified, and must delete the information if privacy was > requested. > The procedures are all there in the privacy draft, and just need > some minor extensions to handle multiple identity types, and > per-identity > privacy requests. > > The previous efforts (spatial) generated a string giving location > information. Sip uses "name-addr | addr-spec" everywhere, which > includes a display-name string; however a URL format would be nicer. > I was sure I had heard about a URL format with this information, but > can't find any reference to it. > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: "Rosen, Brian" > Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft) > Date: Mon, 5 Feb 2001 10:44:54 -0500 > > There was an effort started several IETFs ago to define a PROTOCOL > to exchange geographic location. That was shot down. There is still > a low level effort to define a format for exchanging such information. > > Before starting another effort, you might want to look at the prior > work (spatial). You also MUST forthrightly face up to the privacy > concerns that have stymied other efforts. The security > implications of > knowing where you are can be VERY daunting, and in general discussions > on the issues have yielded more problems than answers.' > > Brian > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 13:49:56 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14255 for ; Mon, 5 Feb 2001 13:49:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 98DAB4439E; Mon, 5 Feb 2001 12:50:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 5BE124436F for ; Mon, 5 Feb 2001 12:49:33 -0500 (EST) 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 NAA01557; Mon, 5 Feb 2001 13:49:17 -0500 (EST) 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 NAA18249; Mon, 5 Feb 2001 13:49:18 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <1H2LBBCR>; Mon, 5 Feb 2001 13:48:24 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EE6E@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'William Marshall'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 5 Feb 2001 13:48:25 -0500 If I have an enterprise network, and it connects to a public network, then the trust boundary may stop at the private/public boundary. The "subscriber" is the enterprise, not the individual. In the privacy draft, if extended to location, there is no mechanism to: Recognize that this is an emergency call Recognize that the UAS is the emergency center Pass location information despite any of the requests the UAC may make. Yet, the requirement is to identify the location of the individual. I think the draft has some fine mechanisms in it. I just don't think they are sufficient for emergency purposes. Brian > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Monday, February 05, 2001 1:31 PM > To: brian.rosen@marconi.com > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] Re: Location information > > > An ordinary call must yield subscriber information. There is > not an option for the user to suppress this, by law (although the > user may request this information not be given to the destination). > However, the destination can always identify the caller, for purposes > of tracing an obscene or harassing call. > > Accuracy of location is certainly variable, and it is possible > the UA may permit delivery of less precise information, but suppress > accurate information. Multiple levels are just like multiple > identities; > the privacy draft as described by Mark in previous email > allows separate > anonymity requirements to be attached to each. > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: "Rosen, Brian" > To: "'William Marshall'" > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] Re: Location information > Date: Mon, 5 Feb 2001 12:01:48 -0500 > > The problem that location presents that is different from the > privacy draft (unless I missed it) is that an emergency call must > yield location information. There is not an option for the user > to suppress this, by law. The path by which a user might connect > to an emergency center cannot be pre-arranged. I believe that it > will take creation of a cryptographically secure infrastructure > to allow such a system to have the desired property that the user > can control location information, but when required it can be > securely delivered. > > I also think that location is not an "all or nothing" kind of > thing. The privacy draft presupposes that the world is bifurcated > into trusted and untrusted domains, and privacy is secured > when venturing into an untrusted domain. This is not the behavior > I really want. The desired behavior I want is: > Accuracy (precision) of location is variable > I may want to give some people precise > information, others > less precise. There will be multiple levels > Time (and motion) variability - if I am mobile, then where I > am changes over time. I need to express this somehow, > but I also need to control it (not everyone can > be told that > I am mobile) > What we learned in the spatial effort is that the whole location thing > is more complex that you would like it to be, and it is hard to get > an implementable subset that has enough functionality to be > interesting. > We also learned the difficulties in reaching consensus on issues that > involve privacy. > > Brian > > > > > > -----Original Message----- > > From: William Marshall [mailto:wtm@research.att.com] > > Sent: Monday, February 05, 2001 11:40 AM > > To: brian.rosen@marconi.com > > Cc: sip@lists.bell-labs.com > > Subject: [SIP] Re: Location information > > > > > > Brian, > > > > It seems that the privacy draft faces up squarely to the privacy > > concerns. The draft already deals with all the regulatory > > requirements > > about verification of identity, hiding of identity, etc. > The security > > implications of knowing who you are are just as daunting as knowing > > where you are. In some places regulations already cover > > location info, > > and the framework in the privacy draft deals with them. > > > > As with the subscriber identity - the UA may insert it, and may > > demand (via a tag and a Proxy-Require) that it be kept private. > > The proxies may verify the identity, and mark it verified, or mark > > it unverified, and must delete the information if privacy was > > requested. > > The procedures are all there in the privacy draft, and just need > > some minor extensions to handle multiple identity types, and > > per-identity > > privacy requests. > > > > The previous efforts (spatial) generated a string giving location > > information. Sip uses "name-addr | addr-spec" everywhere, which > > includes a display-name string; however a URL format would be nicer. > > I was sure I had heard about a URL format with this information, but > > can't find any reference to it. > > > > Bill Marshall > > wtm@research.att.com > > > > -----original message----- > > From: "Rosen, Brian" > > Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft) > > Date: Mon, 5 Feb 2001 10:44:54 -0500 > > > > There was an effort started several IETFs ago to define a PROTOCOL > > to exchange geographic location. That was shot down. > There is still > > a low level effort to define a format for exchanging such > information. > > > > Before starting another effort, you might want to look at the prior > > work (spatial). You also MUST forthrightly face up to the privacy > > concerns that have stymied other efforts. The security > > implications of > > knowing where you are can be VERY daunting, and in general > discussions > > on the issues have yielded more problems than answers.' > > > > Brian > > > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 5 14:25:55 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15298 for ; Mon, 5 Feb 2001 14:25:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A23624436F; Mon, 5 Feb 2001 13:26:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cundall.co.uk (dorfl.roke.co.uk [193.118.192.45]) by lists.bell-labs.com (Postfix) with SMTP id D0EC444336 for ; Mon, 5 Feb 2001 13:25:02 -0500 (EST) Received: from [193.118.195.83] ([193.118.195.83] verified) by cundall.co.uk (Stalker SMTP Server 1.7) with ESMTP id S.0000052674; Mon, 05 Feb 2001 19:24:45 +0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <200102051831.NAA81646@fish-ha.research.att.com> References: <200102051831.NAA81646@fish-ha.research.att.com> To: William Marshall From: Lawrence Conroy Subject: RE: [SIP] Re: Location information Cc: sip@lists.bell-labs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 5 Feb 2001 19:26:49 +0000 At 1:31 pm -0500 5/2/2001, William Marshall wrote: >An ordinary call must yield subscriber information. There is >not an option for the user to suppress this, by law (although the >user may request this information not be given to the destination). >However, the destination can always identify the caller, for purposes >of tracing an obscene or harassing call. > >Accuracy of location is certainly variable, and it is possible >the UA may permit delivery of less precise information, but suppress >accurate information. Multiple levels are just like multiple identities; >the privacy draft as described by Mark in previous email allows separate >anonymity requirements to be attached to each. > >Bill Marshall >wtm@research.att.com Hi all, Forgive if I misunderstand the discussion so far, but in the GSTN the call party has control only over presentation. They have no control over the Calling Line Identity being used within a network (and normally, on a "trust by wire" system, it's the phone Network that sets/validates this anyway). Thus, one might envisage a Network degrading the CLI it presents (maybe to only the last four digits), but the E911 sub-system will still get the "full monty". For Location Based Services it is/will be the same. This is one reason why some Operators have stated that they will NOT trust location information calculated by the Mobile Terminal/User. They will be responsible for delivering full location info to the Public Services Access Point, and THEY want to do the calculation... as before, they are the ones who will either set or validate the location. Now...How they do this in a VoIP world is an interesting topic, IMHO. -- All the best, Lawrence ----------------------------------------------------------------------- | Lawrence Conroy, | "These Opinions must be mine, 'cos if they | | Roke Manor Research | were my Company's they'd pay me for them" | |- lwc@roke.co.uk ---+- Tel: +44 1794 833666 Fax: +44 1794 833434 --| _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 09:14:28 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14563 for ; Tue, 6 Feb 2001 09:14:28 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E2D0744348; Tue, 6 Feb 2001 09:19:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id B5B204436C for ; Tue, 6 Feb 2001 09:18:47 -0500 (EST) 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 f16E45d21307; Tue, 6 Feb 2001 15:04:05 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA20603; Tue, 6 Feb 2001 16:04:05 +0200 (EET) Message-ID: <3A800453.27F473EE@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: Tom-PT Taylor , sip@lists.bell-labs.com, Joshua Moloney Subject: Re: [SIP] Overlap call setup References: <802569EB.004A6692.00@marconicomms.com> Content-Type: multipart/mixed; boundary="------------0B05E45D4B6D3F9084FB204D" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 16:04:03 +0200 This is a multi-part message in MIME format. --------------0B05E45D4B6D3F9084FB204D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >Certainly using explicit SIP responses minimises the need to use context >to determine what ISUP message to generate. I am not opposed to the idea >of using a new response to indicate that some form of routing is taking >place at the egress (or beyond). Of course, the UAS GW could send a 186 when it receives the first INVITE, no matter if more digits will come or not. The 186 would only be a more "safe" (you can use PRACK etc) way then 100 to provide the UAC GW with Contact and/or Record-Route headers, and the UAC GW would not map it into any ISUP message. Then, IF the digits in the INVITE were enough to route the call to the final PSTN user, and the UAS GW receives an ACM, it would map it into a 180 and send it to the UAC GW, which then can map it to an ISUP message. Another issue: The case we have now been discussing is fine for SIP-to-PSTN and PSTN-SIP-PSTN scenarios. However, if we have a PSTN-to-SIP scenario, we would probably not send INFOs. A SIP proxy COULD (I presented this solution in another thread), of course, send 18x and wait for more digits, but since the call in this case is not completely routed (the proxy is not the end user from a SIP point of view) it would probably send 484 responses until an INVITE with enough digits to find the SIP UAS is found. PSTN PHONE GW SIP PROXY SIP UA -------------------------------------------------- -- IAM --> -- INVITE --> <- 484 ------ -- ACK -----> -- SAM --> -- INVITE --> <- 484 ------ -- ACK -----> -- SAM --> -- INVITE --> -- INVITE --> <- 200 ------ <- 200 ------ -- ACK -----> -- ACK -----> So, in this case we would still have to use the 484/re-INVITE mechanism, UNLESS the proxy is allowed to only send a 18x to the first INVITE and then wait for more digits sent in INFO messages (like I showed in the other thread). After all, I think that operlap dialing is going to be used almost only in PSTN-to-SIP (and PSTN-SIP-PSTN) cases. At least I have never seen a SIP Phone that would send digits in separate messages (you type the whole B-number, press 'send' and everything is sent in a single INVITE) Regards, Christer Holmberg Ericsson Finland Regards, Christer (lmfchh) > > Regards, > > K. Robinson > > Christer Holmberg on 05/02/2001 14:20:25 > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > cc: Tom-PT Taylor , > sip@lists.bell-labs.com, Joshua Moloney > > > > > Subject: Re: [SIP] Overlap call setup > > > Hi, > > Keith Robinson wrote: > > > >Christer wrote ; > > > >>Again, we assume that the GWs support ISUP transparency, because if the > >>GW only supports ISUP/SIP mapping it will not be able to know if to > >>generate an ACM when the 18x is received - even if the GW would be smart > >>enough to notice that there is SOME ISUP message in the 180 response. > > > >Surely, if a GW is mapping ISUP to SIP (and vice versa) then there must >be > rules to dictate which SIP messages map to which ISUP messages and in >what > context. In fact, aren't these the rules we are debating ? The point >being that > even if a GW is ONLY performing SIP/ISUP/SIP mapping > >then it STILL MUST know when to genrate the ACM as part of the mapping > >function, REGARDLESS of transparency. > > Yes, and since it may not be possible to have rules when a 180 should > generate a ACM, and when it should not. So, in the case of overlap > dialing, when the 18x is only used to "ask" for more digits, my > suggestion was to use a specific provisional response code that would > not generate an ACM. > > Then, when we want an ACM to be generated, no matter if ISUP > transparency is supported or not, we would send a 180 Alerting. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Regards, > > > > K. Robinson. > > > > Christer Holmberg on 05/02/2001 11:10:49 > > > > > > > > > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > > > cc: Tom-PT Taylor , > > sip@lists.bell-labs.com, Joshua Moloney > > > > > > > > > > Subject: Re: [SIP] Overlap call setup > > > > > > Hi, > > > > Again, we assume that the GWs support ISUP transparency, because if the > > GW only supports ISUP/SIP mapping it will not be able to know if to > > generate an ACM when the 18x is received - even if the GW would be smart > > enough to notice that there is SOME ISUP message in the 180 response. > > > > Personally, I still think that a separate provisional response code > > (I've been using 186 as an example) should be used, and any UAC (SIP > > phone or PSTN GW) supporting overlap dialing must understand the > > response. And, if the UAC knows it has already sent all digits, > > receiving a 186 could, for example, cause it to send a CANCEL to the > > INVITE, instead of waiting for the ISUP digit timers to expire and > > receive a 486 final response. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Keith Robinson wrote: > > > > > > In the absence of receiving an encapsulated ACM, the ingress > > > gateway could generate its own ACM when it receives a 180 Alerting; this > > > response must mean it is safe to assume call routing is complete > > > and caters for terminations within a SIP network. Thought needs to be > > > given to scenarios where a non-200 final response is received, say 486 > > > Busy, as in these cases 180 Alerting, probably, wouldn't be generated. > > > > > > Regards, > > > > > > Keith. > > > > > > "Tom-PT Taylor" on 02/02/2001 14:12:39 > > > > > > > > > > > > > > > > > > > > > > > > To: Christer Holmberg > > > > > > > > > cc: Keith Robinson/MAIN/MC1@MCMAIN, > > > sip@lists.bell-labs.com, "Joshua Moloney" > > > > > > > > > > > > > > > Subject: RE: [SIP] Overlap call setup > > > > > > > > > Replies below. > > > > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > Sent: Friday, February 02, 2001 1:17 AM > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > > > > [MDN05:CT07:EXCH] > > > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > > > > > > > Hi, > > > > > > > > I see a couple of issues here. > > > > > > > > 1. Even if the UAS returns Accept-Encoding: application/isup, > > > > it doesn't > > > > mean that it is going to send an encapsulated ACM. > > > > > > [PTT] > > > Agreed, and that is a nasty point. It's related to the next one. > > > > > > > > > > > 2. Even if it the UAS GW would send an encapsulated ACM, it > > > > is not sure > > > > that the UAC GW supports ISUP transparency in the first place. It may > > > > support only ISUP/SIP mapping, for example. > > > > > > [PTT] > > > That one is easily solved, in two ways. First, by hypothesis the UAC GW has > > > encapsulated the IAM in the initial INVITE. It can also include an > > > Accept-Content: header. In fact, this is essential so that the two ends can > > > negotiate stuff like ISUP version or the fact that one of them really wants > > > to propagate Q.931. > > > > > > So, given that the UAS GW has received an encapsulated IAM, the > > > Accept-Content: header indicates that it did or did not find the > > > encapsulated content acceptable. If it did find it acceptable, how do we > > > oblige it to keep up its end of the conversation? I expect the behaviour > > > has to be specified in the SIP-T umbrella document, and SIP/GSTN gateway > > > products have to indicate their conformity to that document. > > > > > > > > > > > I think that part of the problem, which is not related only to overlap > > > > dialling, is that a SIP/PSTN GW from a SIP point of view is an SIP UA, > > > > and from a SIP point of view should act like an SIP UA. Maybe > > > > it should > > > > be considered as a SIP node of its own, with GW specific functional > > > > requirements. The only thing we have now is how to map > > > > between ISUP and > > > > SIP, but that is obviously not enough. ??? > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > ------------------------------------------------------------------------ > > > Name: att1.htm > > > att1.htm Type: Hypertext Markup Language (text/html) > > > Encoding: base64 > > > Description: Internet HTML --------------0B05E45D4B6D3F9084FB204D 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 --------------0B05E45D4B6D3F9084FB204D-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 09:18:37 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14693 for ; Tue, 6 Feb 2001 09:18:36 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1E1DC4436C; Tue, 6 Feb 2001 09:20:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 353B444368 for ; Tue, 6 Feb 2001 09:19:21 -0500 (EST) 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 f166End12474 for ; Tue, 6 Feb 2001 07:14:49 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA10501; Tue, 6 Feb 2001 08:14:47 +0200 (EET) Message-ID: <3A7F9652.FF1B0DFE@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: <3A7E92A9.8C492AF0@lmf.ericsson.se> <3A7F2D74.CD84B9E4@lmf.ericsson.se> Content-Type: multipart/mixed; boundary="------------D575D2B08704FEA11787EFA8" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 08:14:42 +0200 This is a multi-part message in MIME format. --------------D575D2B08704FEA11787EFA8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Gonzalo, I didn't say I am going to use INFO, but that is what has been proposed earlier in this thread, so I assumed INFO would be used. The reason for the discussion from the beginning was that the overlap signalling, according to the SIP-ISUP mapping draft, may not work very well, and a solution using 18x responses and INFO messages, instead of 484 and re-INVITEs, was proposed. Regards, Christer Holmberg Ericsson Finland Gonzalo Camarillo wrote: > > Hello Christer, > > Why are you using INFO for sending extra digits? > > Please, check the SIP-ISUP mapping draft, overlap signalling section. > > Regards, > > Gonzalo > > Christer Holmberg wrote: > > > > Hi, > > > > The discussion about overlap dialing has been pretty much about calls > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > Consider the following scenario. > > > > PSTN PHONE GW SIP SERVER SIP UAS > > ----------------------------------------------------------- > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > | <- 18x ------ | > > --- 2 ---> -- SAM -> | -- INFO ----> | > > | <- 200 (INFO) | > > | <- 18x ------ | > > --- 3 ---> -- SAM -> | -- INFO ----> | > > | <- 200 (INFO) | -- INVITE > > --> > > | <- 200 (INVITE)| <- 200 ------ > > > > In this case, the SIP server (note that I am not using the word 'proxy') > > must collect digits, sent from the PSTN side using overlap dialing, to > > be able to find the SIP UAS, and INFO is used to provide the digits > > after the INVITE has been sent. > > > > My question is, should a SIP server (proxy, if you like) be allowed to > > behave like this, or MUST it send 486s, and receive new INVITEs, until > > it is able to find the UAS? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo --------------D575D2B08704FEA11787EFA8 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 --------------D575D2B08704FEA11787EFA8-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 09:23:22 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14853 for ; Tue, 6 Feb 2001 09:23:22 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 496E644380; Tue, 6 Feb 2001 09:21:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by lists.bell-labs.com (Postfix) with ESMTP id C4C6144356 for ; Tue, 6 Feb 2001 09:20:54 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 6 Feb 2001 13:33:09 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id NAA05596; Tue, 6 Feb 2001 13:33:06 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569EB.004A699C ; Tue, 6 Feb 2001 13:32:47 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Christer Holmberg Cc: Tom-PT Taylor , sip@lists.bell-labs.com, Joshua Moloney Message-ID: <802569EB.004A6692.00@marconicomms.com> Subject: Re: [SIP] Overlap call setup Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=NAmhJvOA25vjPbeHNX32IVTWKK8siUBwEByc7GK4RDWiYO68NDdFoHa6" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 13:32:49 +0000 --0__=NAmhJvOA25vjPbeHNX32IVTWKK8siUBwEByc7GK4RDWiYO68NDdFoHa6 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Certainly using explicit SIP responses minimises the need to use context to determine what ISUP message to generate. I am not opposed to the idea of using a new response to indicate that some form of routing is taking place at the egress (or beyond). Regards, K. Robinson Christer Holmberg on 05/02/2001 14:20:25 To: Keith Robinson/MAIN/MC1@MCMAIN cc: Tom-PT Taylor , sip@lists.bell-labs.com, Joshua Moloney Subject: Re: [SIP] Overlap call setup Hi, Keith Robinson wrote: > >Christer wrote ; > >>Again, we assume that the GWs support ISUP transparency, because if the >>GW only supports ISUP/SIP mapping it will not be able to know if to >>generate an ACM when the 18x is received - even if the GW would be smart >>enough to notice that there is SOME ISUP message in the 180 response. > >Surely, if a GW is mapping ISUP to SIP (and vice versa) then there must >be rules to dictate which SIP messages map to which ISUP messages and in >what context. In fact, aren't these the rules we are debating ? The point >being that even if a GW is ONLY performing SIP/ISUP/SIP mapping >then it STILL MUST know when to genrate the ACM as part of the mapping >function, REGARDLESS of transparency. Yes, and since it may not be possible to have rules when a 180 should generate a ACM, and when it should not. So, in the case of overlap dialing, when the 18x is only used to "ask" for more digits, my suggestion was to use a specific provisional response code that would not generate an ACM. Then, when we want an ACM to be generated, no matter if ISUP transparency is supported or not, we would send a 180 Alerting. Regards, Christer Holmberg Ericsson Finland > > Regards, > > K. Robinson. > > Christer Holmberg on 05/02/2001 11:10:49 > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > cc: Tom-PT Taylor , > sip@lists.bell-labs.com, Joshua Moloney > > > > > Subject: Re: [SIP] Overlap call setup > > > Hi, > > Again, we assume that the GWs support ISUP transparency, because if the > GW only supports ISUP/SIP mapping it will not be able to know if to > generate an ACM when the 18x is received - even if the GW would be smart > enough to notice that there is SOME ISUP message in the 180 response. > > Personally, I still think that a separate provisional response code > (I've been using 186 as an example) should be used, and any UAC (SIP > phone or PSTN GW) supporting overlap dialing must understand the > response. And, if the UAC knows it has already sent all digits, > receiving a 186 could, for example, cause it to send a CANCEL to the > INVITE, instead of waiting for the ISUP digit timers to expire and > receive a 486 final response. > > Regards, > > Christer Holmberg > Ericsson Finland > > Keith Robinson wrote: > > > > In the absence of receiving an encapsulated ACM, the ingress > > gateway could generate its own ACM when it receives a 180 Alerting; this > > response must mean it is safe to assume call routing is complete > > and caters for terminations within a SIP network. Thought needs to be > > given to scenarios where a non-200 final response is received, say 486 > > Busy, as in these cases 180 Alerting, probably, wouldn't be generated. > > > > Regards, > > > > Keith. > > > > "Tom-PT Taylor" on 02/02/2001 14:12:39 > > > > > > > > > > > > > > > > To: Christer Holmberg > > > > > > cc: Keith Robinson/MAIN/MC1@MCMAIN, > > sip@lists.bell-labs.com, "Joshua Moloney" > > > > > > > > > > Subject: RE: [SIP] Overlap call setup > > > > > > Replies below. > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Friday, February 02, 2001 1:17 AM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > > > [MDN05:CT07:EXCH] > > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > > > Hi, > > > > > > I see a couple of issues here. > > > > > > 1. Even if the UAS returns Accept-Encoding: application/isup, > > > it doesn't > > > mean that it is going to send an encapsulated ACM. > > > > [PTT] > > Agreed, and that is a nasty point. It's related to the next one. > > > > > > > > 2. Even if it the UAS GW would send an encapsulated ACM, it > > > is not sure > > > that the UAC GW supports ISUP transparency in the first place. It may > > > support only ISUP/SIP mapping, for example. > > > > [PTT] > > That one is easily solved, in two ways. First, by hypothesis the UAC GW has > > encapsulated the IAM in the initial INVITE. It can also include an > > Accept-Content: header. In fact, this is essential so that the two ends can > > negotiate stuff like ISUP version or the fact that one of them really wants > > to propagate Q.931. > > > > So, given that the UAS GW has received an encapsulated IAM, the > > Accept-Content: header indicates that it did or did not find the > > encapsulated content acceptable. If it did find it acceptable, how do we > > oblige it to keep up its end of the conversation? I expect the behaviour > > has to be specified in the SIP-T umbrella document, and SIP/GSTN gateway > > products have to indicate their conformity to that document. > > > > > > > > I think that part of the problem, which is not related only to overlap > > > dialling, is that a SIP/PSTN GW from a SIP point of view is an SIP UA, > > > and from a SIP point of view should act like an SIP UA. Maybe > > > it should > > > be considered as a SIP node of its own, with GW specific functional > > > requirements. The only thing we have now is how to map > > > between ISUP and > > > SIP, but that is obviously not enough. ??? > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > ------------------------------------------------------------------------ > > Name: att1.htm > > att1.htm Type: Hypertext Markup Language (text/html) > > Encoding: base64 > > Description: Internet HTML --0__=NAmhJvOA25vjPbeHNX32IVTWKK8siUBwEByc7GK4RDWiYO68NDdFoHa6 Content-type: application/octet-stream; name="christer.holmberg.vcf" Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOkhvbG1iZXJnO0NocmlzdGVyDQp0ZWw7Y2VsbDorMzU4LTQwLTU2MDQ0 MTINCnRlbDt3b3JrOiszNTgtOS0yOTkyOTQzDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnOkVy aWNzc29uO0lQIE11bHRpbWVkaWEgLyBBZHZhbmNlZCBTaWduYWxsaW5nIFJlc2VhcmNoIExhYm9y YXRvcnkNCmFkcjo7Ozs7OzsNCnZlcnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpjaHJpc3Rlci5o b2xtYmVyZ0BsbWYuZXJpY3Nzb24uc2UNCnRpdGxlOlN5c3RlbSBEZXNpZ25lcg0KZm46Q2hyaXN0 ZXIgSG9sbWJlcmcNCmVuZDp2Y2FyZA0KDQo= --0__=NAmhJvOA25vjPbeHNX32IVTWKK8siUBwEByc7GK4RDWiYO68NDdFoHa6-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 09:29:47 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15108 for ; Tue, 6 Feb 2001 09:29:46 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 300AC44390; Tue, 6 Feb 2001 09:21:19 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id 0CC6544356 for ; Tue, 6 Feb 2001 09:21:01 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qhars002.nortel.com; Tue, 6 Feb 2001 14:16:08 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Feb 2001 14:15:13 -0000 Message-ID: From: "Michael O'Doherty" To: "'Ashutosh Dutta'" , "Michael O'Doherty" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP in small adhoc and Pico networks MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09047.335D3C80" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 14:15:04 -0000 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_01C09047.335D3C80 Content-Type: text/plain; charset="iso-8859-1" Ashutosh, I may have misunderstood the question, but I think there are a couple of concepts involved here. To allow all SIP clients in a particular broadcast domain know about each other, the 'Hello' message approach (or register message acting as a 'Hello' type of message) is probably the simplest and lowest message overhead. If there is a desire to allow devices within a broadcast domain know about multicast sessions available in the domain then SAP/SDP could be used, although it would probably be worth investigating how multicast applies to adhoc networks - this discussion is probably not appropriate for the SIP list. Cheers, Mick. -----Original Message----- From: Ashutosh Dutta [mailto:adutta@telcordia.com] Sent: 02 February 2001 19:19 To: O'Doherty, Michael [MDN05:MD01:EXCH] Cc: sip@lists.bell-labs.com Subject: Re: [SIP] SIP in small adhoc and Pico networks Michael, would you assume each Piconet member in the same subnet (broadcast domain), can we define a well defined multicast address to get the listing of the users with SIP UA enabled in the neighborhood, and their contact address, may be by using something like SAP/SDP. Thanks Ashutosh _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. ------_=_NextPart_001_01C09047.335D3C80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] SIP in small adhoc and Pico networks

Ashutosh,

I may have misunderstood the question, but I think = there are a couple of concepts involved here.

To allow all SIP clients in a particular broadcast = domain know about each other, the 'Hello' message approach (or register = message acting as a 'Hello' type of message) is probably the simplest = and lowest message overhead.

If there is a desire to allow devices within a = broadcast domain know about multicast sessions available in the domain = then SAP/SDP could be used, although it would probably be worth = investigating how multicast applies to adhoc networks - this discussion = is probably not appropriate for the SIP list.

Cheers,

Mick.



-----Original Message-----
From: Ashutosh Dutta [mailto:adutta@telcordia.com]
Sent: 02 February 2001 19:19
To: O'Doherty, Michael [MDN05:MD01:EXCH]
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP in small adhoc and Pico = networks




Michael, would you assume each Piconet member in the = same subnet (broadcast
domain), can we define a well defined multicast = address to get the listing of
the users with SIP UA enabled in the neighborhood, = and their contact address,
may be by using something  like SAP/SDP.

Thanks
Ashutosh



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

------_=_NextPart_001_01C09047.335D3C80-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 09:38:03 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15526 for ; Tue, 6 Feb 2001 09:38:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D992E4439C; Tue, 6 Feb 2001 09:23:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id F027A4439B for ; Tue, 6 Feb 2001 09:22:28 -0500 (EST) 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 f167pfC10047; Tue, 6 Feb 2001 08:51:42 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA18196; Tue, 6 Feb 2001 09:51:40 +0200 (EET) Message-ID: <3A7FAD06.F4877037@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Keith Robinson , Tom-PT Taylor , Joshua Moloney Subject: Re: [SIP] Overlap call setup References: <802569EA.004DAB73.00@marconicomms.com> <3A7EB6A9.9C22F2BF@lmf.ericsson.se> Content-Type: multipart/mixed; boundary="------------54998BB78C6C9529D79BB881" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 09:51:34 +0200 This is a multi-part message in MIME format. --------------54998BB78C6C9529D79BB881 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I had a look through the thread, and I still have one issue. I do NOT think that we can assume that the PSTN GW will know how many digits are needed to route a call to the PSTN end-user, so I don't think we can use provisional responses to "ask" for more digits. Yes, the GW may know how many digits it needs to route the call to the next PSTN switch, but it doesn't know how many digits that switch needes, etc... So, my proposal would be: 1. When the INVITE has been routed to the GW UAS, the only response sent back is 100. That would, of course, assume that we have to add Contact and/or Record-Route headers in the 100 response... 2. Then, the UAC would use INFO to send more digits to the UAC, which would forward them as SAMs. No, the GW would not "ask" for more digits, but does it really have to? If the UAC wants to send more digits, it can do so anyway, so... 3. THEN, when the GW receives ACM from the PSTN side, it would send a 18x provisional response back to the UAC. The UAC would now know that no more digits are needed to route the call. Of course, we can get a "please enter your code"-message, and be asked to provide digits, but that is another issue. We should remember that the GW SIP UAS may not even know that the UAC is sending more digits, because it may send them in encapsulated ISUP messages. In that case, however, the GW SIP UAS will not know it's SAMs, so it couldn't make a decission on if to send 186 "Gimme more digits" or not... Regards, Christer Holmberg Ericsson Finland Christer Holmberg wrote: > > Hi, > > Keith Robinson wrote: > > > >Christer wrote ; > > > >>Again, we assume that the GWs support ISUP transparency, because if the > >>GW only supports ISUP/SIP mapping it will not be able to know if to > >>generate an ACM when the 18x is received - even if the GW would be smart > >>enough to notice that there is SOME ISUP message in the 180 response. > > > >Surely, if a GW is mapping ISUP to SIP (and vice versa) then there must >be rules to dictate which SIP messages map to which ISUP messages and in >what context. In fact, aren't these the rules we are debating ? The point >being that even if a GW is ONLY performing SIP/ISUP/SIP mapping > >then it STILL MUST know when to genrate the ACM as part of the mapping >function, REGARDLESS of transparency. > > Yes, and since it may not be possible to have rules when a 180 should > generate a ACM, and when it should not. So, in the case of overlap > dialing, when the 18x is only used to "ask" for more digits, my > suggestion was to use a specific provisional response code that would > not generate an ACM. > > Then, when we want an ACM to be generated, no matter if ISUP > transparency is supported or not, we would send a 180 Alerting. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Regards, > > > > K. Robinson. > > > > Christer Holmberg on 05/02/2001 11:10:49 > > > > > > > > > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > > > cc: Tom-PT Taylor , > > sip@lists.bell-labs.com, Joshua Moloney > > > > > > > > > > Subject: Re: [SIP] Overlap call setup > > > > > > Hi, > > > > Again, we assume that the GWs support ISUP transparency, because if the > > GW only supports ISUP/SIP mapping it will not be able to know if to > > generate an ACM when the 18x is received - even if the GW would be smart > > enough to notice that there is SOME ISUP message in the 180 response. > > > > Personally, I still think that a separate provisional response code > > (I've been using 186 as an example) should be used, and any UAC (SIP > > phone or PSTN GW) supporting overlap dialing must understand the > > response. And, if the UAC knows it has already sent all digits, > > receiving a 186 could, for example, cause it to send a CANCEL to the > > INVITE, instead of waiting for the ISUP digit timers to expire and > > receive a 486 final response. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Keith Robinson wrote: > > > > > > In the absence of receiving an encapsulated ACM, the ingress > > > gateway could generate its own ACM when it receives a 180 Alerting; this > > > response must mean it is safe to assume call routing is complete > > > and caters for terminations within a SIP network. Thought needs to be > > > given to scenarios where a non-200 final response is received, say 486 > > > Busy, as in these cases 180 Alerting, probably, wouldn't be generated. > > > > > > Regards, > > > > > > Keith. > > > > > > "Tom-PT Taylor" on 02/02/2001 14:12:39 > > > > > > > > > > > > > > > > > > > > > > > > To: Christer Holmberg > > > > > > > > > cc: Keith Robinson/MAIN/MC1@MCMAIN, > > > sip@lists.bell-labs.com, "Joshua Moloney" > > > > > > > > > > > > > > > Subject: RE: [SIP] Overlap call setup > > > > > > > > > Replies below. > > > > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > Sent: Friday, February 02, 2001 1:17 AM > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > > > > [MDN05:CT07:EXCH] > > > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > > > > > > > Hi, > > > > > > > > I see a couple of issues here. > > > > > > > > 1. Even if the UAS returns Accept-Encoding: application/isup, > > > > it doesn't > > > > mean that it is going to send an encapsulated ACM. > > > > > > [PTT] > > > Agreed, and that is a nasty point. It's related to the next one. > > > > > > > > > > > 2. Even if it the UAS GW would send an encapsulated ACM, it > > > > is not sure > > > > that the UAC GW supports ISUP transparency in the first place. It may > > > > support only ISUP/SIP mapping, for example. > > > > > > [PTT] > > > That one is easily solved, in two ways. First, by hypothesis the UAC GW has > > > encapsulated the IAM in the initial INVITE. It can also include an > > > Accept-Content: header. In fact, this is essential so that the two ends can > > > negotiate stuff like ISUP version or the fact that one of them really wants > > > to propagate Q.931. > > > > > > So, given that the UAS GW has received an encapsulated IAM, the > > > Accept-Content: header indicates that it did or did not find the > > > encapsulated content acceptable. If it did find it acceptable, how do we > > > oblige it to keep up its end of the conversation? I expect the behaviour > > > has to be specified in the SIP-T umbrella document, and SIP/GSTN gateway > > > products have to indicate their conformity to that document. > > > > > > > > > > > I think that part of the problem, which is not related only to overlap > > > > dialling, is that a SIP/PSTN GW from a SIP point of view is an SIP UA, > > > > and from a SIP point of view should act like an SIP UA. Maybe > > > > it should > > > > be considered as a SIP node of its own, with GW specific functional > > > > requirements. The only thing we have now is how to map > > > > between ISUP and > > > > SIP, but that is obviously not enough. ??? > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > ------------------------------------------------------------------------ > > > Name: att1.htm > > > att1.htm Type: Hypertext Markup Language (text/html) > > > Encoding: base64 > > > Description: Internet HTML --------------54998BB78C6C9529D79BB881 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 --------------54998BB78C6C9529D79BB881-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 09:42:48 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15744 for ; Tue, 6 Feb 2001 09:42:48 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E6DA8443BC; Tue, 6 Feb 2001 09:31:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by lists.bell-labs.com (Postfix) with ESMTP id 8D7B4443BB for ; Tue, 6 Feb 2001 09:30:49 -0500 (EST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id SAA14852 for ; Tue, 6 Feb 2001 18:52:33 +0900 (JST) (envelope-from ohba.takumi@lab.ntt.co.jp) Received: from imi.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/05/00) with ESMTP id SAA14703 for ; Tue, 6 Feb 2001 18:52:33 +0900 (JST) (envelope-from ohba.takumi@lab.ntt.co.jp) Received: from [129.60.10.47] ([129.60.10.47]) by imi.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id SAA22102 for ; Tue, 6 Feb 2001 18:52:32 +0900 (JST) Message-Id: <200102060952.SAA22102@imi.m.ecl.ntt.co.jp> X-Sender: to006@imi.m.ecl.ntt.co.jp X-Mailer: Macintosh Eudora Pro Version 3.1.1-Jr2 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F304759F@DYN-TX-EXCH-001.dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: sip@lists.bell-labs.com From: Takumi Ohba Subject: [SIP] over-length message Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 18:50:45 +0900 Dear all, This is Takumi Ohba, NTT. I have some questions concerning handling of over-length messages. One example; If a user want to attach very large data to a SIP message as a MIME part, but it make the message longer than the MTU, what should the user do? The only choice to the user is to give up attaching the data? Another example; A SIP proxy may receive a larger message that it can transfer. This may happen when the proxy uses different transport layers for incoming and outgoing links and the outgoing link has smaller maximum datagram packet size than that for the incoming link. For example, the incoming link uses UDP (max: 64k octets) and the outgoing link uses signalling AAL (max: 4k octets). The proxy may receive 5k-octet message if the MTU permits it, but it cannot transfer the message to the outgoing signalling AAL link. In this case, what should the proxy do? Should it give up transferring the massage itself, or shorten the message and transfer it by discarding less important part of the message? In the latter case, how can the proxy identify less important part of the message? Best regards, Takumi Ohba *************************************************** Takumi OHBA NTT Network Service Systems Laboratories tel +81 422 59 4405 fax +81 422 59 3494 e-mail ohba.takumi@lab.ntt.co.jp *************************************************** _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 09:46:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15899 for ; Tue, 6 Feb 2001 09:46:22 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D583C443C2; Tue, 6 Feb 2001 09:34:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 5163A443C1 for ; Tue, 6 Feb 2001 09:33:04 -0500 (EST) 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 f15MkSC16665 for ; Mon, 5 Feb 2001 23:46:28 +0100 (MET) Received: from lmf.ericsson.se ([142.133.141.104]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA02631; Mon, 5 Feb 2001 23:46:22 +0100 (MET) Message-ID: <3A7F2D74.CD84B9E4@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: <3A7E92A9.8C492AF0@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 00:47:16 +0200 Content-Transfer-Encoding: 7bit Hello Christer, Why are you using INFO for sending extra digits? Please, check the SIP-ISUP mapping draft, overlap signalling section. Regards, Gonzalo Christer Holmberg wrote: > > Hi, > > The discussion about overlap dialing has been pretty much about calls > from SIP to PSTN, or PSTN-SIP-PSTN. > > Consider the following scenario. > > PSTN PHONE GW SIP SERVER SIP UAS > ----------------------------------------------------------- > > --- 1 ---> -- IAM -> | -- INVITE --> | > | <- 18x ------ | > --- 2 ---> -- SAM -> | -- INFO ----> | > | <- 200 (INFO) | > | <- 18x ------ | > --- 3 ---> -- SAM -> | -- INFO ----> | > | <- 200 (INFO) | -- INVITE > --> > | <- 200 (INVITE)| <- 200 ------ > > In this case, the SIP server (note that I am not using the word 'proxy') > must collect digits, sent from the PSTN side using overlap dialing, to > be able to find the SIP UAS, and INFO is used to provide the digits > after the INVITE has been sent. > > My question is, should a SIP server (proxy, if you like) be allowed to > behave like this, or MUST it send 486s, and receive new INVITEs, until > it is able to find the UAS? > > Regards, > > Christer Holmberg > Ericsson Finland -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 10:14:56 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17386 for ; Tue, 6 Feb 2001 10:14:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BCB71443D3; Tue, 6 Feb 2001 10:08:07 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 9E2BD4433B for ; Tue, 6 Feb 2001 10:07:34 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Feb 6 10:04:56 EST 2001 Received: by lists.bell-labs.com (Postfix) id BD02B44380; Tue, 6 Feb 2001 09:53:19 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (unknown [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id 32F8E4437D for ; Tue, 6 Feb 2001 09:53:19 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Feb 2001 13:04:27 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00BD0D8@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'William Marshall'" , "'Rosen, Brian'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 13:04:25 -0000 See below. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Rosen, Brian[SMTP:Brian.Rosen@marconi.com] > Sent: 05 February 2001 17:01 > To: 'William Marshall' > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] Re: Location information > > The problem that location presents that is different from the > privacy draft (unless I missed it) is that an emergency call must > yield location information. There is not an option for the user > to suppress this, by law. > While the current privacy draft identifies that a user requesting "full" privacy will receive this, I do not believe it is true. The current PSTN, ISDN and mobile network service definitions all provide for some special users (normally law enforcement agencies or emergency attendants) who have access to this information no matter what the anonymity aka restriction parameters indicate. I think the privacy draft needs to identify that certain categories of user will exist that override the anonymity setting, and that this is a "national option" of whatever the IETF equivalent of such terminology is. > The path by which a user might connect > to an emergency center cannot be pre-arranged. I believe that it > will take creation of a cryptographically secure infrastructure > to allow such a system to have the desired property that the user > can control location information, but when required it can be > securely delivered. > > I also think that location is not an "all or nothing" kind of > thing. The privacy draft presupposes that the world is bifurcated > into trusted and untrusted domains, and privacy is secured > when venturing into an untrusted domain. This is not the behavior > I really want. The desired behavior I want is: > Accuracy (precision) of location is variable > I may want to give some people precise information, others > less precise. There will be multiple levels > Time (and motion) variability - if I am mobile, then where I > am changes over time. I need to express this somehow, > but I also need to control it (not everyone can be told that > I am mobile) > This will vary between different services. For emergency calls, the current location at the time at which the INVITE was sent is probably sufficient. Location information in other protocols does include both accuracy and velocity indicators, if such are required. Other services may require a more continuous update of location - at some point this ceases to become something that the SIP protocol should provide and becomes something that should be in a separate media stream. Any views on where this breakpoint is reached? > What we learned in the spatial effort is that the whole location thing > is more complex that you would like it to be, and it is hard to get > an implementable subset that has enough functionality to be interesting. > We could end up here building something that does everything, but is over complex. I would note that we have two potential mechanisms to cater for this: i) the same location could be repeated in a request, each intended for different service capabilities and with different levels of accuracy. One of the proposals is to repeat the Remote-Party-ID header. Thus a highly accurate location could be propagated with the request for emergency calls, and a somewhat more general location could be propagated to a server providing location based services. ii) the final proxy before a untrusted hop is reached could reduce the accuracy of location information. I am not sure how we would go about specifying this behaviour generically for all identifiers. It could be done for certain identifiers in an application specific manner. > We also learned the difficulties in reaching consensus on issues that > involve privacy. > > Brian > > > > > > -----Original Message----- > > From: William Marshall [mailto:wtm@research.att.com] > > Sent: Monday, February 05, 2001 11:40 AM > > To: brian.rosen@marconi.com > > Cc: sip@lists.bell-labs.com > > Subject: [SIP] Re: Location information > > > > > > Brian, > > > > It seems that the privacy draft faces up squarely to the privacy > > concerns. The draft already deals with all the regulatory > > requirements > > about verification of identity, hiding of identity, etc. The security > > implications of knowing who you are are just as daunting as knowing > > where you are. In some places regulations already cover > > location info, > > and the framework in the privacy draft deals with them. > > > > As with the subscriber identity - the UA may insert it, and may > > demand (via a tag and a Proxy-Require) that it be kept private. > > The proxies may verify the identity, and mark it verified, or mark > > it unverified, and must delete the information if privacy was > > requested. > > The procedures are all there in the privacy draft, and just need > > some minor extensions to handle multiple identity types, and > > per-identity > > privacy requests. > > > > The previous efforts (spatial) generated a string giving location > > information. Sip uses "name-addr | addr-spec" everywhere, which > > includes a display-name string; however a URL format would be nicer. > > I was sure I had heard about a URL format with this information, but > > can't find any reference to it. > > > > Bill Marshall > > wtm@research.att.com > > > > -----original message----- > > From: "Rosen, Brian" > > Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft) > > Date: Mon, 5 Feb 2001 10:44:54 -0500 > > > > There was an effort started several IETFs ago to define a PROTOCOL > > to exchange geographic location. That was shot down. There is still > > a low level effort to define a format for exchanging such information. > > > > Before starting another effort, you might want to look at the prior > > work (spatial). You also MUST forthrightly face up to the privacy > > concerns that have stymied other efforts. The security > > implications of > > knowing where you are can be VERY daunting, and in general discussions > > on the issues have yielded more problems than answers.' > > > > Brian > > > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 10:22:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17691 for ; Tue, 6 Feb 2001 10:22:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C0174433C; Tue, 6 Feb 2001 09:51:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id AF07E44338 for ; Tue, 6 Feb 2001 09:50:46 -0500 (EST) 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 f16Eojd00628; Tue, 6 Feb 2001 15:50:45 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA23431; Tue, 6 Feb 2001 16:50:43 +0200 (EET) Message-ID: <3A800F42.6D1A99A7@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Takumi Ohba Cc: sip@lists.bell-labs.com Subject: Re: [SIP] over-length message References: <200102060952.SAA22102@imi.m.ecl.ntt.co.jp> Content-Type: multipart/mixed; boundary="------------318C993C3AF5962F8F9E3F11" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 16:50:42 +0200 This is a multi-part message in MIME format. --------------318C993C3AF5962F8F9E3F11 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I think it has been agreed that a SIP message, including possible MIME message bodies, should "fit" into a single UDP MTU. Do you have an example where that length would not be enough? Regards, Christer Holmberg Ericsson Finland Takumi Ohba wrote: > > Dear all, > > This is Takumi Ohba, NTT. > I have some questions concerning handling of over-length messages. > > One example; > If a user want to attach very large data to a SIP message as a MIME part, > but it make the message longer than the MTU, what should the user do? > The only choice to the user is to give up attaching the data? > > Another example; > A SIP proxy may receive a larger message that it can transfer. This may > happen when the proxy uses different transport layers for incoming and > outgoing links and the outgoing link has smaller maximum datagram packet > size than that for the incoming link. > For example, the incoming link uses UDP (max: 64k octets) and the outgoing > link uses signalling AAL (max: 4k octets). The proxy may receive 5k-octet > message if the MTU permits it, but it cannot transfer the message to the > outgoing signalling AAL link. > > In this case, what should the proxy do? > Should it give up transferring the massage itself, or shorten the message > and transfer it by discarding less important part of the message? In the > latter case, how can the proxy identify less important part of the message? > > Best regards, > Takumi Ohba > > *************************************************** > Takumi OHBA > NTT Network Service Systems Laboratories > tel +81 422 59 4405 fax +81 422 59 3494 > e-mail ohba.takumi@lab.ntt.co.jp > *************************************************** > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. --------------318C993C3AF5962F8F9E3F11 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 --------------318C993C3AF5962F8F9E3F11-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 10:24:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17771 for ; Tue, 6 Feb 2001 10:24:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E6BB1443DA; Tue, 6 Feb 2001 10:09:06 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id 5D28E4437D for ; Tue, 6 Feb 2001 10:08:01 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Tue Feb 6 10:06:35 EST 2001 Received: by lists.bell-labs.com (Postfix) id DFCD044384; Tue, 6 Feb 2001 09:53:25 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (unknown [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id 797F44437D for ; Tue, 6 Feb 2001 09:53:25 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Feb 2001 11:25:26 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00BD0D5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@lists.bell-labs.com'" , "'Mark Watson'" Subject: RE: [SIP] SIP Privacy Draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 11:25:22 -0000 In addition to the current discussion on location, I wanted to add some words on the following part of Marks comment. I do believe within any individual session, and for any endpoint, there are multiple identities that need to be exchanged. We either have the option of specifying these in the RFC, or allowing to be added as IANA registered enhancements, or a combination of both. Before we decide this, we possibly need to get some idea of the number of different identities people may want. I think this involves adding definitions to the terms that Mark has identified. We should also note that we already have a number of identities already existing in the draft, depending on the endpoint we are talking about. For the calling endpoint we have the From header and the Contact header. These may fulfil some of the functions of i) and ii) in Mark's list. I would like to propose two definitions which I believe should be covered by an extended privacy draft (note that these are currently phrased from the viewpoint of the calling endpoint, and would need to be modified to cover other endpoints: Logical Calling Subscriber ID A URL that identifies the owner of the telecommunications subscription of the user originating the session. Logical Calling User ID A URL that identifies the calling user, and that shall at least be suitable for making a return session establishment. It is the second of these that I would expect to be used in a Calling Line Identification Presentation Service. The first would need to accompany any emergency call, or be used for any malicious call identification. Keith Drage Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Mark Watson[SMTP:mwatson@nortelnetworks.com] > Sent: 01 February 2001 15:49 > To: 'sip@lists.bell-labs.com' > Subject: [SIP] SIP Privacy Draft > > All, > > I sent some comments on this draft to the list in December. Below is an > update to these comments based on some off-line discussions. (The draft > itself is at > http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-00.txt) > > Five enhancements to the draft are proposed: > > 3) Types of identity > > A party involved in a session may have several kinds of identity. Support > should be provided for signalling any/all of them: > > i) Subscriber identity - who owns the network subscription under which the > session is being established > ii) User identity - a human being > iii) Display/Alias identity - the identity that the party wishes to be > known as > iv) Return identity - the identity to be used to contact the party (e.g. > to establish a return call/session) > v) Terminal identity > > In many practical scenarios one or all of these identities are in fact the > same and the same as the User identity, and so all do not need to be > signalled separately. In any given application scenario it should be > specified what these identities refer to. > ,cut> > Regards, > > Mark Watson > Nortel Networks > mwatson@nortelnetworks.com > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 10:24:55 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17815 for ; Tue, 6 Feb 2001 10:24:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DAF21443CD; Tue, 6 Feb 2001 10:22:17 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 4C256443BB for ; Tue, 6 Feb 2001 10:21:38 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Feb 6 10:18:06 EST 2001 Received: by lists.bell-labs.com (Postfix) id 1F0C944385; Tue, 6 Feb 2001 09:53:27 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (unknown [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id A5BF544386 for ; Tue, 6 Feb 2001 09:53:26 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Feb 2001 13:14:57 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00BD0D9@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] More on privacy Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 13:14:56 -0000 To add a further issue to the current discussions on privacy. The current specification of trusted versus untrusted really only deals with the presentation of information to untrusted entities. In the ISDN/PSTN world there is also the concept of information being provided by an untrusted source, for example an separate enterprise network, or a user attached to that separate enterprise network. In some cases the untrusted source may be the only entity able to provide truly accurate information. Therefore for Calling Line Identification Presentation there is a special indicator of user provided unscreened. This means that in ISDN we have an either or situation for CLIP, the user is either told: - this is the number for dialback purposes, but you cannot trust the reliability of this information because I cannot check it. or - this is the number for dialback purposes, but I have only provided you with the information I can check, therefore it may not get you back to the real source of the call, but only to the enterprise network that sourced it. In SIP we could have the possibility of providing both, but we would need to discuss how we would identify these identifiers. For example two different identifier tags in the Remote-Party_ID header, or a common identifier tag, but a separate indication of level of screening. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 10:25:00 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17834 for ; Tue, 6 Feb 2001 10:25:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E3B84439B; Tue, 6 Feb 2001 10:18:17 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by lists.bell-labs.com (Postfix) with ESMTP id 8384C443CB; Tue, 6 Feb 2001 09:52:18 -0500 (EST) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id JAA10390; Tue, 6 Feb 2001 09:44:13 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852569EB.0050F146 ; Tue, 6 Feb 2001 09:44:06 -0500 X-Lotus-FromDomain: TELCORDIA From: "Petros N. Mouchtaris" To: sip@lists.bell-labs.com, megaco@standards.nortelnetworks.com, iptel@lists.bell-labs.com Message-ID: <852569EB.0050F0B6.00@notes949.cc.telcordia.com> Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=xebx9GWlI1k5mGE2gkF0k8W61p2gSMPnUlZZhBGWHn0fGt8SbuDMx0j5" Content-Disposition: inline Subject: [SIP] VoIP conference Call for Papers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 09:43:24 -0500 --0__=xebx9GWlI1k5mGE2gkF0k8W61p2gSMPnUlZZhBGWHn0fGt8SbuDMx0j5 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Attached is a call for papers for a VoIP conference. Abstracts are due on February 19. You can check www.spie.org/info/itcom for more details or send me an e-mail if you have any questions. Petros Call for Papers for the Voice over IP (VoIP) Technology Conference Denver, 20-23 August 2001 Part of SPIE's ITComm 2001 - International Symposium and Exhibit on the Convergence of Information Technology and Communication Technologies, 20-24 August 2001, Denver, Colorado. Conference Chair: Petros Mouchtaris, Telcordia Technologies Program Committee: Flemming Andreasen, Cisco Dimitris Kabilafkas, OTE R&D Fuchun (Joe) Lin, Telcordia Technologies Dave McDysan, WorldCom Seshadri Mohan, Comverse Petros Mouchtaris (Chair), Telcordia Technologies Rajesh Talpade, Telcordia Technologies The convergence of information and communication technologies has allowed the use of data networks for offering voice and multimedia services. When Voice over IP (VoIP) was first introduced commercially in the mid-nineties it was marketed as an inexpensive alternative to traditional telephone service. Quality of Service was not a critical issue because users were willing to tolerate low quality because of the low cost of the service. Today, large carriers with a long tradition in offering high quality services are considering deployment of VoIP. Also, VoIP has lost its low cost appeal because prices of traditional telephone services have dropped dramatically. Long term success of VoIP will depend on whether VoIP networks can provide high quality and can be used for offering a wide array of exciting services that cannot be offered by traditional telephone networks. The goal of this conference is to bring together researchers, engineers and users of VoIP technologies, with a focus on how carriers can offer exciting VoIP services that provide high quality of service to users. This conference is part of the ITComm Symposium and Exhibit, which focuses on the convergence of information and communication technologies. The symposium will take place in the beautiful Denver/Boulder area, a fast-moving high technology corridor also called "Silicon Mountain." Authors are invited to submit abstracts in the following and related topics: --0__=xebx9GWlI1k5mGE2gkF0k8W61p2gSMPnUlZZhBGWHn0fGt8SbuDMx0j5 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =B7 VoIP Architectures =B7 Quality of Service =B7 Reliability, Resiliency, and Fault Tolerance =B7 VoIP Services and service APIs =B7 VoIP mobility and integration with wireless networks =B7 Interworking of VoIP with PSTN including Intelligent Networks =B7 Signaling protocols for VoIP =B7 Addressing and numbering approaches for VoIP =B7 VoIP over access technologies (e.g. xDSL, cable) =B7 Deployment experiences and lessons learned Submitted abstracts should be of approximately 250 words. There will b= e a proceedings, published by SPIE, distributed at the conference. Accepte= d papers will be allocated up to 15 pages in the proceedings. = --0__=xebx9GWlI1k5mGE2gkF0k8W61p2gSMPnUlZZhBGWHn0fGt8SbuDMx0j5-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 10:25:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17854 for ; Tue, 6 Feb 2001 10:25:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 33D87443AF; Tue, 6 Feb 2001 10:18:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 654404434D for ; Tue, 6 Feb 2001 09:24:32 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12808; Tue, 6 Feb 2001 08:16:44 -0500 (EST) Message-Id: <200102061316.IAA12808@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-ietf-sip-cc-transfer-03.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 08:16:43 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Call Control Author(s) : R. Sparks Filename : draft-ietf-sip-cc-transfer-03.txt Pages : 19 Date : 05-Feb-01 This document defines a SIP extension within the new Call Control Framework to provide Call Transfer capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-cc-transfer-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-cc-transfer-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-cc-transfer-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010205132001.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-cc-transfer-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-cc-transfer-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010205132001.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 10:30:16 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18106 for ; Tue, 6 Feb 2001 10:30:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BF0F244396; Tue, 6 Feb 2001 10:22:08 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id CCAE8443B3 for ; Tue, 6 Feb 2001 10:21:37 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Feb 6 10:18:06 EST 2001 Received: by lists.bell-labs.com (Postfix) id 8BA0E4437D; Tue, 6 Feb 2001 09:53:26 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (unknown [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id 061CD44385 for ; Tue, 6 Feb 2001 09:53:25 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Feb 2001 11:53:22 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00BD0D6@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Drage, Keith (Keith)" , "'Jiri Kuthan'" , Mark Watson , "'Rosen, Brian'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 11:53:21 -0000 See below. Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Rosen, Brian[SMTP:Brian.Rosen@marconi.com] > Sent: 05 February 2001 18:28 > To: 'Drage, Keith (Keith)'; 'Jiri Kuthan'; Mark Watson > Cc: 'sip@lists.bell-labs.com' > Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft) > > The cited proposal uses WGS84, which is the accepted standard for > world coordinates. I know that there is some variability in the precise > ellipsoid definitions that have some national variation. I'm not enough > of an expert to know which version this represents, but it appears to > offer > no variation, so they probably picked one and went on; a position I favor. > This is certainly based on WGS84, as the intention when it was defined was not to invent something new. I am not sure how well it now corresponds because I have only ever worked from this document (as have ETSI, 3GPP and ITU-T), and not from WGS84. > It also seems to have all of the variables one might want (including > motion > vectors). So, I would agree that we want to have something very closely > aligned with this format in terms of parameters. > > I didn't see anything having to do with intentional degrading of > accuracy, so that is one missing capability. The document developed over time. For reasons of compatibility new descriptions were added rather than modify old descriptions. The later additions were principally "uncertainty" and "confidence" so you will find some descriptions that include them and some that do not. I believe these are the terms you are looking for. By the way we do not need to cater for all descriptions in this document. Rather it should be a shopping list where the selection of descriptions: a) fulfils the requirements of the SIP community b) can be mapped to those used by ISUP, MAP, INAP and CAMEL (and any other protocols that people can identify as important but which I do not know about). > Brian > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Monday, February 05, 2001 1:08 PM > > To: 'Jiri Kuthan'; Mark Watson; 'Rosen, Brian' > > Cc: 'sip@lists.bell-labs.com' > > Subject: RE: Location information (was Re: [SIP] SIP Privacy Draft) > > > > > > There is however a requirement in existing protocols for passing this > > information around within network entities. Therefore you > > will see support > > in ISUP, MAP, INAP and CAMEL for such an identifier. I > > believe that there is > > requirement to be able to carry this identifier within SIP, > > although not in > > "clear" to the user entities. Work done in ITU-T and in ETSI, > > both in the > > services area and in the ISUP area, defined this identifier > > as another form > > of calling line identity. > > > > The usage in these protocols is all based on the same set of > > underlying > > variants, of which the best definition in protocol > > independent terms is > > probably in the following 3GPP reference > > > > TS 23.032. > > > > 3rd Generation Partnership Project; > > Technical Specification Group Core Network; > > Universal Geographical Area Description (GAD) > > > > and which may be found at the following URL > > > > ftp://ftp.3gpp.org/Specs/2000-12/R1999/23_series/23032-310.zip > > > > Due to the need to interwork between SIP and other protocols, it would > > appear to be essential to maintain the same number and type > > of parameters > > within the SIP encoding, although some difference will > > obviously have to > > exist at the transfer level to allow a text encoding in SIP, > > while the other > > protocols use a binary encoding. > > > > This is not a matter of telling the IETF what to do, it is > > merely that every > > other signalling protocol in the world appears to use a > > subset of these > > formats. > > > > Keith > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > > ---------- > > > From: Rosen, Brian[SMTP:Brian.Rosen@marconi.com] > > > Sent: 05 February 2001 15:44 > > > To: 'Jiri Kuthan'; Mark Watson > > > Cc: 'sip@lists.bell-labs.com' > > > Subject: RE: Location information (was Re: [SIP] SIP > > Privacy Draft) > > > > > > There was an effort started several IETFs ago to define a PROTOCOL > > > to exchange geographic location. That was shot down. > > There is still > > > a low level effort to define a format for exchanging such > > information. > > > > > > Before starting another effort, you might want to look at the prior > > > work (spatial). You also MUST forthrightly face up to the privacy > > > concerns that have stymied other efforts. The security > > implications of > > > knowing where you are can be VERY daunting, and in general > > discussions > > > on the issues have yielded more problems than answers.' > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > > > > Sent: Saturday, February 03, 2001 4:49 PM > > > > To: Mark Watson > > > > Cc: 'sip@lists.bell-labs.com' > > > > Subject: Location information (was Re: [SIP] SIP Privacy Draft) > > > > > > > > > > > > > Mark Watson wrote: > > > > [...] > > > > > 5) Location Information > > > > > > > > > > A further type of Party information is the physical > > > > location of the Party. This is useful for calls to emergency > > > > service centers and for geographic routing services. There is > > > > apparantly a URL format for geographic location, so this > > > > could be used for this purpose. > > > > > > > > Where is the URL format specified? > > > > > > > > I agree that URL is a good place to accomodate geographical > > > > location and it > > > > would be useful to have a standardized notation. > > > > draft-daviel-http-geo-header-02.txt > > > > specifies header fields for conveying location in HTTP. > > > > However as the position > > > > identifies services and may be used with more protocols than > > > > just HTTP I would > > > > prefer conveying it in URLs. > > > > > > > > Henning's 911 draft also addresses many of related issues. > > > > > > > > Is there interest in going ahead with such URLs? > > > > > > > > Jiri > > > > > > > > > > > > > > > > ------------ > > > > P.S. It seems to me there are some geo-service points on > > > > which some folks > > > > like to disagree. Let me give a couple of more details from > > > > my perspective > > > > so that we can save a couple of RTTs if there is interest in > > > > discussing this. > > > > - URL format for conveying geo-info is a URL format and > > > > nothing else. There > > > > are three orthogonal jobs: 1) determining geo-info, 2) > > > > finding a server > > > > providing location-base services and 3) conveying the > > > > geo-info to it. > > > > Geo-info in URLs would make only the third job. > > > > - The geo-info may be gained from anywhere: access providers, > > > > from GPS provider, > > > > typed-in by sextant-equipped user, from IPv6 address, etc. > > > > It does not have to > > > > indicate your current position; for example, when planning > > > > a trip a travelling > > > > agent may want to get connected to a hotel nearby his > > > > client's destination. > > > > - Both end-devices and proxies (if they know it) may insert > > > > geo-info. The latter > > > > case may be subject to privacy issues -- users may not be > > > > always happy to > > > > disseminate geo-info. > > > > - No limitations are put on how to find location-based > > > > services. They may be > > > > located at an outbound proxy discovered automatically using > > > > DHCP but they > > > > may be at Jeff's pizza server advertised in newspaper as well. > > > > - No assumptions are made about what the services are; it is > > > > service providers' > > > > discretion to implement "conntact a Pizza Inc. rep in > > > > caller's proximity", > > > > "notify my parents whenever I move", "emergency", etc. > > > > > > > > _______________________________________________ > > > > This list is for continuing development of the SIP protocol. > > > > The sip-implementer's list is the place to discuss implementation, > > > > and to receive advice on understanding existing sip. > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > > "subscribe sip-implementors" in the body. > > > > > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > > > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 10:47:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18851 for ; Tue, 6 Feb 2001 10:47:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 53F3B44377; Tue, 6 Feb 2001 10:42:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from email5.etsi.org (email5.etsi.fr [212.234.161.50]) by lists.bell-labs.com (Postfix) with ESMTP id E150044365 for ; Tue, 6 Feb 2001 10:41:53 -0500 (EST) Received: by EMAIL5 with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Feb 2001 16:41:36 +0100 Message-ID: <7B7F473688DBD211B56C00805F85906C01E46D08@EMAIL2> From: Reinhard Scholl To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP Bake-off: Early Bird Rate for Hotel extended ... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 16:41:52 +0100 ... until 15 February. To register for the event: http://www.etsi.org/bake-off etc. Reinhard Scholl ETSI Bake-off Service _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 11:08:42 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19893 for ; Tue, 6 Feb 2001 11:08:42 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6F484443AE; Tue, 6 Feb 2001 11:03:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id 1214044357 for ; Tue, 6 Feb 2001 11:02:33 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qhars002.nortel.com; Tue, 6 Feb 2001 16:02:18 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Feb 2001 16:02:17 -0000 Message-ID: From: "Mark Watson" To: "Rosen, Brian" , "'William Marshall'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09056.28591D90" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 16:02:08 -0000 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_01C09056.28591D90 Content-Type: text/plain; charset="iso-8859-1" The public network will likely be trusted in the sense that it promises to obey the user's stated privacy requirements, indeed Data Protection legislation will usually oblige the public network provider to do this. Also, it will likely be a requirement of the public service that terminals identify themselves in some way. I do not think it likely that for Emergency calls, terminals/networks will behave differently with respect to identity information than for normal calls except that it will probably not be considered an infringement of privacy to deliver identity information to an Emergency call centre even when the user has requested it be kept private. More complex is how does the public service provider verify the identity and location information ? In the example above, the public service provider can only be sure of the owner of the Enterprise network from which the call came, and this may not translate into a single geographic location. The network would be forced to send forward only the 'unverified' location information provided by the caller. ...Mark > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: 05 February 2001 18:48 > To: 'William Marshall' > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] Re: Location information > > > If I have an enterprise network, and it connects to a public > network, then > the trust boundary may stop at the private/public boundary. The > "subscriber" > is the enterprise, not the individual. In the privacy draft, > if extended to > location, there is no mechanism to: > Recognize that this is an emergency call > Recognize that the UAS is the emergency center > Pass location information despite any of the requests > the UAC may > make. > > Yet, the requirement is to identify the location of the individual. > I think the draft has some fine mechanisms in it. I just > don't think they > are > sufficient for emergency purposes. > > Brian > > > -----Original Message----- > > From: William Marshall [mailto:wtm@research.att.com] > > Sent: Monday, February 05, 2001 1:31 PM > > To: brian.rosen@marconi.com > > Cc: sip@lists.bell-labs.com > > Subject: RE: [SIP] Re: Location information > > > > > > An ordinary call must yield subscriber information. There is > > not an option for the user to suppress this, by law (although the > > user may request this information not be given to the destination). > > However, the destination can always identify the caller, > for purposes > > of tracing an obscene or harassing call. > > > > Accuracy of location is certainly variable, and it is possible > > the UA may permit delivery of less precise information, but suppress > > accurate information. Multiple levels are just like multiple > > identities; > > the privacy draft as described by Mark in previous email > > allows separate > > anonymity requirements to be attached to each. > > > > Bill Marshall > > wtm@research.att.com > > > > -----original message----- > > From: "Rosen, Brian" > > To: "'William Marshall'" > > Cc: sip@lists.bell-labs.com > > Subject: RE: [SIP] Re: Location information > > Date: Mon, 5 Feb 2001 12:01:48 -0500 > > > > The problem that location presents that is different from the > > privacy draft (unless I missed it) is that an emergency call must > > yield location information. There is not an option for the user > > to suppress this, by law. The path by which a user might connect > > to an emergency center cannot be pre-arranged. I believe that it > > will take creation of a cryptographically secure infrastructure > > to allow such a system to have the desired property that the user > > can control location information, but when required it can be > > securely delivered. > > > > I also think that location is not an "all or nothing" kind of > > thing. The privacy draft presupposes that the world is bifurcated > > into trusted and untrusted domains, and privacy is secured > > when venturing into an untrusted domain. This is not the behavior > > I really want. The desired behavior I want is: > > Accuracy (precision) of location is variable > > I may want to give some people precise > > information, others > > less precise. There will be multiple levels > > Time (and motion) variability - if I am mobile, then where I > > am changes over time. I need to express this somehow, > > but I also need to control it (not everyone can > > be told that > > I am mobile) > > What we learned in the spatial effort is that the whole > location thing > > is more complex that you would like it to be, and it is hard to get > > an implementable subset that has enough functionality to be > > interesting. > > We also learned the difficulties in reaching consensus on > issues that > > involve privacy. > > > > Brian > > > > > > > > > > > -----Original Message----- > > > From: William Marshall [mailto:wtm@research.att.com] > > > Sent: Monday, February 05, 2001 11:40 AM > > > To: brian.rosen@marconi.com > > > Cc: sip@lists.bell-labs.com > > > Subject: [SIP] Re: Location information > > > > > > > > > Brian, > > > > > > It seems that the privacy draft faces up squarely to the privacy > > > concerns. The draft already deals with all the regulatory > > > requirements > > > about verification of identity, hiding of identity, etc. > > The security > > > implications of knowing who you are are just as daunting > as knowing > > > where you are. In some places regulations already cover > > > location info, > > > and the framework in the privacy draft deals with them. > > > > > > As with the subscriber identity - the UA may insert it, and may > > > demand (via a tag and a Proxy-Require) that it be kept private. > > > The proxies may verify the identity, and mark it verified, or mark > > > it unverified, and must delete the information if privacy was > > > requested. > > > The procedures are all there in the privacy draft, and just need > > > some minor extensions to handle multiple identity types, and > > > per-identity > > > privacy requests. > > > > > > The previous efforts (spatial) generated a string giving location > > > information. Sip uses "name-addr | addr-spec" everywhere, which > > > includes a display-name string; however a URL format > would be nicer. > > > I was sure I had heard about a URL format with this > information, but > > > can't find any reference to it. > > > > > > Bill Marshall > > > wtm@research.att.com > > > > > > -----original message----- > > > From: "Rosen, Brian" > > > Subject: RE: Location information (was Re: [SIP] SIP > Privacy Draft) > > > Date: Mon, 5 Feb 2001 10:44:54 -0500 > > > > > > There was an effort started several IETFs ago to define a PROTOCOL > > > to exchange geographic location. That was shot down. > > There is still > > > a low level effort to define a format for exchanging such > > information. > > > > > > Before starting another effort, you might want to look at > the prior > > > work (spatial). You also MUST forthrightly face up to the privacy > > > concerns that have stymied other efforts. The security > > > implications of > > > knowing where you are can be VERY daunting, and in general > > discussions > > > on the issues have yielded more problems than answers.' > > > > > > Brian > > > > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > > > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > ------_=_NextPart_001_01C09056.28591D90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Re: Location information

The public network will likely be trusted in the = sense that it promises to obey the user's stated privacy requirements, = indeed Data Protection legislation will usually oblige the public = network provider to do this. Also, it will likely be a requirement of = the public service that terminals identify themselves in some = way.

I do not think it likely that for Emergency calls, = terminals/networks will behave differently with respect to identity = information than for normal calls except that it will probably not be = considered an infringement of privacy to deliver identity information = to an Emergency call centre even when the user has requested it be kept = private.

More complex is how does the public service provider = verify the identity and location information ? In the example above, = the public service provider can only be sure of the owner of the = Enterprise network from which the call came, and this may not translate = into a single geographic location. The network would be forced to send = forward only the 'unverified' location information provided by the = caller.

...Mark

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: 05 February 2001 18:48
> To: 'William Marshall'
> Cc: sip@lists.bell-labs.com
> Subject: RE: [SIP] Re: Location = information
>
>
> If I have an enterprise network, and it = connects to a public
> network, then
> the trust boundary may stop at the = private/public boundary.  The
> "subscriber"
> is the enterprise, not the individual.  In = the privacy draft,
> if extended to
> location, there is no mechanism to:
>       Recognize that = this is an emergency call
>       Recognize that = the UAS is the emergency center
>       Pass location = information despite any of the requests
> the UAC may
> make.
>
> Yet, the requirement is to identify the = location of the individual.
> I think the draft has some fine mechanisms in = it.  I just
> don't think they
> are
> sufficient for emergency purposes.
>
> Brian
>
> > -----Original Message-----
> > From: William Marshall [mailto:wtm@research.att.com]
> > Sent: Monday, February 05, 2001 1:31 = PM
> > To: brian.rosen@marconi.com
> > Cc: sip@lists.bell-labs.com
> > Subject: RE: [SIP] Re: Location = information
> >
> >
> > An ordinary call must yield subscriber = information.  There is
> > not an option for the user to suppress = this, by law (although the
> > user may request this information not be = given to the destination).
> > However, the destination can always = identify the caller,
> for purposes
> > of tracing an obscene or harassing = call.
> >
> > Accuracy of location is certainly = variable, and it is possible
> > the UA may permit delivery of less precise = information, but suppress
> > accurate information.  Multiple = levels are just like multiple
> > identities;
> > the privacy draft as described by Mark in = previous email
> > allows separate
> > anonymity requirements to be attached to = each.
> >
> > Bill Marshall
> > wtm@research.att.com
> >
> > -----original message-----
> > From: "Rosen, Brian" = <Brian.Rosen@marconi.com>
> > To: "'William Marshall'" = <wtm@research.att.com>
> > Cc: sip@lists.bell-labs.com
> > Subject: RE: [SIP] Re: Location = information
> > Date: Mon, 5 Feb 2001 12:01:48 -0500 =
> >
> > The problem that location presents that is = different from the
> > privacy draft (unless I missed it) is that = an emergency call must
> > yield location information.  There is = not an option for the user
> > to suppress this, by law.  The path = by which a user might connect
> > to an emergency center cannot be = pre-arranged.  I believe that it
> > will take creation of a cryptographically = secure infrastructure
> > to allow such a system to have the desired = property that the user
> > can control location information, but when = required it can be
> > securely delivered.
> >
> > I also think that location is not an = "all or nothing" kind of
> > thing.  The privacy draft presupposes = that the world is bifurcated
> > into trusted and untrusted domains, and = privacy is secured
> > when venturing into an untrusted = domain.  This is not the behavior
> > I really want. The desired behavior I want = is:
> >     Accuracy (precision) of = location is variable
> >     =         I may want to give some = people precise
> > information, others
> >     =         less precise.  There = will be multiple levels
> >     Time (and motion) = variability - if I am mobile, then where I
> >     =         am changes over time.  = I need to express this somehow,
> >     =         but I also need to control = it (not everyone can
> > be told that
> >     =         I am mobile)
> > What we learned in the spatial effort is = that the whole
> location thing
> > is more complex that you would like it to = be, and it is hard to get
> > an implementable subset that has enough = functionality to be
> > interesting.
> > We also learned the difficulties in = reaching consensus on
> issues that
> > involve privacy.
> >
> > Brian
> >    
> >    
> >    
> >
> > > -----Original Message-----
> > > From: William Marshall [mailto:wtm@research.att.com]
> > > Sent: Monday, February 05, 2001 11:40 = AM
> > > To: brian.rosen@marconi.com
> > > Cc: sip@lists.bell-labs.com
> > > Subject: [SIP] Re: Location = information
> > >
> > >
> > > Brian,
> > >
> > > It seems that the privacy draft faces = up squarely to the privacy
> > > concerns.  The draft already = deals with all the regulatory
> > > requirements
> > > about verification of identity, = hiding of identity, etc. 
> > The security
> > > implications of knowing who you are = are just as daunting
> as knowing
> > > where you are.  In some places = regulations already cover
> > > location info,
> > > and the framework in the privacy = draft deals with them.
> > >
> > > As with the subscriber identity - the = UA may insert it, and may
> > > demand (via a tag and a = Proxy-Require) that it be kept private.
> > > The proxies may verify the identity, = and mark it verified, or mark
> > > it unverified, and must delete the = information if privacy was
> > > requested.
> > > The procedures are all there in the = privacy draft, and just need
> > > some minor extensions to handle = multiple identity types, and
> > > per-identity
> > > privacy requests.
> > >
> > > The previous efforts (spatial) = generated a string giving location
> > > information.  Sip uses = "name-addr | addr-spec" everywhere, which
> > > includes a display-name string; = however a URL format
> would be nicer.
> > > I was sure I had heard about a URL = format with this
> information, but
> > > can't find any reference to = it.
> > >
> > > Bill Marshall
> > > wtm@research.att.com
> > >
> > > -----original message-----
> > > From: "Rosen, Brian" = <Brian.Rosen@marconi.com>
> > > Subject: RE: Location information = (was Re: [SIP] SIP
> Privacy Draft)
> > > Date: Mon, 5 Feb 2001 10:44:54 = -0500
> > >
> > > There was an effort started several = IETFs ago to define a PROTOCOL
> > > to exchange geographic = location.  That was shot down. 
> > There is still
> > > a low level effort to define a format = for exchanging such
> > information.
> > >
> > > Before starting another effort, you = might want to look at
> the prior
> > > work (spatial).  You also MUST = forthrightly face up to the privacy
> > > concerns that have stymied other = efforts.  The security
> > > implications of
> > > knowing where you are can be VERY = daunting, and in general
> > discussions
> > > on the issues have yielded more = problems than answers.'
> > >
> > > Brian
> > >
> > >
> > > = _______________________________________________
> > > This list is for continuing = development of the SIP protocol.
> > > The sip-implementer's list is the = place to discuss implementation,
> > > and to receive advice on = understanding existing sip.
> > > To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> > > "subscribe = sip-implementors" in the body.
> > >
> >
>
> = _______________________________________________
> This list is for continuing development of the = SIP protocol.
> The sip-implementer's list is the place to = discuss implementation,
> and to receive advice on understanding existing = sip.
> To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the = body.
>

------_=_NextPart_001_01C09056.28591D90-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 11:24:27 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20696 for ; Tue, 6 Feb 2001 11:24:27 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7142B44384; Tue, 6 Feb 2001 11:19:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 5951A443A7 for ; Tue, 6 Feb 2001 11:18:22 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA01575; Tue, 6 Feb 2001 08:18:32 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT24993; Tue, 6 Feb 2001 08:18:15 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA01397; Tue, 6 Feb 2001 08:18:15 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14976.9159.383005.113330@thomasm-u1.cisco.com> To: "Drage, Keith (Keith)" Cc: "'William Marshall'" , "'Rosen, Brian'" , sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information In-Reply-To: <475FF955A05DD411980D00508B6D5FB00BD0D8@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00BD0D8@en0033exch001u.uk.lucent.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 08:18:15 -0800 (PST) Content-Transfer-Encoding: 7bit Drage, Keith (Keith) writes: > While the current privacy draft identifies that a user requesting "full" > privacy will receive this, I do not believe it is true. The current PSTN, > ISDN and mobile network service definitions all provide for some special > users (normally law enforcement agencies or emergency attendants) who have > access to this information no matter what the anonymity aka restriction > parameters indicate. I think the privacy draft needs to identify that > certain categories of user will exist that override the anonymity setting, > and that this is a "national option" of whatever the IETF equivalent of such > terminology is. Ick. This sounds like just the kind of thing that _shouldn't_ be handled at the protocol level, but instead at the service deployment level with the necessary agreements. Why can't the UAC look at the INVITEE's identity to determine if it wants to give out its identity after all? Why can't you make the proxy log INVITE's with calling anonymity requested and then the cops can get it out of the logs if required? Mike _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 11:39:03 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21500 for ; Tue, 6 Feb 2001 11:39:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C09D443E2; Tue, 6 Feb 2001 11:32:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by lists.bell-labs.com (Postfix) with ESMTP id 96EB3443E2 for ; Tue, 6 Feb 2001 11:31:34 -0500 (EST) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id LAA19286; Tue, 6 Feb 2001 11:18:42 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852569EB.005995D1 ; Tue, 6 Feb 2001 11:18:30 -0500 X-Lotus-FromDomain: TELCORDIA From: "Ashutosh Dutta" To: "Michael O'Doherty" Cc: "'Ashutosh Dutta'" , "Michael O'Doherty" , sip@lists.bell-labs.com Message-ID: <852569EB.005993DA.00@notes949.cc.telcordia.com> Subject: RE: [SIP] SIP in small adhoc and Pico networks Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 11:17:45 -0500 Mick, I was not suggesting for multicast sessions, rather ability of these adhoc clients to annouce that they are SIP UA capable and they can do so by announcing their parameters in a well known multicast address (pre-provisioned) by use of SAP/SDP so that other clients in the neighborhood can figure out about the existence of SIP clients. Only thing in this method is that , the adhoc clients should be multicast capable. Thanks Ashutosh _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 11:44:41 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21708 for ; Tue, 6 Feb 2001 11:44:41 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 795E944342; Tue, 6 Feb 2001 11:40:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from taku.hut.fi (taku.hut.fi [130.233.228.87]) by lists.bell-labs.com (Postfix) with ESMTP id ABEF844336 for ; Tue, 6 Feb 2001 11:39:40 -0500 (EST) Received: from beta.hut.fi (bhoeneis@beta.hut.fi [130.233.224.51]) by taku.hut.fi (8.9.3/8.9.3) with ESMTP id SAA13673 for ; Tue, 6 Feb 2001 18:39:39 +0200 (EET) From: Bernie Hoeneisen To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Informing UA after network initated deregistration? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 18:39:37 +0200 (EET) Hi, I have some questions concerning informing the UA in case the network de-registers the UA, and wants to inform the UA about this. Let me describe a possible use case: Supposed the UA normally registers to only one registrar. Furthermore this registrar needs some maintenance break. The policy in this registrar/network is, to inform all its registered UAs, that they have been de-registered (and maybe provide an address, where it can send a new registration.) Remark: There can be more reasons, why a network element needs to de-register a user, maintenance break is just one. My questions: - Has this problem area been addressed earlier in IETF? If yes, please send me some pointers. - What do key-people think about such a feature, where a registrar informs about de-registration of users? Is it welcome to include it into a SIP extension (e.g. defining a method for it e.g. UNREGISTER, or re-using other methods such as NOTIFY), or whatever would be appropriate? br, Bernie _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 11:58:56 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22472 for ; Tue, 6 Feb 2001 11:58:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 31B9044368; Tue, 6 Feb 2001 11:54:06 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 7F00C44359 for ; Tue, 6 Feb 2001 11:53:35 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Feb 6 11:51:31 EST 2001 Received: by lists.bell-labs.com (Postfix) id 5BBFA44384; Tue, 6 Feb 2001 11:39:54 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id DD4F14437D for ; Tue, 6 Feb 2001 11:39:53 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 6 Feb 2001 16:39:53 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00BD0E2@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Drage, Keith (Keith)" , "'Michael Thomas'" Cc: "'William Marshall'" , "'Rosen, Brian'" , sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 16:39:50 -0000 You seem to have two comments: i) that this is a service issue and should not be dealt with at the protocol level. I do have some sympathy with this. However the privacy draft does not stop at the protocol level, and does define that in full anonymity is requested the information is supressed at the last proxy in the trusted network, which I guess you would defined as a service level requirement. Even at the protocol level, we do need a common understanding of the semantics of all the codings, and in my belief, "full" can never mean full anonymity to all potential recipients. Therefore even if we remove all the service aspects, we should be extremely clear about the semantics of the defined values. ii) you seem to be querying whether such a requirement exists at all, and propose to leave everything to analysing call logs. In public networks, all emergency attendents will be specified to automatically have access to such information. They need to assess whether the call is meaningful from that URL (as part of the input to quickly identify malicious calls - something that is an increasing problem throughout the world) and also as a means to reestablishing the call should it be terminated before completion (assuming the call has failed for only a temporary condition). No scanning of call logs is going to fulfil this requirement. I believe this requirement is general for all public networks. In addition, in some countries it appears to be part of the regulatory framework that certain classes of users have access to restricted identities, and therefore public networks in those countries have to provide a means of supporting it. I believe, but have no further information, that the calls that might fall into this class are non-emergency calls to the police, i.e. calls that fulfil some of the requirements of emengency calls but not all of them, e.g. with regard to urgency of response. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Michael Thomas[SMTP:mat@cisco.com] > Sent: 06 February 2001 16:18 > To: Drage, Keith (Keith) > Cc: 'William Marshall'; 'Rosen, Brian'; sip@lists.bell-labs.com > Subject: RE: [SIP] Re: Location information > > Drage, Keith (Keith) writes: > > While the current privacy draft identifies that a user requesting > "full" > > privacy will receive this, I do not believe it is true. The current > PSTN, > > ISDN and mobile network service definitions all provide for some > special > > users (normally law enforcement agencies or emergency attendants) who > have > > access to this information no matter what the anonymity aka restriction > > parameters indicate. I think the privacy draft needs to identify that > > certain categories of user will exist that override the anonymity > setting, > > and that this is a "national option" of whatever the IETF equivalent of > such > > terminology is. > > Ick. This sounds like just the kind of thing that > _shouldn't_ be handled at the protocol level, but > instead at the service deployment level with the > necessary agreements. Why can't the UAC look at > the INVITEE's identity to determine if it wants > to give out its identity after all? Why can't you > make the proxy log INVITE's with calling anonymity > requested and then the cops can get it out of the logs > if required? > > Mike > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 12:11:29 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23082 for ; Tue, 6 Feb 2001 12:11:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 25959443D4; Tue, 6 Feb 2001 11:57:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by lists.bell-labs.com (Postfix) with ESMTP id 25B4C443EB for ; Tue, 6 Feb 2001 11:55:59 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Tue, 6 Feb 2001 16:55:56 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id QAA15633; Tue, 6 Feb 2001 16:55:56 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569EB.005CFA29 ; Tue, 6 Feb 2001 16:55:33 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Gonzalo.Camarillo@lmf.ericsson.se Cc: christer.holmberg@lmf.ericsson.se, jmoloney@nortelnetworks.com, taylor@nortelnetworks.com, sip@lists.bell-labs.com Message-ID: <802569EB.005CF82D.00@marconicomms.com> Subject: Re: [SIP] Overlap call setup Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=uTwobsREb7UvOC3fwDHKZcv8TpHIaeOTJMYcmxeQ2ZtNeF3cRdqA8i6B" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 16:55:39 +0000 --0__=uTwobsREb7UvOC3fwDHKZcv8TpHIaeOTJMYcmxeQ2ZtNeF3cRdqA8i6B Content-type: text/plain; charset=us-ascii Content-Disposition: inline Attached is an earlier posting I raised highlighting my concerns with some of the mechanisms outlined in the sip-isup document. This is the source of recent discussions. Regards, K. Robinson ---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 06/02/2001 16:42 --------------------------- 31/01/2001 16:34 Keith Robinson To: "Joshua Moloney" @ MCEXT cc: sip@lists.bell-labs.com@MCEXT Subject: Re: [SIP] Overlap call setup (Document link: Keith Robinson) I have recently been trying to get clarification on the implemenation of overlap sending; see attached for the discussion that has taken place so far. Certainly, the mechanism outlined (very sketchily) in RFC2543bis-02 sect 4.2.1 is fundamentally flawed. The Request-URI cannot be used to carry extra digits as the Record-Route/Route mechanism would end up overwriting the R-URI and therefore the subsequent digits would be lost. This then leads to the idea of using the TO field as described in sip-isup-00-00.txt; however, I have the following issues with the mechanisms described in this document : As the TO field is different on each subsequent INVITE, then it is a new call leg on an existing call id; RFC2543bis-02 sect. 11.5 does not state what a UAS should make of this. If you follow the logic in 11.5 you get to case (3), but here it only defines the behaviour if the TO and FROM fields match. The 484 sent backwards kills that call attempt (but not the state for that Call-Id - is this problematic for intermediate proxies ?) so subsequent INVITEs will actually be initial INVITEs. As these INVITEs must get to the same terminating UAS, the originating UAC will have to create a ROUTE header in an initial INVITE using , at least the CONTACT address from the 484. This implies the use of source routing, an issue that I don't believe has been fully resolved, and even if it is and becomes part of the base protocol some administrations may be reluctant to admit initial INVITEs which try to circumvent their routing policy, so may reject such INVITEs. Also on the above point, the CONTACT address in the 484 must have the same semantics as that in a 200 response so that a ROUTE header can be built; however RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in 4XX responses indicates a location where additional error information can be found. Indeed, in a recent thread entitled Announcements in SIP (401 & 407 Contact) J. Rosenberg believes that Record-Route does not make sense in any non-200 response. I would raise the question of whether the 484 response has any use in overlap sending (certainly in the case of ISUP) at all. If a node receives insufficient digits to decode than it will wait until it receives some more from the preceding node (or end of dialling timers mature). If the preceding node receives subsequent digits and end of dialling has not been detected then it will pass them on. If the 484 indicated the minimum number of digits before a decode could take place, then it would be useful in cutting down the number of subseqent messages sent. Indeed, isup-sip-00.txt does cover the mechanism where a 183 is sent, and not a 484. The case in point is covered in sect. 11.3 (Example of SIP bridging and overlap signalling); However, I have the following issues with this mechanism: As before relies on source routing. Relies on proxies sending requests on new call legs but existing call-ids to the same downstream server; fine if you administer these proxies, what if you don't ? (Lots of wasted IAMs generated). The mechanism should not send 5 (subsequent INVITE) until it has received an acknowledgement (probably not 100) from the first. Alternatively, the Reason-Phrase could detail more specifically the exact progress of the call ("Decoding Address" in this case ?) so that the ACM is not generated unconditionally. Sect. 11.2 encourages gateways "to return a183 Session Progress with a Contact header as soon as they receive an INVITE that they are going to handle and might contain an incomplete number". Presumably this is to allow the UAC to build a ROUTE so that subsequent INVITEs get to the appropriate UAS. Sect 7.2.3 indicates that a node receiving a 183 prior to generating an ACM should generate an ACM. Applied together these rules may cause a prior node to never send on any subsequent digits and overlap sending would fail. I think an approach is required whereby subsequent digits are sent on the same call leg as the initial INVITE; either multiple INVITEs are allowed before 200 OK (already suggested by J. Rosenberg in a different context) , or the INFO method is used. In both cases the TO field will have to remain the same so a new header (or message body type) is required to convey the digits. Also, replace the 484 with, say, 18X indicating the minimum number of digits required, perhaps in the Reason-Phrase header. Regards, Keith Robinson. "Joshua Moloney" on 31/01/2001 10:49:33 To: sip@lists.bell-labs.com cc: (bcc: Keith Robinson/MAIN/MC1) Subject: [SIP] Overlap call setup Greetings, I would like to ask for clarification regarding the implementation of Overlap. I'll begin by referring to paragraph 3, section 6.1.2 of "draft-ietf-isup-sip-00": It is stated that INVITEs sent after the first one (containing extra digits in the 'To' field) are to be treated as new Call-Legs, seeing as the contents of their 'To' headers differ. As such, there is no relationship between their CSeq values. If this is the case, how is it possible to ensure correct digit ordering over an 'unreliable' transport layer like UDP? It would seem logical that the call originator _would_ use contiguous CSeq values, as it would be 'aware' of the fact that the INVITEs are for the same call. I believe that this issue was raised on the SIP list on 19 November 1999 by Gonzalo C and Jonathan R. The subject of the messages was "Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of the exchange appeared to be an agreement that CSeq ordering should be employed. However, does this in any way imply that under such circumstances the INVITEs would/should belong to the same Call-Leg? After all, the concept of Overlap does not seem to 'fit in' with the concept behind multiple Call-Legs anyway. If there has been a change in thinking behind the problem, and the latest draft is correct, please could you explain how the ordering problem will be overcome. If not, perhaps the draft needs modification to include these considerations... Regards, Josh Moloney --0__=uTwobsREb7UvOC3fwDHKZcv8TpHIaeOTJMYcmxeQ2ZtNeF3cRdqA8i6B Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTIuMzUiPg0KPFRJVExFPk92ZXJsYXAg Y2FsbCBzZXR1cDwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yIEZB Q0U9IkFyaWFsIj5HcmVldGluZ3MsPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFD RT0iQXJpYWwiPkkgd291bGQgbGlrZSB0byBhc2sgZm9yIGNsYXJpZmljYXRpb24gcmVnYXJkaW5n IHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBPdmVybGFwLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yIEZBQ0U9IkFyaWFsIj5JJ2xsIGJlZ2luIGJ5IHJlZmVycmluZyB0byBwYXJhZ3JhcGgg Mywgc2VjdGlvbiA2LjEuMiBvZiAmcXVvdDtkcmFmdC1pZXRmLWlzdXAtc2lwLTAwJnF1b3Q7Ojwv Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JdCBpcyBzdGF0ZWQg dGhhdCBJTlZJVEVzIHNlbnQgYWZ0ZXIgdGhlIGZpcnN0IG9uZSAoY29udGFpbmluZyBleHRyYSBk aWdpdHMgaW4gdGhlICdUbycgZmllbGQpIGFyZSB0byBiZSB0cmVhdGVkIGFzIG5ldyBDYWxsLUxl Z3MsIHNlZWluZyBhcyB0aGUgY29udGVudHMgb2YgdGhlaXIgJ1RvJyBoZWFkZXJzIGRpZmZlci4g QXMgc3VjaCwgdGhlcmUgaXMgbm8gcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlaXIgQ1NlcSB2YWx1 ZXMuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JZiB0aGlzIGlz IHRoZSBjYXNlLCBob3cgaXMgaXQgcG9zc2libGUgdG8gZW5zdXJlIGNvcnJlY3QgZGlnaXQgb3Jk ZXJpbmcgb3ZlciBhbiAndW5yZWxpYWJsZScgdHJhbnNwb3J0IGxheWVyIGxpa2UgVURQPyBJdCB3 b3VsZCBzZWVtIGxvZ2ljYWwgdGhhdCB0aGUgY2FsbCBvcmlnaW5hdG9yIF93b3VsZF8gdXNlIGNv bnRpZ3VvdXMgQ1NlcSB2YWx1ZXMsIGFzIGl0IHdvdWxkIGJlICdhd2FyZScgb2YgdGhlIGZhY3Qg dGhhdCB0aGUgSU5WSVRFcyBhcmUgZm9yIHRoZSBzYW1lIGNhbGwuPC9GT05UPjwvUD4NCg0KPFA+ PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JIGJlbGlldmUgdGhhdCB0aGlzIGlzc3VlIHdhcyBy YWlzZWQgb24gdGhlIFNJUCBsaXN0IG9uIDE5IE5vdmVtYmVyIDE5OTkgYnkgR29uemFsbyBDIGFu ZCBKb25hdGhhbiBSLiBUaGUgc3ViamVjdCBvZiB0aGUgbWVzc2FnZXMgd2FzICZxdW90O1JlOiBD b21tZW50cyBvbiBkcmFmdC1jYW1hcmlsbG8tbW11c2ljLXNpcC1pc3VwLWJjcC0wMC50eHQmcXVv dDsuIFRoZSBvdXRjb21lIG9mIHRoZSBleGNoYW5nZSBhcHBlYXJlZCB0byBiZSBhbiBhZ3JlZW1l bnQgdGhhdCBDU2VxIG9yZGVyaW5nIHNob3VsZCBiZSBlbXBsb3llZC48L0ZPTlQ+PC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkhvd2V2ZXIsIGRvZXMgdGhpcyBpbiBhbnkgd2F5 IGltcGx5IHRoYXQgdW5kZXIgc3VjaCBjaXJjdW1zdGFuY2VzIHRoZSBJTlZJVEVzIHdvdWxkL3No b3VsZCBiZWxvbmcgdG8gdGhlIHNhbWUgQ2FsbC1MZWc/IEFmdGVyIGFsbCwgdGhlIGNvbmNlcHQg b2YgT3ZlcmxhcCBkb2VzIG5vdCBzZWVtIHRvICdmaXQgaW4nIHdpdGggdGhlIGNvbmNlcHQgYmVo aW5kIG11bHRpcGxlIENhbGwtTGVncyBhbnl3YXkuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0la RT0yIEZBQ0U9IkFyaWFsIj5JZiB0aGVyZSBoYXMgYmVlbiBhIGNoYW5nZSBpbiB0aGlua2luZyBi ZWhpbmQgdGhlIHByb2JsZW0sIGFuZCB0aGUgbGF0ZXN0IGRyYWZ0IGlzIGNvcnJlY3QsIHBsZWFz ZSBjb3VsZCB5b3UgZXhwbGFpbiBob3cgdGhlIG9yZGVyaW5nIHByb2JsZW0gd2lsbCBiZSBvdmVy Y29tZS4gSWYgbm90LCBwZXJoYXBzIHRoZSBkcmFmdCBuZWVkcyBtb2RpZmljYXRpb24gdG8gaW5j bHVkZSB0aGVzZSBjb25zaWRlcmF0aW9ucy4uLjwvRk9OVD48L1A+DQo8QlI+DQoNCjxQPjxGT05U IFNJWkU9MiBGQUNFPSJBcmlhbCI+UmVnYXJkcyw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJ WkU9MiBGQUNFPSJBcmlhbCI+Sm9zaCBNb2xvbmV5PC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8 L0hUTUw+ --0__=uTwobsREb7UvOC3fwDHKZcv8TpHIaeOTJMYcmxeQ2ZtNeF3cRdqA8i6B-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 12:16:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23352 for ; Tue, 6 Feb 2001 12:16:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3461D44395; Tue, 6 Feb 2001 12:05:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id D9C0C44402 for ; Tue, 6 Feb 2001 12:01:24 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA22939; Tue, 6 Feb 2001 09:01:01 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT25237; Tue, 6 Feb 2001 09:00:46 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA01406; Tue, 6 Feb 2001 09:00:45 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14976.11709.758225.911192@thomasm-u1.cisco.com> To: "Drage, Keith (Keith)" Cc: "'Michael Thomas'" , "'William Marshall'" , "'Rosen, Brian'" , sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information In-Reply-To: <475FF955A05DD411980D00508B6D5FB00BD0E2@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00BD0E2@en0033exch001u.uk.lucent.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 09:00:45 -0800 (PST) Content-Transfer-Encoding: 7bit Drage, Keith (Keith) writes: > You seem to have two comments: > > i) that this is a service issue and should not be dealt with at the > protocol level. I do have some sympathy with this. However the privacy draft > does not stop at the protocol level, and does define that in full anonymity > is requested the information is supressed at the last proxy in the trusted > network, which I guess you would defined as a service level requirement. > Even at the protocol level, we do need a common understanding of the > semantics of all the codings, and in my belief, "full" can never mean full > anonymity to all potential recipients. Therefore even if we remove all the > service aspects, we should be extremely clear about the semantics of the > defined values. I don't see what the problem is here. The proxy that suppresses caller id is a trusted third party. Part of the implicit agreement between my UA and the proxy is that certain entities -- 911 centers, etc, -- will always have access to my caller id. If you don't like that service, then don't use that proxy. > ii) you seem to be querying whether such a requirement exists at all, > and propose to leave everything to analysing call logs. In public networks, > all emergency attendents will be specified to automatically have access to > such information. They need to assess whether the call is meaningful from > that URL (as part of the input to quickly identify malicious calls - > something that is an increasing problem throughout the world) and also as a > means to reestablishing the call should it be terminated before completion > (assuming the call has failed for only a temporary condition). No scanning > of call logs is going to fulfil this requirement. I believe this requirement > is general for all public networks. In addition, in some countries it > appears to be part of the regulatory framework that certain classes of users > have access to restricted identities, and therefore public networks in those > countries have to provide a means of supporting it. I believe, but have no > further information, that the calls that might fall into this class are > non-emergency calls to the police, i.e. calls that fulfil some of the > requirements of emengency calls but not all of them, e.g. with regard to > urgency of response. And what, exactly, is the problem of having a back door interface to call logs for certain people? I think it would be pretty trivial to hack up a http GET that did this, for example, and that's just off the top of my head -- there's probably a dozen other better ways to skin that cat. Heck, if E911 has static routing entries at the proxy, it doesn't even need a back channel since it would know that the caller id shouldn't be scrubbed. *My* point is that SIP being required to define classes of users to have certain privileges begs an enormous number of questions, not the least of which is designing for a particular system which the IETF don't do. Mike _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 12:33:27 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24177 for ; Tue, 6 Feb 2001 12:33:27 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AD675443C8; Tue, 6 Feb 2001 12:29:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id AAB4F443C3 for ; Tue, 6 Feb 2001 12:28:30 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA02115; Tue, 6 Feb 2001 09:23:53 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAT25442; Tue, 6 Feb 2001 09:23:37 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA01415; Tue, 6 Feb 2001 09:23:37 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14976.13081.369974.593691@thomasm-u1.cisco.com> To: "Mark Watson" Cc: "Rosen, Brian" , "'William Marshall'" , sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 09:23:37 -0800 (PST) Content-Transfer-Encoding: 7bit Mark Watson writes: > More complex is how does the public service provider verify the identity and > location information ? In the same way that it authenticates the user so that it isn't subject to fraud? > In the example above, the public service provider can > only be sure of the owner of the Enterprise network from which the call > came, and this may not translate into a single geographic location. The > network would be forced to send forward only the 'unverified' location > information provided by the caller. That's not necessarily the case. Assuming that the there isn't a fog box in the middle, the UA could sign the request which the public service provider could verify. Or the enterprise could vouch for the identity of the user and/or location much like the PSTN does now. Mike _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 13:25:06 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27006 for ; Tue, 6 Feb 2001 13:25:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9798C4437D; Tue, 6 Feb 2001 13:20:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by lists.bell-labs.com (Postfix) with ESMTP id 39A4D4433B for ; Tue, 6 Feb 2001 13:19:33 -0500 (EST) Received: from yuri.dns.microsoft.com ([172.30.236.11]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 6 Feb 2001 09:35:49 -0800 Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Tue, 6 Feb 2001 09:36:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4638.0 content-class: urn:content-classes:message Subject: RE: [SIP] Re: Location information MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09063.5B7D577F" Message-ID: Thread-Topic: [SIP] Re: Location information Thread-Index: AcCQW8AFrmesw1wSTpe7abYuJKs1rAABvIcg From: "Christian Huitema" To: "Mark Watson" , "Rosen, Brian" , "William Marshall" Cc: X-OriginalArrivalTime: 06 Feb 2001 17:36:38.0662 (UTC) FILETIME=[5C08DA60:01C09063] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 09:36:37 -0800 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09063.5B7D577F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Uh, what is exactly the "public network" that you are talking about? The ISP to which my entreprise network connects have no idea of what the bits in the packets are, and probably don't want to know. The basic SIP solution is end-to-end, with the network being essentially transparent. Sure, there may be competing voice service providers that want to provide added value on top of the basic service, but we cannot assume that there has to be a man in the middle.=20 =20 -- Christian Huitema =20 =20 -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com]=20 Sent: Tuesday, February 06, 2001 8:02 AM To: Rosen, Brian; William Marshall Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information The public network will likely be trusted in the sense that it promises to obey the user's stated privacy requirements, indeed Data Protection legislation will usually oblige the public network provider to do this. Also, it will likely be a requirement of the public service that terminals identify themselves in some way. I do not think it likely that for Emergency calls, terminals/networks will behave differently with respect to identity information than for normal calls except that it will probably not be considered an infringement of privacy to deliver identity information to an Emergency call centre even when the user has requested it be kept private. More complex is how does the public service provider verify the identity and location information ? In the example above, the public service provider can only be sure of the owner of the Enterprise network from which the call came, and this may not translate into a single geographic location. The network would be forced to send forward only the 'unverified' location information provided by the caller. ...Mark=20 > -----Original Message-----=20 > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20 > Sent: 05 February 2001 18:48=20 > To: 'William Marshall'=20 > Cc: sip@lists.bell-labs.com=20 > Subject: RE: [SIP] Re: Location information=20 >=20 >=20 > If I have an enterprise network, and it connects to a public=20 > network, then=20 > the trust boundary may stop at the private/public boundary. The=20 > "subscriber"=20 > is the enterprise, not the individual. In the privacy draft,=20 > if extended to=20 > location, there is no mechanism to:=20 > Recognize that this is an emergency call=20 > Recognize that the UAS is the emergency center=20 > Pass location information despite any of the requests=20 > the UAC may=20 > make.=20 >=20 > Yet, the requirement is to identify the location of the individual.=20 > I think the draft has some fine mechanisms in it. I just=20 > don't think they=20 > are=20 > sufficient for emergency purposes.=20 >=20 > Brian=20 >=20 > > -----Original Message-----=20 > > From: William Marshall [mailto:wtm@research.att.com]=20 > > Sent: Monday, February 05, 2001 1:31 PM=20 > > To: brian.rosen@marconi.com=20 > > Cc: sip@lists.bell-labs.com=20 > > Subject: RE: [SIP] Re: Location information=20 > >=20 > >=20 > > An ordinary call must yield subscriber information. There is=20 > > not an option for the user to suppress this, by law (although the=20 > > user may request this information not be given to the destination).=20 > > However, the destination can always identify the caller,=20 > for purposes=20 > > of tracing an obscene or harassing call.=20 > >=20 > > Accuracy of location is certainly variable, and it is possible=20 > > the UA may permit delivery of less precise information, but suppress=20 > > accurate information. Multiple levels are just like multiple=20 > > identities;=20 > > the privacy draft as described by Mark in previous email=20 > > allows separate=20 > > anonymity requirements to be attached to each.=20 > >=20 > > Bill Marshall=20 > > wtm@research.att.com=20 > >=20 > > -----original message-----=20 > > From: "Rosen, Brian" =20 > > To: "'William Marshall'" =20 > > Cc: sip@lists.bell-labs.com=20 > > Subject: RE: [SIP] Re: Location information=20 > > Date: Mon, 5 Feb 2001 12:01:48 -0500=20 > >=20 > > The problem that location presents that is different from the=20 > > privacy draft (unless I missed it) is that an emergency call must=20 > > yield location information. There is not an option for the user=20 > > to suppress this, by law. The path by which a user might connect=20 > > to an emergency center cannot be pre-arranged. I believe that it=20 > > will take creation of a cryptographically secure infrastructure=20 > > to allow such a system to have the desired property that the user=20 > > can control location information, but when required it can be=20 > > securely delivered.=20 > >=20 > > I also think that location is not an "all or nothing" kind of=20 > > thing. The privacy draft presupposes that the world is bifurcated=20 > > into trusted and untrusted domains, and privacy is secured=20 > > when venturing into an untrusted domain. This is not the behavior=20 > > I really want. The desired behavior I want is:=20 > > Accuracy (precision) of location is variable=20 > > I may want to give some people precise=20 > > information, others=20 > > less precise. There will be multiple levels=20 > > Time (and motion) variability - if I am mobile, then where I=20 > > am changes over time. I need to express this somehow,=20 > > but I also need to control it (not everyone can=20 > > be told that=20 > > I am mobile)=20 > > What we learned in the spatial effort is that the whole=20 > location thing=20 > > is more complex that you would like it to be, and it is hard to get=20 > > an implementable subset that has enough functionality to be=20 > > interesting.=20 > > We also learned the difficulties in reaching consensus on=20 > issues that=20 > > involve privacy.=20 > >=20 > > Brian=20 > > =20 > > =20 > > =20 > >=20 > > > -----Original Message-----=20 > > > From: William Marshall [mailto:wtm@research.att.com]=20 > > > Sent: Monday, February 05, 2001 11:40 AM=20 > > > To: brian.rosen@marconi.com=20 > > > Cc: sip@lists.bell-labs.com=20 > > > Subject: [SIP] Re: Location information=20 > > >=20 > > >=20 > > > Brian,=20 > > >=20 > > > It seems that the privacy draft faces up squarely to the privacy=20 > > > concerns. The draft already deals with all the regulatory > > > requirements=20 > > > about verification of identity, hiding of identity, etc. =20 > > The security=20 > > > implications of knowing who you are are just as daunting=20 > as knowing=20 > > > where you are. In some places regulations already cover=20 > > > location info,=20 > > > and the framework in the privacy draft deals with them.=20 > > >=20 > > > As with the subscriber identity - the UA may insert it, and may=20 > > > demand (via a tag and a Proxy-Require) that it be kept private.=20 > > > The proxies may verify the identity, and mark it verified, or mark=20 > > > it unverified, and must delete the information if privacy was=20 > > > requested.=20 > > > The procedures are all there in the privacy draft, and just need=20 > > > some minor extensions to handle multiple identity types, and=20 > > > per-identity=20 > > > privacy requests.=20 > > >=20 > > > The previous efforts (spatial) generated a string giving location=20 > > > information. Sip uses "name-addr | addr-spec" everywhere, which=20 > > > includes a display-name string; however a URL format=20 > would be nicer.=20 > > > I was sure I had heard about a URL format with this=20 > information, but=20 > > > can't find any reference to it.=20 > > >=20 > > > Bill Marshall=20 > > > wtm@research.att.com=20 > > >=20 > > > -----original message-----=20 > > > From: "Rosen, Brian" =20 > > > Subject: RE: Location information (was Re: [SIP] SIP=20 > Privacy Draft)=20 > > > Date: Mon, 5 Feb 2001 10:44:54 -0500=20 > > >=20 > > > There was an effort started several IETFs ago to define a PROTOCOL=20 > > > to exchange geographic location. That was shot down. =20 > > There is still=20 > > > a low level effort to define a format for exchanging such=20 > > information.=20 > > >=20 > > > Before starting another effort, you might want to look at=20 > the prior=20 > > > work (spatial). You also MUST forthrightly face up to the privacy=20 > > > concerns that have stymied other efforts. The security=20 > > > implications of=20 > > > knowing where you are can be VERY daunting, and in general > > discussions=20 > > > on the issues have yielded more problems than answers.'=20 > > >=20 > > > Brian=20 > > >=20 > > >=20 > > > _______________________________________________=20 > > > This list is for continuing development of the SIP protocol.=20 > > > The sip-implementer's list is the place to discuss implementation,=20 > > > and to receive advice on understanding existing sip.=20 > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with=20 > > > "subscribe sip-implementors" in the body.=20 > > >=20 > >=20 >=20 > _______________________________________________=20 > This list is for continuing development of the SIP protocol.=20 > The sip-implementer's list is the place to discuss implementation,=20 > and to receive advice on understanding existing sip.=20 > To subscribe to it, send mail to majordomo@cs.columbia.edu with=20 > "subscribe sip-implementors" in the body.=20 >=20 ------_=_NextPart_001_01C09063.5B7D577F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Uh,=20 what is exactly the "public network" that you are talking about? The ISP = to=20 which my entreprise network connects have no idea of what the bits in = the=20 packets are, and probably don't want to know. The basic SIP solution is=20 end-to-end, with the network being essentially transparent. Sure, there = may be=20 competing voice service providers that want to provide added value on = top of the=20 basic service, but we cannot assume that there has to be a man in the = middle.=20
 
--=20 Christian Huitema
 
 
-----Original = Message-----
From: Mark=20 Watson [mailto:mwatson@nortelnetworks.com]
Sent: Tuesday, = February=20 06, 2001 8:02 AM
To: Rosen, Brian; William = Marshall
Cc:=20 sip@lists.bell-labs.com
Subject: RE: [SIP] Re: Location=20 information

The public network will likely be trusted in the = sense that it=20 promises to obey the user's stated privacy requirements, indeed Data=20 Protection legislation will usually oblige the public network provider = to do=20 this. Also, it will likely be a requirement of the public service that = terminals identify themselves in some way.

I do not think it likely that for Emergency calls,=20 terminals/networks will behave differently with respect to identity=20 information than for normal calls except that it will probably not be=20 considered an infringement of privacy to deliver identity information = to an=20 Emergency call centre even when the user has requested it be kept=20 private.

More complex is how does the public service provider = verify=20 the identity and location information ? In the example above, the = public=20 service provider can only be sure of the owner of the Enterprise = network from=20 which the call came, and this may not translate into a single = geographic=20 location. The network would be forced to send forward only the = 'unverified'=20 location information provided by the caller.

...Mark

> -----Original Message-----
>=20 From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]=20
> Sent: 05 February 2001 18:48
> To: 'William Marshall'
> = Cc:=20 sip@lists.bell-labs.com
> Subject: RE: = [SIP] Re:=20 Location information
>
>=20
> If I have an enterprise network, and it = connects=20 to a public
> network, then =
> the trust boundary may stop at the private/public = boundary. =20 The
> "subscriber"
> is=20 the enterprise, not the individual.  In the privacy draft,=20
> if extended to
>=20 location, there is no mechanism to:
>=20       Recognize that this is an emergency = call=20
>       Recognize that = the UAS is=20 the emergency center
>=20       Pass location information despite any = of the=20 requests
> the UAC may
>=20 make.
>
> = Yet, the=20 requirement is to identify the location of the individual. =
> I think the draft has some fine mechanisms in it.  = I just=20
> don't think they
> are=20
> sufficient for emergency = purposes.=20
>
> Brian =
>
> > -----Original=20 Message-----
> > From: William = Marshall [mailto:wtm@research.att.com]=20
> > Sent: Monday, February 05, 2001 1:31 = PM=20
> > To: brian.rosen@marconi.com =
> > Cc: sip@lists.bell-labs.com
> >=20 Subject: RE: [SIP] Re: Location information
> >=20
> >
> = > An=20 ordinary call must yield subscriber information.  There is =
> > not an option for the user to suppress = this, by law=20 (although the
> > user may request = this=20 information not be given to the destination).
>=20 > However, the destination can always identify the caller, =
> for purposes
> > of = tracing an=20 obscene or harassing call.
> > =
> > Accuracy of location is certainly variable, and it = is=20 possible
> > the UA may permit = delivery of less=20 precise information, but suppress
> > = accurate=20 information.  Multiple levels are just like multiple =
> > identities;
> > the = privacy=20 draft as described by Mark in previous email
> >=20 allows separate
> > anonymity = requirements to be=20 attached to each.
> >
> > Bill Marshall
> >=20 wtm@research.att.com
> > =
> > -----original message-----
> >=20 From: "Rosen, Brian" <Brian.Rosen@marconi.com>
> > To: "'William Marshall'" = <wtm@research.att.com>=20
> > Cc: sip@lists.bell-labs.com =
> > Subject: RE: [SIP] Re: Location information =
> > Date: Mon, 5 Feb 2001 12:01:48 -0500 =
> >
> > The problem = that location=20 presents that is different from the
> = > privacy=20 draft (unless I missed it) is that an emergency call must =
> > yield location information.  There is not an = option for=20 the user
> > to suppress this, by = law.  The=20 path by which a user might connect
> > = to an=20 emergency center cannot be pre-arranged.  I believe that = it=20
> > will take creation of a cryptographically = secure=20 infrastructure
> > to allow such a = system to=20 have the desired property that the user
> = > can=20 control location information, but when required it can be =
> > securely delivered.
> = >=20
> > I also think that location is not = an "all or=20 nothing" kind of
> > thing.  The = privacy=20 draft presupposes that the world is bifurcated
>=20 > into trusted and untrusted domains, and privacy is secured =
> > when venturing into an untrusted = domain.  This=20 is not the behavior
> > I really want. = The=20 desired behavior I want is:
> >=20     Accuracy (precision) of location is variable =
> >    =20         I may want to give some = people=20 precise
> > information, others =
> >     =        =20 less precise.  There will be multiple levels
>=20 >     Time (and motion) variability - if I am = mobile, then=20 where I
> >    =20         am changes over time.  = I need=20 to express this somehow,
> > =    =20         but I also need to control = it (not=20 everyone can
> > be told that =
> >     =        =20 I am mobile)
> > What we learned in = the spatial=20 effort is that the whole
> location = thing=20
> > is more complex that you would like it to = be, and=20 it is hard to get
> > an implementable = subset=20 that has enough functionality to be
> = >=20 interesting.
> > We also learned the=20 difficulties in reaching consensus on
> = issues=20 that
> > involve privacy. =
> >
> > Brian =
> >    
> = >=20    
> > =    =20
> >
> = > >=20 -----Original Message-----
> > > = From:=20 William Marshall [mailto:wtm@research.att.com]=20
> > > Sent: Monday, February 05, 2001 = 11:40=20 AM
> > > To: = brian.rosen@marconi.com=20
> > > Cc: sip@lists.bell-labs.com =
> > > Subject: [SIP] Re: Location information =
> > >
> > > =
> > > Brian,
> > = >=20
> > > It seems that the privacy = draft faces=20 up squarely to the privacy
> > >=20 concerns.  The draft already deals with all the regulatory=20
> > > requirements
> > > about verification of identity, hiding of = identity,=20 etc. 
> > The security =
> > > implications of knowing who you are are just = as daunting=20
> as knowing
> > >=20 where you are.  In some places regulations already cover =
> > > location info,
> = > >=20 and the framework in the privacy draft deals with them. =
> > >
> > > As = with the=20 subscriber identity - the UA may insert it, and may
> > > demand (via a tag and a Proxy-Require) that it = be kept=20 private.
> > > The proxies may = verify the=20 identity, and mark it verified, or mark
> = > >=20 it unverified, and must delete the information if privacy was =
> > > requested.
> > = > The=20 procedures are all there in the privacy draft, and just need =
> > > some minor extensions to handle multiple = identity types,=20 and
> > > per-identity =
> > > privacy requests.
> > >=20
> > > The previous efforts = (spatial)=20 generated a string giving location
> > = >=20 information.  Sip uses "name-addr | addr-spec" everywhere, = which=20
> > > includes a display-name string; = however a URL=20 format
> would be nicer.
> > > I was sure I had heard about a URL format with = this=20
> information, but
>=20 > > can't find any reference to it.
> >=20 >
> > > Bill Marshall =
> > > wtm@research.att.com
> >=20 >
> > > -----original = message-----=20
> > > From: "Rosen, Brian"=20 <Brian.Rosen@marconi.com>
> > = >=20 Subject: RE: Location information (was Re: [SIP] SIP
> Privacy Draft)
> > > = Date: Mon, 5=20 Feb 2001 10:44:54 -0500
> > >=20
> > > There was an effort started = several=20 IETFs ago to define a PROTOCOL
> > = > to=20 exchange geographic location.  That was shot down.  =
> > There is still
> > = > a low=20 level effort to define a format for exchanging such
> > information.
> > = >=20
> > > Before starting another = effort, you=20 might want to look at
> the prior =
> > > work (spatial).  You also MUST = forthrightly face up=20 to the privacy
> > > concerns that = have=20 stymied other efforts.  The security
> >=20 > implications of
> > > knowing = where you=20 are can be VERY daunting, and in general
> >=20 discussions
> > > on the issues = have yielded=20 more problems than answers.'
> > >=20
> > > Brian
> >=20 >
> > >
> >=20 > _______________________________________________
> > > This list is for continuing development of the = SIP=20 protocol.
> > > The = sip-implementer's list is=20 the place to discuss implementation,
> = > >=20 and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to=20 majordomo@cs.columbia.edu with
> > = >=20 "subscribe sip-implementors" in the body.
> >=20 >
> >
>=20
>=20 _______________________________________________
>=20 This list is for continuing development of the SIP protocol. =
> The sip-implementer's list is the place to discuss=20 implementation,
> and to receive advice = on=20 understanding existing sip.
> To = subscribe to it,=20 send mail to majordomo@cs.columbia.edu with
>=20 "subscribe sip-implementors" in the body.
>=20

=00 ------_=_NextPart_001_01C09063.5B7D577F-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 14:53:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29748 for ; Tue, 6 Feb 2001 14:53:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2AC6344338; Tue, 6 Feb 2001 14:53:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by lists.bell-labs.com (Postfix) with ESMTP id 1F37E44336 for ; Tue, 6 Feb 2001 14:52:58 -0500 (EST) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA01429 for ; Tue, 6 Feb 2001 14:52:30 -0500 (EST) Received: from cisco.com (rtp-xdm1.cisco.com [64.102.17.80]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAY10978 (AUTH shbhatna); Tue, 6 Feb 2001 14:52:56 -0500 (EST) Message-ID: <3A805617.2D9890F9@cisco.com> From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Branch parameter question Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 14:52:55 -0500 Content-Transfer-Encoding: 7bit The bis-02 version says Branch Parameter = f(To, From, Call-ID, Request-URI, Seq number of CSeq) where 'f' is some hashing function. Which part of the From and To is this referring to - the addr-spec portion ? Does it not assume that addr-spec of From and To headers are byte-by-byte equal. I thought From and To headers should be compared by comparing - the addr-spec portion ( per the rules of URL comparison) - the tag and possibly extension params ?? Now, as we all know 2 URLS may be equal but may not be byte-by-byte equal. So, how does this branch parameter scheme work ?? Thanks, Shail _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 16:05:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01912 for ; Tue, 6 Feb 2001 16:05:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F1B4A4434A; Tue, 6 Feb 2001 16:05:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 57B1E4433F for ; Tue, 6 Feb 2001 16:04:43 -0500 (EST) 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 QAA15406; Tue, 6 Feb 2001 16:04:43 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA28151; Tue, 6 Feb 2001 16:04:35 -0500 (EST) Message-ID: <3A808A87.CA2A1BFD@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Cc: "'William Marshall'" , "'Rosen, Brian'" , sip@lists.bell-labs.com Subject: Re: [SIP] Re: Location information References: <475FF955A05DD411980D00508B6D5FB00BD0D8@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 15:36:39 -0800 Content-Transfer-Encoding: 7bit > > ---------- > > From: Rosen, Brian[SMTP:Brian.Rosen@marconi.com] > > Sent: 05 February 2001 17:01 > > To: 'William Marshall' > > Cc: sip@lists.bell-labs.com > > Subject: RE: [SIP] Re: Location information > > > > The problem that location presents that is different from the > > privacy draft (unless I missed it) is that an emergency call must > > yield location information. There is not an option for the user > > to suppress this, by law. > > > While the current privacy draft identifies that a user requesting "full" > privacy will receive this, I do not believe it is true. The current PSTN, > ISDN and mobile network service definitions all provide for some special > users (normally law enforcement agencies or emergency attendants) who have > access to this information no matter what the anonymity aka restriction > parameters indicate. I think the privacy draft needs to identify that > certain categories of user will exist that override the anonymity setting, > and that this is a "national option" of whatever the IETF equivalent of such > terminology is. There is no equivalent, since there are no national IETF standards. Anything that relies on end systems "being nice" (i.e., doing things they have no interest in doing) is per definition doomed in the Internet that we know. Thus, we can assume that devices will provide accurate information when making a 911 call (since the end system can easily know that this is an emergency call), but if law enforcement has the illusion it can rely on that on other calls, they need to find a different Internet to play in. Should a proxy want to enforce or insert it, those users that are so inclined will find a different proxy. > > > The path by which a user might connect > > to an emergency center cannot be pre-arranged. I believe that it > > will take creation of a cryptographically secure infrastructure > > to allow such a system to have the desired property that the user > > can control location information, but when required it can be > > securely delivered. I don't see this as a problem if we can arrange for an end-to-end public key for PSAPs (or one of the copies of the entity that routes to PSAPs) stored in end systems. > This will vary between different services. For emergency calls, the current > location at the time at which the INVITE was sent is probably sufficient. > Location information in other protocols does include both accuracy and > velocity indicators, if such are required. Other services may require a more > continuous update of location - at some point this ceases to become > something that the SIP protocol should provide and becomes something that > should be in a separate media stream. Any views on where this breakpoint is > reached? This seems like a SUBSCRIBE/NOTIFY operation until the request rate reaches some threshold. I don't think that there is a hard threshold, since this depends solely on the resources one wishes to expend on this and with end-to-end notifications, the effort for "the network" isn't all that large. I would guess that most would agree that 10 msg/sec is probably excessive (and calls for a media stream) and that one message/minute is probably ok, but we'll differ on the points in between. > > ii) the final proxy before a untrusted hop is reached could reduce the > accuracy of location information. > > I am not sure how we would go about specifying this behaviour generically > for all identifiers. It could be done for certain identifiers in an > application specific manner. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 16:12:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02101 for ; Tue, 6 Feb 2001 16:12:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9C17144357; Tue, 6 Feb 2001 16:12:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 7C59E44336 for ; Tue, 6 Feb 2001 16:11:01 -0500 (EST) 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 f16LB0d19698; Tue, 6 Feb 2001 22:11:00 +0100 (MET) Received: from lmf.ericsson.se ([147.117.107.8]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id WAA18236; Tue, 6 Feb 2001 22:10:51 +0100 (MET) Message-ID: <3A806896.3B3B9942@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: christer.holmberg@lmf.ericsson.se, jmoloney@nortelnetworks.com, taylor@nortelnetworks.com, sip@lists.bell-labs.com, adam.roach@ericsson.com Subject: Re: [SIP] Overlap call setup References: <802569EB.005CF82D.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 23:11:50 +0200 Content-Transfer-Encoding: 7bit Hello, Thanks for the pointer. Answers inline: Keith Robinson wrote: > > Attached is an earlier posting I raised highlighting my concerns with some of > the > mechanisms outlined in the sip-isup document. This is the source of recent > discussions. > > Regards, > > K. Robinson > ---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 06/02/2001 16:42 > --------------------------- > > 31/01/2001 16:34 > Keith Robinson > > To: "Joshua Moloney" @ MCEXT > cc: sip@lists.bell-labs.com@MCEXT > > Subject: Re: [SIP] Overlap call setup (Document link: Keith Robinson) > > I have recently been trying to get clarification on the implemenation of > overlap sending; see attached for the discussion that has taken place > so far. > > Certainly, the mechanism outlined (very sketchily) in RFC2543bis-02 sect 4.2.1 > is fundamentally flawed. The Request-URI cannot be used to carry extra digits > as the Record-Route/Route mechanism would end up overwriting the R-URI > and therefore the subsequent digits would be lost. > > This then leads to the idea of using the TO field as described in > sip-isup-00-00.txt; > however, I have the following issues with the mechanisms described in this > document : > > As the TO field is different on each subsequent INVITE, then it is a new call > leg > on an existing call id; RFC2543bis-02 sect. 11.5 does not state what a UAS > should make of this. If you follow the logic in 11.5 you get to case (3), but > here it only defines the behaviour if the TO and FROM fields match. > I do not see here a big problem for a UA. If the UA is a gateway, it will handle the overlap signalling properly. If it is a pure SIP UA, it will answer the first INVITE with a 484 (or "Not found response") and process the second INVITE properly. > The 484 sent backwards kills that call attempt (but not the state for that > Call-Id - > is this problematic for intermediate proxies ?) so subsequent INVITEs will > actually be initial INVITEs. As these INVITEs must get to the same terminating > UAS, > the originating UAC will have to create a ROUTE header in an initial INVITE > using , > at least the CONTACT address from the 484. This implies the use of source > routing, an > issue that I don't believe has been fully resolved, and even if it is and > becomes part > of the base protocol some administrations may be reluctant to admit initial > INVITEs > which try to circumvent their routing policy, so may reject such INVITEs. > There was a big thread about source routing. This kind of source routing is fine. Current proxies handle it properly. If a proxy sees an INVITe with a route header, it does not know if it is the first INVITE or a re-INVITE. Thus, it will work properly. Even if the proxy stores state and it receives a INVITE (non re-INVITE) with a route header, it should honor it. Otherwise, the proxy is not robust. This allows a call stateful proxy to lose state, re-boot and still be able to route requests properly. > Also on the above point, the CONTACT address in the 484 must have the same > semantics as that in a 200 response so that a ROUTE header can be built; however > RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in 4XX responses > indicates a location where additional error information can be found. Indeed, in > a recent > thread entitled Announcements in SIP (401 & 407 Contact) J. Rosenberg believes > that > Record-Route does not make sense in any non-200 response. This contact header that is going to be used is the one present in the 183, not in the 484. This solves the problem of several IAMs al the same time. If the answer was a 484, no IAM was sent. Thus, the next re-INVITE with more digits can be very well handled by a different gateway. > > I would raise the question of whether the 484 response has any use in overlap > sending > (certainly in the case of ISUP) at all. 484 responses are not very useful in this scenario, but they might be useful in anothers (when a UA can ask the user to type more digits, for instance). If a node receives insufficient digits > to decode than it will wait until it receives some more from the preceding node > (or end of > dialling timers mature). If the preceding node receives subsequent digits and > end of dialling > has not been detected then it will pass them on. If the 484 indicated the > minimum number of > digits before a decode could take place, then it would be useful in cutting down > the number > of subseqent messages sent. > > Indeed, isup-sip-00.txt does cover the mechanism where a 183 is sent, and not a > 484. > The case in point is covered in sect. 11.3 (Example of SIP bridging and overlap > signalling); > However, I have the following issues with this mechanism: > > As before relies on source routing. See comments above about this type of source routing. > > Relies on proxies sending requests on new call legs but existing call-ids to the > same > downstream server; fine if you administer these proxies, what if you don't ? Why would you want to limit a call to one call leg?? > (Lots of > wasted IAMs generated). Lots of IAMs????? The situation where more than one (typically two) IAMs are generated is when the 183 arrived to the ingrees gateway after it sent the first re-INVITE. This situation is ulikely to happen anyway, because if you receive subsequent digits so fast (faster than a RTT), you should implement a timer, and not send LOTS of SAMs anyway. > The mechanism should not send 5 (subsequent INVITE) > until it has received an acknowledgement (probably not 100) from the first. Again a timer configuration problem. You can, and your re-INVITE will most likelt reach the same egrees gateway as the 1st one... but it might reach a different one. Thus, the ingrees gateway should be aware of this and be ready for canceling one of the TWO IAMs sent if this happen. But again, this situation is not common. > Alternatively, > the Reason-Phrase could detail more specifically the exact progress of the call > ("Decoding Address" > in this case ?) so that the ACM is not generated unconditionally. > > Sect. 11.2 encourages gateways "to return a183 Session Progress with a Contact > header as soon as they receive an INVITE that they are going to handle and might > contain > an incomplete number". Presumably this is to allow the UAC to build a ROUTE so > that subsequent > INVITEs get to the appropriate UAS. YES. > Sect 7.2.3 indicates that a node receiving a > 183 prior to generating > an ACM should generate an ACM. Applied together these rules may cause a prior > node to never > send on any subsequent digits and overlap sending would fail. The same way that nodes handling overlap signalling do not release the call upon reception of a 484, they will not generate ACMs upon reception of a 183 without SDP and without an ancapsulated ACM... we might want to add this clarification to the draft. > > I think an approach is required whereby subsequent digits are sent on the same > call leg as the > initial INVITE; either multiple INVITEs are allowed before 200 OK (already > suggested by J. Rosenberg > in a different context) Stacking requests is not a good solution in this case. It leads to a lot of problems that we certainly want to avoid. > , or the INFO method is used. If INFO is used any vanilla SIP UA should implement INFO in order tor receive calls/sessions that use overlap signalling. One of the most important requirements for overlap signalling in SIP was that a vanilla SIP UA could handle it. In both cases the TO field > will have to remain the > same so a new header (or message body type) is required to convey the digits. Again, we do not want to implement this in vanilla SIP UAs. Best regards, Gonzalo > Also, replace the 484 > with, say, 18X indicating the minimum number of digits required, perhaps in the > Reason-Phrase header. > > Regards, > > Keith Robinson. > > "Joshua Moloney" on 31/01/2001 10:49:33 > > > > > > > > To: sip@lists.bell-labs.com > > cc: (bcc: Keith Robinson/MAIN/MC1) > > > > Subject: [SIP] Overlap call setup > > > Greetings, > > I would like to ask for clarification regarding the implementation of > Overlap. > > I'll begin by referring to paragraph 3, section 6.1.2 of > "draft-ietf-isup-sip-00": > > It is stated that INVITEs sent after the first one (containing extra digits > in the 'To' field) are to be treated as new Call-Legs, seeing as the > contents of their 'To' headers differ. As such, there is no relationship > between their CSeq values. > > If this is the case, how is it possible to ensure correct digit ordering > over an 'unreliable' transport layer like UDP? It would seem logical that > the call originator _would_ use contiguous CSeq values, as it would be > 'aware' of the fact that the INVITEs are for the same call. > > I believe that this issue was raised on the SIP list on 19 November 1999 by > Gonzalo C and Jonathan R. The subject of the messages was "Re: Comments on > draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of the exchange > appeared to be an agreement that CSeq ordering should be employed. > > However, does this in any way imply that under such circumstances the > INVITEs would/should belong to the same Call-Leg? After all, the concept of > Overlap does not seem to 'fit in' with the concept behind multiple Call-Legs > anyway. > > If there has been a change in thinking behind the problem, and the latest > draft is correct, please could you explain how the ordering problem will be > overcome. If not, perhaps the draft needs modification to include these > considerations... > > Regards, > > Josh Moloney > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64 > Description: Internet HTML -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 16:28:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02480 for ; Tue, 6 Feb 2001 16:28:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 741E944381; Tue, 6 Feb 2001 16:28:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by lists.bell-labs.com (Postfix) with ESMTP id 9201C44371 for ; Tue, 6 Feb 2001 16:27:17 -0500 (EST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id GAA24217; Wed, 7 Feb 2001 06:27:12 +0900 (JST) (envelope-from ohba.takumi@lab.ntt.co.jp) Received: from imi.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/05/00) with ESMTP id GAA20046; Wed, 7 Feb 2001 06:27:11 +0900 (JST) (envelope-from ohba.takumi@lab.ntt.co.jp) Received: from ohbamebius ([129.60.5.147]) by imi.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id GAA13447; Wed, 7 Feb 2001 06:27:09 +0900 (JST) Reply-To: ohba.takumi@lab.ntt.co.jp Message-Id: <4.0.1-J.20010207061527.01040160@imi.m.ecl.ntt.co.jp> X-Sender: ohba.takumi@lab.ntt.co.jp (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1-J To: Christer Holmberg From: Takumi Ohba Subject: Re: [SIP] over-length message Cc: sip@lists.bell-labs.com In-Reply-To: <3A800F42.6D1A99A7@lmf.ericsson.se> References: <200102060952.SAA22102@imi.m.ecl.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 07 Feb 2001 06:34:57 +0900 Dear Holmberg, Thank you for your reply. In my understanding, a SIP message may include user-to-user information, suc h as an image file. Such information can be very large, say 100k byte or more. In addition, some transport layer protocols have poorer max length than UDP. I think that SIP needs explicit specification for handling of over-length me ssage, or I don't think this is a good idea but SIP should specify simple me ssage segmentation procedures like as ISUP. Comments? Regards, At 16:50 01/02/06 +0200, Christer Holmberg wrote: > > Hi, > > I think it has been agreed that a SIP message, including possible MIME > message bodies, should "fit" into a single UDP MTU. Do you have an > example where that length would not be enough? > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Takumi Ohba wrote: > > > > Dear all, > > > > This is Takumi Ohba, NTT. > > I have some questions concerning handling of over-length messages. > > > > One example; > > If a user want to attach very large data to a SIP message as a MIME part, > > but it make the message longer than the MTU, what should the user do? > > The only choice to the user is to give up attaching the data? > > > > Another example; > > A SIP proxy may receive a larger message that it can transfer. This may > > happen when the proxy uses different transport layers for incoming and > > outgoing links and the outgoing link has smaller maximum datagram packet > > size than that for the incoming link. > > For example, the incoming link uses UDP (max: 64k octets) and the outgoing > > link uses signalling AAL (max: 4k octets). The proxy may receive 5k-octet > > message if the MTU permits it, but it cannot transfer the message to the > > outgoing signalling AAL link. > > > > In this case, what should the proxy do? > > Should it give up transferring the massage itself, or shorten the message > > and transfer it by discarding less important part of the message? In the > > latter case, how can the proxy identify less important part of the messa ge? > > > > Best regards, > > Takumi Ohba > > > > *************************************************** > > Takumi OHBA > > NTT Network Service Systems Laboratories > > tel +81 422 59 4405 fax +81 422 59 3494 > > e-mail ohba.takumi@lab.ntt.co.jp > > *************************************************** > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 16:39:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02780 for ; Tue, 6 Feb 2001 16:39:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0B74B4439F; Tue, 6 Feb 2001 16:39:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 0053344359 for ; Tue, 6 Feb 2001 16:38:08 -0500 (EST) 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 QAA18269; Tue, 6 Feb 2001 16:38:08 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA28321; Tue, 6 Feb 2001 16:38:03 -0500 (EST) Message-ID: <3A8099E4.7D4C5E7F@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ohba.takumi@lab.ntt.co.jp Cc: Christer Holmberg , sip@lists.bell-labs.com Subject: Re: [SIP] over-length message References: <200102060952.SAA22102@imi.m.ecl.ntt.co.jp> <4.0.1-J.20010207061527.01040160@imi.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 16:42:12 -0800 Content-Transfer-Encoding: 7bit Takumi Ohba wrote: > > Dear Holmberg, > > Thank you for your reply. > > In my understanding, a SIP message may include user-to-user information, suc > h as an image file. > Such information can be very large, say 100k byte or more. > > In addition, some transport layer protocols have poorer max length than UDP. > > I think that SIP needs explicit specification for handling of over-length me > ssage, or I don't think this is a good idea but SIP should specify simple me > ssage segmentation procedures like as ISUP. We have a protocol called TCP for that. The sender should know, to reasonably degree, what the max. message size is and switch to TCP as needed (or SCTP, if that floats your boat). For very long responses, the UAS can redirect to a transport=tcp URL. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 16:49:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03001 for ; Tue, 6 Feb 2001 16:49:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C3866443B4; Tue, 6 Feb 2001 16:49:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by lists.bell-labs.com (Postfix) with ESMTP id 0B7E34433F for ; Tue, 6 Feb 2001 16:49:00 -0500 (EST) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA08996 for ; Tue, 6 Feb 2001 16:48:33 -0500 (EST) Received: from cisco.com (rtp-xdm1.cisco.com [64.102.17.80]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAY14239 (AUTH shbhatna); Tue, 6 Feb 2001 16:48:57 -0500 (EST) Message-ID: <3A807148.4BF21AEC@cisco.com> From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] Branch parameter question References: <3A805617.2D9890F9@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 16:48:56 -0500 Content-Transfer-Encoding: 7bit Just to clarify, I don't mean comparison of From with To, but comparison of From header as stored in transaction state with what is received in a PDU. Similarly for To header. Basically, my question is hash output of equivalent From headers would be different, so should the hashing be done on "normalized" URL components or the unparsed addr-spec. Thanks, Shail Shail Bhatnagar wrote: > > The bis-02 version says > Branch Parameter = f(To, From, Call-ID, Request-URI, Seq number of CSeq) > > where 'f' is some hashing function. > Which part of the From and To is this referring to - the > addr-spec portion ? Does it not assume that addr-spec > of From and To headers are byte-by-byte equal. I thought > >From and To headers should be compared by comparing > - the addr-spec portion ( per the rules of URL comparison) > - the tag and possibly extension params ?? > Now, as we all know 2 URLS may be equal but may not be > byte-by-byte equal. So, how does this branch parameter > scheme work ?? > > Thanks, > Shail > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 16:55:34 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03109 for ; Tue, 6 Feb 2001 16:55:34 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5ACFE443C0; Tue, 6 Feb 2001 16:51:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 13762443B2 for ; Tue, 6 Feb 2001 16:50:41 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA15701; Tue, 6 Feb 2001 13:50:40 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f16LohC28201; Tue, 6 Feb 2001 13:50:43 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id NAA21852; Tue, 6 Feb 2001 13:50:33 -0800 (PST) Message-ID: <3A80725A.4BF6901E@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] More on privacy References: <475FF955A05DD411980D00508B6D5FB00BD0D9@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 16:53:30 -0500 Content-Transfer-Encoding: 7bit There is currently an "rpi-screen" parameter defined in the privacy draft which basically tags the Remote-Party-ID as verified/screened or not. I'm not sure I understand why it doesn't address what you want to achieve here. -- Flemming "Drage, Keith (Keith)" wrote: > To add a further issue to the current discussions on privacy. > > The current specification of trusted versus untrusted really only deals with > the presentation of information to untrusted entities. > > In the ISDN/PSTN world there is also the concept of information being > provided by an untrusted source, for example an separate enterprise network, > or a user attached to that separate enterprise network. > > In some cases the untrusted source may be the only entity able to provide > truly accurate information. Therefore for Calling Line Identification > Presentation there is a special indicator of user provided unscreened. > > This means that in ISDN we have an either or situation for CLIP, the user is > either told: > > - this is the number for dialback purposes, but you cannot trust the > reliability of this information because I cannot check it. > > or > > - this is the number for dialback purposes, but I have only provided > you with the information I can check, therefore it may not get you back to > the real source of the call, but only to the enterprise network that sourced > it. > > In SIP we could have the possibility of providing both, but we would need to > discuss how we would identify these identifiers. For example two different > identifier tags in the Remote-Party_ID header, or a common identifier tag, > but a separate indication of level of screening. > > Keith > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 17:14:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03587 for ; Tue, 6 Feb 2001 17:14:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AC013443DC; Tue, 6 Feb 2001 17:14:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 927CA44359 for ; Tue, 6 Feb 2001 17:13:29 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA00466; Tue, 6 Feb 2001 14:13:41 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f16MDRk06531; Tue, 6 Feb 2001 14:13:27 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id OAA01360; Tue, 6 Feb 2001 14:13:25 -0800 (PST) Message-ID: <3A8077BB.F8988D2D@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Cc: "'sip@lists.bell-labs.com'" , "'Mark Watson'" Subject: Re: [SIP] SIP Privacy Draft References: <475FF955A05DD411980D00508B6D5FB00BD0D5@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 17:16:27 -0500 Content-Transfer-Encoding: 7bit "Drage, Keith (Keith)" wrote: > In addition to the current discussion on location, I wanted to add some > words on the following part of Marks comment. > > I do believe within any individual session, and for any endpoint, there are > multiple identities that need to be exchanged. > > We either have the option of specifying these in the RFC, or allowing to be > added as IANA registered enhancements, or a combination of both. Before we > decide this, we possibly need to get some idea of the number of different > identities people may want. I think this involves adding definitions to the > terms that Mark has identified. > > We should also note that we already have a number of identities already > existing in the draft, depending on the endpoint we are talking about. For > the calling endpoint we have the From header and the Contact header. These > may fulfil some of the functions of i) and ii) in Mark's list. Your point is well taken, but I don't think the specific examples apply. Note that there is an inherent conflict between anonymity and providing identity information in the From header, which was part of the motivation for the Remote-Party-ID originally. As far as the Contact header is concerned, I also don't think it covers (or should cover) subscriber/user identity. We had discussed if it perhaps covered the terminal identity, and while you conceivably could construct an argument for that, it would inherently place restrictions on the format and information you can provide in a Contact header. I think that would be an unfortunate overloading of semantics, especially if we have a general Remote-Party-ID mechanism that could be used instead, so I would argue against that. > > > I would like to propose two definitions which I believe should be covered by > an extended privacy draft (note that these are currently phrased from the > viewpoint of the calling endpoint, and would need to be modified to cover > other endpoints: > > Logical Calling Subscriber ID > A URL that identifies the owner of the telecommunications > subscription of the user originating the session. > > Logical Calling User ID > A URL that identifies the calling user, and that shall at least be > suitable for making a return session establishment. I'll let Mark speak to these as they are his definitions, but I believe your Logical Calling User ID combines a couple of Mark's identities in one, and I don't that was his intention. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 17:47:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04137 for ; Tue, 6 Feb 2001 17:47:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E5F5144370; Tue, 6 Feb 2001 17:47:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 3EB0544336 for ; Tue, 6 Feb 2001 17:46:04 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 6 Feb 2001 17:44:04 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1MM3GKD4>; Tue, 6 Feb 2001 17:44:04 -0500 Message-ID: <28560036253BD41191A10000F8BCBD11039BC23D@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Christer Holmberg , Gonzalo Camarillo Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0908E.4EDA50A0" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 17:44:04 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0908E.4EDA50A0 Content-Type: text/plain; charset="iso-8859-1" Just to re-hash, in the ISUP-SIP-ISUP context, once call signalling has reached an egress gateway, SIP has done its job -- additional digits will not change call state. It is therefore reasonable to use INFO to carry the additional digits. If we are talking ISUP-SIP, once the destination UAS or a UAS in a B2BUA has been reached, the same consideration applies. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Tuesday, February 06, 2001 1:15 AM > To: Gonzalo Camarillo > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > Hi Gonzalo, > > I didn't say I am going to use INFO, but that is what has > been proposed > earlier in this thread, so I assumed INFO would be used. The > reason for > the discussion from the beginning was that the overlap signalling, > according to the SIP-ISUP mapping draft, may not work very well, and a > solution using 18x responses and INFO messages, instead of 484 and > re-INVITEs, was proposed. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > Gonzalo Camarillo wrote: > > > > Hello Christer, > > > > Why are you using INFO for sending extra digits? > > > > Please, check the SIP-ISUP mapping draft, overlap > signalling section. > > > > Regards, > > > > Gonzalo > > > > Christer Holmberg wrote: > > > > > > Hi, > > > > > > The discussion about overlap dialing has been pretty much > about calls > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > Consider the following scenario. > > > > > > PSTN PHONE GW SIP SERVER SIP UAS > > > ----------------------------------------------------------- > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > | <- 18x ------ | > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > | <- 200 (INFO) | > > > | <- 18x ------ | > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > | <- 200 (INFO) | -- INVITE > > > --> > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > In this case, the SIP server (note that I am not using > the word 'proxy') > > > must collect digits, sent from the PSTN side using > overlap dialing, to > > > be able to find the SIP UAS, and INFO is used to provide > the digits > > > after the INVITE has been sent. > > > > > > My question is, should a SIP server (proxy, if you like) > be allowed to > > > behave like this, or MUST it send 486s, and receive new > INVITEs, until > > > it is able to find the UAS? > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > ------_=_NextPart_001_01C0908E.4EDA50A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Operlap dialing within a SIP network

Just to re-hash, in the ISUP-SIP-ISUP context, once = call signalling has reached an egress gateway, SIP has done its job -- = additional digits will not change call state.  It is therefore = reasonable to use INFO to carry the additional digits.  If we are = talking ISUP-SIP, once the destination UAS or a UAS in a B2BUA has been = reached, the same consideration applies.

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: Tuesday, February 06, 2001 1:15 AM
> To: Gonzalo Camarillo
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] Operlap dialing within a SIP = network
>
>
>
> Hi Gonzalo,
>
> I didn't say I am going to use INFO, but that = is what has
> been proposed
> earlier in this thread, so I assumed INFO would = be used. The
> reason for
> the discussion from the beginning was that the = overlap signalling,
> according to the SIP-ISUP mapping draft, may = not work very well, and a
> solution using 18x responses and INFO messages, = instead of 484 and
> re-INVITEs, was proposed.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
>
> Gonzalo Camarillo wrote:
> >
> > Hello Christer,
> >
> > Why are you using INFO for sending extra = digits?
> >
> > Please, check the SIP-ISUP mapping draft, = overlap
> signalling section.
> >
> > Regards,
> >
> > Gonzalo
> >
> > Christer Holmberg wrote:
> > >
> > > Hi,
> > >
> > > The discussion about overlap dialing = has been pretty much
> about calls
> > > from SIP to PSTN, or = PSTN-SIP-PSTN.
> > >
> > > Consider the following = scenario.
> > >
> > > PSTN = PHONE           &= nbsp; GW           = SIP SERVER      SIP UAS
> > > = -----------------------------------------------------------
> > >
> > > --- 1 --->    -- = IAM -> | -- INVITE -->  |
> > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > --- 2 --->    -- = SAM -> | -- INFO ---->  |
> > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |
> > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > --- 3 --->    -- = SAM -> | -- INFO ---->  |
> > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |   -- INVITE
> > > -->
> > = >           &n= bsp;           &n= bsp; | <- 200 (INVITE)|   <- 200 ------
> > >
> > > In this case, the SIP server (note = that I am not using
> the word 'proxy')
> > > must collect digits, sent from the = PSTN side using
> overlap dialing, to
> > > be able to find the SIP UAS, and INFO = is used to provide
> the digits
> > > after the INVITE has been = sent.
> > >
> > > My question is, should a SIP server = (proxy, if you like)
> be allowed to
> > > behave like this, or MUST it send = 486s, and receive new
> INVITEs, until
> > > it is able to find the UAS?
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> >
> > --
> > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> > = Finland           = ;        http://www.hut.fi/~gonzalo
>

------_=_NextPart_001_01C0908E.4EDA50A0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 19:32:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05152 for ; Tue, 6 Feb 2001 19:32:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 517E544359; Tue, 6 Feb 2001 19:32:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 69DB644336 for ; Tue, 6 Feb 2001 19:31:03 -0500 (EST) 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 TAA23194; Tue, 6 Feb 2001 19:31:00 -0500 (EST) 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 TAA24270; Tue, 6 Feb 2001 19:31:03 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <1H2LD2SR>; Tue, 6 Feb 2001 19:30:56 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF03207AAF@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: Michael Thomas , "Drage, Keith (Keith)" Cc: "'William Marshall'" , sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 19:31:00 -0500 > I don't see what the problem is here. The proxy that > suppresses caller id is a trusted third party. Part > of the implicit agreement between my UA and the > proxy is that certain entities -- 911 centers, etc, -- > will always have access to my caller id. If you > don't like that service, then don't use that proxy. > This is a protocol issue because there are three entities, the UAC, the outgoing proxy, and the incoming proxy (or UAS) at the emergency center. There has to be additional specification that details how this works. The spec probably needs some MUSTs. Some of the issues are: How does the UA indicate to the outgoing proxy that this is an emergency call? What are the minimum requirements for caller identification and location that must be delivered from the UAC to the Proxy Server? How does the outgoing proxy server identify "right" emergency server? What is the minimum requirement for caller identification and location that must be delivered from the outgoing Proxy Server to the center? Are there some minimum requirements for protocol options the emergency center (or proxy or gateway) must implement in order to provide the service needed? It's not entirely clear to me that this is an IETF matter, but it HAS to be done, somewhere. Brian _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 21:10:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06402 for ; Tue, 6 Feb 2001 21:10:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D0FE84433E; Tue, 6 Feb 2001 21:10:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 39B6544336 for ; Tue, 6 Feb 2001 21:09:06 -0500 (EST) 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 f17294d25875; Wed, 7 Feb 2001 03:09:04 +0100 (MET) Received: from lmf.ericsson.se ([142.133.141.44]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id DAA01737; Wed, 7 Feb 2001 03:08:58 +0100 (MET) Message-ID: <3A80AE75.7FC9357B@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor Cc: Christer Holmberg , sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: <28560036253BD41191A10000F8BCBD11039BC23D@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 07 Feb 2001 04:09:57 +0200 Content-Transfer-Encoding: 7bit Hello Tom, Tom-PT Taylor wrote: > > Just to re-hash, in the ISUP-SIP-ISUP context, once call signalling > has reached an egress gateway, SIP has done its job -- additional > digits will not change call state. It is therefore reasonable to use > INFO to carry the additional digits. If we are talking ISUP-SIP, once > the destination UAS or a UAS in a B2BUA has been reached, the same > consideration applies. > I do not agree with these two statements: The 1st INVITE (with just some digits) arrives to a vanilla SIP UA. I will return a Not Found or a 484 Address incomplete. The subsequent INFO carrying more digits will be discarded. Thus, the PSTN to SIP gateway will have to re issue a new INVITE with all the digits. Therefore, it is better to begin directly using er-INVITEs rather than INFO. Besides, I do not think that SIP is just a transport protocol that carries ISUP messages between two gateways. For that, we have already SIGTRAN. SIP might be used to provide services, even when the call is a PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete state. And a SIP message with an incomplete to field does not carry complete state. What if my SIP proxy provides a service for a PSTN-SIP-PSTN call based on the to field (called party number). That proxy would like to see an updated to field, not just a to field that contains just some digits. Best regards, Gonzalo > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Tuesday, February 06, 2001 1:15 AM > > To: Gonzalo Camarillo > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > Hi Gonzalo, > > > > I didn't say I am going to use INFO, but that is what has > > been proposed > > earlier in this thread, so I assumed INFO would be used. The > > reason for > > the discussion from the beginning was that the overlap signalling, > > according to the SIP-ISUP mapping draft, may not work very well, and > a > > solution using 18x responses and INFO messages, instead of 484 and > > re-INVITEs, was proposed. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > Gonzalo Camarillo wrote: > > > > > > Hello Christer, > > > > > > Why are you using INFO for sending extra digits? > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > signalling section. > > > > > > Regards, > > > > > > Gonzalo > > > > > > Christer Holmberg wrote: > > > > > > > > Hi, > > > > > > > > The discussion about overlap dialing has been pretty much > > about calls > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > Consider the following scenario. > > > > > > > > PSTN PHONE GW SIP SERVER SIP UAS > > > > ----------------------------------------------------------- > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > | <- 18x ------ | > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > | <- 200 (INFO) | > > > > | <- 18x ------ | > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > | <- 200 (INFO) | -- INVITE > > > > --> > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > In this case, the SIP server (note that I am not using > > the word 'proxy') > > > > must collect digits, sent from the PSTN side using > > overlap dialing, to > > > > be able to find the SIP UAS, and INFO is used to provide > > the digits > > > > after the INVITE has been sent. > > > > > > > > My question is, should a SIP server (proxy, if you like) > > be allowed to > > > > behave like this, or MUST it send 486s, and receive new > > INVITEs, until > > > > it is able to find the UAS? > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 21:37:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07822 for ; Tue, 6 Feb 2001 21:37:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CBD3F443B3; Tue, 6 Feb 2001 21:37:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 049AD44373 for ; Tue, 6 Feb 2001 21:36:11 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 6 Feb 2001 21:19:23 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1MM3GL67>; Tue, 6 Feb 2001 21:19:24 -0500 Message-ID: <28560036253BD41191A10000F8BCBD11039BC2C1@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Gonzalo Camarillo Cc: Christer Holmberg , sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C090AC.62CB7710" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 21:19:23 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C090AC.62CB7710 Content-Type: text/plain; charset="iso-8859-1" Sorry, we're talking past each other. The premise of my statements is that an INVITE has reached a UAS which has accepted it. It follows that the UAS did not send back a 484, but rather an interim response. IF more digits come along, the INFO method is there to carry them. They do not affect the SIP call state; they are used beyond the UAS, either in a PSTN call or in another SIP call as the case may be. > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, February 06, 2001 9:10 PM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: Christer Holmberg; sip@lists.bell-labs.com > Subject: Re: [SIP] Operlap dialing within a SIP network > > > Hello Tom, > > Tom-PT Taylor wrote: > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call signalling > > has reached an egress gateway, SIP has done its job -- additional > > digits will not change call state. It is therefore > reasonable to use > > INFO to carry the additional digits. If we are talking > ISUP-SIP, once > > the destination UAS or a UAS in a B2BUA has been reached, the same > > consideration applies. > > > > I do not agree with these two statements: > > The 1st INVITE (with just some digits) arrives to a vanilla SIP UA. I > will return a Not Found or a 484 Address incomplete. The > subsequent INFO > carrying more digits will be discarded. Thus, the PSTN to SIP gateway > will have to re issue a new INVITE with all the digits. > Therefore, it is > better to begin directly using er-INVITEs rather than INFO. > > Besides, I do not think that SIP is just a transport protocol that > carries ISUP messages between two gateways. For that, we have already > SIGTRAN. SIP might be used to provide services, even when the > call is a > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > state. And a > SIP message with an incomplete to field does not carry complete state. > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call based > on the to field (called party number). That proxy would like to see an > updated to field, not just a to field that contains just some digits. > > Best regards, > > Gonzalo > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > To: Gonzalo Camarillo > > > Cc: sip@lists.bell-labs.com > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hi Gonzalo, > > > > > > I didn't say I am going to use INFO, but that is what has > > > been proposed > > > earlier in this thread, so I assumed INFO would be used. The > > > reason for > > > the discussion from the beginning was that the overlap signalling, > > > according to the SIP-ISUP mapping draft, may not work > very well, and > > a > > > solution using 18x responses and INFO messages, instead of 484 and > > > re-INVITEs, was proposed. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > Hello Christer, > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > signalling section. > > > > > > > > Regards, > > > > > > > > Gonzalo > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > Hi, > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > about calls > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > Consider the following scenario. > > > > > > > > > > PSTN PHONE GW SIP SERVER SIP UAS > > > > > ----------------------------------------------------------- > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > | <- 18x ------ | > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > | <- 200 (INFO) | > > > > > | <- 18x ------ | > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > | <- 200 (INFO) | -- INVITE > > > > > --> > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > In this case, the SIP server (note that I am not using > > > the word 'proxy') > > > > > must collect digits, sent from the PSTN side using > > > overlap dialing, to > > > > > be able to find the SIP UAS, and INFO is used to provide > > > the digits > > > > > after the INVITE has been sent. > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > be allowed to > > > > > behave like this, or MUST it send 486s, and receive new > > > INVITEs, until > > > > > it is able to find the UAS? > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : > Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > ------_=_NextPart_001_01C090AC.62CB7710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Operlap dialing within a SIP network

Sorry, we're talking past each other.  The = premise of my statements is that an INVITE has reached a UAS which has = accepted it.  It follows that the UAS did not send back a 484, but = rather an interim response.  IF more digits come along, the INFO = method is there to carry them.  They do not affect the SIP call = state; they are used beyond the UAS, either in a PSTN call or in = another SIP call as the case may be.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: Tuesday, February 06, 2001 9:10 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: Christer Holmberg; = sip@lists.bell-labs.com
> Subject: Re: [SIP] Operlap dialing within a SIP = network
>
>
> Hello Tom,
>
> Tom-PT Taylor wrote:
> >
> > Just to re-hash, in the ISUP-SIP-ISUP = context, once call signalling
> > has reached an egress gateway, SIP has = done its job -- additional
> > digits will not change call state.  = It is therefore
> reasonable to use
> > INFO to carry the additional digits.  = If we are talking
> ISUP-SIP, once
> > the destination UAS or a UAS in a B2BUA = has been reached, the same
> > consideration applies.
> >
>
> I do not agree with these two = statements:
>
> The 1st INVITE (with just some digits) arrives = to a vanilla SIP UA. I
> will return a Not Found or a 484 Address = incomplete. The
> subsequent INFO
> carrying more digits will be discarded. Thus, = the PSTN to SIP gateway
> will have to re issue a new INVITE with all the = digits.
> Therefore, it is
> better to begin directly using er-INVITEs = rather than INFO.
>
> Besides, I do not think that SIP is just a = transport protocol that
> carries ISUP messages between two gateways. For = that, we have already
> SIGTRAN. SIP might be used to provide services, = even when the
> call is a
> PSTN-SIP-PSTN call. Thus, SIP messages MUST = carry complete
> state. And a
> SIP message with an incomplete to field does = not carry complete state.
> What if my SIP proxy provides a service for a = PSTN-SIP-PSTN call based
> on the to field (called party number). That = proxy would like to see an
> updated to field, not just a to field that = contains just some digits.
>
> Best regards,
>
> Gonzalo
>
>
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > > Sent: Tuesday, February 06, 2001 1:15 = AM
> > > To: Gonzalo Camarillo
> > > Cc: sip@lists.bell-labs.com
> > > Subject: Re: [SIP] Operlap dialing = within a SIP network
> > >
> > >
> > >
> > > Hi Gonzalo,
> > >
> > > I didn't say I am going to use INFO, = but that is what has
> > > been proposed
> > > earlier in this thread, so I assumed = INFO would be used. The
> > > reason for
> > > the discussion from the beginning was = that the overlap signalling,
> > > according to the SIP-ISUP mapping = draft, may not work
> very well, and
> > a
> > > solution using 18x responses and INFO = messages, instead of 484 and
> > > re-INVITEs, was proposed.
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > >
> > >
> > > Gonzalo Camarillo wrote:
> > > >
> > > > Hello Christer,
> > > >
> > > > Why are you using INFO for = sending extra digits?
> > > >
> > > > Please, check the SIP-ISUP = mapping draft, overlap
> > > signalling section.
> > > >
> > > > Regards,
> > > >
> > > > Gonzalo
> > > >
> > > > Christer Holmberg wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > The discussion about = overlap dialing has been pretty much
> > > about calls
> > > > > from SIP to PSTN, or = PSTN-SIP-PSTN.
> > > > >
> > > > > Consider the following = scenario.
> > > > >
> > > > > PSTN = PHONE           &= nbsp; GW           = SIP SERVER      SIP UAS
> > > > > = -----------------------------------------------------------
> > > > >
> > > > > --- 1 = --->    -- IAM -> | -- INVITE -->  = |
> > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > --- 2 = --->    -- SAM -> | -- INFO ---->  = |
> > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |
> > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > --- 3 = --->    -- SAM -> | -- INFO ---->  = |
> > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |   -- INVITE
> > > > > -->
> > > > = >           &n= bsp;           &n= bsp; | <- 200 (INVITE)|   <- 200 ------
> > > > >
> > > > > In this case, the SIP = server (note that I am not using
> > > the word 'proxy')
> > > > > must collect digits, sent = from the PSTN side using
> > > overlap dialing, to
> > > > > be able to find the SIP = UAS, and INFO is used to provide
> > > the digits
> > > > > after the INVITE has been = sent.
> > > > >
> > > > > My question is, should a = SIP server (proxy, if you like)
> > > be allowed to
> > > > > behave like this, or MUST = it send 486s, and receive new
> > > INVITEs, until
> > > > > it is able to find the = UAS?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Christer Holmberg
> > > > > Ericsson Finland
> > > >
> > > > --
> > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > FIN-02420 = Jorvas          Email = : 
> Gonzalo.Camarillo@ericsson.com
> > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > >
>
> --
> Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> = Finland           = ;        http://www.hut.fi/~gonzalo
>

------_=_NextPart_001_01C090AC.62CB7710-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 21:52:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA08207 for ; Tue, 6 Feb 2001 21:52:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8890C4438C; Tue, 6 Feb 2001 21:52:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 2E1D844336 for ; Tue, 6 Feb 2001 21:51:27 -0500 (EST) 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 f172pPC13983; Wed, 7 Feb 2001 03:51:25 +0100 (MET) Received: from lmf.ericsson.se ([142.133.141.44]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id DAA04115; Wed, 7 Feb 2001 03:51:19 +0100 (MET) Message-ID: <3A80B862.773EB941@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor Cc: Christer Holmberg , sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: <28560036253BD41191A10000F8BCBD11039BC2C1@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 07 Feb 2001 04:52:18 +0200 Content-Transfer-Encoding: 7bit Hi Tom, Still I want to have full state in every SIP message. If the call is addresed to the phone number 1234, I want to have a to field that says 1234. I do not care if there is a leg routed thru the PSTN and another thru SIP. Carrying full state is one of the beauties of SIP. If we begin using INFO for this, it would be the same as using SAMs. Differen names, the same thing... I do not want to re-create ISUP using SIP. I believe that if the session has a destination, it should be present in the to field. Again, if a proxy is providing services for this particular call, it will want to see the called party number in order to trigger the proper service. This is a very good reason for updating the to field every time we have more digits. I like to use SIP between two gateways because it is possible to provide SIP services for a PSTN to PSTN call. If all we want to do is finding a egrees gateway, we would probably want to use other protocols (TRIP & SIGTRAN for instance). Regards, Gonzalo Tom-PT Taylor wrote: > > Sorry, we're talking past each other. The premise of my statements is > that an INVITE has reached a UAS which has accepted it. It follows > that the UAS did not send back a 484, but rather an interim response. > IF more digits come along, the INFO method is there to carry them. > They do not affect the SIP call state; they are used beyond the UAS, > either in a PSTN call or in another SIP call as the case may be. > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Tuesday, February 06, 2001 9:10 PM > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > Hello Tom, > > > > Tom-PT Taylor wrote: > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > signalling > > > has reached an egress gateway, SIP has done its job -- additional > > > digits will not change call state. It is therefore > > reasonable to use > > > INFO to carry the additional digits. If we are talking > > ISUP-SIP, once > > > the destination UAS or a UAS in a B2BUA has been reached, the same > > > > consideration applies. > > > > > > > I do not agree with these two statements: > > > > The 1st INVITE (with just some digits) arrives to a vanilla SIP UA. > I > > will return a Not Found or a 484 Address incomplete. The > > subsequent INFO > > carrying more digits will be discarded. Thus, the PSTN to SIP > gateway > > will have to re issue a new INVITE with all the digits. > > Therefore, it is > > better to begin directly using er-INVITEs rather than INFO. > > > > Besides, I do not think that SIP is just a transport protocol that > > carries ISUP messages between two gateways. For that, we have > already > > SIGTRAN. SIP might be used to provide services, even when the > > call is a > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > state. And a > > SIP message with an incomplete to field does not carry complete > state. > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > based > > on the to field (called party number). That proxy would like to see > an > > updated to field, not just a to field that contains just some > digits. > > > > Best regards, > > > > Gonzalo > > > > > > > > -----Original Message----- > > > > From: Christer Holmberg > [mailto:christer.holmberg@lmf.ericsson.se] > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > To: Gonzalo Camarillo > > > > Cc: sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > been proposed > > > > earlier in this thread, so I assumed INFO would be used. The > > > > reason for > > > > the discussion from the beginning was that the overlap > signalling, > > > > according to the SIP-ISUP mapping draft, may not work > > very well, and > > > a > > > > solution using 18x responses and INFO messages, instead of 484 > and > > > > re-INVITEs, was proposed. > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > Hello Christer, > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > signalling section. > > > > > > > > > > Regards, > > > > > > > > > > Gonzalo > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > about calls > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > PSTN PHONE GW SIP SERVER SIP UAS > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > | <- 18x ------ | > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > | <- 200 (INFO) | > > > > > > | <- 18x ------ | > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > --> > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > the word 'proxy') > > > > > > must collect digits, sent from the PSTN side using > > > > overlap dialing, to > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > the digits > > > > > > after the INVITE has been sent. > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > be allowed to > > > > > > behave like this, or MUST it send 486s, and receive new > > > > INVITEs, until > > > > > > it is able to find the UAS? > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer Holmberg > > > > > > Ericsson Finland > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : > > Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 6 23:24:50 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10585 for ; Tue, 6 Feb 2001 23:24:49 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3645B44341; Tue, 6 Feb 2001 23:24:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 7B02844336 for ; Tue, 6 Feb 2001 23:23:30 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f174NTU25093; Tue, 6 Feb 2001 22:23:29 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f174NTJ28022; Tue, 6 Feb 2001 22:23:29 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id WAA07464; Tue, 6 Feb 2001 22:23:29 -0600 (CST) Received: (from eusadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id WAA13046; Tue, 6 Feb 2001 22:24:11 -0600 (CST) Message-Id: <200102070424.WAA13046@b04a24.exu.ericsson.se> To: sip-events@yahoogroups.com Reply-To: sip-events@yahoogroups.com From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] New SUBSCRIBE/NOTIFY draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 6 Feb 2001 22:24:11 -0600 (CST) Content-Transfer-Encoding: 7bit I have completed a version 03 of the SUBSCRIBE/NOTIFY draft. It has been submitted to the drafts editor for publication; until it becomes available, you may access it from: http://briefcase.yahoo.com/bc/adamr?c&.flabel=fld6&.src=bc&start=1 I apologise for not having the bandwidth to release this much earilier (considering that the interim meeting is in two days). As always, discussion of this draft should take place on the sip-events list, and not the general purpose SIP mailing list. Instuctions for accessing the sip-events mailing list are included in the draft itself. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 03:02:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26356 for ; Wed, 7 Feb 2001 03:02:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C6A064433A; Wed, 7 Feb 2001 03:02:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id E175144336 for ; Wed, 7 Feb 2001 03:01:04 -0500 (EST) 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 DAA28961; Wed, 7 Feb 2001 03:01:05 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id DAA00220; Wed, 7 Feb 2001 03:00:54 -0500 (EST) Message-ID: <3A812BDF.34465B60@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Rosen, Brian" Cc: Michael Thomas , "Drage, Keith (Keith)" , "'William Marshall'" , sip@lists.bell-labs.com Subject: Re: [SIP] Re: Location information References: <4FBEA8857476D311A03300204840E1CF03207AAF@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 07 Feb 2001 03:05:03 -0800 Content-Transfer-Encoding: 7bit I'm hoping that my 911 draft, either in its current form or a revised version, will address the 'find the emergency response center'. There are several parts to this question. > This is a protocol issue because there are three entities, > the UAC, the outgoing proxy, and the incoming proxy (or UAS) > at the emergency center. There has to be additional > specification that details how this works. The spec probably > needs some MUSTs. Some of the issues are: > How does the UA indicate to the outgoing proxy that > this is an emergency call? What are the minimum > requirements for caller identification and location > that must be delivered from the UAC to the Proxy Server? > > How does the outgoing proxy server identify "right" > emergency server? What is the minimum requirement for > caller identification and location that must be > delivered from the outgoing Proxy Server to the center? > Are there some minimum requirements for protocol options > the emergency center (or proxy or gateway) must implement > in order to provide the service needed? > > It's not entirely clear to me that this is an IETF matter, > but it HAS to be done, somewhere. > > Brian > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 05:09:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27369 for ; Wed, 7 Feb 2001 05:09:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 86AA6443D1; Wed, 7 Feb 2001 05:09:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (farley.cisco.com [171.71.153.30]) by lists.bell-labs.com (Postfix) with ESMTP id 126E3443D0 for ; Wed, 7 Feb 2001 05:08:07 -0500 (EST) Received: from tfu-pc (sbrand-dsl1.cisco.com [10.19.132.178]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id CAA08604; Wed, 7 Feb 2001 02:07:56 -0800 (PST) Message-Id: <200102071007.CAA08604@cisco.com> X-Sender: tfu@overnight.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 To: Gonzalo.Camarillo@lmf.ericsson.se From: Taichi Fu Subject: Re: [SIP] Overlap call setup Cc: Keith.Robinson@marconi.com, sip@lists.bell-labs.com In-Reply-To: <200102070904.BAA01065@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 07 Feb 2001 02:07:55 -0800 Hi, Gonzalo, Some comments on three points in discussion. (1) >The same way that nodes handling overlap signalling do not release the >call upon reception of a 484, they will not generate ACMs upon reception >of a 183 without SDP and without an ancapsulated ACM... we might want to >add this clarification to the draft. One potential issue of this is 183 without SDP can also be interpreted as PSTN gateway (and the media gateway it associates with) needs to play (local) ringback for a SIP to PSTN call toward PSTN side phone for the cases the ringback cannot come from the remote SIP phone. This can be resolved using a different Reason Phrase as Keith already indicated or another status code (186). To me it is better if a SIP status code always has unique semantics. (2) >Why would you want to limit a call to one call leg?? If I understand correctly, the issue of multiple call legs appear becauses of definition of call leg. In the case of multiple INVITE with different To headers with accumulated digits (as your sip-isup draft suggested), if we relax that definition slightly: two messages belong to the same call leg if the number in one To header is a prefix of the number in another and the other conditions of the definition are met. To limit its impact, we can allow this change only on a SIP device (proxy) that interfaces with a PSTN gateway if possible (for pure SIP networks, the rfc definition is still followed). This way CSeq is useful. I agree to have multiple call legs is fine in theory, but it is kind of against intuition to me and it might add some implementaion overhead too. (3) INFO or To header for subsequent digits I agree with your thoughts on using TO instead of INFO. However one obvious advantage of INFO is the saving of one message (ACK). Regards, Taichi >Tue, 06 Feb 2001 23:11:50 +0200 >Gonzalo Camarillo wrote: > >Hello, > >Thanks for the pointer. Answers inline: > >Keith Robinson wrote: >> >> Attached is an earlier posting I raised highlighting my concerns with some of >> the >> mechanisms outlined in the sip-isup document. This is the source of recent >> discussions. >> >> Regards, >> >> K. Robinson >> ---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 06/02/2001 16:42 >> --------------------------- >> >> 31/01/2001 16:34 >> Keith Robinson >> >> To: "Joshua Moloney" @ MCEXT >> cc: sip@lists.bell-labs.com@MCEXT >> >> Subject: Re: [SIP] Overlap call setup (Document link: Keith Robinson) >> >> I have recently been trying to get clarification on the implemenation of >> overlap sending; see attached for the discussion that has taken place >> so far. >> >> Certainly, the mechanism outlined (very sketchily) in RFC2543bis-02 sect 4.2.1 >> is fundamentally flawed. The Request-URI cannot be used to carry extra digits >> as the Record-Route/Route mechanism would end up overwriting the R-URI >> and therefore the subsequent digits would be lost. >> >> This then leads to the idea of using the TO field as described in >> sip-isup-00-00.txt; >> however, I have the following issues with the mechanisms described in this >> document : >> >> As the TO field is different on each subsequent INVITE, then it is a new call >> leg >> on an existing call id; RFC2543bis-02 sect. 11.5 does not state what a UAS >> should make of this. If you follow the logic in 11.5 you get to case (3), but >> here it only defines the behaviour if the TO and FROM fields match. >> > > >I do not see here a big problem for a UA. If the UA is a gateway, it >will handle the overlap signalling properly. If it is a pure SIP UA, it >will answer the first INVITE with a 484 (or "Not found response") and >process the second INVITE properly. > > >> The 484 sent backwards kills that call attempt (but not the state for that >> Call-Id - >> is this problematic for intermediate proxies ?) so subsequent INVITEs will >> actually be initial INVITEs. As these INVITEs must get to the same terminating >> UAS, >> the originating UAC will have to create a ROUTE header in an initial INVITE >> using , >> at least the CONTACT address from the 484. This implies the use of source >> routing, an >> issue that I don't believe has been fully resolved, and even if it is and >> becomes part >> of the base protocol some administrations may be reluctant to admit initial >> INVITEs >> which try to circumvent their routing policy, so may reject such INVITEs. >> > > >There was a big thread about source routing. This kind of source routing >is fine. Current proxies handle it properly. > >If a proxy sees an INVITe with a route header, it does not know if it is >the first INVITE or a re-INVITE. Thus, it will work properly. > >Even if the proxy stores state and it receives a INVITE (non re-INVITE) >with a route header, it should honor it. Otherwise, the proxy is not >robust. This allows a call stateful proxy to lose state, re-boot and >still be able to route requests properly. > > > >> Also on the above point, the CONTACT address in the 484 must have the same >> semantics as that in a 200 response so that a ROUTE header can be built; however >> RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in 4XX responses >> indicates a location where additional error information can be found. Indeed, in >> a recent >> thread entitled Announcements in SIP (401 & 407 Contact) J. Rosenberg believes >> that >> Record-Route does not make sense in any non-200 response. > >This contact header that is going to be used is the one present in the >183, not in the 484. This solves the problem of several IAMs al the same >time. If the answer was a 484, no IAM was sent. Thus, the next re-INVITE >with more digits can be very well handled by a different gateway. > > >> >> I would raise the question of whether the 484 response has any use in overlap >> sending >> (certainly in the case of ISUP) at all. > >484 responses are not very useful in this scenario, but they might be >useful in anothers (when a UA can ask the user to type more digits, for >instance). > > > If a node receives insufficient digits >> to decode than it will wait until it receives some more from the preceding node >> (or end of >> dialling timers mature). If the preceding node receives subsequent digits and >> end of dialling >> has not been detected then it will pass them on. If the 484 indicated the >> minimum number of >> digits before a decode could take place, then it would be useful in cutting down >> the number >> of subseqent messages sent. >> >> Indeed, isup-sip-00.txt does cover the mechanism where a 183 is sent, and not a >> 484. >> The case in point is covered in sect. 11.3 (Example of SIP bridging and overlap >> signalling); >> However, I have the following issues with this mechanism: >> >> As before relies on source routing. > >See comments above about this type of source routing. > >> >> Relies on proxies sending requests on new call legs but existing call-ids to the >> same >> downstream server; fine if you administer these proxies, what if you don't ? > >Why would you want to limit a call to one call leg?? > >> (Lots of >> wasted IAMs generated). > >Lots of IAMs????? > >The situation where more than one (typically two) IAMs are generated is >when the 183 arrived to the ingrees gateway after it sent the first >re-INVITE. This situation is ulikely to happen anyway, because if you >receive subsequent digits so fast (faster than a RTT), you should >implement a timer, and not send LOTS of SAMs anyway. > > >> The mechanism should not send 5 (subsequent INVITE) >> until it has received an acknowledgement (probably not 100) from the first. > >Again a timer configuration problem. You can, and your re-INVITE will >most likelt reach the same egrees gateway as the 1st one... but it might >reach a different one. Thus, the ingrees gateway should be aware of this >and be ready for canceling one of the TWO IAMs sent if this happen. > >But again, this situation is not common. > >> Alternatively, >> the Reason-Phrase could detail more specifically the exact progress of the call >> ("Decoding Address" >> in this case ?) so that the ACM is not generated unconditionally. >> >> Sect. 11.2 encourages gateways "to return a183 Session Progress with a Contact >> header as soon as they receive an INVITE that they are going to handle and might >> contain >> an incomplete number". Presumably this is to allow the UAC to build a ROUTE so >> that subsequent >> INVITEs get to the appropriate UAS. > >YES. > > > >> Sect 7.2.3 indicates that a node receiving a >> 183 prior to generating >> an ACM should generate an ACM. Applied together these rules may cause a prior >> node to never >> send on any subsequent digits and overlap sending would fail. > >The same way that nodes handling overlap signalling do not release the >call upon reception of a 484, they will not generate ACMs upon reception >of a 183 without SDP and without an ancapsulated ACM... we might want to >add this clarification to the draft. > >> >> I think an approach is required whereby subsequent digits are sent on the same >> call leg as the >> initial INVITE; either multiple INVITEs are allowed before 200 OK (already >> suggested by J. Rosenberg >> in a different context) > >Stacking requests is not a good solution in this case. It leads to a lot >of problems that we certainly want to avoid. > >> , or the INFO method is used. > >If INFO is used any vanilla SIP UA should implement INFO in order tor >receive calls/sessions that use overlap signalling. One of the most >important requirements for overlap signalling in SIP was that a vanilla >SIP UA could handle it. > > In both cases the TO field >> will have to remain the >> same so a new header (or message body type) is required to convey the digits. > >Again, we do not want to implement this in vanilla SIP UAs. > >Best regards, > >Gonzalo > >> Also, replace the 484 >> with, say, 18X indicating the minimum number of digits required, perhaps in the >> Reason-Phrase header. >> >> Regards, >> >> Keith Robinson. >> >> "Joshua Moloney" on 31/01/2001 10:49:33 >> >> >> >> >> >> >> >> To: sip@lists.bell-labs.com >> >> cc: (bcc: Keith Robinson/MAIN/MC1) >> >> >> >> Subject: [SIP] Overlap call setup >> >> >> Greetings, >> >> I would like to ask for clarification regarding the implementation of >> Overlap. >> >> I'll begin by referring to paragraph 3, section 6.1.2 of >> "draft-ietf-isup-sip-00": >> >> It is stated that INVITEs sent after the first one (containing extra digits >> in the 'To' field) are to be treated as new Call-Legs, seeing as the >> contents of their 'To' headers differ. As such, there is no relationship >> between their CSeq values. >> >> If this is the case, how is it possible to ensure correct digit ordering >> over an 'unreliable' transport layer like UDP? It would seem logical that >> the call originator _would_ use contiguous CSeq values, as it would be >> 'aware' of the fact that the INVITEs are for the same call. >> >> I believe that this issue was raised on the SIP list on 19 November 1999 by >> Gonzalo C and Jonathan R. The subject of the messages was "Re: Comments on >> draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of the exchange >> appeared to be an agreement that CSeq ordering should be employed. >> >> However, does this in any way imply that under such circumstances the >> INVITEs would/should belong to the same Call-Leg? After all, the concept of >> Overlap does not seem to 'fit in' with the concept behind multiple Call-Legs >> anyway. >> >> If there has been a change in thinking behind the problem, and the latest >> draft is correct, please could you explain how the ordering problem will be >> overcome. If not, perhaps the draft needs modification to include these >> considerations... >> >> Regards, >> >> Josh Moloney >> >> ------------------------------------------------------------------------ >> Name: att1.htm >> att1.htm Type: Hypertext Markup Language (text/html) >> Encoding: base64 >> Description: Internet HTML > >-- >Gonzalo Camarillo Phone : +358 9 299 33 71 >Oy L M Ericsson Ab Mobile: +358 40 702 35 35 >Telecom R&D Fax : +358 9 299 30 52 >FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com >Finland http://www.hut.fi/~gonzalo > > > > > > Previous message: [SIP] Overlap call setup > Next message: [SIP] Re: Location information > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 06:30:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27822 for ; Wed, 7 Feb 2001 06:30:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5923A443E5; Wed, 7 Feb 2001 06:30:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis22.marconicomms.com (cvis22.marconicomms.com [195.99.244.54]) by lists.bell-labs.com (Postfix) with ESMTP id C784E443D0 for ; Wed, 7 Feb 2001 06:29:00 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis22.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 7 Feb 2001 11:29:28 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id LAA07027; Wed, 7 Feb 2001 11:28:58 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569EC.003F086B ; Wed, 7 Feb 2001 11:28:29 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: bidulock@openss7.org Cc: Gonzalo.Camarillo@lmf.ericsson.se, christer.holmberg@lmf.ericsson.se, jmoloney@nortelnetworks.com, taylor@nortelnetworks.com, sip@lists.bell-labs.com Message-ID: <802569EC.003F07BA.00@marconicomms.com> Subject: Re: [SIP] Overlap call setup Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=OP8S4akFXtMLGPZEPSItqjHfu5O5RiGDySLN1ID0AogpBth4MRKoSnQw" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 7 Feb 2001 11:28:37 +0000 --0__=OP8S4akFXtMLGPZEPSItqjHfu5O5RiGDySLN1ID0AogpBth4MRKoSnQw Content-type: text/plain; charset=us-ascii Content-Disposition: inline Vendors could mandate that their SIP/PSTN gateways will always block up digits and do everything en bloc; thats fine. I was raising issues I had with the mechanism for supporting overlap sending if it was required to be performed because a particular administration wants to use overlap signalling. Regards, Keith. "Brian F. G. Bidulock" on 07/02/2001 06:49:08 Please respond to bidulock@openss7.org To: Keith Robinson/MAIN/MC1@MCMAIN cc: Gonzalo.Camarillo@lmf.ericsson.se, christer.holmberg@lmf.ericsson.se, jmoloney@nortelnetworks.com, taylor@nortelnetworks.com, sip@lists.bell-labs.com Subject: Re: [SIP] Overlap call setup --0__=OP8S4akFXtMLGPZEPSItqjHfu5O5RiGDySLN1ID0AogpBth4MRKoSnQw Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Keith, I hope that I don't seem too obtuse, but why are you wanting to process= overlap sending through SIP in the first place? Why doesn't your inter-working point merely collect all of the SAMs before it launches the INVITE? As I'm sure you are aware, overlap sending was just a way of getting better performance through an antiquated PSTN by overlapping digit analysis and routing with out-pusling. A terminating switch (or a switch at an inter-working point) should never SAM anyway! Where are you connecting your box in the PSTN that you are going to get overlap sending? Even if you do receive SAMs, what do you hope to achieve by attempting to process them through the SIP network? The only reason for including SAMs in ISUP was for backwards compatibility with CAS trunking. Even in the ISUP-SIP-ISUP case, the fact that you have an ISUP switch on either side means that the performance should be sufficient to do en bloc sending across the inter-working. As you know, the call cannot be connected until after the last digit is= sent, anyway. Overlap sending was a way to remove the digit out-pulsin= g delay from each CAS trunking hop and improve post-dial delay (a critica= l PSTN grade of service parameter). Unless you have an inter-working point (CAS trunk) on both sides of the connection (e.g., CAS-ISUP-SIP-I= SUP-CAS) and a lot of them at that (i.e. CAS-CAS-CAS-ISUP-SIP-ISUP-CAS-CAS-CAS)= there is no reason for overlap sending. Even still, in this arrangement, I don't see the SIP hop as being able to make routing decisions on the call (unless it is a proxy) until the entire number is received. Also, I would question the commercial viability of: CAS-CAS-CAS-ISUP-SIP-ISUP-CAS-CAS-CAS anyway. Could you provide a practical example of when this would be necessary and en bloc sending would not be sufficient at the inter-working point?= --Brian Keith Robinson wrote: (Tue, 06 Feb 2001 16:55:3= 9) > > > Attached is an earlier posting I raised highlighting my concerns with= some > of the mechanisms outlined in the sip-isup document. This is the sour= ce of > recent discussions. > > Regards, > > K. Robinson [snip] -- Brian F. G. Bidulock =A6 The reasonable man adapts himself to the =A6= bidulock@openss7.org =A6 world; the unreasonable one persists in =A6= http://www.openss7.org/ =A6 trying to adapt the world to himself. =A6= =A6 Therefore all progress depends on the =A6= =A6 unreasonable man. -- George Bernard Shaw =A6= = --0__=OP8S4akFXtMLGPZEPSItqjHfu5O5RiGDySLN1ID0AogpBth4MRKoSnQw-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 09:14:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29852 for ; Wed, 7 Feb 2001 09:14:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1CDB644340; Wed, 7 Feb 2001 09:14:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60]) by lists.bell-labs.com (Postfix) with ESMTP id 18F9744340 for ; Wed, 7 Feb 2001 09:13:13 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 7 Feb 2001 14:13:10 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id OAA02165; Wed, 7 Feb 2001 14:13:09 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569EC.004E113D ; Wed, 7 Feb 2001 14:12:42 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Gonzalo Camarillo Cc: christer.holmberg@lmf.ericsson.se, jmoloney@nortelnetworks.com, taylor@nortelnetworks.com, sip@lists.bell-labs.com, adam.roach@ericsson.com Message-ID: <802569EC.004E0F4E.00@marconicomms.com> Subject: Re: [SIP] Overlap call setup Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 7 Feb 2001 14:12:46 +0000 Thanks for the reply. A few points to clarify my thoughts: On the issue of source routing, I am aware of the discussion that took (is still taking ?) place. My concern is not of a technical nature (it will work), it is of an administrative nature; what if an administration does not want soucre routing occuring in its domain for security, accounting reasons etc. It IS possible for a proxy to determine that an INVITE is an initial INVITE; it looks in the TO tag field and finds it blank which means this MUST be an initial INVITE as opposed to a subsequent INVITE on a call leg its forgotten about. So, a proxy MAY be configured to reject these INVITEs while still being robust. Thats why I suggested a solution that would not rely on source routing. On the issue of vanilla UAs, I would not expect them to generate INFO; I would expect them to get back a 484 (or possibly 404) and so generate a new call attempt. Also, is it realistic that a SIP UA is going to send its digits in 'overlap mode' anyway ? Is it not more likely that a user is going to enter the complete digit string and then ask the UA to send this digit string; the digits either decode to an endpoint somewhere or translate to Number Unobtainable ? The full address (or that received so far) could be carried in the INFO message in a new header or a parameter of the TO URL. Having said this, I take your point about retaining state in a single SIP message. If it is mandated that SIP/PSTN gateways only ever signal en-bloc then the overlap sending issues are avoided. Clarification of when to generate the ACM, along the lines of your posting, would be useful. I am still concerned that RFC2543bis-02 defines (very sketchily) overlap sending in a way that is flawed (using Request-URI). This needs addressing by the SIP authors. Regards, K. Robinson Gonzalo Camarillo on 06/02/2001 21:11:50 To: Keith Robinson/MAIN/MC1@MCMAIN cc: christer.holmberg@lmf.ericsson.se, jmoloney@nortelnetworks.com, taylor@nortelnetworks.com, sip@lists.bell-labs.com, adam.roach@ericsson.com Subject: Re: [SIP] Overlap call setup Hello, Thanks for the pointer. Answers inline: Keith Robinson wrote: > > Attached is an earlier posting I raised highlighting my concerns with some of > the > mechanisms outlined in the sip-isup document. This is the source of recent > discussions. > > Regards, > > K. Robinson > ---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 06/02/2001 16:42 > --------------------------- > > 31/01/2001 16:34 > Keith Robinson > > To: "Joshua Moloney" @ MCEXT > cc: sip@lists.bell-labs.com@MCEXT > > Subject: Re: [SIP] Overlap call setup (Document link: Keith Robinson) > > I have recently been trying to get clarification on the implemenation of > overlap sending; see attached for the discussion that has taken place > so far. > > Certainly, the mechanism outlined (very sketchily) in RFC2543bis-02 sect 4.2.1 > is fundamentally flawed. The Request-URI cannot be used to carry extra digits > as the Record-Route/Route mechanism would end up overwriting the R-URI > and therefore the subsequent digits would be lost. > > This then leads to the idea of using the TO field as described in > sip-isup-00-00.txt; > however, I have the following issues with the mechanisms described in this > document : > > As the TO field is different on each subsequent INVITE, then it is a new call > leg > on an existing call id; RFC2543bis-02 sect. 11.5 does not state what a UAS > should make of this. If you follow the logic in 11.5 you get to case (3), but > here it only defines the behaviour if the TO and FROM fields match. > I do not see here a big problem for a UA. If the UA is a gateway, it will handle the overlap signalling properly. If it is a pure SIP UA, it will answer the first INVITE with a 484 (or "Not found response") and process the second INVITE properly. > The 484 sent backwards kills that call attempt (but not the state for that > Call-Id - > is this problematic for intermediate proxies ?) so subsequent INVITEs will > actually be initial INVITEs. As these INVITEs must get to the same terminating > UAS, > the originating UAC will have to create a ROUTE header in an initial INVITE > using , > at least the CONTACT address from the 484. This implies the use of source > routing, an > issue that I don't believe has been fully resolved, and even if it is and > becomes part > of the base protocol some administrations may be reluctant to admit initial > INVITEs > which try to circumvent their routing policy, so may reject such INVITEs. > There was a big thread about source routing. This kind of source routing is fine. Current proxies handle it properly. If a proxy sees an INVITe with a route header, it does not know if it is the first INVITE or a re-INVITE. Thus, it will work properly. Even if the proxy stores state and it receives a INVITE (non re-INVITE) with a route header, it should honor it. Otherwise, the proxy is not robust. This allows a call stateful proxy to lose state, re-boot and still be able to route requests properly. > Also on the above point, the CONTACT address in the 484 must have the same > semantics as that in a 200 response so that a ROUTE header can be built; however > RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in 4XX responses > indicates a location where additional error information can be found. Indeed, in > a recent > thread entitled Announcements in SIP (401 & 407 Contact) J. Rosenberg believes > that > Record-Route does not make sense in any non-200 response. This contact header that is going to be used is the one present in the 183, not in the 484. This solves the problem of several IAMs al the same time. If the answer was a 484, no IAM was sent. Thus, the next re-INVITE with more digits can be very well handled by a different gateway. > > I would raise the question of whether the 484 response has any use in overlap > sending > (certainly in the case of ISUP) at all. 484 responses are not very useful in this scenario, but they might be useful in anothers (when a UA can ask the user to type more digits, for instance). If a node receives insufficient digits > to decode than it will wait until it receives some more from the preceding node > (or end of > dialling timers mature). If the preceding node receives subsequent digits and > end of dialling > has not been detected then it will pass them on. If the 484 indicated the > minimum number of > digits before a decode could take place, then it would be useful in cutting down > the number > of subseqent messages sent. > > Indeed, isup-sip-00.txt does cover the mechanism where a 183 is sent, and not a > 484. > The case in point is covered in sect. 11.3 (Example of SIP bridging and overlap > signalling); > However, I have the following issues with this mechanism: > > As before relies on source routing. See comments above about this type of source routing. > > Relies on proxies sending requests on new call legs but existing call-ids to the > same > downstream server; fine if you administer these proxies, what if you don't ? Why would you want to limit a call to one call leg?? > (Lots of > wasted IAMs generated). Lots of IAMs????? The situation where more than one (typically two) IAMs are generated is when the 183 arrived to the ingrees gateway after it sent the first re-INVITE. This situation is ulikely to happen anyway, because if you receive subsequent digits so fast (faster than a RTT), you should implement a timer, and not send LOTS of SAMs anyway. > The mechanism should not send 5 (subsequent INVITE) > until it has received an acknowledgement (probably not 100) from the first. Again a timer configuration problem. You can, and your re-INVITE will most likelt reach the same egrees gateway as the 1st one... but it might reach a different one. Thus, the ingrees gateway should be aware of this and be ready for canceling one of the TWO IAMs sent if this happen. But again, this situation is not common. > Alternatively, > the Reason-Phrase could detail more specifically the exact progress of the call > ("Decoding Address" > in this case ?) so that the ACM is not generated unconditionally. > > Sect. 11.2 encourages gateways "to return a183 Session Progress with a Contact > header as soon as they receive an INVITE that they are going to handle and might > contain > an incomplete number". Presumably this is to allow the UAC to build a ROUTE so > that subsequent > INVITEs get to the appropriate UAS. YES. > Sect 7.2.3 indicates that a node receiving a > 183 prior to generating > an ACM should generate an ACM. Applied together these rules may cause a prior > node to never > send on any subsequent digits and overlap sending would fail. The same way that nodes handling overlap signalling do not release the call upon reception of a 484, they will not generate ACMs upon reception of a 183 without SDP and without an ancapsulated ACM... we might want to add this clarification to the draft. > > I think an approach is required whereby subsequent digits are sent on the same > call leg as the > initial INVITE; either multiple INVITEs are allowed before 200 OK (already > suggested by J. Rosenberg > in a different context) Stacking requests is not a good solution in this case. It leads to a lot of problems that we certainly want to avoid. > , or the INFO method is used. If INFO is used any vanilla SIP UA should implement INFO in order tor receive calls/sessions that use overlap signalling. One of the most important requirements for overlap signalling in SIP was that a vanilla SIP UA could handle it. In both cases the TO field > will have to remain the > same so a new header (or message body type) is required to convey the digits. Again, we do not want to implement this in vanilla SIP UAs. Best regards, Gonzalo > Also, replace the 484 > with, say, 18X indicating the minimum number of digits required, perhaps in the > Reason-Phrase header. > > Regards, > > Keith Robinson. > > "Joshua Moloney" on 31/01/2001 10:49:33 > > > > > > > > To: sip@lists.bell-labs.com > > cc: (bcc: Keith Robinson/MAIN/MC1) > > > > Subject: [SIP] Overlap call setup > > > Greetings, > > I would like to ask for clarification regarding the implementation of > Overlap. > > I'll begin by referring to paragraph 3, section 6.1.2 of > "draft-ietf-isup-sip-00": > > It is stated that INVITEs sent after the first one (containing extra digits > in the 'To' field) are to be treated as new Call-Legs, seeing as the > contents of their 'To' headers differ. As such, there is no relationship > between their CSeq values. > > If this is the case, how is it possible to ensure correct digit ordering > over an 'unreliable' transport layer like UDP? It would seem logical that > the call originator _would_ use contiguous CSeq values, as it would be > 'aware' of the fact that the INVITEs are for the same call. > > I believe that this issue was raised on the SIP list on 19 November 1999 by > Gonzalo C and Jonathan R. The subject of the messages was "Re: Comments on > draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of the exchange > appeared to be an agreement that CSeq ordering should be employed. > > However, does this in any way imply that under such circumstances the > INVITEs would/should belong to the same Call-Leg? After all, the concept of > Overlap does not seem to 'fit in' with the concept behind multiple Call-Legs > anyway. > > If there has been a change in thinking behind the problem, and the latest > draft is correct, please could you explain how the ordering problem will be > overcome. If not, perhaps the draft needs modification to include these > considerations... > > Regards, > > Josh Moloney > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64 > Description: Internet HTML -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 10:15:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01377 for ; Wed, 7 Feb 2001 10:15:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B44E344360; Wed, 7 Feb 2001 10:15:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id DDF5244352 for ; Wed, 7 Feb 2001 10:14:15 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id HAA00914 for ; Wed, 7 Feb 2001 07:14:18 -0800 (PST) Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with SMTP id AAJ76705; Wed, 7 Feb 2001 07:14:14 -0800 (PST) Message-Id: <4.1.20010206224255.020aa690@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: sip@lists.bell-labs.com From: Rohan Mahy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [SIP] More Info: Interim Meeting this Thursday and Friday Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 06 Feb 2001 22:59:37 -0800 Hi All, 1) First as a reminder: In the IETF anyone may attend any meeting. However, if you are not an active participant on the SIP mailing list, it is unlikely that you will be able to contribute, which is the point of the interim meetings. All meetings are working meetings, not trade shows or training events. If you are just interested in "lurking"--listening to the activities of the working group, then rest assured that, per IETF policy, detailed minutes of the meeting will be posted to the SIP mailing list. Even if you are not subscribed to this list, anyone can still access the archives. Seating will be tight but (barely) adequate based on the number of people who have emailed me. So! If you happen to live in Dallas and you haven't posted to the list in the last week or two, you should really ask yourself if you will be able to ACTIVELY CONTRIBUTE to our collective discussions before you show up. 2) That said, there is a minor change in the agenda. To make it easier for folks on the phone, let's start the conferencing discussion at 5:30 per the agenda below. 3) For folks calling in, please mute yourself immediately as soon as you join the bridge, and when you are finished talking. You can mute/unmute yourself once you are active on the conference bridge by pressing # 5 Doing this will dramatically improve the sound quality for others on the phone. Muting yourself with # 5 will also prevent you from sending cellular noise, key clicks, and/or hold music to the rest of the bridge. If you generate such noise, I will forcibly disconnect you from the conference. Those of you on the phone, please stay dialed in during breaks if you will continue to participate, as the bridge performs garbage collection on unused ports. I will be checking my pager (rmahy@epage.cisco.com) and my email (rohan@cisco.com) frequently during the meeting, so if there are problems, you may send me a text message describing the problem. Here is the dial in information. (I have reserved 10 ports) Thursday Feb 8th 0800 to 1300 Central Time call 408 525 6064 use meeting ID 7474383 (SIPIETF) Thursday Feb 8th 1300 to 1900 Central Time call 408 525 4445 use meeting ID 7474384 Friday Feb 9th 0800 to 1300 Central Time call 408 525 4445 use meeting ID 7474385 Friday Feb 9th 1300 to 1800 Central Time call 408 527 2663 use meeting ID 7474386 4) The Agenda: Note, this is a guideline only. We will be taking plenty of breaks. Those of you on the phone, please stay dialed in during breaks if you will continue to participate, as the bridge performs garbage collection on unused ports. I've asked the relevant folks shown to moderate discussions in each area. If you have a draft or idea you have presented on the list and want to present topics/issues, please contact them. Presentations should NOT be tutorial in nature and should list the issues/choices/differences at hand. Presentations must conform to the usual IETF rules (no logos, etc.). Thursday Feb 8th 08:00 Logisitics and Agenda Bashing Dean Willis 08:30 SUBSCRIBE/NOTIFY (split with presence docs, forking) Adam Roach 11:00 Call Control Models (3pcc vs. phonectl vs. peer-to-peer 3pcc) Rohan 12:30 Break for Lunch 13:30 REFER issues Robert Sparks 16:30 SIP device configuration Rick Dean 17:30 SIP conferencing Henning ~19:00 Stop for the night Friday Feb 9th 08:00 Base spec open issues: (Record Routing, Early Media, ...) Jonathan R 12:00 Break for Lunch (provided) 13:00 Firewall/NAT traversal Jonathan R 15:00 AAA requirements Jon Peterson ~17:00 Close > >Robert Sparks of Dynamicsoft has volunteered the use of a meeting room at > >their offices: > > 5100 Tennyson Parkway > > Suite 1200 > > Plano, Texas 75024 > > > >Directions are available at: > > > http://www.dynamicsoft.com/contact/dynamicsoft_locations.html#Texas Office thanks, -rohan _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 10:28:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01693 for ; Wed, 7 Feb 2001 10:28:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2316244374; Wed, 7 Feb 2001 10:28:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 2764E4436B for ; Wed, 7 Feb 2001 10:27:11 -0500 (EST) 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 f17FR9C09735; Wed, 7 Feb 2001 16:27:09 +0100 (MET) Received: from lmf.ericsson.se (EWUpcp003360pcs.sd.us.am.ericsson.se [142.133.141.69]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA23145; Wed, 7 Feb 2001 16:27:01 +0100 (MET) Message-ID: <3A816987.11AC8D6A@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Taichi Fu Cc: Keith.Robinson@marconi.com, sip@lists.bell-labs.com Subject: Re: [SIP] Overlap call setup References: <200102071007.CAA08604@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 07 Feb 2001 17:28:07 +0200 Content-Transfer-Encoding: 7bit Hello, Taichi Fu wrote: > > Hi, Gonzalo, > > Some comments on three points in discussion. > > (1) > >The same way that nodes handling overlap signalling do not release the > >call upon reception of a 484, they will not generate ACMs upon reception > >of a 183 without SDP and without an ancapsulated ACM... we might want to > >add this clarification to the draft. > > One potential issue of this is 183 without SDP can also be interpreted as PSTN gateway (and the media gateway it associates with) needs to play (local) ringback for a SIP to PSTN call toward PSTN side phone for the cases the ringback cannot come from the remote SIP phone. > This is wrong. If local alerting has to be performed the proper 1xx response is 180 Ringing. This has been pointed out several times in the mailing list. > This can be resolved using a different Reason Phrase as Keith already indicated or another status code (186). To me it is better if a SIP status code always has unique semantics. We discussed this idea also, and finally 183 seems OK for this (providing a contact header for the gateway handling the call). > > (2) > >Why would you want to limit a call to one call leg?? > If I understand correctly, the issue of multiple call legs appear becauses of definition of call leg. In the case of multiple INVITE with different To headers with accumulated digits (as your sip-isup draft suggested), if we relax that definition slightly: two messages belong to the same call leg if the number in one To header is a prefix of the number in another and the other conditions of the definition are met. To limit its impact, we can allow this change only on a SIP device (proxy) that interfaces with a PSTN gateway if possible (for pure SIP networks, the rfc definition is still followed). This way CSeq is useful. I do not think tha streching teh definition of a call leg for a particular interworking case is a good idea. I rather let the definition as it is. We do not need to change it. > > I agree to have multiple call legs is fine in theory, but it is kind of against intuition to me and it might add some implementaion overhead too. There are scenarios where a single call can have multiple call legs. Multiple call legs are present in SIP since the beginning. I do not think we should discuss them now. > > (3) INFO or To header for subsequent digits > I agree with your thoughts on using TO instead of INFO. However one obvious advantage of INFO is the saving of one message (ACK). If we take into account all the problems related to the use of INFO, a message saved is not a big gain. Regards, Gonzalo > > Regards, > Taichi > > >Tue, 06 Feb 2001 23:11:50 +0200 > >Gonzalo Camarillo wrote: > > > >Hello, > > > >Thanks for the pointer. Answers inline: > > > >Keith Robinson wrote: > >> > >> Attached is an earlier posting I raised highlighting my concerns with some of > >> the > >> mechanisms outlined in the sip-isup document. This is the source of recent > >> discussions. > >> > >> Regards, > >> > >> K. Robinson > >> ---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 06/02/2001 16:42 > >> --------------------------- > >> > >> 31/01/2001 16:34 > >> Keith Robinson > >> > >> To: "Joshua Moloney" @ MCEXT > >> cc: sip@lists.bell-labs.com@MCEXT > >> > >> Subject: Re: [SIP] Overlap call setup (Document link: Keith Robinson) > >> > >> I have recently been trying to get clarification on the implemenation of > >> overlap sending; see attached for the discussion that has taken place > >> so far. > >> > >> Certainly, the mechanism outlined (very sketchily) in RFC2543bis-02 sect 4.2.1 > >> is fundamentally flawed. The Request-URI cannot be used to carry extra digits > >> as the Record-Route/Route mechanism would end up overwriting the R-URI > >> and therefore the subsequent digits would be lost. > >> > >> This then leads to the idea of using the TO field as described in > >> sip-isup-00-00.txt; > >> however, I have the following issues with the mechanisms described in this > >> document : > >> > >> As the TO field is different on each subsequent INVITE, then it is a new call > >> leg > >> on an existing call id; RFC2543bis-02 sect. 11.5 does not state what a UAS > >> should make of this. If you follow the logic in 11.5 you get to case (3), but > >> here it only defines the behaviour if the TO and FROM fields match. > >> > > > > > >I do not see here a big problem for a UA. If the UA is a gateway, it > >will handle the overlap signalling properly. If it is a pure SIP UA, it > >will answer the first INVITE with a 484 (or "Not found response") and > >process the second INVITE properly. > > > > > >> The 484 sent backwards kills that call attempt (but not the state for that > >> Call-Id - > >> is this problematic for intermediate proxies ?) so subsequent INVITEs will > >> actually be initial INVITEs. As these INVITEs must get to the same terminating > >> UAS, > >> the originating UAC will have to create a ROUTE header in an initial INVITE > >> using , > >> at least the CONTACT address from the 484. This implies the use of source > >> routing, an > >> issue that I don't believe has been fully resolved, and even if it is and > >> becomes part > >> of the base protocol some administrations may be reluctant to admit initial > >> INVITEs > >> which try to circumvent their routing policy, so may reject such INVITEs. > >> > > > > > >There was a big thread about source routing. This kind of source routing > >is fine. Current proxies handle it properly. > > > >If a proxy sees an INVITe with a route header, it does not know if it is > >the first INVITE or a re-INVITE. Thus, it will work properly. > > > >Even if the proxy stores state and it receives a INVITE (non re-INVITE) > >with a route header, it should honor it. Otherwise, the proxy is not > >robust. This allows a call stateful proxy to lose state, re-boot and > >still be able to route requests properly. > > > > > > > >> Also on the above point, the CONTACT address in the 484 must have the same > >> semantics as that in a 200 response so that a ROUTE header can be built; however > >> RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in 4XX responses > >> indicates a location where additional error information can be found. Indeed, in > >> a recent > >> thread entitled Announcements in SIP (401 & 407 Contact) J. Rosenberg believes > >> that > >> Record-Route does not make sense in any non-200 response. > > > >This contact header that is going to be used is the one present in the > >183, not in the 484. This solves the problem of several IAMs al the same > >time. If the answer was a 484, no IAM was sent. Thus, the next re-INVITE > >with more digits can be very well handled by a different gateway. > > > > > >> > >> I would raise the question of whether the 484 response has any use in overlap > >> sending > >> (certainly in the case of ISUP) at all. > > > >484 responses are not very useful in this scenario, but they might be > >useful in anothers (when a UA can ask the user to type more digits, for > >instance). > > > > > > If a node receives insufficient digits > >> to decode than it will wait until it receives some more from the preceding node > >> (or end of > >> dialling timers mature). If the preceding node receives subsequent digits and > >> end of dialling > >> has not been detected then it will pass them on. If the 484 indicated the > >> minimum number of > >> digits before a decode could take place, then it would be useful in cutting down > >> the number > >> of subseqent messages sent. > >> > >> Indeed, isup-sip-00.txt does cover the mechanism where a 183 is sent, and not a > >> 484. > >> The case in point is covered in sect. 11.3 (Example of SIP bridging and overlap > >> signalling); > >> However, I have the following issues with this mechanism: > >> > >> As before relies on source routing. > > > >See comments above about this type of source routing. > > > >> > >> Relies on proxies sending requests on new call legs but existing call-ids to the > >> same > >> downstream server; fine if you administer these proxies, what if you don't ? > > > >Why would you want to limit a call to one call leg?? > > > >> (Lots of > >> wasted IAMs generated). > > > >Lots of IAMs????? > > > >The situation where more than one (typically two) IAMs are generated is > >when the 183 arrived to the ingrees gateway after it sent the first > >re-INVITE. This situation is ulikely to happen anyway, because if you > >receive subsequent digits so fast (faster than a RTT), you should > >implement a timer, and not send LOTS of SAMs anyway. > > > > > >> The mechanism should not send 5 (subsequent INVITE) > >> until it has received an acknowledgement (probably not 100) from the first. > > > >Again a timer configuration problem. You can, and your re-INVITE will > >most likelt reach the same egrees gateway as the 1st one... but it might > >reach a different one. Thus, the ingrees gateway should be aware of this > >and be ready for canceling one of the TWO IAMs sent if this happen. > > > >But again, this situation is not common. > > > >> Alternatively, > >> the Reason-Phrase could detail more specifically the exact progress of the call > >> ("Decoding Address" > >> in this case ?) so that the ACM is not generated unconditionally. > >> > >> Sect. 11.2 encourages gateways "to return a183 Session Progress with a Contact > >> header as soon as they receive an INVITE that they are going to handle and might > >> contain > >> an incomplete number". Presumably this is to allow the UAC to build a ROUTE so > >> that subsequent > >> INVITEs get to the appropriate UAS. > > > >YES. > > > > > > > >> Sect 7.2.3 indicates that a node receiving a > >> 183 prior to generating > >> an ACM should generate an ACM. Applied together these rules may cause a prior > >> node to never > >> send on any subsequent digits and overlap sending would fail. > > > >The same way that nodes handling overlap signalling do not release the > >call upon reception of a 484, they will not generate ACMs upon reception > >of a 183 without SDP and without an ancapsulated ACM... we might want to > >add this clarification to the draft. > > > >> > >> I think an approach is required whereby subsequent digits are sent on the same > >> call leg as the > >> initial INVITE; either multiple INVITEs are allowed before 200 OK (already > >> suggested by J. Rosenberg > >> in a different context) > > > >Stacking requests is not a good solution in this case. It leads to a lot > >of problems that we certainly want to avoid. > > > >> , or the INFO method is used. > > > >If INFO is used any vanilla SIP UA should implement INFO in order tor > >receive calls/sessions that use overlap signalling. One of the most > >important requirements for overlap signalling in SIP was that a vanilla > >SIP UA could handle it. > > > > In both cases the TO field > >> will have to remain the > >> same so a new header (or message body type) is required to convey the digits. > > > >Again, we do not want to implement this in vanilla SIP UAs. > > > >Best regards, > > > >Gonzalo > > > >> Also, replace the 484 > >> with, say, 18X indicating the minimum number of digits required, perhaps in the > >> Reason-Phrase header. > >> > >> Regards, > >> > >> Keith Robinson. > >> > >> "Joshua Moloney" on 31/01/2001 10:49:33 > >> > >> > >> > >> > >> > >> > >> > >> To: sip@lists.bell-labs.com > >> > >> cc: (bcc: Keith Robinson/MAIN/MC1) > >> > >> > >> > >> Subject: [SIP] Overlap call setup > >> > >> > >> Greetings, > >> > >> I would like to ask for clarification regarding the implementation of > >> Overlap. > >> > >> I'll begin by referring to paragraph 3, section 6.1.2 of > >> "draft-ietf-isup-sip-00": > >> > >> It is stated that INVITEs sent after the first one (containing extra digits > >> in the 'To' field) are to be treated as new Call-Legs, seeing as the > >> contents of their 'To' headers differ. As such, there is no relationship > >> between their CSeq values. > >> > >> If this is the case, how is it possible to ensure correct digit ordering > >> over an 'unreliable' transport layer like UDP? It would seem logical that > >> the call originator _would_ use contiguous CSeq values, as it would be > >> 'aware' of the fact that the INVITEs are for the same call. > >> > >> I believe that this issue was raised on the SIP list on 19 November 1999 by > >> Gonzalo C and Jonathan R. The subject of the messages was "Re: Comments on > >> draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of the exchange > >> appeared to be an agreement that CSeq ordering should be employed. > >> > >> However, does this in any way imply that under such circumstances the > >> INVITEs would/should belong to the same Call-Leg? After all, the concept of > >> Overlap does not seem to 'fit in' with the concept behind multiple Call-Legs > >> anyway. > >> > >> If there has been a change in thinking behind the problem, and the latest > >> draft is correct, please could you explain how the ordering problem will be > >> overcome. If not, perhaps the draft needs modification to include these > >> considerations... > >> > >> Regards, > >> > >> Josh Moloney > >> > >> ------------------------------------------------------------------------ > >> Name: att1.htm > >> att1.htm Type: Hypertext Markup Language (text/html) > >> Encoding: base64 > >> Description: Internet HTML > > > >-- > >Gonzalo Camarillo Phone : +358 9 299 33 71 > >Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > >Telecom R&D Fax : +358 9 299 30 52 > >FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > >Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > Previous message: [SIP] Overlap call setup > > Next message: [SIP] Re: Location information > > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 10:33:32 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01812 for ; Wed, 7 Feb 2001 10:33:32 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 90AE9443BE; Wed, 7 Feb 2001 10:30:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 1C50A443B9 for ; Wed, 7 Feb 2001 10:29:36 -0500 (EST) 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 f17FTYC12349; Wed, 7 Feb 2001 16:29:34 +0100 (MET) Received: from lmf.ericsson.se (EWUpcp003360pcs.sd.us.am.ericsson.se [142.133.141.69]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA23245; Wed, 7 Feb 2001 16:29:22 +0100 (MET) Message-ID: <3A816A14.5BE2BA6D@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: bidulock@openss7.org, christer.holmberg@lmf.ericsson.se, jmoloney@nortelnetworks.com, taylor@nortelnetworks.com, sip@lists.bell-labs.com Subject: Re: [SIP] Overlap call setup References: <802569EC.003F07BA.00@marconicomms.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 07 Feb 2001 17:30:28 +0200 Content-Transfer-Encoding: 8bit Hello, The idea of using always en bloc was present in the first version of the draft. However, when I presented in DC (some IETFs ago), folks wanted overlap signalling to be present also in the draft. That's why we developed such a mechanism. Anyway, I agree that it will not be used a lot. However, it is good to discuss the open issues related to the mechanism to try to resolve all of them. Regards, Gonzalo Keith Robinson wrote: > > Vendors could mandate that their SIP/PSTN gateways will always block up digits > and do everything en bloc; thats fine. > > I was raising issues I had with the mechanism for supporting overlap sending if > it was required to be performed because a particular administration wants to > use overlap signalling. > > Regards, > > Keith. > > "Brian F. G. Bidulock" on 07/02/2001 06:49:08 > > Please respond to bidulock@openss7.org > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > cc: Gonzalo.Camarillo@lmf.ericsson.se, > christer.holmberg@lmf.ericsson.se, > jmoloney@nortelnetworks.com, > taylor@nortelnetworks.com, sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Overlap call setup > > > ------------------------------------------------------------------------ > > Keith, > > I hope that I don't seem too obtuse, but why are you wanting to process > overlap sending through SIP in the first place? Why doesn't your > inter-working point merely collect all of the SAMs before it launches > the INVITE? > > As I'm sure you are aware, overlap sending was just a way of getting > better performance through an antiquated PSTN by overlapping digit > analysis and routing with out-pusling. A terminating switch (or a > switch at an inter-working point) should never SAM anyway! Where are > you connecting your box in the PSTN that you are going to get overlap > sending? > > Even if you do receive SAMs, what do you hope to achieve by attempting > to process them through the SIP network? > > The only reason for including SAMs in ISUP was for backwards > compatibility with CAS trunking. Even in the ISUP-SIP-ISUP case, the > fact that you have an ISUP switch on either side means that the > performance should be sufficient to do en bloc sending across the > inter-working. > > As you know, the call cannot be connected until after the last digit is > sent, anyway. Overlap sending was a way to remove the digit out-pulsing > delay from each CAS trunking hop and improve post-dial delay (a critical > PSTN grade of service parameter). Unless you have an inter-working > point (CAS trunk) on both sides of the connection (e.g., CAS-ISUP-SIP-ISUP-CAS) > and a lot of them at that (i.e. CAS-CAS-CAS-ISUP-SIP-ISUP-CAS-CAS-CAS) > there is no reason for overlap sending. > > Even still, in this arrangement, I don't see the SIP hop as being able > to make routing decisions on the call (unless it is a proxy) until the > entire number is received. Also, I would question the commercial > viability of: > CAS-CAS-CAS-ISUP-SIP-ISUP-CAS-CAS-CAS > > anyway. > > Could you provide a practical example of when this would be necessary > and en bloc sending would not be sufficient at the inter-working point? > > --Brian > > Keith Robinson wrote: (Tue, 06 Feb 2001 16:55:39) > > > > > > Attached is an earlier posting I raised highlighting my concerns with some > > of the mechanisms outlined in the sip-isup document. This is the source of > > recent discussions. > > > > Regards, > > > > K. Robinson > [snip] > > -- > Brian F. G. Bidulock Ś The reasonable man adapts himself to the Ś > bidulock@openss7.org Ś world; the unreasonable one persists in Ś > http://www.openss7.org/ Ś trying to adapt the world to himself. Ś > Ś Therefore all progress depends on the Ś > Ś unreasonable man. -- George Bernard Shaw Ś -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 11:18:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02706 for ; Wed, 7 Feb 2001 11:18:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6083D4436A; Wed, 7 Feb 2001 11:18:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id 5586444369 for ; Wed, 7 Feb 2001 11:17:21 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Wed, 7 Feb 2001 16:16:35 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1PPRMQ1P>; Wed, 7 Feb 2001 16:16:34 -0000 Message-ID: From: "Mark Watson" To: "'Gonzalo Camarillo'" , "Tom-PT Taylor" Cc: Christer Holmberg , sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09121.321466C0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 7 Feb 2001 16:15:32 -0000 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_01C09121.321466C0 Content-Type: text/plain; charset="iso-8859-1" Gonzalo, I thought at the beginning of this thread Keith Robinson identified a number of fundamental flaws with the overlap mechanism in the draft. If I understood rightly, these were: 1) UAS behaviour on receiving multiple INVITES for new Call Legs of the same Call, but with different FROM and TO fields is undefined in the RFC 2) The UAC must use source routing to ensure that all these INVITES make it to the same UAS 3) 183 is used to transport the CONTACT of the UAS to UAC, but 183 may also cause a backwards ACM to be generated, cutting off further digits. I may have mis-understood some of the points slightly, and there may be more. Overlap is a feature of the legacy PSTN - I don't think we need to kill ourselves making SIP support overlap in some kind of native way. Rather, a simple mechanism which allows consenting UAs to negotiate the direct exchange of overlap digits over a single Call Leg would be much better. It's not the same as SAMs because we can negotiate this mechanism to be used only once the UAS has been found. Until this point, calls without enough digits are killed right away with 484s. The price we pay for this is that intermediate proxies may not have access to the full Called Party Number - but a proxy that needs this, that wants to offer service on overlap calls, can always sniff the overlap digits as they go past. Regards, Mark Watson Nortel Networks > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 07 February 2001 02:52 > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: Christer Holmberg; sip@lists.bell-labs.com > Subject: Re: [SIP] Operlap dialing within a SIP network > > > Hi Tom, > > Still I want to have full state in every SIP message. If the call is > addresed to the phone number 1234, I want to have a to field that says > 1234. I do not care if there is a leg routed thru the PSTN and another > thru SIP. > > Carrying full state is one of the beauties of SIP. If we begin using > INFO for this, it would be the same as using SAMs. Differen names, the > same thing... I do not want to re-create ISUP using SIP. I > believe that > if the session has a destination, it should be present in the > to field. > > Again, if a proxy is providing services for this particular call, it > will want to see the called party number in order to trigger > the proper > service. This is a very good reason for updating the to field > every time > we have more digits. > > I like to use SIP between two gateways because it is possible > to provide > SIP services for a PSTN to PSTN call. If all we want to do is > finding a > egrees gateway, we would probably want to use other protocols (TRIP & > SIGTRAN for instance). > > Regards, > > Gonzalo > > Tom-PT Taylor wrote: > > > > Sorry, we're talking past each other. The premise of my > statements is > > that an INVITE has reached a UAS which has accepted it. It follows > > that the UAS did not send back a 484, but rather an interim > response. > > IF more digits come along, the INFO method is there to carry them. > > They do not affect the SIP call state; they are used beyond the UAS, > > either in a PSTN call or in another SIP call as the case may be. > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > Hello Tom, > > > > > > Tom-PT Taylor wrote: > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > signalling > > > > has reached an egress gateway, SIP has done its job -- > additional > > > > digits will not change call state. It is therefore > > > reasonable to use > > > > INFO to carry the additional digits. If we are talking > > > ISUP-SIP, once > > > > the destination UAS or a UAS in a B2BUA has been > reached, the same > > > > > > consideration applies. > > > > > > > > > > I do not agree with these two statements: > > > > > > The 1st INVITE (with just some digits) arrives to a > vanilla SIP UA. > > I > > > will return a Not Found or a 484 Address incomplete. The > > > subsequent INFO > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > gateway > > > will have to re issue a new INVITE with all the digits. > > > Therefore, it is > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > carries ISUP messages between two gateways. For that, we have > > already > > > SIGTRAN. SIP might be used to provide services, even when the > > > call is a > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > state. And a > > > SIP message with an incomplete to field does not carry complete > > state. > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > based > > > on the to field (called party number). That proxy would > like to see > > an > > > updated to field, not just a to field that contains just some > > digits. > > > > > > Best regards, > > > > > > Gonzalo > > > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > To: Gonzalo Camarillo > > > > > Cc: sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > been proposed > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > reason for > > > > > the discussion from the beginning was that the overlap > > signalling, > > > > > according to the SIP-ISUP mapping draft, may not work > > > very well, and > > > > a > > > > > solution using 18x responses and INFO messages, instead of 484 > > and > > > > > re-INVITEs, was proposed. > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > signalling section. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > about calls > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > SIP UAS > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > | <- 18x ------ | > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > | <- 200 (INFO) | > > > > > > > | <- 18x ------ | > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > --> > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > the word 'proxy') > > > > > > > must collect digits, sent from the PSTN side using > > > > > overlap dialing, to > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > the digits > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > be allowed to > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > INVITEs, until > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer Holmberg > > > > > > > Ericsson Finland > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : > > > Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > ------_=_NextPart_001_01C09121.321466C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Operlap dialing within a SIP network

Gonzalo,

I thought at the beginning of this thread Keith = Robinson identified a number of fundamental flaws with the overlap = mechanism in the draft. If I understood rightly, these were:

1) UAS behaviour on receiving multiple INVITES for = new Call Legs of the same Call, but with different FROM and TO fields = is undefined in the RFC

2) The UAC must use source routing to ensure that all = these INVITES make it to the same UAS
3) 183 is used to transport the CONTACT of the UAS = to UAC, but 183 may also cause a backwards ACM to be generated, cutting = off further digits.

I may have mis-understood some of the points = slightly, and there may be more.

Overlap is a feature of the legacy PSTN - I don't = think we need to kill ourselves making SIP support overlap in some kind = of native way. Rather, a simple mechanism which allows consenting UAs = to negotiate the direct exchange of overlap digits over a single Call = Leg would be much better. It's not the same as SAMs because we can = negotiate this mechanism to be used only once the UAS has been found. = Until this point, calls without enough digits are killed right away = with 484s.

The price we pay for this is that intermediate = proxies may not have access to the full Called Party Number - but a = proxy that needs this, that wants to offer service on overlap calls, = can always sniff the overlap digits as they go past.

Regards,

Mark Watson
Nortel Networks




> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: 07 February 2001 02:52
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: Christer Holmberg; = sip@lists.bell-labs.com
> Subject: Re: [SIP] Operlap dialing within a SIP = network
>
>
> Hi Tom,
>
> Still I want to have full state in every SIP = message. If the call is
> addresed to the phone number 1234, I want to = have a to field that says
> 1234. I do not care if there is a leg routed = thru the PSTN and another
> thru SIP.
>
> Carrying full state is one of the beauties of = SIP. If we begin using
> INFO for this, it would be the same as using = SAMs. Differen names, the
> same thing... I do not want to re-create ISUP = using SIP. I
> believe that
> if the session has a destination, it should be = present in the
> to field.
>
> Again, if a proxy is providing services for = this particular call, it
> will want to see the called party number in = order to trigger
> the proper
> service. This is a very good reason for = updating the to field
> every time
> we have more digits.
>
> I like to use SIP between two gateways because = it is possible
> to provide
> SIP services for a PSTN to PSTN call. If all we = want to do is
> finding a
> egrees gateway, we would probably want to use = other protocols (TRIP &
> SIGTRAN for instance).
>
> Regards,
>
> Gonzalo
>
> Tom-PT Taylor wrote:
> >
> > Sorry, we're talking past each = other.  The premise of my
> statements is
> > that an INVITE has reached a UAS which has = accepted it.  It follows
> > that the UAS did not send back a 484, but = rather an interim
> response.
> > IF more digits come along, the INFO method = is there to carry them.
> > They do not affect the SIP call state; = they are used beyond the UAS,
> > either in a PSTN call or in another SIP = call as the case may be.
> >
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > Sent: Tuesday, February 06, 2001 9:10 = PM
> > > To: Taylor, Tom-PT = [NORSE:B901:EXCH]
> > > Cc: Christer Holmberg; = sip@lists.bell-labs.com
> > > Subject: Re: [SIP] Operlap dialing = within a SIP network
> > >
> > >
> > > Hello Tom,
> > >
> > > Tom-PT Taylor wrote:
> > > >
> > > > Just to re-hash, in the = ISUP-SIP-ISUP context, once call
> > signalling
> > > > has reached an egress gateway, = SIP has done its job --
> additional
> > > > digits will not change call = state.  It is therefore
> > > reasonable to use
> > > > INFO to carry the additional = digits.  If we are talking
> > > ISUP-SIP, once
> > > > the destination UAS or a UAS in = a B2BUA has been
> reached, the same
> >
> > > > consideration applies.
> > > >
> > >
> > > I do not agree with these two = statements:
> > >
> > > The 1st INVITE (with just some = digits) arrives to a
> vanilla SIP UA.
> > I
> > > will return a Not Found or a 484 = Address incomplete. The
> > > subsequent INFO
> > > carrying more digits will be = discarded. Thus, the PSTN to SIP
> > gateway
> > > will have to re issue a new INVITE = with all the digits.
> > > Therefore, it is
> > > better to begin directly using = er-INVITEs rather than INFO.
> > >
> > > Besides, I do not think that SIP is = just a transport protocol that
> > > carries ISUP messages between two = gateways. For that, we have
> > already
> > > SIGTRAN. SIP might be used to provide = services, even when the
> > > call is a
> > > PSTN-SIP-PSTN call. Thus, SIP = messages MUST carry complete
> > > state. And a
> > > SIP message with an incomplete to = field does not carry complete
> > state.
> > > What if my SIP proxy provides a = service for a PSTN-SIP-PSTN call
> > based
> > > on the to field (called party = number). That proxy would
> like to see
> > an
> > > updated to field, not just a to field = that contains just some
> > digits.
> > >
> > > Best regards,
> > >
> > > Gonzalo
> > >
> > >
> > > > > -----Original = Message-----
> > > > > From: Christer = Holmberg
> > [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > > > > Sent: Tuesday, February 06, = 2001 1:15 AM
> > > > > To: Gonzalo = Camarillo
> > > > > Cc: = sip@lists.bell-labs.com
> > > > > Subject: Re: [SIP] Operlap = dialing within a SIP network
> > > > >
> > > > >
> > > > >
> > > > > Hi Gonzalo,
> > > > >
> > > > > I didn't say I am going to = use INFO, but that is what has
> > > > > been proposed
> > > > > earlier in this thread, so = I assumed INFO would be used. The
> > > > > reason for
> > > > > the discussion from the = beginning was that the overlap
> > signalling,
> > > > > according to the SIP-ISUP = mapping draft, may not work
> > > very well, and
> > > > a
> > > > > solution using 18x = responses and INFO messages, instead of 484
> > and
> > > > > re-INVITEs, was = proposed.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Christer Holmberg
> > > > > Ericsson Finland
> > > > >
> > > > >
> > > > >
> > > > > Gonzalo Camarillo = wrote:
> > > > > >
> > > > > > Hello Christer,
> > > > > >
> > > > > > Why are you using INFO = for sending extra digits?
> > > > > >
> > > > > > Please, check the = SIP-ISUP mapping draft, overlap
> > > > > signalling section.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Gonzalo
> > > > > >
> > > > > > Christer Holmberg = wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > The discussion = about overlap dialing has been pretty much
> > > > > about calls
> > > > > > > from SIP to PSTN, = or PSTN-SIP-PSTN.
> > > > > > >
> > > > > > > Consider the = following scenario.
> > > > > > >
> > > > > > > PSTN = PHONE           &= nbsp; GW           = SIP SERVER   
>   SIP UAS
> > > > > > >
> = -----------------------------------------------------------
> > > > > > >
> > > > > > > --- 1 = --->    -- IAM -> | -- INVITE -->  = |
> > > > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > --- 2 = --->    -- SAM -> | -- INFO ---->  = |
> > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |
> > > > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > --- 3 = --->    -- SAM -> | -- INFO ---->  = |
> > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |   -- INVITE
> > > > > > > -->
> > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INVITE)|   <- 200 ------
> > > > > > >
> > > > > > > In this case, the = SIP server (note that I am not using
> > > > > the word 'proxy')
> > > > > > > must collect = digits, sent from the PSTN side using
> > > > > overlap dialing, to
> > > > > > > be able to find = the SIP UAS, and INFO is used to provide
> > > > > the digits
> > > > > > > after the INVITE = has been sent.
> > > > > > >
> > > > > > > My question is, = should a SIP server (proxy, if you like)
> > > > > be allowed to
> > > > > > > behave like this, = or MUST it send 486s, and receive new
> > > > > INVITEs, until
> > > > > > > it is able to = find the UAS?
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Christer = Holmberg
> > > > > > > Ericsson = Finland
> > > > > >
> > > > > > --
> > > > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > > > FIN-02420 = Jorvas          Email = :
> > > Gonzalo.Camarillo@ericsson.com
> > > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > >
> > >
> > > --
> > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > >
>
> --
> Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> = Finland           = ;        http://www.hut.fi/= ~gonzalo
>
> = _______________________________________________
> This list is for continuing development of the = SIP protocol.
> The sip-implementer's list is the place to = discuss implementation,
> and to receive advice on understanding existing = sip.
> To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the = body.
>

------_=_NextPart_001_01C09121.321466C0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 11:23:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02826 for ; Wed, 7 Feb 2001 11:23:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 247E0443C9; Wed, 7 Feb 2001 11:23:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53]) by lists.bell-labs.com (Postfix) with ESMTP id 1043A443B8 for ; Wed, 7 Feb 2001 11:22:32 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 7 Feb 2001 14:19:35 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id OAA04070; Wed, 7 Feb 2001 14:20:04 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569EC.004EB570 ; Wed, 7 Feb 2001 14:19:42 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Gonzalo Camarillo Cc: christer.holmberg@lmf.ericsson.se, jmoloney@nortelnetworks.com, taylor@nortelnetworks.com, sip@lists.bell-labs.com, adam.roach@ericsson.com Message-ID: <802569EC.004EB3FF.00@marconicomms.com> Subject: Re: [SIP] Overlap call setup Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 7 Feb 2001 14:19:48 +0000 I forgot to mention that I would not expect vanilla UAs to receive INFO either. The digits received in the INITIAL would not address any endpoint supported by the receiving UA so it generate 484/404. The preceding node would then issue a new call attempt. Regards, K .Robinson ---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 07/02/2001 14:14 --------------------------- 07/02/2001 14:12 Keith Robinson To: Gonzalo Camarillo @ MCEXT cc: christer.holmberg@lmf.ericsson.se@MCEXT, jmoloney@nortelnetworks.com@MCEXT, taylor@nortelnetworks.com@MCEXT, sip@lists.bell-labs.com@MCEXT, adam.roach@ericsson.com@MCEXT Subject: Re: [SIP] Overlap call setup (Document link: Keith Robinson) Thanks for the reply. A few points to clarify my thoughts: On the issue of source routing, I am aware of the discussion that took (is still taking ?) place. My concern is not of a technical nature (it will work), it is of an administrative nature; what if an administration does not want soucre routing occuring in its domain for security, accounting reasons etc. It IS possible for a proxy to determine that an INVITE is an initial INVITE; it looks in the TO tag field and finds it blank which means this MUST be an initial INVITE as opposed to a subsequent INVITE on a call leg its forgotten about. So, a proxy MAY be configured to reject these INVITEs while still being robust. Thats why I suggested a solution that would not rely on source routing. On the issue of vanilla UAs, I would not expect them to generate INFO; I would expect them to get back a 484 (or possibly 404) and so generate a new call attempt. Also, is it realistic that a SIP UA is going to send its digits in 'overlap mode' anyway ? Is it not more likely that a user is going to enter the complete digit string and then ask the UA to send this digit string; the digits either decode to an endpoint somewhere or translate to Number Unobtainable ? The full address (or that received so far) could be carried in the INFO message in a new header or a parameter of the TO URL. Having said this, I take your point about retaining state in a single SIP message. If it is mandated that SIP/PSTN gateways only ever signal en-bloc then the overlap sending issues are avoided. Clarification of when to generate the ACM, along the lines of your posting, would be useful. I am still concerned that RFC2543bis-02 defines (very sketchily) overlap sending in a way that is flawed (using Request-URI). This needs addressing by the SIP authors. Regards, K. Robinson Gonzalo Camarillo on 06/02/2001 21:11:50 To: Keith Robinson/MAIN/MC1@MCMAIN cc: christer.holmberg@lmf.ericsson.se, jmoloney@nortelnetworks.com, taylor@nortelnetworks.com, sip@lists.bell-labs.com, adam.roach@ericsson.com Subject: Re: [SIP] Overlap call setup Hello, Thanks for the pointer. Answers inline: Keith Robinson wrote: > > Attached is an earlier posting I raised highlighting my concerns with some of > the > mechanisms outlined in the sip-isup document. This is the source of recent > discussions. > > Regards, > > K. Robinson > ---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 06/02/2001 16:42 > --------------------------- > > 31/01/2001 16:34 > Keith Robinson > > To: "Joshua Moloney" @ MCEXT > cc: sip@lists.bell-labs.com@MCEXT > > Subject: Re: [SIP] Overlap call setup (Document link: Keith Robinson) > > I have recently been trying to get clarification on the implemenation of > overlap sending; see attached for the discussion that has taken place > so far. > > Certainly, the mechanism outlined (very sketchily) in RFC2543bis-02 sect 4.2.1 > is fundamentally flawed. The Request-URI cannot be used to carry extra digits > as the Record-Route/Route mechanism would end up overwriting the R-URI > and therefore the subsequent digits would be lost. > > This then leads to the idea of using the TO field as described in > sip-isup-00-00.txt; > however, I have the following issues with the mechanisms described in this > document : > > As the TO field is different on each subsequent INVITE, then it is a new call > leg > on an existing call id; RFC2543bis-02 sect. 11.5 does not state what a UAS > should make of this. If you follow the logic in 11.5 you get to case (3), but > here it only defines the behaviour if the TO and FROM fields match. > I do not see here a big problem for a UA. If the UA is a gateway, it will handle the overlap signalling properly. If it is a pure SIP UA, it will answer the first INVITE with a 484 (or "Not found response") and process the second INVITE properly. > The 484 sent backwards kills that call attempt (but not the state for that > Call-Id - > is this problematic for intermediate proxies ?) so subsequent INVITEs will > actually be initial INVITEs. As these INVITEs must get to the same terminating > UAS, > the originating UAC will have to create a ROUTE header in an initial INVITE > using , > at least the CONTACT address from the 484. This implies the use of source > routing, an > issue that I don't believe has been fully resolved, and even if it is and > becomes part > of the base protocol some administrations may be reluctant to admit initial > INVITEs > which try to circumvent their routing policy, so may reject such INVITEs. > There was a big thread about source routing. This kind of source routing is fine. Current proxies handle it properly. If a proxy sees an INVITe with a route header, it does not know if it is the first INVITE or a re-INVITE. Thus, it will work properly. Even if the proxy stores state and it receives a INVITE (non re-INVITE) with a route header, it should honor it. Otherwise, the proxy is not robust. This allows a call stateful proxy to lose state, re-boot and still be able to route requests properly. > Also on the above point, the CONTACT address in the 484 must have the same > semantics as that in a 200 response so that a ROUTE header can be built; however > RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in 4XX responses > indicates a location where additional error information can be found. Indeed, in > a recent > thread entitled Announcements in SIP (401 & 407 Contact) J. Rosenberg believes > that > Record-Route does not make sense in any non-200 response. This contact header that is going to be used is the one present in the 183, not in the 484. This solves the problem of several IAMs al the same time. If the answer was a 484, no IAM was sent. Thus, the next re-INVITE with more digits can be very well handled by a different gateway. > > I would raise the question of whether the 484 response has any use in overlap > sending > (certainly in the case of ISUP) at all. 484 responses are not very useful in this scenario, but they might be useful in anothers (when a UA can ask the user to type more digits, for instance). If a node receives insufficient digits > to decode than it will wait until it receives some more from the preceding node > (or end of > dialling timers mature). If the preceding node receives subsequent digits and > end of dialling > has not been detected then it will pass them on. If the 484 indicated the > minimum number of > digits before a decode could take place, then it would be useful in cutting down > the number > of subseqent messages sent. > > Indeed, isup-sip-00.txt does cover the mechanism where a 183 is sent, and not a > 484. > The case in point is covered in sect. 11.3 (Example of SIP bridging and overlap > signalling); > However, I have the following issues with this mechanism: > > As before relies on source routing. See comments above about this type of source routing. > > Relies on proxies sending requests on new call legs but existing call-ids to the > same > downstream server; fine if you administer these proxies, what if you don't ? Why would you want to limit a call to one call leg?? > (Lots of > wasted IAMs generated). Lots of IAMs????? The situation where more than one (typically two) IAMs are generated is when the 183 arrived to the ingrees gateway after it sent the first re-INVITE. This situation is ulikely to happen anyway, because if you receive subsequent digits so fast (faster than a RTT), you should implement a timer, and not send LOTS of SAMs anyway. > The mechanism should not send 5 (subsequent INVITE) > until it has received an acknowledgement (probably not 100) from the first. Again a timer configuration problem. You can, and your re-INVITE will most likelt reach the same egrees gateway as the 1st one... but it might reach a different one. Thus, the ingrees gateway should be aware of this and be ready for canceling one of the TWO IAMs sent if this happen. But again, this situation is not common. > Alternatively, > the Reason-Phrase could detail more specifically the exact progress of the call > ("Decoding Address" > in this case ?) so that the ACM is not generated unconditionally. > > Sect. 11.2 encourages gateways "to return a183 Session Progress with a Contact > header as soon as they receive an INVITE that they are going to handle and might > contain > an incomplete number". Presumably this is to allow the UAC to build a ROUTE so > that subsequent > INVITEs get to the appropriate UAS. YES. > Sect 7.2.3 indicates that a node receiving a > 183 prior to generating > an ACM should generate an ACM. Applied together these rules may cause a prior > node to never > send on any subsequent digits and overlap sending would fail. The same way that nodes handling overlap signalling do not release the call upon reception of a 484, they will not generate ACMs upon reception of a 183 without SDP and without an ancapsulated ACM... we might want to add this clarification to the draft. > > I think an approach is required whereby subsequent digits are sent on the same > call leg as the > initial INVITE; either multiple INVITEs are allowed before 200 OK (already > suggested by J. Rosenberg > in a different context) Stacking requests is not a good solution in this case. It leads to a lot of problems that we certainly want to avoid. > , or the INFO method is used. If INFO is used any vanilla SIP UA should implement INFO in order tor receive calls/sessions that use overlap signalling. One of the most important requirements for overlap signalling in SIP was that a vanilla SIP UA could handle it. In both cases the TO field > will have to remain the > same so a new header (or message body type) is required to convey the digits. Again, we do not want to implement this in vanilla SIP UAs. Best regards, Gonzalo > Also, replace the 484 > with, say, 18X indicating the minimum number of digits required, perhaps in the > Reason-Phrase header. > > Regards, > > Keith Robinson. > > "Joshua Moloney" on 31/01/2001 10:49:33 > > > > > > > > To: sip@lists.bell-labs.com > > cc: (bcc: Keith Robinson/MAIN/MC1) > > > > Subject: [SIP] Overlap call setup > > > Greetings, > > I would like to ask for clarification regarding the implementation of > Overlap. > > I'll begin by referring to paragraph 3, section 6.1.2 of > "draft-ietf-isup-sip-00": > > It is stated that INVITEs sent after the first one (containing extra digits > in the 'To' field) are to be treated as new Call-Legs, seeing as the > contents of their 'To' headers differ. As such, there is no relationship > between their CSeq values. > > If this is the case, how is it possible to ensure correct digit ordering > over an 'unreliable' transport layer like UDP? It would seem logical that > the call originator _would_ use contiguous CSeq values, as it would be > 'aware' of the fact that the INVITEs are for the same call. > > I believe that this issue was raised on the SIP list on 19 November 1999 by > Gonzalo C and Jonathan R. The subject of the messages was "Re: Comments on > draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of the exchange > appeared to be an agreement that CSeq ordering should be employed. > > However, does this in any way imply that under such circumstances the > INVITEs would/should belong to the same Call-Leg? After all, the concept of > Overlap does not seem to 'fit in' with the concept behind multiple Call-Legs > anyway. > > If there has been a change in thinking behind the problem, and the latest > draft is correct, please could you explain how the ordering problem will be > overcome. If not, perhaps the draft needs modification to include these > considerations... > > Regards, > > Josh Moloney > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64 > Description: Internet HTML -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 11:32:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03091 for ; Wed, 7 Feb 2001 11:32:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AD071443A8; Wed, 7 Feb 2001 11:32:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 2D160443E0 for ; Wed, 7 Feb 2001 11:31:10 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA05317 for ; Wed, 7 Feb 2001 08:31:24 -0800 (PST) Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with SMTP id AAJ77440; Wed, 7 Feb 2001 08:31:06 -0800 (PST) Message-Id: <4.1.20010207081937.00b93de0@imop.cisco.com> Message-Id: <4.1.20010207081937.00b93de0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: sip@lists.bell-labs.com From: Rohan Mahy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [SIP] New version of message waiting draft Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 07 Feb 2001 08:26:16 -0800 Hi, I just finished a new version of the message waiting draft from Ilya Slain and I. Until it appears in the archives it is available at: ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-message-waiting-01.txt thanks, -rohan _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 11:59:06 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03596 for ; Wed, 7 Feb 2001 11:59:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E6AF944394; Wed, 7 Feb 2001 11:59:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 51B684438D for ; Wed, 7 Feb 2001 11:58:46 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA19646 for ; Wed, 7 Feb 2001 12:01:46 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR85AY>; Wed, 7 Feb 2001 11:55:06 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30475B9@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: sip@lists.bell-labs.com Subject: RE: [SIP] Removing 409 to conflicting action params MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 7 Feb 2001 11:55:05 -0500 I share Neil's opinions here. Can anyone state a reason for keeping the restriction? RjS > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Friday, January 19, 2001 6:06 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Removing 409 to conflicting action params > > > Can we please remove the restriction that all current > registrations MUST share the same action param. I haven't > found this to be helpful to either users or implementers. > > The spec doesn't really say anything about servers having > to obey action params so they could be treated as just a > hint to the users wishes. A SIP server could then choose > to try and follow them, use it's own configuration policy > or follow alternative user defined processing logic (CPL etc). > This is more in keeping with the handling of params like > methods that we are seeing more of in Contact headers. > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 12:05:46 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03793 for ; Wed, 7 Feb 2001 12:05:45 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7FBBA443F2; Wed, 7 Feb 2001 12:04:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from betsy.surfcast.com (unknown [194.202.103.100]) by lists.bell-labs.com (Postfix) with ESMTP id 11B93443EF for ; Wed, 7 Feb 2001 12:03:13 -0500 (EST) Received: by betsy.surfcast.internal with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Feb 2001 17:02:07 -0000 Message-ID: <91D91D8F61FAD31191C900508B8BA0B80F5A07@dennis.surfcast.internal> From: Mark Lynch To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Video Conferencing? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 7 Feb 2001 17:01:45 -0000 Hi, I've been working with H323 for a while now but lately have been reading alot about SIP and must say I'm very impressed with it's simplicity and power. The only question I have is reagarding it's video conferencing capabilities. I've been led to believe it's a long way off ? I thought it was as simple as establishing an RTP channel and agreeing a codec. Could someone please tell me I'm wrong and point me to an example of Video conferecing via SIP? I can' t seem to find any. If I'm right could anyone clarify what is happening in relation to this. Regards, Mark _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 13:04:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05086 for ; Wed, 7 Feb 2001 13:04:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0BA334435B; Wed, 7 Feb 2001 13:04:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zrtps06s.us.nortel.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by lists.bell-labs.com (Postfix) with ESMTP id E86DA4434F for ; Wed, 7 Feb 2001 13:03:30 -0500 (EST) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Wed, 7 Feb 2001 12:54:00 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Feb 2001 12:53:34 -0500 Message-ID: <63E0DAD7784FD21188310000F80824B304B97D40@zmpkdx02.us.nortel.com> From: "Mo Zonoun" To: "'Rosen, Brian'" , Michael Thomas , "Drage, Keith (Keith)" Cc: "'William Marshall'" , sip@lists.bell-labs.com, "'tr414@tiacomm.org'" Subject: RE: [SIP] Re: Location information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0912E.E144A7B0" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 7 Feb 2001 12:53:30 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0912E.E144A7B0 Content-Type: text/plain; charset="iso-8859-1" TIA TR-41.4 committee has been working on the E911 issues for while. There are two choices of positioning technologies under consideration. Network-based, which achieves positioning with a network management overlay such as SNMP and Set-based, which uses positioning devices integrated into the set. Some of the issues identified in this list as being out side of IETF area of work should be forwarded to TR-41.4 (tr414@tiacomm.org) for further discussion and inclusion into their work. Mo -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, February 06, 2001 4:31 PM To: Michael Thomas; Drage, Keith (Keith) Cc: 'William Marshall'; sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information > I don't see what the problem is here. The proxy that > suppresses caller id is a trusted third party. Part > of the implicit agreement between my UA and the > proxy is that certain entities -- 911 centers, etc, -- > will always have access to my caller id. If you > don't like that service, then don't use that proxy. > This is a protocol issue because there are three entities, the UAC, the outgoing proxy, and the incoming proxy (or UAS) at the emergency center. There has to be additional specification that details how this works. The spec probably needs some MUSTs. Some of the issues are: How does the UA indicate to the outgoing proxy that this is an emergency call? What are the minimum requirements for caller identification and location that must be delivered from the UAC to the Proxy Server? How does the outgoing proxy server identify "right" emergency server? What is the minimum requirement for caller identification and location that must be delivered from the outgoing Proxy Server to the center? Are there some minimum requirements for protocol options the emergency center (or proxy or gateway) must implement in order to provide the service needed? It's not entirely clear to me that this is an IETF matter, but it HAS to be done, somewhere. Brian _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. ------_=_NextPart_001_01C0912E.E144A7B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Re: Location information

TIA TR-41.4 committee has been working on the E911 = issues for while. There are two choices of positioning technologies = under consideration. Network-based, which achieves positioning with a = network management overlay such as SNMP and Set-based, which uses = positioning devices integrated into the set.

Some of the issues identified in this list as being = out side of IETF area of work should be forwarded to TR-41.4 = (tr414@tiacomm.org) for further discussion and inclusion into their = work.

Mo

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Tuesday, February 06, 2001 4:31 PM
To: Michael Thomas; Drage, Keith (Keith)
Cc: 'William Marshall'; = sip@lists.bell-labs.com
Subject: RE: [SIP] Re: Location information


>    I don't see what the problem = is here. The proxy that
>    suppresses caller id is a = trusted third party. Part
>    of the implicit agreement = between my UA and the
>    proxy is that certain = entities -- 911 centers, etc, --
>    will always have access to my = caller id. If you
>    don't like that service, then = don't use that proxy.
>
This is a protocol issue because there are three = entities,
the UAC, the outgoing proxy, and the incoming proxy = (or UAS)
at the emergency center.  There has to be = additional
specification that details how this works.  The = spec probably
needs some MUSTs.  Some of the issues = are:
        How does = the UA indicate to the outgoing proxy that
        this is = an emergency call?  What are the minimum
        requirements for caller identification and location
        that must = be delivered from the UAC to the Proxy Server?

        How does = the outgoing proxy server identify "right"
        emergency = server?  What is the minimum requirement for
        caller = identification and location that must be
        delivered = from the outgoing Proxy Server to the center?
        Are there = some minimum requirements for protocol options
        the = emergency center (or proxy or gateway) must implement
        in order = to provide the service needed?

It's not entirely clear to me that this is an IETF = matter,
but it HAS to be done, somewhere.

Brian


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

------_=_NextPart_001_01C0912E.E144A7B0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 15:01:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07796 for ; Wed, 7 Feb 2001 15:01:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1AF7A443AD; Wed, 7 Feb 2001 15:01:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 387E044364 for ; Wed, 7 Feb 2001 15:00:13 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 7 Feb 2001 14:56:54 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1MM3G9WM>; Wed, 7 Feb 2001 14:56:55 -0500 Message-ID: <28560036253BD41191A10000F8BCBD1103A038C3@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Gonzalo Camarillo Cc: Christer Holmberg , sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09140.1E57AA10" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 7 Feb 2001 14:56:53 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C09140.1E57AA10 Content-Type: text/plain; charset="iso-8859-1" This is a matter of network policy, not a protocol issue. If the SIP network wants to enforce conversion to en bloc signalling it is free to do so, but this can happen at any point in the signalling chain and would actually be done most efficiently at the ingress gateway if it has the necessary understanding of the dial plan. If the network is prepared merely to pass the ISUP through it is free to do so. > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, February 06, 2001 9:52 PM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: Christer Holmberg; sip@lists.bell-labs.com > Subject: Re: [SIP] Operlap dialing within a SIP network > > > Hi Tom, > > Still I want to have full state in every SIP message. If the call is > addresed to the phone number 1234, I want to have a to field that says > 1234. I do not care if there is a leg routed thru the PSTN and another > thru SIP. > > Carrying full state is one of the beauties of SIP. If we begin using > INFO for this, it would be the same as using SAMs. Differen names, the > same thing... I do not want to re-create ISUP using SIP. I > believe that > if the session has a destination, it should be present in the > to field. > > Again, if a proxy is providing services for this particular call, it > will want to see the called party number in order to trigger > the proper > service. This is a very good reason for updating the to field > every time > we have more digits. > > I like to use SIP between two gateways because it is possible > to provide > SIP services for a PSTN to PSTN call. If all we want to do is > finding a > egrees gateway, we would probably want to use other protocols (TRIP & > SIGTRAN for instance). > > Regards, > > Gonzalo > > Tom-PT Taylor wrote: > > > > Sorry, we're talking past each other. The premise of my > statements is > > that an INVITE has reached a UAS which has accepted it. It follows > > that the UAS did not send back a 484, but rather an interim > response. > > IF more digits come along, the INFO method is there to carry them. > > They do not affect the SIP call state; they are used beyond the UAS, > > either in a PSTN call or in another SIP call as the case may be. > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > Hello Tom, > > > > > > Tom-PT Taylor wrote: > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > signalling > > > > has reached an egress gateway, SIP has done its job -- > additional > > > > digits will not change call state. It is therefore > > > reasonable to use > > > > INFO to carry the additional digits. If we are talking > > > ISUP-SIP, once > > > > the destination UAS or a UAS in a B2BUA has been > reached, the same > > > > > > consideration applies. > > > > > > > > > > I do not agree with these two statements: > > > > > > The 1st INVITE (with just some digits) arrives to a > vanilla SIP UA. > > I > > > will return a Not Found or a 484 Address incomplete. The > > > subsequent INFO > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > gateway > > > will have to re issue a new INVITE with all the digits. > > > Therefore, it is > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > carries ISUP messages between two gateways. For that, we have > > already > > > SIGTRAN. SIP might be used to provide services, even when the > > > call is a > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > state. And a > > > SIP message with an incomplete to field does not carry complete > > state. > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > based > > > on the to field (called party number). That proxy would > like to see > > an > > > updated to field, not just a to field that contains just some > > digits. > > > > > > Best regards, > > > > > > Gonzalo > > > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > To: Gonzalo Camarillo > > > > > Cc: sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > been proposed > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > reason for > > > > > the discussion from the beginning was that the overlap > > signalling, > > > > > according to the SIP-ISUP mapping draft, may not work > > > very well, and > > > > a > > > > > solution using 18x responses and INFO messages, instead of 484 > > and > > > > > re-INVITEs, was proposed. > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > signalling section. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > about calls > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > SIP UAS > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > | <- 18x ------ | > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > | <- 200 (INFO) | > > > > > > > | <- 18x ------ | > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > --> > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > the word 'proxy') > > > > > > > must collect digits, sent from the PSTN side using > > > > > overlap dialing, to > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > the digits > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > be allowed to > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > INVITEs, until > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer Holmberg > > > > > > > Ericsson Finland > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : > > > Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > ------_=_NextPart_001_01C09140.1E57AA10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Operlap dialing within a SIP network

This is a matter of network policy, not a protocol = issue.  If the SIP network wants to enforce conversion to en bloc = signalling it is free to do so, but this can happen at any point in the = signalling chain and would actually be done most efficiently at the = ingress gateway if it has the necessary understanding of the dial = plan.  If the network is prepared merely to pass the ISUP through = it is free to do so.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: Tuesday, February 06, 2001 9:52 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: Christer Holmberg; = sip@lists.bell-labs.com
> Subject: Re: [SIP] Operlap dialing within a SIP = network
>
>
> Hi Tom,
>
> Still I want to have full state in every SIP = message. If the call is
> addresed to the phone number 1234, I want to = have a to field that says
> 1234. I do not care if there is a leg routed = thru the PSTN and another
> thru SIP.
>
> Carrying full state is one of the beauties of = SIP. If we begin using
> INFO for this, it would be the same as using = SAMs. Differen names, the
> same thing... I do not want to re-create ISUP = using SIP. I
> believe that
> if the session has a destination, it should be = present in the
> to field.
>
> Again, if a proxy is providing services for = this particular call, it
> will want to see the called party number in = order to trigger
> the proper
> service. This is a very good reason for = updating the to field
> every time
> we have more digits.
>
> I like to use SIP between two gateways because = it is possible
> to provide
> SIP services for a PSTN to PSTN call. If all we = want to do is
> finding a
> egrees gateway, we would probably want to use = other protocols (TRIP &
> SIGTRAN for instance).
>
> Regards,
>
> Gonzalo
>
> Tom-PT Taylor wrote:
> >
> > Sorry, we're talking past each = other.  The premise of my
> statements is
> > that an INVITE has reached a UAS which has = accepted it.  It follows
> > that the UAS did not send back a 484, but = rather an interim
> response.
> > IF more digits come along, the INFO method = is there to carry them.
> > They do not affect the SIP call state; = they are used beyond the UAS,
> > either in a PSTN call or in another SIP = call as the case may be.
> >
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > Sent: Tuesday, February 06, 2001 9:10 = PM
> > > To: Taylor, Tom-PT = [NORSE:B901:EXCH]
> > > Cc: Christer Holmberg; = sip@lists.bell-labs.com
> > > Subject: Re: [SIP] Operlap dialing = within a SIP network
> > >
> > >
> > > Hello Tom,
> > >
> > > Tom-PT Taylor wrote:
> > > >
> > > > Just to re-hash, in the = ISUP-SIP-ISUP context, once call
> > signalling
> > > > has reached an egress gateway, = SIP has done its job --
> additional
> > > > digits will not change call = state.  It is therefore
> > > reasonable to use
> > > > INFO to carry the additional = digits.  If we are talking
> > > ISUP-SIP, once
> > > > the destination UAS or a UAS in = a B2BUA has been
> reached, the same
> >
> > > > consideration applies.
> > > >
> > >
> > > I do not agree with these two = statements:
> > >
> > > The 1st INVITE (with just some = digits) arrives to a
> vanilla SIP UA.
> > I
> > > will return a Not Found or a 484 = Address incomplete. The
> > > subsequent INFO
> > > carrying more digits will be = discarded. Thus, the PSTN to SIP
> > gateway
> > > will have to re issue a new INVITE = with all the digits.
> > > Therefore, it is
> > > better to begin directly using = er-INVITEs rather than INFO.
> > >
> > > Besides, I do not think that SIP is = just a transport protocol that
> > > carries ISUP messages between two = gateways. For that, we have
> > already
> > > SIGTRAN. SIP might be used to provide = services, even when the
> > > call is a
> > > PSTN-SIP-PSTN call. Thus, SIP = messages MUST carry complete
> > > state. And a
> > > SIP message with an incomplete to = field does not carry complete
> > state.
> > > What if my SIP proxy provides a = service for a PSTN-SIP-PSTN call
> > based
> > > on the to field (called party = number). That proxy would
> like to see
> > an
> > > updated to field, not just a to field = that contains just some
> > digits.
> > >
> > > Best regards,
> > >
> > > Gonzalo
> > >
> > >
> > > > > -----Original = Message-----
> > > > > From: Christer = Holmberg
> > [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > > > > Sent: Tuesday, February 06, = 2001 1:15 AM
> > > > > To: Gonzalo = Camarillo
> > > > > Cc: = sip@lists.bell-labs.com
> > > > > Subject: Re: [SIP] Operlap = dialing within a SIP network
> > > > >
> > > > >
> > > > >
> > > > > Hi Gonzalo,
> > > > >
> > > > > I didn't say I am going to = use INFO, but that is what has
> > > > > been proposed
> > > > > earlier in this thread, so = I assumed INFO would be used. The
> > > > > reason for
> > > > > the discussion from the = beginning was that the overlap
> > signalling,
> > > > > according to the SIP-ISUP = mapping draft, may not work
> > > very well, and
> > > > a
> > > > > solution using 18x = responses and INFO messages, instead of 484
> > and
> > > > > re-INVITEs, was = proposed.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Christer Holmberg
> > > > > Ericsson Finland
> > > > >
> > > > >
> > > > >
> > > > > Gonzalo Camarillo = wrote:
> > > > > >
> > > > > > Hello Christer,
> > > > > >
> > > > > > Why are you using INFO = for sending extra digits?
> > > > > >
> > > > > > Please, check the = SIP-ISUP mapping draft, overlap
> > > > > signalling section.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Gonzalo
> > > > > >
> > > > > > Christer Holmberg = wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > The discussion = about overlap dialing has been pretty much
> > > > > about calls
> > > > > > > from SIP to PSTN, = or PSTN-SIP-PSTN.
> > > > > > >
> > > > > > > Consider the = following scenario.
> > > > > > >
> > > > > > > PSTN = PHONE           &= nbsp; GW           = SIP SERVER   
>   SIP UAS
> > > > > > >
> = -----------------------------------------------------------
> > > > > > >
> > > > > > > --- 1 = --->    -- IAM -> | -- INVITE -->  = |
> > > > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > --- 2 = --->    -- SAM -> | -- INFO ---->  = |
> > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |
> > > > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > --- 3 = --->    -- SAM -> | -- INFO ---->  = |
> > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |   -- INVITE
> > > > > > > -->
> > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INVITE)|   <- 200 ------
> > > > > > >
> > > > > > > In this case, the = SIP server (note that I am not using
> > > > > the word 'proxy')
> > > > > > > must collect = digits, sent from the PSTN side using
> > > > > overlap dialing, to
> > > > > > > be able to find = the SIP UAS, and INFO is used to provide
> > > > > the digits
> > > > > > > after the INVITE = has been sent.
> > > > > > >
> > > > > > > My question is, = should a SIP server (proxy, if you like)
> > > > > be allowed to
> > > > > > > behave like this, = or MUST it send 486s, and receive new
> > > > > INVITEs, until
> > > > > > > it is able to = find the UAS?
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Christer = Holmberg
> > > > > > > Ericsson = Finland
> > > > > >
> > > > > > --
> > > > > > Gonzalo Camarillo =         Phone :  +358  9 = 299 33 71
> > > > > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > > > FIN-02420 = Jorvas          Email = :
> > > Gonzalo.Camarillo@ericsson.com
> > > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > >
> > >
> > > --
> > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > >
>
> --
> Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> = Finland           = ;        http://www.hut.fi/~gonzalo
>

------_=_NextPart_001_01C09140.1E57AA10-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 15:12:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08055 for ; Wed, 7 Feb 2001 15:12:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 616604437C; Wed, 7 Feb 2001 15:12:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 30F3444376 for ; Wed, 7 Feb 2001 15:11:11 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA22396; Wed, 7 Feb 2001 15:14:05 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR85VK>; Wed, 7 Feb 2001 15:07:24 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30475C0@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Rick Dean'" , Ben Campbell Cc: sip@lists.bell-labs.com Subject: RE: [SIP] draft-ietf-sip-handoff-00pre8.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 7 Feb 2001 15:07:23 -0500 Rick - characterizing the requirement to request permission from the user before proceeding as doing some form of interactive query is misleading. The REFER draft (in fact, the original TRANSFER draft) states: A UA receiving a well-formed REFER request SHOULD request approval from the user to proceed (this request could be interactive or through configuration). The parenthetical comment is there for a reason. Current generation clients will have configured policy that grants this approval, then next round will have at least that and maybe, hopefully, something more. RjS > -----Original Message----- > From: Rick Dean [mailto:siplist@fdd.com] > Sent: Tuesday, January 30, 2001 11:14 AM > To: Ben Campbell > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt > > > > Amazon does sessions by a fake directory at the end of > URL's. This technique has the advantage of never eliciting > a dialog box for any browser with any setting. Please > do not underestimate how unfamiliar* an end user can be. > > If a UA is worried about destinations which badly handle > INVITEs with "handoff" headers. That UA should deny > HANDOFFs. This will force the transferor to B2BUA, try > another strategy, or give up. If the transferee already > pops up a message this is too late, and transferors > will B2BUA to begin with. > > We predict frequently the HANDOFF will be intercepted > by a B2BUA call controller and thus hidden from the > transferee. This is for privacy and reliability considerations, > and works most like the existing PSTN. > > We confess, our goal is to build a transfer which works exactly > like the existing phone system, but happens to use SIP. When > we complete this task, feel free to build a phone system > which works differently. We hope you find some customers. > > Yes, proxies should be able to administratively block > HANDOFF requests like any other. Good point. Do we need another > sentence to cover this? Are you proposing a special header or > response code to indicate the proxy and not the end UA blocked it? > Does it make a difference to the HANDOFF sending UA? > > We already have another method which is "prompt the remote human". > REFER to a web page does this best. An audible > question does not need a SIP extension. > > Wouldn't the REFER request to a web page need two promptings? > The first one is do you want to follow the URL and the second is the > question on the web page. I can do more damage > with a HTTP GET than a SIP INVITE, but most browsers follow > 302 redirects automatically anyway. > > BTW, I am scared of what > a REFER with method=REFER prompt would look like to an end > user. Clearly, the designers don't intend this. > > Yes, sophisticated UA's with 19" monitors in expert mode will > defy the > draft and prompt the user. It is their choice, and the IETF > tries hard > not to mandate this behavior outside the protocol. Hopefully the > UA will prompt after the HANDOFF final response, but before the > handoff-status, for timing reasons as you stated. > > Thanks for the feedback. > > -- > Rick > 3Com > > P.S. I will be largely unreacable from Feb 1-6 due to > a vacation. (Jackson Hole Wyoming :-) > > On Mon, Jan 29, 2001 at 04:00:54PM -0500, Ben Campbell wrote: > > Sorry for the lateness of my comments. I just came back > from back to back > > vacation and flu. > > > > I am concerned about the statement that a UA should > automatically process a > > HANDOFF without asking the user. This seems dangerous to > me; I envision a > > scenario where someone calls me, then transfers me to a > billable service > > without my consent. > > > > I did notice the section about being able to > administratively block such > > things at a proxy. I am still thinking about whether that > is sufficient > > protection, as it would require some level of > administrative forethought. I > > suspect we would find a lot of cases of closing the barn > door after the > > horses have left. > > > > I realize you added this requirement because of timing > issues, but it seems > > to be a rather harsh presumption of decisions that at least > sometimes should > > be left to the user. > > > > > -----Original Message----- > > > From: Rick Dean [mailto:siplist@fdd.com] > > > Sent: Wednesday, January 17, 2001 12:27 PM > > > To: sip@lists.bell-labs.com > > > Subject: [SIP] draft-ietf-sip-handoff-00pre8.txt > > > > > > > > > > > > Dear SIP list, > > > > > > Although we would like more time to > > > edit this poor draft, we feel a sneak > > > peek is warranted due to its urgent nature > > > with the upcomming meeting. > > > > > > http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt > > > > > > Some significant differences from REFER are: > > > * narrower scope > > > * method completes without prompting > > > * referred-by like header generated by transferee > > > * location of headers for spawned invite > > > * error processing & final notification > > > > > > Cheers, > > > Rick > > > rick_dean@3com.com > > > > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 15:19:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08173 for ; Wed, 7 Feb 2001 15:19:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A421C443FA; Wed, 7 Feb 2001 15:19:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CEA8E443FF for ; Wed, 7 Feb 2001 15:18:29 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA22549 for ; Wed, 7 Feb 2001 15:21:30 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR85WP>; Wed, 7 Feb 2001 15:14:50 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30475C3@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: sip@lists.bell-labs.com Subject: RE: [SIP] draft-ietf-sip-handoff-00pre8.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 7 Feb 2001 15:14:49 -0500 Background for those who have joined conversation later than last May - the original submission that became the cc-transfer draft used a TRANSFER method. RjS > -----Original Message----- > From: Sean Olson [mailto:sean.olson@ericsson.com] > Sent: Monday, January 29, 2001 1:35 PM > To: Roy, Radhika R, ALCOO > Cc: Patrice Calhoun; ???; Rick Dean; Rohan Mahy; > sip@lists.bell-labs.com > Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt > > > The name can be confusing, I agree. But as with all > specifications, you need to read them in the appropriate > context. I personally find HANDOFF completely apropos for > this usage because it is a SIP method and because the > introduction in the draft does a good job of establishing > the scope and meaning of the method. If HANDOFF is > taboo, how about "TRANSFER"? Nevermind the confusing > part about the transfer draft defining REFER and the handoff > draft defining REFER :) > > my two cents > /sean > > Roy, Radhika R, ALCOO wrote: > > > Yes, as PatC pointed out, the term "HANDOFF" is creating a constant > > confusion. > > I, like many others, also point this to the WG for consideration. > > > > Radhika R. Roy > > AT&T > > > > -----Original Message----- > > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] > > Sent: Sunday, January 28, 2001 1:46 PM > > To: ??? > > Cc: Rick Dean; Rohan Mahy; sip@lists.bell-labs.com > > Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt > > > > > > Ahhh, I see that the misuse of terminology is biting this > WG in the a.. > > > > This isn't a handoff as you, or I, or anyone else involved > in mobility > > management understands it. It is rather a form of call > transfer. You are > > correct that the handoff will occur at the GGSN/SGSN. > > > > I have asked that the WG refrain from using the term > handoff, or handover, > > given that the mobility folks will have serious issues with > it (as they have > > had with SIP Mobility, when it fact it is really > portability). However, the > > WG > > does not seem to be willing to listen to our requests :( > > > > I suppose we will simply have to deal with the constant > confusion we are > > creating in the marketplace by abusing terminology. > > > > PatC > > > >> Dear all. > >> > >> I am some curious about HANDOFF method. > >> I think, HANDOFF method is required when SIP terminal > moves from one > > > > network > > > >> to other network. > >> > >> In 3GPP TR23.821, the sentense, > >> " As a consequence, the behaviour of the multimedia call > control server > >> (CSCF) can be the same whatever the access technology (radio or > > > > wired-line). > > > >> Multimedia call control/mobility management shall not be > aware of the > > > > access > > > >> technology: the multimedia Call Control (CSCF) does not > handle notions > > > > such > > > >> as Hand-Over, RA, " > >> > >> It means that handoff is the problem of GGSN and SGSN not > CSCF which > > > > support > > > >> SIP protocol. It is not the business of CSCF. > >> > >> Therefore I think HANDOFF method is not required at least 3GPP. > >> > >> What do you think about this? > >> > > > > > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 15:54:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08556 for ; Wed, 7 Feb 2001 15:54:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 011944434F; Wed, 7 Feb 2001 15:54:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 9D96A44336 for ; Wed, 7 Feb 2001 15:53:30 -0500 (EST) 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 f17KrTC26168; Wed, 7 Feb 2001 21:53:29 +0100 (MET) Received: from lmf.ericsson.se ([142.133.141.94]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id VAA08498; Wed, 7 Feb 2001 21:53:17 +0100 (MET) Message-ID: <3A81B5FF.D19B0866@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor Cc: Christer Holmberg , sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: <28560036253BD41191A10000F8BCBD1103A038C3@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 07 Feb 2001 22:54:23 +0200 Content-Transfer-Encoding: 7bit Hello Tom, Tom-PT Taylor wrote: > > This is a matter of network policy, not a protocol issue. If the SIP > network wants to enforce conversion to en bloc signalling it is free > to do so, but this can happen at any point in the signalling chain and > would actually be done most efficiently at the ingress gateway if it > has the necessary understanding of the dial plan. If the network is > prepared merely to pass the ISUP through it is free to do so. I agree. If you want, you can do it. As you could also establish an HTTP session between both gateways. You could also establish an FTP session to transfer the ISUP messages between them. As you point out, the network administrator can do with his network whatever he wants, and enforce the policy he wants. I was just saying that if we just want to transparently trasfer ISUP messages between two gateways, SIP is not the best solution. This was my comment. Of course it can be done, but it falls outside SIP's scope. That's why I do not like the INFO solution. Best regards, Gonzalo > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Tuesday, February 06, 2001 9:52 PM > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > Hi Tom, > > > > Still I want to have full state in every SIP message. If the call is > > > addresed to the phone number 1234, I want to have a to field that > says > > 1234. I do not care if there is a leg routed thru the PSTN and > another > > thru SIP. > > > > Carrying full state is one of the beauties of SIP. If we begin using > > > INFO for this, it would be the same as using SAMs. Differen names, > the > > same thing... I do not want to re-create ISUP using SIP. I > > believe that > > if the session has a destination, it should be present in the > > to field. > > > > Again, if a proxy is providing services for this particular call, it > > > will want to see the called party number in order to trigger > > the proper > > service. This is a very good reason for updating the to field > > every time > > we have more digits. > > > > I like to use SIP between two gateways because it is possible > > to provide > > SIP services for a PSTN to PSTN call. If all we want to do is > > finding a > > egrees gateway, we would probably want to use other protocols (TRIP > & > > SIGTRAN for instance). > > > > Regards, > > > > Gonzalo > > > > Tom-PT Taylor wrote: > > > > > > Sorry, we're talking past each other. The premise of my > > statements is > > > that an INVITE has reached a UAS which has accepted it. It > follows > > > that the UAS did not send back a 484, but rather an interim > > response. > > > IF more digits come along, the INFO method is there to carry them. > > > > They do not affect the SIP call state; they are used beyond the > UAS, > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hello Tom, > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > signalling > > > > > has reached an egress gateway, SIP has done its job -- > > additional > > > > > digits will not change call state. It is therefore > > > > reasonable to use > > > > > INFO to carry the additional digits. If we are talking > > > > ISUP-SIP, once > > > > > the destination UAS or a UAS in a B2BUA has been > > reached, the same > > > > > > > > consideration applies. > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > vanilla SIP UA. > > > I > > > > will return a Not Found or a 484 Address incomplete. The > > > > subsequent INFO > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > gateway > > > > will have to re issue a new INVITE with all the digits. > > > > Therefore, it is > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > Besides, I do not think that SIP is just a transport protocol > that > > > > carries ISUP messages between two gateways. For that, we have > > > already > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > call is a > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > state. And a > > > > SIP message with an incomplete to field does not carry complete > > > state. > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > > based > > > > on the to field (called party number). That proxy would > > like to see > > > an > > > > updated to field, not just a to field that contains just some > > > digits. > > > > > > > > Best regards, > > > > > > > > Gonzalo > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > To: Gonzalo Camarillo > > > > > > Cc: sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > been proposed > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > > reason for > > > > > > the discussion from the beginning was that the overlap > > > signalling, > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > very well, and > > > > > a > > > > > > solution using 18x responses and INFO messages, instead of > 484 > > > and > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer Holmberg > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > signalling section. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty > much > > > > > > about calls > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > SIP UAS > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > | <- 18x ------ | > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > | <- 200 (INFO) | > > > > > > > > | <- 18x ------ | > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > --> > > > > > > > > | <- 200 (INVITE)| <- 200 > ------ > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > the word 'proxy') > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > overlap dialing, to > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > > the digits > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > > be allowed to > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > INVITEs, until > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > -- > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > FIN-02420 Jorvas Email : > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : > Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 16:01:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08678 for ; Wed, 7 Feb 2001 16:01:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 988324438D; Wed, 7 Feb 2001 16:01:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from crash.netspeak.com (unknown [208.143.140.6]) by lists.bell-labs.com (Postfix) with ESMTP id 0B5DE4438A for ; Wed, 7 Feb 2001 16:00:42 -0500 (EST) Received: by crash.engineering.netspeak.com with Internet Mail Service (5.5.2650.21) id ; Wed, 7 Feb 2001 15:59:36 -0500 Message-ID: <6C5713970B1FD411ACBE00AA00DCD9A61BCF83@crash.engineering.netspeak.com> From: Kevin Wang To: "'Rohan Mahy'" , sip@lists.bell-labs.com Subject: RE: [SIP] New version of message waiting draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 7 Feb 2001 15:59:34 -0500 I have 2 questions about this message waiting draft: (1) In the 2nd paragraph of section 5.1, "The Subscriber MAY also explicitly fetch the current status at any time." How does a subscriber fetch the status? Based on the draft, my guess is that the subscriber sends a re-SUBSCRIBER message and expects the current status in a NOTIFY message. Could the subscriber expect the current status in the 200 OK? (In this way, we do not need that NOTIFY message for re-synchronization). (2) I notice that there is no user's message information in the NOTIFY message for re-synchronization. (There is user's message information in the NOTIFY message when the status of the messages changes.) If a UA is shutted down abnormally and lost all the information, how can it get the user's message information when it is restarted? Thanks, Kevin Wang Senior Software Engineer NetSpeak Co. Boca Raton, FL 33437 > -----Original Message----- > From: Rohan Mahy [SMTP:rohan@cisco.com] > Sent: Wednesday, February 07, 2001 11:26 AM > To: sip@lists.bell-labs.com > Subject: [SIP] New version of message waiting draft > > Hi, > > I just finished a new version of the message waiting draft from Ilya Slain > and I. Until it appears in the archives it is available at: > > ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-message-waiting-01.txt > > thanks, > -rohan > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 16:23:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09202 for ; Wed, 7 Feb 2001 16:23:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 379D6443D0; Wed, 7 Feb 2001 16:23:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id C5D4A44352 for ; Wed, 7 Feb 2001 16:22:04 -0500 (EST) Received: from overnight.cisco.com (overnight.cisco.com [171.71.154.85]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA08849; Wed, 7 Feb 2001 13:22:17 -0800 (PST) Received: from cisco.com (dhcp-128-107-133-83.cisco.com [128.107.133.83]) by overnight.cisco.com (Mirapoint) with ESMTP id AAB12990 (AUTH tfu); Wed, 7 Feb 2001 13:22:03 -0800 (PST) Message-ID: <3A81BD77.1CD3CB06@cisco.com> From: Taichi Fu Reply-To: tfu@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo Cc: Keith.Robinson@marconi.com, sip@lists.bell-labs.com Subject: Re: [SIP] Overlap call setup References: <200102071007.CAA08604@cisco.com> <3A816987.11AC8D6A@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 07 Feb 2001 13:26:15 -0800 Content-Transfer-Encoding: 7bit Gonzalo, One more question and comment inline. Regards, Taichi Gonzalo Camarillo wrote: > > Hello, > > Taichi Fu wrote: > > > > Hi, Gonzalo, > > > > Some comments on three points in discussion. > > > > (1) > > >The same way that nodes handling overlap signalling do not release the > > >call upon reception of a 484, they will not generate ACMs upon reception > > >of a 183 without SDP and without an ancapsulated ACM... we might want to > > >add this clarification to the draft. > > > > One potential issue of this is 183 without SDP can also be interpreted as PSTN gateway (and the media gateway it associates with) needs to play (local) ringback for a SIP to PSTN call toward PSTN side phone for the cases the ringback cannot come from the remote SIP phone. > > > > This is wrong. If local alerting has to be performed the proper 1xx > response is 180 Ringing. This has been pointed out several times in the > mailing list. Be a bit more general, is it also possible to play some local announcement (other than ringing) to PSTN side after received 183 without SDP? If so, how to differentiate? To interpret 183 without SDP as 'dialing incomplete so no ACM yet' only is a rather strong assertion and I see no advantage of it over a dedicated response code or reason phrase. > > This can be resolved using a different Reason Phrase as Keith already indicated or another status code (186). To me it is better if a SIP status code always has unique semantics. > > We discussed this idea also, and finally 183 seems OK for this > (providing a contact header for the gateway handling the call). > > > > > (2) > > >Why would you want to limit a call to one call leg?? > > If I understand correctly, the issue of multiple call legs appear becauses of definition of call leg. In the case of multiple INVITE with different To headers with accumulated digits (as your sip-isup draft suggested), if we relax that definition slightly: two messages belong to the same call leg if the number in one To header is a prefix of the number in another and the other conditions of the definition are met. To limit its impact, we can allow this change only on a SIP device (proxy) that interfaces with a PSTN gateway if possible (for pure SIP networks, the rfc definition is still followed). This way CSeq is useful. > > I do not think tha streching teh definition of a call leg for a > particular interworking case is a good idea. I rather let the definition > as it is. We do not need to change it. > > > > > I agree to have multiple call legs is fine in theory, but it is kind of against intuition to me and it might add some implementaion overhead too. > > There are scenarios where a single call can have multiple call legs. > Multiple call legs are present in SIP since the beginning. I do not > think we should discuss them now. It should be clear from this thread thay it is in the context of overlap signalling that I am not so in favor of multiple call legs. It is kinds of artificial. After all, all those To headers convey just one number and to me semantically to group them into one call leg is cleaner to understand and to implement. Anyway, it is not a big issue and to have a general consensus is probably more important than to find the optimal. > > > > > (3) INFO or To header for subsequent digits > > I agree with your thoughts on using TO instead of INFO. However one obvious advantage of INFO is the saving of one message (ACK). > > If we take into account all the problems related to the use of INFO, a > message saved is not a big gain. > > Regards, > > Gonzalo > > > > > Regards, > > Taichi > > > > >Tue, 06 Feb 2001 23:11:50 +0200 > > >Gonzalo Camarillo wrote: > > > > > >Hello, > > > > > >Thanks for the pointer. Answers inline: > > > > > >Keith Robinson wrote: > > >> > > >> Attached is an earlier posting I raised highlighting my concerns with some of > > >> the > > >> mechanisms outlined in the sip-isup document. This is the source of recent > > >> discussions. > > >> > > >> Regards, > > >> > > >> K. Robinson > > >> ---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 06/02/2001 16:42 > > >> --------------------------- > > >> > > >> 31/01/2001 16:34 > > >> Keith Robinson > > >> > > >> To: "Joshua Moloney" @ MCEXT > > >> cc: sip@lists.bell-labs.com@MCEXT > > >> > > >> Subject: Re: [SIP] Overlap call setup (Document link: Keith Robinson) > > >> > > >> I have recently been trying to get clarification on the implemenation of > > >> overlap sending; see attached for the discussion that has taken place > > >> so far. > > >> > > >> Certainly, the mechanism outlined (very sketchily) in RFC2543bis-02 sect 4.2.1 > > >> is fundamentally flawed. The Request-URI cannot be used to carry extra digits > > >> as the Record-Route/Route mechanism would end up overwriting the R-URI > > >> and therefore the subsequent digits would be lost. > > >> > > >> This then leads to the idea of using the TO field as described in > > >> sip-isup-00-00.txt; > > >> however, I have the following issues with the mechanisms described in this > > >> document : > > >> > > >> As the TO field is different on each subsequent INVITE, then it is a new call > > >> leg > > >> on an existing call id; RFC2543bis-02 sect. 11.5 does not state what a UAS > > >> should make of this. If you follow the logic in 11.5 you get to case (3), but > > >> here it only defines the behaviour if the TO and FROM fields match. > > >> > > > > > > > > >I do not see here a big problem for a UA. If the UA is a gateway, it > > >will handle the overlap signalling properly. If it is a pure SIP UA, it > > >will answer the first INVITE with a 484 (or "Not found response") and > > >process the second INVITE properly. > > > > > > > > >> The 484 sent backwards kills that call attempt (but not the state for that > > >> Call-Id - > > >> is this problematic for intermediate proxies ?) so subsequent INVITEs will > > >> actually be initial INVITEs. As these INVITEs must get to the same terminating > > >> UAS, > > >> the originating UAC will have to create a ROUTE header in an initial INVITE > > >> using , > > >> at least the CONTACT address from the 484. This implies the use of source > > >> routing, an > > >> issue that I don't believe has been fully resolved, and even if it is and > > >> becomes part > > >> of the base protocol some administrations may be reluctant to admit initial > > >> INVITEs > > >> which try to circumvent their routing policy, so may reject such INVITEs. > > >> > > > > > > > > >There was a big thread about source routing. This kind of source routing > > >is fine. Current proxies handle it properly. > > > > > >If a proxy sees an INVITe with a route header, it does not know if it is > > >the first INVITE or a re-INVITE. Thus, it will work properly. > > > > > >Even if the proxy stores state and it receives a INVITE (non re-INVITE) > > >with a route header, it should honor it. Otherwise, the proxy is not > > >robust. This allows a call stateful proxy to lose state, re-boot and > > >still be able to route requests properly. > > > > > > > > > > > >> Also on the above point, the CONTACT address in the 484 must have the same > > >> semantics as that in a 200 response so that a ROUTE header can be built; however > > >> RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in 4XX responses > > >> indicates a location where additional error information can be found. Indeed, in > > >> a recent > > >> thread entitled Announcements in SIP (401 & 407 Contact) J. Rosenberg believes > > >> that > > >> Record-Route does not make sense in any non-200 response. > > > > > >This contact header that is going to be used is the one present in the > > >183, not in the 484. This solves the problem of several IAMs al the same > > >time. If the answer was a 484, no IAM was sent. Thus, the next re-INVITE > > >with more digits can be very well handled by a different gateway. > > > > > > > > >> > > >> I would raise the question of whether the 484 response has any use in overlap > > >> sending > > >> (certainly in the case of ISUP) at all. > > > > > >484 responses are not very useful in this scenario, but they might be > > >useful in anothers (when a UA can ask the user to type more digits, for > > >instance). > > > > > > > > > If a node receives insufficient digits > > >> to decode than it will wait until it receives some more from the preceding node > > >> (or end of > > >> dialling timers mature). If the preceding node receives subsequent digits and > > >> end of dialling > > >> has not been detected then it will pass them on. If the 484 indicated the > > >> minimum number of > > >> digits before a decode could take place, then it would be useful in cutting down > > >> the number > > >> of subseqent messages sent. > > >> > > >> Indeed, isup-sip-00.txt does cover the mechanism where a 183 is sent, and not a > > >> 484. > > >> The case in point is covered in sect. 11.3 (Example of SIP bridging and overlap > > >> signalling); > > >> However, I have the following issues with this mechanism: > > >> > > >> As before relies on source routing. > > > > > >See comments above about this type of source routing. > > > > > >> > > >> Relies on proxies sending requests on new call legs but existing call-ids to the > > >> same > > >> downstream server; fine if you administer these proxies, what if you don't ? > > > > > >Why would you want to limit a call to one call leg?? > > > > > >> (Lots of > > >> wasted IAMs generated). > > > > > >Lots of IAMs????? > > > > > >The situation where more than one (typically two) IAMs are generated is > > >when the 183 arrived to the ingrees gateway after it sent the first > > >re-INVITE. This situation is ulikely to happen anyway, because if you > > >receive subsequent digits so fast (faster than a RTT), you should > > >implement a timer, and not send LOTS of SAMs anyway. > > > > > > > > >> The mechanism should not send 5 (subsequent INVITE) > > >> until it has received an acknowledgement (probably not 100) from the first. > > > > > >Again a timer configuration problem. You can, and your re-INVITE will > > >most likelt reach the same egrees gateway as the 1st one... but it might > > >reach a different one. Thus, the ingrees gateway should be aware of this > > >and be ready for canceling one of the TWO IAMs sent if this happen. > > > > > >But again, this situation is not common. > > > > > >> Alternatively, > > >> the Reason-Phrase could detail more specifically the exact progress of the call > > >> ("Decoding Address" > > >> in this case ?) so that the ACM is not generated unconditionally. > > >> > > >> Sect. 11.2 encourages gateways "to return a183 Session Progress with a Contact > > >> header as soon as they receive an INVITE that they are going to handle and might > > >> contain > > >> an incomplete number". Presumably this is to allow the UAC to build a ROUTE so > > >> that subsequent > > >> INVITEs get to the appropriate UAS. > > > > > >YES. > > > > > > > > > > > >> Sect 7.2.3 indicates that a node receiving a > > >> 183 prior to generating > > >> an ACM should generate an ACM. Applied together these rules may cause a prior > > >> node to never > > >> send on any subsequent digits and overlap sending would fail. > > > > > >The same way that nodes handling overlap signalling do not release the > > >call upon reception of a 484, they will not generate ACMs upon reception > > >of a 183 without SDP and without an ancapsulated ACM... we might want to > > >add this clarification to the draft. > > > > > >> > > >> I think an approach is required whereby subsequent digits are sent on the same > > >> call leg as the > > >> initial INVITE; either multiple INVITEs are allowed before 200 OK (already > > >> suggested by J. Rosenberg > > >> in a different context) > > > > > >Stacking requests is not a good solution in this case. It leads to a lot > > >of problems that we certainly want to avoid. > > > > > >> , or the INFO method is used. > > > > > >If INFO is used any vanilla SIP UA should implement INFO in order tor > > >receive calls/sessions that use overlap signalling. One of the most > > >important requirements for overlap signalling in SIP was that a vanilla > > >SIP UA could handle it. > > > > > > In both cases the TO field > > >> will have to remain the > > >> same so a new header (or message body type) is required to convey the digits. > > > > > >Again, we do not want to implement this in vanilla SIP UAs. > > > > > >Best regards, > > > > > >Gonzalo > > > > > >> Also, replace the 484 > > >> with, say, 18X indicating the minimum number of digits required, perhaps in the > > >> Reason-Phrase header. > > >> > > >> Regards, > > >> > > >> Keith Robinson. > > >> > > >> "Joshua Moloney" on 31/01/2001 10:49:33 > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> To: sip@lists.bell-labs.com > > >> > > >> cc: (bcc: Keith Robinson/MAIN/MC1) > > >> > > >> > > >> > > >> Subject: [SIP] Overlap call setup > > >> > > >> > > >> Greetings, > > >> > > >> I would like to ask for clarification regarding the implementation of > > >> Overlap. > > >> > > >> I'll begin by referring to paragraph 3, section 6.1.2 of > > >> "draft-ietf-isup-sip-00": > > >> > > >> It is stated that INVITEs sent after the first one (containing extra digits > > >> in the 'To' field) are to be treated as new Call-Legs, seeing as the > > >> contents of their 'To' headers differ. As such, there is no relationship > > >> between their CSeq values. > > >> > > >> If this is the case, how is it possible to ensure correct digit ordering > > >> over an 'unreliable' transport layer like UDP? It would seem logical that > > >> the call originator _would_ use contiguous CSeq values, as it would be > > >> 'aware' of the fact that the INVITEs are for the same call. > > >> > > >> I believe that this issue was raised on the SIP list on 19 November 1999 by > > >> Gonzalo C and Jonathan R. The subject of the messages was "Re: Comments on > > >> draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of the exchange > > >> appeared to be an agreement that CSeq ordering should be employed. > > >> > > >> However, does this in any way imply that under such circumstances the > > >> INVITEs would/should belong to the same Call-Leg? After all, the concept of > > >> Overlap does not seem to 'fit in' with the concept behind multiple Call-Legs > > >> anyway. > > >> > > >> If there has been a change in thinking behind the problem, and the latest > > >> draft is correct, please could you explain how the ordering problem will be > > >> overcome. If not, perhaps the draft needs modification to include these > > >> considerations... > > >> > > >> Regards, > > >> > > >> Josh Moloney > > >> > > >> ------------------------------------------------------------------------ > > >> Name: att1.htm > > >> att1.htm Type: Hypertext Markup Language (text/html) > > >> Encoding: base64 > > >> Description: Internet HTML > > > > > >-- > > >Gonzalo Camarillo Phone : +358 9 299 33 71 > > >Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > >Telecom R&D Fax : +358 9 299 30 52 > > >FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > >Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > Previous message: [SIP] Overlap call setup > > > Next message: [SIP] Re: Location information > > > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > > > > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 16:38:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09478 for ; Wed, 7 Feb 2001 16:38:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B9A1E44352; Wed, 7 Feb 2001 16:38:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (HSE-Kitchener-ppp194190.sympatico.ca [64.229.12.31]) by lists.bell-labs.com (Postfix) with ESMTP id 5C18B44336 for ; Wed, 7 Feb 2001 16:37:25 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 7 Feb 2001 16:40:05 -0500 (EST) From: Billy Biggs To: Robert Sparks Cc: Rick Dean , Ben Campbell , SIP List Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt Message-ID: <20010207164005.A888@div8.net> References: <9BF66EBF6BEFD942915B4D4D45C051F30475C0@DYN-TX-EXCH-001.dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F30475C0@DYN-TX-EXCH-001.dynamicsoft.com>; from rsparks@dynamicsoft.com on Wed, Feb 07, 2001 at 03:07:23PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 7 Feb 2001 16:40:05 -0500 Robert Sparks (rsparks@dynamicsoft.com): > Rick - characterizing the requirement to request permission from the > user before proceeding as doing some form of interactive query is > misleading. > > The REFER draft (in fact, the original TRANSFER draft) states: > A UA receiving a well-formed REFER request SHOULD request > approval from the user to proceed (this request could be > interactive or through configuration). > > The parenthetical comment is there for a reason. Current generation > clients will have configured policy that grants this approval, then > next round will have at least that and maybe, hopefully, something > more. We should rephrase it to say that any policy decisions must not ever be interactive, but may be subject to local configuration policy. However, unlike your REFER draft, a HANDOFF (MOVE? TRANSFER?) is useless if it cannot be performed immediately. The intent is to smoothly transition from a 3-way bridged conference to a 2-way call between the unconnected participants. Regardless, in many (most?) cases the recipient of the HANDOFF will be a call control server or PSTN gateway, which will be forced to rely on local policy. -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 7 21:56:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15511 for ; Wed, 7 Feb 2001 21:56:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D6C7044376; Wed, 7 Feb 2001 21:56:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hoteldns02.stsn.com (p134.usslc13.stsn.com [208.32.226.134]) by lists.bell-labs.com (Postfix) with ESMTP id F140A44336 for ; Wed, 7 Feb 2001 21:55:09 -0500 (EST) Received: from eburger ([10.81.136.63]) by hoteldns02.stsn.com (8.11.0/8.11.0) with SMTP id f182rg122366 for ; Wed, 7 Feb 2001 19:53:42 -0700 From: "Eric Burger" To: Subject: RE: [SIP] over-length message 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.4522.1200 Importance: Normal In-Reply-To: <3A800F42.6D1A99A7@lmf.ericsson.se> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 7 Feb 2001 20:55:40 -0500 Content-Transfer-Encoding: 7bit His point wasn't that it wouldn't fit into a UDP MTU, it's that it might not fit into an ATM MTU, for example. How's this for a scenario: lots of VIA's and computer generated URL's. That will pretty quickly fill a 4K ATM AAL5 MTU, or even the "safe" 540 byte UDP WAN MTU. Reminds me of the "how big should my buffer be" thread... The answer is "boundless". > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Christer Holmberg > Sent: Tuesday, February 06, 2001 9:51 AM > To: Takumi Ohba [snip] > I think it has been agreed that a SIP message, including possible MIME > message bodies, should "fit" into a single UDP MTU. Do you have an > example where that length would not be enough? [snip] > > One example; > > If a user want to attach very large data to a SIP message as a > MIME part, > > but it make the message longer than the MTU, what should the user do? > > The only choice to the user is to give up attaching the data? > > > > Another example; > > A SIP proxy may receive a larger message that it can transfer. This may > > happen when the proxy uses different transport layers for incoming and > > outgoing links and the outgoing link has smaller maximum datagram packet > > size than that for the incoming link. > > For example, the incoming link uses UDP (max: 64k octets) and > the outgoing > > link uses signalling AAL (max: 4k octets). The proxy may > receive 5k-octet > > message if the MTU permits it, but it cannot transfer the message to the > > outgoing signalling AAL link. > > > > In this case, what should the proxy do? > > Should it give up transferring the massage itself, or shorten > the message > > and transfer it by discarding less important part of the > message? In the > > latter case, how can the proxy identify less important part of > the message? _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 08:23:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06242 for ; Thu, 8 Feb 2001 08:23:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 026CD44403; Thu, 8 Feb 2001 08:23:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id AAF2444336 for ; Thu, 8 Feb 2001 08:22:43 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id IAA28633; Thu, 8 Feb 2001 08:25:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR8715>; Thu, 8 Feb 2001 08:19:01 -0500 Message-ID: From: Jonathan Rosenberg To: Eric Burger , sip@lists.bell-labs.com Subject: RE: [SIP] over-length message MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 8 Feb 2001 08:18:59 -0500 > -----Original Message----- > From: Eric Burger [mailto:eburger@snowshore.com] > Sent: Wednesday, February 07, 2001 8:56 PM > To: sip@lists.bell-labs.com > Subject: RE: [SIP] over-length message > > > His point wasn't that it wouldn't fit into a UDP MTU, it's > that it might not > fit into an ATM MTU, for example. Well, there is no such thing as a UDP MTU. There is an IP maximum packet size, which is 64k. The MTU is different on each link, and the path MTU is the minimum of the MTU along a message path. Should a packet arrive on a link which is in excess of the MTU, it is fragmented. THis is done at the IP layer, transparent to the applications. So, a proxy simply won't care that a 3k UDP packet arrived over ATM unfragmented, and will depart over ethernet with an MTU of 1500 bytes, requiring fragmentation. Fragmentation is not a great thing, as it has known error exponentiation effects, but functionally, its completely hidden from the proxy. Thus, the problem that has been described does not exist. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 08:25:03 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06304 for ; Thu, 8 Feb 2001 08:25:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DE36544409; Thu, 8 Feb 2001 08:23:19 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 69A5144336 for ; Thu, 8 Feb 2001 08:22:54 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id IAA28644; Thu, 8 Feb 2001 08:25:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR8717>; Thu, 8 Feb 2001 08:19:11 -0500 Message-ID: From: Jonathan Rosenberg To: Billy Biggs , Robert Sparks Cc: Rick Dean , Ben Campbell , SIP List Subject: RE: [SIP] draft-ietf-sip-handoff-00pre8.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 8 Feb 2001 08:19:03 -0500 Sorry for being absent from sipml discussions.... I was on vacation and generally been swamped. Following sip is a lot of work these days. Anyway, a few comments on this. I realize we are discussing it today during the meeting, hopefully this note can help set the stage for those discussions. Here is my summary of the differences between this draft and the REFER draft: 1. additional headers for the triggered invite are specified within a body part of the HANDOFF. In REFER, they are specified as header parameters in the target's URL. I personally dislike the approach taken in HANDOFF. I don't understand why it is needed. There is some gripe about complexity with ? separated headers in a URL, but multipart is, IMHO, far harder. 2. the body of the HANDOFF can have SDP, presumably for simultaneously putting media on hold and initiating the transfer (I believe, please correct if I'm wrong). SDP in REFER has no meaning. I also dislike the approach in HANDOFF. It is turning HANDOFF into a re-INVITE + REFER function. Now, ALGs in firewalls need to process HANDOFF to modify media stream information. B2BUas need to do the same. As a matter of design, sip's approach has been to modularize and separate functions. This is why we changed BYE/Also to REFER followed by BYE. The argument made for the HANDOFF approach is latency and message overhead. I believe this is a red herring in practice, but its a matter of personal taste in protocol design. 3. The reffered-by equivalent in HANDOFF is generated by the transferee, not transferor, and they are not signed. This is a huge security hole. It will allow me to take over call legs that other parties have with each other. Bad. 4. The status of the handoff is conveyed in a re-INVITE in the reverse direction (presumably so that media on hold can be turned off?) if it fails, else a BYE if it succeeds. I don't like the mis-use of INVITE as a means to convey status for a previous transaction. What if there are multiple previous REFER? How is the status correlated to the REFER? What if the triggered generates a 300, which is recursed by the transferee, then a 400? Which is returned? Are reason codes returned? What about warning headers? Sounds like a real notification mechanism is needed here. 5. The triggered INVITE from the HANDOFF can contain a Replaces used to replace the existing call leg between the transferor and target. This causes the target to send a BYE to the transferor. In REFER, the transferor would send a BYE to the target, and this would be based on learning the successful completion of the triggered INVITE. I suppose the argument here is message overhead and latency, once more. I think that covers it. On the issue of method names - if this draft is accepted as a wg document I would definitely want to change the method name. I'm with Pat on this one; it will cause confusion. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Billy Biggs [mailto:billy@billybiggs.com] > Sent: Wednesday, February 07, 2001 4:40 PM > To: Robert Sparks > Cc: Rick Dean; Ben Campbell; SIP List > Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt > > > Robert Sparks (rsparks@dynamicsoft.com): > > > Rick - characterizing the requirement to request permission from the > > user before proceeding as doing some form of interactive query is > > misleading. > > > > The REFER draft (in fact, the original TRANSFER draft) states: > > A UA receiving a well-formed REFER request SHOULD request > > approval from the user to proceed (this request could be > > interactive or through configuration). > > > > The parenthetical comment is there for a reason. Current generation > > clients will have configured policy that grants this approval, then > > next round will have at least that and maybe, hopefully, something > > more. > > We should rephrase it to say that any policy decisions must not ever > be interactive, but may be subject to local configuration policy. > > However, unlike your REFER draft, a HANDOFF (MOVE? TRANSFER?) is > useless if it cannot be performed immediately. The intent is to > smoothly transition from a 3-way bridged conference to a 2-way call > between the unconnected participants. > > Regardless, in many (most?) cases the recipient of the > HANDOFF will be > a call control server or PSTN gateway, which will be forced to rely on > local policy. > > -- > Billy Biggs bbiggs@dumbterm.net > http://www.billybiggs.com/ wbiggs@uwaterloo.ca > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 09:35:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08173 for ; Thu, 8 Feb 2001 09:35:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BF92B44407; Thu, 8 Feb 2001 09:35:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailweb7.rediffmail.com (unknown [202.54.124.152]) by lists.bell-labs.com (Postfix) with SMTP id DE32744336 for ; Thu, 8 Feb 2001 09:34:48 -0500 (EST) Received: (qmail 20164 invoked by uid 510); 8 Feb 2001 13:26:52 -0000 Message-ID: <20010208132652.20161.qmail@mailweb7.rediffmail.com> Received: from unknown (202.152.131.154) by rediffmail.com via HTTP; 08 Feb 2001 13:26:52 -0000 MIME-Version: 1.0 To: "sip@lists.bell-labs.com" From: "Ashhar Farhan" Content-ID: Content-type: text/plain Content-Transfer-Encoding: 7bit Subject: [SIP] NAT, SOCKS 5 proxies, win proxies Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 8 Feb 2001 13:26:52 -0000 Content-Transfer-Encoding: 7bit there are several issues that arise out of NAT and socks 5 traversals and there have been several suggestions about overcoming them. it is very important that we are able to traverse these proxies as most of the enterprises are behind them. 1. most of the schemes and papers submitted on the traversal issues have been suggestions to modify NAT and SOCKS behaviour to fit our shoe. i don't think that this is a workable approach. there are virtually hundreds of NAT and SOCKS implementations all over and if we are aiming at ubiquity, we need to comply with their existing architectures rather than suggesting some of our own. therefore, my suggestion will be to see if it is possible to make SIP work with the existing NAT, SOCKS 5 proxies as well as WinSock proxies. 2. a central problem to all proxy traversals (including that of NAT) is that we can never definitely know the UDP port associate opened by the proxy on behalf of a client behind the proxy server. therefore, the SIP protocol will have to work with an unknown UDP port. 3. The second issue is that RTP too will have to work in conjunction with SIP. therefore, the problem is to correctly identify the UDP port that to be specified in SDP for RTP (and for the purists, even the RTCP). 4. finally, not all clients behind a proxy will be able to open out the 5060 for themselves. 5. a clean approach to these problems is to write an application that co-hosts a state-ful proxy with an RTP relay, that uses the call states maintained within the SIP proxy to correctly route the RTP packets. This application sits on the same machine as the intranet proxy server. the trouble with this approach is that your network admin has to be a fan of RFC2543 to agree to installing a SIP/RTP proxy that of all the horrors relays UDP packets for all (s)he cares. 6. The other option is to coax SIP itself to work with the current NAT/proxy architectures. Let me propose a scheme which is a little too bitter. Recommendations: a) SIP and RTP should be able to work from a single UDP port. By examining the SIP /RTP header, it should be possible to figure out which is which and accordingly process that datagram. this is a pretty radical thing. i am essentially saying the SIP should be able to work as an in-band signalling mechanism. b)If the port and ip address in Contact does not match the actual IP and port address from which a UDP is received, then there should be mechanism of being able to repy back to the address/port from which the request came in. c) The UDP port association may die within a minute, therefore, REGISTER has to be more frequent than 5 minutes. d) In case of NAT, under this scheme, only out going calls will be possible. In order to accept incoming calls, clients behind NAT will have to work through a SIP/RTP proxy that is not necessarily locate on the Intranet. The most important points to consider here are: 1. single port to be used for SIP and RTP, SIP and RTP streaming to be directed to the same address/port from where the original request/response was received. Thus, SIP should be able to indicate "use the port i am talking to you from" to the other side. 2. in case of using a proxy, the port association maybe different for different out-bound destinations, therfore, the media streaming too has to be proxied from the same port as where the SIP is being proxied. - farhan@hotfoon. _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 10:17:24 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09863 for ; Thu, 8 Feb 2001 10:17:19 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 049E84440F; Thu, 8 Feb 2001 10:17:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by lists.bell-labs.com (Postfix) with ESMTP id 2DD0E44336 for ; Thu, 8 Feb 2001 10:16:25 -0500 (EST) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA21934 for ; Thu, 8 Feb 2001 10:15:58 -0500 (EST) Received: from cisco.com (rtp-xdm1.cisco.com [64.102.17.80]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAY52102 (AUTH shbhatna); Thu, 8 Feb 2001 10:16:24 -0500 (EST) Message-ID: <3A82B846.48AB4089@cisco.com> From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Second try - Branch parameter question Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 08 Feb 2001 10:16:22 -0500 Content-Transfer-Encoding: 7bit (a) When a proxy computes the cryptographic hash of From, To, Call-ID, CSeq.seqnum and Request-URI, can it use the unparsed From and To or normalized form of their parsed components. Does the loop detection scheme in the bis-02 version assumes that From header of a looped request or a spiralled request is byte-by-byte same as the From header of the original incoming request ? (Same question for To header) (b) When using the To header, should the proxy include the To tag in the hash computation ? If it did, then ACK will map to a different transaction than the corresponding INVITE ?? Comments ?? Thanks, Shail _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 10:56:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11172 for ; Thu, 8 Feb 2001 10:56:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CC85F44415; Thu, 8 Feb 2001 10:56:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 004F744413 for ; Thu, 8 Feb 2001 10:55:51 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA01505; Thu, 8 Feb 2001 07:56:04 -0800 (PST) Received: from sony-laptop (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with SMTP id AAJ91020; Thu, 8 Feb 2001 07:55:46 -0800 (PST) Message-Id: <4.1.20010208075133.01e92160@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Kevin Wang , sip@lists.bell-labs.com From: Rohan Mahy Subject: RE: [SIP] New version of message waiting draft In-Reply-To: <6C5713970B1FD411ACBE00AA00DCD9A61BCF83@crash.engineering.n etspeak.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 08 Feb 2001 07:56:52 -0800 Hi, At 12:59 PM 2/7/01 , Kevin Wang wrote: >I have 2 questions about this message waiting draft: >(1) In the 2nd paragraph of section 5.1, "The Subscriber MAY also explicitly >fetch the current status at any time." How does a subscriber fetch the >status? Based on the draft, my guess is that the subscriber sends a >re-SUBSCRIBER message and expects the current status in a NOTIFY message. >Could the subscriber expect the current status in the 200 OK? (In this way, >we do not need that NOTIFY message for re-synchronization). you can't put this in the 200, because the SUBSCRIBE might be forked, and only one of the 200s will get back. >(2) I notice that there is no user's message information in the NOTIFY >message for re-synchronization. (There is user's message information in the >NOTIFY message when the status of the messages changes.) If a UA is shutted >down abnormally and lost all the information, how can it get the user's >message information when it is restarted? POP or IMAP. getting this via NOTIFY is not practical. >> -----Original Message----- >> From: Rohan Mahy [SMTP:rohan@cisco.com] >> Sent: Wednesday, February 07, 2001 11:26 AM >> To: sip@lists.bell-labs.com >> Subject: [SIP] New version of message waiting draft >> >> Hi, >> >> I just finished a new version of the message waiting draft from Ilya Slain >> and I. Until it appears in the archives it is available at: >> >> ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-message-waiting-01.txt >> >> thanks, >> -rohan >> >> _______________________________________________ >> This list is for continuing development of the SIP protocol. >> The sip-implementer's list is the place to discuss implementation, >> and to receive advice on understanding existing sip. >> To subscribe to it, send mail to majordomo@cs.columbia.edu with >> "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 11:29:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12250 for ; Thu, 8 Feb 2001 11:29:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9EBBB44419; Thu, 8 Feb 2001 11:29:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 3B83244414 for ; Thu, 8 Feb 2001 11:28:38 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 8 Feb 2001 16:28:38 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA00849; Thu, 8 Feb 2001 16:27:23 GMT From: "Jo Hornsby" To: "Shail Bhatnagar" , Subject: RE: [SIP] Second try - Branch parameter question Message-ID: <001b01c091ec$03d2f440$4e34c3c1@ubiquity.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <3A82B846.48AB4089@cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 8 Feb 2001 16:27:22 -0000 Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > (a) When a proxy computes the cryptographic hash of > From, To, Call-ID, CSeq.seqnum and Request-URI, > can it use the unparsed From and To or normalized > form of their parsed components. > Does the loop detection scheme in the bis-02 > version assumes that From header of a looped > request or a spiralled request is byte-by-byte > same as the From header of the original incoming > request ? (Same question for To header) I would say that, in general, byte-by-byte is far too fragile. Some sort of normalised form sounds like a good way to go. > (b) When using the To header, should the proxy include > the To tag in the hash computation ? If it did, then > ACK will map to a different transaction than the > corresponding INVITE ?? Indeed. I would just go on the To's URI. HTH, - Jo. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 11:35:06 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12411 for ; Thu, 8 Feb 2001 11:35:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EE90E44422; Thu, 8 Feb 2001 11:35:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from crash.netspeak.com (unknown [208.143.140.6]) by lists.bell-labs.com (Postfix) with ESMTP id B441344421 for ; Thu, 8 Feb 2001 11:34:18 -0500 (EST) Received: by crash.engineering.netspeak.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Feb 2001 11:33:07 -0500 Message-ID: <6C5713970B1FD411ACBE00AA00DCD9A61BCF84@crash.engineering.netspeak.com> From: Kevin Wang To: "'Rohan Mahy'" , sip@lists.bell-labs.com Subject: RE: [SIP] New version of message waiting draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 8 Feb 2001 11:33:06 -0500 Hi, I guess I did not make my 2nd question clear. If we look at the NOTIFY message A5 on Page 5, we may find out that the 3rd section and 4th section of the NOTIFY message contain some information (such as message subject, date/time, priority, etc) about the new voicemail messages. However, the NOTIFY message for re-synchronization (for example A3) does not contain that information. So, my question is: if a UA loses its previous data for some reason and restart again, how can the UA retrieve that information (message subject, date/time, priority, etc) from the Notifier? Thanks, -Kevin > -----Original Message----- > From: Rohan Mahy [SMTP:rohan@cisco.com] > Sent: Thursday, February 08, 2001 10:57 AM > To: Kevin Wang; sip@lists.bell-labs.com > Subject: RE: [SIP] New version of message waiting draft > > Hi, > > At 12:59 PM 2/7/01 , Kevin Wang wrote: > >I have 2 questions about this message waiting draft: > >(1) In the 2nd paragraph of section 5.1, "The Subscriber MAY also > explicitly > >fetch the current status at any time." How does a subscriber fetch the > >status? Based on the draft, my guess is that the subscriber sends a > >re-SUBSCRIBER message and expects the current status in a NOTIFY message. > >Could the subscriber expect the current status in the 200 OK? (In this > way, > >we do not need that NOTIFY message for re-synchronization). > > you can't put this in the 200, because the SUBSCRIBE might be forked, and > only one of the 200s will get back. > > >(2) I notice that there is no user's message information in the NOTIFY > >message for re-synchronization. (There is user's message information in > the > >NOTIFY message when the status of the messages changes.) If a UA is > shutted > >down abnormally and lost all the information, how can it get the user's > >message information when it is restarted? > > POP or IMAP. getting this via NOTIFY is not practical. > > >> -----Original Message----- > >> From: Rohan Mahy [SMTP:rohan@cisco.com] > >> Sent: Wednesday, February 07, 2001 11:26 AM > >> To: sip@lists.bell-labs.com > >> Subject: [SIP] New version of message waiting draft > >> > >> Hi, > >> > >> I just finished a new version of the message waiting draft from Ilya > Slain > >> and I. Until it appears in the archives it is available at: > >> > >> ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-message-waiting-01.txt > >> > >> thanks, > >> -rohan > >> > >> _______________________________________________ > >> This list is for continuing development of the SIP protocol. > >> The sip-implementer's list is the place to discuss implementation, > >> and to receive advice on understanding existing sip. > >> To subscribe to it, send mail to majordomo@cs.columbia.edu with > >> "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 12:03:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13185 for ; Thu, 8 Feb 2001 12:03:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 69E8144413; Thu, 8 Feb 2001 12:03:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by lists.bell-labs.com (Postfix) with ESMTP id E58C244336 for ; Thu, 8 Feb 2001 12:02:58 -0500 (EST) Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16]) by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA29294; Thu, 8 Feb 2001 12:02:32 -0500 (EST) Received: from cisco.com (rtp-xdm1.cisco.com [64.102.17.80]) by dingdong.cisco.com (Mirapoint) with ESMTP id AAY55288 (AUTH shbhatna); Thu, 8 Feb 2001 12:02:57 -0500 (EST) Message-ID: <3A82D140.D153A6D3@cisco.com> From: Shail Bhatnagar X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jo Hornsby Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Second try - Branch parameter question References: <001b01c091ec$03d2f440$4e34c3c1@ubiquity.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 08 Feb 2001 12:02:56 -0500 Content-Transfer-Encoding: 7bit Jo, I tend to think that doing URL match for addr-spec of From/To headers and concatenating normalized URL components even for hash computation, is an unnecessary overhead. Practically speaking, every proxy/ua will save the unparsed form of From/To as it came in the first time (or as it sent out the first time) and could do a simple string match on the addr-spec. (I thought URLs cannot have white spaces ??) I don't find the URL matching rules very useful for the addr-spec of From and To headers, but would be forced to use them. Shail Jo Hornsby wrote: > > Shail Bhatnagar wrote: > > (a) When a proxy computes the cryptographic hash of > > From, To, Call-ID, CSeq.seqnum and Request-URI, > > can it use the unparsed From and To or normalized > > form of their parsed components. > > Does the loop detection scheme in the bis-02 > > version assumes that From header of a looped > > request or a spiralled request is byte-by-byte > > same as the From header of the original incoming > > request ? (Same question for To header) > > I would say that, in general, byte-by-byte is far too > fragile. Some sort of normalised form sounds like a > good way to go. > > > (b) When using the To header, should the proxy include > > the To tag in the hash computation ? If it did, then > > ACK will map to a different transaction than the > > corresponding INVITE ?? > > Indeed. I would just go on the To's URI. > > HTH, > > - Jo. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 12:53:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14788 for ; Thu, 8 Feb 2001 12:53:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 630F44435F; Thu, 8 Feb 2001 12:53:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id 36F6C44336 for ; Thu, 8 Feb 2001 12:52:10 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qhars002.nortel.com; Thu, 8 Feb 2001 17:50:49 +0000 Received: from nwcwi1a.europe.nortel.com ([47.30.176.175]) by znsgd00t.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1RT7G2N6; Thu, 8 Feb 2001 17:50:17 -0000 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2650.21) id <1RWTAJBS>; Thu, 8 Feb 2001 17:50:17 -0000 Message-ID: X-Sybari-Space: 00000000 00000000 00000000 From: "Mark Watson" To: Christer Holmberg , sip@lists.bell-labs.com Cc: Keith Robinson , "Tom-PT Taylor" , "Joshua Moloney" Subject: RE: [SIP] Overlap call setup MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C091F7.96649E20" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 8 Feb 2001 17:50:13 -0000 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_01C091F7.96649E20 Content-Type: text/plain; charset="ISO-8859-1" I think this is a good proposal. I would suggest that the overlap capability is offered in the INVITE and accepted in the response from the UAS. Otherwise we get problems (e.g. user on standard SIP client dials under-length number by mistake, PSTN gateway sends IAM and returns response to UAC, but now the PSTN is waiting for more digits so we do not get failure until something times out.) I think the idea of including the number of digits to send in a reponse was not that the UAS would know the total number of digits needed, but that it might know 'I need at least 3 more digits to route this'. If it signalled this information back, the UAC could wait 'till it had got 3 more digits and we would save two messages, that's all. Regards, Mark Watson Nortel Networks > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: 06 February 2001 07:52 > To: sip@lists.bell-labs.com > Cc: Keith Robinson; Taylor, Tom-PT [NORSE:B901:EXCH]; Moloney, Joshua > [MDN05:CT07:EXCH] > Subject: Re: [SIP] Overlap call setup > > > > Hi, > > I had a look through the thread, and I still have one issue. > > I do NOT think that we can assume that the PSTN GW will know how many > digits are needed to route a call to the PSTN end-user, so I > don't think > we can use provisional responses to "ask" for more digits. Yes, the GW > may know how many digits it needs to route the call to the next PSTN > switch, but it doesn't know how many digits that switch needes, etc... > > So, my proposal would be: > > 1. When the INVITE has been routed to the GW UAS, the only > response sent > back is 100. That would, of course, assume that we have to add Contact > and/or Record-Route headers in the 100 response... > > 2. Then, the UAC would use INFO to send more digits to the UAC, which > would forward them as SAMs. No, the GW would not "ask" for > more digits, > but does it really have to? If the UAC wants to send more > digits, it can > do so anyway, so... > > 3. THEN, when the GW receives ACM from the PSTN side, it would send a > 18x provisional response back to the UAC. The UAC would now > know that no > more digits are needed to route the call. Of course, we can get a > "please enter your code"-message, and be asked to provide digits, but > that is another issue. > > We should remember that the GW SIP UAS may not even know that > the UAC is > sending more digits, because it may send them in encapsulated ISUP > messages. In that case, however, the GW SIP UAS will not know > it's SAMs, > so it couldn't make a decission on if to send 186 "Gimme more > digits" or > not... > > > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > > > Christer Holmberg wrote: > > > > Hi, > > > > Keith Robinson wrote: > > > > > >Christer wrote ; > > > > > >>Again, we assume that the GWs support ISUP transparency, > because if the > > >>GW only supports ISUP/SIP mapping it will not be able to > know if to > > >>generate an ACM when the 18x is received - even if the GW > would be smart > > >>enough to notice that there is SOME ISUP message in the > 180 response. > > > > > >Surely, if a GW is mapping ISUP to SIP (and vice versa) > then there must >be rules to dictate which SIP messages map > to which ISUP messages and in >what context. In fact, aren't > these the rules we are debating ? The point >being that even > if a GW is ONLY performing SIP/ISUP/SIP mapping > > >then it STILL MUST know when to genrate the ACM as part of > the mapping >function, REGARDLESS of transparency. > > > > Yes, and since it may not be possible to have rules when a > 180 should > > generate a ACM, and when it should not. So, in the case of overlap > > dialing, when the 18x is only used to "ask" for more digits, my > > suggestion was to use a specific provisional response code > that would > > not generate an ACM. > > > > Then, when we want an ACM to be generated, no matter if ISUP > > transparency is supported or not, we would send a 180 Alerting. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > Regards, > > > > > > K. Robinson. > > > > > > Christer Holmberg on > 05/02/2001 11:10:49 > > > > > > > > > > > > > > > > > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > > > > > cc: Tom-PT Taylor , > > > sip@lists.bell-labs.com, Joshua Moloney > > > > > > > > > > > > > > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > Hi, > > > > > > Again, we assume that the GWs support ISUP transparency, > because if the > > > GW only supports ISUP/SIP mapping it will not be able to > know if to > > > generate an ACM when the 18x is received - even if the GW > would be smart > > > enough to notice that there is SOME ISUP message in the > 180 response. > > > > > > Personally, I still think that a separate provisional > response code > > > (I've been using 186 as an example) should be used, and > any UAC (SIP > > > phone or PSTN GW) supporting overlap dialing must understand the > > > response. And, if the UAC knows it has already sent all digits, > > > receiving a 186 could, for example, cause it to send a > CANCEL to the > > > INVITE, instead of waiting for the ISUP digit timers to expire and > > > receive a 486 final response. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > Keith Robinson wrote: > > > > > > > > In the absence of receiving an encapsulated ACM, the ingress > > > > gateway could generate its own ACM when it receives a > 180 Alerting; this > > > > response must mean it is safe to assume call routing is complete > > > > and caters for terminations within a SIP network. > Thought needs to be > > > > given to scenarios where a non-200 final response is > received, say 486 > > > > Busy, as in these cases 180 Alerting, probably, > wouldn't be generated. > > > > > > > > Regards, > > > > > > > > Keith. > > > > > > > > "Tom-PT Taylor" on > 02/02/2001 14:12:39 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Christer Holmberg > > > > > > > > > > > > cc: Keith Robinson/MAIN/MC1@MCMAIN, > > > > sip@lists.bell-labs.com, "Joshua Moloney" > > > > > > > > > > > > > > > > > > > > Subject: RE: [SIP] Overlap call setup > > > > > > > > > > > > Replies below. > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > Sent: Friday, February 02, 2001 1:17 AM > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > > > > > [MDN05:CT07:EXCH] > > > > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I see a couple of issues here. > > > > > > > > > > 1. Even if the UAS returns Accept-Encoding: application/isup, > > > > > it doesn't > > > > > mean that it is going to send an encapsulated ACM. > > > > > > > > [PTT] > > > > Agreed, and that is a nasty point. It's related to the > next one. > > > > > > > > > > > > > > 2. Even if it the UAS GW would send an encapsulated ACM, it > > > > > is not sure > > > > > that the UAC GW supports ISUP transparency in the > first place. It may > > > > > support only ISUP/SIP mapping, for example. > > > > > > > > [PTT] > > > > That one is easily solved, in two ways. First, by > hypothesis the UAC GW has > > > > encapsulated the IAM in the initial INVITE. It can > also include an > > > > Accept-Content: header. In fact, this is essential so > that the two ends can > > > > negotiate stuff like ISUP version or the fact that one > of them really wants > > > > to propagate Q.931. > > > > > > > > So, given that the UAS GW has received an encapsulated IAM, the > > > > Accept-Content: header indicates that it did or did not find the > > > > encapsulated content acceptable. If it did find it > acceptable, how do we > > > > oblige it to keep up its end of the conversation? I > expect the behaviour > > > > has to be specified in the SIP-T umbrella document, and > SIP/GSTN gateway > > > > products have to indicate their conformity to that document. > > > > > > > > > > > > > > I think that part of the problem, which is not > related only to overlap > > > > > dialling, is that a SIP/PSTN GW from a SIP point of > view is an SIP UA, > > > > > and from a SIP point of view should act like an SIP UA. Maybe > > > > > it should > > > > > be considered as a SIP node of its own, with GW > specific functional > > > > > requirements. The only thing we have now is how to map > > > > > between ISUP and > > > > > SIP, but that is obviously not enough. ??? > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > Name: att1.htm > > > > att1.htm Type: Hypertext Markup Language (text/html) > > > > Encoding: base64 > > > > Description: Internet HTML > ------_=_NextPart_001_01C091F7.96649E20 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Overlap call setup

I think this is a good proposal.

I would suggest that the overlap capability is = offered in the INVITE and accepted in the response from the UAS. = Otherwise we get problems (e.g. user on standard SIP client dials = under-length number by mistake, PSTN gateway sends IAM and returns = response to UAC, but now the PSTN is waiting for more digits so we do = not get failure until something times out.)

I think the idea of including the number of digits to = send in a reponse was not that the UAS would know the total number of = digits needed, but that it might know 'I need at least 3 more digits to = route this'. If it signalled this information back, the UAC could wait = 'till it had got 3 more digits and we would save two messages, that's = all.

Regards,

Mark Watson
Nortel Networks


> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: 06 February 2001 07:52
> To: sip@lists.bell-labs.com
> Cc: Keith Robinson; Taylor, Tom-PT = [NORSE:B901:EXCH]; Moloney, Joshua
> [MDN05:CT07:EXCH]
> Subject: Re: [SIP] Overlap call setup
>
>
>
> Hi,
>
> I had a look through the thread, and I still = have one issue.
>
> I do NOT think that we can assume that the PSTN = GW will know how many
> digits are needed to route a call to the PSTN = end-user, so I
> don't think
> we can use provisional responses to = "ask" for more digits. Yes, the GW
> may know how many digits it needs to route the = call to the next PSTN
> switch, but it doesn't know how many digits = that switch needes, etc...
>
> So, my proposal would be:
>
> 1. When the INVITE has been routed to the GW = UAS, the only
> response sent
> back is 100. That would, of course, assume that = we have to add Contact
> and/or Record-Route headers in the 100 = response...
>
> 2. Then, the UAC would use INFO to send more = digits to the UAC, which
> would forward them as SAMs. No, the GW would = not "ask" for
> more digits,
> but does it really have to? If the UAC wants to = send more
> digits, it can
> do so anyway, so...
>
> 3. THEN, when the GW receives ACM from the PSTN = side, it would send a
> 18x provisional response back to the UAC. The = UAC would now
> know that no
> more digits are needed to route the call. Of = course, we can get a
> "please enter your code"-message, and = be asked to provide digits, but
> that is another issue.
>
> We should remember that the GW SIP UAS may not = even know that
> the UAC is
> sending more digits, because it may send them = in encapsulated ISUP
> messages. In that case, however, the GW SIP UAS = will not know
> it's SAMs,
> so it couldn't make a decission on if to send = 186 "Gimme more
> digits" or
> not...
>
>
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
>
>
>
>
>
>
>
> Christer Holmberg wrote:
> >
> > Hi,
> >
> > Keith Robinson wrote:
> > >
> > >Christer wrote ;
> > >
> > >>Again, we assume that the GWs = support ISUP transparency,
> because if the
> > >>GW only supports ISUP/SIP mapping = it will not be able to
> know if to
> > >>generate an ACM when the 18x is = received - even if the GW
> would be smart
> > >>enough to notice that there is = SOME ISUP message in the
> 180 response.
> > >
> > >Surely, if a GW is mapping ISUP to SIP = (and vice versa)
> then there must >be rules to dictate which = SIP messages map
> to which ISUP messages and in >what context. = In fact, aren't
> these the rules we are debating ? The point = >being that even
> if a GW is ONLY performing SIP/ISUP/SIP = mapping
> > >then it STILL MUST know when to = genrate the ACM as part of
> the mapping >function, REGARDLESS of = transparency.
> >
> > Yes, and since it may not be possible to = have rules when a
> 180 should
> > generate a ACM, and when it should not. = So, in the case of overlap
> > dialing, when the 18x is only used to = "ask" for more digits, my
> > suggestion was to use a specific = provisional response code
> that would
> > not generate an ACM.
> >
> > Then, when we want an ACM to be generated, = no matter if ISUP
> > transparency is supported or not, we would = send a 180 Alerting.
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> > >
> > > Regards,
> > >
> > > K. Robinson.
> > >
> > > Christer Holmberg = <christer.holmberg@lmf.ericsson.se> on
> 05/02/2001 11:10:49
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  = To:      Keith Robinson/MAIN/MC1@MCMAIN
> > >
> > >  = cc:      Tom-PT Taylor = <taylor@nortelnetworks.com>,
> > = >           = sip@lists.bell-labs.com, Joshua Moloney
> > = >           = <jmoloney@nortelnetworks.com>
> > >
> > >
> > >
> > >  Subject: Re: [SIP] Overlap call = setup
> > >
> > >
> > > Hi,
> > >
> > > Again, we assume that the GWs support = ISUP transparency,
> because if the
> > > GW only supports ISUP/SIP mapping it = will not be able to
> know if to
> > > generate an ACM when the 18x is = received - even if the GW
> would be smart
> > > enough to notice that there is SOME = ISUP message in the
> 180 response.
> > >
> > > Personally, I still think that a = separate provisional
> response code
> > > (I've been using 186 as an example) = should be used, and
> any UAC (SIP
> > > phone or PSTN GW) supporting overlap = dialing must understand the
> > > response. And, if the UAC knows it = has already sent all digits,
> > > receiving a 186 could, for example, = cause it to send a
> CANCEL to the
> > > INVITE, instead of waiting for the = ISUP digit timers to expire and
> > > receive a 486 final response.
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > > Keith Robinson wrote:
> > > >
> > > > In the absence of receiving an = encapsulated ACM, the ingress
> > > > gateway could generate its own = ACM when it receives a
> 180 Alerting; this
> > > > response must mean it is safe to = assume call routing is complete
> > > > and caters for terminations = within a SIP network.
> Thought needs to be
> > > > given to scenarios where a = non-200 final response is
> received, say 486
> > > > Busy, as in these cases 180 = Alerting, probably,
> wouldn't be generated.
> > > >
> > > > Regards,
> > > >
> > > > Keith.
> > > >
> > > > "Tom-PT Taylor" = <taylor@nortelnetworks.com> on
> 02/02/2001 14:12:39
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  = To:      Christer Holmberg
> > > = >           = <christer.holmberg@lmf.ericsson.se>
> > > >
> > > >  = cc:      Keith = Robinson/MAIN/MC1@MCMAIN,
> > > = >           = sip@lists.bell-labs.com, "Joshua Moloney"
> > > = >           = <jmoloney@nortelnetworks.com>
> > > >
> > > >
> > > >
> > > >  Subject: RE: [SIP] Overlap = call setup
> > > >
> > > >
> > > > Replies below.
> > > >
> > > > > -----Original = Message-----
> > > > > From: Christer Holmberg =
> [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > > > > Sent: Friday, February 02, = 2001 1:17 AM
> > > > > To: Taylor, Tom-PT = [NORSE:B901:EXCH]
> > > > > Cc: Keith Robinson; = sip@lists.bell-labs.com; Moloney, Joshua
> > > > > [MDN05:CT07:EXCH]
> > > > > Subject: Re: [SIP] Overlap = call setup
> > > > >
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I see a couple of issues = here.
> > > > >
> > > > > 1. Even if the UAS returns = Accept-Encoding: application/isup,
> > > > > it doesn't
> > > > > mean that it is going to = send an encapsulated ACM.
> > > >
> > > > [PTT]
> > > > Agreed, and that is a nasty = point.  It's related to the
> next one.
> > > >
> > > > >
> > > > > 2. Even if it the UAS GW = would send an encapsulated ACM, it
> > > > > is not sure
> > > > > that the UAC GW supports = ISUP transparency in the
> first place. It may
> > > > > support only ISUP/SIP = mapping, for example.
> > > >
> > > > [PTT]
> > > > That one is easily solved, in = two ways.  First, by
> hypothesis the UAC GW has
> > > > encapsulated the IAM in the = initial INVITE.  It can
> also include an
> > > > Accept-Content: header.  In = fact, this is essential so
> that the two ends can
> > > > negotiate stuff like ISUP = version or the fact that one
> of them really wants
> > > > to propagate Q.931.
> > > >
> > > > So, given that the UAS GW has = received an encapsulated IAM, the
> > > > Accept-Content: header indicates = that it did or did not find the
> > > > encapsulated content = acceptable.  If it did find it
> acceptable, how do we
> > > > oblige it to keep up its end of = the conversation?  I
> expect the behaviour
> > > > has to be specified in the SIP-T = umbrella document, and
> SIP/GSTN gateway
> > > > products have to indicate their = conformity to that document.
> > > >
> > > > >
> > > > > I think that part of the = problem, which is not
> related only to overlap
> > > > > dialling, is that a = SIP/PSTN GW from a SIP point of
> view is an SIP UA,
> > > > > and from a SIP point of = view should act like an SIP UA. Maybe
> > > > > it should
> > > > > be considered as a SIP node = of its own, with GW
> specific functional
> > > > > requirements. The only = thing we have now is how to map
> > > > > between ISUP and
> > > > > SIP, but that is obviously = not enough. ???
> > > > >
> > > > > Regards,
> > > > >
> > > > > Christer Holmberg
> > > > > Ericsson Finland
> > > > >
> > > >
> > > >  
> = --------------------------------------------------------------
> ----------
> > > = >           &n= bsp;       Name: att1.htm
> > > >    = att1.htm       Type: Hypertext Markup = Language (text/html)
> > > = >           &n= bsp;   Encoding: base64
> > > = >            = Description: Internet HTML
>

------_=_NextPart_001_01C091F7.96649E20-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 13:18:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15604 for ; Thu, 8 Feb 2001 13:18:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4AC0544429; Thu, 8 Feb 2001 13:18:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67]) by lists.bell-labs.com (Postfix) with ESMTP id E119844336 for ; Thu, 8 Feb 2001 13:17:34 -0500 (EST) Received: from matt.ipverse.com (lsanca1-ar5-208-223.dsl.gtei.net [4.33.208.223]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DZWGTH49; Thu, 8 Feb 2001 10:17:27 -0800 Message-Id: <5.0.2.1.2.20010208101421.02120800@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 To: sip@lists.bell-labs.com From: Matt Holdrege Subject: RE: [SIP] Overlap call setup In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 08 Feb 2001 10:17:08 -0800 I hope we aren't burdening the spec to cover all cases. In the case of two trunking gateway/softswitch complexes setting up a call between each other, I don't think we need too worry too much about their capabilities. Each complex will have all the local understanding they need. At 09:50 AM 2/8/2001, Mark Watson wrote: >I think this is a good proposal. > >I would suggest that the overlap capability is offered in the INVITE and >accepted in the response from the UAS. Otherwise we get problems (e.g. >user on standard SIP client dials under-length number by mistake, PSTN >gateway sends IAM and returns response to UAC, but now the PSTN is waiting >for more digits so we do not get failure until something times out.) > >I think the idea of including the number of digits to send in a reponse >was not that the UAS would know the total number of digits needed, but >that it might know 'I need at least 3 more digits to route this'. If it >signalled this information back, the UAC could wait 'till it had got 3 >more digits and we would save two messages, that's all. > >Regards, > >Mark Watson >Nortel Networks > > > -----Original Message----- > > From: Christer Holmberg > [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: 06 February 2001 07:52 > > To: sip@lists.bell-labs.com > > Cc: Keith Robinson; Taylor, Tom-PT [NORSE:B901:EXCH]; Moloney, Joshua > > [MDN05:CT07:EXCH] > > Subject: Re: [SIP] Overlap call setup > > > > > > > > Hi, > > > > I had a look through the thread, and I still have one issue. > > > > I do NOT think that we can assume that the PSTN GW will know how many > > digits are needed to route a call to the PSTN end-user, so I > > don't think > > we can use provisional responses to "ask" for more digits. Yes, the GW > > may know how many digits it needs to route the call to the next PSTN > > switch, but it doesn't know how many digits that switch needes, etc... > > > > So, my proposal would be: > > > > 1. When the INVITE has been routed to the GW UAS, the only > > response sent > > back is 100. That would, of course, assume that we have to add Contact > > and/or Record-Route headers in the 100 response... > > > > 2. Then, the UAC would use INFO to send more digits to the UAC, which > > would forward them as SAMs. No, the GW would not "ask" for > > more digits, > > but does it really have to? If the UAC wants to send more > > digits, it can > > do so anyway, so... > > > > 3. THEN, when the GW receives ACM from the PSTN side, it would send a > > 18x provisional response back to the UAC. The UAC would now > > know that no > > more digits are needed to route the call. Of course, we can get a > > "please enter your code"-message, and be asked to provide digits, but > > that is another issue. > > > > We should remember that the GW SIP UAS may not even know that > > the UAC is > > sending more digits, because it may send them in encapsulated ISUP > > messages. In that case, however, the GW SIP UAS will not know > > it's SAMs, > > so it couldn't make a decission on if to send 186 "Gimme more > > digits" or > > not... > > > > > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > Hi, > > > > > > Keith Robinson wrote: > > > > > > > >Christer wrote ; > > > > > > > >>Again, we assume that the GWs support ISUP transparency, > > because if the > > > >>GW only supports ISUP/SIP mapping it will not be able to > > know if to > > > >>generate an ACM when the 18x is received - even if the GW > > would be smart > > > >>enough to notice that there is SOME ISUP message in the > > 180 response. > > > > > > > >Surely, if a GW is mapping ISUP to SIP (and vice versa) > > then there must >be rules to dictate which SIP messages map > > to which ISUP messages and in >what context. In fact, aren't > > these the rules we are debating ? The point >being that even > > if a GW is ONLY performing SIP/ISUP/SIP mapping > > > >then it STILL MUST know when to genrate the ACM as part of > > the mapping >function, REGARDLESS of transparency. > > > > > > Yes, and since it may not be possible to have rules when a > > 180 should > > > generate a ACM, and when it should not. So, in the case of overlap > > > dialing, when the 18x is only used to "ask" for more digits, my > > > suggestion was to use a specific provisional response code > > that would > > > not generate an ACM. > > > > > > Then, when we want an ACM to be generated, no matter if ISUP > > > transparency is supported or not, we would send a 180 Alerting. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > Regards, > > > > > > > > K. Robinson. > > > > > > > > Christer Holmberg on > > 05/02/2001 11:10:49 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > > > > > > > cc: Tom-PT Taylor , > > > > sip@lists.bell-labs.com, Joshua Moloney > > > > > > > > > > > > > > > > > > > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > > > Hi, > > > > > > > > Again, we assume that the GWs support ISUP transparency, > > because if the > > > > GW only supports ISUP/SIP mapping it will not be able to > > know if to > > > > generate an ACM when the 18x is received - even if the GW > > would be smart > > > > enough to notice that there is SOME ISUP message in the > > 180 response. > > > > > > > > Personally, I still think that a separate provisional > > response code > > > > (I've been using 186 as an example) should be used, and > > any UAC (SIP > > > > phone or PSTN GW) supporting overlap dialing must understand the > > > > response. And, if the UAC knows it has already sent all digits, > > > > receiving a 186 could, for example, cause it to send a > > CANCEL to the > > > > INVITE, instead of waiting for the ISUP digit timers to expire and > > > > receive a 486 final response. > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > > > Keith Robinson wrote: > > > > > > > > > > In the absence of receiving an encapsulated ACM, the ingress > > > > > gateway could generate its own ACM when it receives a > > 180 Alerting; this > > > > > response must mean it is safe to assume call routing is complete > > > > > and caters for terminations within a SIP network. > > Thought needs to be > > > > > given to scenarios where a non-200 final response is > > received, say 486 > > > > > Busy, as in these cases 180 Alerting, probably, > > wouldn't be generated. > > > > > > > > > > Regards, > > > > > > > > > > Keith. > > > > > > > > > > "Tom-PT Taylor" on > > 02/02/2001 14:12:39 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Christer Holmberg > > > > > > > > > > > > > > > cc: Keith Robinson/MAIN/MC1@MCMAIN, > > > > > sip@lists.bell-labs.com, "Joshua Moloney" > > > > > > > > > > > > > > > > > > > > > > > > > Subject: RE: [SIP] Overlap call setup > > > > > > > > > > > > > > > Replies below. > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > Sent: Friday, February 02, 2001 1:17 AM > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > Cc: Keith Robinson; sip@lists.bell-labs.com; Moloney, Joshua > > > > > > [MDN05:CT07:EXCH] > > > > > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > I see a couple of issues here. > > > > > > > > > > > > 1. Even if the UAS returns Accept-Encoding: application/isup, > > > > > > it doesn't > > > > > > mean that it is going to send an encapsulated ACM. > > > > > > > > > > [PTT] > > > > > Agreed, and that is a nasty point. It's related to the > > next one. > > > > > > > > > > > > > > > > > 2. Even if it the UAS GW would send an encapsulated ACM, it > > > > > > is not sure > > > > > > that the UAC GW supports ISUP transparency in the > > first place. It may > > > > > > support only ISUP/SIP mapping, for example. > > > > > > > > > > [PTT] > > > > > That one is easily solved, in two ways. First, by > > hypothesis the UAC GW has > > > > > encapsulated the IAM in the initial INVITE. It can > > also include an > > > > > Accept-Content: header. In fact, this is essential so > > that the two ends can > > > > > negotiate stuff like ISUP version or the fact that one > > of them really wants > > > > > to propagate Q.931. > > > > > > > > > > So, given that the UAS GW has received an encapsulated IAM, the > > > > > Accept-Content: header indicates that it did or did not find the > > > > > encapsulated content acceptable. If it did find it > > acceptable, how do we > > > > > oblige it to keep up its end of the conversation? I > > expect the behaviour > > > > > has to be specified in the SIP-T umbrella document, and > > SIP/GSTN gateway > > > > > products have to indicate their conformity to that document. > > > > > > > > > > > > > > > > > I think that part of the problem, which is not > > related only to overlap > > > > > > dialling, is that a SIP/PSTN GW from a SIP point of > > view is an SIP UA, > > > > > > and from a SIP point of view should act like an SIP UA. Maybe > > > > > > it should > > > > > > be considered as a SIP node of its own, with GW > > specific functional > > > > > > requirements. The only thing we have now is how to map > > > > > > between ISUP and > > > > > > SIP, but that is obviously not enough. ??? > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer Holmberg > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > > > > Name: att1.htm > > > > > att1.htm Type: Hypertext Markup Language (text/html) > > > > > Encoding: base64 > > > > > Description: Internet HTML > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 13:45:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16217 for ; Thu, 8 Feb 2001 13:45:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CBC664434C; Thu, 8 Feb 2001 13:45:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id D804F4434B for ; Thu, 8 Feb 2001 13:43:56 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Thu, 8 Feb 2001 17:51:01 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1RT7G2NZ>; Thu, 8 Feb 2001 17:50:11 -0000 Message-ID: From: "Mark Watson" To: Keith Robinson , bidulock@openss7.org Cc: Gonzalo.Camarillo@lmf.ericsson.se, christer.holmberg@lmf.ericsson.se, "Joshua Moloney" , "Tom-PT Taylor" , sip@lists.bell-labs.com Subject: RE: [SIP] Overlap call setup MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C091F7.97791B60" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 8 Feb 2001 17:50:15 -0000 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_01C091F7.97791B60 Content-Type: text/plain; charset="ISO-8859-1" There are other reasons for overlap which are not to do with outpulsing delay/CAS interworking, but rather to do with determining end of dialling. 1) Support of open dial-plans, where not even the terminating exchange knows how many digits to expect, only the user equipment knows this 2) Simplification of routing data, so not all exchanges have to know the global dial-plan in order to work out how many digits to expect In the absence of an indication of end-of-dialling from the calling user you have only two choices: a) Run an inter-digit timer and assume end of dialling if it expires b) Overlap digits through the network towards a point where the end of dialling can be determined from dial-plan knowledge It is generally felt that for networks puporting to offer PSTN or better services, (a) is not acceptable as it adds post-dial delay and can mis-identify end of dialling if the user is too slow. Of course an end-of-dialling indication from the user is highly desirable, which is why all systems more advanced than simple telephony are based on this (mobile phones, ISDN, SIP), but systems exist, and will continue to exist for many decades, which do not provide this. I believe there are important flaws in the mechanisms in the RFC and isup mapping draft. Not least the requirements to have multiple outstanding call legs for each extra digit, to use a whole INVITE for a single digit and to tie these into a single call instance on the ISUP side of a gateway could not be described as elegant. We seem to be near reasonable solution based on negotiating the use of INFOs - I think we should go ahead and document this so that we can bottom out the details. Regards, Mark Watson Nortel Networks > -----Original Message----- > From: Keith Robinson [mailto:Keith.Robinson@marconi.com] > Sent: 07 February 2001 11:29 > To: bidulock@openss7.org > Cc: Gonzalo.Camarillo@lmf.ericsson.se; > christer.holmberg@lmf.ericsson.se; Moloney, Joshua [MDN05:CT07:EXCH]; > Taylor, Tom-PT [NORSE:B901:EXCH]; sip@lists.bell-labs.com > Subject: Re: [SIP] Overlap call setup > > > > > Vendors could mandate that their SIP/PSTN gateways will > always block up digits > and do everything en bloc; thats fine. > > I was raising issues I had with the mechanism for supporting > overlap sending if > it was required to be performed because a particular > administration wants to > use overlap signalling. > > Regards, > > Keith. > > > > > > > > > "Brian F. G. Bidulock" on 07/02/2001 06:49:08 > > Please respond to bidulock@openss7.org > > > > > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > cc: Gonzalo.Camarillo@lmf.ericsson.se, > christer.holmberg@lmf.ericsson.se, > jmoloney@nortelnetworks.com, > taylor@nortelnetworks.com, sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Overlap call setup > > > > > > > > ------_=_NextPart_001_01C091F7.97791B60 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Overlap call setup

There are other reasons for overlap which are not to = do with outpulsing delay/CAS interworking, but rather to do with = determining end of dialling.

1) Support of open dial-plans, where not even the = terminating exchange knows how many digits to expect, only the user = equipment knows this

2) Simplification of routing data, so not all = exchanges have to know the global dial-plan in order to work out how = many digits to expect

In the absence of an indication of end-of-dialling = from the calling user you have only two choices:
a) Run an inter-digit timer and assume end of = dialling if it expires
b) Overlap digits through the network towards a = point where the end of dialling can be determined from dial-plan = knowledge

It is generally felt that for networks puporting to = offer PSTN or better services, (a) is not acceptable as it adds = post-dial delay and can mis-identify end of dialling if the user is too = slow.

Of course an end-of-dialling indication from the user = is highly desirable, which is why all systems more advanced than simple = telephony are based on this (mobile phones, ISDN, SIP), but systems = exist, and will continue to exist for many decades, which do not = provide this.

I believe there are important flaws in the mechanisms = in the RFC and isup mapping draft. Not least the requirements to have = multiple outstanding call legs for each extra digit, to use a whole = INVITE for a single digit and to tie these into a single call instance = on the ISUP side of a gateway could not be described as = elegant.

We seem to be near reasonable solution based on = negotiating the use of INFOs - I think we should go ahead and document = this so that we can bottom out the details.

Regards,

Mark Watson
Nortel Networks

> -----Original Message-----
> From: Keith Robinson [mailto:Keith.Robinson@marconi= .com]
> Sent: 07 February 2001 11:29
> To: bidulock@openss7.org
> Cc: Gonzalo.Camarillo@lmf.ericsson.se;
> christer.holmberg@lmf.ericsson.se; Moloney, = Joshua [MDN05:CT07:EXCH];
> Taylor, Tom-PT [NORSE:B901:EXCH]; = sip@lists.bell-labs.com
> Subject: Re: [SIP] Overlap call setup
>
>
>
>
> Vendors could mandate that their SIP/PSTN = gateways will
> always block up digits
> and do everything en bloc; thats fine.
>
> I  was raising issues I had with the = mechanism for supporting
> overlap sending if
> it was required to be performed because a = particular
> administration wants to
> use overlap signalling.
>
> Regards,
>
> Keith.
>
>
>
>
>
>
>
>
> "Brian F. G. Bidulock" = <bidulock@openss7.org> on 07/02/2001 06:49:08
>
> Please respond to bidulock@openss7.org
>          = ;            = ;            = ;            = ;            = ;    
>          = ;        
>          = ;            = ;            = ;            = ;            = ;    
>          = ;        
>          = ;            = ;            = ;            = ;            = ;    
>          = ;        
>
>
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>  To:      Keith = Robinson/MAIN/MC1@MCMAIN        =             =  
>          = ;            = ;            = ;            = ;            = ;    
>  cc:      = Gonzalo.Camarillo@lmf.ericsson.se,      &n= bsp;           =
>          = ; = christer.holmberg@lmf.ericsson.se,      &n= bsp;           =
>          = ; = jmoloney@nortelnetworks.com,       &n= bsp;           &n= bsp;   
>          = ; taylor@nortelnetworks.com, sip@lists.bell-labs.com 
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>          = ;            = ;            = ;            = ;            = ;    
>  Subject: Re: [SIP] Overlap call = setup           &= nbsp;            =
>          = ;            = ;            = ;            = ;            = ;    
>
>
>
>
>
>
>

------_=_NextPart_001_01C091F7.97791B60-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 13:46:48 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16316 for ; Thu, 8 Feb 2001 13:46:48 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D69AB44393; Thu, 8 Feb 2001 13:45:21 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id 46CC54434C for ; Thu, 8 Feb 2001 13:44:04 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Thu, 8 Feb 2001 17:50:42 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1RT7G2NT>; Thu, 8 Feb 2001 17:50:08 -0000 Message-ID: From: "Mark Watson" To: Flemming Andreasen , "Drage, Keith (Keith)" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] More on privacy MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C091F7.937A4F70" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 8 Feb 2001 17:50:08 -0000 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_01C091F7.937A4F70 Content-Type: text/plain; charset="ISO-8859-1" Keith, I had the same response as Flemming. The idea is that if information is received from an untrusted source, the proxy sets rpi-screen to 'yes' for the identities that it can verify to be correct and 'no' for those that it can't. For identities received from a trusted source, the rpi-screen values are maintained as received (though it could change some 'no's to 'yes's if it can do the verification. I guess your comment is whether we should be able to include two identities both claiming to be of the same type and for the same party but with different rpi-screen values. I think this would be a good idea as I don't think we should be placing any unnecessary restrictions/dependencies in the syntax at this point, as long as the semantics are clear. ...Mark > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: 06 February 2001 21:54 > To: Drage, Keith (Keith) > Cc: 'sip@lists.bell-labs.com' > Subject: Re: [SIP] More on privacy > > > There is currently an "rpi-screen" parameter defined in the > privacy draft which > basically tags the Remote-Party-ID as verified/screened or > not. I'm not sure I > understand why it doesn't address what you want to achieve here. > > -- Flemming > > > "Drage, Keith (Keith)" wrote: > > > To add a further issue to the current discussions on privacy. > > > > The current specification of trusted versus untrusted > really only deals with > > the presentation of information to untrusted entities. > > > > In the ISDN/PSTN world there is also the concept of > information being > > provided by an untrusted source, for example an separate > enterprise network, > > or a user attached to that separate enterprise network. > > > > In some cases the untrusted source may be the only entity > able to provide > > truly accurate information. Therefore for Calling Line > Identification > > Presentation there is a special indicator of user provided > unscreened. > > > > This means that in ISDN we have an either or situation for > CLIP, the user is > > either told: > > > > - this is the number for dialback purposes, but you > cannot trust the > > reliability of this information because I cannot check it. > > > > or > > > > - this is the number for dialback purposes, but I > have only provided > > you with the information I can check, therefore it may not > get you back to > > the real source of the call, but only to the enterprise > network that sourced > > it. > > > > In SIP we could have the possibility of providing both, but > we would need to > > discuss how we would identify these identifiers. For > example two different > > identifier tags in the Remote-Party_ID header, or a common > identifier tag, > > but a separate indication of level of screening. > > > > Keith > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > -- > Flemming Andreasen > Cisco Systems > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > ------_=_NextPart_001_01C091F7.937A4F70 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] More on privacy

Keith,

I had the same response as Flemming. The idea is that = if information is received from an untrusted source, the proxy sets = rpi-screen to 'yes' for the identities that it can verify to be correct = and 'no' for those that it can't. For identities received from a = trusted source, the rpi-screen values are maintained as received = (though it could change some 'no's to 'yes's if it can do the = verification.

I guess your comment is whether we should be able to = include two identities both claiming to be of the same type and for the = same party but with different rpi-screen values. I think this would be = a good idea as I don't think we should be placing any unnecessary = restrictions/dependencies in the syntax at this point, as long as the = semantics are clear.

...Mark

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]=
> Sent: 06 February 2001 21:54
> To: Drage, Keith (Keith)
> Cc: 'sip@lists.bell-labs.com'
> Subject: Re: [SIP] More on privacy
>
>
> There is currently an "rpi-screen" = parameter defined in the
> privacy draft which
> basically tags the Remote-Party-ID as = verified/screened or
> not. I'm not sure I
> understand why it doesn't address what you want = to achieve here.
>
> -- Flemming
>
>
> "Drage, Keith (Keith)" wrote:
>
> > To add a further issue to the current = discussions on privacy.
> >
> > The current specification of trusted = versus untrusted
> really only deals with
> > the presentation of information to = untrusted entities.
> >
> > In the ISDN/PSTN world there is also the = concept of
> information being
> > provided by an untrusted source, for = example an separate
> enterprise network,
> > or a user attached to that separate = enterprise network.
> >
> > In some cases the untrusted source may be = the only entity
> able to provide
> > truly accurate information. Therefore for = Calling Line
> Identification
> > Presentation there is a special indicator = of user provided
> unscreened.
> >
> > This means that in ISDN we have an either = or situation for
> CLIP, the user is
> > either told:
> >
> > -       this = is the number for dialback purposes, but you
> cannot trust the
> > reliability of this information because I = cannot check it.
> >
> > or
> >
> > -       this = is the number for dialback purposes, but I
> have only provided
> > you with the information I can check, = therefore it may not
> get you back to
> > the real source of the call, but only to = the enterprise
> network that sourced
> > it.
> >
> > In SIP we could have the possibility of = providing both, but
> we would need to
> > discuss how we would identify these = identifiers. For
> example two different
> > identifier tags in the Remote-Party_ID = header, or a common
> identifier tag,
> > but a separate indication of level of = screening.
> >
> > Keith
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: drage@lucent.com
> >
> > = _______________________________________________
> > This list is for continuing development of = the SIP protocol.
> > The sip-implementer's list is the place to = discuss implementation,
> > and to receive advice on understanding = existing sip.
> > To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in = the body.
>
> --
> Flemming Andreasen
> Cisco Systems
>
>
>
> = _______________________________________________
> This list is for continuing development of the = SIP protocol.
> The sip-implementer's list is the place to = discuss implementation,
> and to receive advice on understanding existing = sip.
> To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the = body.
>

------_=_NextPart_001_01C091F7.937A4F70-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 13:51:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16442 for ; Thu, 8 Feb 2001 13:51:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 42AB34434D; Thu, 8 Feb 2001 13:51:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id CF2504433F for ; Thu, 8 Feb 2001 13:50:50 -0500 (EST) Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA27287; Thu, 8 Feb 2001 13:50:49 -0500 (EST) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id NAA69515; Thu, 8 Feb 2001 13:50:46 -0500 (EST) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14978.60038.490002.167034@conrail.cs.columbia.edu> To: sip@lists.bell-labs.com Cc: sip-implementors@cs.columbia.edu Subject: RE: [SIP] over-length message In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 8 Feb 2001 13:50:46 -0500 (EST) Content-Transfer-Encoding: 7bit On Thursday, February 8 2001, "Jonathan Rosenberg" wrote to "Eric Burger, sip@lists.bell-labs.com" saying: > Well, there is no such thing as a UDP MTU. There is an IP maximum packet > size, which is 64k. The MTU is different on each link, and the path MTU is > the minimum of the MTU along a message path. Should a packet arrive on a > link which is in excess of the MTU, it is fragmented. THis is done at the IP > layer, transparent to the applications. So, a proxy simply won't care that a > 3k UDP packet arrived over ATM unfragmented, and will depart over ethernet > with an MTU of 1500 bytes, requiring fragmentation. Fragmentation is not a > great thing, as it has known error exponentiation effects, but functionally, > its completely hidden from the proxy. Thus, the problem that has been > described does not exist. Except for all the embedded SIP devices which seem to have decided that they don't need to support IP fragmentation. This has been a significant interoperability problem at bakeoffs. Needless to say, I think this is something that SIP implementors should beaware of, and fix before considering their embedded devices production-quality. I also think that we ought to add a torture test case where crucial information in the SIP request sits after the 1500 byte mark. Cc'd to sip-implementors; followups should go there. -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 14:01:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16845 for ; Thu, 8 Feb 2001 14:01:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 091D04435A; Thu, 8 Feb 2001 14:01:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by lists.bell-labs.com (Postfix) with ESMTP id ACE5444336 for ; Thu, 8 Feb 2001 14:00:53 -0500 (EST) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Thu, 8 Feb 2001 07:00:02 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1MM3HHNT>; Thu, 8 Feb 2001 07:00:04 -0500 Message-ID: <28560036253BD41191A10000F8BCBD1103A03D2E@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Gonzalo Camarillo Cc: Christer Holmberg , sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C091C6.AAADE890" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 8 Feb 2001 07:00:01 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C091C6.AAADE890 Content-Type: text/plain; charset="iso-8859-1" You are correct about using some other means of transport if ISUP trans-shipment is all your network is doing. If the call destination (to a SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call basis, however, using SIP to establish your call routing leads to using SIP to carry the ISUP. > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, February 06, 2001 9:52 PM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: Christer Holmberg; sip@lists.bell-labs.com > Subject: Re: [SIP] Operlap dialing within a SIP network > > > Hi Tom, > > Still I want to have full state in every SIP message. If the call is > addresed to the phone number 1234, I want to have a to field that says > 1234. I do not care if there is a leg routed thru the PSTN and another > thru SIP. > > Carrying full state is one of the beauties of SIP. If we begin using > INFO for this, it would be the same as using SAMs. Differen names, the > same thing... I do not want to re-create ISUP using SIP. I > believe that > if the session has a destination, it should be present in the > to field. > > Again, if a proxy is providing services for this particular call, it > will want to see the called party number in order to trigger > the proper > service. This is a very good reason for updating the to field > every time > we have more digits. > > I like to use SIP between two gateways because it is possible > to provide > SIP services for a PSTN to PSTN call. If all we want to do is > finding a > egrees gateway, we would probably want to use other protocols (TRIP & > SIGTRAN for instance). > > Regards, > > Gonzalo > > Tom-PT Taylor wrote: > > > > Sorry, we're talking past each other. The premise of my > statements is > > that an INVITE has reached a UAS which has accepted it. It follows > > that the UAS did not send back a 484, but rather an interim > response. > > IF more digits come along, the INFO method is there to carry them. > > They do not affect the SIP call state; they are used beyond the UAS, > > either in a PSTN call or in another SIP call as the case may be. > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > Hello Tom, > > > > > > Tom-PT Taylor wrote: > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > signalling > > > > has reached an egress gateway, SIP has done its job -- > additional > > > > digits will not change call state. It is therefore > > > reasonable to use > > > > INFO to carry the additional digits. If we are talking > > > ISUP-SIP, once > > > > the destination UAS or a UAS in a B2BUA has been > reached, the same > > > > > > consideration applies. > > > > > > > > > > I do not agree with these two statements: > > > > > > The 1st INVITE (with just some digits) arrives to a > vanilla SIP UA. > > I > > > will return a Not Found or a 484 Address incomplete. The > > > subsequent INFO > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > gateway > > > will have to re issue a new INVITE with all the digits. > > > Therefore, it is > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > carries ISUP messages between two gateways. For that, we have > > already > > > SIGTRAN. SIP might be used to provide services, even when the > > > call is a > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > state. And a > > > SIP message with an incomplete to field does not carry complete > > state. > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > based > > > on the to field (called party number). That proxy would > like to see > > an > > > updated to field, not just a to field that contains just some > > digits. > > > > > > Best regards, > > > > > > Gonzalo > > > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > To: Gonzalo Camarillo > > > > > Cc: sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > been proposed > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > reason for > > > > > the discussion from the beginning was that the overlap > > signalling, > > > > > according to the SIP-ISUP mapping draft, may not work > > > very well, and > > > > a > > > > > solution using 18x responses and INFO messages, instead of 484 > > and > > > > > re-INVITEs, was proposed. > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > signalling section. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > about calls > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > SIP UAS > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > | <- 18x ------ | > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > | <- 200 (INFO) | > > > > > > > | <- 18x ------ | > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > --> > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > the word 'proxy') > > > > > > > must collect digits, sent from the PSTN side using > > > > > overlap dialing, to > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > the digits > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > be allowed to > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > INVITEs, until > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer Holmberg > > > > > > > Ericsson Finland > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : > > > Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > ------_=_NextPart_001_01C091C6.AAADE890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Operlap dialing within a SIP network

You are correct about using some other means of = transport if ISUP trans-shipment is all your network is doing.  If = the call destination (to a SIP endpoint, to an H.323 endpoint, to a = PSTN endpoint) varies on a per-call basis, however, using SIP to = establish your call routing leads to using SIP to carry the = ISUP.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: Tuesday, February 06, 2001 9:52 PM
> To: Taylor, Tom-PT [NORSE:B901:EXCH]
> Cc: Christer Holmberg; = sip@lists.bell-labs.com
> Subject: Re: [SIP] Operlap dialing within a SIP = network
>
>
> Hi Tom,
>
> Still I want to have full state in every SIP = message. If the call is
> addresed to the phone number 1234, I want to = have a to field that says
> 1234. I do not care if there is a leg routed = thru the PSTN and another
> thru SIP.
>
> Carrying full state is one of the beauties of = SIP. If we begin using
> INFO for this, it would be the same as using = SAMs. Differen names, the
> same thing... I do not want to re-create ISUP = using SIP. I
> believe that
> if the session has a destination, it should be = present in the
> to field.
>
> Again, if a proxy is providing services for = this particular call, it
> will want to see the called party number in = order to trigger
> the proper
> service. This is a very good reason for = updating the to field
> every time
> we have more digits.
>
> I like to use SIP between two gateways because = it is possible
> to provide
> SIP services for a PSTN to PSTN call. If all we = want to do is
> finding a
> egrees gateway, we would probably want to use = other protocols (TRIP &
> SIGTRAN for instance).
>
> Regards,
>
> Gonzalo
>
> Tom-PT Taylor wrote:
> >
> > Sorry, we're talking past each = other.  The premise of my
> statements is
> > that an INVITE has reached a UAS which has = accepted it.  It follows
> > that the UAS did not send back a 484, but = rather an interim
> response.
> > IF more digits come along, the INFO method = is there to carry them.
> > They do not affect the SIP call state; = they are used beyond the UAS,
> > either in a PSTN call or in another SIP = call as the case may be.
> >
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > Sent: Tuesday, February 06, 2001 9:10 = PM
> > > To: Taylor, Tom-PT = [NORSE:B901:EXCH]
> > > Cc: Christer Holmberg; = sip@lists.bell-labs.com
> > > Subject: Re: [SIP] Operlap dialing = within a SIP network
> > >
> > >
> > > Hello Tom,
> > >
> > > Tom-PT Taylor wrote:
> > > >
> > > > Just to re-hash, in the = ISUP-SIP-ISUP context, once call
> > signalling
> > > > has reached an egress gateway, = SIP has done its job --
> additional
> > > > digits will not change call = state.  It is therefore
> > > reasonable to use
> > > > INFO to carry the additional = digits.  If we are talking
> > > ISUP-SIP, once
> > > > the destination UAS or a UAS in = a B2BUA has been
> reached, the same
> >
> > > > consideration applies.
> > > >
> > >
> > > I do not agree with these two = statements:
> > >
> > > The 1st INVITE (with just some = digits) arrives to a
> vanilla SIP UA.
> > I
> > > will return a Not Found or a 484 = Address incomplete. The
> > > subsequent INFO
> > > carrying more digits will be = discarded. Thus, the PSTN to SIP
> > gateway
> > > will have to re issue a new INVITE = with all the digits.
> > > Therefore, it is
> > > better to begin directly using = er-INVITEs rather than INFO.
> > >
> > > Besides, I do not think that SIP is = just a transport protocol that
> > > carries ISUP messages between two = gateways. For that, we have
> > already
> > > SIGTRAN. SIP might be used to provide = services, even when the
> > > call is a
> > > PSTN-SIP-PSTN call. Thus, SIP = messages MUST carry complete
> > > state. And a
> > > SIP message with an incomplete to = field does not carry complete
> > state.
> > > What if my SIP proxy provides a = service for a PSTN-SIP-PSTN call
> > based
> > > on the to field (called party = number). That proxy would
> like to see
> > an
> > > updated to field, not just a to field = that contains just some
> > digits.
> > >
> > > Best regards,
> > >
> > > Gonzalo
> > >
> > >
> > > > > -----Original = Message-----
> > > > > From: Christer = Holmberg
> > [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > > > > Sent: Tuesday, February 06, = 2001 1:15 AM
> > > > > To: Gonzalo = Camarillo
> > > > > Cc: = sip@lists.bell-labs.com
> > > > > Subject: Re: [SIP] Operlap = dialing within a SIP network
> > > > >
> > > > >
> > > > >
> > > > > Hi Gonzalo,
> > > > >
> > > > > I didn't say I am going to = use INFO, but that is what has
> > > > > been proposed
> > > > > earlier in this thread, so = I assumed INFO would be used. The
> > > > > reason for
> > > > > the discussion from the = beginning was that the overlap
> > signalling,
> > > > > according to the SIP-ISUP = mapping draft, may not work
> > > very well, and
> > > > a
> > > > > solution using 18x = responses and INFO messages, instead of 484
> > and
> > > > > re-INVITEs, was = proposed.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Christer Holmberg
> > > > > Ericsson Finland
> > > > >
> > > > >
> > > > >
> > > > > Gonzalo Camarillo = wrote:
> > > > > >
> > > > > > Hello Christer,
> > > > > >
> > > > > > Why are you using INFO = for sending extra digits?
> > > > > >
> > > > > > Please, check the = SIP-ISUP mapping draft, overlap
> > > > > signalling section.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Gonzalo
> > > > > >
> > > > > > Christer Holmberg = wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > The discussion = about overlap dialing has been pretty much
> > > > > about calls
> > > > > > > from SIP to PSTN, = or PSTN-SIP-PSTN.
> > > > > > >
> > > > > > > Consider the = following scenario.
> > > > > > >
> > > > > > > PSTN = PHONE           &= nbsp; GW           = SIP SERVER   
>   SIP UAS
> > > > > > >
> = -----------------------------------------------------------
> > > > > > >
> > > > > > > --- 1 = --->    -- IAM -> | -- INVITE -->  = |
> > > > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > --- 2 = --->    -- SAM -> | -- INFO ---->  = |
> > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |
> > > > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > --- 3 = --->    -- SAM -> | -- INFO ---->  = |
> > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |   -- INVITE
> > > > > > > -->
> > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INVITE)|   <- 200 ------
> > > > > > >
> > > > > > > In this case, the = SIP server (note that I am not using
> > > > > the word 'proxy')
> > > > > > > must collect = digits, sent from the PSTN side using
> > > > > overlap dialing, to
> > > > > > > be able to find = the SIP UAS, and INFO is used to provide
> > > > > the digits
> > > > > > > after the INVITE = has been sent.
> > > > > > >
> > > > > > > My question is, = should a SIP server (proxy, if you like)
> > > > > be allowed to
> > > > > > > behave like this, = or MUST it send 486s, and receive new
> > > > > INVITEs, until
> > > > > > > it is able to = find the UAS?
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Christer = Holmberg
> > > > > > > Ericsson = Finland
> > > > > >
> > > > > > --
> > > > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > > > FIN-02420 = Jorvas          Email = :
> > > Gonzalo.Camarillo@ericsson.com
> > > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > >
> > >
> > > --
> > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > >
>
> --
> Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> = Finland           = ;        http://www.hut.fi/~gonzalo
>

------_=_NextPart_001_01C091C6.AAADE890-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 14:20:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17383 for ; Thu, 8 Feb 2001 14:20:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 30AF844364; Thu, 8 Feb 2001 14:20:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from [216.201.26.130] (unknown [216.201.26.130]) by lists.bell-labs.com (Postfix) with SMTP id AF1E44434B for ; Thu, 8 Feb 2001 14:19:30 -0500 (EST) Received: from HOMER by [216.201.26.130] via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 8 Feb 2001 19:58:02 UT Received: from jrancier (jrancier [10.1.30.65]) by mail-server.syr.softechnics.com (8.8.7/8.8.7) with SMTP id OAA08922 for ; Thu, 8 Feb 2001 14:19:29 -0500 From: "Jeff Rancier" To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <20010208190201.E020D4436B@lists.bell-labs.com> Subject: [SIP] Digest settings Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 8 Feb 2001 14:20:52 -0500 Content-Transfer-Encoding: 7bit Is there anyway to get _one_ digest for the day. I think so far today I have received about 5 different digests. Please excuse my lack of knowledge regarding digested mailings. Thanks, Jeff -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of sip-request@lists.bell-labs.com Sent: Thursday, February 08, 2001 2:02 PM To: sip@lists.bell-labs.com Subject: SIP digest, Vol 1 #776 - 2 msgs Send SIP mailing list submissions to sip@lists.bell-labs.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.bell-labs.com/mailman/listinfo/sip or, via email, send a message with subject or body 'help' to sip-request@lists.bell-labs.com You can reach the person managing the list at sip-admin@lists.bell-labs.com When replying, please edit your Subject line so it is more specific than "Re: Contents of SIP digest..." _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 15:52:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19246 for ; Thu, 8 Feb 2001 15:52:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 61BF94433B; Thu, 8 Feb 2001 15:52:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id B0E3344336 for ; Thu, 8 Feb 2001 15:51:41 -0500 (EST) 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 PAA07124; Thu, 8 Feb 2001 15:51:42 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA17492; Thu, 8 Feb 2001 15:51:40 -0500 (EST) Message-ID: <3A82B2B8.E6AE5EBB@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Lynch Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Video Conferencing? References: <91D91D8F61FAD31191C900508B8BA0B80F5A07@dennis.surfcast.internal> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 08 Feb 2001 06:52:40 -0800 Content-Transfer-Encoding: 7bit The spec contains several examples containing more than one media. If you ignore things that don't belong in signaling protocols (such as floor control), SIP will work just fine for any number of media. There are a (small, unfortunately) number of user agents that support things other than audio, but I've seen user agents supporting video, games, text chat, shared whiteboards and shared applications, this being a matter of adding the appropriate line to SDP, not of modifying SIP. Thus, the lack of activity simply reflects the fact that there doesn't seem to be anything special that is left to be done here. This probably qualifies as a FAQ... Mark Lynch wrote: > > Hi, > > I've been working with H323 for a while now but lately have been reading > alot about SIP and must say I'm very impressed with it's simplicity and > power. The only question I have is reagarding it's video conferencing > capabilities. I've been led to believe it's a long way off ? I thought it > was as simple as establishing an RTP channel and agreeing a codec. > > Could someone please tell me I'm wrong and point me to an example of Video > conferecing via SIP? I can' t seem to find any. > > If I'm right could anyone clarify what is happening in relation to this. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 18:28:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21491 for ; Thu, 8 Feb 2001 18:28:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8DE0044350; Thu, 8 Feb 2001 18:28:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251]) by lists.bell-labs.com (Postfix) with ESMTP id 7784A44336 for ; Thu, 8 Feb 2001 18:27:40 -0500 (EST) Received: from stinkbug.antd.nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id SAA03504 for ; Thu, 8 Feb 2001 18:21:47 -0500 (EST) From: "'M. Ranganathan'" X-Sender: mranga@localhost.localdomain To: sip@lists.bell-labs.com Message-ID: 'Reply-To: M. Ranganathan < mranga@antd.nist.gov >' MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Extracting a call flow from a trace? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 8 Feb 2001 18:27:33 -0500 (EST) Hello and greetings! Hopefully, this message is not directed at the wrong mailing list! As I understand it, SIP is a stateless protocol. If all the messages from a call flow are available to me from a set of log files that are ordered, would it be possible to deduce the call flow (i.e. causal sequences of messages) from just looking at the message logs (with no additional information than the SIP Messages themselves) or is further information required? Thanks in advance for your answers. Regards Ranga. -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 19:58:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22272 for ; Thu, 8 Feb 2001 19:58:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3CA794434B; Thu, 8 Feb 2001 19:58:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from snap.CS.Berkeley.EDU (snap.CS.Berkeley.EDU [128.32.37.81]) by lists.bell-labs.com (Postfix) with ESMTP id D6F9844336 for ; Thu, 8 Feb 2001 19:57:52 -0500 (EST) Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id RAA27102 for sip@lists.bell-labs.com; Thu, 8 Feb 2001 17:00:12 -0800 From: John Lazzaro Message-Id: <200102090100.RAA27102@snap.CS.Berkeley.EDU> To: sip@lists.bell-labs.com Subject: Re: [SIP] NAT, SOCKS 5 proxies, win proxies Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 8 Feb 2001 17:00:12 -0800 afarhan@rediffmail.com writes: > a) SIP and RTP should be able to work from a single UDP port. This basic idea can work -- sooner or later I hope to write up a SIP B2BUA I've implemented for multi-party conference initialization that takes this route, mostly following the "Activision" techniques described in the recent "Protocol Complications with NAT" RFC. The ugliest aspect of this is that unless you also want to multiplex RTP and RTCP on the same UDP port, you need to have parallel SIP sessions going on two ports, on for the RTP port and one for the RTCP port. In my SDP-specific implementation for the B2BUA, the NAT information specified in the Activision algorithm gets embedded in SDP fmt lines by the SIP conference server, which is another ugly aspect ... although I believe that if the received tag for Via was a hostport, you might be able to legally embed this NAT information in the SIP itself. However, I think there's a big difference between "it can be made to work" and "everyone should do it" -- using the OS to do multiplexing is a pretty key concept in ALF, and when you ignore it all sorts of bad things result. One that immediately comes to mind -- you can't connect() the socket on the client if you're using the Activision algorithm in the multi-party case, since you're using the same socket to send RTP to several parties, as well as the SIP conference B2BUA. The result is, you can't get ICMP feedback to tell if you're UDP packets aren't being listened to, and need to use timeouts exclusively ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 8 22:26:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25038 for ; Thu, 8 Feb 2001 22:26:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2E54744343; Thu, 8 Feb 2001 22:26:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0A0CF44336 for ; Thu, 8 Feb 2001 22:25:55 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA09680; Thu, 8 Feb 2001 22:28:55 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR895F>; Thu, 8 Feb 2001 22:22:12 -0500 Message-ID: From: Jonathan Rosenberg To: "'John Lazzaro'" , sip@lists.bell-labs.com Subject: RE: [SIP] NAT, SOCKS 5 proxies, win proxies MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 8 Feb 2001 22:22:03 -0500 All solutions for nat and firewall traversal that assume no enterprise support are ugly. I have proposed one solution: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-entfw-00.txt which relies on a B2BUA outside of the firewall, coupled with SIP over TLS. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: John Lazzaro [mailto:lazzaro@CS.Berkeley.EDU] > Sent: Thursday, February 08, 2001 8:00 PM > To: sip@lists.bell-labs.com > Subject: Re: [SIP] NAT, SOCKS 5 proxies, win proxies > > > > afarhan@rediffmail.com writes: > > a) SIP and RTP should be able to work from a single UDP port. > > This basic idea can work -- sooner or later I hope to write up > a SIP B2BUA I've implemented for multi-party conference > initialization that takes this route, mostly following the > "Activision" techniques described in the recent "Protocol > Complications with NAT" RFC. The ugliest aspect of this is > that unless you also want to multiplex RTP and RTCP on the > same UDP port, you need to have parallel SIP sessions going > on two ports, on for the RTP port and one for the RTCP port. > In my SDP-specific implementation for the B2BUA, the NAT > information specified in the Activision algorithm gets > embedded in SDP fmt lines by the SIP conference server, > which is another ugly aspect ... although I believe that > if the received tag for Via was a hostport, you might be able > to legally embed this NAT information in the SIP itself. > > However, I think there's a big difference between "it can > be made to work" and "everyone should do it" -- using the > OS to do multiplexing is a pretty key concept in ALF, and > when you ignore it all sorts of bad things result. > One that immediately comes to mind -- you can't connect() > the socket on the client if you're using the Activision > algorithm in the multi-party case, since you're using the > same socket to send RTP to several parties, as well as > the SIP conference B2BUA. The result is, you can't get > ICMP feedback to tell if you're UDP packets aren't being > listened to, and need to use timeouts exclusively ... > > -------------------------------------------------------------- > ----------- > John Lazzaro -- Research Specialist -- CS Division -- EECS -- > UC Berkeley > lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 01:09:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28706 for ; Fri, 9 Feb 2001 01:09:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E69244378; Fri, 9 Feb 2001 01:09:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by lists.bell-labs.com (Postfix) with ESMTP id 6DFE644344 for ; Fri, 9 Feb 2001 01:08:41 -0500 (EST) Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id PAA15092; Fri, 9 Feb 2001 15:08:39 +0900 (JST) (envelope-from ohba.takumi@lab.ntt.co.jp) Received: from imi.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/05/00) with ESMTP id PAA28203; Fri, 9 Feb 2001 15:08:39 +0900 (JST) (envelope-from ohba.takumi@lab.ntt.co.jp) Received: from [129.60.10.47] ([129.60.10.47]) by imi.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id PAA08708; Fri, 9 Feb 2001 15:08:38 +0900 (JST) Message-Id: <200102090608.PAA08708@imi.m.ecl.ntt.co.jp> X-Sender: to006@imi.m.ecl.ntt.co.jp X-Mailer: Macintosh Eudora Pro Version 3.1.1-Jr2 In-Reply-To: <14978.60038.490002.167034@conrail.cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: sip@lists.bell-labs.com From: Takumi Ohba Subject: RE: [SIP] over-length message Cc: sip-implementors@cs.columbia.edu Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 9 Feb 2001 15:06:53 +0900 Dear all, Sorry for continuing this topic on this mailing list, but I would like to confirm one point, which may relate to SIP protocol development. I understand that SIP over transport protocols using IP has no limit, thanks to the IP fragmentation function. So, SIP has no need to worry about message length if it uses IP based transport protocols, but should use TCP if it wants to send longer message than the path MTU. I also understand that supporting IP fragmentation is implementation issue. On the other hand, SIP cannot send too long message over a transport protocol that has no fragmentation function, such as MTP or signalling AAL. However, nobody except me considers that SIP uses such transport protocol at this stage, and therefore, this is not a problem. In other word, it is only a future possible problem. If we will use such transport protocols, SIP will have to care about message length and specify something (handling of over length message, or message segmentation procedures in SIP level). Is my understanding correct? Regards, Takumi Ohba *************************************************** Takumi OHBA NTT Network Service Systems Laboratories tel +81 422 59 4405 fax +81 422 59 3494 e-mail ohba.takumi@lab.ntt.co.jp *************************************************** _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 07:26:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14170 for ; Fri, 9 Feb 2001 07:26:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AD59044362; Fri, 9 Feb 2001 07:26:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id ACD0644362 for ; Fri, 9 Feb 2001 07:25:13 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id HAA11346; Fri, 9 Feb 2001 07:28:06 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR80GY>; Fri, 9 Feb 2001 07:21:23 -0500 Message-ID: From: Jonathan Rosenberg To: "'Tom-PT Taylor'" , Gonzalo Camarillo Cc: Christer Holmberg , sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 9 Feb 2001 07:21:21 -0500 I think the correct answer about which approach to use (INFO vs. multiple call legs) depends on your view of the scope of the address within the sip cloud. If you believe that the sip role has ended once you have enough digits to select an egress gateway (which may be as few as one, i.e., +1 selects a US gateway), then the sip address of that gateway can be viewed as sip:+1@provider.com, and all subsequent digits are PSTN issues, outside the scope of SIP. If you believe that the sip role encompasses functions that might apply to the PSTN subscribers, then you need to have the entire number, and the multiple call leg approach is the right way to go. The multiple call leg approach is clearly ugly and inelegant, but it has the nice property of completely masking the existence of overlap from proxies and app servers within the network, allowing them to provide services in the normal way. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Thursday, February 08, 2001 7:00 AM To: Gonzalo Camarillo Cc: Christer Holmberg; sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network You are correct about using some other means of transport if ISUP trans-shipment is all your network is doing. If the call destination (to a SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call basis, however, using SIP to establish your call routing leads to using SIP to carry the ISUP. > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Tuesday, February 06, 2001 9:52 PM > To: Taylor, Tom-PT [NORSE:B901:EXCH] > Cc: Christer Holmberg; sip@lists.bell-labs.com > Subject: Re: [SIP] Operlap dialing within a SIP network > > > Hi Tom, > > Still I want to have full state in every SIP message. If the call is > addresed to the phone number 1234, I want to have a to field that says > 1234. I do not care if there is a leg routed thru the PSTN and another > thru SIP. > > Carrying full state is one of the beauties of SIP. If we begin using > INFO for this, it would be the same as using SAMs. Differen names, the > same thing... I do not want to re-create ISUP using SIP. I > believe that > if the session has a destination, it should be present in the > to field. > > Again, if a proxy is providing services for this particular call, it > will want to see the called party number in order to trigger > the proper > service. This is a very good reason for updating the to field > every time > we have more digits. > > I like to use SIP between two gateways because it is possible > to provide > SIP services for a PSTN to PSTN call. If all we want to do is > finding a > egrees gateway, we would probably want to use other protocols (TRIP & > SIGTRAN for instance). > > Regards, > > Gonzalo > > Tom-PT Taylor wrote: > > > > Sorry, we're talking past each other. The premise of my > statements is > > that an INVITE has reached a UAS which has accepted it. It follows > > that the UAS did not send back a 484, but rather an interim > response. > > IF more digits come along, the INFO method is there to carry them. > > They do not affect the SIP call state; they are used beyond the UAS, > > either in a PSTN call or in another SIP call as the case may be. > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > Hello Tom, > > > > > > Tom-PT Taylor wrote: > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > signalling > > > > has reached an egress gateway, SIP has done its job -- > additional > > > > digits will not change call state. It is therefore > > > reasonable to use > > > > INFO to carry the additional digits. If we are talking > > > ISUP-SIP, once > > > > the destination UAS or a UAS in a B2BUA has been > reached, the same > > > > > > consideration applies. > > > > > > > > > > I do not agree with these two statements: > > > > > > The 1st INVITE (with just some digits) arrives to a > vanilla SIP UA. > > I > > > will return a Not Found or a 484 Address incomplete. The > > > subsequent INFO > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > gateway > > > will have to re issue a new INVITE with all the digits. > > > Therefore, it is > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > carries ISUP messages between two gateways. For that, we have > > already > > > SIGTRAN. SIP might be used to provide services, even when the > > > call is a > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > state. And a > > > SIP message with an incomplete to field does not carry complete > > state. > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > based > > > on the to field (called party number). That proxy would > like to see > > an > > > updated to field, not just a to field that contains just some > > digits. > > > > > > Best regards, > > > > > > Gonzalo > > > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > To: Gonzalo Camarillo > > > > > Cc: sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > been proposed > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > reason for > > > > > the discussion from the beginning was that the overlap > > signalling, > > > > > according to the SIP-ISUP mapping draft, may not work > > > very well, and > > > > a > > > > > solution using 18x responses and INFO messages, instead of 484 > > and > > > > > re-INVITEs, was proposed. > > > > > > > > > > Regards, > > > > > > > > > > Christer Holmberg > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > signalling section. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > about calls > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > SIP UAS > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > | <- 18x ------ | > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > | <- 200 (INFO) | > > > > > > > | <- 18x ------ | > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > --> > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > the word 'proxy') > > > > > > > must collect digits, sent from the PSTN side using > > > > > overlap dialing, to > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > the digits > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > be allowed to > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > INVITEs, until > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer Holmberg > > > > > > > Ericsson Finland > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : > > > Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 07:55:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14995 for ; Fri, 9 Feb 2001 07:55:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 014824435C; Fri, 9 Feb 2001 07:55:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 71E6944336 for ; Fri, 9 Feb 2001 07:54:36 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id HAA11458 for ; Fri, 9 Feb 2001 07:57:37 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR80HT>; Fri, 9 Feb 2001 07:50:54 -0500 Message-ID: From: Jonathan Rosenberg To: Robert Sparks , sip@lists.bell-labs.com Subject: RE: [SIP] Removing 409 to conflicting action params MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 9 Feb 2001 07:50:50 -0500 The reason it was there is that if the proxy DOES want to follow it, it becomes meaningless to have some URLS with redirect, and some with proxy. What does the proxy do? Does it mean to redirect if the highest q value URL has an action of redirect, even though others say proxy? What if the q values are the same, or none were specified? We came to the conclusion that it could mean any number of more complex behaviors, most of which were more appropriately specified via a CPL than action params. So, I would like to keep this restriction. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Wednesday, February 07, 2001 11:55 AM > To: sip@lists.bell-labs.com > Subject: RE: [SIP] Removing 409 to conflicting action params > > > I share Neil's opinions here. > Can anyone state a reason for keeping the restriction? > > RjS > > > -----Original Message----- > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > Sent: Friday, January 19, 2001 6:06 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Removing 409 to conflicting action params > > > > > > Can we please remove the restriction that all current > > registrations MUST share the same action param. I haven't > > found this to be helpful to either users or implementers. > > > > The spec doesn't really say anything about servers having > > to obey action params so they could be treated as just a > > hint to the users wishes. A SIP server could then choose > > to try and follow them, use it's own configuration policy > > or follow alternative user defined processing logic (CPL etc). > > This is more in keeping with the handling of params like > > methods that we are seeing more of in Contact headers. > > > > Cheers, > > Neil. > > -- > > Ubiquity Software Corporation, UK http://www.ubiquity.net > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 08:01:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15212 for ; Fri, 9 Feb 2001 08:01:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F1E5944379; Fri, 9 Feb 2001 08:01:05 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9B88944336 for ; Fri, 9 Feb 2001 08:00:51 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id IAA11561; Fri, 9 Feb 2001 08:03:47 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR802N>; Fri, 9 Feb 2001 07:57:04 -0500 Message-ID: From: Jonathan Rosenberg To: "'Bernie Hoeneisen'" , sip@lists.bell-labs.com Subject: RE: [SIP] Informing UA after network initated deregistration? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 9 Feb 2001 07:56:54 -0500 > -----Original Message----- > From: Bernie Hoeneisen [mailto:bhoeneis@cc.hut.fi] > Sent: Tuesday, February 06, 2001 11:40 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Informing UA after network initated deregistration? > > > Hi, > > I have some questions concerning informing the UA in case the network > de-registers the UA, and wants to inform the UA about this. > > Let me describe a possible use case: Supposed the UA > normally registers > to only one registrar. Furthermore this registrar needs some > maintenance > break. The policy in this registrar/network is, to inform all its > registered UAs, that they have been de-registered (and maybe > provide an > address, where it can send a new registration.) > Remark: There can be more reasons, why a network element needs to > de-register a user, maintenance break is just one. > > > My questions: > > - Has this problem area been addressed earlier in IETF? > If yes, please send me some pointers. Yes. The issue has been raised on the list at least three separate times. Please check the archives. > > - What do key-people think about such a feature, where a registrar > informs about de-registration of users? Is it welcome to include it > into a SIP extension (e.g. defining a method for it e.g. UNREGISTER, > or re-using other methods such as NOTIFY), or whatever would be > appropriate? My view is the same it was the other three times. Failover and redundancy for devices contacted by clients is best handled by using things like SRV records. The SRV record for some registrar would contain a list of ordered devices to try. When you want to service the main one, you take it out of service. Clients who re-register will get an ICMP error, and as per draft-ietf-sip-srv, will then try the next address, which is its backup. This works not only for registrations, but for outbound proxies, and any other sip communications, even between servers and servers. SRV is not ideal for all load balancing and failover needs, as is well known, but I think it addresses this need perfectly well. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 08:37:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16476 for ; Fri, 9 Feb 2001 08:37:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 29D1A44337; Fri, 9 Feb 2001 08:37:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 0D3A544336 for ; Fri, 9 Feb 2001 08:36:04 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 9 Feb 2001 13:36:03 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id NAA27820; Fri, 9 Feb 2001 13:34:44 GMT Message-ID: <3A83F1F3.BB9BDEBE@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Robert Sparks , sip@lists.bell-labs.com Subject: Re: [SIP] Removing 409 to conflicting action params References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 09 Feb 2001 13:34:43 +0000 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > The reason it was there is that if the proxy DOES want to follow it, it > becomes meaningless to have some URLS with redirect, and some with proxy. > What does the proxy do? I am not asking that Proxy/Registrars be forbidden from responding 409 just that they be free to choose not to. Presently a registrar MUST respond 409 to conflicting action params. I don't want to be forced to respond 409 when somebody has their mailto URL registered with an redirect action and then wants to add a SIP URL which they want requests proxied to. > Does it mean to redirect if the highest q value URL > has an action of redirect, even though others say proxy? What if the q > values are the same, or none were specified? We came to the conclusion that > it could mean any number of more complex behaviors, most of which were more > appropriately specified via a CPL than action params. > > So, I would like to keep this restriction. This is a fair point but we could define how a server should respond to mixed action params wrt q values if that is perceived to be an issue. I think that generally CPL will be available to provide this sort of control where it is really needed and so the whole existence of an action param is fairly unintersting. If present can't it just be treated more as a hint. A SIP server could then choose to try and follow them, use it's own configuration policy or follow alternative user defined processing logic (CPL etc). This gives more flexibility than mandating 409s. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 08:58:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17260 for ; Fri, 9 Feb 2001 08:58:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5708744388; Fri, 9 Feb 2001 08:58:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 0A4ED44336 for ; Fri, 9 Feb 2001 08:57:53 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id FAA01759; Fri, 9 Feb 2001 05:57:55 -0800 (PST) Received: from sony-laptop (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with SMTP id AAK03522; Fri, 9 Feb 2001 05:57:51 -0800 (PST) Message-Id: <4.1.20010209060045.01f07da0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Kevin Wang , sip@lists.bell-labs.com From: Rohan Mahy Subject: RE: [SIP] New version of message waiting draft In-Reply-To: <6C5713970B1FD411ACBE00AA00DCD9A61BCF84@crash.engineering.n etspeak.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 09 Feb 2001 06:01:54 -0800 At 08:33 AM 2/8/01 , Kevin Wang wrote: >Hi, > >I guess I did not make my 2nd question clear. If we look at the NOTIFY >message A5 on Page 5, we may find out that the 3rd section and 4th section >of the NOTIFY message contain some information (such as message subject, >date/time, priority, etc) about the new voicemail messages. However, the >NOTIFY message for re-synchronization (for example A3) does not contain that >information. So, my question is: if a UA loses its previous data for some >reason and restart again, how can the UA retrieve that information (message >subject, date/time, priority, etc) from the Notifier? it is unreasonable to resyncronize this information with NOTIFY, so the client must use POP or IMAP to get the current contents of the mailbox. thanks, -rohan >Thanks, > >-Kevin >> -----Original Message----- >> From: Rohan Mahy [SMTP:rohan@cisco.com] >> Sent: Thursday, February 08, 2001 10:57 AM >> To: Kevin Wang; sip@lists.bell-labs.com >> Subject: RE: [SIP] New version of message waiting draft >> >> Hi, >> >> At 12:59 PM 2/7/01 , Kevin Wang wrote: >> >I have 2 questions about this message waiting draft: >> >(1) In the 2nd paragraph of section 5.1, "The Subscriber MAY also >> explicitly >> >fetch the current status at any time." How does a subscriber fetch the >> >status? Based on the draft, my guess is that the subscriber sends a >> >re-SUBSCRIBER message and expects the current status in a NOTIFY message. >> >Could the subscriber expect the current status in the 200 OK? (In this >> way, >> >we do not need that NOTIFY message for re-synchronization). >> >> you can't put this in the 200, because the SUBSCRIBE might be forked, and >> only one of the 200s will get back. >> >> >(2) I notice that there is no user's message information in the NOTIFY >> >message for re-synchronization. (There is user's message information in >> the >> >NOTIFY message when the status of the messages changes.) If a UA is >> shutted >> >down abnormally and lost all the information, how can it get the user's >> >message information when it is restarted? >> >> POP or IMAP. getting this via NOTIFY is not practical. >> >> >> -----Original Message----- >> >> From: Rohan Mahy [SMTP:rohan@cisco.com] >> >> Sent: Wednesday, February 07, 2001 11:26 AM >> >> To: sip@lists.bell-labs.com >> >> Subject: [SIP] New version of message waiting draft >> >> >> >> Hi, >> >> >> >> I just finished a new version of the message waiting draft from Ilya >> Slain >> >> and I. Until it appears in the archives it is available at: >> >> >> >> ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-message-waiting-01.txt >> >> >> >> thanks, >> >> -rohan >> >> >> >> _______________________________________________ >> >> This list is for continuing development of the SIP protocol. >> >> The sip-implementer's list is the place to discuss implementation, >> >> and to receive advice on understanding existing sip. >> >> To subscribe to it, send mail to majordomo@cs.columbia.edu with >> >> "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 09:00:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17335 for ; Fri, 9 Feb 2001 09:00:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 34B6A4439D; Fri, 9 Feb 2001 09:00:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 597234439A for ; Fri, 9 Feb 2001 08:59:41 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA12232 for ; Fri, 9 Feb 2001 09:02:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR80NV>; Fri, 9 Feb 2001 08:55:59 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30475CE@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: RE: [SIP] Removing 409 to conflicting action params MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 9 Feb 2001 08:55:51 -0500 I'm not advocating destroying the response code, just allowing using it to be policy at the registrar. The classic proxy you mention would choose to use a registar that by policy returned 409. The current MUST restriction prevents applications that _can_ deal with multiple action types from using a "compliant" registrar. Further, with the current wording, I can't ask a proxy to proxy MESSAGEs and redirect INVITES, which is a very reasonable thing to ask a classic proxy to do. RjS > -----Original Message----- > From: Jonathan Rosenberg > Sent: Friday, February 09, 2001 6:51 AM > To: Robert Sparks; sip@lists.bell-labs.com > Subject: RE: [SIP] Removing 409 to conflicting action params > > > The reason it was there is that if the proxy DOES want to > follow it, it becomes meaningless to have some URLS with > redirect, and some with proxy. What does the proxy do? Does > it mean to redirect if the highest q value URL has an action > of redirect, even though others say proxy? What if the q > values are the same, or none were specified? We came to the > conclusion that it could mean any number of more complex > behaviors, most of which were more appropriately specified > via a CPL than action params. > > So, I would like to keep this restriction. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Wednesday, February 07, 2001 11:55 AM > > To: sip@lists.bell-labs.com > > Subject: RE: [SIP] Removing 409 to conflicting action params > > > > > > I share Neil's opinions here. > > Can anyone state a reason for keeping the restriction? > > > > RjS > > > > > -----Original Message----- > > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > > Sent: Friday, January 19, 2001 6:06 AM > > > To: sip@lists.bell-labs.com > > > Subject: [SIP] Removing 409 to conflicting action params > > > > > > > > > Can we please remove the restriction that all current > > > registrations MUST share the same action param. I haven't > > > found this to be helpful to either users or implementers. > > > > > > The spec doesn't really say anything about servers having > > > to obey action params so they could be treated as just a > > > hint to the users wishes. A SIP server could then choose > > > to try and follow them, use it's own configuration policy > > > or follow alternative user defined processing logic (CPL etc). > > > This is more in keeping with the handling of params like > > > methods that we are seeing more of in Contact headers. > > > > > > Cheers, > > > Neil. > > > -- > > > Ubiquity Software Corporation, UK http://www.ubiquity.net > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > > > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 09:19:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17933 for ; Fri, 9 Feb 2001 09:19:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 512F4443A4; Fri, 9 Feb 2001 09:19:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id B39654438B for ; Fri, 9 Feb 2001 09:18:35 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qhars002.nortel.com; Fri, 9 Feb 2001 14:18:18 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1RT7HYA5>; Fri, 9 Feb 2001 14:18:15 -0000 Message-ID: From: "Mark Watson" To: William Marshall , sip@lists.bell-labs.com Subject: RE: [SIP] 3pcc open issue with manyfolks draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C092A3.23DD15B0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 9 Feb 2001 14:18:14 -0000 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_01C092A3.23DD15B0 Content-Type: text/plain; charset="ISO-8859-1" Bill, all, I think that independently of the 3rd party Call Control cases, there are still two open issues with the manyfolks draft even for a simple two-party case. 1) Whilst it is possible for A to require that a COMET be set in the B --> A direction, and for B to require that a COMET be sent in the A --> B direction, it is not possible for A to require that B awaits the A --> B COMET or for B to require that A awaits the B --> A COMET. If, say, A is responsible for resource reservation in both directions (send and recv), it is quite likely that A will require B to await the A->B COMET before alerting the user. We shouldn't be making assumptions about who is responsible for the resource reservation - it depends on the technology being used in the network. 2) The draft only covers pre-conditions associated with a particular media stream - the qos is a media attribute. So, if the UA does not choose to support that media stream, it does not wait for the COMET. I believe we could easily extend to cope with pre-conditions which are not related to a particular media path between the UAs (e.g. completion of some dialogue with another network on the other side of the SIP UA.) This could be achieved by allowing the qos attribute to appear as a session attribute. Regards, Mark Watson Nortel Networks > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: 01 February 2001 22:34 > To: sip@lists.bell-labs.com > Subject: [SIP] 3pcc open issue with manyfolks draft > > > In San Diego, third party call control was brought up again > as an issue > with the manyfolks draft. I believe it is covered by the draft as it > exists today, and offer the following call flow to demonstrate this. > > A is attempting to call B. Proxy in the middle, CC, decides that > a transcoder, T, is needed in the call. Resulting call is A<->T > and T<->B, with CC being the 3rd party controller of T<->B. > T is assumed to not need to ring, and it will respond immediately > with a 200-OK when the INVITE preconditions are satisfied. > > In all cases below, item n+1 in a grouping is enabled by item n. > Where independent sequences start, a note indicates where the first > item in the group overlaps with the previous. > > There is no question that this call flow is complex, and has lots > of messages with the third party call controller. However, it > has the very nice property that each endpoint follows exactly the > same resource reservation procedures whether there is a 3pcc involved > or not. All of the special handling is done by CC. > > Bill Marshall > wtm@research.att.com > > 1. A --INVITE-> CC a=qos: > required sendrecv > 2. CC ---INVITE--> T a=qos: > required sr confirm > 3. CC <----183---- T a=qos: > required sr confirm > 4. A <---183--- CC > 5. A ====RSVP=================> T > 6. A --COMET--> CC a=qos: success send > note that CC used a Record-Route in the 183 to force the > PRACK and COMET to go through CC. This is > independent of > the use of a Record-Route in the 200-OK for > future signaling. > > (also in response to the 183 message (4) above) > 5. A --PRACK--> CC ---PRACK---> T > 6. A <===RSVP================== T > 7. CC <--COMET---- T a=qos: success send > note that T is now stalled, waiting for CC > to send a COMET to T. > > (also in response to the INVITE message (1) above) > 2. CC ---INVITE--> T w/o SDP > 3. CC <----183---- T a=qos: > required sr confirm > 4. CC -----------------INVITE----> B a=qos: > required sr confirm > 5. CC <------------------183------ B a=qos: > required sr confirm > 6. CC ------------------PRACK----> B > 7. T <===RSVP===== B > 8. CC <----COMET------------------ B a=qos: success send > note that B is now stalled, waiting for CC to send a COMET to B > > (also in response to the 183 message (3) immediately above) > 4. CC ---PRACK---> T a=qos: > required sr confirm > 5. CC T ====RSVP====> B > 6. CC <--COMET---- T a=qos: success send > > At this point, CC knows that resources are available from > A->T, from T->A, > from T->B, and B->T. It is "safe" to let the call proceed. > > 7. CC ---COMET-------------------> B a=qos: success send > 8. CC <---180--------------------- B > (CC generates a 180 response for the A<->T call, knowing that > T doesn't ring) > 9. A <---180--- CC > 10 CC <---200--------------------- B > 11 CC ---COMET---> T a=qos: success send > 12 CC <---200----- T > 13 A <---200--- CC completes call from A<->T > (also in response to the 200-OK from B, received in (10) above) > 11 CC ----200----> T completes call from T<->B > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > ------_=_NextPart_001_01C092A3.23DD15B0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] 3pcc open issue with manyfolks draft

Bill, all,

I think that independently of the 3rd party Call = Control cases, there are still two open issues with the manyfolks draft = even for a simple two-party case.

1) Whilst it is possible for A to require that a = COMET be set in the B --> A direction, and for B to require that a = COMET be sent in the A --> B direction, it is not possible for A to = require that B awaits the A --> B COMET or for B to require that A = awaits the B --> A COMET.

If, say, A is responsible for resource reservation in = both directions (send and recv), it is quite likely that A will require = B to await the A->B COMET before alerting the user. We shouldn't be = making assumptions about who is responsible for the resource = reservation - it depends on the technology being used in the = network.

2) The draft only covers pre-conditions associated = with a particular media stream - the qos is a media attribute. So, if = the UA does not choose to support that media stream, it does not wait = for the COMET. I believe we could easily extend to cope with = pre-conditions which are not related to a particular media path between = the UAs (e.g. completion of some dialogue with another network on the = other side of the SIP UA.) This could be achieved by allowing the qos = attribute to appear as a session attribute.

Regards,

Mark Watson
Nortel Networks



> -----Original Message-----
> From: William Marshall [mailto:wtm@research.att.com]
> Sent: 01 February 2001 22:34
> To: sip@lists.bell-labs.com
> Subject: [SIP] 3pcc open issue with manyfolks = draft
>
>
> In San Diego, third party call control was = brought up again
> as an issue
> with the manyfolks draft.  I believe it is = covered by the draft as it
> exists today, and offer the following call flow = to demonstrate this.
>
> A is attempting to call B.  Proxy in the = middle, CC, decides that
> a transcoder, T, is needed in the call.  = Resulting call is A<->T
> and T<->B, with CC being the 3rd party = controller of T<->B.
> T is assumed to not need to ring, and it will = respond immediately
> with a 200-OK when the INVITE preconditions are = satisfied.
>
> In all cases below, item n+1 in a grouping is = enabled by item n.
> Where independent sequences start, a note = indicates where the first
> item in the group overlaps with the = previous.
>
> There is no question that this call flow is = complex, and has lots
> of messages with the third party call = controller.  However, it
> has the very nice property that each endpoint = follows exactly the
> same resource reservation procedures whether = there is a 3pcc involved
> or not.  All of the special handling is = done by CC.
>
> Bill Marshall
> wtm@research.att.com
>
> 1. A --INVITE-> CC    =         =         =            a=3Dqos: =
> required sendrecv
> 2.    =         CC ---INVITE--> = T       =            a=3Dqos: =
> required sr confirm
> 3.    =         CC <----183---- = T       =            a=3Dqos: =
> required sr confirm
> 4. A <---183--- CC
> 5. A = =3D=3D=3D=3DRSVP=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D> = T
> 6. A --COMET--> CC    =         =         =            a=3Dqos: = success send
>       =         note that CC used a = Record-Route in the 183 to force the
>       =         PRACK and COMET to go = through CC.  This is
> independent of
>       =         the use of a Record-Route in = the 200-OK for
> future signaling.
>
> (also in response to the 183 message (4) = above)
> 5. A --PRACK--> CC ---PRACK---> T
> 6. A = <=3D=3D=3DRSVP=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = T
> 7.    =         CC <--COMET---- = T       =            a=3Dqos: = success send
>       note that T is = now stalled, waiting for CC
>       =         to send a COMET to T.
>
> (also in response to the INVITE message (1) = above)
> 2.    =         CC ---INVITE--> = T       =            w/o SDP
> 3.    =         CC <----183---- = T       =            a=3Dqos: =
> required sr confirm
> 4.    =         CC = -----------------INVITE----> B  a=3Dqos:
> required sr confirm
> 5.    =         CC = <------------------183------ B  a=3Dqos:
> required sr confirm
> 6.    =         CC = ------------------PRACK----> B
> 7.    =         =         =         T = <=3D=3D=3DRSVP=3D=3D=3D=3D=3D B
> 8.    =         CC = <----COMET------------------ B  a=3Dqos: success send
>       note that B is = now stalled, waiting for CC to send a COMET to B
>
> (also in response to the 183 message (3) = immediately above)
> 4.    =         CC ---PRACK---> = T       =            a=3Dqos: =
> required sr confirm
> 5.    =         = CC      =         T = =3D=3D=3D=3DRSVP=3D=3D=3D=3D> B
> 6.    =         CC <--COMET---- = T       =            a=3Dqos: = success send
>
> At this point, CC knows that resources are = available from
> A->T, from T->A,
> from T->B, and B->T.  It is = "safe" to let the call proceed.
>
> 7.    =         CC = ---COMET-------------------> B  a=3Dqos: success send
> 8.    =         CC = <---180--------------------- B
> (CC generates a 180 response for the = A<->T call, knowing that
> T doesn't ring)
> 9. A <---180--- CC
> 10    =         CC = <---200--------------------- B
> 11    =         CC ---COMET---> = T       =            a=3Dqos: = success send
> 12    =         CC <---200----- T
> 13 A <---200--- CC    =         =         completes call from = A<->T
> (also in response to the 200-OK from B, = received in (10) above)
> 11    =         CC ----200----> = T       completes call from = T<->B
>
>
> = _______________________________________________
> This list is for continuing development of the = SIP protocol.
> The sip-implementer's list is the place to = discuss implementation,
> and to receive advice on understanding existing = sip.
> To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the = body.
>

------_=_NextPart_001_01C092A3.23DD15B0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 10:41:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20508 for ; Fri, 9 Feb 2001 10:41:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E916544358; Fri, 9 Feb 2001 10:41:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id E5E2944336 for ; Fri, 9 Feb 2001 10:40:41 -0500 (EST) Received: by dnspri.npac.com; id JAA09433; Fri, 9 Feb 2001 09:40:39 -0600 (CST) Received: from unknown(192.168.23.4) by dnspri.npac.com via smap (V5.0) id xma009377; Fri, 9 Feb 01 09:40:26 -0600 Received: by chi02.chicago.npac.com with Internet Mail Service (5.5.2650.21) id ; Fri, 9 Feb 2001 09:40:16 -0600 Message-ID: From: James Yu To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] draft-levy-sip-diversion-01.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 9 Feb 2001 09:36:10 -0600 Would like to propose to add a new diversion reason code - "number mapping." The new code can be used, for example, when a redirect server performs a number mapping from a freephone number to a POTS number and returns the POTS number in the Contact hearder of a 302 response. The two numbers/addresses are "related." There is a need to at least describe in texts (if not to be shown in the call flows) about the recursing proxy sending CANCEL for any pending INVITE downstream, receiving 200 OK (CANCEL), receiving a 487 response and returning an ACK for several examples. The procedures at the the recursing proxy need to specify that the recursing proxy must not forward the 487 response upstream. The 3xx/4xx in many example should be Acked. It is not clear why "time-of-day" is needed unless the night service needs to use multiple reason codes for proper call processing. A reason code such as "unavailable" or even "uncondicational" (set after busy hours by the shops) seems to be sufficient. James Yu Principal Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue, NW, Suite 400 Washington, D.C. 20005 USA +1-202-533-2814 (B) +1-202-285-8326 (Mobile) +1-202-533-2987 (Fax) james.yu@neustar.com http://www.neustar.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 10:44:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20627 for ; Fri, 9 Feb 2001 10:44:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BC0DA4438B; Fri, 9 Feb 2001 10:44:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from radvpost.us.radvision.com (unknown [38.150.216.6]) by lists.bell-labs.com (Postfix) with ESMTP id 4AE6744336 for ; Fri, 9 Feb 2001 10:43:50 -0500 (EST) Received: by RADVPOST with Internet Mail Service (5.5.2650.21) id <1S8A9LRR>; Fri, 9 Feb 2001 10:42:48 -0500 Message-ID: <0D5BBF5D638DD4119E3400508BD9494529EF99@RADVPOST> From: Orit Levin To: Henning Schulzrinne , Mark Lynch Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Video Conferencing? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 9 Feb 2001 10:42:48 -0500 Actually (because of one of our company businesses Voice and Video Conferencing) we looked closer to how SIP can be used for real life multimedia applications. I would say, there are still some obstacles on the way before quality SIP/SDP based multimedia service will be delivered beyond lab environment. And I am NOT talking about advanced features that hopefully SDPng and some Floor Control protocol would provide. (BTW I support SDPng work very much.) As a first step towards "SIP for Video" I will submit a Draft for the upcoming IETF meeting presenting these requirements. I would be glad to know how much interest exists to work on this topic from the floor. Best Regards, Orit Levin RADVision Inc. TEL: 201.529.4300 x 230 FAX:201.529.3516 mailto:orit@radvision.com http://www.radvision.com 575 Corporate Drive Suite 420 Mahwah, NJ 07430 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, February 08, 2001 9:53 AM To: Mark Lynch Cc: 'sip@lists.bell-labs.com' Subject: Re: [SIP] Video Conferencing? The spec contains several examples containing more than one media. If you ignore things that don't belong in signaling protocols (such as floor control), SIP will work just fine for any number of media. There are a (small, unfortunately) number of user agents that support things other than audio, but I've seen user agents supporting video, games, text chat, shared whiteboards and shared applications, this being a matter of adding the appropriate line to SDP, not of modifying SIP. Thus, the lack of activity simply reflects the fact that there doesn't seem to be anything special that is left to be done here. This probably qualifies as a FAQ... Mark Lynch wrote: > > Hi, > > I've been working with H323 for a while now but lately have been reading > alot about SIP and must say I'm very impressed with it's simplicity and > power. The only question I have is reagarding it's video conferencing > capabilities. I've been led to believe it's a long way off ? I thought it > was as simple as establishing an RTP channel and agreeing a codec. > > Could someone please tell me I'm wrong and point me to an example of Video > conferecing via SIP? I can' t seem to find any. > > If I'm right could anyone clarify what is happening in relation to this. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 10:54:19 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20850 for ; Fri, 9 Feb 2001 10:54:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 81347443B0; Fri, 9 Feb 2001 10:48:07 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 41684443AC for ; Fri, 9 Feb 2001 10:47:37 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Feb 9 10:44:01 EST 2001 Received: by lists.bell-labs.com (Postfix) id 7F8CA44380; Fri, 9 Feb 2001 10:32:26 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 368E34437D for ; Fri, 9 Feb 2001 10:32:26 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA00179; Fri, 9 Feb 2001 09:32:23 -0600 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA00142; Fri, 9 Feb 2001 09:32:21 -0600 Message-ID: <3A840D78.38AEAF97@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "'M. Ranganathan'" Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Extracting a call flow from a trace? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 09 Feb 2001 09:32:08 -0600 Content-Transfer-Encoding: 7bit "'M. Ranganathan'" wrote: > > Hello and greetings! > > Hopefully, this message is not directed at the wrong mailing list! > > As I understand it, SIP is a stateless protocol. If all the messages from > a call flow are available to me from a set of log files that are ordered, > would it be possible to deduce the call flow (i.e. causal sequences of > messages) from just looking at the message logs (with no additional > information than the SIP Messages themselves) or is further information > required? I would presume so; and further, you may be able to re-create the causal sequence of message flow based on the logs of only a UAC, UAS, or a R-R'ed proxy (as opposed to the logs of a UAC AND a UAS). - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 11:05:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21252 for ; Fri, 9 Feb 2001 11:05:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F2FED443B8; Fri, 9 Feb 2001 11:05:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id C7662443B7 for ; Fri, 9 Feb 2001 11:04:51 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA19879 for ; Fri, 9 Feb 2001 08:04:54 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAV21420; Fri, 9 Feb 2001 08:04:50 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA02452; Fri, 9 Feb 2001 08:04:50 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14980.5410.254153.835763@thomasm-u1.cisco.com> To: sip@lists.bell-labs.com X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Subject: [SIP] sip in mime Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 9 Feb 2001 08:04:50 -0800 (PST) Content-Transfer-Encoding: 7bit I scanned through the bis draft and it wasn't immediately obvious to me whether you can embed SIP headers in a MIME attachement. Specifically, I was wondering whether it would be legit to embed SIP headers and potentially recursively adding MIME multipart into a SMIME attachement. Allowing this would provide an arguably more standards track way of transporting secure end to end SIP headers in proxy routed messages. Even if you prefer the existing PGP mechanism, it would seem cleaner to place the PGP signed part into a MIME attachement so that we can relax some of the weird rules that I'm guessing are mainly an artifact of MIME not being baked enough in that part of SIP's evolution. Mike _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 12:58:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26565 for ; Fri, 9 Feb 2001 12:58:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DA2F64438E; Fri, 9 Feb 2001 12:58:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id D1B0644336 for ; Fri, 9 Feb 2001 12:57:18 -0500 (EST) 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 MAA09371; Fri, 9 Feb 2001 12:57:15 -0500 (EST) 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 MAA14111; Fri, 9 Feb 2001 12:57:18 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <1H2LH7AF>; Fri, 9 Feb 2001 12:57:06 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EE99@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , "Drage, Keith (Keith)" Cc: "'William Marshall'" , "Rosen, Brian" , sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 9 Feb 2001 12:57:12 -0500 > > > The path by which a user might connect > > > to an emergency center cannot be pre-arranged. I believe that it > > > will take creation of a cryptographically secure infrastructure > > > to allow such a system to have the desired property that the user > > > can control location information, but when required it can be > > > securely delivered. > > I don't see this as a problem if we can arrange for an > end-to-end public > key for PSAPs (or one of the copies of the entity that routes > to PSAPs) > stored in end systems. > I was thinking that we would have a PSAP CA, the root certificate of which could easily be stored in the UA (or proxy servers). Then anyone could validate easily that the other end was a PSAP. Brian _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 19:47:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05283 for ; Fri, 9 Feb 2001 19:47:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 984CF4436B; Fri, 9 Feb 2001 19:47:01 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 7C0B444336 for ; Fri, 9 Feb 2001 19:46:30 -0500 (EST) 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 f1A0kPC25174; Sat, 10 Feb 2001 01:46:29 +0100 (MET) Received: from lmf.ericsson.se (EWUwsp001658wss.sd.us.am.ericsson.se [142.133.141.74]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id BAA13065; Sat, 10 Feb 2001 01:46:19 +0100 (MET) Message-ID: <21DAEE32.864ADABB@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Tom-PT Taylor'" , Christer Holmberg , sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Jan 1988 02:39:14 +0200 Content-Transfer-Encoding: 7bit Hello, Jonathan Rosenberg wrote: > > I think the correct answer about which approach to use (INFO vs. multiple > call legs) depends on your view of the scope of the address within the sip > cloud. If you believe that the sip role has ended once you have enough > digits to select an egress gateway (which may be as few as one, i.e., +1 > selects a US gateway), then the sip address of that gateway can be viewed as > sip:+1@provider.com, and all subsequent digits are PSTN issues, outside the > scope of SIP. I definitively agree that this is the view that INFO fans have of a SIP cloud. What I am saying is that this view is wrong. This usage of SIP falls outside the scope of SIP. If they want to use SIP for locating a gateway, it is fine. But after the gateway has been located, let's use another method for transporting ISUP signalling. Let's assume that I get an IAM with "+1", as Jonathan says in his example. Then the INVITE generated by the gateway will reach the US gateway. Now, the mission of SIP has finished, since the gateway has been located. Why don't we put in the body of this INVITE a session description that comprises a media session and a SIGTRAN session? This way we would have established these two sessions between the gateways and all the subsequent ISUP messages would be sent over the SIGTRAN session. I find that the usage of SIP that I have just described would be OK. What I do not understand is why folks want to use SIP for transporting subsequent ISUP messages. SIP does not have good transport properties (big overhead, it can run over UDP...). Besides, it does not provide ordered delivery. If the INVITE has Cseq=1 and the next message that the egrees gateway receives is a INFO with Cseq=7... what should the gateway do? Maybe there were several proxies in the middle asking for credentials for the INFO, so the ingrees gateway had to add authentication stuff and resend the INFO. If this was the case, the SAM contained in the INFO would be the second digit of the called party number... However, maybe 5 INFO messages got lost, and the SAM that we have received in the body of the INFO makes no sense without the previous ones because is the 7th digit of the number... This is not usually a problem in SIP, since all messages have full state. However, using INFO for sending SAMs breaks this rule, and therefore it breaks the SIP model. I believe that considering that the session is established after the first INVITE and sending the following SAMs using INFO is making one of the mistakes described in the guidelines for SIP authors: "We need to transport ISUP signalling over IP between two gateways. Both gateways already implement SIP... why do we have to implement another protocol? Let's use SIP to transport ISUP signalling". We are just trying to use SIP for this just because it would save implementing yet another protocol in the gateways. I strongly disagree with this usage of SIP. SIP-T is good as long as the SIP cloud provides services. If not, SIP-T is not a good protocol for transporting ISUP signalling. Best regards, Gonzalo If you believe that the sip role encompasses functions that > might apply to the PSTN subscribers, then you need to have the entire > number, and the multiple call leg approach is the right way to go. > > The multiple call leg approach is clearly ugly and inelegant, but it has the > nice property of completely masking the existence of overlap from proxies > and app servers within the network, allowing them to provide services in the > normal way. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Thursday, February 08, 2001 7:00 AM > To: Gonzalo Camarillo > Cc: Christer Holmberg; sip@lists.bell-labs.com > Subject: RE: [SIP] Operlap dialing within a SIP network > > You are correct about using some other means of transport if ISUP > trans-shipment is all your network is doing. If the call destination (to a > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call > basis, however, using SIP to establish your call routing leads to using SIP > to carry the ISUP. > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Tuesday, February 06, 2001 9:52 PM > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > Hi Tom, > > > > Still I want to have full state in every SIP message. If the call is > > addresed to the phone number 1234, I want to have a to field that says > > 1234. I do not care if there is a leg routed thru the PSTN and another > > thru SIP. > > > > Carrying full state is one of the beauties of SIP. If we begin using > > INFO for this, it would be the same as using SAMs. Differen names, the > > same thing... I do not want to re-create ISUP using SIP. I > > believe that > > if the session has a destination, it should be present in the > > to field. > > > > Again, if a proxy is providing services for this particular call, it > > will want to see the called party number in order to trigger > > the proper > > service. This is a very good reason for updating the to field > > every time > > we have more digits. > > > > I like to use SIP between two gateways because it is possible > > to provide > > SIP services for a PSTN to PSTN call. If all we want to do is > > finding a > > egrees gateway, we would probably want to use other protocols (TRIP & > > SIGTRAN for instance). > > > > Regards, > > > > Gonzalo > > > > Tom-PT Taylor wrote: > > > > > > Sorry, we're talking past each other. The premise of my > > statements is > > > that an INVITE has reached a UAS which has accepted it. It follows > > > that the UAS did not send back a 484, but rather an interim > > response. > > > IF more digits come along, the INFO method is there to carry them. > > > They do not affect the SIP call state; they are used beyond the UAS, > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hello Tom, > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > signalling > > > > > has reached an egress gateway, SIP has done its job -- > > additional > > > > > digits will not change call state. It is therefore > > > > reasonable to use > > > > > INFO to carry the additional digits. If we are talking > > > > ISUP-SIP, once > > > > > the destination UAS or a UAS in a B2BUA has been > > reached, the same > > > > > > > > consideration applies. > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > vanilla SIP UA. > > > I > > > > will return a Not Found or a 484 Address incomplete. The > > > > subsequent INFO > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > gateway > > > > will have to re issue a new INVITE with all the digits. > > > > Therefore, it is > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > > carries ISUP messages between two gateways. For that, we have > > > already > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > call is a > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > state. And a > > > > SIP message with an incomplete to field does not carry complete > > > state. > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > based > > > > on the to field (called party number). That proxy would > > like to see > > > an > > > > updated to field, not just a to field that contains just some > > > digits. > > > > > > > > Best regards, > > > > > > > > Gonzalo > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > To: Gonzalo Camarillo > > > > > > Cc: sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > been proposed > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > reason for > > > > > > the discussion from the beginning was that the overlap > > > signalling, > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > very well, and > > > > > a > > > > > > solution using 18x responses and INFO messages, instead of 484 > > > and > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer Holmberg > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > signalling section. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > > about calls > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > SIP UAS > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > | <- 18x ------ | > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > | <- 200 (INFO) | > > > > > > > > | <- 18x ------ | > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > --> > > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > the word 'proxy') > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > overlap dialing, to > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > the digits > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > be allowed to > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > INVITEs, until > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > -- > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > FIN-02420 Jorvas Email : > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 9 20:03:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05448 for ; Fri, 9 Feb 2001 20:03:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5D45443B6; Fri, 9 Feb 2001 20:03:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 17AD144336 for ; Fri, 9 Feb 2001 20:02:43 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id HAA12341 for ; Sat, 10 Feb 2001 07:08:03 -0600 Message-ID: <00b001c092fc$8358e970$c00c0c42@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Tentative schedule for SIP WG at IETF50 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 9 Feb 2001 18:57:34 -0600 Content-Transfer-Encoding: 7bit SIP meeting has been tentatively scheduled for TWO sessions. MONDAY, March 19, 2001 1300-1500 Afternoon Sessions I APP ldapext LDAP Extension WG INT ipcdn IP over Cable Data Network WG OPS ngtrans Next Generation Transition WG TSV sip Session Initiation Protocol WG USV uswg User Services WG TUESDAY, March 20, 2001 0900-1130 Morning Sessions APP ldup LDAP Duplication/Replication/Update Protocols WG INT dhc Dynamic Host Configuration WG OPS opsarea Operations & Management Open Area RTG msdp Multicast Source Discovery Protocol WG SEC ipsra IP Security Remote Access WG TSV sip Session Initiation Protocol WG _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 00:25:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10335 for ; Sat, 10 Feb 2001 00:25:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 477914435E; Sat, 10 Feb 2001 00:25:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id C007944336 for ; Sat, 10 Feb 2001 00:24:43 -0500 (EST) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G8J0022J0D6LQ@firewall.mcit.com> for sip@lists.bell-labs.com; Sat, 10 Feb 2001 05:24:43 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0G8J00M010D6BV@dgismtp04.wcomnet.com>; Sat, 10 Feb 2001 05:24:42 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G8J00M010D5BO@dgismtp04.wcomnet.com>; Sat, 10 Feb 2001 05:24:42 +0000 (GMT) Received: from Steveb1 ([166.44.245.121]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0G8J003G20CTVO@dgismtp04.wcomnet.com>; Sat, 10 Feb 2001 05:24:32 +0000 (GMT) From: "Christopher A. Martin" Subject: RE: [SIP] NAT, SOCKS 5 proxies, win proxies In-reply-to: <20010208132652.20161.qmail@mailweb7.rediffmail.com> To: "'Ashhar Farhan'" , sip@lists.bell-labs.com Reply-To: christopher.a.martin@wcom.com Message-id: <003b01c09321$bb6f20c0$29e023a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 09 Feb 2001 23:24:24 -0600 Content-Transfer-Encoding: 7bit There are a couple of questions to be posed here, in my mind. Do we develop firewalls to provide "transparent" end to end communications or do we develop protocols to support firewalls? Creating application level gateways to facilitate the "transparent" functionality is a common task that vendors typically perform to increase the functionality as well as the value of the product. Creating protocols to support firewalls is worse than a hasty work-around, IMHO. More comments below, > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Ashhar Farhan > Sent: Thursday, February 08, 2001 7:27 AM > To: sip@lists.bell-labs.com > Subject: [SIP] NAT, SOCKS 5 proxies, win proxies > > > there are several issues that arise out of NAT and socks 5 > traversals and there have been several suggestions about > overcoming them. > > it is very important that we are able to traverse these > proxies as most of the enterprises are behind them. > > 1. most of the schemes and papers submitted on the traversal > issues have been suggestions to modify NAT and SOCKS > behaviour to fit our shoe. i don't think that this is a > workable approach. there are virtually hundreds of NAT and > SOCKS implementations all over and if we are aiming at > ubiquity, we need to comply with their existing architectures > rather than suggesting some of our own. therefore, my > suggestion will be to see if it is possible to make SIP work > with the existing NAT, SOCKS 5 proxies as well as WinSock proxies. > NAT and SOCKS wsa developed to support the enterprise in a secure manner and to provide functional translation when necessary. The very functions they provide lend themselves for modification, in combination with application level gateways. > 2. a central problem to all proxy traversals (including that > of NAT) is that we can never definitely know the UDP port > associate opened by the proxy on behalf of a client behind > the proxy server. therefore, the SIP protocol will have to > work with an unknown UDP port. > We can and do knowthe listening port, as well as the source IP address of the client. Typically, when dealing with RTP firewalls ALG's are created aware of the associated RTCP requirements. > 3. The second issue is that RTP too will have to work in > conjunction with SIP. therefore, the problem is to correctly > identify the UDP port that to be specified in SDP for RTP > (and for the purists, even the RTCP). > see above. as for RTCP it is always the next highest odd port number, thus ther is no need to identify rather pinhole accordingly. > 4. finally, not all clients behind a proxy will be able to > open out the 5060 for themselves. > This can be defined. Typically if the call is established from within it is allowed access out by the firewall, if configured to do this. > 5. a clean approach to these problems is to write an > application that co-hosts a state-ful proxy with an RTP > relay, that uses the call states maintained within the SIP > proxy to correctly route the RTP packets. This application > sits on the same machine as the intranet proxy server. > Now this may be another valid approach to pursue, if nothing more than to prove vibility. > the trouble with this approach is that your network admin has > to be a fan of RFC2543 to agree to installing a SIP/RTP proxy > that of all the horrors relays UDP packets for all (s)he cares. > I believe that if SIP functinality is being considered it is most likely out of the hands of the administrator to decide if they are a fan of SIP or not. > 6. The other option is to coax SIP itself to work with the > current NAT/proxy architectures. Let me propose a scheme > which is a little too bitter. This is where I get heartburn. The first and foremost job of a firewall is to provide a "transparent" end-to-end solution without disrupting the functionality of the Internet Protocols traversing it. It is setup to provide protection and accountability, to not re-write of IP protocols. > > Recommendations: > a) SIP and RTP should be able to work from a single UDP port. > By examining the SIP /RTP header, it should be possible to > figure out which is which and accordingly process that > datagram. this is a pretty radical thing. i am essentially > saying the SIP should be able to work as an in-band > signalling mechanism. This would require even more processing by the firewall, because without parsing the packet just about anything could be entering the network, now we would be building a method of circumventing security policies through friewalls. By combining the two protocols we would be developing a stronger vulnerability for DoS type attacks. > b)If the port and ip address in Contact does not match the > actual IP and port address from which a UDP is received, then > there should be mechanism of being able to repy back to the > address/port from which the request came in. This would actually be a good idea for the RTP packets, something that my associate brought up the other day. If the clients were set up to send and receive on the same port it could simplify the access permissions on the firewall. > c) The UDP port association may die within a minute, > therefore, REGISTER has to be more frequent than 5 minutes > d) In case of NAT, under this scheme, only out going calls > will be possible. In order to accept incoming calls, clients > behind NAT will have to work through a SIP/RTP proxy that is > not necessarily locate on the Intranet. > This may not be necessary due to the fact that, depending on the NAT method used, internal clients may be assigned unique "listening" ports on the outside, or split DNS may be implemented. There are several methods that could be looked into closely on this point. > The most important points to consider here are: > 1. single port to be used for SIP and RTP, SIP and RTP > streaming to be directed to the same address/port from where > the original request/response was received. Thus, SIP should > be able to indicate "use the port i am talking to you from" > to the other side. > 2. in case of using a proxy, the port association maybe > different for different out-bound destinations, therfore, the > media streaming too has to be proxied from the same port as > where the SIP is being proxied. > > - farhan@hotfoon. > This is a solution that may have possibilities as an alternative solution, I believe that there is a draft that describes something similiar to this SIP scenario, in combination with MGCP, ftp://ftp.ietf.org/internet-drafts/draft-thernelius-sip-firewall-solution-00 .txt \ Christopher A. Martin SR. Security Integration Engineer IP Communications Engineering, WorldCom 972-729-4569 > _____________________________________________________ > Chat with your friends as soon as they come online. Get Rediff Bol at > http://bol.rediff.com > > > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 00:45:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10487 for ; Sat, 10 Feb 2001 00:45:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A275A443C1; Sat, 10 Feb 2001 00:45:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A402244336 for ; Sat, 10 Feb 2001 00:44:49 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA22335; Sat, 10 Feb 2001 00:47:48 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR9B5R>; Sat, 10 Feb 2001 00:41:04 -0500 Message-ID: From: Jonathan Rosenberg To: Michael Thomas , sip@lists.bell-labs.com Subject: RE: [SIP] sip in mime MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 10 Feb 2001 00:41:03 -0500 Indeed, it was agreed at the last meeting (at least, agreed upon by those at the bar bof), that it would be wise to deprecate the PGP stuff (and, as a result, the canonicalization rules), in favor of S/MIME or PGP/MIME. The implication of this is that we will need to define a mime type of message/sip so that the signed message can be carried in a part of the SIP message: INVITE sip:jdrosen@dynamicsoft.com SIP/2.0 To: sip:user@host From: sip:caller@host Content-Type: multipart/related Boundary: --- --- Content-Type: message/sip To: sip:user@host From: sip:caller@host Content-Type: application/sdp --- Content-Type: application/sdp --- Content-Type: signature (whatever the type is for it) sad08asdohasdojnasd08sdnoasdaosd09 Its big, but thats S/MIME. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Friday, February 09, 2001 11:05 AM > To: sip@lists.bell-labs.com > Subject: [SIP] sip in mime > > > > I scanned through the bis draft and it wasn't > immediately obvious to me whether you can embed > SIP headers in a MIME attachement. Specifically, I > was wondering whether it would be legit to embed > SIP headers and potentially recursively adding > MIME multipart into a SMIME attachement. Allowing > this would provide an arguably more standards > track way of transporting secure end to end SIP > headers in proxy routed messages. Even if you > prefer the existing PGP mechanism, it would seem > cleaner to place the PGP signed part into a MIME > attachement so that we can relax some of the weird > rules that I'm guessing are mainly an artifact of > MIME not being baked enough in that part of SIP's > evolution. > > Mike > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 00:46:24 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10509 for ; Sat, 10 Feb 2001 00:46:24 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E9CE443CC; Sat, 10 Feb 2001 00:45:25 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1EB3B443C1 for ; Sat, 10 Feb 2001 00:44:50 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA22351; Sat, 10 Feb 2001 00:47:50 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR9B54>; Sat, 10 Feb 2001 00:41:06 -0500 Message-ID: From: Jonathan Rosenberg To: "sip (E-mail)" , sip-implementors@cs.columbia.edu MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] List usage Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 10 Feb 2001 00:41:05 -0500 Note: The sip list is for the activities of the sip working group of the IETF. This includes development of extensions, and improvements in the baseline sip spec for advancement towards draft standards. The sip-implementors list is meant for QUESTIONS on sip, requests for information, and the like. I expect that despite our efforts, newbies will continue to post questions on the main sip list. I would strongly encourage our body of experts who answer these questions to NOT answer them on the main sip list. Send your response to the person and to sip-implementors. Otherwise, the thread will not migrate. Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 00:48:19 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10524 for ; Sat, 10 Feb 2001 00:48:19 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A43CD443D8; Sat, 10 Feb 2001 00:45:38 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5D55544336 for ; Sat, 10 Feb 2001 00:44:51 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA22347; Sat, 10 Feb 2001 00:47:50 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR9B5V>; Sat, 10 Feb 2001 00:41:06 -0500 Message-ID: From: Jonathan Rosenberg To: Neil Deason , Jonathan Rosenberg Cc: Robert Sparks , sip@lists.bell-labs.com Subject: RE: [SIP] Removing 409 to conflicting action params MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 10 Feb 2001 00:41:05 -0500 > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Friday, February 09, 2001 8:35 AM > To: Jonathan Rosenberg > Cc: Robert Sparks; sip@lists.bell-labs.com > Subject: Re: [SIP] Removing 409 to conflicting action params > > > Jonathan Rosenberg wrote: > > > > The reason it was there is that if the proxy DOES want to > follow it, it > > becomes meaningless to have some URLS with redirect, and > some with proxy. > > What does the proxy do? > > I am not asking that Proxy/Registrars be forbidden from > responding > 409 just that they be free to choose not to. Presently a > registrar > MUST respond 409 to conflicting action params. I don't want to > be forced to respond 409 when somebody has their mailto URL > registered > with an redirect action and then wants to add a SIP URL which > they want requests proxied to. It is not that simple. If you allow proxies to accept these kinds of things, that means you allow clients to send them. Once you do that, you must define concrete processing rules associated with registrations of this type. Otherwise, a UA now has no way of knowing the processing a proxy will apply to a set of registered Contacts, or worse, what the behavior they're requesting actually is. As an example, a UA believes it wants a service whereby the proxy server forwards the request to A, and if it fails, redirects to B. So, it registers a contact URL with proxy action as high q value, and a separate contact as redirect action as a lower proxy. It assumes that a proxy server will do this service as a result. THe proxy might accept this, and provide this interpretation, or it might accept it, and provide a different interpretation, or it might reject it. If it rejects it, what does the client do then? Must it alert the user to redefine the parameters? I wouldn't want to handle this customer service call. However, as defined now, the meaning of a set of registered contacts is CLEAR. If you want more complex behaviors, you send a CPL (and indeed, the above service is readily representable in a clear and unambigous way using CPL). By removing this restriction, and as a consequence, allowing clients to send all kinds of weird stuff, the end result will not be what users expect. -Jonathan R. > > > Does it mean to redirect if the highest q value URL > > has an action of redirect, even though others say proxy? > What if the q > > values are the same, or none were specified? We came to the > conclusion that > > it could mean any number of more complex behaviors, most of > which were more > > appropriately specified via a CPL than action params. > > > > So, I would like to keep this restriction. > > This is a fair point but we could define how a server > should respond to mixed action params wrt q values if that > is perceived to be an issue. I think that generally CPL will be > available to provide this sort of control where it is really > needed and so the whole existence of an action param is fairly > unintersting. If present can't it just be treated more as a hint. > A SIP server could then choose to try and follow them, use it's > own configuration policy or follow alternative user defined > processing logic (CPL etc). This gives more flexibility than > mandating 409s. > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 00:50:44 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10541 for ; Sat, 10 Feb 2001 00:50:43 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 33B89443E0; Sat, 10 Feb 2001 00:45:50 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 680D244336 for ; Sat, 10 Feb 2001 00:44:53 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA22377; Sat, 10 Feb 2001 00:47:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR9B55>; Sat, 10 Feb 2001 00:41:08 -0500 Message-ID: From: Jonathan Rosenberg To: "Henning G. Schulzrinne" , Henry Sinnreich Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP Conference-Discovering Participants Identities MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 10 Feb 2001 00:41:07 -0500 > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, February 04, 2001 9:57 AM > To: Henry Sinnreich > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] SIP Conference-Discovering Participants Identities > > > Henry Sinnreich wrote: > > > > Have a problem with the strict requirements that for secure > and confidential > > business conferences, the identity of all authenticated > participants should > > be clearly be known and preferably displayed at all times during the > > conference. > > > > However, the I-D on "Models for Multi-Party Conferencing in > SIP" states: > > >4.5 Discovering Participant Identities > > > The identities of other participants in the conference are > > > NOT known through SIP. > > > > Using RTP to display user identities seems broken, since an unwanted > > listener can have no RTP packets sent. > > http://ietf.org/internet-drafts/draft-rosenberg-sip-conferencing-models-00.t > xt > This particular problem can also be solved by a somewhat smarter mixer. Rather than acting as a pure mixer as defined in rfc1889, it generates RTCP SDES items for all people that have joined the conference at the sip level, but have not sent RTCP SDES on their own. It can construct the name, to some reasonable level, from the From field of the INVITE used to join the conference. An even smarter mixer might ignore the RTCP SDES sent from the users entirely, and rather, generate the RTCP SDES using the identity obtained from any SIP authorization/authentication process used to verify identity when the user join the conference in the first place. Since RTP (and RTCP) can be encrypted, you can also get privacy of this data by encrypting it. This way, only conference participants know the list of people in a conference; an eavesdropper cannot determine it. So, I think you can get adequate security features. If people think this idea is not too much of a hack, I will gladly add it to the conferencing models draft. >> Any other solution to display all participants? >> How could a conference bridge signal to users who else in participating? >> > >SUBSCRIBE/NOTIFY may be an appropriate mechanism. However, nothing >prevents a participant from having others listening in, so this isn't a >foolproof mechanism. SUB/NOT could work, as we discussed in the interim meeting today. However, I still maintain that there is a lot of other things you might want here, and they are part of a broader conference control protocol, for which one component is notifications of lists of subscribers. Rather than have a SIP mechanism for SUB/NOT for the subscriber list, and a SEPARATE protocol for managing those subscribers (consider the case where I get notified that a user joined, and then I want to mute them. Its a bit harder as this operation now spans two separate protocols; there may be issues with that), I'd rather specify out a conference control protocol that does everything. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 00:53:26 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10562 for ; Sat, 10 Feb 2001 00:53:24 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 90A84443E7; Sat, 10 Feb 2001 00:46:01 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0E3E144336 for ; Sat, 10 Feb 2001 00:44:54 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA22374; Sat, 10 Feb 2001 00:47:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR9B57>; Sat, 10 Feb 2001 00:41:08 -0500 Message-ID: From: Jonathan Rosenberg To: Jo Hornsby , William Marshall , jdrosen@dynamicsoft.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Some idea on Stateful SIP Proxy for Card Service MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 10 Feb 2001 00:41:07 -0500 > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Thursday, February 01, 2001 4:41 AM > To: William Marshall; jdrosen@dynamicsoft.com > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] Some idea on Stateful SIP Proxy for Card Service > > > William Marshall wrote: > > Consider a simple voicemail service, implemented by a > service provider. > > The UAS receives an INVITE, sends 180-Ringing, then 4xx/6xx > and gives up. > > The proxy changes the 4xx/6xx into a 302-Redirect with a > Contact header > > of the voicemail server. > > > > But, a proxy can't do this. So it is a B2BUA. There is > nothing about > > state storage needed, nothing extra for fault tolerance and scale; > > in fact this "proxy" is probably simpler than most > "stateful proxies". > > But its need to change the response from 4xx/6xx to 3xx > makes it a B2BUA. > > I disagree with this. I think it is fine for a proxy to pull > responses "out of the air". What's it's not allowed to do is > modify fundamental transaction-identifying headers (From, To, > Call-ID, CSeq, Via immediately spring to mind). Indeed, it is fine. Here is a proof, in fact. Consider that the proxy forks, gets a 4xx and a 5xx. Then, it forks once more, but to itself. WHen it receives this fork, it responds with a 3xx. Now, the best response is 3xx, which it may forward upstream. What a proxy should not do, is generate a response when there are pending proxied branches outstanding. If it does this, one of those pending branches may respond with a 200 OK, but you've already sent some other non-2xx upstream. Thats bad. This is why you REALLy want to have a UAS that responds to a cancelled INVITE with a 487; it guarantees that the proxy gets final responses before forwarding one upstream. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 00:56:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10575 for ; Sat, 10 Feb 2001 00:56:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A28C3443EC; Sat, 10 Feb 2001 00:46:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6F2F344336 for ; Sat, 10 Feb 2001 00:44:55 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA22367; Sat, 10 Feb 2001 00:47:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR9B56>; Sat, 10 Feb 2001 00:41:08 -0500 Message-ID: From: Jonathan Rosenberg To: "Rosen, Brian" , "'Jon.Peterson@Level3.com'" , chsharp@cisco.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 10 Feb 2001 00:41:07 -0500 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, February 02, 2001 9:28 AM > To: 'Jon.Peterson@Level3.com'; chsharp@cisco.com > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs > > > > And is it just me, or is the idea that BICC will be > > encapsulated in SIP > > somewhat counterintuitive? Are there any services today that > > require that? > > Anyway, if there is interest I'd be inclined to say that BICC > > should have > > it's own MIME type which should be discussed on its own merits. > > So, SIP-T is used for, among other things, ISUP-SIP-ISUP. > You don't think anyone wants to do BICC-SIP-BICC when SIP is > one operator's > network, and the BICCs are two other operators? > > I also see BICC-SIP-ISUP and of course ISUP-BICC-SIP-ISUP and > variations. Seems prejudicial in favor of SIP catering to BICC. If we do this, what about: SIP-BICC-SIP I think we should request the BICC guys to be able to encapsulate SIP messages. After all, what about service transparency across my SIP network! All these operators that are deploying SIP are doing so, in part, because of the service possibilities. Shall I be forced to lose those capabilities when I traverse an IP based BICC network? Why do the BICC guys get to keep their services, and the SIP guys don't? After all, BICC is even newer than SIP. Of course, once we do that, the more fun case is: ISUP-SIP-BICC-SIP-ISUP in which case the encapsulated SIP messages themselves contain ISUP messages, both of which are encapsulated in BICC. Of course, we should probably also consider the case of: SIP-ISUP-SIP Think about it; a SIP phone calls a PSTN number. It goes to an ss7 gateway. Turns out, that this number is then forwarded to another number, and that number is a VoIP terminal. So, it exits at another gateway, and hits the terminal. I suppose we should also request the ISUP guys to encapsulate SIP messages. Now then, we should also probably consider the case of: SIP-BICC-SIP-ISUP-SIP-BICC -Jonathan R. "reducio ad absurdum" --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 00:58:26 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10604 for ; Sat, 10 Feb 2001 00:58:25 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E0D91443F3; Sat, 10 Feb 2001 00:46:24 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 54D3D44336 for ; Sat, 10 Feb 2001 00:44:56 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA22365; Sat, 10 Feb 2001 00:47:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR9B5Y>; Sat, 10 Feb 2001 00:41:08 -0500 Message-ID: From: Jonathan Rosenberg To: Ashutosh Dutta , "Michael O'Doherty" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP in small adhoc and Pico networks MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 10 Feb 2001 00:41:06 -0500 I actually don't think SIP REGISTER is appropriate here. THe reason is that this problem is much broader than SIP. As a general issue, the devices which come into being in one of these piconets will have many services associated with URLS - ftp services, web services, IM services, sip services, and so on. Normally, these service URLs are published through out-of-bands means, like on a business card or from a directory service. What you need here is a way to construct dynamic, distributed directory services that allow you access to the resources on the network as they are introduced. In fact, the argument could be made that the right solution is actually a Directory Agent-less SLP network. When a device joins the piconet, it creates service agents that advertise the services on the device - the sip URL, for example, along with the parameters of that service (the name of the user, their codecs, and so on). By doing this with a service independent mechanism, it works for lots of things besides SIP. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Ashutosh Dutta [mailto:adutta@telcordia.com] > Sent: Friday, February 02, 2001 2:19 PM > To: Michael O'Doherty > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] SIP in small adhoc and Pico networks > > > > > Michael, would you assume each Piconet member in the same > subnet (broadcast > domain), can we define a well defined multicast address to > get the listing of > the users with SIP UA enabled in the neighborhood, and their > contact address, > may be by using something like SAP/SDP. > > Thanks > Ashutosh > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 00:59:53 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10628 for ; Sat, 10 Feb 2001 00:59:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 95F0A44404; Sat, 10 Feb 2001 00:47:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id 33389443F1 for ; Sat, 10 Feb 2001 00:46:20 -0500 (EST) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G8J00DII1D6YY@firewall.mcit.com> for sip@lists.bell-labs.com; Sat, 10 Feb 2001 05:46:18 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0G8J006011D5U3@dgismtp04.wcomnet.com>; Sat, 10 Feb 2001 05:46:18 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G8J006011D3TS@dgismtp04.wcomnet.com>; Sat, 10 Feb 2001 05:46:17 +0000 (GMT) Received: from Steveb1 ([166.44.245.121]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0G8J0060E1CT90@dgismtp04.wcomnet.com>; Sat, 10 Feb 2001 05:46:08 +0000 (GMT) From: "Christopher A. Martin" Subject: RE: [SIP] NAT, SOCKS 5 proxies, win proxies In-reply-to: To: "'Jonathan Rosenberg'" , "'John Lazzaro'" , sip@lists.bell-labs.com Reply-To: christopher.a.martin@wcom.com Message-id: <004001c09324$bffe6580$29e023a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 09 Feb 2001 23:46:00 -0600 Content-Transfer-Encoding: 7bit Jonathan, I believe that workarounds for firewall inadequacies is no better than removing the firewall. The issue of trust compounds the already insecure nature of SIP without adding a possible avenue of attack from an untrusted public source, through the use of SSL or TLS. by at least creating the functionality at or on the firewall one could at least have a fighting chance. Also as we know vulnerabilities exist, but also can be created by unsound architectures. Already SSL has been determined to be flawed in a lab environment, causing a systme vulnerability that may allow access to the server running it. TLS is supposed to fix alot of the downside to SSL, as well as become the standards based form of SSL, but does it also have the vulnerability? In the draft you state "The other alternative, embedding a SIP ALG within enterprise NATs and firewalls, has not happened. The top commercial firewall and NAT products continue to be SIP-unaware. Even if SIP ALG support were added immediately, there is still a huge installed based of firewalls and NATs that do not understand SIP." As an assumption on my part I would like to go out on a limb and state that just as SIP is evolving, and growing in support, so will the firewall vendors in implementing the solution. I also believe that if an enterprise has made the decision to implement SIP, whether to save money or take advantage of the new functionality offered at such a scale, they have already signaled that they are willing to do what it takes to support SIP. If the existing firewall technology cannot accomodate the business requirement to implement SIP, the enterprise will most likely find a vendor that can. As we know a couple of vendors have already begun to support SIP functionality, and others are following suit. But I've rambled my personal agenda long enough, on to the task at hand. Lets make the standards based methodology needed to propagate SIP to the world through NAT, short lived though it may be. :^) Christopher A. Martin SR. Security Integration Engineer IP Communications Engineering, WorldCom 972-729-4569 > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > Sent: Thursday, February 08, 2001 9:22 PM > To: 'John Lazzaro'; sip@lists.bell-labs.com > Subject: RE: [SIP] NAT, SOCKS 5 proxies, win proxies > > > All solutions for nat and firewall traversal that assume no enterprise > support are ugly. I have proposed one solution: > > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-ent > fw-00.txt > > which relies on a B2BUA outside of the firewall, coupled with > SIP over TLS. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: John Lazzaro [mailto:lazzaro@CS.Berkeley.EDU] > > Sent: Thursday, February 08, 2001 8:00 PM > > To: sip@lists.bell-labs.com > > Subject: Re: [SIP] NAT, SOCKS 5 proxies, win proxies > > > > > > > > afarhan@rediffmail.com writes: > > > a) SIP and RTP should be able to work from a single UDP port. > > > > This basic idea can work -- sooner or later I hope to write up > > a SIP B2BUA I've implemented for multi-party conference > > initialization that takes this route, mostly following the > > "Activision" techniques described in the recent "Protocol > > Complications with NAT" RFC. The ugliest aspect of this is > > that unless you also want to multiplex RTP and RTCP on the > > same UDP port, you need to have parallel SIP sessions going > > on two ports, on for the RTP port and one for the RTCP port. > > In my SDP-specific implementation for the B2BUA, the NAT > > information specified in the Activision algorithm gets > > embedded in SDP fmt lines by the SIP conference server, > > which is another ugly aspect ... although I believe that > > if the received tag for Via was a hostport, you might be able > > to legally embed this NAT information in the SIP itself. > > > > However, I think there's a big difference between "it can > > be made to work" and "everyone should do it" -- using the > > OS to do multiplexing is a pretty key concept in ALF, and > > when you ignore it all sorts of bad things result. > > One that immediately comes to mind -- you can't connect() > > the socket on the client if you're using the Activision > > algorithm in the multi-party case, since you're using the > > same socket to send RTP to several parties, as well as > > the SIP conference B2BUA. The result is, you can't get > > ICMP feedback to tell if you're UDP packets aren't being > > listened to, and need to use timeouts exclusively ... > > > > -------------------------------------------------------------- > > ----------- > > John Lazzaro -- Research Specialist -- CS Division -- EECS -- > > UC Berkeley > > lazzaro [at] cs [dot] berkeley [dot] edu > www.cs.berkeley.edu/~lazzaro > -------------------------------------------------------------- > ----------- > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 12:21:06 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26740 for ; Sat, 10 Feb 2001 12:21:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C868A44342; Sat, 10 Feb 2001 12:21:01 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 96A2744339 for ; Sat, 10 Feb 2001 12:20:41 -0500 (EST) 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 f1AHKed17073; Sat, 10 Feb 2001 18:20:40 +0100 (MET) Received: from lmf.ericsson.se (EWUwsp001639wss.sd.us.am.ericsson.se [142.133.141.55]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id SAA05157; Sat, 10 Feb 2001 18:20:36 +0100 (MET) Message-ID: <21DBD73D.B3CA4EC4@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tfu@cisco.com Cc: Keith.Robinson@marconi.com, sip@lists.bell-labs.com Subject: Re: [SIP] Overlap call setup References: <200102071007.CAA08604@cisco.com> <3A816987.11AC8D6A@lmf.ericsson.se> <3A81BD77.1CD3CB06@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Jan 1988 19:13:33 +0200 Content-Transfer-Encoding: 7bit Hello, > > This is wrong. If local alerting has to be performed the proper 1xx > > response is 180 Ringing. This has been pointed out several times in the > > mailing list. > > Be a bit more general, is it also possible to play some local > announcement (other than ringing) to PSTN side after received 183 > without SDP? If so, how to differentiate? To interpret 183 without SDP > as 'dialing incomplete so no ACM yet' only is a rather strong assertion > and I see no advantage of it over a dedicated response code or reason > phrase. Early media is being discussed right now, so things might change. Right now, 183 with no SDP does not imply playing any announcement to the user other than "Session in progress". Gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 12:34:02 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26796 for ; Sat, 10 Feb 2001 12:34:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E164C44349; Sat, 10 Feb 2001 12:34:01 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 0B93B44339 for ; Sat, 10 Feb 2001 12:33:38 -0500 (EST) 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 f1AHXaC03547; Sat, 10 Feb 2001 18:33:36 +0100 (MET) Received: from lmf.ericsson.se (EWUwsp001639wss.sd.us.am.ericsson.se [142.133.141.55]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id SAA06444; Sat, 10 Feb 2001 18:33:30 +0100 (MET) Message-ID: <21DBDA42.DD3A4CFB@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson Cc: Keith Robinson , bidulock@openss7.org, christer.holmberg@lmf.ericsson.se, Joshua Moloney , Tom-PT Taylor , sip@lists.bell-labs.com Subject: Re: [SIP] Overlap call setup References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Jan 1988 19:26:26 +0200 Content-Transfer-Encoding: 7bit Hello, Mark Watson wrote: > > There are other reasons for overlap which are not to do with > outpulsing delay/CAS interworking, but rather to do with determining > end of dialling. > > 1) Support of open dial-plans, where not even the terminating exchange > knows how many digits to expect, only the user equipment knows this > > 2) Simplification of routing data, so not all exchanges have to know > the global dial-plan in order to work out how many digits to expect > > In the absence of an indication of end-of-dialling from the calling > user you have only two choices: > a) Run an inter-digit timer and assume end of dialling if it expires > b) Overlap digits through the network towards a point where the end of > dialling can be determined from dial-plan knowledge > > It is generally felt that for networks puporting to offer PSTN or > better services, (a) is not acceptable as it adds post-dial delay and > can mis-identify end of dialling if the user is too slow. > > Of course an end-of-dialling indication from the user is highly > desirable, which is why all systems more advanced than simple > telephony are based on this (mobile phones, ISDN, SIP), but systems > exist, and will continue to exist for many decades, which do not > provide this. > > I believe there are important flaws in the mechanisms in the RFC and > isup mapping draft. Not least the requirements to have multiple > outstanding call legs for each extra digit, to use a whole INVITE for > a single digit and to tie these into a single call instance on the > ISUP side of a gateway could not be described as elegant. > It is not elegant, but it is the best mechanism (or less bad than the others, if you want). > We seem to be near reasonable solution based on negotiating the use of > INFOs Do not think so. As I said several times, if you want the SIP network to provide services, you have to go for multiple call legs. If you just want to transport signalling, SIP is a very bad protocol for that purpose. Use another. Using INFO for sending SAMs is trying to re-create the ISDN call model using SIP. I just do not like the whole idea. Regards, Gonzalo - I think we should go ahead and document this so that we can > bottom out the details. > > Regards, > > Mark Watson > Nortel Networks > > > -----Original Message----- > > From: Keith Robinson [mailto:Keith.Robinson@marconi.com] > > Sent: 07 February 2001 11:29 > > To: bidulock@openss7.org > > Cc: Gonzalo.Camarillo@lmf.ericsson.se; > > christer.holmberg@lmf.ericsson.se; Moloney, Joshua > [MDN05:CT07:EXCH]; > > Taylor, Tom-PT [NORSE:B901:EXCH]; sip@lists.bell-labs.com > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > Vendors could mandate that their SIP/PSTN gateways will > > always block up digits > > and do everything en bloc; thats fine. > > > > I was raising issues I had with the mechanism for supporting > > overlap sending if > > it was required to be performed because a particular > > administration wants to > > use overlap signalling. > > > > Regards, > > > > Keith. > > > > > > > > > > > > > > > > > > "Brian F. G. Bidulock" on 07/02/2001 06:49:08 > > > > > Please respond to bidulock@openss7.org > > > > > > > > > > > > > > > > > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > > > cc: Gonzalo.Camarillo@lmf.ericsson.se, > > christer.holmberg@lmf.ericsson.se, > > jmoloney@nortelnetworks.com, > > taylor@nortelnetworks.com, sip@lists.bell-labs.com > > > > > > > > Subject: Re: [SIP] Overlap call setup > > > > > > > > > > > > > > > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 12:49:02 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26853 for ; Sat, 10 Feb 2001 12:49:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3F86A44342; Sat, 10 Feb 2001 12:49:01 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 30D8544339 for ; Sat, 10 Feb 2001 12:48:49 -0500 (EST) 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 f1AHmmd19085; Sat, 10 Feb 2001 18:48:48 +0100 (MET) Received: from lmf.ericsson.se (EWUwsp001639wss.sd.us.am.ericsson.se [142.133.141.55]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id SAA07986; Sat, 10 Feb 2001 18:48:42 +0100 (MET) Message-ID: <21DBDDD2.803C4463@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson Cc: Tom-PT Taylor , Christer Holmberg , sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Jan 1988 19:41:38 +0200 Content-Transfer-Encoding: 7bit Hello, Mark Watson wrote: > > Gonzalo, > > I thought at the beginning of this thread Keith Robinson identified a > number of fundamental flaws with the overlap mechanism in the draft. > If I understood rightly, these were: > > 1) UAS behaviour on receiving multiple INVITES for new Call Legs of > the same Call, but with different FROM and TO fields is undefined in > the RFC > It is not defined because it does not need to be defined. Different implementations will do different things. The RFC does not and MUST NOT cover those situations. For example, if I have multiple call legs in a gaming session, should the RFC define what to do? In a conferencing environment the correct behavior might be just to mix the media. Anyway, a gateway will know what to do with multiple call legs that carry more digits in the to field. If the entity receiving the INVITEs is a UA it will not represent a problem either. The UA will process the first INVITE and answer 484 or 404. Then, it will receive the 2nd and try to process it. If there are nor enought digits, it will respond again 484 or 404. If there are enough digits, the call will be established. Thus, I do not see any problem here. > 2) The UAC must use source routing to ensure that all these INVITES > make it to the same UAS What is the problem here? This is done in order to address the problem of proxies performing load balancing. Some folks have pointed out that maybe the betwork wants to route the second INVITE in a different way... why the network would like to do that? The policy that is applicable to the fist INVITE (that contained a prefix of the number) should be the same that applies to the subsequent ones. I do not think that the network wants that all the calls to numbers begining by +1234 traverse proxy A, but if the prefix is +12345 should traverse proxy B. I do not see any real situation where the source routing performed here might cause a problem. > 3) 183 is used to transport the CONTACT of the UAS to UAC, but 183 may > also cause a backwards ACM to be generated, cutting off further > digits. I said already that this will be clarified in the draft. However, this has to do with the early media issue also. > > I may have mis-understood some of the points slightly, and there may > be more. > > Overlap is a feature of the legacy PSTN - I don't think we need to > kill ourselves making SIP support overlap in some kind of native way. > Rather, a simple mechanism which allows consenting UAs to negotiate > the direct exchange of overlap digits over a single Call Leg would be > much better. It's not the same as SAMs because we can negotiate this > mechanism to be used only once the UAS has been found. Until this > point, calls without enough digits are killed right away with 484s. > > The price we pay for this is that intermediate proxies may not have > access to the full Called Party Number - but a proxy that needs this, > that wants to offer service on overlap calls, can always sniff the > overlap digits as they go past. Let me get this straight. Are you are proposing to change the logic in all the already existing proxies because you want to provide services when you use INFO for carrying SAMs? This is just impossible. I still prefer a mechanism that do not require changes in the existing proxies (multiple call-legs). Best regards, Gonzalo > > Regards, > > Mark Watson > Nortel Networks > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: 07 February 2001 02:52 > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > Hi Tom, > > > > Still I want to have full state in every SIP message. If the call is > > > addresed to the phone number 1234, I want to have a to field that > says > > 1234. I do not care if there is a leg routed thru the PSTN and > another > > thru SIP. > > > > Carrying full state is one of the beauties of SIP. If we begin using > > > INFO for this, it would be the same as using SAMs. Differen names, > the > > same thing... I do not want to re-create ISUP using SIP. I > > believe that > > if the session has a destination, it should be present in the > > to field. > > > > Again, if a proxy is providing services for this particular call, it > > > will want to see the called party number in order to trigger > > the proper > > service. This is a very good reason for updating the to field > > every time > > we have more digits. > > > > I like to use SIP between two gateways because it is possible > > to provide > > SIP services for a PSTN to PSTN call. If all we want to do is > > finding a > > egrees gateway, we would probably want to use other protocols (TRIP > & > > SIGTRAN for instance). > > > > Regards, > > > > Gonzalo > > > > Tom-PT Taylor wrote: > > > > > > Sorry, we're talking past each other. The premise of my > > statements is > > > that an INVITE has reached a UAS which has accepted it. It > follows > > > that the UAS did not send back a 484, but rather an interim > > response. > > > IF more digits come along, the INFO method is there to carry them. > > > > They do not affect the SIP call state; they are used beyond the > UAS, > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hello Tom, > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > signalling > > > > > has reached an egress gateway, SIP has done its job -- > > additional > > > > > digits will not change call state. It is therefore > > > > reasonable to use > > > > > INFO to carry the additional digits. If we are talking > > > > ISUP-SIP, once > > > > > the destination UAS or a UAS in a B2BUA has been > > reached, the same > > > > > > > > consideration applies. > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > vanilla SIP UA. > > > I > > > > will return a Not Found or a 484 Address incomplete. The > > > > subsequent INFO > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > gateway > > > > will have to re issue a new INVITE with all the digits. > > > > Therefore, it is > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > Besides, I do not think that SIP is just a transport protocol > that > > > > carries ISUP messages between two gateways. For that, we have > > > already > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > call is a > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > state. And a > > > > SIP message with an incomplete to field does not carry complete > > > state. > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > > based > > > > on the to field (called party number). That proxy would > > like to see > > > an > > > > updated to field, not just a to field that contains just some > > > digits. > > > > > > > > Best regards, > > > > > > > > Gonzalo > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > To: Gonzalo Camarillo > > > > > > Cc: sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > been proposed > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > > reason for > > > > > > the discussion from the beginning was that the overlap > > > signalling, > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > very well, and > > > > > a > > > > > > solution using 18x responses and INFO messages, instead of > 484 > > > and > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer Holmberg > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > signalling section. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty > much > > > > > > about calls > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > SIP UAS > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > | <- 18x ------ | > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > | <- 200 (INFO) | > > > > > > > > | <- 18x ------ | > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > --> > > > > > > > > | <- 200 (INVITE)| <- 200 > ------ > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > the word 'proxy') > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > overlap dialing, to > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > > the digits > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > > be allowed to > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > INVITEs, until > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > -- > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > FIN-02420 Jorvas Email : > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : > Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 12:58:03 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26903 for ; Sat, 10 Feb 2001 12:58:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8CB144342; Sat, 10 Feb 2001 12:58:01 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 5F9EE44339 for ; Sat, 10 Feb 2001 12:57:30 -0500 (EST) 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 f1AHvTC05065; Sat, 10 Feb 2001 18:57:29 +0100 (MET) Received: from lmf.ericsson.se (EWUwsp001639wss.sd.us.am.ericsson.se [142.133.141.55]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id SAA08836; Sat, 10 Feb 2001 18:57:15 +0100 (MET) Message-ID: <21DBDFD3.8B1D1D39@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: christer.holmberg@lmf.ericsson.se, jmoloney@nortelnetworks.com, taylor@nortelnetworks.com, sip@lists.bell-labs.com, adam.roach@ericsson.com Subject: Re: [SIP] Overlap call setup References: <802569EC.004E0F4E.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Jan 1988 19:50:11 +0200 Content-Transfer-Encoding: 7bit Hello, Keith Robinson wrote: > > Thanks for the reply. A few points to clarify my thoughts: > > On the issue of source routing, I am aware of the discussion that took (is still > taking ?) > place. My concern is not of a technical nature (it will work), it is of an > administrative nature; what > if an administration does not want soucre routing occuring in its domain for > security, > accounting reasons etc. It IS possible for a proxy to determine that an INVITE > is > an initial INVITE; it looks in the TO tag field and finds it blank which means > this MUST > be an initial INVITE as opposed to a subsequent INVITE on a call leg its > forgotten > about. So, a proxy MAY be configured to reject these INVITEs while still being > robust. > Thats why I suggested a solution that would not rely on source routing. I answer to this in my previous mail. I do not think that the proxy is going to apply a different policy (proxies that the request will traverse) when more digits are received. If an INVITE to +1234 has to go thru proxy A, another INVITE to +12345 will have to traverse proxy A also. Thus, the Route will not change from one request to the other. Anyway, if a network is not performing load balancing between gateways it can ignore the record-route. Its only purpose is to avoid multiples INVITEs to arrive to different egrees gateways. If this happended, multiples IAM would be generated rather than a IAM and several SAMs. > > On the issue of vanilla UAs, I would not expect them to generate INFO; I would > expect them to get back > a 484 (or possibly 404) and so generate a new call attempt. Excantly. Thus, in this situation you would be using the multiple call legs approach. That is a bid advantage. It works with gateways and with vanilla SIP UAs. INFO does not. > Also, is it > realistic that a SIP UA is going to send > its digits in 'overlap mode' anyway ? I hope that the only SIP UAs that send digits in overlap mode are the gateways towards the PSTN. > to enter the complete > digit string and then ask the UA to send this digit string; the digits either > decode to an endpoint somewhere > or translate to Number Unobtainable ? > > The full address (or that received so far) could be carried in the INFO message > in a new header > or a parameter of the TO URL. > > Having said this, I take your point about retaining state in a single SIP > message. If it is > mandated that SIP/PSTN gateways only ever signal en-bloc then the overlap > sending > issues are avoided. > > Clarification of when to generate the ACM, along the lines of your posting, > would be useful. Yes, I will do it. Best regards, Gonzalo > > I am still concerned that RFC2543bis-02 defines (very sketchily) overlap sending > in a > way that is flawed (using Request-URI). This needs addressing by the SIP > authors. > > Regards, > K. Robinson > > Gonzalo Camarillo on 06/02/2001 21:11:50 > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > cc: christer.holmberg@lmf.ericsson.se, > jmoloney@nortelnetworks.com, > taylor@nortelnetworks.com, sip@lists.bell-labs.com, > adam.roach@ericsson.com > > > > Subject: Re: [SIP] Overlap call setup > > > Hello, > > Thanks for the pointer. Answers inline: > > Keith Robinson wrote: > > > > Attached is an earlier posting I raised highlighting my concerns with some of > > the > > mechanisms outlined in the sip-isup document. This is the source of recent > > discussions. > > > > Regards, > > > > K. Robinson > > ---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 06/02/2001 > 16:42 > > --------------------------- > > > > 31/01/2001 16:34 > > Keith Robinson > > > > To: "Joshua Moloney" @ MCEXT > > cc: sip@lists.bell-labs.com@MCEXT > > > > Subject: Re: [SIP] Overlap call setup (Document link: Keith Robinson) > > > > I have recently been trying to get clarification on the implemenation of > > overlap sending; see attached for the discussion that has taken place > > so far. > > > > Certainly, the mechanism outlined (very sketchily) in RFC2543bis-02 sect 4.2.1 > > is fundamentally flawed. The Request-URI cannot be used to carry extra digits > > as the Record-Route/Route mechanism would end up overwriting the R-URI > > and therefore the subsequent digits would be lost. > > > > This then leads to the idea of using the TO field as described in > > sip-isup-00-00.txt; > > however, I have the following issues with the mechanisms described in this > > document : > > > > As the TO field is different on each subsequent INVITE, then it is a new call > > leg > > on an existing call id; RFC2543bis-02 sect. 11.5 does not state what a UAS > > should make of this. If you follow the logic in 11.5 you get to case (3), but > > here it only defines the behaviour if the TO and FROM fields match. > > > > I do not see here a big problem for a UA. If the UA is a gateway, it > will handle the overlap signalling properly. If it is a pure SIP UA, it > will answer the first INVITE with a 484 (or "Not found response") and > process the second INVITE properly. > > > The 484 sent backwards kills that call attempt (but not the state for that > > Call-Id - > > is this problematic for intermediate proxies ?) so subsequent INVITEs will > > actually be initial INVITEs. As these INVITEs must get to the same terminating > > UAS, > > the originating UAC will have to create a ROUTE header in an initial INVITE > > using , > > at least the CONTACT address from the 484. This implies the use of source > > routing, an > > issue that I don't believe has been fully resolved, and even if it is and > > becomes part > > of the base protocol some administrations may be reluctant to admit initial > > INVITEs > > which try to circumvent their routing policy, so may reject such INVITEs. > > > > There was a big thread about source routing. This kind of source routing > is fine. Current proxies handle it properly. > > If a proxy sees an INVITe with a route header, it does not know if it is > the first INVITE or a re-INVITE. Thus, it will work properly. > > Even if the proxy stores state and it receives a INVITE (non re-INVITE) > with a route header, it should honor it. Otherwise, the proxy is not > robust. This allows a call stateful proxy to lose state, re-boot and > still be able to route requests properly. > > > Also on the above point, the CONTACT address in the 484 must have the same > > semantics as that in a 200 response so that a ROUTE header can be built; > however > > RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in 4XX responses > > indicates a location where additional error information can be found. Indeed, > in > > a recent > > thread entitled Announcements in SIP (401 & 407 Contact) J. Rosenberg believes > > that > > Record-Route does not make sense in any non-200 response. > > This contact header that is going to be used is the one present in the > 183, not in the 484. This solves the problem of several IAMs al the same > time. If the answer was a 484, no IAM was sent. Thus, the next re-INVITE > with more digits can be very well handled by a different gateway. > > > > > I would raise the question of whether the 484 response has any use in overlap > > sending > > (certainly in the case of ISUP) at all. > > 484 responses are not very useful in this scenario, but they might be > useful in anothers (when a UA can ask the user to type more digits, for > instance). > > If a node receives insufficient digits > > to decode than it will wait until it receives some more from the preceding > node > > (or end of > > dialling timers mature). If the preceding node receives subsequent digits and > > end of dialling > > has not been detected then it will pass them on. If the 484 indicated the > > minimum number of > > digits before a decode could take place, then it would be useful in cutting > down > > the number > > of subseqent messages sent. > > > > Indeed, isup-sip-00.txt does cover the mechanism where a 183 is sent, and not > a > > 484. > > The case in point is covered in sect. 11.3 (Example of SIP bridging and > overlap > > signalling); > > However, I have the following issues with this mechanism: > > > > As before relies on source routing. > > See comments above about this type of source routing. > > > > > Relies on proxies sending requests on new call legs but existing call-ids to > the > > same > > downstream server; fine if you administer these proxies, what if you don't ? > > Why would you want to limit a call to one call leg?? > > > (Lots of > > wasted IAMs generated). > > Lots of IAMs????? > > The situation where more than one (typically two) IAMs are generated is > when the 183 arrived to the ingrees gateway after it sent the first > re-INVITE. This situation is ulikely to happen anyway, because if you > receive subsequent digits so fast (faster than a RTT), you should > implement a timer, and not send LOTS of SAMs anyway. > > > The mechanism should not send 5 (subsequent INVITE) > > until it has received an acknowledgement (probably not 100) from the first. > > Again a timer configuration problem. You can, and your re-INVITE will > most likelt reach the same egrees gateway as the 1st one... but it might > reach a different one. Thus, the ingrees gateway should be aware of this > and be ready for canceling one of the TWO IAMs sent if this happen. > > But again, this situation is not common. > > > Alternatively, > > the Reason-Phrase could detail more specifically the exact progress of the > call > > ("Decoding Address" > > in this case ?) so that the ACM is not generated unconditionally. > > > > Sect. 11.2 encourages gateways "to return a183 Session Progress with a Contact > > header as soon as they receive an INVITE that they are going to handle and > might > > contain > > an incomplete number". Presumably this is to allow the UAC to build a ROUTE so > > that subsequent > > INVITEs get to the appropriate UAS. > > YES. > > > Sect 7.2.3 indicates that a node receiving a > > 183 prior to generating > > an ACM should generate an ACM. Applied together these rules may cause a prior > > node to never > > send on any subsequent digits and overlap sending would fail. > > The same way that nodes handling overlap signalling do not release the > call upon reception of a 484, they will not generate ACMs upon reception > of a 183 without SDP and without an ancapsulated ACM... we might want to > add this clarification to the draft. > > > > > I think an approach is required whereby subsequent digits are sent on the same > > call leg as the > > initial INVITE; either multiple INVITEs are allowed before 200 OK (already > > suggested by J. Rosenberg > > in a different context) > > Stacking requests is not a good solution in this case. It leads to a lot > of problems that we certainly want to avoid. > > > , or the INFO method is used. > > If INFO is used any vanilla SIP UA should implement INFO in order tor > receive calls/sessions that use overlap signalling. One of the most > important requirements for overlap signalling in SIP was that a vanilla > SIP UA could handle it. > > In both cases the TO field > > will have to remain the > > same so a new header (or message body type) is required to convey the digits. > > Again, we do not want to implement this in vanilla SIP UAs. > > Best regards, > > Gonzalo > > > Also, replace the 484 > > with, say, 18X indicating the minimum number of digits required, perhaps in > the > > Reason-Phrase header. > > > > Regards, > > > > Keith Robinson. > > > > "Joshua Moloney" on 31/01/2001 10:49:33 > > > > > > > > > > > > > > > > To: sip@lists.bell-labs.com > > > > cc: (bcc: Keith Robinson/MAIN/MC1) > > > > > > > > Subject: [SIP] Overlap call setup > > > > > > Greetings, > > > > I would like to ask for clarification regarding the implementation of > > Overlap. > > > > I'll begin by referring to paragraph 3, section 6.1.2 of > > "draft-ietf-isup-sip-00": > > > > It is stated that INVITEs sent after the first one (containing extra digits > > in the 'To' field) are to be treated as new Call-Legs, seeing as the > > contents of their 'To' headers differ. As such, there is no relationship > > between their CSeq values. > > > > If this is the case, how is it possible to ensure correct digit ordering > > over an 'unreliable' transport layer like UDP? It would seem logical that > > the call originator _would_ use contiguous CSeq values, as it would be > > 'aware' of the fact that the INVITEs are for the same call. > > > > I believe that this issue was raised on the SIP list on 19 November 1999 by > > Gonzalo C and Jonathan R. The subject of the messages was "Re: Comments on > > draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of the exchange > > appeared to be an agreement that CSeq ordering should be employed. > > > > However, does this in any way imply that under such circumstances the > > INVITEs would/should belong to the same Call-Leg? After all, the concept of > > Overlap does not seem to 'fit in' with the concept behind multiple Call-Legs > > anyway. > > > > If there has been a change in thinking behind the problem, and the latest > > draft is correct, please could you explain how the ordering problem will be > > overcome. If not, perhaps the draft needs modification to include these > > considerations... > > > > Regards, > > > > Josh Moloney > > > > ------------------------------------------------------------------------ > > Name: att1.htm > > att1.htm Type: Hypertext Markup Language (text/html) > > Encoding: base64 > > Description: Internet HTML > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 13:10:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26990 for ; Sat, 10 Feb 2001 13:10:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6441B44338; Sat, 10 Feb 2001 13:10:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (farley.cisco.com [171.71.153.30]) by lists.bell-labs.com (Postfix) with ESMTP id 92F1744337 for ; Sat, 10 Feb 2001 13:09:02 -0500 (EST) Received: from tfu-pc (sbrand-dsl1.cisco.com [10.19.132.178]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id KAA12312; Sat, 10 Feb 2001 10:08:53 -0800 (PST) Message-Id: <200102101808.KAA12312@cisco.com> X-Sender: tfu@overnight.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 To: Gonzalo Camarillo From: Taichi Fu Subject: Re: [SIP] Overlap call setup Cc: Keith.Robinson@marconi.com, sip@lists.bell-labs.com In-Reply-To: <21DBD73D.B3CA4EC4@lmf.ericsson.se> References: <200102071007.CAA08604@cisco.com> <3A816987.11AC8D6A@lmf.ericsson.se> <3A81BD77.1CD3CB06@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 10 Feb 2001 10:08:53 -0800 Gonzalo, Thanks for your explanation. Taichi At 07:13 PM 1/1/88 +0200, Gonzalo Camarillo wrote: >Early media is being discussed right now, so things might change. So I guess we need either a new response code, a special formulated 183 for (local) early media or else. Hope to see a general consensus. >Right now, 183 with no SDP does not imply playing any announcement to the user >other than "Session in progress". If so hope to see the following statement be added in Section 7.1.5 of rfcbis2 (if it is not already there): '183 with no SDP must (should ?) not play any announcement (early media) to the user. Also 'no early media if 183 w/o SDP' seems not exactly to be the same as 'no ACM if 183 w/o SDP'. But that is only my conjecture. >Gonzalo > >_______________________________________________ >This list is for continuing development of the SIP protocol. >The sip-implementer's list is the place to discuss implementation, >and to receive advice on understanding existing sip. >To subscribe to it, send mail to majordomo@cs.columbia.edu with >"subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 17:10:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28801 for ; Sat, 10 Feb 2001 17:10:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AD9F544338; Sat, 10 Feb 2001 17:10:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 998A044338 for ; Sat, 10 Feb 2001 17:09:41 -0500 (EST) 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 RAA02213; Sat, 10 Feb 2001 17:09:42 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA28811; Sat, 10 Feb 2001 17:09:39 -0500 (EST) Message-ID: <3A85A672.7DFDB1B0@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Henry Sinnreich , sip@lists.bell-labs.com Subject: Re: [SIP] SIP Conference-Discovering Participants Identities References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 10 Feb 2001 12:37:06 -0800 Content-Transfer-Encoding: 7bit > > This particular problem can also be solved by a somewhat smarter mixer. > Rather than acting as a pure mixer as defined in rfc1889, it generates RTCP > SDES items for all people that have joined the conference at the sip level, > but have not sent RTCP SDES on their own. It can construct the name, to some > reasonable level, from the From field of the INVITE used to join the > conference. > > An even smarter mixer might ignore the RTCP SDES sent from the users > entirely, and rather, generate the RTCP SDES using the identity obtained > from any SIP authorization/authentication process used to verify identity > when the user join the conference in the first place. > > Since RTP (and RTCP) can be encrypted, you can also get privacy of this data > by encrypting it. This way, only conference participants know the list of > people in a conference; an eavesdropper cannot determine it. > > So, I think you can get adequate security features. > > If people think this idea is not too much of a hack, I will gladly add it to > the conferencing models draft. To some extent a mixer already has to generate its own RTCP messages, either copying the RTCP from incoming streams or generate its own set, so this is standard behavior for a mixer. If the conference server acts as an RTP translator, i.e., simply replicates packets, it can do something similar. > > >> Any other solution to display all participants? > >> How could a conference bridge signal to users who else in participating? > >> > > > >SUBSCRIBE/NOTIFY may be an appropriate mechanism. However, nothing > >prevents a participant from having others listening in, so this isn't a > >foolproof mechanism. > > SUB/NOT could work, as we discussed in the interim meeting today. However, I > still maintain that there is a lot of other things you might want here, and > they are part of a broader conference control protocol, for which one > component is notifications of lists of subscribers. Rather than have a SIP In many cases, for a central conference server, you really don't need much more than that. We are controlling permissions and media replication via a web interface in our server, which seems to work pretty well. The one advantage of SUB/NOT is that's easier to divorce media from such notifications. For example, you can imagine long-running chat rooms where I want to be notified whenever a certain person shows up (or leaves, depending on my particular preferences). That's pretty natural for the subscription model. > mechanism for SUB/NOT for the subscriber list, and a SEPARATE protocol for > managing those subscribers (consider the case where I get notified that a > user joined, and then I want to mute them. Its a bit harder as this > operation now spans two separate protocols; there may be issues with that), > I'd rather specify out a conference control protocol that does everything. > This fictitious protocol has been around for so long, that I'm somewhat concerned to keep useful functionality from being deployed. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 17:11:24 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28847 for ; Sat, 10 Feb 2001 17:11:23 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 20C1344340; Sat, 10 Feb 2001 17:10:26 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id DAE2D44338 for ; Sat, 10 Feb 2001 17:09:42 -0500 (EST) 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 RAA02219; Sat, 10 Feb 2001 17:09:43 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA28815; Sat, 10 Feb 2001 17:09:41 -0500 (EST) Message-ID: <3A85A75D.8A91D080@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Ashutosh Dutta , "Michael O'Doherty" , sip@lists.bell-labs.com Subject: Re: [SIP] SIP in small adhoc and Pico networks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 10 Feb 2001 12:41:01 -0800 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > I actually don't think SIP REGISTER is appropriate here. THe reason is that > this problem is much broader than SIP. That is true, but that doesn't argue any more for not using REGISTER as in a non-ad-hoc network. After all, we could also use SLP to locate users in a regular network for SIP. SLP isn't particularly well suited for locating persons, as it's mostly designed for parameterized services. I'm sure you could modify it appropriately, but the REGISTER approach seems pretty natural for the user-location model. > > As a general issue, the devices which come into being in one of these > piconets will have many services associated with URLS - ftp services, web > services, IM services, sip services, and so on. Normally, these service URLs > are published through out-of-bands means, like on a business card or from a > directory service. What you need here is a way to construct dynamic, > distributed directory services that allow you access to the resources on the > network as they are introduced. > > In fact, the argument could be made that the right solution is actually a > Directory Agent-less SLP network. When a device joins the piconet, it > creates service agents that advertise the services on the device - the sip > URL, for example, along with the parameters of that service (the name of the > user, their codecs, and so on). By doing this with a service independent > mechanism, it works for lots of things besides SIP. > > -Jonathan R. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 21:35:52 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03069 for ; Sat, 10 Feb 2001 21:35:51 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 29AE144338; Sat, 10 Feb 2001 21:35:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from gtei1.bellatlantic.net (gtei1.bellatlantic.net [199.45.40.145]) by lists.bell-labs.com (Postfix) with ESMTP id 4A8E544337 for ; Sat, 10 Feb 2001 21:34:52 -0500 (EST) Received: from eburger (adsl-141-156-35-49.bellatlantic.net [141.156.35.49]) by gtei1.bellatlantic.net (8.9.1/8.9.1) with SMTP id VAA22694; Sat, 10 Feb 2001 21:34:55 -0500 (EST) From: "Eric Burger" To: , , Cc: "Rohan Mahy" , "Kevin Wang" Subject: RE: [SIP] New version of message waiting draft 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: <4.1.20010209060045.01f07da0@imop.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 10 Feb 2001 21:35:11 -0500 Content-Transfer-Encoding: 7bit [First of all, I suggest any follow-up to go to the sip-events list!!!] If I may rephrase Kevin's question, it is "what happens if I (the UA) crashes after I've set up a SUBSCRIPTION?" For example, the UA will receive what are, in its view, unsolicited NOTIFY messages. Alternately, the UA may recognize that the NOTIFY messages belong to it, but it will have lost the initial state. Remember, the NOTIFY message only propagates updates (IMHO the correct choice). My response to the question: if the UA crashes, when it restarts it will re-subscribe to the message presence server. This subscription is an initial subscription, so the UA will receive the entire state of the mailbox. See Section 5.3 of the draft. > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Rohan Mahy > Sent: Friday, February 09, 2001 9:02 AM > To: Kevin Wang; sip@lists.bell-labs.com > Subject: RE: [SIP] New version of message waiting draft > > > At 08:33 AM 2/8/01 , Kevin Wang wrote: > >Hi, > > > >I guess I did not make my 2nd question clear. If we look at the NOTIFY > >message A5 on Page 5, we may find out that the 3rd section and > 4th section > >of the NOTIFY message contain some information (such as message subject, > >date/time, priority, etc) about the new voicemail messages. However, the > >NOTIFY message for re-synchronization (for example A3) does not > contain that > >information. So, my question is: if a UA loses its previous data for some > >reason and restart again, how can the UA retrieve that > information (message > >subject, date/time, priority, etc) from the Notifier? > > it is unreasonable to resyncronize this information with NOTIFY, so the > client must use POP or IMAP to get the current contents of the mailbox. > > thanks, > -rohan > > >Thanks, > > > >-Kevin > >> -----Original Message----- > >> From: Rohan Mahy [SMTP:rohan@cisco.com] > >> Sent: Thursday, February 08, 2001 10:57 AM > >> To: Kevin Wang; sip@lists.bell-labs.com > >> Subject: RE: [SIP] New version of message waiting draft > >> > >> Hi, > >> > >> At 12:59 PM 2/7/01 , Kevin Wang wrote: > >> >I have 2 questions about this message waiting draft: > >> >(1) In the 2nd paragraph of section 5.1, "The Subscriber MAY also > >> explicitly > >> >fetch the current status at any time." How does a subscriber fetch the > >> >status? Based on the draft, my guess is that the subscriber sends a > >> >re-SUBSCRIBER message and expects the current status in a > NOTIFY message. > >> >Could the subscriber expect the current status in the 200 OK? (In this > >> way, > >> >we do not need that NOTIFY message for re-synchronization). > >> > >> you can't put this in the 200, because the SUBSCRIBE might be > forked, and > >> only one of the 200s will get back. > >> > >> >(2) I notice that there is no user's message information in the NOTIFY > >> >message for re-synchronization. (There is user's message > information in > >> the > >> >NOTIFY message when the status of the messages changes.) If a UA is > >> shutted > >> >down abnormally and lost all the information, how can it get > the user's > >> >message information when it is restarted? > >> > >> POP or IMAP. getting this via NOTIFY is not practical. > >> > >> >> -----Original Message----- > >> >> From: Rohan Mahy [SMTP:rohan@cisco.com] > >> >> Sent: Wednesday, February 07, 2001 11:26 AM > >> >> To: sip@lists.bell-labs.com > >> >> Subject: [SIP] New version of message waiting draft > >> >> > >> >> Hi, > >> >> > >> >> I just finished a new version of the message waiting draft from Ilya > >> Slain > >> >> and I. Until it appears in the archives it is available at: > >> >> > >> >> ftp://ftpeng.cisco.com/rmahy/draft-mahy-sip-message-waiting-01.txt >> >> >> >> thanks, >> >> -rohan >> >> >> >> _______________________________________________ >> >> This list is for continuing development of the SIP protocol. >> >> The sip-implementer's list is the place to discuss implementation, >> >> and to receive advice on understanding existing sip. >> >> To subscribe to it, send mail to majordomo@cs.columbia.edu with >> >> "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 10 21:37:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03097 for ; Sat, 10 Feb 2001 21:37:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 46AA84434A; Sat, 10 Feb 2001 21:36:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from gtei1.bellatlantic.net (gtei1.bellatlantic.net [199.45.40.145]) by lists.bell-labs.com (Postfix) with ESMTP id 5AD7644337 for ; Sat, 10 Feb 2001 21:35:02 -0500 (EST) Received: from eburger (adsl-141-156-35-49.bellatlantic.net [141.156.35.49]) by gtei1.bellatlantic.net (8.9.1/8.9.1) with SMTP id VAA22732; Sat, 10 Feb 2001 21:35:03 -0500 (EST) From: "Eric Burger" To: "Rohan Mahy" , Cc: , , Subject: MWI unsubscribe (was [SIP] New version of message waiting draft) 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: <4.1.20010207081937.00b93de0@imop.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 10 Feb 2001 21:35:17 -0500 Content-Transfer-Encoding: 7bit [First of all, I suggest any follow-up to go to the sip-events list!!!] Much better than the last version! Conceptually, what we try to achieve with MWI is the _presence_ of messages on the messaging server, much in the same way as we look for the _presence_ of people on an instant messaging system. This philosophy doesn't change anything in the draft, but including some sort of language to that effect would make it more accessible to the reader. On a behavioral level, I understand why the notification entity sends message A13 in response to the unsubscribe request A11. However, the UA really doesn't want this information. I was thinking of how to do an unsubscribe, without either messing up the semantics of SUBSCRIBE or creating a new method. How about if the unsubscribe message A11 did NOT include the "Accept: application/simple-message-summary" header. Being a well-formed message, the notifier would send a 200 OK and the session is finished. This assumes that "Expires: 0" in the new message A11. I would put it in the spec that a non-zero Expires time without an Accept header results in bizarre behavior. Notification servers SHOULD reply with a 4xx (406?) response in this case. Either way the session will be finished, as there's no reason for a notification server to create a session to *not* send notifications. Should this be part of sub/notify (S 5.1.5.3), or is it too odd? -- - Eric _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sun Feb 11 08:50:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08777 for ; Sun, 11 Feb 2001 08:50:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8A1AE44338; Sun, 11 Feb 2001 08:50:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3272144337 for ; Sun, 11 Feb 2001 08:49:46 -0500 (EST) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G8L00F65IETJO@firewall.mcit.com> for sip@lists.bell-labs.com; Sun, 11 Feb 2001 13:49:41 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G8L00101IEQT9@dgismtp02.wcomnet.com>; Sun, 11 Feb 2001 13:49:41 +0000 (GMT) Received: from hsinnreich ([166.44.137.20]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G8L00MDKHYCFZ@dgismtp02.wcomnet.com>; Sun, 11 Feb 2001 13:49:35 +0000 (GMT) From: Henry Sinnreich Subject: RE: [SIP] SIP Conference-Discovering Participants Identities In-reply-to: To: Jonathan Rosenberg , "Henning G. Schulzrinne" Cc: sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 11 Feb 2001 07:49:33 -0600 Content-Transfer-Encoding: 7bit >If people think this idea is not too much of a hack, It does not appear to be a hack, but rather a normal task for the application. Henry -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg Sent: Friday, February 09, 2001 11:41 PM To: Henning G. Schulzrinne; Henry Sinnreich Cc: sip@lists.bell-labs.com Subject: RE: [SIP] SIP Conference-Discovering Participants Identities > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, February 04, 2001 9:57 AM > To: Henry Sinnreich > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] SIP Conference-Discovering Participants Identities > > > Henry Sinnreich wrote: > > > > Have a problem with the strict requirements that for secure > and confidential > > business conferences, the identity of all authenticated > participants should > > be clearly be known and preferably displayed at all times during the > > conference. > > > > However, the I-D on "Models for Multi-Party Conferencing in > SIP" states: > > >4.5 Discovering Participant Identities > > > The identities of other participants in the conference are > > > NOT known through SIP. > > > > Using RTP to display user identities seems broken, since an unwanted > > listener can have no RTP packets sent. > > http://ietf.org/internet-drafts/draft-rosenberg-sip-conferencing-models-00.t > xt > This particular problem can also be solved by a somewhat smarter mixer. Rather than acting as a pure mixer as defined in rfc1889, it generates RTCP SDES items for all people that have joined the conference at the sip level, but have not sent RTCP SDES on their own. It can construct the name, to some reasonable level, from the From field of the INVITE used to join the conference. An even smarter mixer might ignore the RTCP SDES sent from the users entirely, and rather, generate the RTCP SDES using the identity obtained from any SIP authorization/authentication process used to verify identity when the user join the conference in the first place. Since RTP (and RTCP) can be encrypted, you can also get privacy of this data by encrypting it. This way, only conference participants know the list of people in a conference; an eavesdropper cannot determine it. So, I think you can get adequate security features. If people think this idea is not too much of a hack, I will gladly add it to the conferencing models draft. >> Any other solution to display all participants? >> How could a conference bridge signal to users who else in participating? >> > >SUBSCRIBE/NOTIFY may be an appropriate mechanism. However, nothing >prevents a participant from having others listening in, so this isn't a >foolproof mechanism. SUB/NOT could work, as we discussed in the interim meeting today. However, I still maintain that there is a lot of other things you might want here, and they are part of a broader conference control protocol, for which one component is notifications of lists of subscribers. Rather than have a SIP mechanism for SUB/NOT for the subscriber list, and a SEPARATE protocol for managing those subscribers (consider the case where I get notified that a user joined, and then I want to mute them. Its a bit harder as this operation now spans two separate protocols; there may be issues with that), I'd rather specify out a conference control protocol that does everything. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 12 00:40:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18085 for ; Mon, 12 Feb 2001 00:40:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 034C944337; Mon, 12 Feb 2001 00:40:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207]) by lists.bell-labs.com (Postfix) with ESMTP id B28C044336 for ; Mon, 12 Feb 2001 00:39:09 -0500 (EST) Received: (from siplist@localhost) by fdd.com (8.10.1/8.10.1) id f1C5d6I01751 for sip@lists.bell-labs.com; Sun, 11 Feb 2001 23:39:06 -0600 (CST) From: Rick Dean To: sip@lists.bell-labs.com Message-ID: <20010211233906.A15340@fdd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [SIP] pictures of Dallas meeting Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 11 Feb 2001 23:39:06 -0600 Here is a quick and dirty page of pictures from the Dallas SIP meeting Feb 8-9, 2001... http://fdd.com/dallasSip/ Thanks to Rohan Mahy for organizing and Dynamicsoft for hosting. -- Rick 3Com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 12 06:58:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03898 for ; Mon, 12 Feb 2001 06:58:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C80E344337; Mon, 12 Feb 2001 06:58:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 480CB44336 for ; Mon, 12 Feb 2001 06:57:23 -0500 (EST) 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 f1CBuud18905; Mon, 12 Feb 2001 12:56:56 +0100 (MET) Received: from lmf.ericsson.se (E0050DA99842B.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA18499; Mon, 12 Feb 2001 13:56:52 +0200 (EET) Message-ID: <3A87CF83.C39D3C2F@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Gonzalo Camarillo , Jonathan Rosenberg , "'Tom-PT Taylor'" Subject: Re: [SIP] Operlap dialing within a SIP network References: <21DAEE32.864ADABB@lmf.ericsson.se> Content-Type: multipart/mixed; boundary="------------8EC507096E66C53B0B2783CF" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 12 Feb 2001 13:56:51 +0200 This is a multi-part message in MIME format. --------------8EC507096E66C53B0B2783CF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry, but I still have some issues with this thread :) I mentioned it earlier, but it was never discussed. First, to comment the previous discusion, I do NOT want to "use SIP just to transport ISUP". I never even assumed that ISUP transparency was used (it has nothing to do with the ISUP-SIP draft) in the first place. For the INFO proposal I assumed a specific header could be used... However, let us leave the INFO proposal for a minute, and instead discuss the problem with the current proposal (according to the ISUP-SIP draft). So, here is one issue: Let's assume that GW B receives an INVITE, from GW A, with enough digits to route (so, no 484 will be sent back). An IAM will be generated, and the call setup will be routed to the next PSTN switch, switch C. Switch C, however, DOES need more digits to be able to route the call. Switch C, however, can not inform GW B about that, so no response, provisional or final, other than a 100 automatically generated by GW B will be sent back to GW A. Now, we can assume that GW A, when it receives more digits, will generate a new INVITE anyway, even if it didn't receive 484. So... Issue 1: Since GW B already has established a call setup for the first INVITE, and has also probably reserved PSTN resources etc for it. Issue 2: Can we now require that GW B will be smart enough to compare the digits in new INVITE with the ones in the old one, and generate the SAMs needed? Issue 3: To prevent issue 1 and 2, GW A could send a CANCEL for the previous INVITE everytime it sends a new INVITE (if a 484 hasn't been received before that). That would, however: - Generate lots of extra SIP traffic, which is not good. - Make the GW B process every new INVITE as a new call. That would make the GW B first reserve PSTN resources, then unreserve them when the CANCEL comes, reserve them again when the new INVITE comes etc etc etc. That solution doesn't sound very good either, I think... I also agree that operlap dialing will not be very widely used, but it may be used in PSTN-SIP-PSTN cases, so... Comments? Regards, Christer Holmberg Ericsson Finland Gonzalo Camarillo wrote: > > Hello, > > Jonathan Rosenberg wrote: > > > > I think the correct answer about which approach to use (INFO vs. multiple > > call legs) depends on your view of the scope of the address within the sip > > cloud. If you believe that the sip role has ended once you have enough > > digits to select an egress gateway (which may be as few as one, i.e., +1 > > selects a US gateway), then the sip address of that gateway can be viewed as > > sip:+1@provider.com, and all subsequent digits are PSTN issues, outside the > > scope of SIP. > > I definitively agree that this is the view that INFO fans have of a SIP > cloud. What I am saying is that this view is wrong. This usage of SIP > falls outside the scope of SIP. > > If they want to use SIP for locating a gateway, it is fine. But after > the gateway has been located, let's use another method for transporting > ISUP signalling. > > Let's assume that I get an IAM with "+1", as Jonathan says in his > example. Then the INVITE generated by the gateway will reach the US > gateway. Now, the mission of SIP has finished, since the gateway has > been located. Why don't we put in the body of this INVITE a session > description that comprises a media session and a SIGTRAN session? This > way we would have established these two sessions between the gateways > and all the subsequent ISUP messages would be sent over the SIGTRAN > session. > > I find that the usage of SIP that I have just described would be OK. > What I do not understand is why folks want to use SIP for transporting > subsequent ISUP messages. SIP does not have good transport properties > (big overhead, it can run over UDP...). Besides, it does not provide > ordered delivery. > > If the INVITE has Cseq=1 and the next message that the egrees gateway > receives is a INFO with Cseq=7... what should the gateway do? Maybe > there were several proxies in the middle asking for credentials for the > INFO, so the ingrees gateway had to add authentication stuff and resend > the INFO. If this was the case, the SAM contained in the INFO would be > the second digit of the called party number... However, maybe 5 INFO > messages got lost, and the SAM that we have received in the body of the > INFO makes no sense without the previous ones because is the 7th digit > of the number... > > This is not usually a problem in SIP, since all messages have full > state. However, using INFO for sending SAMs breaks this rule, and > therefore it breaks the SIP model. > > I believe that considering that the session is established after the > first INVITE and sending the following SAMs using INFO is making one of > the mistakes described in the guidelines for SIP authors: "We need to > transport ISUP signalling over IP between two gateways. Both gateways > already implement SIP... why do we have to implement another protocol? > Let's use SIP to transport ISUP signalling". We are just trying to use > SIP for this just because it would save implementing yet another > protocol in the gateways. > > I strongly disagree with this usage of SIP. SIP-T is good as long as the > SIP cloud provides services. If not, SIP-T is not a good protocol for > transporting ISUP signalling. > > Best regards, > > Gonzalo > > If you believe that the sip role encompasses functions that > > might apply to the PSTN subscribers, then you need to have the entire > > number, and the multiple call leg approach is the right way to go. > > > > The multiple call leg approach is clearly ugly and inelegant, but it has the > > nice property of completely masking the existence of overlap from proxies > > and app servers within the network, allowing them to provide services in the > > normal way. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > Sent: Thursday, February 08, 2001 7:00 AM > > To: Gonzalo Camarillo > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > You are correct about using some other means of transport if ISUP > > trans-shipment is all your network is doing. If the call destination (to a > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call > > basis, however, using SIP to establish your call routing leads to using SIP > > to carry the ISUP. > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > Hi Tom, > > > > > > Still I want to have full state in every SIP message. If the call is > > > addresed to the phone number 1234, I want to have a to field that says > > > 1234. I do not care if there is a leg routed thru the PSTN and another > > > thru SIP. > > > > > > Carrying full state is one of the beauties of SIP. If we begin using > > > INFO for this, it would be the same as using SAMs. Differen names, the > > > same thing... I do not want to re-create ISUP using SIP. I > > > believe that > > > if the session has a destination, it should be present in the > > > to field. > > > > > > Again, if a proxy is providing services for this particular call, it > > > will want to see the called party number in order to trigger > > > the proper > > > service. This is a very good reason for updating the to field > > > every time > > > we have more digits. > > > > > > I like to use SIP between two gateways because it is possible > > > to provide > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > finding a > > > egrees gateway, we would probably want to use other protocols (TRIP & > > > SIGTRAN for instance). > > > > > > Regards, > > > > > > Gonzalo > > > > > > Tom-PT Taylor wrote: > > > > > > > > Sorry, we're talking past each other. The premise of my > > > statements is > > > > that an INVITE has reached a UAS which has accepted it. It follows > > > > that the UAS did not send back a 484, but rather an interim > > > response. > > > > IF more digits come along, the INFO method is there to carry them. > > > > They do not affect the SIP call state; they are used beyond the UAS, > > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > signalling > > > > > > has reached an egress gateway, SIP has done its job -- > > > additional > > > > > > digits will not change call state. It is therefore > > > > > reasonable to use > > > > > > INFO to carry the additional digits. If we are talking > > > > > ISUP-SIP, once > > > > > > the destination UAS or a UAS in a B2BUA has been > > > reached, the same > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > vanilla SIP UA. > > > > I > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > subsequent INFO > > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > > gateway > > > > > will have to re issue a new INVITE with all the digits. > > > > > Therefore, it is > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > > > carries ISUP messages between two gateways. For that, we have > > > > already > > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > > call is a > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > state. And a > > > > > SIP message with an incomplete to field does not carry complete > > > > state. > > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > > based > > > > > on the to field (called party number). That proxy would > > > like to see > > > > an > > > > > updated to field, not just a to field that contains just some > > > > digits. > > > > > > > > > > Best regards, > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > To: Gonzalo Camarillo > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > > been proposed > > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > > reason for > > > > > > > the discussion from the beginning was that the overlap > > > > signalling, > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > very well, and > > > > > > a > > > > > > > solution using 18x responses and INFO messages, instead of 484 > > > > and > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer Holmberg > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > signalling section. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > > > about calls > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > SIP UAS > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > | <- 18x ------ | > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > | <- 18x ------ | > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > > --> > > > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > > the word 'proxy') > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > overlap dialing, to > > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > > the digits > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > > be allowed to > > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > > INVITEs, until > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > -- > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > FIN-02420 Jorvas Email : > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo --------------8EC507096E66C53B0B2783CF 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 --------------8EC507096E66C53B0B2783CF-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 12 08:02:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04876 for ; Mon, 12 Feb 2001 08:02:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 554334433A; Mon, 12 Feb 2001 08:02:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 076F844336 for ; Mon, 12 Feb 2001 08:01:22 -0500 (EST) 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 f1CD1KC06336 for ; Mon, 12 Feb 2001 14:01:20 +0100 (MET) Received: from lmf.ericsson.se ([131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA22707 for ; Mon, 12 Feb 2001 15:01:18 +0200 (EET) Message-ID: <3A87DE9D.69F6AA72@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------1334BFC743639A5AC7853E3E" Subject: [SIP] Session-timer issue with ISUP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 12 Feb 2001 15:01:17 +0200 This is a multi-part message in MIME format. --------------1334BFC743639A5AC7853E3E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I would like to clarify an issue with the session-timer - again related to SIP/PSTN interworking. The session-timer draft says: "If the refreshing re-INVITE is used solely for refreshing, it MUST still contain a session description, unchanged from the previous INVITE. The session description MUST somehow indicate that it has not changed. In the case of SDP, this is accomplished by including the same value for the origin field as previous messages to its peer." First, I assume that it is NOT allowed to send a new ISUP body in the re-INVITE (INFO MUST be used for that, since it doesn't affect the SIP part of the call). If it is allowed, I would not only have to compare the SDP body to the original INVITE, but also the ISUP body - and any other possible body... Second, if the first assumption is correct, I wonder if it is possible not to send the ISUP bodies in the re-INVITEs at all? The minus is that parts of the keep-alive mechanism provided by the session-timer dissapears, but the plus is that the refresh re-INVITE messages will be smaller (the initial INVITE message may be pretty big, if it contains both SDP and ISUP, and possible also other message body types...). I guess one has to compare the number of smaller messages compared to how many times the UAS will crash. Comments? Regards, Christer Holmberg Ericsson Finland --------------1334BFC743639A5AC7853E3E 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 --------------1334BFC743639A5AC7853E3E-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 12 09:09:17 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06801 for ; Mon, 12 Feb 2001 09:09:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 238EA44337; Mon, 12 Feb 2001 09:09:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id BACA844336 for ; Mon, 12 Feb 2001 09:08:37 -0500 (EST) 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 f1CE6Jd04863; Mon, 12 Feb 2001 15:06:19 +0100 (MET) Received: from lmf.ericsson.se ([138.85.235.236]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id PAA19500; Mon, 12 Feb 2001 15:06:10 +0100 (MET) Message-ID: <3A87EC10.6CA4C47C@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: sip@lists.bell-labs.com, Jonathan Rosenberg , "'Tom-PT Taylor'" Subject: Re: [SIP] Operlap dialing within a SIP network References: <21DAEE32.864ADABB@lmf.ericsson.se> <3A87CF83.C39D3C2F@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 12 Feb 2001 15:58:40 +0200 Content-Transfer-Encoding: 7bit Hello Christer, Comments inline: Christer Holmberg wrote: > > Sorry, but I still have some issues with this thread :) I mentioned it > earlier, but it was never discussed. > > First, to comment the previous discusion, I do NOT want to "use SIP just > to transport ISUP". I never even assumed that ISUP transparency was used > (it has nothing to do with the ISUP-SIP draft) in the first place. For > the INFO proposal I assumed a specific header could be used... > > However, let us leave the INFO proposal for a minute, and instead > discuss the problem with the current proposal (according to the ISUP-SIP > draft). > > So, here is one issue: > > Let's assume that GW B receives an INVITE, from GW A, with enough digits > to route (so, no 484 will be sent back). An IAM will be generated, and > the call setup will be routed to the next PSTN switch, switch C. Switch > C, however, DOES need more digits to be able to route the call. Switch > C, however, can not inform GW B about that, so no response, provisional > or final, other than a 100 automatically generated by GW B will be sent > back to GW A. > > Now, we can assume that GW A, when it receives more digits, will > generate a new INVITE anyway, even if it didn't receive 484. So... > Yes, so far this is correct. > Issue 1: Since GW B already has established a call setup for the first > INVITE, and has also probably reserved PSTN resources etc for it. Yes. In the normal case it has reserved a timeslot in a E1. This does not have to change, since the arrival of more digits will not require more resorces. The resources needed for the call are defined in the IAM. The SAMs just add more digits to the called number. Nothing more. > > Issue 2: Can we now require that GW B will be smart enough to compare > the digits in new INVITE with the ones in the old one, and generate the > SAMs needed? The new INVITE has the same call-ID as the first one. Thus, everything that the gateway has do to is sending a SAM with the new digits. I do not think this is a complicated operation. Just parsing a SIP message involves more complicated operations than this one. > > Issue 3: To prevent issue 1 and 2, GW A could send a CANCEL for the > previous INVITE everytime it sends a new INVITE (if a 484 hasn't been > received before that). That would, however: Besides your points, this is a bad idea because if the CANCEL arrives before the new INVITE, the result is that the egrees gateway sends a REL and then a new IAM. This is what we want to avoid. Actually this one was one of the first proposals for overlap signalling (long time ago...). Regards, Gonzalo > > - Generate lots of extra SIP traffic, which is not good. > > - Make the GW B process every new INVITE as a new call. That would make > the GW B first reserve PSTN resources, then unreserve them when the > CANCEL comes, reserve them again when the new INVITE comes etc etc etc. > That solution doesn't sound very good either, I think... > > I also agree that operlap dialing will not be very widely used, but it > may be used in PSTN-SIP-PSTN cases, so... > > Comments? > > Regards, > > Christer Holmberg > Ericsson Finland > > Gonzalo Camarillo wrote: > > > > Hello, > > > > Jonathan Rosenberg wrote: > > > > > > I think the correct answer about which approach to use (INFO vs. multiple > > > call legs) depends on your view of the scope of the address within the sip > > > cloud. If you believe that the sip role has ended once you have enough > > > digits to select an egress gateway (which may be as few as one, i.e., +1 > > > selects a US gateway), then the sip address of that gateway can be viewed as > > > sip:+1@provider.com, and all subsequent digits are PSTN issues, outside the > > > scope of SIP. > > > > I definitively agree that this is the view that INFO fans have of a SIP > > cloud. What I am saying is that this view is wrong. This usage of SIP > > falls outside the scope of SIP. > > > > If they want to use SIP for locating a gateway, it is fine. But after > > the gateway has been located, let's use another method for transporting > > ISUP signalling. > > > > Let's assume that I get an IAM with "+1", as Jonathan says in his > > example. Then the INVITE generated by the gateway will reach the US > > gateway. Now, the mission of SIP has finished, since the gateway has > > been located. Why don't we put in the body of this INVITE a session > > description that comprises a media session and a SIGTRAN session? This > > way we would have established these two sessions between the gateways > > and all the subsequent ISUP messages would be sent over the SIGTRAN > > session. > > > > I find that the usage of SIP that I have just described would be OK. > > What I do not understand is why folks want to use SIP for transporting > > subsequent ISUP messages. SIP does not have good transport properties > > (big overhead, it can run over UDP...). Besides, it does not provide > > ordered delivery. > > > > If the INVITE has Cseq=1 and the next message that the egrees gateway > > receives is a INFO with Cseq=7... what should the gateway do? Maybe > > there were several proxies in the middle asking for credentials for the > > INFO, so the ingrees gateway had to add authentication stuff and resend > > the INFO. If this was the case, the SAM contained in the INFO would be > > the second digit of the called party number... However, maybe 5 INFO > > messages got lost, and the SAM that we have received in the body of the > > INFO makes no sense without the previous ones because is the 7th digit > > of the number... > > > > This is not usually a problem in SIP, since all messages have full > > state. However, using INFO for sending SAMs breaks this rule, and > > therefore it breaks the SIP model. > > > > I believe that considering that the session is established after the > > first INVITE and sending the following SAMs using INFO is making one of > > the mistakes described in the guidelines for SIP authors: "We need to > > transport ISUP signalling over IP between two gateways. Both gateways > > already implement SIP... why do we have to implement another protocol? > > Let's use SIP to transport ISUP signalling". We are just trying to use > > SIP for this just because it would save implementing yet another > > protocol in the gateways. > > > > I strongly disagree with this usage of SIP. SIP-T is good as long as the > > SIP cloud provides services. If not, SIP-T is not a good protocol for > > transporting ISUP signalling. > > > > Best regards, > > > > Gonzalo > > > > If you believe that the sip role encompasses functions that > > > might apply to the PSTN subscribers, then you need to have the entire > > > number, and the multiple call leg approach is the right way to go. > > > > > > The multiple call leg approach is clearly ugly and inelegant, but it has the > > > nice property of completely masking the existence of overlap from proxies > > > and app servers within the network, allowing them to provide services in the > > > normal way. > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > -----Original Message----- > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > Sent: Thursday, February 08, 2001 7:00 AM > > > To: Gonzalo Camarillo > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > > > You are correct about using some other means of transport if ISUP > > > trans-shipment is all your network is doing. If the call destination (to a > > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call > > > basis, however, using SIP to establish your call routing leads to using SIP > > > to carry the ISUP. > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hi Tom, > > > > > > > > Still I want to have full state in every SIP message. If the call is > > > > addresed to the phone number 1234, I want to have a to field that says > > > > 1234. I do not care if there is a leg routed thru the PSTN and another > > > > thru SIP. > > > > > > > > Carrying full state is one of the beauties of SIP. If we begin using > > > > INFO for this, it would be the same as using SAMs. Differen names, the > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > believe that > > > > if the session has a destination, it should be present in the > > > > to field. > > > > > > > > Again, if a proxy is providing services for this particular call, it > > > > will want to see the called party number in order to trigger > > > > the proper > > > > service. This is a very good reason for updating the to field > > > > every time > > > > we have more digits. > > > > > > > > I like to use SIP between two gateways because it is possible > > > > to provide > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > finding a > > > > egrees gateway, we would probably want to use other protocols (TRIP & > > > > SIGTRAN for instance). > > > > > > > > Regards, > > > > > > > > Gonzalo > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > statements is > > > > > that an INVITE has reached a UAS which has accepted it. It follows > > > > > that the UAS did not send back a 484, but rather an interim > > > > response. > > > > > IF more digits come along, the INFO method is there to carry them. > > > > > They do not affect the SIP call state; they are used beyond the UAS, > > > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > signalling > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > additional > > > > > > > digits will not change call state. It is therefore > > > > > > reasonable to use > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > ISUP-SIP, once > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > reached, the same > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > vanilla SIP UA. > > > > > I > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > subsequent INFO > > > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > > > gateway > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > Therefore, it is > > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > > > > carries ISUP messages between two gateways. For that, we have > > > > > already > > > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > > > call is a > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > state. And a > > > > > > SIP message with an incomplete to field does not carry complete > > > > > state. > > > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > > > based > > > > > > on the to field (called party number). That proxy would > > > > like to see > > > > > an > > > > > > updated to field, not just a to field that contains just some > > > > > digits. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Christer Holmberg > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > To: Gonzalo Camarillo > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > > > been proposed > > > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > > > reason for > > > > > > > > the discussion from the beginning was that the overlap > > > > > signalling, > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > very well, and > > > > > > > a > > > > > > > > solution using 18x responses and INFO messages, instead of 484 > > > > > and > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > > > > about calls > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > SIP UAS > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > > > --> > > > > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > > > the word 'proxy') > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > overlap dialing, to > > > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > > > the digits > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > > > be allowed to > > > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > > > INVITEs, until > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 12 09:37:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07998 for ; Mon, 12 Feb 2001 09:37:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B43C944349; Mon, 12 Feb 2001 09:37:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 6B0D544344 for ; Mon, 12 Feb 2001 09:36:00 -0500 (EST) 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 f1CEWKC24269; Mon, 12 Feb 2001 15:32:20 +0100 (MET) Received: from lmf.ericsson.se ([131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA28655; Mon, 12 Feb 2001 16:32:19 +0200 (EET) Message-ID: <3A87F3F1.483492FA@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Gonzalo Camarillo , Jonathan Rosenberg , "'Tom-PT Taylor'" Subject: Re: [SIP] Operlap dialing within a SIP network References: <21DAEE32.864ADABB@lmf.ericsson.se> <3A87CF83.C39D3C2F@lmf.ericsson.se> <3A87EC10.6CA4C47C@lmf.ericsson.se> Content-Type: multipart/mixed; boundary="------------353328910799B30C27EEE5BE" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 12 Feb 2001 16:32:17 +0200 This is a multi-part message in MIME format. --------------353328910799B30C27EEE5BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hola! Gonzalo Camarillo wrote: > >Hello Christer, > >Comments inline: > >Christer Holmberg wrote: >> >>Sorry, but I still have some issues with this thread :) I mentioned it >>earlier, but it was never discussed. >> >>First, to comment the previous discusion, I do NOT want to "use SIP just >>to transport ISUP". I never even assumed that ISUP transparency was used >>(it has nothing to do with the ISUP-SIP draft) in the first place. For >>the INFO proposal I assumed a specific header could be used... >> >>However, let us leave the INFO proposal for a minute, and instead >>discuss the problem with the current proposal (according to the ISUP-SIP >>draft). >> >>So, here is one issue: >> >>Let's assume that GW B receives an INVITE, from GW A, with enough digits >>to route (so, no 484 will be sent back). An IAM will be generated, and >>the call setup will be routed to the next PSTN switch, switch C. Switch >>C, however, DOES need more digits to be able to route the call. Switch >>C, however, can not inform GW B about that, so no response, provisional >>or final, other than a 100 automatically generated by GW B will be sent >>back to GW A. >> >>Now, we can assume that GW A, when it receives more digits, will >>generate a new INVITE anyway, even if it didn't receive 484. So... >> > >Yes, so far this is correct. > >>Issue 1: Since GW B already has established a call setup for the first >>INVITE, and has also probably reserved PSTN resources etc for it. > >Yes. In the normal case it has reserved a timeslot in a E1. This does >not have to change, since the arrival of more digits will not require >more resorces. The resources needed for the call are defined in the IAM. >The SAMs just add more digits to the called number. Nothing more. > >> >>Issue 2: Can we now require that GW B will be smart enough to compare >>the digits in new INVITE with the ones in the old one, and generate the >>SAMs needed? > >The new INVITE has the same call-ID as the first one. Thus, everything >that the gateway has do to is sending a SAM with the new digits. > >I do not think this is a complicated operation. Just parsing a SIP >message involves more complicated operations than this one. It may not be complicated, but maybe it should be pointed out somewhere. However, a request may be forked, and a proxy may for some strange reason change the whole Request-URI, so that two different INVITEs for the same Call-ID is received, but I think it is an implementation issue how the GW handles those kind of situations. >>Issue 3: To prevent issue 1 and 2, GW A could send a CANCEL for the >>previous INVITE everytime it sends a new INVITE (if a 484 hasn't been >>received before that). That would, however: > >Besides your points, this is a bad idea because if the CANCEL arrives >before the new INVITE, the result is that the egrees gateway sends a REL >and then a new IAM. That is what I meant would happend, and it is not a good idea. >This is what we want to avoid. I couldn't agree more on that :) Regards, Christer Holmberg Ericsson Finland >Actually this one was one of the first proposals for overlap signalling >(long time ago...). > >Regards, > >Gonzalo > > > > > - Generate lots of extra SIP traffic, which is not good. > > > > - Make the GW B process every new INVITE as a new call. That would make > > the GW B first reserve PSTN resources, then unreserve them when the > > CANCEL comes, reserve them again when the new INVITE comes etc etc etc. > > That solution doesn't sound very good either, I think... > > > > I also agree that operlap dialing will not be very widely used, but it > > may be used in PSTN-SIP-PSTN cases, so... > > > > Comments? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Gonzalo Camarillo wrote: > > > > > > Hello, > > > > > > Jonathan Rosenberg wrote: > > > > > > > > I think the correct answer about which approach to use (INFO vs. multiple > > > > call legs) depends on your view of the scope of the address within the sip > > > > cloud. If you believe that the sip role has ended once you have enough > > > > digits to select an egress gateway (which may be as few as one, i.e., +1 > > > > selects a US gateway), then the sip address of that gateway can be viewed as > > > > sip:+1@provider.com, and all subsequent digits are PSTN issues, outside the > > > > scope of SIP. > > > > > > I definitively agree that this is the view that INFO fans have of a SIP > > > cloud. What I am saying is that this view is wrong. This usage of SIP > > > falls outside the scope of SIP. > > > > > > If they want to use SIP for locating a gateway, it is fine. But after > > > the gateway has been located, let's use another method for transporting > > > ISUP signalling. > > > > > > Let's assume that I get an IAM with "+1", as Jonathan says in his > > > example. Then the INVITE generated by the gateway will reach the US > > > gateway. Now, the mission of SIP has finished, since the gateway has > > > been located. Why don't we put in the body of this INVITE a session > > > description that comprises a media session and a SIGTRAN session? This > > > way we would have established these two sessions between the gateways > > > and all the subsequent ISUP messages would be sent over the SIGTRAN > > > session. > > > > > > I find that the usage of SIP that I have just described would be OK. > > > What I do not understand is why folks want to use SIP for transporting > > > subsequent ISUP messages. SIP does not have good transport properties > > > (big overhead, it can run over UDP...). Besides, it does not provide > > > ordered delivery. > > > > > > If the INVITE has Cseq=1 and the next message that the egrees gateway > > > receives is a INFO with Cseq=7... what should the gateway do? Maybe > > > there were several proxies in the middle asking for credentials for the > > > INFO, so the ingrees gateway had to add authentication stuff and resend > > > the INFO. If this was the case, the SAM contained in the INFO would be > > > the second digit of the called party number... However, maybe 5 INFO > > > messages got lost, and the SAM that we have received in the body of the > > > INFO makes no sense without the previous ones because is the 7th digit > > > of the number... > > > > > > This is not usually a problem in SIP, since all messages have full > > > state. However, using INFO for sending SAMs breaks this rule, and > > > therefore it breaks the SIP model. > > > > > > I believe that considering that the session is established after the > > > first INVITE and sending the following SAMs using INFO is making one of > > > the mistakes described in the guidelines for SIP authors: "We need to > > > transport ISUP signalling over IP between two gateways. Both gateways > > > already implement SIP... why do we have to implement another protocol? > > > Let's use SIP to transport ISUP signalling". We are just trying to use > > > SIP for this just because it would save implementing yet another > > > protocol in the gateways. > > > > > > I strongly disagree with this usage of SIP. SIP-T is good as long as the > > > SIP cloud provides services. If not, SIP-T is not a good protocol for > > > transporting ISUP signalling. > > > > > > Best regards, > > > > > > Gonzalo > > > > > > If you believe that the sip role encompasses functions that > > > > might apply to the PSTN subscribers, then you need to have the entire > > > > number, and the multiple call leg approach is the right way to go. > > > > > > > > The multiple call leg approach is clearly ugly and inelegant, but it has the > > > > nice property of completely masking the existence of overlap from proxies > > > > and app servers within the network, allowing them to provide services in the > > > > normal way. > > > > > > > > -Jonathan R. > > > > > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > -----Original Message----- > > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > > Sent: Thursday, February 08, 2001 7:00 AM > > > > To: Gonzalo Camarillo > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > > > > > You are correct about using some other means of transport if ISUP > > > > trans-shipment is all your network is doing. If the call destination (to a > > > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call > > > > basis, however, using SIP to establish your call routing leads to using SIP > > > > to carry the ISUP. > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > Still I want to have full state in every SIP message. If the call is > > > > > addresed to the phone number 1234, I want to have a to field that says > > > > > 1234. I do not care if there is a leg routed thru the PSTN and another > > > > > thru SIP. > > > > > > > > > > Carrying full state is one of the beauties of SIP. If we begin using > > > > > INFO for this, it would be the same as using SAMs. Differen names, the > > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > > believe that > > > > > if the session has a destination, it should be present in the > > > > > to field. > > > > > > > > > > Again, if a proxy is providing services for this particular call, it > > > > > will want to see the called party number in order to trigger > > > > > the proper > > > > > service. This is a very good reason for updating the to field > > > > > every time > > > > > we have more digits. > > > > > > > > > > I like to use SIP between two gateways because it is possible > > > > > to provide > > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > > finding a > > > > > egrees gateway, we would probably want to use other protocols (TRIP & > > > > > SIGTRAN for instance). > > > > > > > > > > Regards, > > > > > > > > > > Gonzalo > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > > statements is > > > > > > that an INVITE has reached a UAS which has accepted it. It follows > > > > > > that the UAS did not send back a 484, but rather an interim > > > > > response. > > > > > > IF more digits come along, the INFO method is there to carry them. > > > > > > They do not affect the SIP call state; they are used beyond the UAS, > > > > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > > signalling > > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > > additional > > > > > > > > digits will not change call state. It is therefore > > > > > > > reasonable to use > > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > > ISUP-SIP, once > > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > > reached, the same > > > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > > vanilla SIP UA. > > > > > > I > > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > > subsequent INFO > > > > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > > > > gateway > > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > > Therefore, it is > > > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > > > > > carries ISUP messages between two gateways. For that, we have > > > > > > already > > > > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > > > > call is a > > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > > state. And a > > > > > > > SIP message with an incomplete to field does not carry complete > > > > > > state. > > > > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > > > > based > > > > > > > on the to field (called party number). That proxy would > > > > > like to see > > > > > > an > > > > > > > updated to field, not just a to field that contains just some > > > > > > digits. > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Christer Holmberg > > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > > To: Gonzalo Camarillo > > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > > > > been proposed > > > > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > > > > reason for > > > > > > > > > the discussion from the beginning was that the overlap > > > > > > signalling, > > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > > very well, and > > > > > > > > a > > > > > > > > > solution using 18x responses and INFO messages, instead of 484 > > > > > > and > > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > > > > > about calls > > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > > SIP UAS > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > > > > --> > > > > > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > > > > the word 'proxy') > > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > > overlap dialing, to > > > > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > > > > the digits > > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > > > > be allowed to > > > > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > > > > INVITEs, until > > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo --------------353328910799B30C27EEE5BE 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 --------------353328910799B30C27EEE5BE-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 12 10:56:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12218 for ; Mon, 12 Feb 2001 10:56:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0944944339; Mon, 12 Feb 2001 10:56:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 92CF944336; Mon, 12 Feb 2001 07:22:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04149; Mon, 12 Feb 2001 07:21:51 -0500 (EST) Message-Id: <200102121221.HAA04149@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com, iptel@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-yu-tel-url-02.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 12 Feb 2001 07:21:51 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to the 'tel' and 'fax' URLs to Support Number Portability and Freephone Service Author(s) : J. Yu Filename : draft-yu-tel-url-02.txt Pages : 12 Date : 09-Feb-01 This document proposes some extensions to the 'tel' and 'fax' Uniform Resource Locators (URLs) for supporting number portability (NP) and freephone service. Those proposed extensions allow the Session Initiation Protocol (SIP) to carry those URLs or to convert those URLs to the SIP URL so as to support NP and freephone service. The proposed extensions allow the SIP protocol to be used to derive the routing number for the ported geographical numbers, identify the freephone service provider/carrier or the Plain Old Telephone Service (POTS) number for a freephone number, and carry the NP- and freephone-related information in the SIP messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-yu-tel-url-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-yu-tel-url-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-yu-tel-url-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: <20010209142915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-yu-tel-url-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-yu-tel-url-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010209142915.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 12 13:32:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17623 for ; Mon, 12 Feb 2001 13:32:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3537744338; Mon, 12 Feb 2001 13:32:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4]) by lists.bell-labs.com (Postfix) with SMTP id 817C644338 for ; Mon, 12 Feb 2001 13:31:54 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Mon, 12 Feb 2001 10:31:04 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id <1SFW4P7Z>; Mon, 12 Feb 2001 10:31:04 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD32EA9C@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "Jonathan Rosenberg" Cc: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1696F46232732-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Subject: [SIP] Question regarding CSEQ processing with PRACK... Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 12 Feb 2001 10:30:57 -0800 Content-Transfer-Encoding: 7bit All: I needed some clarification on the usage of CSEQ with PRACK's. The draft says that the CSEQ number in PRACK MUST be higher than the last transaction CSEQ number (INVITE or otherwise). So, for example, say, an UAC sends out an INVITE with CSEQ 1, it receives a 180 ringing, it issues a PRACK with CSEQ 2. The question I had is should these CSEQ's be preserved after the INVITE transaction has ended? Meaning, in the above example, say the PRACK, generates a 200 OK by the UAS for the same, followed by an ACK for the INVITE(when the called party answers), the UAC issues an ACK with CSEQ 1 INVITE to complete the 3 way handshake. At a later point of time, say, the user hungup, which causes the UAC to issue a BYE, should the CSEQ field be constructed with a sequence number, higher than the last PRACK it sent out(or received in case of far end disconnects) or the last INVITE it sent out(or received)? Please elaborate. Thanks. Venkatesh _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 12 14:05:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18690 for ; Mon, 12 Feb 2001 14:05:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BF04644338; Mon, 12 Feb 2001 14:05:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchatl1.edgeconnect.com (smtp.EDGECONNECT.com [63.99.99.17]) by lists.bell-labs.com (Postfix) with ESMTP id B3B6344337 for ; Mon, 12 Feb 2001 14:04:13 -0500 (EST) Received: from DDCW6701 (63.113.183.106 [63.113.183.106]) by exchatl1.edgeconnect.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1TVYRNBX; Mon, 12 Feb 2001 13:55:59 -0500 From: "Victor A Paulsamy" To: "SIP" Cc: "Victor A Paulsamy" 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 Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 12 Feb 2001 14:05:38 -0500 Content-Transfer-Encoding: 7bit Hi, I'm having difficulty in understanding the following from RFC2327, SDP. "When a list of payload formats is given, this implies that all of these formats may be used in the session, but the first of these formats is the default format for the session." -- SDP Standards Track, page 20. What does default mean here? When a m-line reads as "m=audio 49230 RTP/AVP 3 4 5", does this mean that the remote UA will be requested to use GSM (PT 3) if it could support it and if it didn't support GSM, the local UA will negotiate for G723 (PT 4) with the remote UA and so on? (It's clear that I need to understand the above phrase!). Thanks for your help and valuable time. Regards, --victor _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 12 14:08:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18794 for ; Mon, 12 Feb 2001 14:08:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 663D744355; Mon, 12 Feb 2001 14:08:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchatl1.edgeconnect.com (smtp.EDGECONNECT.com [63.99.99.17]) by lists.bell-labs.com (Postfix) with ESMTP id AB12244352 for ; Mon, 12 Feb 2001 14:07:44 -0500 (EST) Received: from voicecore.com (63.113.183.106 [63.113.183.106]) by exchatl1.edgeconnect.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1TVYRNB6; Mon, 12 Feb 2001 13:59:40 -0500 Message-ID: <3A883462.2D509875@voicecore.com> From: Samir Chatterjee X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Lynch Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Video Conferencing? References: <91D91D8F61FAD31191C900508B8BA0B80F5A07@dennis.surfcast.internal> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 12 Feb 2001 14:07:14 -0500 Content-Transfer-Encoding: 7bit We are looking into collaboration technologies including video and the use of SIP. I think SIP does not have to do much for handling video-conferencing since SDP negotiation can simply have an added line describing the proper codec to be used at either side. Then it goes to the actual media handler where ports have to be opened and video to be handled. But there are some other interesting issues that come up. * In video-conferencing, I think there is no gateway involved. Because the other end is most likely a IP host unlike VoIP where the terminating end could be a dumb telephone. But could the other end be a TV set on a regular HFC cable network that is not transporting IP over its reverse channels? Then the Headend becomes a true gateway...opens up whole lot of issues. * While 3-way calling and multi-party calling in voice has been handled, I think the same analogies in the video-conferencing world have to be better understood. What does it mean to bring another video source in to the (multicast) session that is going on? Can a simple MCU handle all these video mixing? * QOS and bandwidth issues are probably stringent for video-conferencing. * To promote SIP towards broader acceptance, everyone is trying to push for new capabilities it brings to the table eg., web/telephony integration etc. I really like the idea of thinking beyond current telephone handsets and services we know of coming from the SS7 world. What about video services? We have seen so far regular TV broadcast, pay-per-view, on-demand video and some limited conferencing. Can anyone identify interesting video services along the same lines as we have done in the voice services world (which again unfortunately many people do not use)? * I think voice calls and pricing per minute have come up many times. Rate arbitrage is an initial driver but not sustainable long term. What is the pricing analogy for video services? Samir -- *************************************************************** Dr. Samir Chatterjee Chairman, Co-founder & CTO VoiceCore Technologies Inc. Ph: 770-246-9973 | Fax:770-326-9922 email: schatterjee@voicecore.com http://www.voicecore.com (Also) Associate Professor Computer Information Systems Department J Mack Robinson College of Business Georgia State University Atlanta, GA 30303. Ph: 404-651-3886 **************************************************************** Mark Lynch wrote: > Hi, > > I've been working with H323 for a while now but lately have been reading > alot about SIP and must say I'm very impressed with it's simplicity and > power. The only question I have is reagarding it's video conferencing > capabilities. I've been led to believe it's a long way off ? I thought it > was as simple as establishing an RTP channel and agreeing a codec. > > Could someone please tell me I'm wrong and point me to an example of Video > conferecing via SIP? I can' t seem to find any. > > If I'm right could anyone clarify what is happening in relation to this. > > Regards, > Mark _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 12 22:08:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26901 for ; Mon, 12 Feb 2001 22:08:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C20554433A; Mon, 12 Feb 2001 22:08:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web12604.mail.yahoo.com (web12604.mail.yahoo.com [216.136.173.227]) by lists.bell-labs.com (Postfix) with SMTP id 8157844337 for ; Mon, 12 Feb 2001 22:07:27 -0500 (EST) Message-ID: <20010213030727.95648.qmail@web12604.mail.yahoo.com> Received: from [137.132.3.7] by web12604.mail.yahoo.com; Tue, 13 Feb 2001 11:07:27 CST From: =?iso-8859-1?q?Nirmalya=20Ghosh?= To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] Question on Missing Content Length field Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 11:07:27 +0800 (CST) Content-Transfer-Encoding: 8bit Hi, I've been trying to find the answer in the RFC (2543) and also in past queries posted on this mailing list - but couldn't quite get a clear answer. What I wish to find out is what does a proxy server do, if it receives a request with a missing "Content-Length" field? Section 6.15 (pg.51) says that, "if a server receives a UDP request without Content-Length, it MUST assume that the request encompasses the remainder of the packet"; Whereas, Section 7.4.12 (pg.79) says that, "The server refuses to accept the request without a defined Content-Length" So, does this imply that if this field is missing in an incoming request, the server returns a 411 (Length Required) response? Or, does it just assume to have no body and process the request? Thanks in advance. Regards, nirmalya __________________________________________________ Do You Yahoo!? Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.com.sg/ _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 03:22:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14223 for ; Tue, 13 Feb 2001 03:22:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6E1F64433A; Tue, 13 Feb 2001 03:22:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id D0A1D44337 for ; Tue, 13 Feb 2001 03:21:57 -0500 (EST) Received: from Hash (195.238.204.177 [195.238.204.177]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 15PHARHG; Tue, 13 Feb 2001 09:16:19 +0100 From: "Hisham Khartabil" To: "Jonathan Rosenberg" , "Neil Deason" Cc: "Robert Sparks" , Subject: RE: [SIP] Removing 409 to conflicting action params 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: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 10:22:23 +0200 Content-Transfer-Encoding: 7bit The example Jonathan gives is for contacts for the same type of request. As Robert said, if I want my MESSAGEs to go to a different place than my INVITEs, it should be allowed. So, I propose (4 examples below): REGISTER sip:registrarserver.com SIP/2.0 ... contact: sip:me@machineA.hotsip.com;action=proxy;method=MESSAGE contact: sip:me@machineBhotsip.com;action=redirect;method=MESSAGE Illegal. REGISTER sip:registrarserver.com SIP/2.0 ... contact: sip:me@machineA.hotsip.com;action=proxy;method=MESSAGE contact: sip:me@machineBhotsip.com;action=redirect;method=INVITE Legal. REGISTER sip:registrarserver.com SIP/2.0 ... contact: sip:me@machineA.hotsip.com;action=proxy contact: sip:me@machineBhotsip.com;action=redirect Illegal REGISTER sip:registrarserver.com SIP/2.0 ... contact: sip:me@machineA.hotsip.com;action=proxy contact: sip:me@machineBhotsip.com;action=redirect;method=MESSAGE Not sure about this one. Maybe illegal. I propose this to be in the user preferences and not the base sip. Regards, Hisham Khartabil Hotsip Finland www.hotsip.com -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg Sent: Saturday, 10 February 2001 7:41 AM To: Neil Deason; Jonathan Rosenberg Cc: Robert Sparks; sip@lists.bell-labs.com Subject: RE: [SIP] Removing 409 to conflicting action params > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Friday, February 09, 2001 8:35 AM > To: Jonathan Rosenberg > Cc: Robert Sparks; sip@lists.bell-labs.com > Subject: Re: [SIP] Removing 409 to conflicting action params > > > Jonathan Rosenberg wrote: > > > > The reason it was there is that if the proxy DOES want to > follow it, it > > becomes meaningless to have some URLS with redirect, and > some with proxy. > > What does the proxy do? > > I am not asking that Proxy/Registrars be forbidden from > responding > 409 just that they be free to choose not to. Presently a > registrar > MUST respond 409 to conflicting action params. I don't want to > be forced to respond 409 when somebody has their mailto URL > registered > with an redirect action and then wants to add a SIP URL which > they want requests proxied to. It is not that simple. If you allow proxies to accept these kinds of things, that means you allow clients to send them. Once you do that, you must define concrete processing rules associated with registrations of this type. Otherwise, a UA now has no way of knowing the processing a proxy will apply to a set of registered Contacts, or worse, what the behavior they're requesting actually is. As an example, a UA believes it wants a service whereby the proxy server forwards the request to A, and if it fails, redirects to B. So, it registers a contact URL with proxy action as high q value, and a separate contact as redirect action as a lower proxy. It assumes that a proxy server will do this service as a result. THe proxy might accept this, and provide this interpretation, or it might accept it, and provide a different interpretation, or it might reject it. If it rejects it, what does the client do then? Must it alert the user to redefine the parameters? I wouldn't want to handle this customer service call. However, as defined now, the meaning of a set of registered contacts is CLEAR. If you want more complex behaviors, you send a CPL (and indeed, the above service is readily representable in a clear and unambigous way using CPL). By removing this restriction, and as a consequence, allowing clients to send all kinds of weird stuff, the end result will not be what users expect. -Jonathan R. > > > Does it mean to redirect if the highest q value URL > > has an action of redirect, even though others say proxy? > What if the q > > values are the same, or none were specified? We came to the > conclusion that > > it could mean any number of more complex behaviors, most of > which were more > > appropriately specified via a CPL than action params. > > > > So, I would like to keep this restriction. > > This is a fair point but we could define how a server > should respond to mixed action params wrt q values if that > is perceived to be an issue. I think that generally CPL will be > available to provide this sort of control where it is really > needed and so the whole existence of an action param is fairly > unintersting. If present can't it just be treated more as a hint. > A SIP server could then choose to try and follow them, use it's > own configuration policy or follow alternative user defined > processing logic (CPL etc). This gives more flexibility than > mandating 409s. > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 03:28:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14265 for ; Tue, 13 Feb 2001 03:28:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2AC6A4435C; Tue, 13 Feb 2001 03:28:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 2E7384435B for ; Tue, 13 Feb 2001 03:27:47 -0500 (EST) Received: from Hash (195.238.204.177 [195.238.204.177]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 15PHARH6; Tue, 13 Feb 2001 09:22:09 +0100 From: "Hisham Khartabil" To: "Nirmalya Ghosh" , Subject: RE: [SIP] Question on Missing Content Length field Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-reply-to: <20010213030727.95648.qmail@web12604.mail.yahoo.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 10:28:12 +0200 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Nirmalya Ghosh > Sent: Tuesday, 13 February 2001 5:07 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Question on Missing Content Length field > > > Hi, > I've been trying to find the answer in the RFC (2543) and also in > past queries posted on > this mailing list - but couldn't quite get a clear answer. What I > wish to find out is > what does a proxy server do, if it receives a request with a > missing "Content-Length" > field? > > Section 6.15 (pg.51) says that, "if a server receives a UDP > request without > Content-Length, it MUST assume that the request encompasses the > remainder of the packet"; I think this was during the days when you were allowed more than one SIP message in a UDP datagram. > > Whereas, Section 7.4.12 (pg.79) says that, "The server refuses to > accept the request > without a defined Content-Length" well, i think this is an implementation issue. We just make the assumption that the rest of the packet is the body and try and parse that. > > So, does this imply that if this field is missing in an incoming > request, the server > returns a 411 (Length Required) response? Or, does it just assume > to have no body and > process the request? > > Thanks in advance. > > Regards, > nirmalya > > __________________________________________________ > Do You Yahoo!? > Yahoo! Mail – Free email you can access from anywhere! > http://mail.yahoo.com.sg/ > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. Regards, Hisham Khartabil Hotsip Finland www.hotsip.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 04:35:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14585 for ; Tue, 13 Feb 2001 04:35:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2245644342; Tue, 13 Feb 2001 04:35:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 6BE6B44337 for ; Tue, 13 Feb 2001 04:34:33 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 13 Feb 2001 09:34:33 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA22703; Tue, 13 Feb 2001 09:33:19 GMT Message-ID: <3A88FF5F.75DD7044@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Robert Sparks , sip@lists.bell-labs.com Subject: Re: [SIP] Removing 409 to conflicting action params References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 09:33:19 +0000 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > -----Original Message----- > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > Sent: Friday, February 09, 2001 8:35 AM > > To: Jonathan Rosenberg > > Cc: Robert Sparks; sip@lists.bell-labs.com > > Subject: Re: [SIP] Removing 409 to conflicting action params > > > > Jonathan Rosenberg wrote: > > > > > > The reason it was there is that if the proxy DOES want to > > follow it, it > > > becomes meaningless to have some URLS with redirect, and > > some with proxy. > > > What does the proxy do? > > > > I am not asking that Proxy/Registrars be forbidden from > > responding > > 409 just that they be free to choose not to. Presently a > > registrar > > MUST respond 409 to conflicting action params. I don't want to > > be forced to respond 409 when somebody has their mailto URL > > registered > > with an redirect action and then wants to add a SIP URL which > > they want requests proxied to. > > It is not that simple. If you allow proxies to accept these kinds of things, > that means you allow clients to send them. Once you do that, you must define > concrete processing rules associated with registrations of this type. > Otherwise, a UA now has no way of knowing the > processing a proxy will apply to a set of registered Contacts, or worse, > what the > behavior they're requesting actually is. > > As an example, a UA believes it wants a service whereby the proxy server > forwards the request to A, and if it fails, redirects to B. So, it registers > a contact URL with proxy action as high q value, and a separate contact as > redirect action as a lower proxy. It assumes that a proxy server will do > this service as a result. THe proxy might accept this, and provide this > interpretation, or it might accept it, and provide a different > interpretation, or it might reject it. If it rejects it, what does the > client do then? Must it alert the user to redefine the parameters? I > wouldn't want to handle this customer service call. > > However, as defined now, the meaning of a set of registered contacts is > CLEAR. If you want more complex behaviors, you send a CPL (and indeed, the > above service is readily representable in a clear and unambigous way using > CPL). By removing this restriction, and as a consequence, allowing clients > to send all kinds of weird stuff, the end result will not be what users > expect. I think this example is slightly bogus as we both agree this should and will be done by CPL. If anything this example shows how redundant action params are. As things stand both contacts must have been registered with the same action param, either proxy or redirect, and then one of them overridden by CPL. The point isn't to promote action params + q params as an alternative to CPL etc it is more about moving towards deprecating action params. What users really care about is that requests reach them. Whether they do so via an intermediate server redirecting or proxying is of considerably less interest. So removing a servers compulsion to 409 contacts with a mixture of actions is ihmo user friendly. I would also argue that there is little clarity in the status quo as presently the only thing specified is that you cannot have a mix of action params. You could register all your contacts with an action of proxy but a server's local config cause it to redirect. Note q params don't come into things as they are already ignored in the basic case. To better define things we could say is something like ... Clients MAY use the action parameter within registrations as a hint to a server as to how requests to their contacts be handled. Users that want to control a servers action when routing requests sent to them should use CPL or SIP-CGI. Servers not wishing to accept registrations with differing action parameters MAY reject them with a status of 409. We could go further defining how servers handle mixed action params if it really bothers people. I think it is a bit of a non issue - like whether the de facto local server policy is redirect or proxy. I just want requests to find me, for greater control I use CPL. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 04:36:35 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14596 for ; Tue, 13 Feb 2001 04:36:34 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 884C744362; Tue, 13 Feb 2001 04:35:20 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id C6BD444337 for ; Tue, 13 Feb 2001 04:34:48 -0500 (EST) 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 f1D9YlC16416 for ; Tue, 13 Feb 2001 10:34:47 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA13998 for ; Tue, 13 Feb 2001 11:34:46 +0200 (EET) Message-ID: <3A88FFB4.9F52503D@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs References: Content-Type: multipart/mixed; boundary="------------46CCEB4052E3549293BC45C2" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 11:34:44 +0200 This is a multi-part message in MIME format. --------------46CCEB4052E3549293BC45C2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Not to forget the cases where we encapsulate everything in morse code and smoke signals - after all, SIP is newer than those methods, so... :) Christer Holmberg Ericsson Finlande Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Sent: Friday, February 02, 2001 9:28 AM > > To: 'Jon.Peterson@Level3.com'; chsharp@cisco.com > > Cc: sip@lists.bell-labs.com > > Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs > > > > > > > And is it just me, or is the idea that BICC will be > > > encapsulated in SIP > > > somewhat counterintuitive? Are there any services today that > > > require that? > > > Anyway, if there is interest I'd be inclined to say that BICC > > > should have > > > it's own MIME type which should be discussed on its own merits. > > > > So, SIP-T is used for, among other things, ISUP-SIP-ISUP. > > You don't think anyone wants to do BICC-SIP-BICC when SIP is > > one operator's > > network, and the BICCs are two other operators? > > > > I also see BICC-SIP-ISUP and of course ISUP-BICC-SIP-ISUP and > > variations. > > Seems prejudicial in favor of SIP catering to BICC. If we do this, what > about: > > SIP-BICC-SIP > > I think we should request the BICC guys to be able to encapsulate SIP > messages. After all, what about service transparency across my SIP network! > All these operators that are deploying SIP are doing so, in part, because of > the service possibilities. Shall I be forced to lose those capabilities when > I traverse an IP based BICC network? Why do the BICC guys get to keep their > services, and the SIP guys don't? After all, BICC is even newer than SIP. > > Of course, once we do that, the more fun case is: > > ISUP-SIP-BICC-SIP-ISUP > > in which case the encapsulated SIP messages themselves contain ISUP > messages, both of which are encapsulated in BICC. > > Of course, we should probably also consider the case of: > > SIP-ISUP-SIP > > Think about it; a SIP phone calls a PSTN number. It goes to an ss7 gateway. > Turns out, that this number is then forwarded to another number, and that > number is a VoIP terminal. So, it exits at another gateway, and hits the > terminal. I suppose we should also request the ISUP guys to encapsulate SIP > messages. > > Now then, we should also probably consider the case of: > > SIP-BICC-SIP-ISUP-SIP-BICC > > -Jonathan R. > "reducio ad absurdum" > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. --------------46CCEB4052E3549293BC45C2 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 --------------46CCEB4052E3549293BC45C2-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 04:49:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14777 for ; Tue, 13 Feb 2001 04:49:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B8F044369; Tue, 13 Feb 2001 04:49:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dns1.catt.ac.cn (unknown [202.106.106.98]) by lists.bell-labs.com (Postfix) with ESMTP id 9A58F44369 for ; Tue, 13 Feb 2001 04:44:50 -0500 (EST) Received: from liangxg (202.106.106.126 [202.106.106.126]) by dns1.catt.ac.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1LD941LY; Tue, 13 Feb 2001 17:38:21 +0800 Message-ID: <002301c095a1$6b3a25a0$75ce12ac@MCSD.local> From: "Xingang Liang" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C095E4.76477310" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Any material for SIP study? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 17:43:23 +0800 This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C095E4.76477310 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgZXZlcnkgb25lLEkgYW0ganVzdCBmb2N1c2luZyBvbiBTSVAgaW4gM0dQUCBub3csYnV0IEkg ZG9uJ3Qga25vdyBhYm91dCBpdCxJIHdvbmRlciBpZiBhbnlvbmUgY2FuIGRpcmVjdCBtZSBzb21l IG1hdGVyaWFscyBvciByZWZlcmVuY2UgYWJvdXQgU0lQLHNvIHRoYXQgSSBjYW4gbGVhcm4gaXQg cXVpY2tseSENCkkgd2lsbCB0aGFuayBldmVyeSBvbmUgaGVyZSBmaXJzdCx0aGFuayB5b3UhISEN Cg0KQW55IGFkdmljZSBpcyB3ZWxjb21lISEhIQ0KDQpCZXN0IFJlZ2FyZHMNClhpbmdhbmcgTGlh bmcNClN0YW5kYXJkaXphdGlvbiBEZXBhcnRtZW50DQpNb2JpbGUgQ29tbXVuaWNhdGlvbiBSJkQg Q2VudGVyDQpDaGluYSBBY2FkZW15IG9mIFRlbGVjb21tdW5pY2F0aW9uIFRlY2hub2xvZ3koQ0FU VCkNCk5vLjQwLFh1ZXl1YW4gUm9hZA0KQmVpamluZyxDaGluYQ0KMTAwMDgzDQpUZWw6Kzg2MTAg NjIzMDQ0MjJFWFQyMjUNCkZheDorODYxMCA2MjMwMzEyNw0KTWFpbHRvOmxpYW5neGdAY2F0dC5h Yy5jbg0KIA0KIA0K ------=_NextPart_000_0020_01C095E4.76477310 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PEJBU0UgDQpocmVmPSJmaWxlOi8vQzpcUHJv Z3JhbSBGaWxlc1xDb21tb24gRmlsZXNcTWljcm9zb2Z0IFNoYXJlZFxTdGF0aW9uZXJ5XCI+DQo8 U1RZTEU+Qk9EWSB7DQoJQkFDS0dST1VORC1QT1NJVElPTjogbGVmdCB0b3A7IEJBQ0tHUk9VTkQt UkVQRUFUOiBuby1yZXBlYXQ7IENPTE9SOiAjMDAwMDAwOyBGT05ULUZBTUlMWTogQ291cmllciBO ZXcgQ0U7IEZPTlQtU0laRTogMTBwdDsgTUFSR0lOLUxFRlQ6IDI1cHg7IE1BUkdJTi1UT1A6IDI1 cHgNCn0NCjwvU1RZTEU+DQoNCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjAwLjMxMDMuMTAwMCIg bmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj5IaSBl dmVyeSBvbmUsSSBhbSBqdXN0IGZvY3VzaW5nIG9uIFNJUCZuYnNwO2luIDNHUFAgbm93LGJ1dCBJ IGRvbid0IGtub3cgDQphYm91dCBpdCxJIHdvbmRlciBpZiBhbnlvbmUgY2FuIGRpcmVjdCBtZSBz b21lIG1hdGVyaWFscyBvciByZWZlcmVuY2UgYWJvdXQgDQpTSVAsc28gdGhhdCBJIGNhbiZuYnNw O2xlYXJuIGl0IHF1aWNrbHkhPC9ESVY+DQo8RElWPkkgd2lsbCB0aGFuayBldmVyeSBvbmUgaGVy ZSBmaXJzdCx0aGFuayB5b3UhISE8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkFueSBh ZHZpY2UgaXMgd2VsY29tZSEhISE8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkJlc3Qg UmVnYXJkczwvRElWPg0KPERJVj5YaW5nYW5nIExpYW5nPEJSPlN0YW5kYXJkaXphdGlvbiBEZXBh cnRtZW50PEJSPk1vYmlsZSBDb21tdW5pY2F0aW9uIFImYW1wO0QgDQpDZW50ZXI8QlI+Q2hpbmEg QWNhZGVteSBvZiBUZWxlY29tbXVuaWNhdGlvbiBUZWNobm9sb2d5KENBVFQpPEJSPk5vLjQwLFh1 ZXl1YW4gDQpSb2FkPEJSPkJlaWppbmcsQ2hpbmE8QlI+MTAwMDgzPEJSPlRlbDorODYxMCA2MjMw NDQyMkVYVDIyNTxCUj5GYXg6Kzg2MTAgDQo2MjMwMzEyNzxCUj48QSANCmhyZWY9Im1haWx0bzps aWFuZ3hnQGNhdHQuYWMuY24iPk1haWx0bzpsaWFuZ3hnQGNhdHQuYWMuY248L0E+PEJSPiZuYnNw OzxCUj4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0020_01C095E4.76477310-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 07:55:17 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16544 for ; Tue, 13 Feb 2001 07:55:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6197F44337; Tue, 13 Feb 2001 07:55:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id C2C5244336 for ; Tue, 13 Feb 2001 07:54:13 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 13 Feb 2001 12:54:13 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id MAA12086; Tue, 13 Feb 2001 12:52:50 GMT Message-ID: <3A892E24.FCF5776@ubiquity.net> From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hisham Khartabil Cc: Jonathan Rosenberg , Neil Deason , Robert Sparks , sip@lists.bell-labs.com Subject: Re: [SIP] Removing 409 to conflicting action params References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 12:52:52 +0000 Content-Transfer-Encoding: 7bit Hisham Khartabil wrote: > The example Jonathan gives is for contacts for the same type of request. As > Robert said, if I want my MESSAGEs to go to a different place than my > INVITEs, it should be allowed. > > So, I propose (4 examples below): > > REGISTER sip:registrarserver.com SIP/2.0 > ... > contact: sip:me@machineA.hotsip.com;action=proxy;method=MESSAGE > contact: sip:me@machineBhotsip.com;action=redirect;method=MESSAGE > > Illegal. And wrong you should be using the "methods" parameter not "method" throughout but that isn't my main point. > > > REGISTER sip:registrarserver.com SIP/2.0 > ... > contact: sip:me@machineA.hotsip.com;action=proxy;method=MESSAGE > contact: sip:me@machineBhotsip.com;action=redirect;method=INVITE > > Legal. > > REGISTER sip:registrarserver.com SIP/2.0 > ... > contact: sip:me@machineA.hotsip.com;action=proxy > contact: sip:me@machineBhotsip.com;action=redirect > > Illegal > > REGISTER sip:registrarserver.com SIP/2.0 > ... > contact: sip:me@machineA.hotsip.com;action=proxy > contact: sip:me@machineBhotsip.com;action=redirect;method=MESSAGE > > Not sure about this one. Maybe illegal. > > I propose this to be in the user preferences and not the base sip. This is the worst of both worlds and inconsistent, and as caller preferences aren't in the base spec, this can't be in the base spec. The best option I believe is to change the MUST to a MAY. The q parameter also has no use in the base spec (section 4.2.6.3) and so can't really be used in arguments for mandating 409s for conflicting actions in the base spec. James Undery _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 10:00:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20781 for ; Tue, 13 Feb 2001 10:00:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB59344341; Tue, 13 Feb 2001 10:00:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 3C04B44336 for ; Tue, 13 Feb 2001 07:01:09 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15663; Tue, 13 Feb 2001 07:01:09 -0500 (EST) Message-Id: <200102131201.HAA15663@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-ietf-sip-serverfeatures-03.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 07:01:08 -0500 --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-03.txt Pages : 7 Date : 12-Feb-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-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-serverfeatures-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-serverfeatures-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010212125314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-serverfeatures-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-serverfeatures-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010212125314.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 11:46:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23689 for ; Tue, 13 Feb 2001 11:46:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFB5844340; Tue, 13 Feb 2001 11:46:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id 8E14D44337 for ; Tue, 13 Feb 2001 11:44:45 -0500 (EST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Tue, 13 Feb 2001 16:20:49 +0000 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2650.21) id <16WQAWTT>; Tue, 13 Feb 2001 16:20:47 -0000 Message-ID: From: "Mark Watson" To: "'Gonzalo Camarillo'" , "Mark Watson" Cc: "Tom-PT Taylor" , Christer Holmberg , sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C095C5.3C33D660" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 13:59:51 -0000 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_01C095C5.3C33D660 Content-Type: text/plain; charset="iso-8859-1" Gonzalo, I'm not sure were completely understanding each other here. I think we do agree that there is value in the SIP-T concept, so that the PSTN can interwork with services provided in the 'pure SIP' network by SIP proxy servers. I think that the path we're on of including ISUP messages inside SIP messages is as good as any other for this, so I don't see any value in pursuing alternatives, such as setting up a SIGTRAN session for the ISUP signalling. I do not see the problem, though, with allowing PSTN gateways to switch to a more efficient mode of overlap signalling once the gateway out of the SIP network has been identified. Sure, whilst the call is still progressing through the SIP network, and we want to make use of the routing capabilities in the SIP network, we use normal SIP procedures, but once we have hit the PSTN gateway, why not optimise things ? > > 2) The UAC must use source routing to ensure that all these INVITES > > make it to the same UAS > > What is the problem here? This is done in order to address the problem > of proxies performing load balancing. Some folks have pointed out that > maybe the betwork wants to route the second INVITE in a > different way... > why the network would like to do that? The policy that is > applicable to > the fist INVITE (that contained a prefix of the number) should be the > same that applies to the subsequent ones. Why ? How can you possibly know that all services in all networks will work this way ? There are a host of reasons why routing of the INVITE might vary due to factors other than the digits. INVITES for the *same digits* might route differently, and not just due to load balancing. > > The price we pay for this is that intermediate proxies may not have > > access to the full Called Party Number - but a proxy that > needs this, > > that wants to offer service on overlap calls, can always sniff the > > overlap digits as they go past. > > Let me get this straight. Are you are proposing to change the logic in > all the already existing proxies because you want to provide services > when you use INFO for carrying SAMs? This is just impossible. > All proxies which want to provide services: a) which operate *after* the INVITE has been routed and the terminating point in the SIP network found, b) which require access to the full PSTN number, c) on PSTN -> SIP-T -> PSTN calls, d) which are delivered on overlap calls, and e) which do not know the dial-plan well enough to identity end-of-dialling themselves. I think right now this is the empty set, so, yes, I can upgrade all these :-) Regards, Mark Watson Nortel Networks > I still prefer a mechanism that do not require changes in the existing > proxies (multiple call-legs). > > Best regards, > > Gonzalo > > > > > Regards, > > > > Mark Watson > > Nortel Networks > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: 07 February 2001 02:52 > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > Hi Tom, > > > > > > Still I want to have full state in every SIP message. If > the call is > > > > > addresed to the phone number 1234, I want to have a to field that > > says > > > 1234. I do not care if there is a leg routed thru the PSTN and > > another > > > thru SIP. > > > > > > Carrying full state is one of the beauties of SIP. If we > begin using > > > > > INFO for this, it would be the same as using SAMs. Differen names, > > the > > > same thing... I do not want to re-create ISUP using SIP. I > > > believe that > > > if the session has a destination, it should be present in the > > > to field. > > > > > > Again, if a proxy is providing services for this > particular call, it > > > > > will want to see the called party number in order to trigger > > > the proper > > > service. This is a very good reason for updating the to field > > > every time > > > we have more digits. > > > > > > I like to use SIP between two gateways because it is possible > > > to provide > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > finding a > > > egrees gateway, we would probably want to use other > protocols (TRIP > > & > > > SIGTRAN for instance). > > > > > > Regards, > > > > > > Gonzalo > > > > > > Tom-PT Taylor wrote: > > > > > > > > Sorry, we're talking past each other. The premise of my > > > statements is > > > > that an INVITE has reached a UAS which has accepted it. It > > follows > > > > that the UAS did not send back a 484, but rather an interim > > > response. > > > > IF more digits come along, the INFO method is there to > carry them. > > > > > > They do not affect the SIP call state; they are used beyond the > > UAS, > > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > signalling > > > > > > has reached an egress gateway, SIP has done its job -- > > > additional > > > > > > digits will not change call state. It is therefore > > > > > reasonable to use > > > > > > INFO to carry the additional digits. If we are talking > > > > > ISUP-SIP, once > > > > > > the destination UAS or a UAS in a B2BUA has been > > > reached, the same > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > vanilla SIP UA. > > > > I > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > subsequent INFO > > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > > gateway > > > > > will have to re issue a new INVITE with all the digits. > > > > > Therefore, it is > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > Besides, I do not think that SIP is just a transport protocol > > that > > > > > carries ISUP messages between two gateways. For that, we have > > > > already > > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > > call is a > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > state. And a > > > > > SIP message with an incomplete to field does not > carry complete > > > > state. > > > > > What if my SIP proxy provides a service for a > PSTN-SIP-PSTN call > > > > > > based > > > > > on the to field (called party number). That proxy would > > > like to see > > > > an > > > > > updated to field, not just a to field that contains just some > > > > digits. > > > > > > > > > > Best regards, > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > To: Gonzalo Camarillo > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > > been proposed > > > > > > > earlier in this thread, so I assumed INFO would > be used. The > > > > > > > > > reason for > > > > > > > the discussion from the beginning was that the overlap > > > > signalling, > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > very well, and > > > > > > a > > > > > > > solution using 18x responses and INFO messages, instead of > > 484 > > > > and > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer Holmberg > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > signalling section. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty > > much > > > > > > > about calls > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > SIP UAS > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > | <- 18x ------ | > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > | <- 18x ------ | > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > > --> > > > > > > > > > | <- 200 (INVITE)| <- 200 > > ------ > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > > the word 'proxy') > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > overlap dialing, to > > > > > > > > > be able to find the SIP UAS, and INFO is used > to provide > > > > > > > > > the digits > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > if you like) > > > > > > > > > be allowed to > > > > > > > > > behave like this, or MUST it send 486s, and > receive new > > > > > > > INVITEs, until > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > -- > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > FIN-02420 Jorvas Email : > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : > > Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > ------_=_NextPart_001_01C095C5.3C33D660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Operlap dialing within a SIP network

Gonzalo,

I'm not sure were completely understanding each other = here.

I think we do agree that there is value in the SIP-T = concept, so that the PSTN can interwork with services provided in the = 'pure SIP' network by SIP proxy servers.

I think that the path we're on of including ISUP = messages inside SIP messages is as good as any other for this, so I = don't see any value in pursuing alternatives, such as setting up a = SIGTRAN session for the ISUP signalling.

I do not see the problem, though, with allowing PSTN = gateways to switch to a more efficient mode of overlap signalling once = the gateway out of the SIP network has been identified. Sure, whilst = the call is still progressing through the SIP network, and we want to = make use of the routing capabilities in the SIP network, we use normal = SIP procedures, but once we have hit the PSTN gateway, why not optimise = things ?

<snip>

> > 2) The UAC must use source routing to = ensure that all these INVITES
> > make it to the same UAS
>
> What is the problem here? This is done in order = to address the problem
> of proxies performing load balancing. Some = folks have pointed out that
> maybe the betwork wants to route the second = INVITE in a
> different way...
> why the network would like to do that? The = policy that is
> applicable to
> the fist INVITE (that contained a prefix of the = number) should be the
> same that applies to the subsequent = ones.

Why ? How can you possibly know that all services in = all networks will work this way ? There are a host of reasons why = routing of the INVITE might vary due to factors other than the digits. = INVITES for the *same digits* might route differently, and not just due = to load balancing.

<snip>

> > The price we pay for this is that = intermediate proxies may not have
> > access to the full Called Party Number - = but a proxy that
> needs this,
> > that wants to offer service on overlap = calls, can always sniff the
> > overlap digits as they go past.
>
> Let me get this straight. Are you are proposing = to change the logic in
> all the already existing proxies because you = want to provide services
> when you use INFO for carrying SAMs? This is = just impossible.
>

All proxies which want to provide services:
a) which operate *after* the INVITE has been routed = and the terminating point in the SIP network found,
b) which require access to the full PSTN = number,
c) on PSTN -> SIP-T -> PSTN calls,
d) which are delivered on overlap calls, and
e) which do not know the dial-plan well enough to = identity end-of-dialling themselves.

I think right now this is the empty set, so, yes, I = can upgrade all these :-)

Regards,

Mark Watson
Nortel Networks

> I still prefer a mechanism that do not require = changes in the existing
> proxies (multiple call-legs).
>
> Best regards,
>
> Gonzalo
>
> >
> > Regards,
> >
> > Mark Watson
> > Nortel Networks
> >
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > Sent: 07 February 2001 02:52
> > > To: Taylor, Tom-PT = [NORSE:B901:EXCH]
> > > Cc: Christer Holmberg; = sip@lists.bell-labs.com
> > > Subject: Re: [SIP] Operlap dialing = within a SIP network
> > >
> > >
> > > Hi Tom,
> > >
> > > Still I want to have full state in = every SIP message. If
> the call is
> >
> > > addresed to the phone number 1234, I = want to have a to field that
> > says
> > > 1234. I do not care if there is a leg = routed thru the PSTN and
> > another
> > > thru SIP.
> > >
> > > Carrying full state is one of the = beauties of SIP. If we
> begin using
> >
> > > INFO for this, it would be the same = as using SAMs. Differen names,
> > the
> > > same thing... I do not want to = re-create ISUP using SIP. I
> > > believe that
> > > if the session has a destination, it = should be present in the
> > > to field.
> > >
> > > Again, if a proxy is providing = services for this
> particular call, it
> >
> > > will want to see the called party = number in order to trigger
> > > the proper
> > > service. This is a very good reason = for updating the to field
> > > every time
> > > we have more digits.
> > >
> > > I like to use SIP between two = gateways because it is possible
> > > to provide
> > > SIP services for a PSTN to PSTN call. = If all we want to do is
> > > finding a
> > > egrees gateway, we would probably = want to use other
> protocols (TRIP
> > &
> > > SIGTRAN for instance).
> > >
> > > Regards,
> > >
> > > Gonzalo
> > >
> > > Tom-PT Taylor wrote:
> > > >
> > > > Sorry, we're talking past each = other.  The premise of my
> > > statements is
> > > > that an INVITE has reached a UAS = which has accepted it.  It
> > follows
> > > > that the UAS did not send back a = 484, but rather an interim
> > > response.
> > > > IF more digits come along, the = INFO method is there to
> carry them.
> >
> > > > They do not affect the SIP call = state; they are used beyond the
> > UAS,
> > > > either in a PSTN call or in = another SIP call as the case may be.
> > > >
> > > > > -----Original = Message-----
> > > > > From: Gonzalo = Camarillo
> > [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > > > Sent: Tuesday, February 06, = 2001 9:10 PM
> > > > > To: Taylor, Tom-PT = [NORSE:B901:EXCH]
> > > > > Cc: Christer Holmberg; = sip@lists.bell-labs.com
> > > > > Subject: Re: [SIP] Operlap = dialing within a SIP network
> > > > >
> > > > >
> > > > > Hello Tom,
> > > > >
> > > > > Tom-PT Taylor wrote:
> > > > > >
> > > > > > Just to re-hash, in = the ISUP-SIP-ISUP context, once call
> > > > signalling
> > > > > > has reached an egress = gateway, SIP has done its job --
> > > additional
> > > > > > digits will not change = call state.  It is therefore
> > > > > reasonable to use
> > > > > > INFO to carry the = additional digits.  If we are talking
> > > > > ISUP-SIP, once
> > > > > > the destination UAS or = a UAS in a B2BUA has been
> > > reached, the same
> > > >
> > > > > > consideration = applies.
> > > > > >
> > > > >
> > > > > I do not agree with these = two statements:
> > > > >
> > > > > The 1st INVITE (with just = some digits) arrives to a
> > > vanilla SIP UA.
> > > > I
> > > > > will return a Not Found or = a 484 Address incomplete. The
> > > > > subsequent INFO
> > > > > carrying more digits will = be discarded. Thus, the PSTN to SIP
> > > > gateway
> > > > > will have to re issue a new = INVITE with all the digits.
> > > > > Therefore, it is
> > > > > better to begin directly = using er-INVITEs rather than INFO.
> > > > >
> > > > > Besides, I do not think = that SIP is just a transport protocol
> > that
> > > > > carries ISUP messages = between two gateways. For that, we have
> > > > already
> > > > > SIGTRAN. SIP might be used = to provide services, even when the
> > > > > call is a
> > > > > PSTN-SIP-PSTN call. Thus, = SIP messages MUST carry complete
> > > > > state. And a
> > > > > SIP message with an = incomplete to field does not
> carry complete
> > > > state.
> > > > > What if my SIP proxy = provides a service for a
> PSTN-SIP-PSTN call
> >
> > > > based
> > > > > on the to field (called = party number). That proxy would
> > > like to see
> > > > an
> > > > > updated to field, not just = a to field that contains just some
> > > > digits.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Gonzalo
> > > > >
> > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: Christer = Holmberg
> > > > [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > > > > > > Sent: Tuesday, = February 06, 2001 1:15 AM
> > > > > > > To: Gonzalo = Camarillo
> > > > > > > Cc: = sip@lists.bell-labs.com
> > > > > > > Subject: Re: = [SIP] Operlap dialing within a SIP network
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi = Gonzalo,
> > > > > > >
> > > > > > > I didn't say I am = going to use INFO, but that is what has
> > > > > > > been = proposed
> > > > > > > earlier in this = thread, so I assumed INFO would
> be used. The
> >
> > > > > > > reason for
> > > > > > > the discussion = from the beginning was that the overlap
> > > > signalling,
> > > > > > > according to the = SIP-ISUP mapping draft, may not work
> > > > > very well, and
> > > > > > a
> > > > > > > solution using = 18x responses and INFO messages, instead of
> > 484
> > > > and
> > > > > > > re-INVITEs, was = proposed.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Christer = Holmberg
> > > > > > > Ericsson = Finland
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Gonzalo Camarillo = wrote:
> > > > > > > >
> > > > > > > > Hello = Christer,
> > > > > > > >
> > > > > > > > Why are you = using INFO for sending extra digits?
> > > > > > > >
> > > > > > > > Please, = check the SIP-ISUP mapping draft, overlap
> > > > > > > signalling = section.
> > > > > > > >
> > > > > > > > = Regards,
> > > > > > > >
> > > > > > > > = Gonzalo
> > > > > > > >
> > > > > > > > Christer = Holmberg wrote:
> > > > > > > > >
> > > > > > > > > = Hi,
> > > > > > > > >
> > > > > > > > > The = discussion about overlap dialing has been pretty
> > much
> > > > > > > about = calls
> > > > > > > > > from = SIP to PSTN, or PSTN-SIP-PSTN.
> > > > > > > > >
> > > > > > > > > = Consider the following scenario.
> > > > > > > > >
> > > > > > > > > PSTN = PHONE           &= nbsp; GW           = SIP SERVER
> > >   SIP UAS
> > > > > > > > >
> > > = -----------------------------------------------------------
> > > > > > > > >
> > > > > > > > > --- 1 = --->    -- IAM -> | -- INVITE -->  = |
> > > > > > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > > > --- 2 = --->    -- SAM -> | -- INFO ---->  = |
> > > > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |
> > > > > > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > > > --- 3 = --->    -- SAM -> | -- INFO ---->  = |
> > > > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |   -- INVITE
> > > > > > > > > = -->
> > > > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INVITE)|   <- 200
> > ------
> > > > > > > > >
> > > > > > > > > In this = case, the SIP server (note that I am not using
> > > > > > > the word = 'proxy')
> > > > > > > > > must = collect digits, sent from the PSTN side using
> > > > > > > overlap dialing, = to
> > > > > > > > > be able = to find the SIP UAS, and INFO is used
> to provide
> >
> > > > > > > the digits
> > > > > > > > > after = the INVITE has been sent.
> > > > > > > > >
> > > > > > > > > My = question is, should a SIP server (proxy,
> if you like)
> >
> > > > > > > be allowed = to
> > > > > > > > > behave = like this, or MUST it send 486s, and
> receive new
> > > > > > > INVITEs, = until
> > > > > > > > > it is = able to find the UAS?
> > > > > > > > >
> > > > > > > > > = Regards,
> > > > > > > > >
> > > > > > > > > = Christer Holmberg
> > > > > > > > > = Ericsson Finland
> > > > > > > >
> > > > > > > > --
> > > > > > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > > > > > Oy L M = Ericsson Ab        Mobile:  = +358 40 702 35 35
> > > > > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > > > > > FIN-02420 = Jorvas          Email = :
> > > > > = Gonzalo.Camarillo@ericsson.com
> > > > > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > > > >
> > > > >
> > > > > --
> > > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > > FIN-02420 = Jorvas          Email = :
> > Gonzalo.Camarillo@ericsson.com
> > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > >
> > >
> > > --
> > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > >
> > > = _______________________________________________
> > > This list is for continuing = development of the SIP protocol.
> > > The sip-implementer's list is the = place to discuss implementation,
> > > and to receive advice on = understanding existing sip.
> > > To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> > > "subscribe = sip-implementors" in the body.
> > >
>
> --
> Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> = Finland           = ;        http://www.hut.fi/~gonzalo
>

------_=_NextPart_001_01C095C5.3C33D660-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 12:00:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24134 for ; Tue, 13 Feb 2001 12:00:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7A50A44340; Tue, 13 Feb 2001 12:00:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 258E044337 for ; Tue, 13 Feb 2001 11:59:20 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id IAA00405 for ; Tue, 13 Feb 2001 08:59:22 -0800 (PST) Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with SMTP id AAK41750; Tue, 13 Feb 2001 08:59:13 -0800 (PST) Message-Id: <4.1.20010213085223.01351f00@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: sip@lists.bell-labs.com From: Rohan Mahy Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5178866==_.ALT" Subject: [SIP] matching m= lines with multi-unicast SDP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 09:08:20 -0800 --=====================_5178866==_.ALT Content-Type: text/plain; charset="us-ascii" Hi folks, Let's say I send an INVITE to A with a multi-unicast SDP. I want A to send (the same) audio to 10.1.1.1 and 10.1.1.2, and be prepared to receive audio from either (or both). A -- 10.1.1.1 \ 10.1.1.2 Here is part of my INVITE: INVITE sip:A -> ... m=audio 16902 0 c=10.1.1.1 m=audio 19764 0 c=10.1.1.2 Now according to the m= line matching rules, I need all the lines to match. So which of the following are valid responses? It seems that none of them have the desired semantics. Two m= lines, but use the same port (is this allowed?) <- 200 ... m=audio 17804 0 c=10.1.1.3 m=audio 17804 0 c=10.1.1.3 Two m= lines, one port set to zero (doesn't this mean "i won't accept that stream"?) <- 200 ... m=audio 17804 0 c=10.1.1.3 m=audio 0 0 c=10.1.1.3 Two m= lines, one address line set to zero (make 10.1.1.2 stop sending?) <- 200 ... m=audio 17804 0 c=10.1.1.3 m=audio 17804 0 c=0.0.0.0 Only one m= line (seems to violate principal of m= line matching) <- 200 ... m=audio 17804 0 c=10.1.1.3 Comments are welcome. thanks, -rohan --=====================_5178866==_.ALT Content-Type: text/html; charset="us-ascii" Hi folks,

Let's say I send an INVITE to A with a multi-unicast SDP.  I want A to send (the same) audio to 10.1.1.1 and 10.1.1.2, and be prepared to receive audio from either (or both).

A -- 10.1.1.1
 \
  10.1.1.2

Here is part of my INVITE:
INVITE sip:A ->
...
m=audio 16902 0
c=10.1.1.1
m=audio 19764 0
c=10.1.1.2

Now according to the m= line matching rules, I need all the lines to match.  So which of the following are valid responses?  It seems that none of them have the desired semantics.

Two m= lines, but use the same port  (is this allowed?)

        <- 200
        ...
m=audio 17804 0
c=10.1.1.3
m=audio 17804 0
c=10.1.1.3

Two m= lines, one port set to zero (doesn't this mean "i won't accept that stream"?)
<- 200
...
m=audio 17804 0
c=10.1.1.3
m=audio 0 0
c=10.1.1.3

Two m= lines, one address line set to zero (make 10.1.1.2 stop sending?)
<- 200
...
m=audio 17804 0
c=10.1.1.3
m=audio 17804 0
c=0.0.0.0

Only one m= line (seems to violate principal of m= line matching)
<- 200
...
m=audio 17804 0
c=10.1.1.3

Comments are welcome.

thanks,
-rohan
--=====================_5178866==_.ALT-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 12:28:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25045 for ; Tue, 13 Feb 2001 12:28:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 794464433C; Tue, 13 Feb 2001 12:28:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id 3175A44337 for ; Tue, 13 Feb 2001 12:27:31 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G8P00B01HDGLD@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 13 Feb 2001 17:17:40 +0000 (GMT) Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G8P00B3MHDFDM@firewall.mcit.com>; Tue, 13 Feb 2001 17:17:40 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with SMTP id <0G8P00B01HDFQ0@dgismtp02.wcomnet.com>; Tue, 13 Feb 2001 17:17:39 +0000 (GMT) Received: from Steveb1 ([166.35.224.41]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0G8P006OEHCZZG@dgismtp02.wcomnet.com>; Tue, 13 Feb 2001 17:17:23 +0000 (GMT) From: "Christopher A. Martin" Subject: RE: [SIP] matching m= lines with multi-unicast SDP In-reply-to: <4.1.20010213085223.01351f00@imop.cisco.com> To: "'Rohan Mahy'" , sip@lists.bell-labs.com Reply-To: christopher.a.martin@wcom.com Message-id: <005301c095e0$d2186180$6401010a@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Wre4EvkuxJeYMxDD1wCEFA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 11:17:18 -0600 This is a multi-part message in MIME format. --Boundary_(ID_Wre4EvkuxJeYMxDD1wCEFA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hello, Wouldnt the response be unique from each host, regardless of the mcast INVITE, since the INVITE specifies which listening port is open on the caller to each recipient? One callee wouldnt respond with a listening port on behalf of the other callee, would they? I'll go and read up on this, since these are assumptions on my part. Chris. -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Rohan Mahy Sent: Tuesday, February 13, 2001 11:08 AM To: sip@lists.bell-labs.com Subject: [SIP] matching m= lines with multi-unicast SDP Hi folks, Let's say I send an INVITE to A with a multi-unicast SDP. I want A to send (the same) audio to 10.1.1.1 and 10.1.1.2, and be prepared to receive audio from either (or both). A -- 10.1.1.1 \ 10.1.1.2 Here is part of my INVITE: INVITE sip:A -> ... m=audio 16902 0 c=10.1.1.1 m=audio 19764 0 c=10.1.1.2 Now according to the m= line matching rules, I need all the lines to match. So which of the following are valid responses? It seems that none of them have the desired semantics. Two m= lines, but use the same port (is this allowed?) <- 200 ... m=audio 17804 0 c=10.1.1.3 m=audio 17804 0 c=10.1.1.3 Two m= lines, one port set to zero (doesn't this mean "i won't accept that stream"?) <- 200 ... m=audio 17804 0 c=10.1.1.3 m=audio 0 0 c=10.1.1.3 Two m= lines, one address line set to zero (make 10.1.1.2 stop sending?) <- 200 ... m=audio 17804 0 c=10.1.1.3 m=audio 17804 0 c=0.0.0.0 Only one m= line (seems to violate principal of m= line matching) <- 200 ... m=audio 17804 0 c=10.1.1.3 Comments are welcome. thanks, -rohan --Boundary_(ID_Wre4EvkuxJeYMxDD1wCEFA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,
Wouldnt the response be unique from each = host,=20 regardless of the mcast INVITE, since the INVITE specifies which = listening=20 port is open on the caller to each recipient?
 
One=20 callee wouldnt respond with a listening port on behalf = of the=20 other callee, would they?
 
I'll=20 go and read up on this, since these are assumptions on my=20 part.
Chris.
-----Original Message-----
From:=20 sip-admin@lists.bell-labs.com = [mailto:sip-admin@lists.bell-labs.com]On=20 Behalf Of Rohan Mahy
Sent: Tuesday, February 13, 2001 = 11:08=20 AM
To: sip@lists.bell-labs.com
Subject: [SIP] = matching m=3D=20 lines with multi-unicast SDP

Hi = folks,

Let's say I=20 send an INVITE to A with a multi-unicast SDP.  I want A to send = (the=20 same) audio to 10.1.1.1 and 10.1.1.2, and be prepared to receive audio = from=20 either (or both).

A -- 10.1.1.1
 \
 =20 10.1.1.2

Here is part of my INVITE:
INVITE sip:A ->=20
...=20
m=3Daudio 16902 0=20
c=3D10.1.1.1=20
m=3Daudio 19764 0=20
c=3D10.1.1.2

Now according to the m=3D line = matching rules, I=20 need all the lines to match.  So which of the following are valid = responses?  It seems that none of them have the desired=20 semantics.

Two m=3D lines, but use the same port  (is this = = allowed?)

        <= /X-TAB><-=20 = 200
        ...= =20
m=3Daudio 17804 0=20
c=3D10.1.1.3=20
m=3Daudio 17804 0=20
c=3D10.1.1.3

Two m=3D lines, one port set to = zero (doesn't=20 this mean "i won't accept that stream"?)
<- 200=20
...=20
m=3Daudio 17804 0=20
c=3D10.1.1.3=20
m=3Daudio 0 0=20
c=3D10.1.1.3

Two m=3D lines, one address line = set to zero=20 (make 10.1.1.2 stop sending?)
<- 200=20
...=20
m=3Daudio 17804 0=20
c=3D10.1.1.3=20
m=3Daudio 17804 0=20
c=3D0.0.0.0

Only one m=3D line (seems to = violate principal of=20 m=3D line matching)
<- 200=20
...=20
m=3Daudio 17804 0=20
c=3D10.1.1.3

Comments are=20 welcome.

thanks,
-rohan
--Boundary_(ID_Wre4EvkuxJeYMxDD1wCEFA)-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 12:31:34 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25146 for ; Tue, 13 Feb 2001 12:31:34 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 85E8044368; Tue, 13 Feb 2001 12:28:18 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 976C144337 for ; Tue, 13 Feb 2001 12:27:35 -0500 (EST) 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 f1DHP2C07039; Tue, 13 Feb 2001 18:25:03 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id TAA10969; Tue, 13 Feb 2001 19:25:02 +0200 (EET) Message-ID: <3A896DEA.C38464C8@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Mark Watson , "'Gonzalo Camarillo'" , Tom-PT Taylor Subject: Re: [SIP] Operlap dialing within a SIP network References: Content-Type: multipart/mixed; boundary="------------615D9DE3E9C31652D6DEA97B" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 19:24:58 +0200 This is a multi-part message in MIME format. --------------615D9DE3E9C31652D6DEA97B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I think it is important to define what we want to optimize - the SIP network, the GW, or something else. I think that we during this discussion has clarified that it will not matter very much on the PSTN side, but on the SIP side. The advantages of using INFO - or, let say of not using re-INVITEs - would be: 1. We save network capacity, because we don't have to send ACKs for every re-INVITE. This may not sound too much for a single client but for PSTN gateways, where overlap dialing most likely will be used, I think we can assume that we are talking about a significant number of messages. 2. The logic in the UAS GW would be more simple, because it would not need to compare the Request-URI in the re-INVITEs with the Request-URI in the previous INVITE, to generate the correct SAM messages (using INFO, you just send the new digits, and the GW generate SAMs of them). 3. If (again, this has nothing to do with the overlap procedure itself) you have SDP body, and an encapsulated ISUP body (or any other message-body), in the INVITE, you must send it in every re-INVITE also (if you receive 484 you would probably always do so, but you may also send your re-INVITE before you get a response, and/or a proxy may suddenly re-route the INVITE to another GW, which needs the ISUP body). The advantage of using re-INVITEs, however, are: 1. You can easier access services in the SIP network 2. The GW UAC have to wait for a non-484 response for your INVITEs before you start using INFO, instead you can send your re-INVITEs as soon as you receive a SAM from ISUP. It has been discussed that the GW UAS would send some kind of provisional response when it has received enough digits to route the call forward. So, until you get that provisional response you will have to wait for the response to every INVITE you send before you can send the next INVITE, which may include buffering of SAMs in your GW UAC, and that is NOT to optimize. 3. If TRANSACTION overlaping for INFO is not allowed you would also have to wait for the response to every INFO you send before you can send the next one, since they belong to the same call-leg (the re-INVITEs are all different legs, so you don't have transaction overlaping there). 4. You can re-route the call setup to another MGC at any time (the disadvantage is, like I mentioned, that you have to include your message bodies, ISUP etc, in every INVITE), since every INVITE will have all digits in the Request-URI. The new GW UAS would then simply handle the INVITE as an initial INVITE. Yes, the proxy re-routing the call would probably also have to CANCEL to old leg (if a 484 was not received, which would happend if the GW managed to route the call forward in the PSTN network). With INFO that would not be possible. First, the proxy would have to "transfer" the INFO into an INVITE, but that would not help because the UAC still has an ongoing INVITE transaction, and does not want a response to an INFO method it never even sent. Regards, Christer Holmberg Ericsson Finland Mark Watson wrote: > > Gonzalo, > > I'm not sure were completely understanding each other here. > > I think we do agree that there is value in the SIP-T concept, so that > the PSTN can interwork with services provided in the 'pure SIP' > network by SIP proxy servers. > > I think that the path we're on of including ISUP messages inside SIP > messages is as good as any other for this, so I don't see any value in > pursuing alternatives, such as setting up a SIGTRAN session for the > ISUP signalling. > > I do not see the problem, though, with allowing PSTN gateways to > switch to a more efficient mode of overlap signalling once the gateway > out of the SIP network has been identified. Sure, whilst the call is > still progressing through the SIP network, and we want to make use of > the routing capabilities in the SIP network, we use normal SIP > procedures, but once we have hit the PSTN gateway, why not optimise > things ? > > > > > > 2) The UAC must use source routing to ensure that all these > INVITES > > > make it to the same UAS > > > > What is the problem here? This is done in order to address the > problem > > of proxies performing load balancing. Some folks have pointed out > that > > maybe the betwork wants to route the second INVITE in a > > different way... > > why the network would like to do that? The policy that is > > applicable to > > the fist INVITE (that contained a prefix of the number) should be > the > > same that applies to the subsequent ones. > > Why ? How can you possibly know that all services in all networks will > work this way ? There are a host of reasons why routing of the INVITE > might vary due to factors other than the digits. INVITES for the *same > digits* might route differently, and not just due to load balancing. > > > > > > The price we pay for this is that intermediate proxies may not > have > > > access to the full Called Party Number - but a proxy that > > needs this, > > > that wants to offer service on overlap calls, can always sniff the > > > > overlap digits as they go past. > > > > Let me get this straight. Are you are proposing to change the logic > in > > all the already existing proxies because you want to provide > services > > when you use INFO for carrying SAMs? This is just impossible. > > > > All proxies which want to provide services: > a) which operate *after* the INVITE has been routed and the > terminating point in the SIP network found, > b) which require access to the full PSTN number, > c) on PSTN -> SIP-T -> PSTN calls, > d) which are delivered on overlap calls, and > e) which do not know the dial-plan well enough to identity > end-of-dialling themselves. > > I think right now this is the empty set, so, yes, I can upgrade all > these :-) > > Regards, > > Mark Watson > Nortel Networks > > > I still prefer a mechanism that do not require changes in the > existing > > proxies (multiple call-legs). > > > > Best regards, > > > > Gonzalo > > > > > > > > Regards, > > > > > > Mark Watson > > > Nortel Networks > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: 07 February 2001 02:52 > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hi Tom, > > > > > > > > Still I want to have full state in every SIP message. If > > the call is > > > > > > > addresed to the phone number 1234, I want to have a to field > that > > > says > > > > 1234. I do not care if there is a leg routed thru the PSTN and > > > another > > > > thru SIP. > > > > > > > > Carrying full state is one of the beauties of SIP. If we > > begin using > > > > > > > INFO for this, it would be the same as using SAMs. Differen > names, > > > the > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > believe that > > > > if the session has a destination, it should be present in the > > > > to field. > > > > > > > > Again, if a proxy is providing services for this > > particular call, it > > > > > > > will want to see the called party number in order to trigger > > > > the proper > > > > service. This is a very good reason for updating the to field > > > > every time > > > > we have more digits. > > > > > > > > I like to use SIP between two gateways because it is possible > > > > to provide > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > finding a > > > > egrees gateway, we would probably want to use other > > protocols (TRIP > > > & > > > > SIGTRAN for instance). > > > > > > > > Regards, > > > > > > > > Gonzalo > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > statements is > > > > > that an INVITE has reached a UAS which has accepted it. It > > > follows > > > > > that the UAS did not send back a 484, but rather an interim > > > > response. > > > > > IF more digits come along, the INFO method is there to > > carry them. > > > > > > > > They do not affect the SIP call state; they are used beyond > the > > > UAS, > > > > > either in a PSTN call or in another SIP call as the case may > be. > > > > > > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > signalling > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > additional > > > > > > > digits will not change call state. It is therefore > > > > > > reasonable to use > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > ISUP-SIP, once > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > reached, the same > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > vanilla SIP UA. > > > > > I > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > subsequent INFO > > > > > > carrying more digits will be discarded. Thus, the PSTN to > SIP > > > > > gateway > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > Therefore, it is > > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > > > Besides, I do not think that SIP is just a transport > protocol > > > that > > > > > > carries ISUP messages between two gateways. For that, we > have > > > > > already > > > > > > SIGTRAN. SIP might be used to provide services, even when > the > > > > > > call is a > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > state. And a > > > > > > SIP message with an incomplete to field does not > > carry complete > > > > > state. > > > > > > What if my SIP proxy provides a service for a > > PSTN-SIP-PSTN call > > > > > > > > based > > > > > > on the to field (called party number). That proxy would > > > > like to see > > > > > an > > > > > > updated to field, not just a to field that contains just > some > > > > > digits. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Christer Holmberg > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > To: Gonzalo Camarillo > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what > has > > > > > > > > been proposed > > > > > > > > earlier in this thread, so I assumed INFO would > > be used. The > > > > > > > > > > > reason for > > > > > > > > the discussion from the beginning was that the overlap > > > > > signalling, > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > very well, and > > > > > > > a > > > > > > > > solution using 18x responses and INFO messages, instead > of > > > 484 > > > > > and > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty > > > > much > > > > > > > > about calls > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > SIP UAS > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | -- > INVITE > > > > > > > > > > --> > > > > > > > > > > | <- 200 (INVITE)| <- 200 > > > ------ > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not > using > > > > > > > > the word 'proxy') > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > overlap dialing, to > > > > > > > > > > be able to find the SIP UAS, and INFO is used > > to provide > > > > > > > > > > > the digits > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > > if you like) > > > > > > > > > > > be allowed to > > > > > > > > > > behave like this, or MUST it send 486s, and > > receive new > > > > > > > > INVITEs, until > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : > > > Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : > Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > _______________________________________________ > > > > This list is for continuing development of the SIP protocol. > > > > The sip-implementer's list is the place to discuss > implementation, > > > > and to receive advice on understanding existing sip. > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > > "subscribe sip-implementors" in the body. > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > --------------615D9DE3E9C31652D6DEA97B 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 --------------615D9DE3E9C31652D6DEA97B-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 12:39:21 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25351 for ; Tue, 13 Feb 2001 12:39:21 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E8DC644360; Tue, 13 Feb 2001 12:32:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by lists.bell-labs.com (Postfix) with ESMTP id D9ACB44372 for ; Tue, 13 Feb 2001 12:31:20 -0500 (EST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 13 Feb 2001 09:02:54 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 Feb 2001 09:03:39 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Tue, 13 Feb 2001 09:03:39 -0800 Content-Class: urn:content-classes:message Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4643.0 Thread-Topic: [SIP] Operlap dialing within a SIP network Thread-Index: AcCV3NktzupdeWP6TEaUELskgUWW2wAAYrxA From: "Christian Huitema" To: "Mark Watson" , "Gonzalo Camarillo" Cc: "Tom-PT Taylor" , "Christer Holmberg" , X-OriginalArrivalTime: 13 Feb 2001 17:03:39.0608 (UTC) FILETIME=[E9516D80:01C095DE] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 09:03:39 -0800 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA25351 The question is, how do we differentiate between a PSTN gateway and an VoIP PBX. Both can take advantage of additional digits; only one of them is capable of receiving ISUP. In the VoIP PBX case, you would want the additional digits to be sent the "pure SIP" way, i.e. through a re-invite. -- Christian Huitema -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Tuesday, February 13, 2001 6:00 AM To: 'Gonzalo Camarillo'; Mark Watson Cc: Tom-PT Taylor; Christer Holmberg; sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network Gonzalo, I'm not sure were completely understanding each other here. I think we do agree that there is value in the SIP-T concept, so that the PSTN can interwork with services provided in the 'pure SIP' network by SIP proxy servers. I think that the path we're on of including ISUP messages inside SIP messages is as good as any other for this, so I don't see any value in pursuing alternatives, such as setting up a SIGTRAN session for the ISUP signalling. I do not see the problem, though, with allowing PSTN gateways to switch to a more efficient mode of overlap signalling once the gateway out of the SIP network has been identified. Sure, whilst the call is still progressing through the SIP network, and we want to make use of the routing capabilities in the SIP network, we use normal SIP procedures, but once we have hit the PSTN gateway, why not optimise things ? > > 2) The UAC must use source routing to ensure that all these INVITES > > make it to the same UAS > > What is the problem here? This is done in order to address the problem > of proxies performing load balancing. Some folks have pointed out that > maybe the betwork wants to route the second INVITE in a > different way... > why the network would like to do that? The policy that is > applicable to > the fist INVITE (that contained a prefix of the number) should be the > same that applies to the subsequent ones. Why ? How can you possibly know that all services in all networks will work this way ? There are a host of reasons why routing of the INVITE might vary due to factors other than the digits. INVITES for the *same digits* might route differently, and not just due to load balancing. > > The price we pay for this is that intermediate proxies may not have > > access to the full Called Party Number - but a proxy that > needs this, > > that wants to offer service on overlap calls, can always sniff the > > overlap digits as they go past. > > Let me get this straight. Are you are proposing to change the logic in > all the already existing proxies because you want to provide services > when you use INFO for carrying SAMs? This is just impossible. > All proxies which want to provide services: a) which operate *after* the INVITE has been routed and the terminating point in the SIP network found, b) which require access to the full PSTN number, c) on PSTN -> SIP-T -> PSTN calls, d) which are delivered on overlap calls, and e) which do not know the dial-plan well enough to identity end-of-dialling themselves. I think right now this is the empty set, so, yes, I can upgrade all these :-) Regards, Mark Watson Nortel Networks > I still prefer a mechanism that do not require changes in the existing > proxies (multiple call-legs). > > Best regards, > > Gonzalo > > > > > Regards, > > > > Mark Watson > > Nortel Networks > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: 07 February 2001 02:52 > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > Hi Tom, > > > > > > Still I want to have full state in every SIP message. If > the call is > > > > > addresed to the phone number 1234, I want to have a to field that > > says > > > 1234. I do not care if there is a leg routed thru the PSTN and > > another > > > thru SIP. > > > > > > Carrying full state is one of the beauties of SIP. If we > begin using > > > > > INFO for this, it would be the same as using SAMs. Differen names, > > the > > > same thing... I do not want to re-create ISUP using SIP. I > > > believe that > > > if the session has a destination, it should be present in the > > > to field. > > > > > > Again, if a proxy is providing services for this > particular call, it > > > > > will want to see the called party number in order to trigger > > > the proper > > > service. This is a very good reason for updating the to field > > > every time > > > we have more digits. > > > > > > I like to use SIP between two gateways because it is possible > > > to provide > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > finding a > > > egrees gateway, we would probably want to use other > protocols (TRIP > > & > > > SIGTRAN for instance). > > > > > > Regards, > > > > > > Gonzalo > > > > > > Tom-PT Taylor wrote: > > > > > > > > Sorry, we're talking past each other. The premise of my > > > statements is > > > > that an INVITE has reached a UAS which has accepted it. It > > follows > > > > that the UAS did not send back a 484, but rather an interim > > > response. > > > > IF more digits come along, the INFO method is there to > carry them. > > > > > > They do not affect the SIP call state; they are used beyond the > > UAS, > > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > signalling > > > > > > has reached an egress gateway, SIP has done its job -- > > > additional > > > > > > digits will not change call state. It is therefore > > > > > reasonable to use > > > > > > INFO to carry the additional digits. If we are talking > > > > > ISUP-SIP, once > > > > > > the destination UAS or a UAS in a B2BUA has been > > > reached, the same > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > vanilla SIP UA. > > > > I > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > subsequent INFO > > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > > gateway > > > > > will have to re issue a new INVITE with all the digits. > > > > > Therefore, it is > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > Besides, I do not think that SIP is just a transport protocol > > that > > > > > carries ISUP messages between two gateways. For that, we have > > > > already > > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > > call is a > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > state. And a > > > > > SIP message with an incomplete to field does not > carry complete > > > > state. > > > > > What if my SIP proxy provides a service for a > PSTN-SIP-PSTN call > > > > > > based > > > > > on the to field (called party number). That proxy would > > > like to see > > > > an > > > > > updated to field, not just a to field that contains just some > > > > digits. > > > > > > > > > > Best regards, > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > To: Gonzalo Camarillo > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > > been proposed > > > > > > > earlier in this thread, so I assumed INFO would > be used. The > > > > > > > > > reason for > > > > > > > the discussion from the beginning was that the overlap > > > > signalling, > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > very well, and > > > > > > a > > > > > > > solution using 18x responses and INFO messages, instead of > > 484 > > > > and > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer Holmberg > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > signalling section. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty > > much > > > > > > > about calls > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > SIP UAS > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > | <- 18x ------ | > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > | <- 18x ------ | > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > > --> > > > > > > > > > | <- 200 (INVITE)| <- 200 > > ------ > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > > the word 'proxy') > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > overlap dialing, to > > > > > > > > > be able to find the SIP UAS, and INFO is used > to provide > > > > > > > > > the digits > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > if you like) > > > > > > > > > be allowed to > > > > > > > > > behave like this, or MUST it send 486s, and > receive new > > > > > > > INVITEs, until > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > -- > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > FIN-02420 Jorvas Email : > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : > > Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 14:29:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28444 for ; Tue, 13 Feb 2001 14:29:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A65B4433A; Tue, 13 Feb 2001 14:29:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 1A36844337 for ; Tue, 13 Feb 2001 14:28:27 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA06191 for ; Tue, 13 Feb 2001 11:28:29 -0800 (PST) Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with SMTP id AAK44206; Tue, 13 Feb 2001 11:28:25 -0800 (PST) Message-Id: <4.1.20010213111204.0137de50@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: sip@lists.bell-labs.com From: Rohan Mahy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [SIP] multicast SDP in 200 only Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 11:12:25 -0800 Hi, I think we came to consensus that for unicast SDP, you must either have SDP in the INV/200 or in the 200/ACK. Reading the conferencing models draft, I realized that for multicast the spec permits different behavior: > Inviting users to join is simple. Any user may invite any other user > to join. The SIP INVITE request contains SDP that indicates multicast > addresses for each media line. The SDP in the 200 OK response may > actually be empty. From Section B.3 of RFC2543: > For multicast, receive and send multicast addresses are the > same and all parties use the same port numbers to receive > media data. If the session description provided by the > caller is acceptable to the callee, the callee can choose > not to include a session description or MAY echo the > description in the response. so my question is, should it be OK to send no SDP in INVITE, multicast SDP in 200, and no SDP in ACK? My proposal is that we deprecate the old behavior, and encourage implementations which receive a multicast SDP in an INVITE to echo it back in the 200; and likewise if no SDP was in an INVITE, to echo the multicast SDP from a 200 in the ACK. Does this seem reasonable? thanks, -rohan _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 15:15:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29479 for ; Tue, 13 Feb 2001 15:15:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8380D4433A; Tue, 13 Feb 2001 15:15:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id 842F244337 for ; Tue, 13 Feb 2001 15:14:50 -0500 (EST) Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id UAA17086; Tue, 13 Feb 2001 20:14:43 GMT From: Alejandro.Avella@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id UAA25379; Tue, 13 Feb 2001 20:14:39 GMT Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id <1QBA15F0>; Tue, 13 Feb 2001 13:16:48 -0700 Message-ID: <45519C0029A1D411BE3F00508BF9E5522CFA38@n0216idc1.oss.level3.com> To: liangxg@catt.ac.cn, sip@lists.bell-labs.com Subject: RE: [SIP] Any material for SIP study? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C095F9.4DC40060" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 13:12:35 -0700 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C095F9.4DC40060 Content-Type: text/plain; charset="gb2312" Try this web page: http://www.cs.columbia.edu/~hgs/sip/ Or this book SIP: Understanding the Session Initiation Protocol by Alan B. Johnston http://www.amazon.com/exec/obidos/ASIN/1580531687/qid=982095141/sr=1-16/ref= sc_b_16/102-2428220-5411311 Alejandro -----Original Message----- From: Xingang Liang [mailto:liangxg@catt.ac.cn] Sent: Tuesday, February 13, 2001 2:43 AM To: sip@lists.bell-labs.com Subject: [SIP] Any material for SIP study? Hi every one,I am just focusing on SIP in 3GPP now,but I don't know about it,I wonder if anyone can direct me some materials or reference about SIP,so that I can learn it quickly! I will thank every one here first,thank you!!! Any advice is welcome!!!! Best Regards Xingang Liang Standardization Department Mobile Communication R&D Center China Academy of Telecommunication Technology(CATT) No.40,Xueyuan Road Beijing,China 100083 Tel:+8610 62304422EXT225 Fax:+8610 62303127 Mailto:liangxg@catt.ac.cn ------_=_NextPart_001_01C095F9.4DC40060 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Try = this web=20 page:
http://www.cs.columbia.edu= /~hgs/sip/
 
Or = this=20 book
SIP: Understanding the Session = Initiation=20 Protocol
by Alan=20 B. Johnston
http://www.amazon.com/exe= c/obidos/ASIN/1580531687/qid=3D982095141/sr=3D1-16/ref=3Dsc_b_16/102-242= 8220-5411311
 
Alejandro
-----Original Message-----
From: Xingang = Liang=20 [mailto:liangxg@catt.ac.cn]
Sent: Tuesday, February 13, = 2001 2:43=20 AM
To: sip@lists.bell-labs.com
Subject: [SIP] Any = material=20 for SIP study?

Hi every one,I am just focusing on SIP in 3GPP now,but I = don't know=20 about it,I wonder if anyone can direct me some materials or reference = about=20 SIP,so that I can learn it quickly!
I will thank every one here first,thank you!!!
 
Any advice is welcome!!!!
 
Best Regards
Xingang Liang
Standardization Department
Mobile = Communication=20 R&D Center
China Academy of Telecommunication=20 Technology(CATT)
No.40,Xueyuan = Road
Beijing,China
100083
Tel:+8610=20 62304422EXT225
Fax:+8610 62303127
Mailto:liangxg@catt.ac.cn
&nbs= p;
 
------_=_NextPart_001_01C095F9.4DC40060-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 16:27:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00584 for ; Tue, 13 Feb 2001 16:27:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 863404433A; Tue, 13 Feb 2001 16:27:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (HSE-Kitchener-ppp194714.sympatico.ca [64.229.14.47]) by lists.bell-labs.com (Postfix) with ESMTP id ED83644337 for ; Tue, 13 Feb 2001 16:26:06 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 13 Feb 2001 16:29:09 -0500 (EST) From: Billy Biggs To: Rohan Mahy Cc: SIP List Subject: Re: [SIP] matching m= lines with multi-unicast SDP Message-ID: <20010213162909.B2224@div8.net> References: <4.1.20010213085223.01351f00@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010213085223.01351f00@imop.cisco.com>; from rohan@cisco.com on Tue, Feb 13, 2001 at 09:08:20AM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 16:29:09 -0500 Rohan Mahy (rohan@cisco.com): > Let's say I send an INVITE to A with a multi-unicast SDP. I want A to > send (the same) audio to 10.1.1.1 and 10.1.1.2, and be prepared to > receive audio from either (or both). Careful: If A accepts the INVITE, it should be prepared to receive media from anywhere, not only from 10.1.1.1 and 10.1.1.2. > A -- 10.1.1.1 > \ > 10.1.1.2 > > Here is part of my INVITE: > INVITE sip:A -> > ... > m=audio 16902 0 > c=10.1.1.1 > m=audio 19764 0 > c=10.1.1.2 > > Now according to the m= line matching rules, I need all the lines to > match. So which of the following are valid responses? It seems that > none of them have the desired semantics. > > [...] > > Only one m= line (seems to violate principal of m= line matching) > <- 200 > ... > m=audio 17804 0 > c=10.1.1.3 (personal opinion) I think it should be this. Because your SDP may be modified by a third party, or transcoded, or whatever, I believe that the two session descriptions (local and remote) to be completely independant: advertise what you are willing to receive, the remote end will do the same, we'll talk happily. I'm against the idea of m= line matching. -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 17:19:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01499 for ; Tue, 13 Feb 2001 17:19:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 959DB4433A; Tue, 13 Feb 2001 17:19:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id D26D544337 for ; Tue, 13 Feb 2001 17:18:22 -0500 (EST) 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 f1DMIMd26998; Tue, 13 Feb 2001 23:18:22 +0100 (MET) Received: from lmf.ericsson.se (EWUwsp001664wss.sd.us.am.ericsson.se [142.133.141.80]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA26474; Tue, 13 Feb 2001 23:18:15 +0100 (MET) Message-ID: <3A89B0F9.CE3D59F7@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson Cc: Tom-PT Taylor , Christer Holmberg , sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 14 Feb 2001 00:11:05 +0200 Content-Transfer-Encoding: 7bit Hello Mark, Mark Watson wrote: > > Gonzalo, > > I'm not sure were completely understanding each other here. > I am sure that we do not understand each other... my comments inline: > I think we do agree that there is value in the SIP-T concept, so that > the PSTN can interwork with services provided in the 'pure SIP' > network by SIP proxy servers. > > I think that the path we're on of including ISUP messages inside SIP > messages is as good as any other for this, so I don't see any value in > pursuing alternatives, such as setting up a SIGTRAN session for the > ISUP signalling. > > I do not see the problem, though, with allowing PSTN gateways to > switch to a more efficient mode of overlap signalling once the gateway > out of the SIP network has been identified. Sure, whilst the call is > still progressing through the SIP network, and we want to make use of > the routing capabilities in the SIP network, we use normal SIP > procedures, but once we have hit the PSTN gateway, why not optimise > things ? > Optimizing things means to use an optimal way for transporting overlap signalling, right? Then, you want to use SIGTRAN. Efficient, allows multi-homing, low overhead, etc... Using INFO breaks all the application servers in the SIP network. Besides, it breaks SIP itself (as I have been pointing out a number of times in this thread already). But people are more worried about saving one message (the ACK) than about being coherent with the way SIP services will be provided. > > > > > 2) The UAC must use source routing to ensure that all these > INVITES > > > make it to the same UAS > > > > What is the problem here? This is done in order to address the > problem > > of proxies performing load balancing. Some folks have pointed out > that > > maybe the betwork wants to route the second INVITE in a > > different way... > > why the network would like to do that? The policy that is > > applicable to > > the fist INVITE (that contained a prefix of the number) should be > the > > same that applies to the subsequent ones. > > Why ? How can you possibly know that all services in all networks will > work this way ? There are a host of reasons why routing of the INVITE > might vary due to factors other than the digits. INVITES for the *same > digits* might route differently, and not just due to load balancing. Let me explain this point. If the network has routed in a certain way (that, as you say, might depend on a thousand of parameters) the first INVITE, the following INFOs (assuming that you use INFO for sending SAMs) will be routed in the same way, right? Well, then, the re-INVITEs belonging to the same call have to be routed in the same way also. So, even if the network decides not to honor the record route present in the INVITE, the message will be routed in the same way. The only expection is when the routing decision is made randomly, that is, without depending on any parameters. This is, the same message might be routed in a different way depending on the time of the day, for instance. Then, this is load balancing, and that is why source routing is used. > > > > > > The price we pay for this is that intermediate proxies may not > have > > > access to the full Called Party Number - but a proxy that > > needs this, > > > that wants to offer service on overlap calls, can always sniff the > > > > overlap digits as they go past. > > > > Let me get this straight. Are you are proposing to change the logic > in > > all the already existing proxies because you want to provide > services > > when you use INFO for carrying SAMs? This is just impossible. > > > > All proxies which want to provide services: > a) which operate *after* the INVITE has been routed and the > terminating point in the SIP network found, > b) which require access to the full PSTN number, > c) on PSTN -> SIP-T -> PSTN calls, > d) which are delivered on overlap calls, and > e) which do not know the dial-plan well enough to identity > end-of-dialling themselves. > > I think right now this is the empty set, so, yes, I can upgrade all > these :-) All these proxies are NOT standard SIP proxies. They examine INFO messages in order to provide services... if you want to implement your network in a non-standard way, it is up to you. I will implement my network in a way that allows the same SIP proxy to handle SIP-SIP calls, PSTN-SIP calls, etc... And this was Jonathan was trying to say in his mail. The application server architecture will work well if re-INVITEs are used. It won't if INFOs are used. But anyway, if you still want to use INFO and you intend to implement non-standard SIP proxies to provide your services, it is all up to you... I just don't buy that. Best regards, Gonzalo > > Regards, > > Mark Watson > Nortel Networks > > > I still prefer a mechanism that do not require changes in the > existing > > proxies (multiple call-legs). > > > > Best regards, > > > > Gonzalo > > > > > > > > Regards, > > > > > > Mark Watson > > > Nortel Networks > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: 07 February 2001 02:52 > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hi Tom, > > > > > > > > Still I want to have full state in every SIP message. If > > the call is > > > > > > > addresed to the phone number 1234, I want to have a to field > that > > > says > > > > 1234. I do not care if there is a leg routed thru the PSTN and > > > another > > > > thru SIP. > > > > > > > > Carrying full state is one of the beauties of SIP. If we > > begin using > > > > > > > INFO for this, it would be the same as using SAMs. Differen > names, > > > the > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > believe that > > > > if the session has a destination, it should be present in the > > > > to field. > > > > > > > > Again, if a proxy is providing services for this > > particular call, it > > > > > > > will want to see the called party number in order to trigger > > > > the proper > > > > service. This is a very good reason for updating the to field > > > > every time > > > > we have more digits. > > > > > > > > I like to use SIP between two gateways because it is possible > > > > to provide > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > finding a > > > > egrees gateway, we would probably want to use other > > protocols (TRIP > > > & > > > > SIGTRAN for instance). > > > > > > > > Regards, > > > > > > > > Gonzalo > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > statements is > > > > > that an INVITE has reached a UAS which has accepted it. It > > > follows > > > > > that the UAS did not send back a 484, but rather an interim > > > > response. > > > > > IF more digits come along, the INFO method is there to > > carry them. > > > > > > > > They do not affect the SIP call state; they are used beyond > the > > > UAS, > > > > > either in a PSTN call or in another SIP call as the case may > be. > > > > > > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > signalling > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > additional > > > > > > > digits will not change call state. It is therefore > > > > > > reasonable to use > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > ISUP-SIP, once > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > reached, the same > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > vanilla SIP UA. > > > > > I > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > subsequent INFO > > > > > > carrying more digits will be discarded. Thus, the PSTN to > SIP > > > > > gateway > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > Therefore, it is > > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > > > Besides, I do not think that SIP is just a transport > protocol > > > that > > > > > > carries ISUP messages between two gateways. For that, we > have > > > > > already > > > > > > SIGTRAN. SIP might be used to provide services, even when > the > > > > > > call is a > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > state. And a > > > > > > SIP message with an incomplete to field does not > > carry complete > > > > > state. > > > > > > What if my SIP proxy provides a service for a > > PSTN-SIP-PSTN call > > > > > > > > based > > > > > > on the to field (called party number). That proxy would > > > > like to see > > > > > an > > > > > > updated to field, not just a to field that contains just > some > > > > > digits. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Christer Holmberg > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > To: Gonzalo Camarillo > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what > has > > > > > > > > been proposed > > > > > > > > earlier in this thread, so I assumed INFO would > > be used. The > > > > > > > > > > > reason for > > > > > > > > the discussion from the beginning was that the overlap > > > > > signalling, > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > very well, and > > > > > > > a > > > > > > > > solution using 18x responses and INFO messages, instead > of > > > 484 > > > > > and > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty > > > > much > > > > > > > > about calls > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > SIP UAS > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | -- > INVITE > > > > > > > > > > --> > > > > > > > > > > | <- 200 (INVITE)| <- 200 > > > ------ > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not > using > > > > > > > > the word 'proxy') > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > overlap dialing, to > > > > > > > > > > be able to find the SIP UAS, and INFO is used > > to provide > > > > > > > > > > > the digits > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > > if you like) > > > > > > > > > > > be allowed to > > > > > > > > > > behave like this, or MUST it send 486s, and > > receive new > > > > > > > > INVITEs, until > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : > > > Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : > Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > _______________________________________________ > > > > This list is for continuing development of the SIP protocol. > > > > The sip-implementer's list is the place to discuss > implementation, > > > > and to receive advice on understanding existing sip. > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > > "subscribe sip-implementors" in the body. > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 17:29:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01704 for ; Tue, 13 Feb 2001 17:29:22 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A56B744366; Tue, 13 Feb 2001 17:29:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 9FDDC44337 for ; Tue, 13 Feb 2001 17:28:27 -0500 (EST) 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 f1DMRUd00759; Tue, 13 Feb 2001 23:27:30 +0100 (MET) Received: from lmf.ericsson.se (EWUwsp001664wss.sd.us.am.ericsson.se [142.133.141.80]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA27588; Tue, 13 Feb 2001 23:27:21 +0100 (MET) Message-ID: <3A89B31C.FF1147E1@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: sip@lists.bell-labs.com, Mark Watson , Tom-PT Taylor Subject: Re: [SIP] Operlap dialing within a SIP network References: <3A896DEA.C38464C8@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 14 Feb 2001 00:20:12 +0200 Content-Transfer-Encoding: 7bit Hello Christer, This thread has already too many messages, and folks seem to respond without taking into consideration previous answers: > 2. The logic in the UAS GW would be more simple, because it would not > need > to compare the Request-URI in the re-INVITEs with the Request-URI in the > previous INVITE, to generate the correct SAM messages (using INFO, you > just send the new digits, and the GW generate SAMs of them). AS I said before, INFO does not ensure ordered delibery. So, if you do what you are just describing, it will NOT work. You will get an INFO with a SAM before the previous INFO with the previous SAM arrives... you will just shuffle the digits of the number... BAD IDEA. However, you might argue that you will use a new request-URI. Well, this is not standard SIP again. You should honor the contact header you have received, and not modify it on your own... again, you are thinking just about gateways. I would like you to think about normal clients, APS, etc... then, you will see that instead of simplifying your gateways, you are adding complexity, because you will have to implement standard SIP to interwork with vanilla UAs and your SIP-T with INFOs to interwork with other gateways. Best regards, Gonzalo > > 3. If (again, this has nothing to do with the overlap procedure itself) > you have SDP body, and an encapsulated ISUP body (or any other > message-body), in the INVITE, you must send it in every re-INVITE also > (if you receive 484 you would probably always do so, but you may also > send your re-INVITE before you get a response, and/or a proxy may > suddenly re-route the INVITE to another GW, which needs the ISUP body). > > The advantage of using re-INVITEs, however, are: > > 1. You can easier access services in the SIP network > > 2. The GW UAC have to wait for a non-484 response for your INVITEs > before you start using INFO, instead you can send your re-INVITEs as > soon as you receive a SAM from ISUP. It has been discussed that the GW > UAS would send some kind of provisional response when it has received > enough digits to route the call forward. So, until you get that > provisional response you will have to wait for the response to every > INVITE you send before you can send the next INVITE, which may include > buffering of SAMs in your GW UAC, and that is NOT to optimize. > > 3. If TRANSACTION overlaping for INFO is not allowed you would also have > to wait for the response to every INFO you send before you can send the > next one, since they belong to the same call-leg (the re-INVITEs are all > different legs, so you don't have transaction overlaping there). > > 4. You can re-route the call setup to another MGC at any time (the > disadvantage is, like I mentioned, that you have to include your message > bodies, ISUP etc, in every INVITE), since every INVITE will have all > digits in the Request-URI. The new GW UAS would then simply handle the > INVITE as an initial INVITE. Yes, the proxy re-routing the call would > probably also have to CANCEL to old leg (if a 484 was not received, > which would happend if the GW managed to route the call forward in the > PSTN network). With INFO that would not be possible. First, the proxy > would have to "transfer" the INFO into an INVITE, but that would not > help because the UAC still has an ongoing INVITE transaction, and does > not want a response to an INFO method it never even sent. > > Regards, > > Christer Holmberg > Ericsson Finland > > Mark Watson wrote: > > > > Gonzalo, > > > > I'm not sure were completely understanding each other here. > > > > I think we do agree that there is value in the SIP-T concept, so that > > the PSTN can interwork with services provided in the 'pure SIP' > > network by SIP proxy servers. > > > > I think that the path we're on of including ISUP messages inside SIP > > messages is as good as any other for this, so I don't see any value in > > pursuing alternatives, such as setting up a SIGTRAN session for the > > ISUP signalling. > > > > I do not see the problem, though, with allowing PSTN gateways to > > switch to a more efficient mode of overlap signalling once the gateway > > out of the SIP network has been identified. Sure, whilst the call is > > still progressing through the SIP network, and we want to make use of > > the routing capabilities in the SIP network, we use normal SIP > > procedures, but once we have hit the PSTN gateway, why not optimise > > things ? > > > > > > > > > > 2) The UAC must use source routing to ensure that all these > > INVITES > > > > make it to the same UAS > > > > > > What is the problem here? This is done in order to address the > > problem > > > of proxies performing load balancing. Some folks have pointed out > > that > > > maybe the betwork wants to route the second INVITE in a > > > different way... > > > why the network would like to do that? The policy that is > > > applicable to > > > the fist INVITE (that contained a prefix of the number) should be > > the > > > same that applies to the subsequent ones. > > > > Why ? How can you possibly know that all services in all networks will > > work this way ? There are a host of reasons why routing of the INVITE > > might vary due to factors other than the digits. INVITES for the *same > > digits* might route differently, and not just due to load balancing. > > > > > > > > > > The price we pay for this is that intermediate proxies may not > > have > > > > access to the full Called Party Number - but a proxy that > > > needs this, > > > > that wants to offer service on overlap calls, can always sniff the > > > > > > overlap digits as they go past. > > > > > > Let me get this straight. Are you are proposing to change the logic > > in > > > all the already existing proxies because you want to provide > > services > > > when you use INFO for carrying SAMs? This is just impossible. > > > > > > > All proxies which want to provide services: > > a) which operate *after* the INVITE has been routed and the > > terminating point in the SIP network found, > > b) which require access to the full PSTN number, > > c) on PSTN -> SIP-T -> PSTN calls, > > d) which are delivered on overlap calls, and > > e) which do not know the dial-plan well enough to identity > > end-of-dialling themselves. > > > > I think right now this is the empty set, so, yes, I can upgrade all > > these :-) > > > > Regards, > > > > Mark Watson > > Nortel Networks > > > > > I still prefer a mechanism that do not require changes in the > > existing > > > proxies (multiple call-legs). > > > > > > Best regards, > > > > > > Gonzalo > > > > > > > > > > > Regards, > > > > > > > > Mark Watson > > > > Nortel Networks > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: 07 February 2001 02:52 > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > Still I want to have full state in every SIP message. If > > > the call is > > > > > > > > > addresed to the phone number 1234, I want to have a to field > > that > > > > says > > > > > 1234. I do not care if there is a leg routed thru the PSTN and > > > > another > > > > > thru SIP. > > > > > > > > > > Carrying full state is one of the beauties of SIP. If we > > > begin using > > > > > > > > > INFO for this, it would be the same as using SAMs. Differen > > names, > > > > the > > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > > believe that > > > > > if the session has a destination, it should be present in the > > > > > to field. > > > > > > > > > > Again, if a proxy is providing services for this > > > particular call, it > > > > > > > > > will want to see the called party number in order to trigger > > > > > the proper > > > > > service. This is a very good reason for updating the to field > > > > > every time > > > > > we have more digits. > > > > > > > > > > I like to use SIP between two gateways because it is possible > > > > > to provide > > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > > finding a > > > > > egrees gateway, we would probably want to use other > > > protocols (TRIP > > > > & > > > > > SIGTRAN for instance). > > > > > > > > > > Regards, > > > > > > > > > > Gonzalo > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > > statements is > > > > > > that an INVITE has reached a UAS which has accepted it. It > > > > follows > > > > > > that the UAS did not send back a 484, but rather an interim > > > > > response. > > > > > > IF more digits come along, the INFO method is there to > > > carry them. > > > > > > > > > > They do not affect the SIP call state; they are used beyond > > the > > > > UAS, > > > > > > either in a PSTN call or in another SIP call as the case may > > be. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gonzalo Camarillo > > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > > signalling > > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > > additional > > > > > > > > digits will not change call state. It is therefore > > > > > > > reasonable to use > > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > > ISUP-SIP, once > > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > > reached, the same > > > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > > vanilla SIP UA. > > > > > > I > > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > > subsequent INFO > > > > > > > carrying more digits will be discarded. Thus, the PSTN to > > SIP > > > > > > gateway > > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > > Therefore, it is > > > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > > > > > Besides, I do not think that SIP is just a transport > > protocol > > > > that > > > > > > > carries ISUP messages between two gateways. For that, we > > have > > > > > > already > > > > > > > SIGTRAN. SIP might be used to provide services, even when > > the > > > > > > > call is a > > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > > state. And a > > > > > > > SIP message with an incomplete to field does not > > > carry complete > > > > > > state. > > > > > > > What if my SIP proxy provides a service for a > > > PSTN-SIP-PSTN call > > > > > > > > > > based > > > > > > > on the to field (called party number). That proxy would > > > > > like to see > > > > > > an > > > > > > > updated to field, not just a to field that contains just > > some > > > > > > digits. > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Christer Holmberg > > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > > To: Gonzalo Camarillo > > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what > > has > > > > > > > > > been proposed > > > > > > > > > earlier in this thread, so I assumed INFO would > > > be used. The > > > > > > > > > > > > > reason for > > > > > > > > > the discussion from the beginning was that the overlap > > > > > > signalling, > > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > > very well, and > > > > > > > > a > > > > > > > > > solution using 18x responses and INFO messages, instead > > of > > > > 484 > > > > > > and > > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty > > > > > > much > > > > > > > > > about calls > > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > > SIP UAS > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > | <- 200 (INFO) | -- > > INVITE > > > > > > > > > > > --> > > > > > > > > > > > | <- 200 (INVITE)| <- 200 > > > > ------ > > > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not > > using > > > > > > > > > the word 'proxy') > > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > > overlap dialing, to > > > > > > > > > > > be able to find the SIP UAS, and INFO is used > > > to provide > > > > > > > > > > > > > the digits > > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > > > if you like) > > > > > > > > > > > > > be allowed to > > > > > > > > > > > behave like this, or MUST it send 486s, and > > > receive new > > > > > > > > > INVITEs, until > > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > FIN-02420 Jorvas Email : > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : > > Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > _______________________________________________ > > > > > This list is for continuing development of the SIP protocol. > > > > > The sip-implementer's list is the place to discuss > > implementation, > > > > > and to receive advice on understanding existing sip. > > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > > > "subscribe sip-implementors" in the body. > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 17:33:39 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01781 for ; Tue, 13 Feb 2001 17:33:38 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 451DC4437A; Tue, 13 Feb 2001 17:30:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 87E6E44337 for ; Tue, 13 Feb 2001 17:29:02 -0500 (EST) 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 f1DMT1d01257; Tue, 13 Feb 2001 23:29:01 +0100 (MET) Received: from lmf.ericsson.se (EWUwsp001664wss.sd.us.am.ericsson.se [142.133.141.80]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA27801; Tue, 13 Feb 2001 23:28:54 +0100 (MET) Message-ID: <3A89B37A.2533D2BA@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christian Huitema Cc: Mark Watson , Tom-PT Taylor , Christer Holmberg , sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 14 Feb 2001 00:21:46 +0200 Content-Transfer-Encoding: 7bit Hi, I agree 100%. Let's do things in the "pure SIP" way, and let us forget about optimizations that are "almost" compatible with SIP. Gonzalo Christian Huitema wrote: > > The question is, how do we differentiate between a PSTN gateway and an > VoIP PBX. Both can take advantage of additional digits; only one of them > is capable of receiving ISUP. In the VoIP PBX case, you would want the > additional digits to be sent the "pure SIP" way, i.e. through a > re-invite. > > -- Christian Huitema > > -----Original Message----- > From: Mark Watson [mailto:mwatson@nortelnetworks.com] > Sent: Tuesday, February 13, 2001 6:00 AM > To: 'Gonzalo Camarillo'; Mark Watson > Cc: Tom-PT Taylor; Christer Holmberg; sip@lists.bell-labs.com > Subject: RE: [SIP] Operlap dialing within a SIP network > > Gonzalo, > I'm not sure were completely understanding each other here. > I think we do agree that there is value in the SIP-T concept, so that > the PSTN can interwork with services provided in the 'pure SIP' network > by SIP proxy servers. > I think that the path we're on of including ISUP messages inside SIP > messages is as good as any other for this, so I don't see any value in > pursuing alternatives, such as setting up a SIGTRAN session for the ISUP > signalling. > I do not see the problem, though, with allowing PSTN gateways to switch > to a more efficient mode of overlap signalling once the gateway out of > the SIP network has been identified. Sure, whilst the call is still > progressing through the SIP network, and we want to make use of the > routing capabilities in the SIP network, we use normal SIP procedures, > but once we have hit the PSTN gateway, why not optimise things ? > > > > 2) The UAC must use source routing to ensure that all these INVITES > > > make it to the same UAS > > > > What is the problem here? This is done in order to address the problem > > > of proxies performing load balancing. Some folks have pointed out that > > > maybe the betwork wants to route the second INVITE in a > > different way... > > why the network would like to do that? The policy that is > > applicable to > > the fist INVITE (that contained a prefix of the number) should be the > > same that applies to the subsequent ones. > Why ? How can you possibly know that all services in all networks will > work this way ? There are a host of reasons why routing of the INVITE > might vary due to factors other than the digits. INVITES for the *same > digits* might route differently, and not just due to load balancing. > > > > The price we pay for this is that intermediate proxies may not have > > > access to the full Called Party Number - but a proxy that > > needs this, > > > that wants to offer service on overlap calls, can always sniff the > > > overlap digits as they go past. > > > > Let me get this straight. Are you are proposing to change the logic in > > > all the already existing proxies because you want to provide services > > when you use INFO for carrying SAMs? This is just impossible. > > > All proxies which want to provide services: > a) which operate *after* the INVITE has been routed and the terminating > point in the SIP network found, > b) which require access to the full PSTN number, > c) on PSTN -> SIP-T -> PSTN calls, > d) which are delivered on overlap calls, and > e) which do not know the dial-plan well enough to identity > end-of-dialling themselves. > I think right now this is the empty set, so, yes, I can upgrade all > these :-) > Regards, > Mark Watson > Nortel Networks > > I still prefer a mechanism that do not require changes in the existing > > > proxies (multiple call-legs). > > > > Best regards, > > > > Gonzalo > > > > > > > > Regards, > > > > > > Mark Watson > > > Nortel Networks > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: 07 February 2001 02:52 > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hi Tom, > > > > > > > > Still I want to have full state in every SIP message. If > > the call is > > > > > > > addresed to the phone number 1234, I want to have a to field that > > > says > > > > 1234. I do not care if there is a leg routed thru the PSTN and > > > another > > > > thru SIP. > > > > > > > > Carrying full state is one of the beauties of SIP. If we > > begin using > > > > > > > INFO for this, it would be the same as using SAMs. Differen names, > > > > the > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > believe that > > > > if the session has a destination, it should be present in the > > > > to field. > > > > > > > > Again, if a proxy is providing services for this > > particular call, it > > > > > > > will want to see the called party number in order to trigger > > > > the proper > > > > service. This is a very good reason for updating the to field > > > > every time > > > > we have more digits. > > > > > > > > I like to use SIP between two gateways because it is possible > > > > to provide > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > finding a > > > > egrees gateway, we would probably want to use other > > protocols (TRIP > > > & > > > > SIGTRAN for instance). > > > > > > > > Regards, > > > > > > > > Gonzalo > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > statements is > > > > > that an INVITE has reached a UAS which has accepted it. It > > > follows > > > > > that the UAS did not send back a 484, but rather an interim > > > > response. > > > > > IF more digits come along, the INFO method is there to > > carry them. > > > > > > > > They do not affect the SIP call state; they are used beyond the > > > UAS, > > > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > signalling > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > additional > > > > > > > digits will not change call state. It is therefore > > > > > > reasonable to use > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > ISUP-SIP, once > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > reached, the same > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > vanilla SIP UA. > > > > > I > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > subsequent INFO > > > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > > > gateway > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > Therefore, it is > > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > > > Besides, I do not think that SIP is just a transport protocol > > > that > > > > > > carries ISUP messages between two gateways. For that, we have > > > > > already > > > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > > > call is a > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > state. And a > > > > > > SIP message with an incomplete to field does not > > carry complete > > > > > state. > > > > > > What if my SIP proxy provides a service for a > > PSTN-SIP-PSTN call > > > > > > > > based > > > > > > on the to field (called party number). That proxy would > > > > like to see > > > > > an > > > > > > updated to field, not just a to field that contains just some > > > > > digits. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Christer Holmberg > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > To: Gonzalo Camarillo > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > > > been proposed > > > > > > > > earlier in this thread, so I assumed INFO would > > be used. The > > > > > > > > > > > reason for > > > > > > > > the discussion from the beginning was that the overlap > > > > > signalling, > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > very well, and > > > > > > > a > > > > > > > > solution using 18x responses and INFO messages, instead of > > > > 484 > > > > > and > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty > > > much > > > > > > > > about calls > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > SIP UAS > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > > > > --> > > > > > > > > > > | <- 200 (INVITE)| <- 200 > > > ------ > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > > > > the word 'proxy') > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > overlap dialing, to > > > > > > > > > > be able to find the SIP UAS, and INFO is used > > to provide > > > > > > > > > > > the digits > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > > if you like) > > > > > > > > > > > be allowed to > > > > > > > > > > behave like this, or MUST it send 486s, and > > receive new > > > > > > > > INVITEs, until > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : > > > Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > _______________________________________________ > > > > This list is for continuing development of the SIP protocol. > > > > The sip-implementer's list is the place to discuss implementation, > > > > > and to receive advice on understanding existing sip. > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > > "subscribe sip-implementors" in the body. > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 13 23:12:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07361 for ; Tue, 13 Feb 2001 23:12:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EB50D44337; Tue, 13 Feb 2001 23:12:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by lists.bell-labs.com (Postfix) with ESMTP id 48B6744336 for ; Tue, 13 Feb 2001 23:11:57 -0500 (EST) Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Tue, 13 Feb 2001 20:45:45 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1MM3KLGQ>; Tue, 13 Feb 2001 20:43:55 -0500 Message-ID: <28560036253BD41191A10000F8BCBD110250C6E1@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "'Christian Huitema'" , "Mark Watson" , Gonzalo Camarillo Cc: Christer Holmberg , sip Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09627.95DA3350" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 13 Feb 2001 20:43:52 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C09627.95DA3350 Content-Type: text/plain; charset="iso-8859-1" This happens naturally: the VOIP PBX knows its dialling plan and can tell if not enough digits have been received. By hypothesis, the outgoing gateway to the PSTN is unable to tell if all needed digits have been received, but knows how to route the call onward. Christer raised the issue of how to handle the case where an entity beyond the gateway determines that more digits are needed. I would suggest that it works the same as a pure PSTN call: either the caller voluntarily provides more digits or the call eventually times out and fails. > -----Original Message----- > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > Sent: Tuesday, February 13, 2001 12:04 PM > To: Watson, Mark [MAIFP:EP11-M:EXCH]; Gonzalo Camarillo > Cc: Taylor, Tom-PT [NORSE:B901:EXCH]; Christer Holmberg; sip > Subject: RE: [SIP] Operlap dialing within a SIP network > > > The question is, how do we differentiate between a PSTN gateway and an > VoIP PBX. Both can take advantage of additional digits; only > one of them > is capable of receiving ISUP. In the VoIP PBX case, you would want the > additional digits to be sent the "pure SIP" way, i.e. through a > re-invite. > > -- Christian Huitema > > -----Original Message----- > From: Mark Watson [mailto:mwatson@nortelnetworks.com] > Sent: Tuesday, February 13, 2001 6:00 AM > To: 'Gonzalo Camarillo'; Mark Watson > Cc: Tom-PT Taylor; Christer Holmberg; sip@lists.bell-labs.com > Subject: RE: [SIP] Operlap dialing within a SIP network > > > Gonzalo, > I'm not sure were completely understanding each other here. > I think we do agree that there is value in the SIP-T concept, so that > the PSTN can interwork with services provided in the 'pure > SIP' network > by SIP proxy servers. > I think that the path we're on of including ISUP messages inside SIP > messages is as good as any other for this, so I don't see any value in > pursuing alternatives, such as setting up a SIGTRAN session > for the ISUP > signalling. > I do not see the problem, though, with allowing PSTN gateways > to switch > to a more efficient mode of overlap signalling once the gateway out of > the SIP network has been identified. Sure, whilst the call is still > progressing through the SIP network, and we want to make use of the > routing capabilities in the SIP network, we use normal SIP procedures, > but once we have hit the PSTN gateway, why not optimise things ? > > > > 2) The UAC must use source routing to ensure that all > these INVITES > > > make it to the same UAS > > > > What is the problem here? This is done in order to address > the problem > > > of proxies performing load balancing. Some folks have > pointed out that > > > maybe the betwork wants to route the second INVITE in a > > different way... > > why the network would like to do that? The policy that is > > applicable to > > the fist INVITE (that contained a prefix of the number) > should be the > > same that applies to the subsequent ones. > Why ? How can you possibly know that all services in all networks will > work this way ? There are a host of reasons why routing of the INVITE > might vary due to factors other than the digits. INVITES for the *same > digits* might route differently, and not just due to load balancing. > > > > The price we pay for this is that intermediate proxies > may not have > > > access to the full Called Party Number - but a proxy that > > needs this, > > > that wants to offer service on overlap calls, can always > sniff the > > > overlap digits as they go past. > > > > Let me get this straight. Are you are proposing to change > the logic in > > > all the already existing proxies because you want to > provide services > > when you use INFO for carrying SAMs? This is just impossible. > > > All proxies which want to provide services: > a) which operate *after* the INVITE has been routed and the > terminating > point in the SIP network found, > b) which require access to the full PSTN number, > c) on PSTN -> SIP-T -> PSTN calls, > d) which are delivered on overlap calls, and > e) which do not know the dial-plan well enough to identity > end-of-dialling themselves. > I think right now this is the empty set, so, yes, I can upgrade all > these :-) > Regards, > Mark Watson > Nortel Networks > > I still prefer a mechanism that do not require changes in > the existing > > > proxies (multiple call-legs). > > > > Best regards, > > > > Gonzalo > > > > > > > > Regards, > > > > > > Mark Watson > > > Nortel Networks > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: 07 February 2001 02:52 > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hi Tom, > > > > > > > > Still I want to have full state in every SIP message. If > > the call is > > > > > > > addresed to the phone number 1234, I want to have a to > field that > > > says > > > > 1234. I do not care if there is a leg routed thru the PSTN and > > > another > > > > thru SIP. > > > > > > > > Carrying full state is one of the beauties of SIP. If we > > begin using > > > > > > > INFO for this, it would be the same as using SAMs. > Differen names, > > > > the > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > believe that > > > > if the session has a destination, it should be present in the > > > > to field. > > > > > > > > Again, if a proxy is providing services for this > > particular call, it > > > > > > > will want to see the called party number in order to trigger > > > > the proper > > > > service. This is a very good reason for updating the to field > > > > every time > > > > we have more digits. > > > > > > > > I like to use SIP between two gateways because it is possible > > > > to provide > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > finding a > > > > egrees gateway, we would probably want to use other > > protocols (TRIP > > > & > > > > SIGTRAN for instance). > > > > > > > > Regards, > > > > > > > > Gonzalo > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > statements is > > > > > that an INVITE has reached a UAS which has accepted it. It > > > follows > > > > > that the UAS did not send back a 484, but rather an interim > > > > response. > > > > > IF more digits come along, the INFO method is there to > > carry them. > > > > > > > > They do not affect the SIP call state; they are used > beyond the > > > UAS, > > > > > either in a PSTN call or in another SIP call as the > case may be. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > signalling > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > additional > > > > > > > digits will not change call state. It is therefore > > > > > > reasonable to use > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > ISUP-SIP, once > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > reached, the same > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > vanilla SIP UA. > > > > > I > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > subsequent INFO > > > > > > carrying more digits will be discarded. Thus, the > PSTN to SIP > > > > > gateway > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > Therefore, it is > > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > > > Besides, I do not think that SIP is just a > transport protocol > > > that > > > > > > carries ISUP messages between two gateways. For > that, we have > > > > > already > > > > > > SIGTRAN. SIP might be used to provide services, > even when the > > > > > > call is a > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > state. And a > > > > > > SIP message with an incomplete to field does not > > carry complete > > > > > state. > > > > > > What if my SIP proxy provides a service for a > > PSTN-SIP-PSTN call > > > > > > > > based > > > > > > on the to field (called party number). That proxy would > > > > like to see > > > > > an > > > > > > updated to field, not just a to field that contains > just some > > > > > digits. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Christer Holmberg > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > To: Gonzalo Camarillo > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that > is what has > > > > > > > > been proposed > > > > > > > > earlier in this thread, so I assumed INFO would > > be used. The > > > > > > > > > > > reason for > > > > > > > > the discussion from the beginning was that the overlap > > > > > signalling, > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > very well, and > > > > > > > a > > > > > > > > solution using 18x responses and INFO messages, > instead of > > > > 484 > > > > > and > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has > been pretty > > > much > > > > > > > > about calls > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > SIP UAS > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | > -- INVITE > > > > > > > > > > > --> > > > > > > > > > > | <- 200 (INVITE)| <- 200 > > > ------ > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I > am not using > > > > > > > > > the word 'proxy') > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > overlap dialing, to > > > > > > > > > > be able to find the SIP UAS, and INFO is used > > to provide > > > > > > > > > > > the digits > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > > if you like) > > > > > > > > > > > be allowed to > > > > > > > > > > behave like this, or MUST it send 486s, and > > receive new > > > > > > > > INVITEs, until > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : > > > Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : > Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > _______________________________________________ > > > > This list is for continuing development of the SIP protocol. > > > > The sip-implementer's list is the place to discuss > implementation, > > > > > and to receive advice on understanding existing sip. > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > > "subscribe sip-implementors" in the body. > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > ------_=_NextPart_001_01C09627.95DA3350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Operlap dialing within a SIP network

This happens naturally: the VOIP PBX knows its = dialling plan and can tell if not enough digits have been = received.  By hypothesis, the outgoing gateway to the PSTN is = unable to tell if all needed digits have been received, but knows how = to route the call onward.

Christer raised the issue of how to handle the case = where an entity beyond the gateway determines that more digits are = needed.  I would suggest that it works the same as a pure PSTN = call: either the caller voluntarily provides more digits or the call = eventually times out and fails.

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@exchange.m= icrosoft.com]
> Sent: Tuesday, February 13, 2001 12:04 = PM
> To: Watson, Mark [MAIFP:EP11-M:EXCH]; Gonzalo = Camarillo
> Cc: Taylor, Tom-PT [NORSE:B901:EXCH]; Christer = Holmberg; sip
> Subject: RE: [SIP] Operlap dialing within a SIP = network
>
>
> The question is, how do we differentiate = between a PSTN gateway and an
> VoIP PBX. Both can take advantage of additional = digits; only
> one of them
> is capable of receiving ISUP. In the VoIP PBX = case, you would want the
> additional digits to be sent the "pure = SIP" way, i.e. through a
> re-invite.
>
> -- Christian Huitema
>
> -----Original Message-----
> From: Mark Watson [mailto:mwatson@nortelnetworks= .com]
> Sent: Tuesday, February 13, 2001 6:00 AM
> To: 'Gonzalo Camarillo'; Mark Watson
> Cc: Tom-PT Taylor; Christer Holmberg; = sip@lists.bell-labs.com
> Subject: RE: [SIP] Operlap dialing within a SIP = network
>
>
> Gonzalo,
> I'm not sure were completely understanding each = other here.
> I think we do agree that there is value in the = SIP-T concept, so that
> the PSTN can interwork with services provided = in the 'pure
> SIP' network
> by SIP proxy servers.
> I think that the path we're on of including = ISUP messages inside SIP
> messages is as good as any other for this, so I = don't see any value in
> pursuing alternatives, such as setting up a = SIGTRAN session
> for the ISUP
> signalling.
> I do not see the problem, though, with allowing = PSTN gateways
> to switch
> to a more efficient mode of overlap signalling = once the gateway out of
> the SIP network has been identified. Sure, = whilst the call is still
> progressing through the SIP network, and we = want to make use of the
> routing capabilities in the SIP network, we use = normal SIP procedures,
> but once we have hit the PSTN gateway, why not = optimise things ?
> <snip>
> > > 2) The UAC must use source routing to = ensure that all
> these INVITES
> > > make it to the same UAS
> >
> > What is the problem here? This is done in = order to address
> the problem
>
> > of proxies performing load balancing. Some = folks have
> pointed out that
>
> > maybe the betwork wants to route the = second INVITE in a
> > different way...
> > why the network would like to do that? The = policy that is
> > applicable to
> > the fist INVITE (that contained a prefix = of the number)
> should be the
> > same that applies to the subsequent ones. =
> Why ? How can you possibly know that all = services in all networks will
> work this way ? There are a host of reasons why = routing of the INVITE
> might vary due to factors other than the = digits. INVITES for the *same
> digits* might route differently, and not just = due to load balancing.
> <snip>
> > > The price we pay for this is that = intermediate proxies
> may not have
> > > access to the full Called Party = Number - but a proxy that
> > needs this,
> > > that wants to offer service on = overlap calls, can always
> sniff the
> > > overlap digits as they go past. =
> >
> > Let me get this straight. Are you are = proposing to change
> the logic in
>
> > all the already existing proxies because = you want to
> provide services
> > when you use INFO for carrying SAMs? This = is just impossible.
> >
> All proxies which want to provide services: =
> a) which operate *after* the INVITE has been = routed and the
> terminating
> point in the SIP network found,
> b) which require access to the full PSTN = number,
> c) on PSTN -> SIP-T -> PSTN calls, =
> d) which are delivered on overlap calls, and =
> e) which do not know the dial-plan well enough = to identity
> end-of-dialling themselves.
> I think right now this is the empty set, so, = yes, I can upgrade all
> these :-)
> Regards,
> Mark Watson
> Nortel Networks
> > I still prefer a mechanism that do not = require changes in
> the existing
>
> > proxies (multiple call-legs).
> >
> > Best regards,
> >
> > Gonzalo
> >
> > >
> > > Regards,
> > >
> > > Mark Watson
> > > Nortel Networks
> > >
> > > > -----Original Message----- =
> > > > From: Gonzalo Camarillo
> [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
>
> > > > Sent: 07 February 2001 02:52 =
> > > > To: Taylor, Tom-PT = [NORSE:B901:EXCH]
> > > > Cc: Christer Holmberg; = sip@lists.bell-labs.com
> > > > Subject: Re: [SIP] Operlap = dialing within a SIP network
> > > >
> > > >
> > > > Hi Tom,
> > > >
> > > > Still I want to have full state = in every SIP message. If
> > the call is
> > >
> > > > addresed to the phone number = 1234, I want to have a to
> field that
> > > says
> > > > 1234. I do not care if there is = a leg routed thru the PSTN and
> > > another
> > > > thru SIP.
> > > >
> > > > Carrying full state is one of = the beauties of SIP. If we
> > begin using
> > >
> > > > INFO for this, it would be the = same as using SAMs.
> Differen names,
>
> > > the
> > > > same thing... I do not want to = re-create ISUP using SIP. I
> > > > believe that
> > > > if the session has a = destination, it should be present in the
> > > > to field.
> > > >
> > > > Again, if a proxy is providing = services for this
> > particular call, it
> > >
> > > > will want to see the called = party number in order to trigger
> > > > the proper
> > > > service. This is a very good = reason for updating the to field
> > > > every time
> > > > we have more digits.
> > > >
> > > > I like to use SIP between two = gateways because it is possible
> > > > to provide
> > > > SIP services for a PSTN to PSTN = call. If all we want to do is
> > > > finding a
> > > > egrees gateway, we would = probably want to use other
> > protocols (TRIP
> > > &
> > > > SIGTRAN for instance).
> > > >
> > > > Regards,
> > > >
> > > > Gonzalo
> > > >
> > > > Tom-PT Taylor wrote:
> > > > >
> > > > > Sorry, we're talking past = each other.  The premise of my
> > > > statements is
> > > > > that an INVITE has reached = a UAS which has accepted it.  It
> > > follows
> > > > > that the UAS did not send = back a 484, but rather an interim
> > > > response.
> > > > > IF more digits come along, = the INFO method is there to
> > carry them.
> > >
> > > > > They do not affect the SIP = call state; they are used
> beyond the
> > > UAS,
> > > > > either in a PSTN call or in = another SIP call as the
> case may be.
>
> > > > >
> > > > > > -----Original = Message-----
> > > > > > From: Gonzalo = Camarillo
> > > [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > > > > Sent: Tuesday, = February 06, 2001 9:10 PM
> > > > > > To: Taylor, Tom-PT = [NORSE:B901:EXCH]
> > > > > > Cc: Christer Holmberg; = sip@lists.bell-labs.com
> > > > > > Subject: Re: [SIP] = Operlap dialing within a SIP network
> > > > > >
> > > > > >
> > > > > > Hello Tom,
> > > > > >
> > > > > > Tom-PT Taylor wrote: =
> > > > > > >
> > > > > > > Just to re-hash, = in the ISUP-SIP-ISUP context, once call
> > > > > signalling
> > > > > > > has reached an = egress gateway, SIP has done its job --
> > > > additional
> > > > > > > digits will not = change call state.  It is therefore
> > > > > > reasonable to use =
> > > > > > > INFO to carry the = additional digits.  If we are talking
> > > > > > ISUP-SIP, once
> > > > > > > the destination = UAS or a UAS in a B2BUA has been
> > > > reached, the same
> > > > >
> > > > > > > consideration = applies.
> > > > > > >
> > > > > >
> > > > > > I do not agree with = these two statements:
> > > > > >
> > > > > > The 1st INVITE (with = just some digits) arrives to a
> > > > vanilla SIP UA.
> > > > > I
> > > > > > will return a Not = Found or a 484 Address incomplete. The
> > > > > > subsequent INFO =
> > > > > > carrying more digits = will be discarded. Thus, the
> PSTN to SIP
> > > > > gateway
> > > > > > will have to re issue = a new INVITE with all the digits.
> > > > > > Therefore, it is =
> > > > > > better to begin = directly using er-INVITEs rather than INFO.
> > > > > >
> > > > > > Besides, I do not = think that SIP is just a
> transport protocol
> > > that
> > > > > > carries ISUP messages = between two gateways. For
> that, we have
> > > > > already
> > > > > > SIGTRAN. SIP might be = used to provide services,
> even when the
> > > > > > call is a
> > > > > > PSTN-SIP-PSTN call. = Thus, SIP messages MUST carry complete
> > > > > > state. And a
> > > > > > SIP message with an = incomplete to field does not
> > carry complete
> > > > > state.
> > > > > > What if my SIP proxy = provides a service for a
> > PSTN-SIP-PSTN call
> > >
> > > > > based
> > > > > > on the to field = (called party number). That proxy would
> > > > like to see
> > > > > an
> > > > > > updated to field, not = just a to field that contains
> just some
> > > > > digits.
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Gonzalo
> > > > > >
> > > > > >
> > > > > > > > = -----Original Message-----
> > > > > > > > From: = Christer Holmberg
> > > > > [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > > > > > > > Sent: = Tuesday, February 06, 2001 1:15 AM
> > > > > > > > To: Gonzalo = Camarillo
> > > > > > > > Cc: = sip@lists.bell-labs.com
> > > > > > > > Subject: Re: = [SIP] Operlap dialing within a SIP network
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Gonzalo, =
> > > > > > > >
> > > > > > > > I didn't say = I am going to use INFO, but that
> is what has
> > > > > > > > been = proposed
> > > > > > > > earlier in = this thread, so I assumed INFO would
> > be used. The
> > >
> > > > > > > > reason for =
> > > > > > > > the = discussion from the beginning was that the overlap
> > > > > signalling,
> > > > > > > > according to = the SIP-ISUP mapping draft, may not work
> > > > > > very well, and
> > > > > > > a
> > > > > > > > solution = using 18x responses and INFO messages,
> instead of
>
> > > 484
> > > > > and
> > > > > > > > re-INVITEs, = was proposed.
> > > > > > > >
> > > > > > > > Regards, =
> > > > > > > >
> > > > > > > > Christer = Holmberg
> > > > > > > > Ericsson = Finland
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Gonzalo = Camarillo wrote:
> > > > > > > > >
> > > > > > > > > Hello = Christer,
> > > > > > > > >
> > > > > > > > > Why are = you using INFO for sending extra digits?
> > > > > > > > >
> > > > > > > > > Please, = check the SIP-ISUP mapping draft, overlap
> > > > > > > > signalling = section.
> > > > > > > > >
> > > > > > > > > = Regards,
> > > > > > > > >
> > > > > > > > > Gonzalo =
> > > > > > > > >
> > > > > > > > > = Christer Holmberg wrote:
> > > > > > > > > > =
> > > > > > > > > > = Hi,
> > > > > > > > > > =
> > > > > > > > > > = The discussion about overlap dialing has
> been pretty
> > > much
> > > > > > > > about calls =
> > > > > > > > > > = from SIP to PSTN, or PSTN-SIP-PSTN.
> > > > > > > > > > =
> > > > > > > > > > = Consider the following scenario.
> > > > > > > > > > =
> > > > > > > > > > = PSTN = PHONE           &= nbsp; GW           = SIP SERVER
> > > >   SIP UAS
> > > > > > > > > > =
> > > > = -----------------------------------------------------------
> > > > > > > > > > =
> > > > > > > > > > = --- 1 --->    -- IAM -> | -- INVITE -->  | =
> > > > > > > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > > > > = --- 2 --->    -- SAM -> | -- INFO ---->  | =
> > > > > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |
> > > > > > > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > > > > = --- 3 --->    -- SAM -> | -- INFO ---->  | =
> > > > > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  | 
>  -- INVITE
>
> > > > > > > > > > = -->
> > > > > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INVITE)|   <- 200
> > > ------
> > > > > > > > > > =
> > > > > > > > > > In = this case, the SIP server (note that I
> am not using
>
> > > > > > > > the word = 'proxy')
> > > > > > > > > > = must collect digits, sent from the PSTN side using
> > > > > > > > overlap = dialing, to
> > > > > > > > > > be = able to find the SIP UAS, and INFO is used
> > to provide
> > >
> > > > > > > > the digits =
> > > > > > > > > > = after the INVITE has been sent.
> > > > > > > > > > =
> > > > > > > > > > My = question is, should a SIP server (proxy,
> > if you like)
> > >
> > > > > > > > be allowed = to
> > > > > > > > > > = behave like this, or MUST it send 486s, and
> > receive new
> > > > > > > > INVITEs, = until
> > > > > > > > > > it = is able to find the UAS?
> > > > > > > > > > =
> > > > > > > > > > = Regards,
> > > > > > > > > > =
> > > > > > > > > > = Christer Holmberg
> > > > > > > > > > = Ericsson Finland
> > > > > > > > >
> > > > > > > > > -- =
> > > > > > > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > > > > > > Oy L M = Ericsson Ab        Mobile:  = +358 40 702 35 35
> > > > > > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 52 =
> > > > > > > > > = FIN-02420 Jorvas          = Email :
> > > > > > = Gonzalo.Camarillo@ericsson.com
> > > > > > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 52 =
> > > > > > FIN-02420 = Jorvas          Email : =
> > > Gonzalo.Camarillo@ericsson.com =
> > > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > > >
> > > >
> > > > --
> > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 52 =
> > > > FIN-02420 = Jorvas          Email = : 
> Gonzalo.Camarillo@ericsson.com
> > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > >
> > > > = _______________________________________________
> > > > This list is for continuing = development of the SIP protocol.
> > > > The sip-implementer's list is = the place to discuss
> implementation,
>
> > > > and to receive advice on = understanding existing sip.
> > > > To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> > > > "subscribe = sip-implementors" in the body.
> > > >
> >
> > --
> > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > Telecom = R&D           = ;    Fax   :  +358  9 299 30 52 =
> > FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> > = Finland           = ;        http://www.hut.fi/~gonzalo
> >
>

------_=_NextPart_001_01C09627.95DA3350-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 14 01:14:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11525 for ; Wed, 14 Feb 2001 01:14:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB4EC44337; Wed, 14 Feb 2001 01:14:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id AE1E944336 for ; Wed, 14 Feb 2001 01:13:42 -0500 (EST) 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 f1E6Bod22335; Wed, 14 Feb 2001 07:11:50 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA08733; Wed, 14 Feb 2001 08:11:49 +0200 (EET) Message-ID: <3A8A219F.B49B4514@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip Cc: Tom-PT Taylor , "'Christian Huitema'" , Mark Watson , Gonzalo Camarillo Subject: Re: [SIP] Operlap dialing within a SIP network References: <28560036253BD41191A10000F8BCBD110250C6E1@zcard00g.ca.nortel.com> Content-Type: multipart/mixed; boundary="------------A653A77DD8F59AAAC6A0A47E" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 14 Feb 2001 08:11:43 +0200 This is a multi-part message in MIME format. --------------A653A77DD8F59AAAC6A0A47E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >This happens naturally: the VOIP PBX knows its dialling plan and can >tell if not enough digits have been received. By hypothesis, the >outgoing gateway to the PSTN is unable to tell if all needed digits >have been received, but knows how to route the call onward. > >Christer raised the issue of how to handle the case where an entity >beyond the gateway determines that more digits are needed. I would >suggest that it works the same as a pure PSTN call: either the caller >voluntarily provides more digits or the call eventually times out and >fails. That is the way it must work, because the entity beyond the gateway can not tell the gateway to send a 484 response to ask for more digits. And, at the end, what I mentioned before, if the sending gateway receives more digits, nothing stops it from sending re-INVITES - no matter if a 484 has been received for the previous INVITE or not. Regards, Christer Holmberg Ericsson Finland > > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > > Sent: Tuesday, February 13, 2001 12:04 PM > > To: Watson, Mark [MAIFP:EP11-M:EXCH]; Gonzalo Camarillo > > Cc: Taylor, Tom-PT [NORSE:B901:EXCH]; Christer Holmberg; sip > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > > > The question is, how do we differentiate between a PSTN gateway and > an > > VoIP PBX. Both can take advantage of additional digits; only > > one of them > > is capable of receiving ISUP. In the VoIP PBX case, you would want > the > > additional digits to be sent the "pure SIP" way, i.e. through a > > re-invite. > > > > -- Christian Huitema > > > > -----Original Message----- > > From: Mark Watson [mailto:mwatson@nortelnetworks.com] > > Sent: Tuesday, February 13, 2001 6:00 AM > > To: 'Gonzalo Camarillo'; Mark Watson > > Cc: Tom-PT Taylor; Christer Holmberg; sip@lists.bell-labs.com > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > > > Gonzalo, > > I'm not sure were completely understanding each other here. > > I think we do agree that there is value in the SIP-T concept, so > that > > the PSTN can interwork with services provided in the 'pure > > SIP' network > > by SIP proxy servers. > > I think that the path we're on of including ISUP messages inside SIP > > > messages is as good as any other for this, so I don't see any value > in > > pursuing alternatives, such as setting up a SIGTRAN session > > for the ISUP > > signalling. > > I do not see the problem, though, with allowing PSTN gateways > > to switch > > to a more efficient mode of overlap signalling once the gateway out > of > > the SIP network has been identified. Sure, whilst the call is still > > progressing through the SIP network, and we want to make use of the > > routing capabilities in the SIP network, we use normal SIP > procedures, > > but once we have hit the PSTN gateway, why not optimise things ? > > > > > > 2) The UAC must use source routing to ensure that all > > these INVITES > > > > make it to the same UAS > > > > > > What is the problem here? This is done in order to address > > the problem > > > > > of proxies performing load balancing. Some folks have > > pointed out that > > > > > maybe the betwork wants to route the second INVITE in a > > > different way... > > > why the network would like to do that? The policy that is > > > applicable to > > > the fist INVITE (that contained a prefix of the number) > > should be the > > > same that applies to the subsequent ones. > > Why ? How can you possibly know that all services in all networks > will > > work this way ? There are a host of reasons why routing of the > INVITE > > might vary due to factors other than the digits. INVITES for the > *same > > digits* might route differently, and not just due to load balancing. > > > > > > > The price we pay for this is that intermediate proxies > > may not have > > > > access to the full Called Party Number - but a proxy that > > > needs this, > > > > that wants to offer service on overlap calls, can always > > sniff the > > > > overlap digits as they go past. > > > > > > Let me get this straight. Are you are proposing to change > > the logic in > > > > > all the already existing proxies because you want to > > provide services > > > when you use INFO for carrying SAMs? This is just impossible. > > > > > All proxies which want to provide services: > > a) which operate *after* the INVITE has been routed and the > > terminating > > point in the SIP network found, > > b) which require access to the full PSTN number, > > c) on PSTN -> SIP-T -> PSTN calls, > > d) which are delivered on overlap calls, and > > e) which do not know the dial-plan well enough to identity > > end-of-dialling themselves. > > I think right now this is the empty set, so, yes, I can upgrade all > > these :-) > > Regards, > > Mark Watson > > Nortel Networks > > > I still prefer a mechanism that do not require changes in > > the existing > > > > > proxies (multiple call-legs). > > > > > > Best regards, > > > > > > Gonzalo > > > > > > > > > > > Regards, > > > > > > > > Mark Watson > > > > Nortel Networks > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > > Sent: 07 February 2001 02:52 > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > Still I want to have full state in every SIP message. If > > > the call is > > > > > > > > > addresed to the phone number 1234, I want to have a to > > field that > > > > says > > > > > 1234. I do not care if there is a leg routed thru the PSTN and > > > > > another > > > > > thru SIP. > > > > > > > > > > Carrying full state is one of the beauties of SIP. If we > > > begin using > > > > > > > > > INFO for this, it would be the same as using SAMs. > > Differen names, > > > > > > the > > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > > believe that > > > > > if the session has a destination, it should be present in the > > > > > to field. > > > > > > > > > > Again, if a proxy is providing services for this > > > particular call, it > > > > > > > > > will want to see the called party number in order to trigger > > > > > the proper > > > > > service. This is a very good reason for updating the to field > > > > > every time > > > > > we have more digits. > > > > > > > > > > I like to use SIP between two gateways because it is possible > > > > > to provide > > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > > finding a > > > > > egrees gateway, we would probably want to use other > > > protocols (TRIP > > > > & > > > > > SIGTRAN for instance). > > > > > > > > > > Regards, > > > > > > > > > > Gonzalo > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > > statements is > > > > > > that an INVITE has reached a UAS which has accepted it. It > > > > follows > > > > > > that the UAS did not send back a 484, but rather an interim > > > > > response. > > > > > > IF more digits come along, the INFO method is there to > > > carry them. > > > > > > > > > > They do not affect the SIP call state; they are used > > beyond the > > > > UAS, > > > > > > either in a PSTN call or in another SIP call as the > > case may be. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gonzalo Camarillo > > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > > > signalling > > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > > additional > > > > > > > > digits will not change call state. It is therefore > > > > > > > reasonable to use > > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > > ISUP-SIP, once > > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > > reached, the same > > > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > > vanilla SIP UA. > > > > > > I > > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > > subsequent INFO > > > > > > > carrying more digits will be discarded. Thus, the > > PSTN to SIP > > > > > > gateway > > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > > Therefore, it is > > > > > > > better to begin directly using er-INVITEs rather than > INFO. > > > > > > > > > > > > > > Besides, I do not think that SIP is just a > > transport protocol > > > > that > > > > > > > carries ISUP messages between two gateways. For > > that, we have > > > > > > already > > > > > > > SIGTRAN. SIP might be used to provide services, > > even when the > > > > > > > call is a > > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > > > state. And a > > > > > > > SIP message with an incomplete to field does not > > > carry complete > > > > > > state. > > > > > > > What if my SIP proxy provides a service for a > > > PSTN-SIP-PSTN call > > > > > > > > > > based > > > > > > > on the to field (called party number). That proxy would > > > > > like to see > > > > > > an > > > > > > > updated to field, not just a to field that contains > > just some > > > > > > digits. > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Christer Holmberg > > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > > To: Gonzalo Camarillo > > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP > network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that > > is what has > > > > > > > > > been proposed > > > > > > > > > earlier in this thread, so I assumed INFO would > > > be used. The > > > > > > > > > > > > > reason for > > > > > > > > > the discussion from the beginning was that the overlap > > > > > > > signalling, > > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > > very well, and > > > > > > > > a > > > > > > > > > solution using 18x responses and INFO messages, > > instead of > > > > > > 484 > > > > > > and > > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has > > been pretty > > > > much > > > > > > > > > about calls > > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > > SIP UAS > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > | <- 200 (INFO) | > > -- INVITE > > > > > > > > > > > > > --> > > > > > > > > > > > | <- 200 (INVITE)| <- > 200 > > > > ------ > > > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I > > am not using > > > > > > > > > > > the word 'proxy') > > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > > > overlap dialing, to > > > > > > > > > > > be able to find the SIP UAS, and INFO is used > > > to provide > > > > > > > > > > > > > the digits > > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > > > if you like) > > > > > > > > > > > > > be allowed to > > > > > > > > > > > behave like this, or MUST it send 486s, and > > > receive new > > > > > > > > > INVITEs, until > > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > FIN-02420 Jorvas Email : > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : > > Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > _______________________________________________ > > > > > This list is for continuing development of the SIP protocol. > > > > > The sip-implementer's list is the place to discuss > > implementation, > > > > > > > and to receive advice on understanding existing sip. > > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu > with > > > > > "subscribe sip-implementors" in the body. > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > --------------A653A77DD8F59AAAC6A0A47E 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 --------------A653A77DD8F59AAAC6A0A47E-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 14 01:43:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15091 for ; Wed, 14 Feb 2001 01:43:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 317A144348; Wed, 14 Feb 2001 01:43:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 3B88C44336 for ; Wed, 14 Feb 2001 01:42:39 -0500 (EST) 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 f1E6fHC27283; Wed, 14 Feb 2001 07:41:17 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA10263; Wed, 14 Feb 2001 08:41:16 +0200 (EET) Message-ID: <3A8A2886.11E1BF91@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Gonzalo Camarillo , Mark Watson , Tom-PT Taylor Subject: Re: [SIP] Operlap dialing within a SIP network References: <3A896DEA.C38464C8@lmf.ericsson.se> <3A89B31C.FF1147E1@lmf.ericsson.se> Content-Type: multipart/mixed; boundary="------------8B84B65575FFF4C27F47F723" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 14 Feb 2001 08:41:10 +0200 This is a multi-part message in MIME format. --------------8B84B65575FFF4C27F47F723 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gonzalo, My mail was not yet another proposal for using INFO, I simply tried to define how we could "optimize" our system by using re-INVITEs and by not using re-INVITEs. >This thread has already too many messages, and folks seem to respond >without taking into consideration previous answers: > >>2. The logic in the UAS GW would be more simple, because it would not >>need to compare the Request-URI in the re-INVITEs with the Request-URI >>in the previous INVITE, to generate the correct SAM messages (using >>INFO, you just send the new digits, and the GW generate SAMs of them). > >AS I said before, INFO does not ensure ordered delibery. So, if you do >what you are just describing, it will NOT work. You will get an INFO >with a SAM before the previous INFO with the previous SAM arrives... you >will just shuffle the digits of the number... BAD IDEA. Well, sending re-INVITEs doesn't ensure you more ordered delivery either. Yes, the difference is that in the INVITE you will always receive ALL digits, not only the new-ones, so that solves that issue. >However, you might argue that you will use a new request-URI. Well, this >is not standard SIP again. You could have a separate header in the INFO with ALL digits, but then the digit processing in the UAS GW probably would not be more simple than by using re-INVITEs, so I agree that you will not optimize in that sense by using INFO :) >You should honor the contact header you have received, and not modify it >on your own... again, you are thinking just about gateways. What Contact header would I get in the 484 anyway??? The responding gateway doesn't know which the new digits are going to be. I can only get the host part in the Contact, and that is going to be the same no matter which method I use. E.g., assume I send an INVITE to 123@mgw.com, and receive a 484. The UAC gateway has now received more digits, 456, so I send a new INVITE to 123456@mgw.com. The UAS gateway, however, didn't know that I was going to use that Request-URI, so it couldn't have put those extra digits in the user part of the Contact header in the 484 response. And, if I send the re-INVITE before I get the response to the previous INVITE, OR I don't get a response at all because the UAS gateway has received enough digits to route the call to the next PSTN entity, the UAC gateway will not even get a Contact header before it sends the next re-INVITE. AND, according to the draft the Contact header in a 484 response is used ONLY to indicate where more info about the error can be found, not where to send the next request... Regards, Christer Holmberg Ericsson Finland > > I would like you to think about normal clients, APS, etc... then, you > will see that instead of simplifying your gateways, you are adding > complexity, because you will have to implement standard SIP to interwork > with vanilla UAs and your SIP-T with INFOs to interwork with other > gateways. > > Best regards, > > Gonzalo > > > > 3. If (again, this has nothing to do with the overlap procedure itself) > > you have SDP body, and an encapsulated ISUP body (or any other > > message-body), in the INVITE, you must send it in every re-INVITE also > > (if you receive 484 you would probably always do so, but you may also > > send your re-INVITE before you get a response, and/or a proxy may > > suddenly re-route the INVITE to another GW, which needs the ISUP body). > > > > The advantage of using re-INVITEs, however, are: > > > > 1. You can easier access services in the SIP network > > > > 2. The GW UAC have to wait for a non-484 response for your INVITEs > > before you start using INFO, instead you can send your re-INVITEs as > > soon as you receive a SAM from ISUP. It has been discussed that the GW > > UAS would send some kind of provisional response when it has received > > enough digits to route the call forward. So, until you get that > > provisional response you will have to wait for the response to every > > INVITE you send before you can send the next INVITE, which may include > > buffering of SAMs in your GW UAC, and that is NOT to optimize. > > > > 3. If TRANSACTION overlaping for INFO is not allowed you would also have > > to wait for the response to every INFO you send before you can send the > > next one, since they belong to the same call-leg (the re-INVITEs are all > > different legs, so you don't have transaction overlaping there). > > > > 4. You can re-route the call setup to another MGC at any time (the > > disadvantage is, like I mentioned, that you have to include your message > > bodies, ISUP etc, in every INVITE), since every INVITE will have all > > digits in the Request-URI. The new GW UAS would then simply handle the > > INVITE as an initial INVITE. Yes, the proxy re-routing the call would > > probably also have to CANCEL to old leg (if a 484 was not received, > > which would happend if the GW managed to route the call forward in the > > PSTN network). With INFO that would not be possible. First, the proxy > > would have to "transfer" the INFO into an INVITE, but that would not > > help because the UAC still has an ongoing INVITE transaction, and does > > not want a response to an INFO method it never even sent. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > Mark Watson wrote: > > > > > > Gonzalo, > > > > > > I'm not sure were completely understanding each other here. > > > > > > I think we do agree that there is value in the SIP-T concept, so that > > > the PSTN can interwork with services provided in the 'pure SIP' > > > network by SIP proxy servers. > > > > > > I think that the path we're on of including ISUP messages inside SIP > > > messages is as good as any other for this, so I don't see any value in > > > pursuing alternatives, such as setting up a SIGTRAN session for the > > > ISUP signalling. > > > > > > I do not see the problem, though, with allowing PSTN gateways to > > > switch to a more efficient mode of overlap signalling once the gateway > > > out of the SIP network has been identified. Sure, whilst the call is > > > still progressing through the SIP network, and we want to make use of > > > the routing capabilities in the SIP network, we use normal SIP > > > procedures, but once we have hit the PSTN gateway, why not optimise > > > things ? > > > > > > > > > > > > > > 2) The UAC must use source routing to ensure that all these > > > INVITES > > > > > make it to the same UAS > > > > > > > > What is the problem here? This is done in order to address the > > > problem > > > > of proxies performing load balancing. Some folks have pointed out > > > that > > > > maybe the betwork wants to route the second INVITE in a > > > > different way... > > > > why the network would like to do that? The policy that is > > > > applicable to > > > > the fist INVITE (that contained a prefix of the number) should be > > > the > > > > same that applies to the subsequent ones. > > > > > > Why ? How can you possibly know that all services in all networks will > > > work this way ? There are a host of reasons why routing of the INVITE > > > might vary due to factors other than the digits. INVITES for the *same > > > digits* might route differently, and not just due to load balancing. > > > > > > > > > > > > > > The price we pay for this is that intermediate proxies may not > > > have > > > > > access to the full Called Party Number - but a proxy that > > > > needs this, > > > > > that wants to offer service on overlap calls, can always sniff the > > > > > > > > overlap digits as they go past. > > > > > > > > Let me get this straight. Are you are proposing to change the logic > > > in > > > > all the already existing proxies because you want to provide > > > services > > > > when you use INFO for carrying SAMs? This is just impossible. > > > > > > > > > > All proxies which want to provide services: > > > a) which operate *after* the INVITE has been routed and the > > > terminating point in the SIP network found, > > > b) which require access to the full PSTN number, > > > c) on PSTN -> SIP-T -> PSTN calls, > > > d) which are delivered on overlap calls, and > > > e) which do not know the dial-plan well enough to identity > > > end-of-dialling themselves. > > > > > > I think right now this is the empty set, so, yes, I can upgrade all > > > these :-) > > > > > > Regards, > > > > > > Mark Watson > > > Nortel Networks > > > > > > > I still prefer a mechanism that do not require changes in the > > > existing > > > > proxies (multiple call-legs). > > > > > > > > Best regards, > > > > > > > > Gonzalo > > > > > > > > > > > > > > Regards, > > > > > > > > > > Mark Watson > > > > > Nortel Networks > > > > > > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > Sent: 07 February 2001 02:52 > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > Still I want to have full state in every SIP message. If > > > > the call is > > > > > > > > > > > addresed to the phone number 1234, I want to have a to field > > > that > > > > > says > > > > > > 1234. I do not care if there is a leg routed thru the PSTN and > > > > > another > > > > > > thru SIP. > > > > > > > > > > > > Carrying full state is one of the beauties of SIP. If we > > > > begin using > > > > > > > > > > > INFO for this, it would be the same as using SAMs. Differen > > > names, > > > > > the > > > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > > > believe that > > > > > > if the session has a destination, it should be present in the > > > > > > to field. > > > > > > > > > > > > Again, if a proxy is providing services for this > > > > particular call, it > > > > > > > > > > > will want to see the called party number in order to trigger > > > > > > the proper > > > > > > service. This is a very good reason for updating the to field > > > > > > every time > > > > > > we have more digits. > > > > > > > > > > > > I like to use SIP between two gateways because it is possible > > > > > > to provide > > > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > > > finding a > > > > > > egrees gateway, we would probably want to use other > > > > protocols (TRIP > > > > > & > > > > > > SIGTRAN for instance). > > > > > > > > > > > > Regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > > > statements is > > > > > > > that an INVITE has reached a UAS which has accepted it. It > > > > > follows > > > > > > > that the UAS did not send back a 484, but rather an interim > > > > > > response. > > > > > > > IF more digits come along, the INFO method is there to > > > > carry them. > > > > > > > > > > > > They do not affect the SIP call state; they are used beyond > > > the > > > > > UAS, > > > > > > > either in a PSTN call or in another SIP call as the case may > > > be. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Gonzalo Camarillo > > > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > > > signalling > > > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > > > additional > > > > > > > > > digits will not change call state. It is therefore > > > > > > > > reasonable to use > > > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > > > ISUP-SIP, once > > > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > > > reached, the same > > > > > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > > > vanilla SIP UA. > > > > > > > I > > > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > > > subsequent INFO > > > > > > > > carrying more digits will be discarded. Thus, the PSTN to > > > SIP > > > > > > > gateway > > > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > > > Therefore, it is > > > > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > > > > > > > Besides, I do not think that SIP is just a transport > > > protocol > > > > > that > > > > > > > > carries ISUP messages between two gateways. For that, we > > > have > > > > > > > already > > > > > > > > SIGTRAN. SIP might be used to provide services, even when > > > the > > > > > > > > call is a > > > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > > > state. And a > > > > > > > > SIP message with an incomplete to field does not > > > > carry complete > > > > > > > state. > > > > > > > > What if my SIP proxy provides a service for a > > > > PSTN-SIP-PSTN call > > > > > > > > > > > > based > > > > > > > > on the to field (called party number). That proxy would > > > > > > like to see > > > > > > > an > > > > > > > > updated to field, not just a to field that contains just > > > some > > > > > > > digits. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Christer Holmberg > > > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > > > To: Gonzalo Camarillo > > > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what > > > has > > > > > > > > > > been proposed > > > > > > > > > > earlier in this thread, so I assumed INFO would > > > > be used. The > > > > > > > > > > > > > > > reason for > > > > > > > > > > the discussion from the beginning was that the overlap > > > > > > > signalling, > > > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > > > very well, and > > > > > > > > > a > > > > > > > > > > solution using 18x responses and INFO messages, instead > > > of > > > > > 484 > > > > > > > and > > > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty > > > > > > > > much > > > > > > > > > > about calls > > > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > > > SIP UAS > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > > | <- 200 (INFO) | -- > > > INVITE > > > > > > > > > > > > --> > > > > > > > > > > > > | <- 200 (INVITE)| <- 200 > > > > > ------ > > > > > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not > > > using > > > > > > > > > > the word 'proxy') > > > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > > > overlap dialing, to > > > > > > > > > > > > be able to find the SIP UAS, and INFO is used > > > > to provide > > > > > > > > > > > > > > > the digits > > > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > > > > if you like) > > > > > > > > > > > > > > > be allowed to > > > > > > > > > > > > behave like this, or MUST it send 486s, and > > > > receive new > > > > > > > > > > INVITEs, until > > > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > FIN-02420 Jorvas Email : > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : > > > Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > _______________________________________________ > > > > > > This list is for continuing development of the SIP protocol. > > > > > > The sip-implementer's list is the place to discuss > > > implementation, > > > > > > and to receive advice on understanding existing sip. > > > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > > > > "subscribe sip-implementors" in the body. > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > -- > Gonzalo Camarillo Phone : +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 --------------8B84B65575FFF4C27F47F723 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 --------------8B84B65575FFF4C27F47F723-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 14 02:57:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24663 for ; Wed, 14 Feb 2001 02:57:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1563844337; Wed, 14 Feb 2001 02:57:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id A9A6C44336 for ; Wed, 14 Feb 2001 02:56:51 -0500 (EST) 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 f1E7uod27791 for ; Wed, 14 Feb 2001 08:56:50 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA15445 for ; Wed, 14 Feb 2001 09:56:48 +0200 (EET) Message-ID: <3A8A3A3A.6702BBEB@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] I-D ACTION:draft-ietf-sip-serverfeatures-03.txt References: <200102131201.HAA15663@ietf.org> Content-Type: multipart/mixed; boundary="------------A7ED0A7C47409FDFD0A01FE1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 14 Feb 2001 09:56:42 +0200 This is a multi-part message in MIME format. --------------A7ED0A7C47409FDFD0A01FE1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have an issue, which I don't know if it has has been discussed before, but at least it is not mentioned in the draft. The draft says that the UAC shall insert all supported option-tags in the Supported header, that the UAS can send a 421 response etc etc etc. I think it should be allowed also for a proxy server on the path to insert it's own option tags in the request, and then handle the feature correctly if the UAS chooses to use it. This is similar to the session-timer, where a proxy can choose to use the feature even if the UAC doesn't. I also think it should be allowed for a proxy server an option tag from the Supported header (for example, it may want the next entity not to require it to be used), but still be able to require it for the entity from where it received the request. An example: ------- ----------- ----------- ------- | UAC |----------| PROXY 1 |----------| PROXY 2 |----------| UAS | ------- ----------- ----------- ------- --> INVITE --> INVITE --> INVITE Supported: a Supported: a,b Supported: a <-- 200 <-- 200 <-- 200 Require: b In this case "b" could be some advanced feature/service, which the User-Agents may not be able to handle (or maybe aren't even allowed to, e.g. for security/billing/management/operator/whatever reasons), but the proxies will use it between themselves. I mean, isn't this one of the purposes of proxy servers in the first place: not only to provide services to the end-users but also within the SIP network? No, the draft may not say that all this is forbidden (after all, a proxy also acts like both a UAC and a UAS, so...), but maybe by clarifying it people would realise how useful the Supported header can be for services, re-routing, and the use of proxies in general. And, the same thing should also be allowed for the Require- and Proxy-Require headers... After all, in a real-world deployment I think that it is going often to be pretty much the operator, managing the proxy servers in the network, who is going to decide what users are allowed to require, and/or show support for, from each other. Regards, Christer Holmberg Ericsson Finland --------------A7ED0A7C47409FDFD0A01FE1 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 --------------A7ED0A7C47409FDFD0A01FE1-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 14 05:11:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25552 for ; Wed, 14 Feb 2001 05:11:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94ADC44337; Wed, 14 Feb 2001 05:11:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60]) by lists.bell-labs.com (Postfix) with ESMTP id E6AEF44336 for ; Wed, 14 Feb 2001 05:10:01 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 14 Feb 2001 10:09:59 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id KAA18027; Wed, 14 Feb 2001 10:09:57 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569F3.0037A7D5 ; Wed, 14 Feb 2001 10:07:54 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Gonzalo Camarillo Cc: Jonathan Rosenberg , "'Tom-PT Taylor'" , Christer Holmberg , sip@lists.bell-labs.com Message-ID: <802569F3.00377A7A.00@marconicomms.com> Subject: Re: [SIP] Operlap dialing within a SIP network Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 14 Feb 2001 10:00:24 +0000 Gonzalo, It seems you have two main reasons against the use of the INFO method for the conveyance of subsequent ISUP information: 1) Lack of ordered delivery of the INFO messages Ordered delivery could be maintained by the UAC not sending the next INFO until a 200 OK response for the previous one had been received. 2) Lack of state carried in the INFO messge The digits received so far could be carried in a header within the INFO message. Each INFO message would then carry the same information as a re-INVITE. My reason for exploring the use of INFO is not to save on messages. It is to do with the issue of source routing. Again, my concern of source routing is not one of a technical nature. What if an administration has a security policy that states source routing (a ROUTE header in an initial INVITE) will not take place in its SIP network but it also requires that the same network interworks with the PSTN; if any part of the PSTN interworking mechanism relies on source routing then there is a conflict of requirements. It is this conflict I wish to address. Regards, K. Robinson. Gonzalo Camarillo on 01/01/88 00:39:14 To: Jonathan Rosenberg cc: "'Tom-PT Taylor'" , Christer Holmberg , sip@lists.bell-labs.com(bcc: Keith Robinson/MAIN/MC1) Subject: Re: [SIP] Operlap dialing within a SIP network Hello, Jonathan Rosenberg wrote: > > I think the correct answer about which approach to use (INFO vs. multiple > call legs) depends on your view of the scope of the address within the sip > cloud. If you believe that the sip role has ended once you have enough > digits to select an egress gateway (which may be as few as one, i.e., +1 > selects a US gateway), then the sip address of that gateway can be viewed as > sip:+1@provider.com, and all subsequent digits are PSTN issues, outside the > scope of SIP. I definitively agree that this is the view that INFO fans have of a SIP cloud. What I am saying is that this view is wrong. This usage of SIP falls outside the scope of SIP. If they want to use SIP for locating a gateway, it is fine. But after the gateway has been located, let's use another method for transporting ISUP signalling. Let's assume that I get an IAM with "+1", as Jonathan says in his example. Then the INVITE generated by the gateway will reach the US gateway. Now, the mission of SIP has finished, since the gateway has been located. Why don't we put in the body of this INVITE a session description that comprises a media session and a SIGTRAN session? This way we would have established these two sessions between the gateways and all the subsequent ISUP messages would be sent over the SIGTRAN session. I find that the usage of SIP that I have just described would be OK. What I do not understand is why folks want to use SIP for transporting subsequent ISUP messages. SIP does not have good transport properties (big overhead, it can run over UDP...). Besides, it does not provide ordered delivery. If the INVITE has Cseq=1 and the next message that the egrees gateway receives is a INFO with Cseq=7... what should the gateway do? Maybe there were several proxies in the middle asking for credentials for the INFO, so the ingrees gateway had to add authentication stuff and resend the INFO. If this was the case, the SAM contained in the INFO would be the second digit of the called party number... However, maybe 5 INFO messages got lost, and the SAM that we have received in the body of the INFO makes no sense without the previous ones because is the 7th digit of the number... This is not usually a problem in SIP, since all messages have full state. However, using INFO for sending SAMs breaks this rule, and therefore it breaks the SIP model. I believe that considering that the session is established after the first INVITE and sending the following SAMs using INFO is making one of the mistakes described in the guidelines for SIP authors: "We need to transport ISUP signalling over IP between two gateways. Both gateways already implement SIP... why do we have to implement another protocol? Let's use SIP to transport ISUP signalling". We are just trying to use SIP for this just because it would save implementing yet another protocol in the gateways. I strongly disagree with this usage of SIP. SIP-T is good as long as the SIP cloud provides services. If not, SIP-T is not a good protocol for transporting ISUP signalling. Best regards, Gonzalo If you believe that the sip role encompasses functions that > might apply to the PSTN subscribers, then you need to have the entire > number, and the multiple call leg approach is the right way to go. > > The multiple call leg approach is clearly ugly and inelegant, but it has the > nice property of completely masking the existence of overlap from proxies > and app servers within the network, allowing them to provide services in the > normal way. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Thursday, February 08, 2001 7:00 AM > To: Gonzalo Camarillo > Cc: Christer Holmberg; sip@lists.bell-labs.com > Subject: RE: [SIP] Operlap dialing within a SIP network > > You are correct about using some other means of transport if ISUP > trans-shipment is all your network is doing. If the call destination (to a > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call > basis, however, using SIP to establish your call routing leads to using SIP > to carry the ISUP. > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: Tuesday, February 06, 2001 9:52 PM > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > Hi Tom, > > > > Still I want to have full state in every SIP message. If the call is > > addresed to the phone number 1234, I want to have a to field that says > > 1234. I do not care if there is a leg routed thru the PSTN and another > > thru SIP. > > > > Carrying full state is one of the beauties of SIP. If we begin using > > INFO for this, it would be the same as using SAMs. Differen names, the > > same thing... I do not want to re-create ISUP using SIP. I > > believe that > > if the session has a destination, it should be present in the > > to field. > > > > Again, if a proxy is providing services for this particular call, it > > will want to see the called party number in order to trigger > > the proper > > service. This is a very good reason for updating the to field > > every time > > we have more digits. > > > > I like to use SIP between two gateways because it is possible > > to provide > > SIP services for a PSTN to PSTN call. If all we want to do is > > finding a > > egrees gateway, we would probably want to use other protocols (TRIP & > > SIGTRAN for instance). > > > > Regards, > > > > Gonzalo > > > > Tom-PT Taylor wrote: > > > > > > Sorry, we're talking past each other. The premise of my > > statements is > > > that an INVITE has reached a UAS which has accepted it. It follows > > > that the UAS did not send back a 484, but rather an interim > > response. > > > IF more digits come along, the INFO method is there to carry them. > > > They do not affect the SIP call state; they are used beyond the UAS, > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hello Tom, > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > signalling > > > > > has reached an egress gateway, SIP has done its job -- > > additional > > > > > digits will not change call state. It is therefore > > > > reasonable to use > > > > > INFO to carry the additional digits. If we are talking > > > > ISUP-SIP, once > > > > > the destination UAS or a UAS in a B2BUA has been > > reached, the same > > > > > > > > consideration applies. > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > vanilla SIP UA. > > > I > > > > will return a Not Found or a 484 Address incomplete. The > > > > subsequent INFO > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > gateway > > > > will have to re issue a new INVITE with all the digits. > > > > Therefore, it is > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > > carries ISUP messages between two gateways. For that, we have > > > already > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > call is a > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > state. And a > > > > SIP message with an incomplete to field does not carry complete > > > state. > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > based > > > > on the to field (called party number). That proxy would > > like to see > > > an > > > > updated to field, not just a to field that contains just some > > > digits. > > > > > > > > Best regards, > > > > > > > > Gonzalo > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > To: Gonzalo Camarillo > > > > > > Cc: sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > been proposed > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > reason for > > > > > > the discussion from the beginning was that the overlap > > > signalling, > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > very well, and > > > > > a > > > > > > solution using 18x responses and INFO messages, instead of 484 > > > and > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer Holmberg > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > signalling section. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > > about calls > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > SIP UAS > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > | <- 18x ------ | > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > | <- 200 (INFO) | > > > > > > > > | <- 18x ------ | > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > --> > > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > the word 'proxy') > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > overlap dialing, to > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > the digits > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > be allowed to > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > INVITEs, until > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > -- > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > FIN-02420 Jorvas Email : > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 14 05:58:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25903 for ; Wed, 14 Feb 2001 05:58:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7CF394433A; Wed, 14 Feb 2001 05:58:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 7B5D644336 for ; Wed, 14 Feb 2001 05:57:49 -0500 (EST) 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 f1EArdC24031; Wed, 14 Feb 2001 11:53:40 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA27336; Wed, 14 Feb 2001 12:53:38 +0200 (EET) Message-ID: <3A8A63AB.2F841200@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Keith Robinson , Gonzalo Camarillo , Jonathan Rosenberg , "'Tom-PT Taylor'" Subject: Re: [SIP] Operlap dialing within a SIP network References: <802569F3.00377A7A.00@marconicomms.com> Content-Type: multipart/mixed; boundary="------------C531AD3130F16894FC672646" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 14 Feb 2001 12:53:31 +0200 This is a multi-part message in MIME format. --------------C531AD3130F16894FC672646 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am not Gonzalo, but I will comment anyway... :) >Gonzalo, > >It seems you have two main reasons against the use of the INFO >method for the conveyance of subsequent ISUP information: > >1) Lack of ordered delivery of the INFO messages > >Ordered delivery could be maintained by the UAC not sending the next INFO >until a 200 OK response for the previous one had been received. I am strongly against that. We would have to start buffering incoming SAMs, and by having to wait for the response before sending the next INVITE it would slow down the setup time between the nodes. This is also related with the PRACK issue, where we also may have to do buffering becuase we have to wait for messages (which means we may have to do buffering), but that is another issue... >2) Lack of state carried in the INFO messge > >The digits received so far could be carried in a header within the >INFO message. Each INFO message would then carry the same information >as a re-INVITE. > >My reason for exploring the use of INFO is not to save on messages. It is >to do with the issue of source routing. Again, my concern of source >routing is not one of a technical nature. What if an administration has a >security policy that states source routing (a ROUTE header in >an initial INVITE) will not take place in its SIP network but it also >requires that the same network interworks with the PSTN; if any part of >the PSTN interworking mechanism relies on source routing then there is a >conflict of requirements. It is this conflict >I wish to address. I am not sure I understood this correctly. But, in either case the UAC will have to send an initial INVITE, so it can choose to insert a ROUTE header. I think that the administrator proxies in the network should be able to handle that, e.g. either by refusing the message (a proxy should have the last say about if a message is allowed to be routed in a specific way or not), sending a 3xx response (to re-route the call), or simply by removing the ROUTE header (I know that is not allowed, but the there is also an issue of allowing ROUTE in the initial INVITE in the first place, so...). In another mail I pointed out that the network operator administrator most likely wants to have good control of the network, so I think it should be allowed for proxies to do these kind of things. Otherwise one can send anything in the requests, and soon we will have a bunch of "SIP Viruses" out there... Regards, Christer Holmberg Ericsson Finland > > Regards, > > K. Robinson. > > Gonzalo Camarillo on 01/01/88 00:39:14 > > > > > > > > To: Jonathan Rosenberg > > cc: "'Tom-PT Taylor'" , > Christer Holmberg > , > sip@lists.bell-labs.com(bcc: Keith > Robinson/MAIN/MC1) > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > Hello, > > Jonathan Rosenberg wrote: > > > > I think the correct answer about which approach to use (INFO vs. multiple > > call legs) depends on your view of the scope of the address within the sip > > cloud. If you believe that the sip role has ended once you have enough > > digits to select an egress gateway (which may be as few as one, i.e., +1 > > selects a US gateway), then the sip address of that gateway can be viewed as > > sip:+1@provider.com, and all subsequent digits are PSTN issues, outside the > > scope of SIP. > > I definitively agree that this is the view that INFO fans have of a SIP > cloud. What I am saying is that this view is wrong. This usage of SIP > falls outside the scope of SIP. > If they want to use SIP for locating a gateway, it is fine. But after > the gateway has been located, let's use another method for transporting > ISUP signalling. > > Let's assume that I get an IAM with "+1", as Jonathan says in his > example. Then the INVITE generated by the gateway will reach the US > gateway. Now, the mission of SIP has finished, since the gateway has > been located. Why don't we put in the body of this INVITE a session > description that comprises a media session and a SIGTRAN session? This > way we would have established these two sessions between the gateways > and all the subsequent ISUP messages would be sent over the SIGTRAN > session. > > I find that the usage of SIP that I have just described would be OK. > What I do not understand is why folks want to use SIP for transporting > subsequent ISUP messages. SIP does not have good transport properties > (big overhead, it can run over UDP...). Besides, it does not provide > ordered delivery. > > If the INVITE has Cseq=1 and the next message that the egrees gateway > receives is a INFO with Cseq=7... what should the gateway do? Maybe > there were several proxies in the middle asking for credentials for the > INFO, so the ingrees gateway had to add authentication stuff and resend > the INFO. If this was the case, the SAM contained in the INFO would be > the second digit of the called party number... However, maybe 5 INFO > messages got lost, and the SAM that we have received in the body of the > INFO makes no sense without the previous ones because is the 7th digit > of the number... > > This is not usually a problem in SIP, since all messages have full > state. However, using INFO for sending SAMs breaks this rule, and > therefore it breaks the SIP model. > > I believe that considering that the session is established after the > first INVITE and sending the following SAMs using INFO is making one of > the mistakes described in the guidelines for SIP authors: "We need to > transport ISUP signalling over IP between two gateways. Both gateways > already implement SIP... why do we have to implement another protocol? > Let's use SIP to transport ISUP signalling". We are just trying to use > SIP for this just because it would save implementing yet another > protocol in the gateways. > > I strongly disagree with this usage of SIP. SIP-T is good as long as the > SIP cloud provides services. If not, SIP-T is not a good protocol for > transporting ISUP signalling. > > Best regards, > > Gonzalo > > If you believe that the sip role encompasses functions that > > might apply to the PSTN subscribers, then you need to have the entire > > number, and the multiple call leg approach is the right way to go. > > > > The multiple call leg approach is clearly ugly and inelegant, but it has the > > nice property of completely masking the existence of overlap from proxies > > and app servers within the network, allowing them to provide services in the > > normal way. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > Sent: Thursday, February 08, 2001 7:00 AM > > To: Gonzalo Camarillo > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > You are correct about using some other means of transport if ISUP > > trans-shipment is all your network is doing. If the call destination (to a > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call > > basis, however, using SIP to establish your call routing leads to using SIP > > to carry the ISUP. > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > Hi Tom, > > > > > > Still I want to have full state in every SIP message. If the call is > > > addresed to the phone number 1234, I want to have a to field that says > > > 1234. I do not care if there is a leg routed thru the PSTN and another > > > thru SIP. > > > > > > Carrying full state is one of the beauties of SIP. If we begin using > > > INFO for this, it would be the same as using SAMs. Differen names, the > > > same thing... I do not want to re-create ISUP using SIP. I > > > believe that > > > if the session has a destination, it should be present in the > > > to field. > > > > > > Again, if a proxy is providing services for this particular call, it > > > will want to see the called party number in order to trigger > > > the proper > > > service. This is a very good reason for updating the to field > > > every time > > > we have more digits. > > > > > > I like to use SIP between two gateways because it is possible > > > to provide > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > finding a > > > egrees gateway, we would probably want to use other protocols (TRIP & > > > SIGTRAN for instance). > > > > > > Regards, > > > > > > Gonzalo > > > > > > Tom-PT Taylor wrote: > > > > > > > > Sorry, we're talking past each other. The premise of my > > > statements is > > > > that an INVITE has reached a UAS which has accepted it. It follows > > > > that the UAS did not send back a 484, but rather an interim > > > response. > > > > IF more digits come along, the INFO method is there to carry them. > > > > They do not affect the SIP call state; they are used beyond the UAS, > > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > signalling > > > > > > has reached an egress gateway, SIP has done its job -- > > > additional > > > > > > digits will not change call state. It is therefore > > > > > reasonable to use > > > > > > INFO to carry the additional digits. If we are talking > > > > > ISUP-SIP, once > > > > > > the destination UAS or a UAS in a B2BUA has been > > > reached, the same > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > vanilla SIP UA. > > > > I > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > subsequent INFO > > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > > gateway > > > > > will have to re issue a new INVITE with all the digits. > > > > > Therefore, it is > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > > > carries ISUP messages between two gateways. For that, we have > > > > already > > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > > call is a > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > state. And a > > > > > SIP message with an incomplete to field does not carry complete > > > > state. > > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > > based > > > > > on the to field (called party number). That proxy would > > > like to see > > > > an > > > > > updated to field, not just a to field that contains just some > > > > digits. > > > > > > > > > > Best regards, > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > To: Gonzalo Camarillo > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > > been proposed > > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > > reason for > > > > > > > the discussion from the beginning was that the overlap > > > > signalling, > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > very well, and > > > > > > a > > > > > > > solution using 18x responses and INFO messages, instead of 484 > > > > and > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer Holmberg > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > signalling section. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > > > about calls > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > SIP UAS > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > | <- 18x ------ | > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > | <- 18x ------ | > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > > --> > > > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > > the word 'proxy') > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > overlap dialing, to > > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > > the digits > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > > be allowed to > > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > > INVITEs, until > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > -- > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > FIN-02420 Jorvas Email : > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. --------------C531AD3130F16894FC672646 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 --------------C531AD3130F16894FC672646-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 14 07:29:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26657 for ; Wed, 14 Feb 2001 07:29:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 280224433A; Wed, 14 Feb 2001 07:29:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from email5.etsi.org (email5.etsi.fr [212.234.161.50]) by lists.bell-labs.com (Postfix) with ESMTP id CDA8744336 for ; Wed, 14 Feb 2001 07:28:05 -0500 (EST) Received: by EMAIL5 with Internet Mail Service (5.5.2650.21) id <16WYT609>; Wed, 14 Feb 2001 13:27:59 +0100 Message-ID: <337FC70FD51CD411A3500008C70D56F15003CA@EMAIL1> From: Nathalie Guinet To: "'sip@lists.bell-labs.com'" Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] URGENT: REMINDER SIP BAKE OFF REGISTRATION DEADLINES Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 14 Feb 2001 13:27:59 +0100 Dear SIP Bake-off participants, I remind you that the Early Bird Room Rate of the Royal Hotel Casino has been extended until 15th February (tomorrow). After that date, the rate will be increased by 200ff/night (= 30.5 EUR) You may use this form to make your booking. http://webapp.etsi.org/interop3/doc/registration.doc Second, the deadline for the registration to participate to the SIP Bake-off is 25. February. You may register your company, the participants and equipment requirements by visiting this page: http://webapp.etsi.org/interop3/Rules.asp?eventid=3 General information on the registration process can be found at http://www.etsi.org/bake-off/2UpcomingBakeoffs/2001_SIP/SIP_generalinfo.htm You should also proceed to the payment of the corresponding participation fees as explained in the same page. Do not hesitate one second to contact me should you have any worries or questions with any of these points. Thanks for your attention. Nathalie Guinet ETSI Bake-off Service Event Coordinator http://www.etsi.org/bake-off Tel: +33 (0)4 92 94 43 62 Fax: + 33 (0)4 92 38 49 13 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 14 09:39:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00154 for ; Wed, 14 Feb 2001 09:39:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BF19F4433C; Wed, 14 Feb 2001 09:39:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 35AB34433A for ; Wed, 14 Feb 2001 09:38:32 -0500 (EST) 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 f1EEcUd10792; Wed, 14 Feb 2001 15:38:30 +0100 (MET) Received: from lmf.ericsson.se (EWUwsp001637wss.sd.us.am.ericsson.se [142.133.141.53]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id PAA09992; Wed, 14 Feb 2001 15:38:23 +0100 (MET) Message-ID: <3A8A96B8.B804D4A0@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: Jonathan Rosenberg , "'Tom-PT Taylor'" , Christer Holmberg , sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: <802569F3.00377A7A.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 14 Feb 2001 16:31:20 +0200 Content-Transfer-Encoding: 7bit Hello Keith, Keith Robinson wrote: > > Gonzalo, > > It seems you have two main reasons against the use of the INFO > method for the conveyance of subsequent ISUP information: > > 1) Lack of ordered delivery of the INFO messages > > Ordered delivery could be maintained by the UAC not sending the next INFO > until a 200 OK response for the previous one had been received. > > 2) Lack of state carried in the INFO messge > > The digits received so far could be carried in a header within the > INFO message. Each INFO message would then carry the same information > as a re-INVITE. > Actually my main reason against the use of INFO is that it does not work with vanilla SIP UAs and vanilla SIP Application Servers. How you resolve the technical issues related to INFO does not really matter to me. It is not "vanilla" SIP, and I am against this kind of non-standard mechanisms. > My reason for exploring the use of INFO is not to save on messages. It is > to do with the issue of source routing. Again, my concern of source > routing is not one of a technical nature. What if an administration has a > security policy that states source routing (a ROUTE header in > an initial INVITE) will not take place in its SIP network but it also requires > that > the same network interworks with the PSTN; if any part of the PSTN interworking > mechanism > relies on source routing then there is a conflict of requirements. It is this > conflict > I wish to address. > OK, let's address this. Source routing is proposed in the draft to address load balancing. This is, a proxy that sends INVITEs to different egrees gateways. So, if an IAM and one SAM are received, the second INVITE might end up in another gateway than the fist INVITE. This would trigger 2 IAMs instead of 1 IAM and 1 SAM. OK, this is the problem that has to be solved. What I wanted to say in the draft (I did not have lot of time and it has to be rephrased), was the following: It is strongly RECOMMENDED that proxies route requests that are basically identical and just differ in the to field (more digits) in the same way. So, if such as proxy performs load balancing, all the subsequent INVITEs will reach the same egrees gateway. This is not difficult to do, because most likely a call to +1234 has to be routed in the same way as a call to +12345. So, the only real requirement in that proxies do not make routing decisions based on random variables (such as internal clocks). Then, just in case folks did not feel comfortable with this solution (which I believe is the good one), I outlined the source routing solution. And what about load balancing? You can still have load balancing. Your proxy makes the routing decision based on to, from, and what ever fields it wants. Then, it can calculate a digest of some fields, and make a "random" routing decision based on that hash. This provides load balancing but still routes INVITEs carrying SAMs in the proper way. Does this resolve your issue? Best regards, Gonzalo > Regards, > > K. Robinson. > > Gonzalo Camarillo on 01/01/88 00:39:14 > > > > > > > > To: Jonathan Rosenberg > > cc: "'Tom-PT Taylor'" , > Christer Holmberg > , > sip@lists.bell-labs.com(bcc: Keith > Robinson/MAIN/MC1) > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > Hello, > > Jonathan Rosenberg wrote: > > > > I think the correct answer about which approach to use (INFO vs. multiple > > call legs) depends on your view of the scope of the address within the sip > > cloud. If you believe that the sip role has ended once you have enough > > digits to select an egress gateway (which may be as few as one, i.e., +1 > > selects a US gateway), then the sip address of that gateway can be viewed as > > sip:+1@provider.com, and all subsequent digits are PSTN issues, outside the > > scope of SIP. > > I definitively agree that this is the view that INFO fans have of a SIP > cloud. What I am saying is that this view is wrong. This usage of SIP > falls outside the scope of SIP. > If they want to use SIP for locating a gateway, it is fine. But after > the gateway has been located, let's use another method for transporting > ISUP signalling. > > Let's assume that I get an IAM with "+1", as Jonathan says in his > example. Then the INVITE generated by the gateway will reach the US > gateway. Now, the mission of SIP has finished, since the gateway has > been located. Why don't we put in the body of this INVITE a session > description that comprises a media session and a SIGTRAN session? This > way we would have established these two sessions between the gateways > and all the subsequent ISUP messages would be sent over the SIGTRAN > session. > > I find that the usage of SIP that I have just described would be OK. > What I do not understand is why folks want to use SIP for transporting > subsequent ISUP messages. SIP does not have good transport properties > (big overhead, it can run over UDP...). Besides, it does not provide > ordered delivery. > > If the INVITE has Cseq=1 and the next message that the egrees gateway > receives is a INFO with Cseq=7... what should the gateway do? Maybe > there were several proxies in the middle asking for credentials for the > INFO, so the ingrees gateway had to add authentication stuff and resend > the INFO. If this was the case, the SAM contained in the INFO would be > the second digit of the called party number... However, maybe 5 INFO > messages got lost, and the SAM that we have received in the body of the > INFO makes no sense without the previous ones because is the 7th digit > of the number... > > This is not usually a problem in SIP, since all messages have full > state. However, using INFO for sending SAMs breaks this rule, and > therefore it breaks the SIP model. > > I believe that considering that the session is established after the > first INVITE and sending the following SAMs using INFO is making one of > the mistakes described in the guidelines for SIP authors: "We need to > transport ISUP signalling over IP between two gateways. Both gateways > already implement SIP... why do we have to implement another protocol? > Let's use SIP to transport ISUP signalling". We are just trying to use > SIP for this just because it would save implementing yet another > protocol in the gateways. > > I strongly disagree with this usage of SIP. SIP-T is good as long as the > SIP cloud provides services. If not, SIP-T is not a good protocol for > transporting ISUP signalling. > > Best regards, > > Gonzalo > > If you believe that the sip role encompasses functions that > > might apply to the PSTN subscribers, then you need to have the entire > > number, and the multiple call leg approach is the right way to go. > > > > The multiple call leg approach is clearly ugly and inelegant, but it has the > > nice property of completely masking the existence of overlap from proxies > > and app servers within the network, allowing them to provide services in the > > normal way. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > Sent: Thursday, February 08, 2001 7:00 AM > > To: Gonzalo Camarillo > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > You are correct about using some other means of transport if ISUP > > trans-shipment is all your network is doing. If the call destination (to a > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call > > basis, however, using SIP to establish your call routing leads to using SIP > > to carry the ISUP. > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > Hi Tom, > > > > > > Still I want to have full state in every SIP message. If the call is > > > addresed to the phone number 1234, I want to have a to field that says > > > 1234. I do not care if there is a leg routed thru the PSTN and another > > > thru SIP. > > > > > > Carrying full state is one of the beauties of SIP. If we begin using > > > INFO for this, it would be the same as using SAMs. Differen names, the > > > same thing... I do not want to re-create ISUP using SIP. I > > > believe that > > > if the session has a destination, it should be present in the > > > to field. > > > > > > Again, if a proxy is providing services for this particular call, it > > > will want to see the called party number in order to trigger > > > the proper > > > service. This is a very good reason for updating the to field > > > every time > > > we have more digits. > > > > > > I like to use SIP between two gateways because it is possible > > > to provide > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > finding a > > > egrees gateway, we would probably want to use other protocols (TRIP & > > > SIGTRAN for instance). > > > > > > Regards, > > > > > > Gonzalo > > > > > > Tom-PT Taylor wrote: > > > > > > > > Sorry, we're talking past each other. The premise of my > > > statements is > > > > that an INVITE has reached a UAS which has accepted it. It follows > > > > that the UAS did not send back a 484, but rather an interim > > > response. > > > > IF more digits come along, the INFO method is there to carry them. > > > > They do not affect the SIP call state; they are used beyond the UAS, > > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > signalling > > > > > > has reached an egress gateway, SIP has done its job -- > > > additional > > > > > > digits will not change call state. It is therefore > > > > > reasonable to use > > > > > > INFO to carry the additional digits. If we are talking > > > > > ISUP-SIP, once > > > > > > the destination UAS or a UAS in a B2BUA has been > > > reached, the same > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > vanilla SIP UA. > > > > I > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > subsequent INFO > > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > > gateway > > > > > will have to re issue a new INVITE with all the digits. > > > > > Therefore, it is > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > > > carries ISUP messages between two gateways. For that, we have > > > > already > > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > > call is a > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > state. And a > > > > > SIP message with an incomplete to field does not carry complete > > > > state. > > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > > based > > > > > on the to field (called party number). That proxy would > > > like to see > > > > an > > > > > updated to field, not just a to field that contains just some > > > > digits. > > > > > > > > > > Best regards, > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > To: Gonzalo Camarillo > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > > been proposed > > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > > reason for > > > > > > > the discussion from the beginning was that the overlap > > > > signalling, > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > very well, and > > > > > > a > > > > > > > solution using 18x responses and INFO messages, instead of 484 > > > > and > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer Holmberg > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > signalling section. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > > > about calls > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > SIP UAS > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > | <- 18x ------ | > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > | <- 18x ------ | > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > > --> > > > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > > the word 'proxy') > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > overlap dialing, to > > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > > the digits > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > > be allowed to > > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > > INVITEs, until > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > -- > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > FIN-02420 Jorvas Email : > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 14 09:52:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00611 for ; Wed, 14 Feb 2001 09:52:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 23E8A4433A; Wed, 14 Feb 2001 09:52:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis22.marconicomms.com (cvis22.marconicomms.com [195.99.244.54]) by lists.bell-labs.com (Postfix) with ESMTP id DA18144336 for ; Wed, 14 Feb 2001 09:51:57 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis22.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 14 Feb 2001 14:52:11 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id OAA24678; Wed, 14 Feb 2001 14:51:53 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569F3.00507460 ; Wed, 14 Feb 2001 14:38:46 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Christer Holmberg Cc: sip@lists.bell-labs.com, Gonzalo Camarillo , Jonathan Rosenberg , "'Tom-PT Taylor'" Message-ID: <802569F3.00502AD6.00@marconicomms.com> Subject: Re: [SIP] Operlap dialing within a SIP network Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=1SJvMvB2r1k4LlpFa9xwQ4wES3KrukZnUIVSMN9znpCJtV8InXtFralS" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 14 Feb 2001 14:35:31 +0000 --0__=1SJvMvB2r1k4LlpFa9xwQ4wES3KrukZnUIVSMN9znpCJtV8InXtFralS Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Christer wrote : > I think that the administrator proxies in the network should be >able to handle that, e.g. either by refusing the message (a proxy should >have the last say about if a message is allowed to be routed in a >specific way or not), sending a 3xx response (to re-route the call), or >simply by removing the ROUTE header (I know that is not allowed, but the >there is also an issue of allowing ROUTE in the initial INVITE in the >first place, so...). In another mail I pointed out that the network >operator administrator most likely wants to have good control of the >network, so I think it should be allowed for proxies to do these kind of >things. This is exactly my concern. What if proxies are configured to reject or ignore the ROUTE header of requests which are attempting to source route. The initial INVITEs sending subsequent digits may not reach the (correct) UAS if they had to traverse such networks and so the mechanism would fail. Regards, K. Robinson. Christer Holmberg on 14/02/2001 10:53:31 To: sip@lists.bell-labs.com cc: Keith Robinson/MAIN/MC1@MCMAIN, Gonzalo Camarillo , Jonathan Rosenberg , "'Tom-PT Taylor'" Subject: Re: [SIP] Operlap dialing within a SIP network Hi, I am not Gonzalo, but I will comment anyway... :) >Gonzalo, > >It seems you have two main reasons against the use of the INFO >method for the conveyance of subsequent ISUP information: > >1) Lack of ordered delivery of the INFO messages > >Ordered delivery could be maintained by the UAC not sending the next INFO >until a 200 OK response for the previous one had been received. I am strongly against that. We would have to start buffering incoming SAMs, and by having to wait for the response before sending the next INVITE it would slow down the setup time between the nodes. This is also related with the PRACK issue, where we also may have to do buffering becuase we have to wait for messages (which means we may have to do buffering), but that is another issue... >2) Lack of state carried in the INFO messge > >The digits received so far could be carried in a header within the >INFO message. Each INFO message would then carry the same information >as a re-INVITE. > >My reason for exploring the use of INFO is not to save on messages. It is >to do with the issue of source routing. Again, my concern of source >routing is not one of a technical nature. What if an administration has a >security policy that states source routing (a ROUTE header in >an initial INVITE) will not take place in its SIP network but it also >requires that the same network interworks with the PSTN; if any part of >the PSTN interworking mechanism relies on source routing then there is a >conflict of requirements. It is this conflict >I wish to address. I am not sure I understood this correctly. But, in either case the UAC will have to send an initial INVITE, so it can choose to insert a ROUTE header. I think that the administrator proxies in the network should be able to handle that, e.g. either by refusing the message (a proxy should have the last say about if a message is allowed to be routed in a specific way or not), sending a 3xx response (to re-route the call), or simply by removing the ROUTE header (I know that is not allowed, but the there is also an issue of allowing ROUTE in the initial INVITE in the first place, so...). In another mail I pointed out that the network operator administrator most likely wants to have good control of the network, so I think it should be allowed for proxies to do these kind of things. Otherwise one can send anything in the requests, and soon we will have a bunch of "SIP Viruses" out there... Regards, Christer Holmberg Ericsson Finland > > Regards, > > K. Robinson. > > Gonzalo Camarillo on 01/01/88 00:39:14 > > > > > > > > To: Jonathan Rosenberg > > cc: "'Tom-PT Taylor'" , > Christer Holmberg > , > sip@lists.bell-labs.com(bcc: Keith > Robinson/MAIN/MC1) > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > Hello, > > Jonathan Rosenberg wrote: > > > > I think the correct answer about which approach to use (INFO vs. multiple > > call legs) depends on your view of the scope of the address within the sip > > cloud. If you believe that the sip role has ended once you have enough > > digits to select an egress gateway (which may be as few as one, i.e., +1 > > selects a US gateway), then the sip address of that gateway can be viewed as > > sip:+1@provider.com, and all subsequent digits are PSTN issues, outside the > > scope of SIP. > > I definitively agree that this is the view that INFO fans have of a SIP > cloud. What I am saying is that this view is wrong. This usage of SIP > falls outside the scope of SIP. > If they want to use SIP for locating a gateway, it is fine. But after > the gateway has been located, let's use another method for transporting > ISUP signalling. > > Let's assume that I get an IAM with "+1", as Jonathan says in his > example. Then the INVITE generated by the gateway will reach the US > gateway. Now, the mission of SIP has finished, since the gateway has > been located. Why don't we put in the body of this INVITE a session > description that comprises a media session and a SIGTRAN session? This > way we would have established these two sessions between the gateways > and all the subsequent ISUP messages would be sent over the SIGTRAN > session. > > I find that the usage of SIP that I have just described would be OK. > What I do not understand is why folks want to use SIP for transporting > subsequent ISUP messages. SIP does not have good transport properties > (big overhead, it can run over UDP...). Besides, it does not provide > ordered delivery. > > If the INVITE has Cseq=1 and the next message that the egrees gateway > receives is a INFO with Cseq=7... what should the gateway do? Maybe > there were several proxies in the middle asking for credentials for the > INFO, so the ingrees gateway had to add authentication stuff and resend > the INFO. If this was the case, the SAM contained in the INFO would be > the second digit of the called party number... However, maybe 5 INFO > messages got lost, and the SAM that we have received in the body of the > INFO makes no sense without the previous ones because is the 7th digit > of the number... > > This is not usually a problem in SIP, since all messages have full > state. However, using INFO for sending SAMs breaks this rule, and > therefore it breaks the SIP model. > > I believe that considering that the session is established after the > first INVITE and sending the following SAMs using INFO is making one of > the mistakes described in the guidelines for SIP authors: "We need to > transport ISUP signalling over IP between two gateways. Both gateways > already implement SIP... why do we have to implement another protocol? > Let's use SIP to transport ISUP signalling". We are just trying to use > SIP for this just because it would save implementing yet another > protocol in the gateways. > > I strongly disagree with this usage of SIP. SIP-T is good as long as the > SIP cloud provides services. If not, SIP-T is not a good protocol for > transporting ISUP signalling. > > Best regards, > > Gonzalo > > If you believe that the sip role encompasses functions that > > might apply to the PSTN subscribers, then you need to have the entire > > number, and the multiple call leg approach is the right way to go. > > > > The multiple call leg approach is clearly ugly and inelegant, but it has the > > nice property of completely masking the existence of overlap from proxies > > and app servers within the network, allowing them to provide services in the > > normal way. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > Sent: Thursday, February 08, 2001 7:00 AM > > To: Gonzalo Camarillo > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > You are correct about using some other means of transport if ISUP > > trans-shipment is all your network is doing. If the call destination (to a > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call > > basis, however, using SIP to establish your call routing leads to using SIP > > to carry the ISUP. > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > Hi Tom, > > > > > > Still I want to have full state in every SIP message. If the call is > > > addresed to the phone number 1234, I want to have a to field that says > > > 1234. I do not care if there is a leg routed thru the PSTN and another > > > thru SIP. > > > > > > Carrying full state is one of the beauties of SIP. If we begin using > > > INFO for this, it would be the same as using SAMs. Differen names, the > > > same thing... I do not want to re-create ISUP using SIP. I > > > believe that > > > if the session has a destination, it should be present in the > > > to field. > > > > > > Again, if a proxy is providing services for this particular call, it > > > will want to see the called party number in order to trigger > > > the proper > > > service. This is a very good reason for updating the to field > > > every time > > > we have more digits. > > > > > > I like to use SIP between two gateways because it is possible > > > to provide > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > finding a > > > egrees gateway, we would probably want to use other protocols (TRIP & > > > SIGTRAN for instance). > > > > > > Regards, > > > > > > Gonzalo > > > > > > Tom-PT Taylor wrote: > > > > > > > > Sorry, we're talking past each other. The premise of my > > > statements is > > > > that an INVITE has reached a UAS which has accepted it. It follows > > > > that the UAS did not send back a 484, but rather an interim > > > response. > > > > IF more digits come along, the INFO method is there to carry them. > > > > They do not affect the SIP call state; they are used beyond the UAS, > > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > signalling > > > > > > has reached an egress gateway, SIP has done its job -- > > > additional > > > > > > digits will not change call state. It is therefore > > > > > reasonable to use > > > > > > INFO to carry the additional digits. If we are talking > > > > > ISUP-SIP, once > > > > > > the destination UAS or a UAS in a B2BUA has been > > > reached, the same > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > vanilla SIP UA. > > > > I > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > subsequent INFO > > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > > gateway > > > > > will have to re issue a new INVITE with all the digits. > > > > > Therefore, it is > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > > > carries ISUP messages between two gateways. For that, we have > > > > already > > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > > call is a > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > state. And a > > > > > SIP message with an incomplete to field does not carry complete > > > > state. > > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > > based > > > > > on the to field (called party number). That proxy would > > > like to see > > > > an > > > > > updated to field, not just a to field that contains just some > > > > digits. > > > > > > > > > > Best regards, > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > To: Gonzalo Camarillo > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > > been proposed > > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > > reason for > > > > > > > the discussion from the beginning was that the overlap > > > > signalling, > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > very well, and > > > > > > a > > > > > > > solution using 18x responses and INFO messages, instead of 484 > > > > and > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer Holmberg > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > signalling section. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > > > about calls > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > SIP UAS > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > | <- 18x ------ | > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > | <- 18x ------ | > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > > --> > > > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > > the word 'proxy') > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > overlap dialing, to > > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > > the digits > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > > be allowed to > > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > > INVITEs, until > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > -- > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > FIN-02420 Jorvas Email : > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. --0__=1SJvMvB2r1k4LlpFa9xwQ4wES3KrukZnUIVSMN9znpCJtV8InXtFralS Content-type: application/octet-stream; name="christer.holmberg.vcf" Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOkhvbG1iZXJnO0NocmlzdGVyDQp0ZWw7Y2VsbDorMzU4LTQwLTU2MDQ0 MTINCnRlbDt3b3JrOiszNTgtOS0yOTkyOTQzDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnOkVy aWNzc29uO0lQIE11bHRpbWVkaWEgLyBBZHZhbmNlZCBTaWduYWxsaW5nIFJlc2VhcmNoIExhYm9y YXRvcnkNCmFkcjo7Ozs7OzsNCnZlcnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpjaHJpc3Rlci5o b2xtYmVyZ0BsbWYuZXJpY3Nzb24uc2UNCnRpdGxlOlN5c3RlbSBEZXNpZ25lcg0KZm46Q2hyaXN0 ZXIgSG9sbWJlcmcNCmVuZDp2Y2FyZA0KDQo= --0__=1SJvMvB2r1k4LlpFa9xwQ4wES3KrukZnUIVSMN9znpCJtV8InXtFralS-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 14 09:59:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00975 for ; Wed, 14 Feb 2001 09:59:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1A3724433A; Wed, 14 Feb 2001 09:59:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 981C644336 for ; Wed, 14 Feb 2001 09:58:21 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id IAA15032; Wed, 14 Feb 2001 08:59:16 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Wed, 14 Feb 2001 08:55:06 -0600 Message-ID: From: "Culpepper, Bert" To: Rohan Mahy , sip@lists.bell-labs.com Subject: RE: [SIP] matching m= lines with multi-unicast SDP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 14 Feb 2001 08:55:05 -0600 my interpretation is below... Rohan Mahy [mailto:rohan@cisco.com] > > Hi folks, > > Let's say I send an INVITE to A with a multi-unicast SDP. I > want A to send (the same) audio to 10.1.1.1 and 10.1.1.2, > and be prepared to receive audio from either (or both). > > A -- 10.1.1.1 > \ > 10.1.1.2 > > Here is part of my INVITE: > > INVITE sip:A -> > ... > m=audio 16902 0 > c=10.1.1.1 > m=audio 19764 0 > c=10.1.1.2 > > > Now according to the m= line matching rules, I need all the > lines to match. So which of the following are valid responses? It > seems that none of them have the desired semantics. > > Two m= lines, but use the same port (is this allowed?) > > <- 200 > ... > m=audio 17804 0 > c=10.1.1.3 > m=audio 17804 0 > c=10.1.1.3 > A is indicating it wants to both media streams sent to the same address and port. This seems fine to me and is the correct response IMHO to achieve what you want. > > Two m= lines, one port set to zero (doesn't this mean "i won't > accept that stream"?) > > <- 200 > ... > m=audio 17804 0 > c=10.1.1.3 > m=audio 0 0 > c=10.1.1.3 > A is saying it'll send and receive the first stream and neither send, nor receive the second. > > Two m= lines, one address line set to zero (make 10.1.1.2 > stop sending?) > > <- 200 > ... > m=audio 17804 0 > c=10.1.1.3 > m=audio 17804 0 > c=0.0.0.0 > A is saying it'll send and receive the first stream but is placing the second stream on hold. However, if the INVITE didn't come from 10.1.1.2 the endpoint receiving the response will have to pass on A's desire to 10.1.1.2 if A doesn't want to deal with two media streams. > > Only one m= line (seems to violate principal of m= line matching) > > <- 200 > ... > m=audio 17804 0 > c=10.1.1.3 > This is an incorrect response since the second m= line is missing. regards, Bert > > Comments are welcome. > > thanks, > -rohan _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 14 10:16:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01814 for ; Wed, 14 Feb 2001 10:16:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 61B694433C; Wed, 14 Feb 2001 10:16:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 7C58644336 for ; Wed, 14 Feb 2001 10:15:21 -0500 (EST) 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 f1EFFKd21993; Wed, 14 Feb 2001 16:15:20 +0100 (MET) Received: from lmf.ericsson.se (EWUwsp001637wss.sd.us.am.ericsson.se [142.133.141.53]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id QAA19089; Wed, 14 Feb 2001 16:13:46 +0100 (MET) Message-ID: <3A8A9F02.FC4929DD@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: sip@lists.bell-labs.com Subject: Re: [SIP] matching m= lines with multi-unicast SDP References: <4.1.20010213085223.01351f00@imop.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 14 Feb 2001 17:06:42 +0200 Content-Transfer-Encoding: 7bit Hello Rohan, You might want to check http://search.ietf.org/internet-drafts/draft-ietf-mmusic-fid-00.txt this draft defines the concept of flow (as opposed to media stream). Best regards, Gonzalo Rohan Mahy wrote: > > Hi folks, > > Let's say I send an INVITE to A with a multi-unicast SDP. I want A to > send (the same) audio to 10.1.1.1 and 10.1.1.2, and be prepared to > receive audio from either (or both). > > A -- 10.1.1.1 > \ > 10.1.1.2 > > Here is part of my INVITE: > > INVITE sip:A -> > ... > m=audio 16902 0 > c=10.1.1.1 > m=audio 19764 0 > c=10.1.1.2 > > Now according to the m= line matching rules, I need all the lines to > match. So which of the following are valid responses? It seems that > none of them have the desired semantics. > > Two m= lines, but use the same port (is this allowed?) > > <- 200 > ... > > m=audio 17804 0 > c=10.1.1.3 > m=audio 17804 0 > c=10.1.1.3 > > Two m= lines, one port set to zero (doesn't this mean "i won't accept > that stream"?) > > <- 200 > ... > m=audio 17804 0 > c=10.1.1.3 > m=audio 0 0 > c=10.1.1.3 > > Two m= lines, one address line set to zero (make 10.1.1.2 stop > sending?) > > <- 200 > ... > m=audio 17804 0 > c=10.1.1.3 > m=audio 17804 0 > c=0.0.0.0 > > Only one m= line (seems to violate principal of m= line matching) > > <- 200 > ... > m=audio 17804 0 > c=10.1.1.3 > > Comments are welcome. > > thanks, > -rohan -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 00:38:15 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26197 for ; Thu, 15 Feb 2001 00:38:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B2D3544337; Thu, 15 Feb 2001 00:38:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailweb14.rediffmail.com (unknown [203.199.83.26]) by lists.bell-labs.com (Postfix) with SMTP id EAAFD44336 for ; Thu, 15 Feb 2001 00:37:08 -0500 (EST) Received: (qmail 14247 invoked by uid 510); 15 Feb 2001 05:29:33 -0000 Message-ID: <20010215052933.14245.qmail@mailweb14.rediffmail.com> Received: from unknown (203.197.174.48) by rediffmail.com via HTTP; 15 Feb 2001 05:29:33 -0000 MIME-Version: 1.0 To: "sip@lists.bell-labs.com" From: "Vijeth D" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Subject: [SIP] Doubt in the RFC Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 15 Feb 2001 05:29:33 -0000 Content-Transfer-Encoding: 7bit Hi, I would like to know if the rfc bis-02 has to be followed while implementing SIP or the original RFC. Because there are some deviations are present which are not mentioned in the changes section. regards, Vijeth _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 02:11:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA10845 for ; Thu, 15 Feb 2001 02:11:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 190D244349; Thu, 15 Feb 2001 02:11:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailweb24.rediffmail.com (unknown [203.199.83.148]) by lists.bell-labs.com (Postfix) with SMTP id 5ABAF44336 for ; Thu, 15 Feb 2001 02:10:55 -0500 (EST) Received: (qmail 11135 invoked by uid 510); 15 Feb 2001 07:02:29 -0000 Message-ID: <20010215070229.11134.qmail@mailweb24.rediffmail.com> Received: from unknown (202.54.89.91) by rediffmail.com via HTTP; 15 Feb 2001 07:02:29 -0000 MIME-Version: 1.0 To: "sip@lists.bell-labs.com" From: "Vijeth D" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Subject: [SIP] regarding location servers and sip registrars Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 15 Feb 2001 07:02:29 -0000 Content-Transfer-Encoding: 7bit Hi, 1. The rfc specifies that the communication b/n the proxies and the location servers is out of scope of the document. Can anybody tell me what document or rfc to refer to understand about this communication. 2. Also there is not much information about the functioning of the SIP registrars in the RFC. Is there any document or draft specifying the same.? regards, Vijeth _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 02:52:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11162 for ; Thu, 15 Feb 2001 02:52:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 618F044343; Thu, 15 Feb 2001 02:52:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dns1.catt.ac.cn (unknown [202.106.106.98]) by lists.bell-labs.com (Postfix) with ESMTP id 9A9C444336 for ; Thu, 15 Feb 2001 02:50:14 -0500 (EST) Received: from liangxg (202.106.106.126 [202.106.106.126]) by dns1.catt.ac.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1LD94H53; Thu, 15 Feb 2001 15:37:30 +0800 Message-ID: <001501c09722$dd545e30$75ce12ac@MCSD.local> From: "Xingang Liang" To: Cc: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C09765.E85B9120" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] An installation question! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 15:42:31 +0800 This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C09765.E85B9120 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksZXZlcnkgb25lLA0KSSBlbmNvdW50ZWQgc29tZSBwcm9ibGVtIGFuZCBjb21lIGhlcmUgZm9y IHF1ZXN0aW9uIGFuZCBob3BlIHlvdSBjYW4gaGVscCBtZSENCkkgd29uZGVyIGlmIHNvbWVib2R5 IGhhcyBpbnN0YWxsZWQgdGhlIFVzZXJfQWdlbnQgb2YgVWJpcXVlbnQgY29tcGFueSBmcm9tIHd3 dy5zaXBjZW50ZXIuY29tICxpZiB5ZXMsIEkgd2FudCB0byBrbm93IHdoeSBJIGNhbid0IGluaXRp YWxpemUgdGhlIHVzZXIgaW50ZXJmYWNlICxJIGRpZCB3aGF0IEkgc2hvdWxkIGRvIGFjY29yZGlu ZyB0byB0aGUgdWFfaW5zdGFsbGF0aW9uX25vdGVzLnBkZiBhbmQgV2hlbiBJIGNvbm5lY3RlZCB0 byB0aGUgd2Vic2l0ZSBodHRwOi8vbG9jYWxob3N0OjQwODAvIGFuZCByZWFjdGl2YXRlZCB0aGUg bGljZW5zZSBrZXkgLHByZXNzaW5nIHRoZSBidXR0b24gInJldHJ5Iix0aGVuIEkgY2FuJ3QgZm91 bmQgYW55dGhpbmcgb24gbXkgc2NyZWVuLHdoYXQgaGFwcGVuZWQ/DQpXaGF0IHNob3VsZCBJIGRv IHRvIGFjdGl2ZSB0aGUgVXNlcl9hZ2VudCdzIEdVST8NCkhvcGUgdG8gZ2V0IHJlc3BvbnNlIHF1 aWNrbHkgYW5kIEkgYW0gZWFnZXIgdG8gdXNlIGl0IHRvIHRlc3QgU0lQIHVzYWdlLg0KVGhhbmsg eW91IGZpcnN0IGhlcmUgd2l0aCBteSBiZXN0IHJlZ2FyZHMNCg0KDQoNClhpbmdhbmcgTGlhbmcN ClN0YW5kYXJkaXphdGlvbiBEZXBhcnRtZW50DQpNb2JpbGUgQ29tbXVuaWNhdGlvbiBSJkQgQ2Vu dGVyDQpDaGluYSBBY2FkZW15IG9mIFRlbGVjb21tdW5pY2F0aW9uIFRlY2hub2xvZ3koQ0FUVCkN Ck5vLjQwLFh1ZXl1YW4gUm9hZA0KQmVpamluZyxDaGluYQ0KMTAwMDgzDQpUZWw6Kzg2MTAgNjIz MDQ0MjJFWFQyMjUNCkZheDorODYxMCA2MjMwMzEyNw0KTWFpbHRvOmxpYW5neGdAY2F0dC5hYy5j bg0KIA0KIA0K ------=_NextPart_000_0012_01C09765.E85B9120 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PEJBU0UgDQpocmVmPSJmaWxlOi8vQzpcUHJv Z3JhbSBGaWxlc1xDb21tb24gRmlsZXNcTWljcm9zb2Z0IFNoYXJlZFxTdGF0aW9uZXJ5XCI+DQo8 U1RZTEU+Qk9EWSB7DQoJQkFDS0dST1VORC1QT1NJVElPTjogbGVmdCB0b3A7IEJBQ0tHUk9VTkQt UkVQRUFUOiBuby1yZXBlYXQ7IENPTE9SOiAjMDAwMDAwOyBGT05ULUZBTUlMWTogQ291cmllciBO ZXcgQ0U7IEZPTlQtU0laRTogMTBwdDsgTUFSR0lOLUxFRlQ6IDI1cHg7IE1BUkdJTi1UT1A6IDI1 cHgNCn0NCjwvU1RZTEU+DQoNCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjAwLjMxMDMuMTAwMCIg bmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj5IaSxl dmVyeSBvbmUsPC9ESVY+DQo8RElWPkkgZW5jb3VudGVkIHNvbWUgcHJvYmxlbSBhbmQgY29tZSBo ZXJlIGZvciBxdWVzdGlvbiBhbmQgaG9wZSB5b3UgY2FuIGhlbHAgDQptZSE8L0RJVj4NCjxESVY+ SSB3b25kZXIgaWYgc29tZWJvZHkgaGFzIGluc3RhbGxlZCB0aGUgVXNlcl9BZ2VudCBvZiBVYmlx dWVudCBjb21wYW55IGZyb20gDQo8QSBocmVmPSJodHRwOi8vd3d3LnNpcGNlbnRlci5jb20iPnd3 dy5zaXBjZW50ZXIuY29tPC9BPiAsaWYgeWVzLCBJIHdhbnQgdG8ga25vdyANCndoeSBJIGNhbid0 IGluaXRpYWxpemUgdGhlIHVzZXIgaW50ZXJmYWNlICxJIGRpZCB3aGF0IEkgc2hvdWxkIGRvIGFj Y29yZGluZyB0byANCnRoZSB1YV9pbnN0YWxsYXRpb25fbm90ZXMucGRmIGFuZCBXaGVuIEkgY29u bmVjdGVkIHRvIHRoZSB3ZWJzaXRlIDxBIA0KaHJlZj0iaHR0cDovL2xvY2FsaG9zdDo0MDgwLyI+ aHR0cDovL2xvY2FsaG9zdDo0MDgwLzwvQT4gYW5kIHJlYWN0aXZhdGVkIHRoZSANCmxpY2Vuc2Ug a2V5ICxwcmVzc2luZyB0aGUgYnV0dG9uICJyZXRyeSIsdGhlbiBJIGNhbid0IGZvdW5kIGFueXRo aW5nIG9uIG15IA0Kc2NyZWVuLHdoYXQgaGFwcGVuZWQ/PC9ESVY+DQo8RElWPldoYXQgc2hvdWxk IEkgZG8gdG8gYWN0aXZlIHRoZSBVc2VyX2FnZW50J3MgR1VJPzwvRElWPg0KPERJVj5Ib3BlIHRv IGdldCByZXNwb25zZSBxdWlja2x5IGFuZCBJIGFtIGVhZ2VyIHRvIHVzZSBpdCB0byB0ZXN0IFNJ UCANCnVzYWdlLjwvRElWPg0KPERJVj5UaGFuayB5b3UgZmlyc3QgaGVyZSB3aXRoIG15IGJlc3Qg cmVnYXJkczwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj5YaW5nYW5nIExpYW5nPEJSPlN0YW5kYXJkaXphdGlvbiBEZXBh cnRtZW50PEJSPk1vYmlsZSBDb21tdW5pY2F0aW9uIFImYW1wO0QgDQpDZW50ZXI8QlI+Q2hpbmEg QWNhZGVteSBvZiBUZWxlY29tbXVuaWNhdGlvbiBUZWNobm9sb2d5KENBVFQpPEJSPk5vLjQwLFh1 ZXl1YW4gDQpSb2FkPEJSPkJlaWppbmcsQ2hpbmE8QlI+MTAwMDgzPEJSPlRlbDorODYxMCA2MjMw NDQyMkVYVDIyNTxCUj5GYXg6Kzg2MTAgDQo2MjMwMzEyNzxCUj48QSANCmhyZWY9Im1haWx0bzps aWFuZ3hnQGNhdHQuYWMuY24iPk1haWx0bzpsaWFuZ3hnQGNhdHQuYWMuY248L0E+PEJSPiZuYnNw OzxCUj4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0012_01C09765.E85B9120-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 03:58:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11629 for ; Thu, 15 Feb 2001 03:58:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B914044343; Thu, 15 Feb 2001 03:58:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dns1.catt.ac.cn (unknown [202.106.106.98]) by lists.bell-labs.com (Postfix) with ESMTP id D726144336 for ; Thu, 15 Feb 2001 03:57:31 -0500 (EST) Received: from liangxg (202.106.106.126 [202.106.106.126]) by dns1.catt.ac.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1LD942AM; Thu, 15 Feb 2001 16:51:07 +0800 Message-ID: <000e01c0972d$265c4e80$75ce12ac@MCSD.local> From: "Xingang Liang" To: Cc: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C09770.30CF57C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] An installation question! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 16:56:07 +0800 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C09770.30CF57C0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksZXZlcnkgb25lLA0KSSBlbmNvdW50ZWQgc29tZSBwcm9ibGVtIGFuZCBjb21lIGhlcmUgZm9y IHF1ZXN0aW9uIGFuZCBob3BlIHlvdSBjYW4gaGVscCBtZSENCkkgd29uZGVyIGlmIHNvbWVib2R5 IGhhcyBpbnN0YWxsZWQgdGhlIFVzZXJfQWdlbnQgb2YgVWJpcXVlbnQgY29tcGFueSBmcm9tIHd3 dy5zaXBjZW50ZXIuY29tICxpZiB5ZXMsIEkgd2FudCB0byBrbm93IHdoeSBJIGNhbid0IGluaXRp YWxpemUgdGhlIHVzZXIgaW50ZXJmYWNlICxJIGRpZCB3aGF0IEkgc2hvdWxkIGRvIGFjY29yZGlu ZyB0byB0aGUgdWFfaW5zdGFsbGF0aW9uX25vdGVzLnBkZiBhbmQgV2hlbiBJIGNvbm5lY3RlZCB0 byB0aGUgd2Vic2l0ZSBodHRwOi8vbG9jYWxob3N0OjQwODAvIGFuZCByZWFjdGl2YXRlZCB0aGUg bGljZW5zZSBrZXkgLHByZXNzaW5nIHRoZSBidXR0b24gInJldHJ5Iix0aGVuIEkgY2FuJ3QgZm91 bmQgYW55dGhpbmcgb24gbXkgc2NyZWVuLHdoYXQgaGFwcGVuZWQ/DQpXaGF0IHNob3VsZCBJIGRv IHRvIGFjdGl2ZSB0aGUgVXNlcl9hZ2VudCdzIEdVST8NCkhvcGUgdG8gZ2V0IHJlc3BvbnNlIHF1 aWNrbHkgYW5kIEkgYW0gZWFnZXIgdG8gdXNlIGl0IHRvIHRlc3QgU0lQIHVzYWdlLg0KVGhhbmsg eW91IGZpcnN0IGhlcmUgd2l0aCBteSBiZXN0IHJlZ2FyZHMNCg0KDQoNClhpbmdhbmcgTGlhbmcN ClN0YW5kYXJkaXphdGlvbiBEZXBhcnRtZW50DQpNb2JpbGUgQ29tbXVuaWNhdGlvbiBSJkQgQ2Vu dGVyDQpDaGluYSBBY2FkZW15IG9mIFRlbGVjb21tdW5pY2F0aW9uIFRlY2hub2xvZ3koQ0FUVCkN Ck5vLjQwLFh1ZXl1YW4gUm9hZA0KQmVpamluZyxDaGluYQ0KMTAwMDgzDQpUZWw6Kzg2MTAgNjIz MDQ0MjJFWFQyMjUNCkZheDorODYxMCA2MjMwMzEyNw0KTWFpbHRvOmxpYW5neGdAY2F0dC5hYy5j bg0KIA0KIA0K ------=_NextPart_000_000B_01C09770.30CF57C0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PEJBU0UgDQpocmVmPSJmaWxlOi8vQzpcUHJv Z3JhbSBGaWxlc1xDb21tb24gRmlsZXNcTWljcm9zb2Z0IFNoYXJlZFxTdGF0aW9uZXJ5XCI+DQo8 U1RZTEU+Qk9EWSB7DQoJQkFDS0dST1VORC1QT1NJVElPTjogbGVmdCB0b3A7IEJBQ0tHUk9VTkQt UkVQRUFUOiBuby1yZXBlYXQ7IENPTE9SOiAjMDAwMDAwOyBGT05ULUZBTUlMWTogQ291cmllciBO ZXcgQ0U7IEZPTlQtU0laRTogMTBwdDsgTUFSR0lOLUxFRlQ6IDI1cHg7IE1BUkdJTi1UT1A6IDI1 cHgNCn0NCjwvU1RZTEU+DQoNCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjAwLjMxMDMuMTAwMCIg bmFtZT1HRU5FUkFUT1I+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4wMC4zMTAzLjEwMDAiIG5h bWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+SGksZXZl cnkgb25lLDwvRElWPg0KPERJVj5JIGVuY291bnRlZCBzb21lIHByb2JsZW0gYW5kIGNvbWUgaGVy ZSBmb3IgcXVlc3Rpb24gYW5kIGhvcGUgeW91IGNhbiBoZWxwIA0KbWUhPC9ESVY+DQo8RElWPkkg d29uZGVyIGlmIHNvbWVib2R5IGhhcyBpbnN0YWxsZWQgdGhlIFVzZXJfQWdlbnQgb2YgVWJpcXVl bnQgY29tcGFueSBmcm9tIA0KPEEgaHJlZj0iaHR0cDovL3d3dy5zaXBjZW50ZXIuY29tIj53d3cu c2lwY2VudGVyLmNvbTwvQT4gLGlmIHllcywgSSB3YW50IHRvIGtub3cgDQp3aHkgSSBjYW4ndCBp bml0aWFsaXplIHRoZSB1c2VyIGludGVyZmFjZSAsSSBkaWQgd2hhdCBJIHNob3VsZCBkbyBhY2Nv cmRpbmcgdG8gDQp0aGUgdWFfaW5zdGFsbGF0aW9uX25vdGVzLnBkZiBhbmQgV2hlbiBJIGNvbm5l Y3RlZCB0byB0aGUgd2Vic2l0ZSA8QSANCmhyZWY9Imh0dHA6Ly9sb2NhbGhvc3Q6NDA4MC8iPmh0 dHA6Ly9sb2NhbGhvc3Q6NDA4MC88L0E+IGFuZCByZWFjdGl2YXRlZCB0aGUgDQpsaWNlbnNlIGtl eSAscHJlc3NpbmcgdGhlIGJ1dHRvbiAicmV0cnkiLHRoZW4gSSBjYW4ndCBmb3VuZCBhbnl0aGlu ZyBvbiBteSANCnNjcmVlbix3aGF0IGhhcHBlbmVkPzwvRElWPg0KPERJVj5XaGF0IHNob3VsZCBJ IGRvIHRvIGFjdGl2ZSB0aGUgVXNlcl9hZ2VudCdzIEdVST88L0RJVj4NCjxESVY+SG9wZSB0byBn ZXQgcmVzcG9uc2UgcXVpY2tseSBhbmQgSSBhbSBlYWdlciB0byB1c2UgaXQgdG8gdGVzdCBTSVAg DQp1c2FnZS48L0RJVj4NCjxESVY+VGhhbmsgeW91IGZpcnN0IGhlcmUgd2l0aCBteSBiZXN0IHJl Z2FyZHM8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+WGluZ2FuZyBMaWFuZzxCUj5TdGFuZGFyZGl6YXRpb24gRGVwYXJ0 bWVudDxCUj5Nb2JpbGUgQ29tbXVuaWNhdGlvbiBSJmFtcDtEIA0KQ2VudGVyPEJSPkNoaW5hIEFj YWRlbXkgb2YgVGVsZWNvbW11bmljYXRpb24gVGVjaG5vbG9neShDQVRUKTxCUj5Oby40MCxYdWV5 dWFuIA0KUm9hZDxCUj5CZWlqaW5nLENoaW5hPEJSPjEwMDA4MzxCUj5UZWw6Kzg2MTAgNjIzMDQ0 MjJFWFQyMjU8QlI+RmF4Ois4NjEwIA0KNjIzMDMxMjc8QlI+PEEgDQpocmVmPSJtYWlsdG86bGlh bmd4Z0BjYXR0LmFjLmNuIj5NYWlsdG86bGlhbmd4Z0BjYXR0LmFjLmNuPC9BPjxCUj4mbmJzcDs8 QlI+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_000B_01C09770.30CF57C0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 04:01:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11664 for ; Thu, 15 Feb 2001 04:01:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 34BAF44359; Thu, 15 Feb 2001 04:01:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dns1.catt.ac.cn (unknown [202.106.106.98]) by lists.bell-labs.com (Postfix) with ESMTP id CD75B44336 for ; Thu, 15 Feb 2001 04:00:40 -0500 (EST) Received: from liangxg (202.106.106.126 [202.106.106.126]) by dns1.catt.ac.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1LD942AW; Thu, 15 Feb 2001 16:54:36 +0800 Message-ID: <003701c0972d$a2d93400$75ce12ac@MCSD.local> From: "Xingang Liang" To: Cc: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0034_01C09770.AD801E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] An installation question! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 16:59:36 +0800 This is a multi-part message in MIME format. ------=_NextPart_000_0034_01C09770.AD801E80 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksZXZlcnkgb25lLA0KSSBlbmNvdW50ZWQgc29tZSBwcm9ibGVtIGFuZCBjb21lIGhlcmUgZm9y IHF1ZXN0aW9uIGFuZCBob3BlIHlvdSBjYW4gaGVscCBtZSENCkkgd29uZGVyIGlmIHNvbWVib2R5 IGhhcyBpbnN0YWxsZWQgdGhlIFVzZXJfQWdlbnQgb2YgVWJpcXVlbnQgY29tcGFueSBmcm9tIHd3 dy5zaXBjZW50ZXIuY29tICxpZiB5ZXMsIEkgd2FudCB0byBrbm93IHdoeSBJIGNhbid0IGluaXRp YWxpemUgdGhlIHVzZXIgaW50ZXJmYWNlICxJIGRpZCB3aGF0IEkgc2hvdWxkIGRvIGFjY29yZGlu ZyB0byB0aGUgdWFfaW5zdGFsbGF0aW9uX25vdGVzLnBkZiBhbmQgV2hlbiBJIGNvbm5lY3RlZCB0 byB0aGUgd2Vic2l0ZSBodHRwOi8vbG9jYWxob3N0OjQwODAvIGFuZCByZWFjdGl2YXRlZCB0aGUg bGljZW5zZSBrZXkgLHByZXNzaW5nIHRoZSBidXR0b24gInJldHJ5Iix0aGVuIEkgY2FuJ3QgZm91 bmQgYW55dGhpbmcgb24gbXkgc2NyZWVuLHdoYXQgaGFwcGVuZWQ/DQpXaGF0IHNob3VsZCBJIGRv IHRvIGFjdGl2ZSB0aGUgVXNlcl9hZ2VudCdzIEdVST8NCkhvcGUgdG8gZ2V0IHJlc3BvbnNlIHF1 aWNrbHkgYW5kIEkgYW0gZWFnZXIgdG8gdXNlIGl0IHRvIHRlc3QgU0lQIHVzYWdlLg0KVGhhbmsg eW91IGZpcnN0IGhlcmUgd2l0aCBteSBiZXN0IHJlZ2FyZHMNCg0KDQoNClhpbmdhbmcgTGlhbmcN ClN0YW5kYXJkaXphdGlvbiBEZXBhcnRtZW50DQpNb2JpbGUgQ29tbXVuaWNhdGlvbiBSJkQgQ2Vu dGVyDQpDaGluYSBBY2FkZW15IG9mIFRlbGVjb21tdW5pY2F0aW9uIFRlY2hub2xvZ3koQ0FUVCkN Ck5vLjQwLFh1ZXl1YW4gUm9hZA0KQmVpamluZyxDaGluYQ0KMTAwMDgzDQpUZWw6Kzg2MTAgNjIz MDQ0MjJFWFQyMjUNCkZheDorODYxMCA2MjMwMzEyNw0KTWFpbHRvOmxpYW5neGdAY2F0dC5hYy5j bg0KIA0KIA0K ------=_NextPart_000_0034_01C09770.AD801E80 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PEJBU0UgDQpocmVmPSJmaWxlOi8vQzpcUHJv Z3JhbSBGaWxlc1xDb21tb24gRmlsZXNcTWljcm9zb2Z0IFNoYXJlZFxTdGF0aW9uZXJ5XCI+DQo8 U1RZTEU+Qk9EWSB7DQoJQkFDS0dST1VORC1QT1NJVElPTjogbGVmdCB0b3A7IEJBQ0tHUk9VTkQt UkVQRUFUOiBuby1yZXBlYXQ7IENPTE9SOiAjMDAwMDAwOyBGT05ULUZBTUlMWTogQ291cmllciBO ZXcgQ0U7IEZPTlQtU0laRTogMTBwdDsgTUFSR0lOLUxFRlQ6IDI1cHg7IE1BUkdJTi1UT1A6IDI1 cHgNCn0NCjwvU1RZTEU+DQoNCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjAwLjMxMDMuMTAwMCIg bmFtZT1HRU5FUkFUT1I+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS4wMC4zMTAzLjEwMDAiIG5h bWU9R0VORVJBVE9SPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDUuMDAuMzEwMy4xMDAwIiBuYW1l PUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPkhpLGV2ZXJ5 IG9uZSw8L0RJVj4NCjxESVY+SSBlbmNvdW50ZWQgc29tZSBwcm9ibGVtIGFuZCBjb21lIGhlcmUg Zm9yIHF1ZXN0aW9uIGFuZCBob3BlIHlvdSBjYW4gaGVscCANCm1lITwvRElWPg0KPERJVj5JIHdv bmRlciBpZiBzb21lYm9keSBoYXMgaW5zdGFsbGVkIHRoZSBVc2VyX0FnZW50IG9mIFViaXF1ZW50 IGNvbXBhbnkgZnJvbSANCjxBIGhyZWY9Imh0dHA6Ly93d3cuc2lwY2VudGVyLmNvbSI+d3d3LnNp cGNlbnRlci5jb208L0E+ICxpZiB5ZXMsIEkgd2FudCB0byBrbm93IA0Kd2h5IEkgY2FuJ3QgaW5p dGlhbGl6ZSB0aGUgdXNlciBpbnRlcmZhY2UgLEkgZGlkIHdoYXQgSSBzaG91bGQgZG8gYWNjb3Jk aW5nIHRvIA0KdGhlIHVhX2luc3RhbGxhdGlvbl9ub3Rlcy5wZGYgYW5kIFdoZW4gSSBjb25uZWN0 ZWQgdG8gdGhlIHdlYnNpdGUgPEEgDQpocmVmPSJodHRwOi8vbG9jYWxob3N0OjQwODAvIj5odHRw Oi8vbG9jYWxob3N0OjQwODAvPC9BPiBhbmQgcmVhY3RpdmF0ZWQgdGhlIA0KbGljZW5zZSBrZXkg LHByZXNzaW5nIHRoZSBidXR0b24gInJldHJ5Iix0aGVuIEkgY2FuJ3QgZm91bmQgYW55dGhpbmcg b24gbXkgDQpzY3JlZW4sd2hhdCBoYXBwZW5lZD88L0RJVj4NCjxESVY+V2hhdCBzaG91bGQgSSBk byB0byBhY3RpdmUgdGhlIFVzZXJfYWdlbnQncyBHVUk/PC9ESVY+DQo8RElWPkhvcGUgdG8gZ2V0 IHJlc3BvbnNlIHF1aWNrbHkgYW5kIEkgYW0gZWFnZXIgdG8gdXNlIGl0IHRvIHRlc3QgU0lQIA0K dXNhZ2UuPC9ESVY+DQo8RElWPlRoYW5rIHlvdSBmaXJzdCBoZXJlIHdpdGggbXkgYmVzdCByZWdh cmRzPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPlhpbmdhbmcgTGlhbmc8QlI+U3RhbmRhcmRpemF0aW9uIERlcGFydG1l bnQ8QlI+TW9iaWxlIENvbW11bmljYXRpb24gUiZhbXA7RCANCkNlbnRlcjxCUj5DaGluYSBBY2Fk ZW15IG9mIFRlbGVjb21tdW5pY2F0aW9uIFRlY2hub2xvZ3koQ0FUVCk8QlI+Tm8uNDAsWHVleXVh biANClJvYWQ8QlI+QmVpamluZyxDaGluYTxCUj4xMDAwODM8QlI+VGVsOis4NjEwIDYyMzA0NDIy RVhUMjI1PEJSPkZheDorODYxMCANCjYyMzAzMTI3PEJSPjxBIA0KaHJlZj0ibWFpbHRvOmxpYW5n eGdAY2F0dC5hYy5jbiI+TWFpbHRvOmxpYW5neGdAY2F0dC5hYy5jbjwvQT48QlI+Jm5ic3A7PEJS PiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0034_01C09770.AD801E80-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 04:08:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11691 for ; Thu, 15 Feb 2001 04:08:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 19C4944363; Thu, 15 Feb 2001 04:08:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id C5ED244362 for ; Thu, 15 Feb 2001 04:07:16 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 15 Feb 2001 09:07:16 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA09229; Thu, 15 Feb 2001 09:04:55 GMT Message-ID: <3A8B9BB6.7E1A1AF3@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Xingang Liang Cc: sip@vovida.org, sip@lists.bell-labs.com Subject: Re: [SIP] An installation question! References: <001501c09722$dd545e30$75ce12ac@MCSD.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 09:04:54 +0000 Content-Transfer-Encoding: 7bit Please post the question to the correct place - the SIP Center support forums. Thanks, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net > Xingang Liang wrote: > > Hi,every one, > I encounted some problem and come here for question and hope > you can help me! > I wonder if somebody has installed the User_Agent of Ubiquent > company from www.sipcenter.com ,if yes, I want to know why I > can't initialize the user interface ,I did what I should do > according to the ua_installation_notes.pdf and When I connected > to the website http://localhost:4080/ and reactivated the > license key ,pressing the button "retry",then I can't found > anything on my screen,what happened? > What should I do to active the User_agent's GUI? > Hope to get response quickly and I am eager to use it to test > SIP usage. > Thank you first here with my best regards _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 04:53:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12045 for ; Thu, 15 Feb 2001 04:53:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3489444358; Thu, 15 Feb 2001 04:53:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 6E12F44336 for ; Thu, 15 Feb 2001 04:52:57 -0500 (EST) 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 f1F9psC15528; Thu, 15 Feb 2001 10:51:54 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA29466; Thu, 15 Feb 2001 11:51:48 +0200 (EET) Message-ID: <3A8BA6B3.2CE510DC@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: sip@lists.bell-labs.com, Gonzalo Camarillo , Jonathan Rosenberg , "'Tom-PT Taylor'" Subject: Re: [SIP] Operlap dialing within a SIP network References: <802569F3.00502AD6.00@marconicomms.com> Content-Type: multipart/mixed; boundary="------------A3743693A754BE1A2A70E8AF" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 11:51:47 +0200 This is a multi-part message in MIME format. --------------A3743693A754BE1A2A70E8AF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Keith Robinson wrote: > >Hi, > >Christer wrote : > > > >>I think that the administrator proxies in the network should be >>able to handle that, e.g. either by refusing the message (a proxy should >>have the last say about if a message is allowed to be routed in a >>specific way or not), sending a 3xx response (to re-route the call), or >>simply by removing the ROUTE header (I know that is not allowed, but the >>there is also an issue of allowing ROUTE in the initial INVITE in the >>first place, so...). In another mail I pointed out that the network >>operator administrator most likely wants to have good control of the >>network, so I think it should be allowed for proxies to do these kind of >>things. > >This is exactly my concern. What if proxies are configured to reject or >ignore the ROUTE header of requests which are attempting to source route. >The initial INVITEs sending subsequent digits may not reach the (correct) >UAS if they had to traverse such networks and so the mechanism would >fail. I don't see this as a protocol issue, but more how the operator has built and configured his network. Also, you have the same problem in other cases too, eg with the session-timer. If a server reboots, when it is going to receive the refresh re-INVITE it is going to process it as an INVITE for a new call, and there may be ROUTE headers in that INVITE, so... And, I don't see how you solve this issue by using INFO. You still have to send at least one initial INVITE, in which your UA, for some reason, may insert ROUTE headers. Again, in this case I don't see it as a problem if a proxy will reject that, because I think the proxies should decide about the routing, not the UA. However, like I mentioned earlier, it IS a problem with the session-timer... Regards, Christer Holmberg Ericsson Finland > > Regards, > > K. Robinson. > > Christer Holmberg on 14/02/2001 10:53:31 > > > > > > > > To: sip@lists.bell-labs.com > > cc: Keith Robinson/MAIN/MC1@MCMAIN, Gonzalo Camarillo > , Jonathan > Rosenberg , "'Tom-PT > Taylor'" > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > Hi, > > I am not Gonzalo, but I will comment anyway... :) > > >Gonzalo, > > > >It seems you have two main reasons against the use of the INFO > >method for the conveyance of subsequent ISUP information: > > > >1) Lack of ordered delivery of the INFO messages > > > >Ordered delivery could be maintained by the UAC not sending the next INFO > >until a 200 OK response for the previous one had been received. > > I am strongly against that. We would have to start buffering incoming > SAMs, and by having to wait for the response before sending the next > INVITE it would slow down the setup time between the nodes. > > This is also related with the PRACK issue, where we also may have to do > buffering becuase we have to wait for messages (which means we may have > to do buffering), but that is another issue... > > >2) Lack of state carried in the INFO messge > > > >The digits received so far could be carried in a header within the > >INFO message. Each INFO message would then carry the same information > >as a re-INVITE. > > > >My reason for exploring the use of INFO is not to save on messages. It is > >to do with the issue of source routing. Again, my concern of source > >routing is not one of a technical nature. What if an administration has a > >security policy that states source routing (a ROUTE header in > >an initial INVITE) will not take place in its SIP network but it also >requires > that the same network interworks with the PSTN; if any part of >the PSTN > interworking mechanism relies on source routing then there is a >conflict of > requirements. It is this conflict > >I wish to address. > > I am not sure I understood this correctly. But, in either case the UAC > will have to send an initial INVITE, so it can choose to insert a ROUTE > header. I think that the administrator proxies in the network should be > able to handle that, e.g. either by refusing the message (a proxy should > have the last say about if a message is allowed to be routed in a > specific way or not), sending a 3xx response (to re-route the call), or > simply by removing the ROUTE header (I know that is not allowed, but the > there is also an issue of allowing ROUTE in the initial INVITE in the > first place, so...). In another mail I pointed out that the network > operator administrator most likely wants to have good control of the > network, so I think it should be allowed for proxies to do these kind of > things. Otherwise one can send anything in the requests, and soon we > will have a bunch of "SIP Viruses" out there... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Regards, > > > > K. Robinson. > > > > Gonzalo Camarillo on 01/01/88 00:39:14 > > > > > > > > > > > > > > > > To: Jonathan Rosenberg > > > > cc: "'Tom-PT Taylor'" , > > Christer Holmberg > > , > > sip@lists.bell-labs.com(bcc: Keith > > Robinson/MAIN/MC1) > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > Hello, > > > > Jonathan Rosenberg wrote: > > > > > > I think the correct answer about which approach to use (INFO vs. multiple > > > call legs) depends on your view of the scope of the address within the sip > > > cloud. If you believe that the sip role has ended once you have enough > > > digits to select an egress gateway (which may be as few as one, i.e., +1 > > > selects a US gateway), then the sip address of that gateway can be viewed as > > > sip:+1@provider.com, and all subsequent digits are PSTN issues, outside the > > > scope of SIP. > > > > I definitively agree that this is the view that INFO fans have of a SIP > > cloud. What I am saying is that this view is wrong. This usage of SIP > > falls outside the scope of SIP. > > If they want to use SIP for locating a gateway, it is fine. But after > > the gateway has been located, let's use another method for transporting > > ISUP signalling. > > > > Let's assume that I get an IAM with "+1", as Jonathan says in his > > example. Then the INVITE generated by the gateway will reach the US > > gateway. Now, the mission of SIP has finished, since the gateway has > > been located. Why don't we put in the body of this INVITE a session > > description that comprises a media session and a SIGTRAN session? This > > way we would have established these two sessions between the gateways > > and all the subsequent ISUP messages would be sent over the SIGTRAN > > session. > > > > I find that the usage of SIP that I have just described would be OK. > > What I do not understand is why folks want to use SIP for transporting > > subsequent ISUP messages. SIP does not have good transport properties > > (big overhead, it can run over UDP...). Besides, it does not provide > > ordered delivery. > > > > If the INVITE has Cseq=1 and the next message that the egrees gateway > > receives is a INFO with Cseq=7... what should the gateway do? Maybe > > there were several proxies in the middle asking for credentials for the > > INFO, so the ingrees gateway had to add authentication stuff and resend > > the INFO. If this was the case, the SAM contained in the INFO would be > > the second digit of the called party number... However, maybe 5 INFO > > messages got lost, and the SAM that we have received in the body of the > > INFO makes no sense without the previous ones because is the 7th digit > > of the number... > > > > This is not usually a problem in SIP, since all messages have full > > state. However, using INFO for sending SAMs breaks this rule, and > > therefore it breaks the SIP model. > > > > I believe that considering that the session is established after the > > first INVITE and sending the following SAMs using INFO is making one of > > the mistakes described in the guidelines for SIP authors: "We need to > > transport ISUP signalling over IP between two gateways. Both gateways > > already implement SIP... why do we have to implement another protocol? > > Let's use SIP to transport ISUP signalling". We are just trying to use > > SIP for this just because it would save implementing yet another > > protocol in the gateways. > > > > I strongly disagree with this usage of SIP. SIP-T is good as long as the > > SIP cloud provides services. If not, SIP-T is not a good protocol for > > transporting ISUP signalling. > > > > Best regards, > > > > Gonzalo > > > > If you believe that the sip role encompasses functions that > > > might apply to the PSTN subscribers, then you need to have the entire > > > number, and the multiple call leg approach is the right way to go. > > > > > > The multiple call leg approach is clearly ugly and inelegant, but it has the > > > nice property of completely masking the existence of overlap from proxies > > > and app servers within the network, allowing them to provide services in the > > > normal way. > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > -----Original Message----- > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > Sent: Thursday, February 08, 2001 7:00 AM > > > To: Gonzalo Camarillo > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > > > You are correct about using some other means of transport if ISUP > > > trans-shipment is all your network is doing. If the call destination (to a > > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call > > > basis, however, using SIP to establish your call routing leads to using SIP > > > to carry the ISUP. > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hi Tom, > > > > > > > > Still I want to have full state in every SIP message. If the call is > > > > addresed to the phone number 1234, I want to have a to field that says > > > > 1234. I do not care if there is a leg routed thru the PSTN and another > > > > thru SIP. > > > > > > > > Carrying full state is one of the beauties of SIP. If we begin using > > > > INFO for this, it would be the same as using SAMs. Differen names, the > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > believe that > > > > if the session has a destination, it should be present in the > > > > to field. > > > > > > > > Again, if a proxy is providing services for this particular call, it > > > > will want to see the called party number in order to trigger > > > > the proper > > > > service. This is a very good reason for updating the to field > > > > every time > > > > we have more digits. > > > > > > > > I like to use SIP between two gateways because it is possible > > > > to provide > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > finding a > > > > egrees gateway, we would probably want to use other protocols (TRIP & > > > > SIGTRAN for instance). > > > > > > > > Regards, > > > > > > > > Gonzalo > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > statements is > > > > > that an INVITE has reached a UAS which has accepted it. It follows > > > > > that the UAS did not send back a 484, but rather an interim > > > > response. > > > > > IF more digits come along, the INFO method is there to carry them. > > > > > They do not affect the SIP call state; they are used beyond the UAS, > > > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > signalling > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > additional > > > > > > > digits will not change call state. It is therefore > > > > > > reasonable to use > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > ISUP-SIP, once > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > reached, the same > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > vanilla SIP UA. > > > > > I > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > subsequent INFO > > > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > > > gateway > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > Therefore, it is > > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > > > > carries ISUP messages between two gateways. For that, we have > > > > > already > > > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > > > call is a > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > state. And a > > > > > > SIP message with an incomplete to field does not carry complete > > > > > state. > > > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > > > based > > > > > > on the to field (called party number). That proxy would > > > > like to see > > > > > an > > > > > > updated to field, not just a to field that contains just some > > > > > digits. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Christer Holmberg > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > To: Gonzalo Camarillo > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > > > been proposed > > > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > > > reason for > > > > > > > > the discussion from the beginning was that the overlap > > > > > signalling, > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > very well, and > > > > > > > a > > > > > > > > solution using 18x responses and INFO messages, instead of 484 > > > > > and > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > > > > about calls > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > SIP UAS > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > > > --> > > > > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > > > the word 'proxy') > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > overlap dialing, to > > > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > > > the digits > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > > > be allowed to > > > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > > > INVITEs, until > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. --------------A3743693A754BE1A2A70E8AF 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 --------------A3743693A754BE1A2A70E8AF-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 05:45:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12338 for ; Thu, 15 Feb 2001 05:45:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4BCC344337; Thu, 15 Feb 2001 05:45:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 8ADC944336 for ; Thu, 15 Feb 2001 05:44:55 -0500 (EST) 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 f1FAg4C07694; Thu, 15 Feb 2001 11:42:04 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA02627; Thu, 15 Feb 2001 12:42:03 +0200 (EET) Message-ID: <3A8BB279.6AD22D06@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: Keith Robinson , Gonzalo Camarillo , Jonathan Rosenberg , "'Tom-PT Taylor'" Subject: Re: [SIP] Operlap dialing within a SIP network References: <802569F3.00502AD6.00@marconicomms.com> <3A8BA6B3.2CE510DC@lmf.ericsson.se> Content-Type: multipart/mixed; boundary="------------9A892893B162E4990BCED8F4" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 12:42:01 +0200 This is a multi-part message in MIME format. --------------9A892893B162E4990BCED8F4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, A comment to my own comment... Christer Holmberg wrote: > >Hi, > >Keith Robinson wrote: >> >>Hi, >> >>Christer wrote : >> >> >> >>>I think that the administrator proxies in the network should be >>>able to handle that, e.g. either by refusing the message (a proxy should >>>have the last say about if a message is allowed to be routed in a >>>specific way or not), sending a 3xx response (to re-route the call), or >>>simply by removing the ROUTE header (I know that is not allowed, but the >>>there is also an issue of allowing ROUTE in the initial INVITE in the >>>first place, so...). In another mail I pointed out that the network >>>operator administrator most likely wants to have good control of the >>>network, so I think it should be allowed for proxies to do these kind of >>>things. >> >>This is exactly my concern. What if proxies are configured to reject or >>ignore the ROUTE header of requests which are attempting to source route. >>The initial INVITEs sending subsequent digits may not reach the (correct) >>UAS if they had to traverse such networks and so the mechanism would >>fail. > >I don't see this as a protocol issue, but more how the operator has >built and configured his network. Also, you have the same problem in >other cases too, eg with the session-timer. If a server reboots, when it >is going to receive the refresh re-INVITE it is going to process it as >an INVITE for a new call, and there may be ROUTE headers in that INVITE, >so... > >And, I don't see how you solve this issue by using INFO. You still have >to send at least one initial INVITE, in which your UA, for some reason, >may insert ROUTE headers. Again, in this case I don't see it as a >problem if a proxy will reject that, because I think the proxies should >decide about the routing, not the UA. However, like I mentioned earlier, >it IS a problem with the session-timer... Actually, I realise you would have the ROUTE problem with EVERY INVITE you send. Since ROUTE is only per call-leg, and every INVITE represents a new call-leg, every INVITE you send would be processed as an INITIAL INVITE request by proxies and UAs, and if you include ROUTE headers you will have the same problem for every INVITE (using INFO, every message is sent for the same call-leg, so you will not have problems with ROUTE). Of course, nothing forces you to insert ROUTE headers in your next INVITE, since it represents a separate call-leg, but I assume the problem is that we often want to do so, to make sure they follow the same path. However, like I mentioned earlier, ROUTE in initial INVITEs is a general problem for SIP, so from that point of view using INFOs would only be a "hack" to get around an existing SIP problem. Regards, Christer Holmberg Ericsson Finland --------------9A892893B162E4990BCED8F4 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 --------------9A892893B162E4990BCED8F4-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 06:13:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12529 for ; Thu, 15 Feb 2001 06:13:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 707F244337; Thu, 15 Feb 2001 06:13:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis22.marconicomms.com (cvis22.marconicomms.com [195.99.244.54]) by lists.bell-labs.com (Postfix) with ESMTP id 569BE44336 for ; Thu, 15 Feb 2001 06:12:55 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis22.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 15 Feb 2001 11:13:06 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id LAA21184; Thu, 15 Feb 2001 11:12:52 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569F4.003D9360 ; Thu, 15 Feb 2001 11:12:34 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Christer Holmberg Cc: sip@lists.bell-labs.com, Gonzalo Camarillo , Jonathan Rosenberg , "'Tom-PT Taylor'" Message-ID: <802569F4.003D8F2A.00@marconicomms.com> Subject: Re: [SIP] Operlap dialing within a SIP network Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=pJNshxSL155bQh6AUjInOZsfqKwtHD2xFxiM71EOSR7WXq4YvX1fwUuP" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 11:12:15 +0000 --0__=pJNshxSL155bQh6AUjInOZsfqKwtHD2xFxiM71EOSR7WXq4YvX1fwUuP Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello, >I don't see this as a protocol issue, but more how the operator has >built and configured his network. Also, you have the same problem in >other cases too, eg with the session-timer. If a server reboots, when it >is going to receive the refresh re-INVITE it is going to process it as >an INVITE for a new call, and there may be ROUTE headers in that INVITE, >so... A proxy can be intelligent enough to distinguish between an initial INVITE with a ROUTE header (source routing) and a re-INVITE received after a reboot; in the case of the initial INVITE, the TO tag field MUST be empty; in the case of the re-INVITE after a reboot the TO tag field MUST NOT be empty. So a proxy can be configured to disallow source routing, while still able to support the session-timer re-INVITE after a reboot, thereby remaining robust. >And, I don't see how you solve this issue by using INFO. You still have >to send at least one initial INVITE, in which your UA, for some reason, >may insert ROUTE headers. Again, in this case I don't see it as a >problem if a proxy will reject that, because I think the proxies should >decide about the routing, not the UA. However, like I mentioned earlier, >it IS a problem with the session-timer... Of course, clients may attempt to source route, and such requests may well be rejected if they traverse a network with a security policy tha disallows it. Its an interoperability issue when going between administrative domains. Regards, K. Robinson Christer Holmberg on 15/02/2001 09:51:47 To: Keith Robinson/MAIN/MC1@MCMAIN cc: sip@lists.bell-labs.com, Gonzalo Camarillo , Jonathan Rosenberg , "'Tom-PT Taylor'" Subject: Re: [SIP] Operlap dialing within a SIP network Hi, Keith Robinson wrote: > >Hi, > >Christer wrote : > > > >>I think that the administrator proxies in the network should be >>able to handle that, e.g. either by refusing the message (a proxy should >>have the last say about if a message is allowed to be routed in a >>specific way or not), sending a 3xx response (to re-route the call), or >>simply by removing the ROUTE header (I know that is not allowed, but the >>there is also an issue of allowing ROUTE in the initial INVITE in the >>first place, so...). In another mail I pointed out that the network >>operator administrator most likely wants to have good control of the >>network, so I think it should be allowed for proxies to do these kind of >>things. > >This is exactly my concern. What if proxies are configured to reject or >ignore the ROUTE header of requests which are attempting to source route. >The initial INVITEs sending subsequent digits may not reach the (correct) >UAS if they had to traverse such networks and so the mechanism would >fail. I don't see this as a protocol issue, but more how the operator has built and configured his network. Also, you have the same problem in other cases too, eg with the session-timer. If a server reboots, when it is going to receive the refresh re-INVITE it is going to process it as an INVITE for a new call, and there may be ROUTE headers in that INVITE, so... And, I don't see how you solve this issue by using INFO. You still have to send at least one initial INVITE, in which your UA, for some reason, may insert ROUTE headers. Again, in this case I don't see it as a problem if a proxy will reject that, because I think the proxies should decide about the routing, not the UA. However, like I mentioned earlier, it IS a problem with the session-timer... Regards, Christer Holmberg Ericsson Finland > > Regards, > > K. Robinson. > > Christer Holmberg on 14/02/2001 10:53:31 > > > > > > > > To: sip@lists.bell-labs.com > > cc: Keith Robinson/MAIN/MC1@MCMAIN, Gonzalo Camarillo > , Jonathan > Rosenberg , "'Tom-PT > Taylor'" > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > Hi, > > I am not Gonzalo, but I will comment anyway... :) > > >Gonzalo, > > > >It seems you have two main reasons against the use of the INFO > >method for the conveyance of subsequent ISUP information: > > > >1) Lack of ordered delivery of the INFO messages > > > >Ordered delivery could be maintained by the UAC not sending the next INFO > >until a 200 OK response for the previous one had been received. > > I am strongly against that. We would have to start buffering incoming > SAMs, and by having to wait for the response before sending the next > INVITE it would slow down the setup time between the nodes. > > This is also related with the PRACK issue, where we also may have to do > buffering becuase we have to wait for messages (which means we may have > to do buffering), but that is another issue... > > >2) Lack of state carried in the INFO messge > > > >The digits received so far could be carried in a header within the > >INFO message. Each INFO message would then carry the same information > >as a re-INVITE. > > > >My reason for exploring the use of INFO is not to save on messages. It is > >to do with the issue of source routing. Again, my concern of source > >routing is not one of a technical nature. What if an administration has a > >security policy that states source routing (a ROUTE header in > >an initial INVITE) will not take place in its SIP network but it also >requires > that the same network interworks with the PSTN; if any part of >the PSTN > interworking mechanism relies on source routing then there is a >conflict of > requirements. It is this conflict > >I wish to address. > > I am not sure I understood this correctly. But, in either case the UAC > will have to send an initial INVITE, so it can choose to insert a ROUTE > header. I think that the administrator proxies in the network should be > able to handle that, e.g. either by refusing the message (a proxy should > have the last say about if a message is allowed to be routed in a > specific way or not), sending a 3xx response (to re-route the call), or > simply by removing the ROUTE header (I know that is not allowed, but the > there is also an issue of allowing ROUTE in the initial INVITE in the > first place, so...). In another mail I pointed out that the network > operator administrator most likely wants to have good control of the > network, so I think it should be allowed for proxies to do these kind of > things. Otherwise one can send anything in the requests, and soon we > will have a bunch of "SIP Viruses" out there... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Regards, > > > > K. Robinson. > > > > Gonzalo Camarillo on 01/01/88 00:39:14 > > > > > > > > > > > > > > > > To: Jonathan Rosenberg > > > > cc: "'Tom-PT Taylor'" , > > Christer Holmberg > > , > > sip@lists.bell-labs.com(bcc: Keith > > Robinson/MAIN/MC1) > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > Hello, > > > > Jonathan Rosenberg wrote: > > > > > > I think the correct answer about which approach to use (INFO vs. multiple > > > call legs) depends on your view of the scope of the address within the sip > > > cloud. If you believe that the sip role has ended once you have enough > > > digits to select an egress gateway (which may be as few as one, i.e., +1 > > > selects a US gateway), then the sip address of that gateway can be viewed as > > > sip:+1@provider.com, and all subsequent digits are PSTN issues, outside the > > > scope of SIP. > > > > I definitively agree that this is the view that INFO fans have of a SIP > > cloud. What I am saying is that this view is wrong. This usage of SIP > > falls outside the scope of SIP. > > If they want to use SIP for locating a gateway, it is fine. But after > > the gateway has been located, let's use another method for transporting > > ISUP signalling. > > > > Let's assume that I get an IAM with "+1", as Jonathan says in his > > example. Then the INVITE generated by the gateway will reach the US > > gateway. Now, the mission of SIP has finished, since the gateway has > > been located. Why don't we put in the body of this INVITE a session > > description that comprises a media session and a SIGTRAN session? This > > way we would have established these two sessions between the gateways > > and all the subsequent ISUP messages would be sent over the SIGTRAN > > session. > > > > I find that the usage of SIP that I have just described would be OK. > > What I do not understand is why folks want to use SIP for transporting > > subsequent ISUP messages. SIP does not have good transport properties > > (big overhead, it can run over UDP...). Besides, it does not provide > > ordered delivery. > > > > If the INVITE has Cseq=1 and the next message that the egrees gateway > > receives is a INFO with Cseq=7... what should the gateway do? Maybe > > there were several proxies in the middle asking for credentials for the > > INFO, so the ingrees gateway had to add authentication stuff and resend > > the INFO. If this was the case, the SAM contained in the INFO would be > > the second digit of the called party number... However, maybe 5 INFO > > messages got lost, and the SAM that we have received in the body of the > > INFO makes no sense without the previous ones because is the 7th digit > > of the number... > > > > This is not usually a problem in SIP, since all messages have full > > state. However, using INFO for sending SAMs breaks this rule, and > > therefore it breaks the SIP model. > > > > I believe that considering that the session is established after the > > first INVITE and sending the following SAMs using INFO is making one of > > the mistakes described in the guidelines for SIP authors: "We need to > > transport ISUP signalling over IP between two gateways. Both gateways > > already implement SIP... why do we have to implement another protocol? > > Let's use SIP to transport ISUP signalling". We are just trying to use > > SIP for this just because it would save implementing yet another > > protocol in the gateways. > > > > I strongly disagree with this usage of SIP. SIP-T is good as long as the > > SIP cloud provides services. If not, SIP-T is not a good protocol for > > transporting ISUP signalling. > > > > Best regards, > > > > Gonzalo > > > > If you believe that the sip role encompasses functions that > > > might apply to the PSTN subscribers, then you need to have the entire > > > number, and the multiple call leg approach is the right way to go. > > > > > > The multiple call leg approach is clearly ugly and inelegant, but it has the > > > nice property of completely masking the existence of overlap from proxies > > > and app servers within the network, allowing them to provide services in the > > > normal way. > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > -----Original Message----- > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > Sent: Thursday, February 08, 2001 7:00 AM > > > To: Gonzalo Camarillo > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > > > You are correct about using some other means of transport if ISUP > > > trans-shipment is all your network is doing. If the call destination (to a > > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call > > > basis, however, using SIP to establish your call routing leads to using SIP > > > to carry the ISUP. > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hi Tom, > > > > > > > > Still I want to have full state in every SIP message. If the call is > > > > addresed to the phone number 1234, I want to have a to field that says > > > > 1234. I do not care if there is a leg routed thru the PSTN and another > > > > thru SIP. > > > > > > > > Carrying full state is one of the beauties of SIP. If we begin using > > > > INFO for this, it would be the same as using SAMs. Differen names, the > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > believe that > > > > if the session has a destination, it should be present in the > > > > to field. > > > > > > > > Again, if a proxy is providing services for this particular call, it > > > > will want to see the called party number in order to trigger > > > > the proper > > > > service. This is a very good reason for updating the to field > > > > every time > > > > we have more digits. > > > > > > > > I like to use SIP between two gateways because it is possible > > > > to provide > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > finding a > > > > egrees gateway, we would probably want to use other protocols (TRIP & > > > > SIGTRAN for instance). > > > > > > > > Regards, > > > > > > > > Gonzalo > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > statements is > > > > > that an INVITE has reached a UAS which has accepted it. It follows > > > > > that the UAS did not send back a 484, but rather an interim > > > > response. > > > > > IF more digits come along, the INFO method is there to carry them. > > > > > They do not affect the SIP call state; they are used beyond the UAS, > > > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > signalling > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > additional > > > > > > > digits will not change call state. It is therefore > > > > > > reasonable to use > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > ISUP-SIP, once > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > reached, the same > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > vanilla SIP UA. > > > > > I > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > subsequent INFO > > > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > > > gateway > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > Therefore, it is > > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > > > > carries ISUP messages between two gateways. For that, we have > > > > > already > > > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > > > call is a > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > state. And a > > > > > > SIP message with an incomplete to field does not carry complete > > > > > state. > > > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > > > based > > > > > > on the to field (called party number). That proxy would > > > > like to see > > > > > an > > > > > > updated to field, not just a to field that contains just some > > > > > digits. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Christer Holmberg > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > To: Gonzalo Camarillo > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > > > been proposed > > > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > > > reason for > > > > > > > > the discussion from the beginning was that the overlap > > > > > signalling, > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > very well, and > > > > > > > a > > > > > > > > solution using 18x responses and INFO messages, instead of 484 > > > > > and > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > > > > about calls > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > SIP UAS > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > > > --> > > > > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > > > the word 'proxy') > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > overlap dialing, to > > > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > > > the digits > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > > > be allowed to > > > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > > > INVITEs, until > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. --0__=pJNshxSL155bQh6AUjInOZsfqKwtHD2xFxiM71EOSR7WXq4YvX1fwUuP Content-type: application/octet-stream; name="christer.holmberg.vcf" Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOkhvbG1iZXJnO0NocmlzdGVyDQp0ZWw7Y2VsbDorMzU4LTQwLTU2MDQ0 MTINCnRlbDt3b3JrOiszNTgtOS0yOTkyOTQzDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnOkVy aWNzc29uO0lQIE11bHRpbWVkaWEgLyBBZHZhbmNlZCBTaWduYWxsaW5nIFJlc2VhcmNoIExhYm9y YXRvcnkNCmFkcjo7Ozs7OzsNCnZlcnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpjaHJpc3Rlci5o b2xtYmVyZ0BsbWYuZXJpY3Nzb24uc2UNCnRpdGxlOlN5c3RlbSBEZXNpZ25lcg0KZm46Q2hyaXN0 ZXIgSG9sbWJlcmcNCmVuZDp2Y2FyZA0KDQo= --0__=pJNshxSL155bQh6AUjInOZsfqKwtHD2xFxiM71EOSR7WXq4YvX1fwUuP-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 06:27:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12591 for ; Thu, 15 Feb 2001 06:27:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 69C6344366; Thu, 15 Feb 2001 06:27:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 4A6D044336 for ; Thu, 15 Feb 2001 06:26:32 -0500 (EST) 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 f1FBQTd09571; Thu, 15 Feb 2001 12:26:29 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA05411; Thu, 15 Feb 2001 13:26:26 +0200 (EET) Message-ID: <3A8BBCE1.611FC86A@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo Cc: Keith Robinson , Jonathan Rosenberg , "'Tom-PT Taylor'" , sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: <802569F3.00377A7A.00@marconicomms.com> <3A8A96B8.B804D4A0@lmf.ericsson.se> Content-Type: multipart/mixed; boundary="------------031338C8F252A58BB5EEF1ED" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 13:26:25 +0200 This is a multi-part message in MIME format. --------------031338C8F252A58BB5EEF1ED Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Gonzalo Camarillo wrote: > >Hello Keith, > >Keith Robinson wrote: >> >>Gonzalo, >> >> It seems you have two main reasons against the use of the INFO >>method for the conveyance of subsequent ISUP information: >> >>1) Lack of ordered delivery of the INFO messages >> >>Ordered delivery could be maintained by the UAC not sending the next INFO >>until a 200 OK response for the previous one had been received. >> >>2) Lack of state carried in the INFO messge >> >>The digits received so far could be carried in a header within the >>INFO message. Each INFO message would then carry the same information >>as a re-INVITE. >> > >Actually my main reason against the use of INFO is that it does not work >with vanilla SIP UAs and vanilla SIP Application Servers. How you >resolve the technical issues related to INFO does not really matter to >me. It is not "vanilla" SIP, and I am against this kind of non-standard >mechanisms. Like I wrote in another mail on the thread, we have a problem using INVITEs too. They all represent different call-legs, and since ROUTE is per call-leg only, every INVITE will be processed as an initial INVITE, and having ROUTE headers in an initial INVITE is still a problem and open issue, so I would not say it is "vanilla" SIP... >>My reason for exploring the use of INFO is not to save on messages. It is >>to do with the issue of source routing. Again, my concern of source >>routing is not one of a technical nature. What if an administration has a >>security policy that states source routing (a ROUTE header in >>an initial INVITE) will not take place in its SIP network but it also requires >>that the same network interworks with the PSTN; if any part of the PSTN interworking >>mechanism relies on source routing then there is a conflict of requirements. It is this >>conflict I wish to address. >> > >OK, let's address this. Source routing is proposed in the draft to >address load balancing. This is, a proxy that sends INVITEs to different >egrees gateways. >So, if an IAM and one SAM are received, the second INVITE might end up >in another gateway than the fist INVITE. This would trigger 2 IAMs >instead of 1 IAM and 1 SAM. > >OK, this is the problem that has to be solved. What I wanted to say in >the draft (I did not have lot of time and it has to be rephrased), was >the following: > >It is strongly RECOMMENDED that proxies route requests that are >basically identical and just differ in the to field (more digits) in the >same way. So, if such as proxy performs load balancing, all the >subsequent INVITEs will reach the same egrees gateway. The problem is that you recommend this in the ISUP-SIP draft, which most of the proxy vendors may not even have read... If this is something to be recommended for proxies, I think it must be in the bis draft. Otherwise I think we must add some kind of Proxy-Require option-tag in your draft, but then it's not "vanlilla" SIP anymore, so... Another recommendation could be that proxies that DO change the routing shall send a CANCEL to where the previous INVITE was sent, unless a 484 response was received for that INVITE. That way we would not have multiple "pending" call setups on the PSTN side. Actually, if we would make all this as a Proxy-Require option-tag ("Proxy-Require: overlap", or something...), compliant proxies MUST to all this. Then, if you don't want to get the routing-, and multiple IAM-, problems in your network, you just buy these kind of proxies. Simple :) >This is not difficult to do, because most likely a call to +1234 has to >be routed in the same way as a call to +12345. So, the only real >requirement in that proxies do not make routing decisions based on >random variables (such as internal clocks). Well, now you assume that the "load balance" stuff in the proxy is done depending on the user part, ie. the phone number, which I don't think is always going to be the case. A proxy may not even look at the phone number. It may send the INVITEs to different gateways anyway, for example if the DNS lookup for the next INVITE will return different IP addresses, IP addresses in different order, or whatever... There may also be other reasons, load balance reasons, why you would send your INVITEs to IP addresses, without even looking at the user part (in this case, the phone number). We should also remember that a proxy will not always send the request to the gateway. It may go to another proxy, etc etc. >Then, just in case folks did not feel comfortable with this solution >(which I believe is the good one), I outlined the source routing >solution. That is one, unfortunately very common, way to "solve" problems... :) >And what about load balancing? You can still have load balancing. Your >proxy makes the routing decision based on to, from, and what ever fields >it wants. Then, it can calculate a digest of some fields, and make a >"random" routing decision based on that hash. This provides load >balancing but still routes INVITEs carrying SAMs in the proper way. This is what I said, but this is all stuff you assume... I think we have two options here: 1. Add the overlap routing stuff to the bis document. It would still only be a recommendation (a SHALL, I guess..), but that's better than nothing. 2. Define an "overlap" option-tag, for example in the ISUP-SIP draft. Now compliant proxies would have to do the routing as you assume, and we could even add my CANCEL proposal, and have a MUST to accept ROUTE headers in new INVITEs at least if the phone number is different. Of course, this would not be "vanilla" SIP, but... And, you could still use "normal" proxies, but have to be aware of the issues that may occur. Regards, Christer Holmberg Ericsson Finland >Does this resolve your issue? > > Best regards, > > Gonzalo > > > Regards, > > > > K. Robinson. > > > > Gonzalo Camarillo on 01/01/88 00:39:14 > > > > > > > > > > > > > > > > To: Jonathan Rosenberg > > > > cc: "'Tom-PT Taylor'" , > > Christer Holmberg > > , > > sip@lists.bell-labs.com(bcc: Keith > > Robinson/MAIN/MC1) > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > Hello, > > > > Jonathan Rosenberg wrote: > > > > > > I think the correct answer about which approach to use (INFO vs. multiple > > > call legs) depends on your view of the scope of the address within the sip > > > cloud. If you believe that the sip role has ended once you have enough > > > digits to select an egress gateway (which may be as few as one, i.e., +1 > > > selects a US gateway), then the sip address of that gateway can be viewed as > > > sip:+1@provider.com, and all subsequent digits are PSTN issues, outside the > > > scope of SIP. > > > > I definitively agree that this is the view that INFO fans have of a SIP > > cloud. What I am saying is that this view is wrong. This usage of SIP > > falls outside the scope of SIP. > > If they want to use SIP for locating a gateway, it is fine. But after > > the gateway has been located, let's use another method for transporting > > ISUP signalling. > > > > Let's assume that I get an IAM with "+1", as Jonathan says in his > > example. Then the INVITE generated by the gateway will reach the US > > gateway. Now, the mission of SIP has finished, since the gateway has > > been located. Why don't we put in the body of this INVITE a session > > description that comprises a media session and a SIGTRAN session? This > > way we would have established these two sessions between the gateways > > and all the subsequent ISUP messages would be sent over the SIGTRAN > > session. > > > > I find that the usage of SIP that I have just described would be OK. > > What I do not understand is why folks want to use SIP for transporting > > subsequent ISUP messages. SIP does not have good transport properties > > (big overhead, it can run over UDP...). Besides, it does not provide > > ordered delivery. > > > > If the INVITE has Cseq=1 and the next message that the egrees gateway > > receives is a INFO with Cseq=7... what should the gateway do? Maybe > > there were several proxies in the middle asking for credentials for the > > INFO, so the ingrees gateway had to add authentication stuff and resend > > the INFO. If this was the case, the SAM contained in the INFO would be > > the second digit of the called party number... However, maybe 5 INFO > > messages got lost, and the SAM that we have received in the body of the > > INFO makes no sense without the previous ones because is the 7th digit > > of the number... > > > > This is not usually a problem in SIP, since all messages have full > > state. However, using INFO for sending SAMs breaks this rule, and > > therefore it breaks the SIP model. > > > > I believe that considering that the session is established after the > > first INVITE and sending the following SAMs using INFO is making one of > > the mistakes described in the guidelines for SIP authors: "We need to > > transport ISUP signalling over IP between two gateways. Both gateways > > already implement SIP... why do we have to implement another protocol? > > Let's use SIP to transport ISUP signalling". We are just trying to use > > SIP for this just because it would save implementing yet another > > protocol in the gateways. > > > > I strongly disagree with this usage of SIP. SIP-T is good as long as the > > SIP cloud provides services. If not, SIP-T is not a good protocol for > > transporting ISUP signalling. > > > > Best regards, > > > > Gonzalo > > > > If you believe that the sip role encompasses functions that > > > might apply to the PSTN subscribers, then you need to have the entire > > > number, and the multiple call leg approach is the right way to go. > > > > > > The multiple call leg approach is clearly ugly and inelegant, but it has the > > > nice property of completely masking the existence of overlap from proxies > > > and app servers within the network, allowing them to provide services in the > > > normal way. > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > -----Original Message----- > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > Sent: Thursday, February 08, 2001 7:00 AM > > > To: Gonzalo Camarillo > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > > > You are correct about using some other means of transport if ISUP > > > trans-shipment is all your network is doing. If the call destination (to a > > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a per-call > > > basis, however, using SIP to establish your call routing leads to using SIP > > > to carry the ISUP. > > > > -----Original Message----- > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hi Tom, > > > > > > > > Still I want to have full state in every SIP message. If the call is > > > > addresed to the phone number 1234, I want to have a to field that says > > > > 1234. I do not care if there is a leg routed thru the PSTN and another > > > > thru SIP. > > > > > > > > Carrying full state is one of the beauties of SIP. If we begin using > > > > INFO for this, it would be the same as using SAMs. Differen names, the > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > believe that > > > > if the session has a destination, it should be present in the > > > > to field. > > > > > > > > Again, if a proxy is providing services for this particular call, it > > > > will want to see the called party number in order to trigger > > > > the proper > > > > service. This is a very good reason for updating the to field > > > > every time > > > > we have more digits. > > > > > > > > I like to use SIP between two gateways because it is possible > > > > to provide > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > finding a > > > > egrees gateway, we would probably want to use other protocols (TRIP & > > > > SIGTRAN for instance). > > > > > > > > Regards, > > > > > > > > Gonzalo > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > statements is > > > > > that an INVITE has reached a UAS which has accepted it. It follows > > > > > that the UAS did not send back a 484, but rather an interim > > > > response. > > > > > IF more digits come along, the INFO method is there to carry them. > > > > > They do not affect the SIP call state; they are used beyond the UAS, > > > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > signalling > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > additional > > > > > > > digits will not change call state. It is therefore > > > > > > reasonable to use > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > ISUP-SIP, once > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > reached, the same > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > vanilla SIP UA. > > > > > I > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > subsequent INFO > > > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > > > gateway > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > Therefore, it is > > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > > > > carries ISUP messages between two gateways. For that, we have > > > > > already > > > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > > > call is a > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > state. And a > > > > > > SIP message with an incomplete to field does not carry complete > > > > > state. > > > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > > > based > > > > > > on the to field (called party number). That proxy would > > > > like to see > > > > > an > > > > > > updated to field, not just a to field that contains just some > > > > > digits. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Christer Holmberg > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > To: Gonzalo Camarillo > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > > > been proposed > > > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > > > reason for > > > > > > > > the discussion from the beginning was that the overlap > > > > > signalling, > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > very well, and > > > > > > > a > > > > > > > > solution using 18x responses and INFO messages, instead of 484 > > > > > and > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > > > > about calls > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > SIP UAS > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > > > --> > > > > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > > > the word 'proxy') > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > overlap dialing, to > > > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > > > the digits > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > > > be allowed to > > > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > > > INVITEs, until > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com --------------031338C8F252A58BB5EEF1ED 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 --------------031338C8F252A58BB5EEF1ED-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 07:08:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13304 for ; Thu, 15 Feb 2001 07:08:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D21F44337; Thu, 15 Feb 2001 07:08:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id 36ACC44336 for ; Thu, 15 Feb 2001 07:07:26 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qhars002.nortel.com; Thu, 15 Feb 2001 12:06:56 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <102C88W2>; Thu, 15 Feb 2001 12:06:55 -0000 Message-ID: From: "Mark Watson" To: "'Christian Huitema'" , "Rosen, Brian" , William Marshall Cc: sip Subject: RE: [SIP] Re: Location information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09747.C8790360" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 12:06:52 -0000 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_01C09747.C8790360 Content-Type: text/plain; charset="iso-8859-1" Hmmm, this is perhaps a slightly larger issue than suits this thread, but anyway: If there is no 'man in the middle' i.e. you can find and connect to your destination directly at the IP layer, then this is essentially a private transaction between you and the destination. You can do what you like in this context - it's just up to you and the destination to agree between youselves. (Although you still both have to respect applicable Data Protection Legislation in respect of any personal information you receive from each other.) If you make your connection via an intermediate proxy or proxies operated by a third party, presumably you do this because those proxies offer some kind of service (e.g. routing). If the third party makes this service publically available, then this is whom I consider the 'public network'. Of course there will be many such service providers that a user can choose from - though there is plenty of work going on to invent ways of restricting a users choice in certain environments. ...Mark -----Original Message----- From: Christian Huitema [mailto:huitema@exchange.microsoft.com] Sent: 06 February 2001 17:37 To: Watson, Mark [MAIFP:EP11-M:EXCH]; Rosen, Brian; William Marshall Cc: sip Subject: RE: [SIP] Re: Location information Uh, what is exactly the "public network" that you are talking about? The ISP to which my entreprise network connects have no idea of what the bits in the packets are, and probably don't want to know. The basic SIP solution is end-to-end, with the network being essentially transparent. Sure, there may be competing voice service providers that want to provide added value on top of the basic service, but we cannot assume that there has to be a man in the middle. -- Christian Huitema -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Tuesday, February 06, 2001 8:02 AM To: Rosen, Brian; William Marshall Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: Location information The public network will likely be trusted in the sense that it promises to obey the user's stated privacy requirements, indeed Data Protection legislation will usually oblige the public network provider to do this. Also, it will likely be a requirement of the public service that terminals identify themselves in some way. I do not think it likely that for Emergency calls, terminals/networks will behave differently with respect to identity information than for normal calls except that it will probably not be considered an infringement of privacy to deliver identity information to an Emergency call centre even when the user has requested it be kept private. More complex is how does the public service provider verify the identity and location information ? In the example above, the public service provider can only be sure of the owner of the Enterprise network from which the call came, and this may not translate into a single geographic location. The network would be forced to send forward only the 'unverified' location information provided by the caller. ...Mark > -----Original Message----- > From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com ] > Sent: 05 February 2001 18:48 > To: 'William Marshall' > Cc: sip@lists.bell-labs.com > Subject: RE: [SIP] Re: Location information > > > If I have an enterprise network, and it connects to a public > network, then > the trust boundary may stop at the private/public boundary. The > "subscriber" > is the enterprise, not the individual. In the privacy draft, > if extended to > location, there is no mechanism to: > Recognize that this is an emergency call > Recognize that the UAS is the emergency center > Pass location information despite any of the requests > the UAC may > make. > > Yet, the requirement is to identify the location of the individual. > I think the draft has some fine mechanisms in it. I just > don't think they > are > sufficient for emergency purposes. > > Brian > > > -----Original Message----- > > From: William Marshall [ mailto:wtm@research.att.com ] > > Sent: Monday, February 05, 2001 1:31 PM > > To: brian.rosen@marconi.com > > Cc: sip@lists.bell-labs.com > > Subject: RE: [SIP] Re: Location information > > > > > > An ordinary call must yield subscriber information. There is > > not an option for the user to suppress this, by law (although the > > user may request this information not be given to the destination). > > However, the destination can always identify the caller, > for purposes > > of tracing an obscene or harassing call. > > > > Accuracy of location is certainly variable, and it is possible > > the UA may permit delivery of less precise information, but suppress > > accurate information. Multiple levels are just like multiple > > identities; > > the privacy draft as described by Mark in previous email > > allows separate > > anonymity requirements to be attached to each. > > > > Bill Marshall > > wtm@research.att.com > > > > -----original message----- > > From: "Rosen, Brian" > > To: "'William Marshall'" > > Cc: sip@lists.bell-labs.com > > Subject: RE: [SIP] Re: Location information > > Date: Mon, 5 Feb 2001 12:01:48 -0500 > > > > The problem that location presents that is different from the > > privacy draft (unless I missed it) is that an emergency call must > > yield location information. There is not an option for the user > > to suppress this, by law. The path by which a user might connect > > to an emergency center cannot be pre-arranged. I believe that it > > will take creation of a cryptographically secure infrastructure > > to allow such a system to have the desired property that the user > > can control location information, but when required it can be > > securely delivered. > > > > I also think that location is not an "all or nothing" kind of > > thing. The privacy draft presupposes that the world is bifurcated > > into trusted and untrusted domains, and privacy is secured > > when venturing into an untrusted domain. This is not the behavior > > I really want. The desired behavior I want is: > > Accuracy (precision) of location is variable > > I may want to give some people precise > > information, others > > less precise. There will be multiple levels > > Time (and motion) variability - if I am mobile, then where I > > am changes over time. I need to express this somehow, > > but I also need to control it (not everyone can > > be told that > > I am mobile) > > What we learned in the spatial effort is that the whole > location thing > > is more complex that you would like it to be, and it is hard to get > > an implementable subset that has enough functionality to be > > interesting. > > We also learned the difficulties in reaching consensus on > issues that > > involve privacy. > > > > Brian > > > > > > > > > > > -----Original Message----- > > > From: William Marshall [ mailto:wtm@research.att.com ] > > > Sent: Monday, February 05, 2001 11:40 AM > > > To: brian.rosen@marconi.com > > > Cc: sip@lists.bell-labs.com > > > Subject: [SIP] Re: Location information > > > > > > > > > Brian, > > > > > > It seems that the privacy draft faces up squarely to the privacy > > > concerns. The draft already deals with all the regulatory > > > requirements > > > about verification of identity, hiding of identity, etc. > > The security > > > implications of knowing who you are are just as daunting > as knowing > > > where you are. In some places regulations already cover > > > location info, > > > and the framework in the privacy draft deals with them. > > > > > > As with the subscriber identity - the UA may insert it, and may > > > demand (via a tag and a Proxy-Require) that it be kept private. > > > The proxies may verify the identity, and mark it verified, or mark > > > it unverified, and must delete the information if privacy was > > > requested. > > > The procedures are all there in the privacy draft, and just need > > > some minor extensions to handle multiple identity types, and > > > per-identity > > > privacy requests. > > > > > > The previous efforts (spatial) generated a string giving location > > > information. Sip uses "name-addr | addr-spec" everywhere, which > > > includes a display-name string; however a URL format > would be nicer. > > > I was sure I had heard about a URL format with this > information, but > > > can't find any reference to it. > > > > > > Bill Marshall > > > wtm@research.att.com > > > > > > -----original message----- > > > From: "Rosen, Brian" > > > Subject: RE: Location information (was Re: [SIP] SIP > Privacy Draft) > > > Date: Mon, 5 Feb 2001 10:44:54 -0500 > > > > > > There was an effort started several IETFs ago to define a PROTOCOL > > > to exchange geographic location. That was shot down. > > There is still > > > a low level effort to define a format for exchanging such > > information. > > > > > > Before starting another effort, you might want to look at > the prior > > > work (spatial). You also MUST forthrightly face up to the privacy > > > concerns that have stymied other efforts. The security > > > implications of > > > knowing where you are can be VERY daunting, and in general > > discussions > > > on the issues have yielded more problems than answers.' > > > > > > Brian > > > > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > > > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > ------_=_NextPart_001_01C09747.C8790360 Content-Type: text/html; charset="iso-8859-1" Message
Hmmm, this is perhaps a slightly larger issue than suits this thread, but anyway:
 
If there is no 'man in the middle' i.e. you can find and connect to your destination directly at the IP layer, then this is essentially a private transaction between you and the destination. You can do what you like in this context - it's just up to you and the destination to agree between youselves. (Although you still both have to respect applicable Data Protection Legislation in respect of any personal information you receive from each other.)
 
If you make your connection via an intermediate proxy or proxies operated by a third party, presumably you do this because those proxies offer some kind of service (e.g. routing). If the third party makes this service publically available, then this is whom I consider the 'public network'.
 
Of course there will be many such service providers that a user can choose from - though there is plenty of work going on to invent ways of restricting a users choice in certain environments.
 
...Mark
-----Original Message-----
From: Christian Huitema [mailto:huitema@exchange.microsoft.com]
Sent: 06 February 2001 17:37
To: Watson, Mark [MAIFP:EP11-M:EXCH]; Rosen, Brian; William Marshall
Cc: sip
Subject: RE: [SIP] Re: Location information

Uh, what is exactly the "public network" that you are talking about? The ISP to which my entreprise network connects have no idea of what the bits in the packets are, and probably don't want to know. The basic SIP solution is end-to-end, with the network being essentially transparent. Sure, there may be competing voice service providers that want to provide added value on top of the basic service, but we cannot assume that there has to be a man in the middle.
 
-- Christian Huitema
 
 
-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Tuesday, February 06, 2001 8:02 AM
To: Rosen, Brian; William Marshall
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Re: Location information

The public network will likely be trusted in the sense that it promises to obey the user's stated privacy requirements, indeed Data Protection legislation will usually oblige the public network provider to do this. Also, it will likely be a requirement of the public service that terminals identify themselves in some way.

I do not think it likely that for Emergency calls, terminals/networks will behave differently with respect to identity information than for normal calls except that it will probably not be considered an infringement of privacy to deliver identity information to an Emergency call centre even when the user has requested it be kept private.

More complex is how does the public service provider verify the identity and location information ? In the example above, the public service provider can only be sure of the owner of the Enterprise network from which the call came, and this may not translate into a single geographic location. The network would be forced to send forward only the 'unverified' location information provided by the caller.

...Mark

> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> Sent: 05 February 2001 18:48
> To: 'William Marshall'
> Cc: sip@lists.bell-labs.com
> Subject: RE: [SIP] Re: Location information
>
>
> If I have an enterprise network, and it connects to a public
> network, then
> the trust boundary may stop at the private/public boundary.  The
> "subscriber"
> is the enterprise, not the individual.  In the privacy draft,
> if extended to
> location, there is no mechanism to:
>       Recognize that this is an emergency call
>       Recognize that the UAS is the emergency center
>       Pass location information despite any of the requests
> the UAC may
> make.
>
> Yet, the requirement is to identify the location of the individual.
> I think the draft has some fine mechanisms in it.  I just
> don't think they
> are
> sufficient for emergency purposes.
>
> Brian
>
> > -----Original Message-----
> > From: William Marshall [mailto:wtm@research.att.com]
> > Sent: Monday, February 05, 2001 1:31 PM
> > To: brian.rosen@marconi.com
> > Cc: sip@lists.bell-labs.com
> > Subject: RE: [SIP] Re: Location information
> >
> >
> > An ordinary call must yield subscriber information.  There is
> > not an option for the user to suppress this, by law (although the
> > user may request this information not be given to the destination).
> > However, the destination can always identify the caller,
> for purposes
> > of tracing an obscene or harassing call.
> >
> > Accuracy of location is certainly variable, and it is possible
> > the UA may permit delivery of less precise information, but suppress
> > accurate information.  Multiple levels are just like multiple
> > identities;
> > the privacy draft as described by Mark in previous email
> > allows separate
> > anonymity requirements to be attached to each.
> >
> > Bill Marshall
> > wtm@research.att.com
> >
> > -----original message-----
> > From: "Rosen, Brian" <Brian.Rosen@marconi.com>
> > To: "'William Marshall'" <wtm@research.att.com>
> > Cc: sip@lists.bell-labs.com
> > Subject: RE: [SIP] Re: Location information
> > Date: Mon, 5 Feb 2001 12:01:48 -0500
> >
> > The problem that location presents that is different from the
> > privacy draft (unless I missed it) is that an emergency call must
> > yield location information.  There is not an option for the user
> > to suppress this, by law.  The path by which a user might connect
> > to an emergency center cannot be pre-arranged.  I believe that it
> > will take creation of a cryptographically secure infrastructure
> > to allow such a system to have the desired property that the user
> > can control location information, but when required it can be
> > securely delivered.
> >
> > I also think that location is not an "all or nothing" kind of
> > thing.  The privacy draft presupposes that the world is bifurcated
> > into trusted and untrusted domains, and privacy is secured
> > when venturing into an untrusted domain.  This is not the behavior
> > I really want. The desired behavior I want is:
> >     Accuracy (precision) of location is variable
> >             I may want to give some people precise
> > information, others
> >             less precise.  There will be multiple levels
> >     Time (and motion) variability - if I am mobile, then where I
> >             am changes over time.  I need to express this somehow,
> >             but I also need to control it (not everyone can
> > be told that
> >             I am mobile)
> > What we learned in the spatial effort is that the whole
> location thing
> > is more complex that you would like it to be, and it is hard to get
> > an implementable subset that has enough functionality to be
> > interesting.
> > We also learned the difficulties in reaching consensus on
> issues that
> > involve privacy.
> >
> > Brian
> >    
> >    
> >    
> >
> > > -----Original Message-----
> > > From: William Marshall [mailto:wtm@research.att.com]
> > > Sent: Monday, February 05, 2001 11:40 AM
> > > To: brian.rosen@marconi.com
> > > Cc: sip@lists.bell-labs.com
> > > Subject: [SIP] Re: Location information
> > >
> > >
> > > Brian,
> > >
> > > It seems that the privacy draft faces up squarely to the privacy
> > > concerns.  The draft already deals with all the regulatory
> > > requirements
> > > about verification of identity, hiding of identity, etc. 
> > The security
> > > implications of knowing who you are are just as daunting
> as knowing
> > > where you are.  In some places regulations already cover
> > > location info,
> > > and the framework in the privacy draft deals with them.
> > >
> > > As with the subscriber identity - the UA may insert it, and may
> > > demand (via a tag and a Proxy-Require) that it be kept private.
> > > The proxies may verify the identity, and mark it verified, or mark
> > > it unverified, and must delete the information if privacy was
> > > requested.
> > > The procedures are all there in the privacy draft, and just need
> > > some minor extensions to handle multiple identity types, and
> > > per-identity
> > > privacy requests.
> > >
> > > The previous efforts (spatial) generated a string giving location
> > > information.  Sip uses "name-addr | addr-spec" everywhere, which
> > > includes a display-name string; however a URL format
> would be nicer.
> > > I was sure I had heard about a URL format with this
> information, but
> > > can't find any reference to it.
> > >
> > > Bill Marshall
> > > wtm@research.att.com
> > >
> > > -----original message-----
> > > From: "Rosen, Brian" <Brian.Rosen@marconi.com>
> > > Subject: RE: Location information (was Re: [SIP] SIP
> Privacy Draft)
> > > Date: Mon, 5 Feb 2001 10:44:54 -0500
> > >
> > > There was an effort started several IETFs ago to define a PROTOCOL
> > > to exchange geographic location.  That was shot down. 
> > There is still
> > > a low level effort to define a format for exchanging such
> > information.
> > >
> > > Before starting another effort, you might want to look at
> the prior
> > > work (spatial).  You also MUST forthrightly face up to the privacy
> > > concerns that have stymied other efforts.  The security
> > > implications of
> > > knowing where you are can be VERY daunting, and in general
> > discussions
> > > on the issues have yielded more problems than answers.'
> > >
> > > Brian
> > >
> > >
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > "subscribe sip-implementors" in the body.
> > >
> >
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
>

------_=_NextPart_001_01C09747.C8790360-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 08:36:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15238 for ; Thu, 15 Feb 2001 08:36:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 997EB44337; Thu, 15 Feb 2001 08:36:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id E51D444336 for ; Thu, 15 Feb 2001 08:35:50 -0500 (EST) 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 f1FDY8C03795; Thu, 15 Feb 2001 14:34:08 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA16360; Thu, 15 Feb 2001 15:34:06 +0200 (EET) Message-ID: <3A8BDACC.D43254DD@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: sip@lists.bell-labs.com, Gonzalo Camarillo , Jonathan Rosenberg , "'Tom-PT Taylor'" Subject: Re: [SIP] Operlap dialing within a SIP network References: <802569F4.003D8F2A.00@marconicomms.com> Content-Type: multipart/mixed; boundary="------------03AD3F0B1B083116AE5A5328" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 15:34:04 +0200 This is a multi-part message in MIME format. --------------03AD3F0B1B083116AE5A5328 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Keith Robinson wrote: > >Hello, > >>I don't see this as a protocol issue, but more how the operator has >>built and configured his network. Also, you have the same problem in >>other cases too, eg with the session-timer. If a server reboots, when it >>is going to receive the refresh re-INVITE it is going to process it as >>an INVITE for a new call, and there may be ROUTE headers in that INVITE, >>so... > >A proxy can be intelligent enough to distinguish between an initial INVITE >with a ROUTE header (source routing) and a re-INVITE received after >a reboot; Yes, a proxy can do this, and we can assume that it do that... But, like I said earlier, it should be written down then, either in the bis as a SHOULD, or in the ISUP-SIP as an option-tag extension, ie a MUST. >in the case of the initial INVITE, the TO tag field MUST be empty; >in the case of the re-INVITE after a reboot the TO tag field MUST NOT be >empty. >So a proxy can be configured to disallow source routing, while still able to support the session-timer >re-INVITE after a reboot, thereby remaining robust. I guess that could work. But again, how many proxy implementations work that way? Since we can't make it a MUST for proxy (for backward compability), the question is, again, if it should be a SHOULD in the bis, or an Proxy-Require option tag extension. Regards, Christer Holmberg Ericsson Finland >>And, I don't see how you solve this issue by using INFO. You still have >>to send at least one initial INVITE, in which your UA, for some reason, >>may insert ROUTE headers. Again, in this case I don't see it as a >>problem if a proxy will reject that, because I think the proxies should >>decide about the routing, not the UA. However, like I mentioned earlier, >>it IS a problem with the session-timer... > >Of course, clients may attempt to source route, and such requests >may well be rejected if they traverse a network with a security policy >tha disallows it. Its an interoperability issue when going between >administrative domains. > >Regards, > > K. Robinson > > Christer Holmberg on 15/02/2001 09:51:47 > > > > > > > > To: Keith Robinson/MAIN/MC1@MCMAIN > > cc: sip@lists.bell-labs.com, Gonzalo Camarillo > , Jonathan > Rosenberg , "'Tom-PT > Taylor'" > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > Hi, > > Keith Robinson wrote: > > > >Hi, > > > >Christer wrote : > > > > > > > >>I think that the administrator proxies in the network should be > >>able to handle that, e.g. either by refusing the message (a proxy should > >>have the last say about if a message is allowed to be routed in a > >>specific way or not), sending a 3xx response (to re-route the call), or > >>simply by removing the ROUTE header (I know that is not allowed, but the > >>there is also an issue of allowing ROUTE in the initial INVITE in the > >>first place, so...). In another mail I pointed out that the network > >>operator administrator most likely wants to have good control of the > >>network, so I think it should be allowed for proxies to do these kind of > >>things. > > > >This is exactly my concern. What if proxies are configured to reject or > >ignore the ROUTE header of requests which are attempting to source route. > >The initial INVITEs sending subsequent digits may not reach the (correct) >UAS > if they had to traverse such networks and so the mechanism would >fail. > > I don't see this as a protocol issue, but more how the operator has > built and configured his network. Also, you have the same problem in > other cases too, eg with the session-timer. If a server reboots, when it > is going to receive the refresh re-INVITE it is going to process it as > an INVITE for a new call, and there may be ROUTE headers in that INVITE, > so... > > And, I don't see how you solve this issue by using INFO. You still have > to send at least one initial INVITE, in which your UA, for some reason, > may insert ROUTE headers. Again, in this case I don't see it as a > problem if a proxy will reject that, because I think the proxies should > decide about the routing, not the UA. However, like I mentioned earlier, > it IS a problem with the session-timer... > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > Regards, > > > > K. Robinson. > > > > Christer Holmberg on 14/02/2001 10:53:31 > > > > > > > > > > > > > > > > To: sip@lists.bell-labs.com > > > > cc: Keith Robinson/MAIN/MC1@MCMAIN, Gonzalo Camarillo > > , Jonathan > > Rosenberg , "'Tom-PT > > Taylor'" > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > Hi, > > > > I am not Gonzalo, but I will comment anyway... :) > > > > >Gonzalo, > > > > > >It seems you have two main reasons against the use of the INFO > > >method for the conveyance of subsequent ISUP information: > > > > > >1) Lack of ordered delivery of the INFO messages > > > > > >Ordered delivery could be maintained by the UAC not sending the next INFO > > >until a 200 OK response for the previous one had been received. > > > > I am strongly against that. We would have to start buffering incoming > > SAMs, and by having to wait for the response before sending the next > > INVITE it would slow down the setup time between the nodes. > > > > This is also related with the PRACK issue, where we also may have to do > > buffering becuase we have to wait for messages (which means we may have > > to do buffering), but that is another issue... > > > > >2) Lack of state carried in the INFO messge > > > > > >The digits received so far could be carried in a header within the > > >INFO message. Each INFO message would then carry the same information > > >as a re-INVITE. > > > > > >My reason for exploring the use of INFO is not to save on messages. It is > > >to do with the issue of source routing. Again, my concern of source > > >routing is not one of a technical nature. What if an administration has a > > >security policy that states source routing (a ROUTE header in > > >an initial INVITE) will not take place in its SIP network but it also > >requires > > that the same network interworks with the PSTN; if any part of >the PSTN > > interworking mechanism relies on source routing then there is a >conflict of > > requirements. It is this conflict > > >I wish to address. > > > > I am not sure I understood this correctly. But, in either case the UAC > > will have to send an initial INVITE, so it can choose to insert a ROUTE > > header. I think that the administrator proxies in the network should be > > able to handle that, e.g. either by refusing the message (a proxy should > > have the last say about if a message is allowed to be routed in a > > specific way or not), sending a 3xx response (to re-route the call), or > > simply by removing the ROUTE header (I know that is not allowed, but the > > there is also an issue of allowing ROUTE in the initial INVITE in the > > first place, so...). In another mail I pointed out that the network > > operator administrator most likely wants to have good control of the > > network, so I think it should be allowed for proxies to do these kind of > > things. Otherwise one can send anything in the requests, and soon we > > will have a bunch of "SIP Viruses" out there... > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > Regards, > > > > > > K. Robinson. > > > > > > Gonzalo Camarillo on 01/01/88 00:39:14 > > > > > > > > > > > > > > > > > > > > > > > > To: Jonathan Rosenberg > > > > > > cc: "'Tom-PT Taylor'" , > > > Christer Holmberg > > > , > > > sip@lists.bell-labs.com(bcc: Keith > > > Robinson/MAIN/MC1) > > > > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > Hello, > > > > > > Jonathan Rosenberg wrote: > > > > > > > > I think the correct answer about which approach to use (INFO vs. multiple > > > > call legs) depends on your view of the scope of the address within the sip > > > > cloud. If you believe that the sip role has ended once you have enough > > > > digits to select an egress gateway (which may be as few as one, i.e., +1 > > > > selects a US gateway), then the sip address of that gateway can be viewed > as > > > > sip:+1@provider.com, and all subsequent digits are PSTN issues, outside > the > > > > scope of SIP. > > > > > > I definitively agree that this is the view that INFO fans have of a SIP > > > cloud. What I am saying is that this view is wrong. This usage of SIP > > > falls outside the scope of SIP. > > > If they want to use SIP for locating a gateway, it is fine. But after > > > the gateway has been located, let's use another method for transporting > > > ISUP signalling. > > > > > > Let's assume that I get an IAM with "+1", as Jonathan says in his > > > example. Then the INVITE generated by the gateway will reach the US > > > gateway. Now, the mission of SIP has finished, since the gateway has > > > been located. Why don't we put in the body of this INVITE a session > > > description that comprises a media session and a SIGTRAN session? This > > > way we would have established these two sessions between the gateways > > > and all the subsequent ISUP messages would be sent over the SIGTRAN > > > session. > > > > > > I find that the usage of SIP that I have just described would be OK. > > > What I do not understand is why folks want to use SIP for transporting > > > subsequent ISUP messages. SIP does not have good transport properties > > > (big overhead, it can run over UDP...). Besides, it does not provide > > > ordered delivery. > > > > > > If the INVITE has Cseq=1 and the next message that the egrees gateway > > > receives is a INFO with Cseq=7... what should the gateway do? Maybe > > > there were several proxies in the middle asking for credentials for the > > > INFO, so the ingrees gateway had to add authentication stuff and resend > > > the INFO. If this was the case, the SAM contained in the INFO would be > > > the second digit of the called party number... However, maybe 5 INFO > > > messages got lost, and the SAM that we have received in the body of the > > > INFO makes no sense without the previous ones because is the 7th digit > > > of the number... > > > > > > This is not usually a problem in SIP, since all messages have full > > > state. However, using INFO for sending SAMs breaks this rule, and > > > therefore it breaks the SIP model. > > > > > > I believe that considering that the session is established after the > > > first INVITE and sending the following SAMs using INFO is making one of > > > the mistakes described in the guidelines for SIP authors: "We need to > > > transport ISUP signalling over IP between two gateways. Both gateways > > > already implement SIP... why do we have to implement another protocol? > > > Let's use SIP to transport ISUP signalling". We are just trying to use > > > SIP for this just because it would save implementing yet another > > > protocol in the gateways. > > > > > > I strongly disagree with this usage of SIP. SIP-T is good as long as the > > > SIP cloud provides services. If not, SIP-T is not a good protocol for > > > transporting ISUP signalling. > > > > > > Best regards, > > > > > > Gonzalo > > > > > > If you believe that the sip role encompasses functions that > > > > might apply to the PSTN subscribers, then you need to have the entire > > > > number, and the multiple call leg approach is the right way to go. > > > > > > > > The multiple call leg approach is clearly ugly and inelegant, but it has > the > > > > nice property of completely masking the existence of overlap from proxies > > > > and app servers within the network, allowing them to provide services in > the > > > > normal way. > > > > > > > > -Jonathan R. > > > > > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > -----Original Message----- > > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > > Sent: Thursday, February 08, 2001 7:00 AM > > > > To: Gonzalo Camarillo > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > > > > > You are correct about using some other means of transport if ISUP > > > > trans-shipment is all your network is doing. If the call destination (to > a > > > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) varies on a > per-call > > > > basis, however, using SIP to establish your call routing leads to using > SIP > > > > to carry the ISUP. > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > Still I want to have full state in every SIP message. If the call is > > > > > addresed to the phone number 1234, I want to have a to field that says > > > > > 1234. I do not care if there is a leg routed thru the PSTN and another > > > > > thru SIP. > > > > > > > > > > Carrying full state is one of the beauties of SIP. If we begin using > > > > > INFO for this, it would be the same as using SAMs. Differen names, the > > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > > believe that > > > > > if the session has a destination, it should be present in the > > > > > to field. > > > > > > > > > > Again, if a proxy is providing services for this particular call, it > > > > > will want to see the called party number in order to trigger > > > > > the proper > > > > > service. This is a very good reason for updating the to field > > > > > every time > > > > > we have more digits. > > > > > > > > > > I like to use SIP between two gateways because it is possible > > > > > to provide > > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > > finding a > > > > > egrees gateway, we would probably want to use other protocols (TRIP & > > > > > SIGTRAN for instance). > > > > > > > > > > Regards, > > > > > > > > > > Gonzalo > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > > statements is > > > > > > that an INVITE has reached a UAS which has accepted it. It follows > > > > > > that the UAS did not send back a 484, but rather an interim > > > > > response. > > > > > > IF more digits come along, the INFO method is there to carry them. > > > > > > They do not affect the SIP call state; they are used beyond the UAS, > > > > > > either in a PSTN call or in another SIP call as the case may be. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > > signalling > > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > > additional > > > > > > > > digits will not change call state. It is therefore > > > > > > > reasonable to use > > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > > ISUP-SIP, once > > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > > reached, the same > > > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > > vanilla SIP UA. > > > > > > I > > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > > subsequent INFO > > > > > > > carrying more digits will be discarded. Thus, the PSTN to SIP > > > > > > gateway > > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > > Therefore, it is > > > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > > > > > Besides, I do not think that SIP is just a transport protocol that > > > > > > > carries ISUP messages between two gateways. For that, we have > > > > > > already > > > > > > > SIGTRAN. SIP might be used to provide services, even when the > > > > > > > call is a > > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > > state. And a > > > > > > > SIP message with an incomplete to field does not carry complete > > > > > > state. > > > > > > > What if my SIP proxy provides a service for a PSTN-SIP-PSTN call > > > > > > based > > > > > > > on the to field (called party number). That proxy would > > > > > like to see > > > > > > an > > > > > > > updated to field, not just a to field that contains just some > > > > > > digits. > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Christer Holmberg > > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > > To: Gonzalo Camarillo > > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that is what has > > > > > > > > > been proposed > > > > > > > > > earlier in this thread, so I assumed INFO would be used. The > > > > > > > > > reason for > > > > > > > > > the discussion from the beginning was that the overlap > > > > > > signalling, > > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > > very well, and > > > > > > > > a > > > > > > > > > solution using 18x responses and INFO messages, instead of 484 > > > > > > and > > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has been pretty much > > > > > > > > > about calls > > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > > SIP UAS > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > | <- 200 (INFO) | -- INVITE > > > > > > > > > > > --> > > > > > > > > > > > | <- 200 (INVITE)| <- 200 ------ > > > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I am not using > > > > > > > > > the word 'proxy') > > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > > overlap dialing, to > > > > > > > > > > > be able to find the SIP UAS, and INFO is used to provide > > > > > > > > > the digits > > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, if you like) > > > > > > > > > be allowed to > > > > > > > > > > > behave like this, or MUST it send 486s, and receive new > > > > > > > > > INVITEs, until > > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. --------------03AD3F0B1B083116AE5A5328 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 --------------03AD3F0B1B083116AE5A5328-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 09:45:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19101 for ; Thu, 15 Feb 2001 09:45:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 78E8E44337; Thu, 15 Feb 2001 09:45:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id 2ABC344336 for ; Thu, 15 Feb 2001 09:44:11 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qhars002.nortel.com; Thu, 15 Feb 2001 14:42:37 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <102C91VA>; Thu, 15 Feb 2001 14:42:36 -0000 Message-ID: From: "Mark Watson" To: "'Gonzalo Camarillo'" , Keith Robinson Cc: Jonathan Rosenberg , "Tom-PT Taylor" , Christer Holmberg , sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0975D.88D72E10" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 14:42:34 -0000 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_01C0975D.88D72E10 Content-Type: text/plain; charset="iso-8859-1" Gonzalo, I don't understand your comment about the INFO Overlap proposals causing problems for 'vanilla' SIP UAs. My suggestion was that the use of INFOs for overlap digits be negotiated between UAC and UAS. So, the UAC would include a 'Supported' tag if it could do overlap INFOs and the mechanism would then only be used if both ends supported it. Otherwise you would just kill session requests without enough digits with 484s. Regarding Application Servers, the INFOs should certainly contain all the digits so far (otherwise we get the problems with lost messages). I do not believe any proxies exist which are being used today in overlap situations and which need access to the whole called number, so we can add this capability to the specification without hurting any existing implementations. Finally, there are many reasons other than simple load balancing why one INVITE might be routed differently to a subsequent, apparently identical, one. e.g. Time of day routing - which is certainly not 'random'. Stateful proxies may also remember where they sent the INVITE so that subsequent requests on the same call leg can be routed the same way. Regards, Mark Watson Nortel Networks > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: 14 February 2001 14:31 > To: Keith Robinson > Cc: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B901:EXCH]; Christer > Holmberg; sip@lists.bell-labs.com > Subject: Re: [SIP] Operlap dialing within a SIP network > > > Hello Keith, > > Keith Robinson wrote: > > > > Gonzalo, > > > > It seems you have two main reasons against the use of the INFO > > method for the conveyance of subsequent ISUP information: > > > > 1) Lack of ordered delivery of the INFO messages > > > > Ordered delivery could be maintained by the UAC not sending > the next INFO > > until a 200 OK response for the previous one had been received. > > > > 2) Lack of state carried in the INFO messge > > > > The digits received so far could be carried in a header within the > > INFO message. Each INFO message would then carry the same > information > > as a re-INVITE. > > > > Actually my main reason against the use of INFO is that it > does not work > with vanilla SIP UAs and vanilla SIP Application Servers. How you > resolve the technical issues related to INFO does not really matter to > me. It is not "vanilla" SIP, and I am against this kind of > non-standard > mechanisms. > > > > My reason for exploring the use of INFO is not to save on > messages. It is > > to do with the issue of source routing. Again, my concern of source > > routing is not one of a technical nature. What if an > administration has a > > security policy that states source routing (a ROUTE header in > > an initial INVITE) will not take place in its SIP network > but it also requires > > that > > the same network interworks with the PSTN; if any part of > the PSTN interworking > > mechanism > > relies on source routing then there is a conflict of > requirements. It is this > > conflict > > I wish to address. > > > > OK, let's address this. Source routing is proposed in the draft to > address load balancing. This is, a proxy that sends INVITEs > to different > egrees gateways. > > So, if an IAM and one SAM are received, the second INVITE might end up > in another gateway than the fist INVITE. This would trigger 2 IAMs > instead of 1 IAM and 1 SAM. > > OK, this is the problem that has to be solved. What I wanted to say in > the draft (I did not have lot of time and it has to be rephrased), was > the following: > > It is strongly RECOMMENDED that proxies route requests that are > basically identical and just differ in the to field (more > digits) in the > same way. So, if such as proxy performs load balancing, all the > subsequent INVITEs will reach the same egrees gateway. > > This is not difficult to do, because most likely a call to > +1234 has to > be routed in the same way as a call to +12345. So, the only real > requirement in that proxies do not make routing decisions based on > random variables (such as internal clocks). > > Then, just in case folks did not feel comfortable with this solution > (which I believe is the good one), I outlined the source routing > solution. > > And what about load balancing? You can still have load balancing. Your > proxy makes the routing decision based on to, from, and what > ever fields > it wants. Then, it can calculate a digest of some fields, and make a > "random" routing decision based on that hash. This provides load > balancing but still routes INVITEs carrying SAMs in the proper way. > > Does this resolve your issue? > > Best regards, > > Gonzalo > > > > > Regards, > > > > K. Robinson. > > > > Gonzalo Camarillo on > 01/01/88 00:39:14 > > > > > > > > > > > > > > > > To: Jonathan Rosenberg > > > > cc: "'Tom-PT Taylor'" , > > Christer Holmberg > > , > > sip@lists.bell-labs.com(bcc: Keith > > Robinson/MAIN/MC1) > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > Hello, > > > > Jonathan Rosenberg wrote: > > > > > > I think the correct answer about which approach to use > (INFO vs. multiple > > > call legs) depends on your view of the scope of the > address within the sip > > > cloud. If you believe that the sip role has ended once > you have enough > > > digits to select an egress gateway (which may be as few > as one, i.e., +1 > > > selects a US gateway), then the sip address of that > gateway can be viewed as > > > sip:+1@provider.com, and all subsequent digits are PSTN > issues, outside the > > > scope of SIP. > > > > I definitively agree that this is the view that INFO fans > have of a SIP > > cloud. What I am saying is that this view is wrong. This > usage of SIP > > falls outside the scope of SIP. > > If they want to use SIP for locating a gateway, it is > fine. But after > > the gateway has been located, let's use another method for > transporting > > ISUP signalling. > > > > Let's assume that I get an IAM with "+1", as Jonathan says in his > > example. Then the INVITE generated by the gateway will reach the US > > gateway. Now, the mission of SIP has finished, since the gateway has > > been located. Why don't we put in the body of this INVITE a session > > description that comprises a media session and a SIGTRAN > session? This > > way we would have established these two sessions between > the gateways > > and all the subsequent ISUP messages would be sent over the SIGTRAN > > session. > > > > I find that the usage of SIP that I have just described would be OK. > > What I do not understand is why folks want to use SIP for > transporting > > subsequent ISUP messages. SIP does not have good transport > properties > > (big overhead, it can run over UDP...). Besides, it does not provide > > ordered delivery. > > > > If the INVITE has Cseq=1 and the next message that the > egrees gateway > > receives is a INFO with Cseq=7... what should the gateway do? Maybe > > there were several proxies in the middle asking for > credentials for the > > INFO, so the ingrees gateway had to add authentication > stuff and resend > > the INFO. If this was the case, the SAM contained in the > INFO would be > > the second digit of the called party number... However, maybe 5 INFO > > messages got lost, and the SAM that we have received in the > body of the > > INFO makes no sense without the previous ones because is > the 7th digit > > of the number... > > > > This is not usually a problem in SIP, since all messages have full > > state. However, using INFO for sending SAMs breaks this rule, and > > therefore it breaks the SIP model. > > > > I believe that considering that the session is established after the > > first INVITE and sending the following SAMs using INFO is > making one of > > the mistakes described in the guidelines for SIP authors: > "We need to > > transport ISUP signalling over IP between two gateways. > Both gateways > > already implement SIP... why do we have to implement > another protocol? > > Let's use SIP to transport ISUP signalling". We are just > trying to use > > SIP for this just because it would save implementing yet another > > protocol in the gateways. > > > > I strongly disagree with this usage of SIP. SIP-T is good > as long as the > > SIP cloud provides services. If not, SIP-T is not a good > protocol for > > transporting ISUP signalling. > > > > Best regards, > > > > Gonzalo > > > > If you believe that the sip role encompasses functions that > > > might apply to the PSTN subscribers, then you need to > have the entire > > > number, and the multiple call leg approach is the right way to go. > > > > > > The multiple call leg approach is clearly ugly and > inelegant, but it has the > > > nice property of completely masking the existence of > overlap from proxies > > > and app servers within the network, allowing them to > provide services in the > > > normal way. > > > > > > -Jonathan R. > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > -----Original Message----- > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > Sent: Thursday, February 08, 2001 7:00 AM > > > To: Gonzalo Camarillo > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > > > You are correct about using some other means of transport if ISUP > > > trans-shipment is all your network is doing. If the call > destination (to a > > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) > varies on a per-call > > > basis, however, using SIP to establish your call routing > leads to using SIP > > > to carry the ISUP. > > > > -----Original Message----- > > > > From: Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hi Tom, > > > > > > > > Still I want to have full state in every SIP message. > If the call is > > > > addresed to the phone number 1234, I want to have a to > field that says > > > > 1234. I do not care if there is a leg routed thru the > PSTN and another > > > > thru SIP. > > > > > > > > Carrying full state is one of the beauties of SIP. If > we begin using > > > > INFO for this, it would be the same as using SAMs. > Differen names, the > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > believe that > > > > if the session has a destination, it should be present in the > > > > to field. > > > > > > > > Again, if a proxy is providing services for this > particular call, it > > > > will want to see the called party number in order to trigger > > > > the proper > > > > service. This is a very good reason for updating the to field > > > > every time > > > > we have more digits. > > > > > > > > I like to use SIP between two gateways because it is possible > > > > to provide > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > finding a > > > > egrees gateway, we would probably want to use other > protocols (TRIP & > > > > SIGTRAN for instance). > > > > > > > > Regards, > > > > > > > > Gonzalo > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > statements is > > > > > that an INVITE has reached a UAS which has accepted > it. It follows > > > > > that the UAS did not send back a 484, but rather an interim > > > > response. > > > > > IF more digits come along, the INFO method is there > to carry them. > > > > > They do not affect the SIP call state; they are used > beyond the UAS, > > > > > either in a PSTN call or in another SIP call as the > case may be. > > > > > > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > signalling > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > additional > > > > > > > digits will not change call state. It is therefore > > > > > > reasonable to use > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > ISUP-SIP, once > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > reached, the same > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > vanilla SIP UA. > > > > > I > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > subsequent INFO > > > > > > carrying more digits will be discarded. Thus, the > PSTN to SIP > > > > > gateway > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > Therefore, it is > > > > > > better to begin directly using er-INVITEs rather than INFO. > > > > > > > > > > > > Besides, I do not think that SIP is just a > transport protocol that > > > > > > carries ISUP messages between two gateways. For > that, we have > > > > > already > > > > > > SIGTRAN. SIP might be used to provide services, > even when the > > > > > > call is a > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > state. And a > > > > > > SIP message with an incomplete to field does not > carry complete > > > > > state. > > > > > > What if my SIP proxy provides a service for a > PSTN-SIP-PSTN call > > > > > based > > > > > > on the to field (called party number). That proxy would > > > > like to see > > > > > an > > > > > > updated to field, not just a to field that contains > just some > > > > > digits. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Christer Holmberg > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > To: Gonzalo Camarillo > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that > is what has > > > > > > > > been proposed > > > > > > > > earlier in this thread, so I assumed INFO would > be used. The > > > > > > > > reason for > > > > > > > > the discussion from the beginning was that the overlap > > > > > signalling, > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > very well, and > > > > > > > a > > > > > > > > solution using 18x responses and INFO messages, > instead of 484 > > > > > and > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has > been pretty much > > > > > > > > about calls > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > SIP UAS > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > | <- 200 (INFO) | > -- INVITE > > > > > > > > > > --> > > > > > > > > > > | <- 200 (INVITE)| > <- 200 ------ > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I > am not using > > > > > > > > the word 'proxy') > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > overlap dialing, to > > > > > > > > > > be able to find the SIP UAS, and INFO is > used to provide > > > > > > > > the digits > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > if you like) > > > > > > > > be allowed to > > > > > > > > > > behave like this, or MUST it send 486s, and > receive new > > > > > > > > INVITEs, until > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : > Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : > Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > ------_=_NextPart_001_01C0975D.88D72E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Operlap dialing within a SIP network

Gonzalo,

I don't understand your comment about the INFO = Overlap proposals causing problems for 'vanilla' SIP UAs. My suggestion = was that the use of INFOs for overlap digits be negotiated between UAC = and UAS.

So, the UAC would include a 'Supported' tag if it = could do overlap INFOs and the mechanism would then only be used if = both ends supported it. Otherwise you would just kill session requests = without enough digits with 484s.

Regarding Application Servers, the INFOs should = certainly contain all the digits so far (otherwise we get the problems = with lost messages). I do not believe any proxies exist which are being = used today in overlap situations and which need access to the whole = called number, so we can add this capability to the specification = without hurting any existing implementations.

Finally, there are many reasons other than simple = load balancing why one INVITE might be routed differently to a = subsequent, apparently identical, one. e.g. Time of day routing - which = is certainly not 'random'. Stateful proxies may also remember where = they sent the INVITE so that subsequent requests on the same call leg = can be routed the same way.

Regards,

Mark Watson
Nortel Networks

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> Sent: 14 February 2001 14:31
> To: Keith Robinson
> Cc: Jonathan Rosenberg; Taylor, Tom-PT = [NORSE:B901:EXCH]; Christer
> Holmberg; sip@lists.bell-labs.com
> Subject: Re: [SIP] Operlap dialing within a SIP = network
>
>
> Hello Keith,
>
> Keith Robinson wrote:
> >
> > Gonzalo,
> >
> >      It seems you = have two main reasons against the use of the INFO
> > method for the conveyance of subsequent = ISUP information:
> >
> > 1) Lack of ordered delivery of the INFO = messages
> >
> > Ordered delivery could be maintained by = the UAC not sending
> the next INFO
> > until a 200 OK response for the previous = one had been received.
> >
> > 2) Lack of state carried in the INFO = messge
> >
> > The digits received so far could be = carried in a header within the
> > INFO message. Each INFO message would then = carry the same
> information
> > as a re-INVITE.
> >
>
> Actually my main reason against the use of INFO = is that it
> does not work
> with vanilla SIP UAs and vanilla SIP = Application Servers. How you
> resolve the technical issues related to INFO = does not really matter to
> me. It is not "vanilla" SIP, and I am = against this kind of
> non-standard
> mechanisms.
>
>
> > My reason for exploring the use of INFO is = not to save on
> messages. It is
> > to do with the issue of source routing. = Again, my concern of source
> > routing is not one of a technical nature. = What if an
> administration has a
> > security policy that states source routing = (a ROUTE header in
> > an initial INVITE) will not take place in = its SIP network
> but it also requires
> > that
> > the same network interworks with the PSTN; = if any part of
> the PSTN interworking
> > mechanism
> > relies on source routing then there is a = conflict of
> requirements. It is this
> > conflict
> > I wish to address.
> >
>
> OK, let's address this. Source routing is = proposed in the draft to
> address load balancing. This is, a proxy that = sends INVITEs
> to different
> egrees gateways.
>
> So, if an IAM and one SAM are received, the = second INVITE might end up
> in another gateway than the fist INVITE. This = would trigger 2 IAMs
> instead of 1 IAM and 1 SAM.
>
> OK, this is the problem that has to be solved. = What I wanted to say in
> the draft (I did not have lot of time and it = has to be rephrased), was
> the following:
>
> It is strongly RECOMMENDED that proxies route = requests that are
> basically identical and just differ in the to = field (more
> digits) in the
> same way. So, if such as proxy performs load = balancing, all the
> subsequent INVITEs will reach the same egrees = gateway.
>
> This is not difficult to do, because most = likely a call to
> +1234 has to
> be routed in the same way as a call to +12345. = So, the only real
> requirement in that proxies do not make routing = decisions based on
> random variables (such as internal = clocks).
>
> Then, just in case folks did not feel = comfortable with this solution
> (which I believe is the good one), I outlined = the source routing
> solution.
>
> And what about load balancing? You can still = have load balancing. Your
> proxy makes the routing decision based on to, = from, and what
> ever fields
> it wants. Then, it can calculate a digest of = some fields, and make a
> "random" routing decision based on = that hash. This provides load
> balancing but still routes INVITEs carrying = SAMs in the proper way.
>
> Does this resolve your issue?
>
> Best regards,
>
> Gonzalo
>
>
>
> > Regards,
> >
> > K. Robinson.
> >
> > Gonzalo Camarillo = <Gonzalo.Camarillo@lmf.ericsson.se> on
> 01/01/88 00:39:14
> >
> >
> >
> >
> >
> >
> >
> >  To:      = Jonathan Rosenberg <jdrosen@dynamicsoft.com>
> >
> >  cc:      = "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
> = >           = Christer Holmberg
> = >           = <christer.holmberg@lmf.ericsson.se>,
> = >           = sip@lists.bell-labs.com(bcc: Keith
> = >           = Robinson/MAIN/MC1)
> >
> >
> >
> >  Subject: Re: [SIP] Operlap dialing = within a SIP network
> >
> >
> > Hello,
> >
> > Jonathan Rosenberg wrote:
> > >
> > > I think the correct answer about = which approach to use
> (INFO vs. multiple
> > > call legs) depends on your view of = the scope of the
> address within the sip
> > > cloud. If you believe that the sip = role has ended once
> you have enough
> > > digits to select an egress gateway = (which may be as few
> as one, i.e., +1
> > > selects a US gateway), then the sip = address of that
> gateway can be viewed as
> > > sip:+1@provider.com, and all = subsequent digits are PSTN
> issues, outside the
> > > scope of SIP.
> >
> > I definitively agree that this is the view = that INFO fans
> have of a SIP
> > cloud. What I am saying is that this view = is wrong. This
> usage of SIP
> > falls outside the scope of SIP.
> > If they want to use SIP for locating a = gateway,  it is
> fine. But after
> > the gateway has been located, let's use = another method for
> transporting
> > ISUP signalling.
> >
> > Let's assume that I get an IAM with = "+1", as Jonathan says in his
> > example. Then the INVITE generated by the = gateway will reach the US
> > gateway. Now, the mission of SIP has = finished, since the gateway has
> > been located. Why don't we put in the body = of this INVITE a session
> > description that comprises a media session = and a SIGTRAN
> session? This
> > way we would have established these two = sessions between
> the gateways
> > and all the subsequent ISUP messages would = be sent over the SIGTRAN
> > session.
> >
> > I find that the usage of SIP that I have = just described would be OK.
> > What I do not understand is why folks want = to use SIP for
> transporting
> > subsequent ISUP messages. SIP does not = have good transport
> properties
> > (big overhead, it can run over UDP...). = Besides, it does not provide
> > ordered delivery.
> >
> > If the INVITE has Cseq=3D1 and the next = message that the
> egrees gateway
> > receives is a INFO with Cseq=3D7... what = should the gateway do? Maybe
> > there were several proxies in the middle = asking for
> credentials for the
> > INFO, so the ingrees gateway had to add = authentication
> stuff and resend
> > the INFO. If this was the case, the SAM = contained in the
> INFO would be
> > the second digit of the called party = number... However, maybe 5 INFO
> > messages got lost, and the SAM that we = have received in the
> body of the
> > INFO makes no sense without the previous = ones because is
> the 7th digit
> > of the number...
> >
> > This is not usually a problem in SIP, = since all messages have full
> > state. However, using INFO for sending = SAMs breaks this rule, and
> > therefore it breaks the SIP model.
> >
> > I believe that considering that the = session is established after the
> > first INVITE and sending the following = SAMs using INFO is
> making one of
> > the mistakes described in the guidelines = for SIP authors:
> "We need to
> > transport ISUP signalling over IP between = two gateways.
> Both gateways
> > already implement SIP... why do we have to = implement
> another protocol?
> > Let's use SIP to transport ISUP = signalling". We are just
> trying to use
> > SIP for this just because it would save = implementing yet another
> > protocol in the gateways.
> >
> > I strongly disagree with this usage of = SIP. SIP-T is good
> as long as the
> > SIP cloud provides services. If not, SIP-T = is not a good
> protocol for
> > transporting ISUP signalling.
> >
> > Best regards,
> >
> > Gonzalo
> >
> >  If you believe that the sip role = encompasses functions that
> > > might apply to the PSTN subscribers, = then you need to
> have the entire
> > > number, and the multiple call leg = approach is the right way to go.
> > >
> > > The multiple call leg approach is = clearly ugly and
> inelegant, but it has the
> > > nice property of completely masking = the existence of
> overlap from proxies
> > > and app servers within the network, = allowing them to
> provide services in the
> > > normal way.
> > >
> > > -Jonathan R.
> > >
> > > ---
> > > Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
> > > Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> > > = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> > > = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> > > http://www.cs.columbia.edu/~jdrosen  &nb= sp;      PHONE: (973) 952-5000
> > > http://www.dynamicsoft.com
> > >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c= om]
> > > Sent: Thursday, February 08, 2001 = 7:00 AM
> > > To: Gonzalo Camarillo
> > > Cc: Christer Holmberg; = sip@lists.bell-labs.com
> > > Subject: RE: [SIP] Operlap dialing = within a SIP network
> > >
> > > You are correct about using some = other means of transport if ISUP
> > > trans-shipment is all your network is = doing.  If the call
> destination (to a
> > > SIP endpoint, to an H.323 endpoint, = to a PSTN endpoint)
> varies on a per-call
> > > basis, however, using SIP to = establish your call routing
> leads to using SIP
> > > to carry the ISUP.
> > > > -----Original = Message-----
> > > > From: Gonzalo Camarillo
> [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > > Sent: Tuesday, February 06, 2001 = 9:52 PM
> > > > To: Taylor, Tom-PT = [NORSE:B901:EXCH]
> > > > Cc: Christer Holmberg; = sip@lists.bell-labs.com
> > > > Subject: Re: [SIP] Operlap = dialing within a SIP network
> > > >
> > > >
> > > > Hi Tom,
> > > >
> > > > Still I want to have full state = in every SIP message.
> If the call is
> > > > addresed to the phone number = 1234, I want to have a to
> field that says
> > > > 1234. I do not care if there is = a leg routed thru the
> PSTN and another
> > > > thru SIP.
> > > >
> > > > Carrying full state is one of = the beauties of SIP. If
> we begin using
> > > > INFO for this, it would be the = same as using SAMs.
> Differen names, the
> > > > same thing... I do not want to = re-create ISUP using SIP. I
> > > > believe that
> > > > if the session has a = destination, it should be present in the
> > > > to field.
> > > >
> > > > Again, if a proxy is providing = services for this
> particular call, it
> > > > will want to see the called = party number in order to trigger
> > > > the proper
> > > > service. This is a very good = reason for updating the to field
> > > > every time
> > > > we have more digits.
> > > >
> > > > I like to use SIP between two = gateways because it is possible
> > > > to provide
> > > > SIP services for a PSTN to PSTN = call. If all we want to do is
> > > > finding a
> > > > egrees gateway, we would = probably want to use other
> protocols (TRIP &
> > > > SIGTRAN for instance).
> > > >
> > > > Regards,
> > > >
> > > > Gonzalo
> > > >
> > > > Tom-PT Taylor wrote:
> > > > >
> > > > > Sorry, we're talking past = each other.  The premise of my
> > > > statements is
> > > > > that an INVITE has reached = a UAS which has accepted
> it.  It follows
> > > > > that the UAS did not send = back a 484, but rather an interim
> > > > response.
> > > > > IF more digits come along, = the INFO method is there
> to carry them.
> > > > > They do not affect the SIP = call state; they are used
> beyond the UAS,
> > > > > either in a PSTN call or in = another SIP call as the
> case may be.
> > > > >
> > > > > > -----Original = Message-----
> > > > > > From: Gonzalo = Camarillo
> [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > > > > Sent: Tuesday, = February 06, 2001 9:10 PM
> > > > > > To: Taylor, Tom-PT = [NORSE:B901:EXCH]
> > > > > > Cc: Christer Holmberg; = sip@lists.bell-labs.com
> > > > > > Subject: Re: [SIP] = Operlap dialing within a SIP network
> > > > > >
> > > > > >
> > > > > > Hello Tom,
> > > > > >
> > > > > > Tom-PT Taylor = wrote:
> > > > > > >
> > > > > > > Just to re-hash, = in the ISUP-SIP-ISUP context, once call
> > > > > signalling
> > > > > > > has reached an = egress gateway, SIP has done its job --
> > > > additional
> > > > > > > digits will not = change call state.  It is therefore
> > > > > > reasonable to = use
> > > > > > > INFO to carry the = additional digits.  If we are talking
> > > > > > ISUP-SIP, once
> > > > > > > the destination = UAS or a UAS in a B2BUA has been
> > > > reached, the same
> > > > >
> > > > > > > consideration = applies.
> > > > > > >
> > > > > >
> > > > > > I do not agree with = these two statements:
> > > > > >
> > > > > > The 1st INVITE (with = just some digits) arrives to a
> > > > vanilla SIP UA.
> > > > > I
> > > > > > will return a Not = Found or a 484 Address incomplete. The
> > > > > > subsequent INFO
> > > > > > carrying more digits = will be discarded. Thus, the
> PSTN to SIP
> > > > > gateway
> > > > > > will have to re issue = a new INVITE with all the digits.
> > > > > > Therefore, it = is
> > > > > > better to begin = directly using er-INVITEs rather than INFO.
> > > > > >
> > > > > > Besides, I do not = think that SIP is just a
> transport protocol that
> > > > > > carries ISUP messages = between two gateways. For
> that, we have
> > > > > already
> > > > > > SIGTRAN. SIP might be = used to provide services,
> even when the
> > > > > > call is a
> > > > > > PSTN-SIP-PSTN call. = Thus, SIP messages MUST carry complete
> > > > > > state. And a
> > > > > > SIP message with an = incomplete to field does not
> carry complete
> > > > > state.
> > > > > > What if my SIP proxy = provides a service for a
> PSTN-SIP-PSTN call
> > > > > based
> > > > > > on the to field = (called party number). That proxy would
> > > > like to see
> > > > > an
> > > > > > updated to field, not = just a to field that contains
> just some
> > > > > digits.
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Gonzalo
> > > > > >
> > > > > >
> > > > > > > > = -----Original Message-----
> > > > > > > > From: = Christer Holmberg
> > > > > [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > > > > > > > Sent: = Tuesday, February 06, 2001 1:15 AM
> > > > > > > > To: Gonzalo = Camarillo
> > > > > > > > Cc: = sip@lists.bell-labs.com
> > > > > > > > Subject: Re: = [SIP] Operlap dialing within a SIP network
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi = Gonzalo,
> > > > > > > >
> > > > > > > > I didn't say = I am going to use INFO, but that
> is what has
> > > > > > > > been = proposed
> > > > > > > > earlier in = this thread, so I assumed INFO would
> be used. The
> > > > > > > > reason = for
> > > > > > > > the = discussion from the beginning was that the overlap
> > > > > signalling,
> > > > > > > > according to = the SIP-ISUP mapping draft, may not work
> > > > > > very well, and
> > > > > > > a
> > > > > > > > solution = using 18x responses and INFO messages,
> instead of 484
> > > > > and
> > > > > > > > re-INVITEs, = was proposed.
> > > > > > > >
> > > > > > > > = Regards,
> > > > > > > >
> > > > > > > > Christer = Holmberg
> > > > > > > > Ericsson = Finland
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Gonzalo = Camarillo wrote:
> > > > > > > > >
> > > > > > > > > Hello = Christer,
> > > > > > > > >
> > > > > > > > > Why are = you using INFO for sending extra digits?
> > > > > > > > >
> > > > > > > > > Please, = check the SIP-ISUP mapping draft, overlap
> > > > > > > > signalling = section.
> > > > > > > > >
> > > > > > > > > = Regards,
> > > > > > > > >
> > > > > > > > > = Gonzalo
> > > > > > > > >
> > > > > > > > > = Christer Holmberg wrote:
> > > > > > > > > = >
> > > > > > > > > > = Hi,
> > > > > > > > > = >
> > > > > > > > > > = The discussion about overlap dialing has
> been pretty much
> > > > > > > > about = calls
> > > > > > > > > > = from SIP to PSTN, or PSTN-SIP-PSTN.
> > > > > > > > > = >
> > > > > > > > > > = Consider the following scenario.
> > > > > > > > > = >
> > > > > > > > > > = PSTN = PHONE           &= nbsp; GW           = SIP SERVER
> > > >   SIP UAS
> > > > > > > > > = >
> > > > = -----------------------------------------------------------
> > > > > > > > > = >
> > > > > > > > > > = --- 1 --->    -- IAM -> | -- INVITE -->  = |
> > > > > > > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > > > > = --- 2 --->    -- SAM -> | -- INFO ---->  = |
> > > > > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |
> > > > > > > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > > > > = --- 3 --->    -- SAM -> | -- INFO ---->  = |
> > > > > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  | 
>  -- INVITE
> > > > > > > > > > = -->
> > > > > > > > > = >           &n= bsp;           &n= bsp; | <- 200 (INVITE)| 
>  <- 200 ------
> > > > > > > > > = >
> > > > > > > > > > In = this case, the SIP server (note that I
> am not using
> > > > > > > > the word = 'proxy')
> > > > > > > > > > = must collect digits, sent from the PSTN side using
> > > > > > > > overlap = dialing, to
> > > > > > > > > > be = able to find the SIP UAS, and INFO is
> used to provide
> > > > > > > > the = digits
> > > > > > > > > > = after the INVITE has been sent.
> > > > > > > > > = >
> > > > > > > > > > My = question is, should a SIP server (proxy,
> if you like)
> > > > > > > > be allowed = to
> > > > > > > > > > = behave like this, or MUST it send 486s, and
> receive new
> > > > > > > > INVITEs, = until
> > > > > > > > > > it = is able to find the UAS?
> > > > > > > > > = >
> > > > > > > > > > = Regards,
> > > > > > > > > = >
> > > > > > > > > > = Christer Holmberg
> > > > > > > > > > = Ericsson Finland
> > > > > > > > >
> > > > > > > > > = --
> > > > > > > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > > > > > > Oy L M = Ericsson Ab        Mobile:  = +358 40 702 35 35
> > > > > > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > > > > > > = FIN-02420 Jorvas          = Email :
> > > > > > = Gonzalo.Camarillo@ericsson.com
> > > > > > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > > > FIN-02420 = Jorvas          Email = : 
> Gonzalo.Camarillo@ericsson.com
> > > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > > >
> > > >
> > > > --
> > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > FIN-02420 = Jorvas          Email = : 
> Gonzalo.Camarillo@ericsson.com
> > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > >
> >
> > --
> > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > FIN-02420 = Jorvas          Email = :  Gonzalo.Camarillo@ericsson.com
> > = Finland           = ;        http://www.hut.fi/~gonzalo
> >
> > = _______________________________________________
> > This list is for continuing development of = the SIP protocol.
> > The sip-implementer's list is the place to = discuss implementation,
> > and to receive advice on understanding = existing sip.
> > To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in = the body.
>
> --
> Gonzalo = Camarillo          &nb= sp;         Phone :   = +1 212 939 71 71
> Columbia = University          &n= bsp;       Mobile:  +358 40 702 35 = 35
> 472 Computer Science = Building        Fax   = :  +358  9 299 30 52
> 1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
> New York, NY = 10027           &= nbsp;      
> = USA           &nb= sp;           &nb= sp;      Gonzalo.Camarillo@ericsson.com
>
> = _______________________________________________
> This list is for continuing development of the = SIP protocol.
> The sip-implementer's list is the place to = discuss implementation,
> and to receive advice on understanding existing = sip.
> To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the = body.
>

------_=_NextPart_001_01C0975D.88D72E10-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 09:53:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19508 for ; Thu, 15 Feb 2001 09:53:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E08CD44337; Thu, 15 Feb 2001 09:53:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 3682144336 for ; Thu, 15 Feb 2001 09:52:51 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id GAA22963; Thu, 15 Feb 2001 06:49:25 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f1FEnTb18762; Thu, 15 Feb 2001 06:49:29 -0800 (PST) Received: from chsharp-w2k.cisco.com ([10.21.54.6]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id GAA02794; Thu, 15 Feb 2001 06:49:20 -0800 (PST) Message-Id: <4.3.2.7.2.20010215093604.01b1fec8@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Mark Watson" From: Chip Sharp Subject: RE: [SIP] Re: Location information Cc: "'Christian Huitema'" , "Rosen, Brian" , William Marshall , sip In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 09:49:16 -0500 The term "public network" has regulatory implications in most countries. As you say, SIP runs end-to-end over an IP infrastructure. It can run between two endpoints that also terminate the RTP stream (e.g., "SIP phones") or it can run between a SIP UA and a proxy/redirect/etc. server. Either way, the two IP hosts running SIP are endpoints on the IP network and (may) have a customer relationship with the IP network provider (i.e., not belong to the IP access provider). In this case, I may go Christian's question one step further and ask "what is this network you are talking about." ;-) It is kind of like talking about the email network. Basically, SIP exchanges are always private exchanges between two endpoints on the IP network as you say in the first paragraph. :-) As for work going on for restricting users' choice, this should *not* be a work item for the SIP WG charter. I can think of at least one regulatory agency that would be interested in hearing more about this work. :-\ Chip At 07:06 AM 2/15/2001, Mark Watson wrote: >Hmmm, this is perhaps a slightly larger issue than suits this thread, but >anyway: > >If there is no 'man in the middle' i.e. you can find and connect to your >destination directly at the IP layer, then this is essentially a private >transaction between you and the destination. You can do what you like in >this context - it's just up to you and the destination to agree between >youselves. (Although you still both have to respect applicable Data >Protection Legislation in respect of any personal information you receive >from each other.) > >If you make your connection via an intermediate proxy or proxies operated >by a third party, presumably you do this because those proxies offer some >kind of service (e.g. routing). If the third party makes this service >publically available, then this is whom I consider the 'public network'. > >Of course there will be many such service providers that a user can choose >from - though there is plenty of work going on to invent ways of >restricting a users choice in certain environments. > >...Mark >>-----Original Message----- >>From: Christian Huitema [mailto:huitema@exchange.microsoft.com] >>Sent: 06 February 2001 17:37 >>To: Watson, Mark [MAIFP:EP11-M:EXCH]; Rosen, Brian; William Marshall >>Cc: sip >>Subject: RE: [SIP] Re: Location information >> >>Uh, what is exactly the "public network" that you are talking about? The >>ISP to which my entreprise network connects have no idea of what the bits >>in the packets are, and probably don't want to know. The basic SIP >>solution is end-to-end, with the network being essentially transparent. >>Sure, there may be competing voice service providers that want to provide >>added value on top of the basic service, but we cannot assume that there >>has to be a man in the middle. >> >>-- Christian Huitema >> >> >>-----Original Message----- >>From: Mark Watson [mailto:mwatson@nortelnetworks.com] >>Sent: Tuesday, February 06, 2001 8:02 AM >>To: Rosen, Brian; William Marshall >>Cc: sip@lists.bell-labs.com >>Subject: RE: [SIP] Re: Location information >>The public network will likely be trusted in the sense that it promises >>to obey the user's stated privacy requirements, indeed Data Protection >>legislation will usually oblige the public network provider to do this. >>Also, it will likely be a requirement of the public service that >>terminals identify themselves in some way. >>I do not think it likely that for Emergency calls, terminals/networks >>will behave differently with respect to identity information than for >>normal calls except that it will probably not be considered an >>infringement of privacy to deliver identity information to an Emergency >>call centre even when the user has requested it be kept private. >>More complex is how does the public service provider verify the identity >>and location information ? In the example above, the public service >>provider can only be sure of the owner of the Enterprise network from >>which the call came, and this may not translate into a single geographic >>location. The network would be forced to send forward only the >>'unverified' location information provided by the caller. >>...Mark >> >> > -----Original Message----- >> > From: Rosen, Brian >> [mailto:Brian.Rosen@marconi.com] >> > Sent: 05 February 2001 18:48 >> > To: 'William Marshall' >> > Cc: sip@lists.bell-labs.com >> > Subject: RE: [SIP] Re: Location information >> > >> > >> > If I have an enterprise network, and it connects to a public >> > network, then >> > the trust boundary may stop at the private/public boundary. The >> > "subscriber" >> > is the enterprise, not the individual. In the privacy draft, >> > if extended to >> > location, there is no mechanism to: >> > Recognize that this is an emergency call >> > Recognize that the UAS is the emergency center >> > Pass location information despite any of the requests >> > the UAC may >> > make. >> > >> > Yet, the requirement is to identify the location of the individual. >> > I think the draft has some fine mechanisms in it. I just >> > don't think they >> > are >> > sufficient for emergency purposes. >> > >> > Brian >> > >> > > -----Original Message----- >> > > From: William Marshall >> [mailto:wtm@research.att.com] >> > > Sent: Monday, February 05, 2001 1:31 PM >> > > To: brian.rosen@marconi.com >> > > Cc: sip@lists.bell-labs.com >> > > Subject: RE: [SIP] Re: Location information >> > > >> > > >> > > An ordinary call must yield subscriber information. There is >> > > not an option for the user to suppress this, by law (although the >> > > user may request this information not be given to the destination). >> > > However, the destination can always identify the caller, >> > for purposes >> > > of tracing an obscene or harassing call. >> > > >> > > Accuracy of location is certainly variable, and it is possible >> > > the UA may permit delivery of less precise information, but suppress >> > > accurate information. Multiple levels are just like multiple >> > > identities; >> > > the privacy draft as described by Mark in previous email >> > > allows separate >> > > anonymity requirements to be attached to each. >> > > >> > > Bill Marshall >> > > wtm@research.att.com >> > > >> > > -----original message----- >> > > From: "Rosen, Brian" >> > > To: "'William Marshall'" >> > > Cc: sip@lists.bell-labs.com >> > > Subject: RE: [SIP] Re: Location information >> > > Date: Mon, 5 Feb 2001 12:01:48 -0500 >> > > >> > > The problem that location presents that is different from the >> > > privacy draft (unless I missed it) is that an emergency call must >> > > yield location information. There is not an option for the user >> > > to suppress this, by law. The path by which a user might connect >> > > to an emergency center cannot be pre-arranged. I believe that it >> > > will take creation of a cryptographically secure infrastructure >> > > to allow such a system to have the desired property that the user >> > > can control location information, but when required it can be >> > > securely delivered. >> > > >> > > I also think that location is not an "all or nothing" kind of >> > > thing. The privacy draft presupposes that the world is bifurcated >> > > into trusted and untrusted domains, and privacy is secured >> > > when venturing into an untrusted domain. This is not the behavior >> > > I really want. The desired behavior I want is: >> > > Accuracy (precision) of location is variable >> > > I may want to give some people precise >> > > information, others >> > > less precise. There will be multiple levels >> > > Time (and motion) variability - if I am mobile, then where I >> > > am changes over time. I need to express this somehow, >> > > but I also need to control it (not everyone can >> > > be told that >> > > I am mobile) >> > > What we learned in the spatial effort is that the whole >> > location thing >> > > is more complex that you would like it to be, and it is hard to get >> > > an implementable subset that has enough functionality to be >> > > interesting. >> > > We also learned the difficulties in reaching consensus on >> > issues that >> > > involve privacy. >> > > >> > > Brian >> > > >> > > >> > > >> > > >> > > > -----Original Message----- >> > > > From: William Marshall >> [mailto:wtm@research.att.com] >> > > > Sent: Monday, February 05, 2001 11:40 AM >> > > > To: brian.rosen@marconi.com >> > > > Cc: sip@lists.bell-labs.com >> > > > Subject: [SIP] Re: Location information >> > > > >> > > > >> > > > Brian, >> > > > >> > > > It seems that the privacy draft faces up squarely to the privacy >> > > > concerns. The draft already deals with all the regulatory >> > > > requirements >> > > > about verification of identity, hiding of identity, etc. >> > > The security >> > > > implications of knowing who you are are just as daunting >> > as knowing >> > > > where you are. In some places regulations already cover >> > > > location info, >> > > > and the framework in the privacy draft deals with them. >> > > > >> > > > As with the subscriber identity - the UA may insert it, and may >> > > > demand (via a tag and a Proxy-Require) that it be kept private. >> > > > The proxies may verify the identity, and mark it verified, or mark >> > > > it unverified, and must delete the information if privacy was >> > > > requested. >> > > > The procedures are all there in the privacy draft, and just need >> > > > some minor extensions to handle multiple identity types, and >> > > > per-identity >> > > > privacy requests. >> > > > >> > > > The previous efforts (spatial) generated a string giving location >> > > > information. Sip uses "name-addr | addr-spec" everywhere, which >> > > > includes a display-name string; however a URL format >> > would be nicer. >> > > > I was sure I had heard about a URL format with this >> > information, but >> > > > can't find any reference to it. >> > > > >> > > > Bill Marshall >> > > > wtm@research.att.com >> > > > >> > > > -----original message----- >> > > > From: "Rosen, Brian" >> > > > Subject: RE: Location information (was Re: [SIP] SIP >> > Privacy Draft) >> > > > Date: Mon, 5 Feb 2001 10:44:54 -0500 >> > > > >> > > > There was an effort started several IETFs ago to define a PROTOCOL >> > > > to exchange geographic location. That was shot down. >> > > There is still >> > > > a low level effort to define a format for exchanging such >> > > information. >> > > > >> > > > Before starting another effort, you might want to look at >> > the prior >> > > > work (spatial). You also MUST forthrightly face up to the privacy >> > > > concerns that have stymied other efforts. The security >> > > > implications of >> > > > knowing where you are can be VERY daunting, and in general >> > > discussions >> > > > on the issues have yielded more problems than answers.' >> > > > >> > > > Brian >> > > > >> > > > >> > > > _______________________________________________ >> > > > This list is for continuing development of the SIP protocol. >> > > > The sip-implementer's list is the place to discuss implementation, >> > > > and to receive advice on understanding existing sip. >> > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with >> > > > "subscribe sip-implementors" in the body. >> > > > >> > > >> > >> > _______________________________________________ >> > This list is for continuing development of the SIP protocol. >> > The sip-implementer's list is the place to discuss implementation, >> > and to receive advice on understanding existing sip. >> > To subscribe to it, send mail to majordomo@cs.columbia.edu with >> > "subscribe sip-implementors" in the body. >> > ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems ------------------------------------------------------------------- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 10:16:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20393 for ; Thu, 15 Feb 2001 10:16:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7AE4A4437C; Thu, 15 Feb 2001 10:16:06 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 66FA74435E for ; Thu, 15 Feb 2001 10:15:40 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Feb 15 10:13:29 EST 2001 Received: by lists.bell-labs.com (Postfix) id 6277044380; Thu, 15 Feb 2001 10:01:58 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 1E38C4437D for ; Thu, 15 Feb 2001 10:01:58 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA05204; Thu, 15 Feb 2001 09:01:54 -0600 Cc: "sip@lists.bell-labs.com" Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA05161; Thu, 15 Feb 2001 09:01:53 -0600 Message-ID: <3A8BEF49.D2C39C9E@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies/Bell Laboratories X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijeth D Original-CC: "sip@lists.bell-labs.com" Subject: Re: [SIP] Doubt in the RFC References: <20010215052933.14245.qmail@mailweb14.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 09:01:29 -0600 Content-Transfer-Encoding: 7bit Vijeth D wrote: > > Hi, > I would like to know if the rfc bis-02 has to be followed while > implementing SIP or the original RFC. Because there are some deviations > are present which are not mentioned in the changes section. I beleive until the bis obsoletes RFC 2543, the latter is the authoratative word on SIP. Most of the changes made to the bis are backwards compatible, except for a couple of places; to wit, some headers (R-R, for instance) in the bis can accept additional parameters (rr-param) which may cause a strict RFC 2543 parser to choke. Also, the bis adds some new response codes; "487 Request Terminated" springs to mind... - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 13:18:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26276 for ; Thu, 15 Feb 2001 13:18:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B0DD044366; Thu, 15 Feb 2001 13:18:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id 540E644363 for ; Thu, 15 Feb 2001 13:17:35 -0500 (EST) Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G8T003149B524@firewall.mcit.com> for sip@lists.bell-labs.com; Thu, 15 Feb 2001 18:13:53 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) id <0G8T008019B4EF@dgismtp04.wcomnet.com>; Thu, 15 Feb 2001 18:13:52 +0000 (GMT) Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G8T008019AYBT@dgismtp04.wcomnet.com>; Thu, 15 Feb 2001 18:13:49 +0000 (GMT) Received: from Steveb1 ([166.35.224.41]) by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0G8T003FJ9AKCD@dgismtp04.wcomnet.com>; Thu, 15 Feb 2001 18:13:33 +0000 (GMT) From: "Christopher A. Martin" Subject: RE: [SIP] Doubt in the RFC In-reply-to: <3A8BEF49.D2C39C9E@lucent.com> To: "'Vijay Gurbani'" , "'Vijeth D'" Cc: sip@lists.bell-labs.com Reply-To: christopher.a.martin@wcom.com Message-id: <000301c0977a$ff4fd480$6401010a@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 12:13:27 -0600 Content-Transfer-Encoding: 7bit I would have to add a grain of salt to this and add that the bug fixes in bis02 should be followed, as they are obvious fixes to real problems found in the current RFC. Other than that the RFC should be adhered to, IMHO. > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Vijay Gurbani > Sent: Thursday, February 15, 2001 9:01 AM > To: Vijeth D > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Doubt in the RFC > > > Vijeth D wrote: > > > > Hi, > > I would like to know if the rfc bis-02 has to be followed while > > implementing SIP or the original RFC. Because there are > some deviations > > are present which are not mentioned in the changes section. > > I beleive until the bis obsoletes RFC 2543, the latter is the > authoratative > word on SIP. Most of the changes made to the bis are > backwards compatible, > except for a couple of places; to wit, some headers (R-R, for > instance) in > the bis can accept additional parameters (rr-param) which may > cause a strict > RFC 2543 parser to choke. Also, the bis adds some new > response codes; "487 > Request Terminated" springs to mind... > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Internet Software and eServices Group > Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: > +1 630 713 0184 > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 15:04:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28911 for ; Thu, 15 Feb 2001 15:04:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 40EA844349; Thu, 15 Feb 2001 15:04:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4EB0044336 for ; Thu, 15 Feb 2001 15:03:52 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA19658; Thu, 15 Feb 2001 15:06:56 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <1MKR93LQ>; Thu, 15 Feb 2001 15:00:00 -0500 Message-ID: From: Jonathan Rosenberg To: "'sip@lists.bell-labs.com'" Cc: "'aaa-wg@merit.edu'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP-AAA mailing list formed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 14:59:58 -0500 Folks, As discussed during the sip working group interim meeting, I have formed a mailing list for discussions of aaa architectures and requirements in support of sip enabled systems. You can find information, subscribe, and so on, at: http://mailman.dynamicsoft.com/mailman/listinfo/sip-aaa The purpose of the list is to have technical discussions, not to continue the endless argument about which working group is responsible for owning the items. I, as a member of the technical community interested in building complete solutions based on sip, believe this is an important subject to work on, no matter where it takes place. I think others agree. This list can serve as a forum for having those discussions. Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 16:48:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01067 for ; Thu, 15 Feb 2001 16:48:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D35624433A; Thu, 15 Feb 2001 16:48:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from iex.iex.com (iex.iex.com [192.153.124.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6BB4C44336 for ; Thu, 15 Feb 2001 16:47:41 -0500 (EST) Received: from iexfw.iex.com ([192.153.124.100]) by iex.iex.com (8.9.1/8.9.3) with SMTP id PAA18553 for ; Thu, 15 Feb 2001 15:47:37 -0600 (CST) Received: from mail.iex.com ([172.25.41.2]) by home.iex.com (8.9.3/8.9.3) with ESMTP id PAA04149 for ; Thu, 15 Feb 2001 15:47:35 -0600 (CST) Message-ID: <3A8C4F50.F0F6E7D2@mail.iex.com> From: Doug Hurtig Reply-To: hurtig@iex.com Organization: IEX Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Cancel of Invite and affect (if any) on prack and reliable provisional responses Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 15:51:12 -0600 Content-Transfer-Encoding: 7bit Hi,

  I have a question related to what should the UAC and UAS do with outstanding
  PRACK requests and reliable provisional responses when the associated INVITE
  is canceled?

    UAC                               UAS

    INVITE -------------------------->

           <-------------------------- 100 provisional response
           <-------------------------- 18x reliable provisional response

    PRACK  ------------> lost

    CANCEL -------------------------->
 

  At this point the UAC is waiting the 200 OK for CANCEL and will resend
  PRACK on time-out. UAS is awaiting PRACK for 18x and will resend 18x on
  time-out.

  Should UAC abort the PRACK or let it continue?

  UAS must send the 200 OK for the CANCEL and should send a 487 response
  for the INVITE. Should the UAS abort the timer associated with any active
  18x response? That is, stop waiting for the PRACK.

 
 
--
Regards,
Doug Hurtig

Tekelec
2425 N. Central Expressway
Richardson, Texas 75080

hurtig@iex.com
972.301.1203
  _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 16:55:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01216 for ; Thu, 15 Feb 2001 16:55:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8F6D24435E; Thu, 15 Feb 2001 16:55:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id DEAA84433A for ; Thu, 15 Feb 2001 16:54:12 -0500 (EST) 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 f1FLgId03701; Thu, 15 Feb 2001 22:42:18 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id XAA07087; Thu, 15 Feb 2001 23:42:12 +0200 (EET) Message-ID: <3A8C4D36.AB192B3F@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson Cc: "'Gonzalo Camarillo'" , Keith Robinson , Jonathan Rosenberg , Tom-PT Taylor , sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: Content-Type: multipart/mixed; boundary="------------4B8A520F835A9E2D612744B5" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 23:42:14 +0200 This is a multi-part message in MIME format. --------------4B8A520F835A9E2D612744B5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Again, I am Gonzalo, but I will also comment... :) Mark Watson wrote: > >Gonzalo, > >I don't understand your comment about the INFO Overlap proposals >causing problems for 'vanilla' SIP UAs. My suggestion was that the use >of INFOs for overlap digits be negotiated between UAC and UAS. My personal opinion is that, even if this overlap dialing thing seems like a very difficult problem to solve, the functionality itself is pretty minor, so I don't think that a UA should have to negotiate about the method to use for this... Also, I don't think your negotiation proposal would work. You should remember that you have to reach the UAS before you can do this negotiation in the first place, which means you may have to send a number of INVITEs, and receive 484 responses from proxies. And, even when you reach the UAS (let's assume it's a PSTN gateway), it may be able to forward the digits, so the only answer you are going to get is 100 - which you will get from the first proxy, so the UAS can't include the negotiation result there. This response-from-the-UAS thing is, however, related to another issue which I will describe in another mail. >So, the UAC would include a 'Supported' tag if it could do overlap >INFOs and the mechanism would then only be used if both ends supported >it. Otherwise you would just kill session requests without enough >digits with 484s. See my comment above why I don't this would work very well. >Regarding Application Servers, the INFOs should certainly contain all >the digits so far (otherwise we get the problems with lost messages). >I do not believe any proxies exist which are being used today in >overlap situations and which need access to the whole called number, >so we can add this capability to the specification without hurting any >existing implementations. Well, well, well... Let's assume it's a proxy that sends the 484 response. Then, if you want to start using INFO, this proxy must remember the INVITE, and collect the INFOs. Then, when the proxy has enough digits, what shall it do then? Create an INVITE of it's own? What will then happen when the UAC receive the response for an INVITE it never created? Also, when the proxy sends the INVITE, it may receive 484 responses from the NEXT proxy in the network, asking for more digits. Ie, your proxy would have to both collect digits from the UAC, and handle the next entity (in this example, another proxy) in the SIP nework. All this would DEFINITELY hurt existing implementations, so you would also have to negotiate with the proxies if they are able to do this... In this case I think Keith's proposal, ie that the proxy is smart enough to see that the only thing that has changed in the new INVITE is the receiver digits, is MUCH easier to implement :) >Finally, there are many reasons other than simple load balancing why >one INVITE might be routed differently to a subsequent, apparently >identical, one. e.g. Time of day routing - which is certainly not >'random'. Stateful proxies may also remember where they sent the >INVITE so that subsequent requests on the same call leg can be routed >the same way. I agree, routing is a problem, but there has been proposals to solve it, ie the one Keith gave. Also, I think that routing, and forking, is the reason for a number of SIP related problems, so I think it is better to find a generic solution to that. Allowing ROUTE headers in specific situations (again, see Keith's proposal) in initial requests is partly a solution. Regards, Christer Holmberg Ericsson Finland > > Regards, > > Mark Watson > Nortel Networks > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > Sent: 14 February 2001 14:31 > > To: Keith Robinson > > Cc: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B901:EXCH]; Christer > > Holmberg; sip@lists.bell-labs.com > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > Hello Keith, > > > > Keith Robinson wrote: > > > > > > Gonzalo, > > > > > > It seems you have two main reasons against the use of the > INFO > > > method for the conveyance of subsequent ISUP information: > > > > > > 1) Lack of ordered delivery of the INFO messages > > > > > > Ordered delivery could be maintained by the UAC not sending > > the next INFO > > > until a 200 OK response for the previous one had been received. > > > > > > 2) Lack of state carried in the INFO messge > > > > > > The digits received so far could be carried in a header within the > > > > INFO message. Each INFO message would then carry the same > > information > > > as a re-INVITE. > > > > > > > Actually my main reason against the use of INFO is that it > > does not work > > with vanilla SIP UAs and vanilla SIP Application Servers. How you > > resolve the technical issues related to INFO does not really matter > to > > me. It is not "vanilla" SIP, and I am against this kind of > > non-standard > > mechanisms. > > > > > > > My reason for exploring the use of INFO is not to save on > > messages. It is > > > to do with the issue of source routing. Again, my concern of > source > > > routing is not one of a technical nature. What if an > > administration has a > > > security policy that states source routing (a ROUTE header in > > > an initial INVITE) will not take place in its SIP network > > but it also requires > > > that > > > the same network interworks with the PSTN; if any part of > > the PSTN interworking > > > mechanism > > > relies on source routing then there is a conflict of > > requirements. It is this > > > conflict > > > I wish to address. > > > > > > > OK, let's address this. Source routing is proposed in the draft to > > address load balancing. This is, a proxy that sends INVITEs > > to different > > egrees gateways. > > > > So, if an IAM and one SAM are received, the second INVITE might end > up > > in another gateway than the fist INVITE. This would trigger 2 IAMs > > instead of 1 IAM and 1 SAM. > > > > OK, this is the problem that has to be solved. What I wanted to say > in > > the draft (I did not have lot of time and it has to be rephrased), > was > > the following: > > > > It is strongly RECOMMENDED that proxies route requests that are > > basically identical and just differ in the to field (more > > digits) in the > > same way. So, if such as proxy performs load balancing, all the > > subsequent INVITEs will reach the same egrees gateway. > > > > This is not difficult to do, because most likely a call to > > +1234 has to > > be routed in the same way as a call to +12345. So, the only real > > requirement in that proxies do not make routing decisions based on > > random variables (such as internal clocks). > > > > Then, just in case folks did not feel comfortable with this solution > > > (which I believe is the good one), I outlined the source routing > > solution. > > > > And what about load balancing? You can still have load balancing. > Your > > proxy makes the routing decision based on to, from, and what > > ever fields > > it wants. Then, it can calculate a digest of some fields, and make a > > > "random" routing decision based on that hash. This provides load > > balancing but still routes INVITEs carrying SAMs in the proper way. > > > > Does this resolve your issue? > > > > Best regards, > > > > Gonzalo > > > > > > > > > Regards, > > > > > > K. Robinson. > > > > > > Gonzalo Camarillo on > > 01/01/88 00:39:14 > > > > > > > > > > > > > > > > > > > > > > > > To: Jonathan Rosenberg > > > > > > cc: "'Tom-PT Taylor'" , > > > Christer Holmberg > > > , > > > sip@lists.bell-labs.com(bcc: Keith > > > Robinson/MAIN/MC1) > > > > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > Hello, > > > > > > Jonathan Rosenberg wrote: > > > > > > > > I think the correct answer about which approach to use > > (INFO vs. multiple > > > > call legs) depends on your view of the scope of the > > address within the sip > > > > cloud. If you believe that the sip role has ended once > > you have enough > > > > digits to select an egress gateway (which may be as few > > as one, i.e., +1 > > > > selects a US gateway), then the sip address of that > > gateway can be viewed as > > > > sip:+1@provider.com, and all subsequent digits are PSTN > > issues, outside the > > > > scope of SIP. > > > > > > I definitively agree that this is the view that INFO fans > > have of a SIP > > > cloud. What I am saying is that this view is wrong. This > > usage of SIP > > > falls outside the scope of SIP. > > > If they want to use SIP for locating a gateway, it is > > fine. But after > > > the gateway has been located, let's use another method for > > transporting > > > ISUP signalling. > > > > > > Let's assume that I get an IAM with "+1", as Jonathan says in his > > > example. Then the INVITE generated by the gateway will reach the > US > > > gateway. Now, the mission of SIP has finished, since the gateway > has > > > been located. Why don't we put in the body of this INVITE a > session > > > description that comprises a media session and a SIGTRAN > > session? This > > > way we would have established these two sessions between > > the gateways > > > and all the subsequent ISUP messages would be sent over the > SIGTRAN > > > session. > > > > > > I find that the usage of SIP that I have just described would be > OK. > > > What I do not understand is why folks want to use SIP for > > transporting > > > subsequent ISUP messages. SIP does not have good transport > > properties > > > (big overhead, it can run over UDP...). Besides, it does not > provide > > > ordered delivery. > > > > > > If the INVITE has Cseq=1 and the next message that the > > egrees gateway > > > receives is a INFO with Cseq=7... what should the gateway do? > Maybe > > > there were several proxies in the middle asking for > > credentials for the > > > INFO, so the ingrees gateway had to add authentication > > stuff and resend > > > the INFO. If this was the case, the SAM contained in the > > INFO would be > > > the second digit of the called party number... However, maybe 5 > INFO > > > messages got lost, and the SAM that we have received in the > > body of the > > > INFO makes no sense without the previous ones because is > > the 7th digit > > > of the number... > > > > > > This is not usually a problem in SIP, since all messages have full > > > > state. However, using INFO for sending SAMs breaks this rule, and > > > therefore it breaks the SIP model. > > > > > > I believe that considering that the session is established after > the > > > first INVITE and sending the following SAMs using INFO is > > making one of > > > the mistakes described in the guidelines for SIP authors: > > "We need to > > > transport ISUP signalling over IP between two gateways. > > Both gateways > > > already implement SIP... why do we have to implement > > another protocol? > > > Let's use SIP to transport ISUP signalling". We are just > > trying to use > > > SIP for this just because it would save implementing yet another > > > protocol in the gateways. > > > > > > I strongly disagree with this usage of SIP. SIP-T is good > > as long as the > > > SIP cloud provides services. If not, SIP-T is not a good > > protocol for > > > transporting ISUP signalling. > > > > > > Best regards, > > > > > > Gonzalo > > > > > > If you believe that the sip role encompasses functions that > > > > might apply to the PSTN subscribers, then you need to > > have the entire > > > > number, and the multiple call leg approach is the right way to > go. > > > > > > > > The multiple call leg approach is clearly ugly and > > inelegant, but it has the > > > > nice property of completely masking the existence of > > overlap from proxies > > > > and app servers within the network, allowing them to > > provide services in the > > > > normal way. > > > > > > > > -Jonathan R. > > > > > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East Hanover, NJ > 07936 > > > > jdrosen@dynamicsoft.com FAX: (973) > 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) > 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > -----Original Message----- > > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > > Sent: Thursday, February 08, 2001 7:00 AM > > > > To: Gonzalo Camarillo > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > > > > > You are correct about using some other means of transport if > ISUP > > > > trans-shipment is all your network is doing. If the call > > destination (to a > > > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) > > varies on a per-call > > > > basis, however, using SIP to establish your call routing > > leads to using SIP > > > > to carry the ISUP. > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > Still I want to have full state in every SIP message. > > If the call is > > > > > addresed to the phone number 1234, I want to have a to > > field that says > > > > > 1234. I do not care if there is a leg routed thru the > > PSTN and another > > > > > thru SIP. > > > > > > > > > > Carrying full state is one of the beauties of SIP. If > > we begin using > > > > > INFO for this, it would be the same as using SAMs. > > Differen names, the > > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > > believe that > > > > > if the session has a destination, it should be present in the > > > > > to field. > > > > > > > > > > Again, if a proxy is providing services for this > > particular call, it > > > > > will want to see the called party number in order to trigger > > > > > the proper > > > > > service. This is a very good reason for updating the to field > > > > > every time > > > > > we have more digits. > > > > > > > > > > I like to use SIP between two gateways because it is possible > > > > > to provide > > > > > SIP services for a PSTN to PSTN call. If all we want to do is > > > > > finding a > > > > > egrees gateway, we would probably want to use other > > protocols (TRIP & > > > > > SIGTRAN for instance). > > > > > > > > > > Regards, > > > > > > > > > > Gonzalo > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > > statements is > > > > > > that an INVITE has reached a UAS which has accepted > > it. It follows > > > > > > that the UAS did not send back a 484, but rather an interim > > > > > response. > > > > > > IF more digits come along, the INFO method is there > > to carry them. > > > > > > They do not affect the SIP call state; they are used > > beyond the UAS, > > > > > > either in a PSTN call or in another SIP call as the > > case may be. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gonzalo Camarillo > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP context, once call > > > > > > > signalling > > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > > additional > > > > > > > > digits will not change call state. It is therefore > > > > > > > reasonable to use > > > > > > > > INFO to carry the additional digits. If we are talking > > > > > > > ISUP-SIP, once > > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > > reached, the same > > > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > > vanilla SIP UA. > > > > > > I > > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > > subsequent INFO > > > > > > > carrying more digits will be discarded. Thus, the > > PSTN to SIP > > > > > > gateway > > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > > Therefore, it is > > > > > > > better to begin directly using er-INVITEs rather than > INFO. > > > > > > > > > > > > > > Besides, I do not think that SIP is just a > > transport protocol that > > > > > > > carries ISUP messages between two gateways. For > > that, we have > > > > > > already > > > > > > > SIGTRAN. SIP might be used to provide services, > > even when the > > > > > > > call is a > > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST carry complete > > > > > > > > state. And a > > > > > > > SIP message with an incomplete to field does not > > carry complete > > > > > > state. > > > > > > > What if my SIP proxy provides a service for a > > PSTN-SIP-PSTN call > > > > > > based > > > > > > > on the to field (called party number). That proxy would > > > > > like to see > > > > > > an > > > > > > > updated to field, not just a to field that contains > > just some > > > > > > digits. > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Christer Holmberg > > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > > To: Gonzalo Camarillo > > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP > network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that > > is what has > > > > > > > > > been proposed > > > > > > > > > earlier in this thread, so I assumed INFO would > > be used. The > > > > > > > > > reason for > > > > > > > > > the discussion from the beginning was that the overlap > > > > > > > signalling, > > > > > > > > > according to the SIP-ISUP mapping draft, may not work > > > > > > > very well, and > > > > > > > > a > > > > > > > > > solution using 18x responses and INFO messages, > > instead of 484 > > > > > > and > > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has > > been pretty much > > > > > > > > > about calls > > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > > SIP UAS > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > | <- 200 (INFO) | > > -- INVITE > > > > > > > > > > > --> > > > > > > > > > > > | <- 200 (INVITE)| > > <- 200 ------ > > > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I > > am not using > > > > > > > > > the word 'proxy') > > > > > > > > > > > must collect digits, sent from the PSTN side using > > > > > > > > > > overlap dialing, to > > > > > > > > > > > be able to find the SIP UAS, and INFO is > > used to provide > > > > > > > > > the digits > > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > > if you like) > > > > > > > > > be allowed to > > > > > > > > > > > behave like this, or MUST it send 486s, and > > receive new > > > > > > > > > INVITEs, until > > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > FIN-02420 Jorvas Email : > > Gonzalo.Camarillo@ericsson.com > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : > > Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > --------------4B8A520F835A9E2D612744B5 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 --------------4B8A520F835A9E2D612744B5-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 17:12:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01500 for ; Thu, 15 Feb 2001 17:12:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 459A94435E; Thu, 15 Feb 2001 17:12:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 4E2D244337 for ; Thu, 15 Feb 2001 17:11:35 -0500 (EST) 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 f1FMBWC22906; Thu, 15 Feb 2001 23:11:33 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id AAA08121; Fri, 16 Feb 2001 00:11:31 +0200 (EET) Message-ID: <3A8C5416.5B75125B@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: hurtig@iex.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Cancel of Invite and affect (if any) on prack and reliable provisionalresponses References: <3A8C4F50.F0F6E7D2@mail.iex.com> Content-Type: multipart/mixed; boundary="------------53BE2D38955D3DA6093B5E3F" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 00:11:34 +0200 This is a multi-part message in MIME format. --------------53BE2D38955D3DA6093B5E3F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >Hi, > >I have a question related to what should the UAC and UAS do with >outstanding PRACK requests and reliable provisional responses when the >associated INVITE is canceled? > > UAC UAS > > INVITE --------------------------> > > <-------------------------- 100 provisional response > <-------------------------- 18x reliable provisional > response > > PRACK ------------> lost > > CANCEL --------------------------> > > >At this point the UAC is waiting the 200 OK for CANCEL and will >resend PRACK on time-out. UAS is awaiting PRACK for 18x and will resend 18x >on time-out. > >Should UAC abort the PRACK or let it continue? I see no reason why you would keep the PRACK alive, since you have canceled your setup request. The problem is that if you simply kill your transaction the UAS is going to re-transmit the 18x response until timeout. One answer would be to also CANCEL to PRACK, but that is related to the issue about if CANCEL is allowed for other requests than INVITE... Also, you have a similar case if you receive the final respones to your INVITE while you still have ongoing PRACK transactions. Why would you then want to keep the PRACK transactions alive, since you (the UAC) KNOWS you have received the provisional responses (otherwise you would never have started the PRACK transaction), and you already have received the final response? I think that CANCEL should be used here. Also (I have a number of issues on PRACK :), what should the UAS do, if it get triggered to send a final response to the INVITE it received, but it is still sending 18x provisional responses it hasn't received a PRACK for? Maybe this is more an implementation issue, but I wanted to point it out. >UAS must send the 200 OK for the CANCEL and should send a 487 >response for the INVITE. Should the UAS abort the timer associated with any >active 18x response? That is, stop waiting for the PRACK. This is also an issue. It is related to what I just wrote, but the difference is that now the UAS hasn't received a CANCEL, but it has still sent the final response to the INVITE. My personal opinion about PRACK is that it is a little weird to spend more resources to ack provisional responses, (PRACK request + response) than to ack the final response (only an ACK request), but I guess that is not related to your question, so... :) Regards, Christer Holmberg Ericsson Finland > > > > -- > Regards, > Doug Hurtig > > Tekelec > 2425 N. Central Expressway > Richardson, Texas 75080 > > hurtig@iex.com > 972.301.1203 > _______________________________________________ This list is for > continuing development of the SIP protocol. The sip-implementer's list > is the place to discuss implementation, and to receive advice on > understanding existing sip. To subscribe to it, send mail to > majordomo@cs.columbia.edu with "subscribe sip-implementors" in the > body. --------------53BE2D38955D3DA6093B5E3F 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 --------------53BE2D38955D3DA6093B5E3F-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 17:36:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01742 for ; Thu, 15 Feb 2001 17:36:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E5E7944337; Thu, 15 Feb 2001 17:36:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from iex.iex.com (iex.iex.com [192.153.124.1]) by lists.bell-labs.com (Postfix) with ESMTP id 55B2344336 for ; Thu, 15 Feb 2001 17:35:42 -0500 (EST) Received: from iexfw.iex.com ([192.153.124.100]) by iex.iex.com (8.9.1/8.9.3) with SMTP id QAA19500; Thu, 15 Feb 2001 16:35:41 -0600 (CST) Received: from mail.iex.com ([172.25.41.2]) by home.iex.com (8.9.3/8.9.3) with ESMTP id QAA05921; Thu, 15 Feb 2001 16:35:40 -0600 (CST) Message-ID: <3A8C5AE0.77C5C6F5@mail.iex.com> From: Doug Hurtig Reply-To: hurtig@iex.com Organization: IEX Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Christer Holmberg Cc: hurtig@iex.com, sip@lists.bell-labs.com Subject: Re: [SIP] Cancel of Invite and affect (if any) on prack and reliableprovisionalresponses References: <3A8C4F50.F0F6E7D2@mail.iex.com> <3A8C5416.5B75125B@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 16:40:32 -0600 Content-Transfer-Encoding: 7bit Christer, Thanks for the response. Christer Holmberg wrote: > Hi, > > >Hi, > > > >I have a question related to what should the UAC and UAS do with > >outstanding PRACK requests and reliable provisional responses when the > >associated INVITE is canceled? > > > > UAC UAS > > > > INVITE --------------------------> > > > > <-------------------------- 100 provisional response > > <-------------------------- 18x reliable provisional > > response > > > > PRACK ------------> lost > > > > CANCEL --------------------------> > > > > > >At this point the UAC is waiting the 200 OK for CANCEL and will > >resend PRACK on time-out. UAS is awaiting PRACK for 18x and will resend > 18x > >on time-out. > > > >Should UAC abort the PRACK or let it continue? > > I see no reason why you would keep the PRACK alive, since you have > canceled your setup request. The problem is that if you simply kill your > transaction the UAS is going to re-transmit the 18x response until > timeout. One answer would be to also CANCEL to PRACK, but that is > related to the issue about if CANCEL is allowed for other requests than > INVITE... I agree with you. However, the 100Rel draft states that CANCEL of PRACK is not valid. > > > Also, you have a similar case if you receive the final respones to your > INVITE while you still have ongoing PRACK transactions. Why would you > then want to keep the PRACK transactions alive, since you (the UAC) > KNOWS you have received the provisional responses (otherwise you would > never have started the PRACK transaction), and you already have received > the final response? I think that CANCEL should be used here. > You are correct in that it does not seem to be the best use of resources to keep the PRACK's going. However, since CANCEL is not allowed can I assume that server will stop 18x retransmission at this point? May need to allow PRACKs to complete. > > Also (I have a number of issues on PRACK :), what should the UAS do, if > it get triggered to send a final response to the INVITE it received, but > it is still sending 18x provisional responses it hasn't received a PRACK > for? Maybe this is more an implementation issue, but I wanted to point > it out. Given the way the 100rel draft is currently written I suspect that you need to allow the PRACKs to continue. The 100rel draft does recommend that the UAS not send the next provisional response until it the previous one is acknowledged. If this is the case, then you could drop unsent provisional responses at the UAS if it was determined that a final response was to be sent. This works if media is sent in first provisional response or in the final response. If however, media could be in one of the dropped provisional responses you could have a problem. > > > >UAS must send the 200 OK for the CANCEL and should send a 487 > >response for the INVITE. Should the UAS abort the timer associated with > any > >active 18x response? That is, stop waiting for the PRACK. > > This is also an issue. It is related to what I just wrote, but the > difference is that now the UAS hasn't received a CANCEL, but it has > still sent the final response to the INVITE. > > My personal opinion about PRACK is that it is a little weird to spend > more resources to ack provisional responses, (PRACK request + response) > than to ack the final response (only an ACK request), but I guess that > is not related to your question, so... :) > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > > -- > > Regards, > > Doug Hurtig > > > > Tekelec > > 2425 N. Central Expressway > > Richardson, Texas 75080 > > > > hurtig@iex.com > > 972.301.1203 > > _______________________________________________ This list is for > > continuing development of the SIP protocol. The sip-implementer's list > > is the place to discuss implementation, and to receive advice on > > understanding existing sip. To subscribe to it, send mail to > > majordomo@cs.columbia.edu with "subscribe sip-implementors" in the > > body. > (See attached file: christer.holmberg.vcf) > (See attached file: InterScan_Disclaimer.txt) > > -------------------------------------------------------------------------------- > Name: InterScan_Disclaimer.txt > InterScan_Disclaimer.txt Type: Plain Text (text/plain) > Encoding: base64 -- Regards, Doug Hurtig Tekelec 2425 N. Central Expressway Richardson, Texas 75080 hurtig@iex.com 972.301.1203 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 17:50:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01903 for ; Thu, 15 Feb 2001 17:50:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 038A04435E; Thu, 15 Feb 2001 17:50:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id BBFF644336 for ; Thu, 15 Feb 2001 17:49:07 -0500 (EST) 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 f1FMn5C07368 for ; Thu, 15 Feb 2001 23:49:06 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id AAA09323; Fri, 16 Feb 2001 00:49:03 +0200 (EET) Message-ID: <3A8C5CE2.78E70A61@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: gonzalo.camarillo@lmf.ericsson.se Content-Type: multipart/mixed; boundary="------------A1D19DBBB8E7BEE123E82D23" Subject: [SIP] Overlap dialing Part II: We reached the UAS Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 00:49:06 +0200 This is a multi-part message in MIME format. --------------A1D19DBBB8E7BEE123E82D23 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I started a separate thread on this, since I assume two things: 1. We only use INVITEs for the overlap dialing 2. The INVITE has reached the UAS, in this case a PSTN gateway. Ok, as long as the gateway UAS doesn't have enough digits to forward the call to the next entity it will send 484 responses. No problem there. But, when it does find the next PSTN entity, the following issues come up: 1. The gateway can not send a final response to the INVITE, since it doesn't know what it is, IF is is, going to receive from ISUP. The proxies on the path, and the UAC, will probably receive a 100 provisional responses, that will extend the re-transmission timer. However, these re-transmissions are not necessary, and they MAY even end up in another gateway, when we come back to the routing issue, and the issue of multiple IAMs. So, I would again like to raise the 186 issue. Ie, the UAS gateway could send a "186 Call Routed Forward" provisional response which, IF the proxies and the UAC supports it, would stop the re-transmission. Yes, there may have been a re-transmission before the 186 is received, but at least the chance of the problems above to occur is smaller. If the UAC also is a gateway, this provisional response would not trigger any ISUP message, it would simply be used for the SIP part of the gateway to stop the re-transmission. 2. The call is routed to the end PSTN user, and the gateway receives a an ISUP indication for that. Now, it generates a 200 OK for the previous INVITE. BUT, what final response does it send to all the other existing INVITE transactions, which arrived earlier, and did NOT trigger a 484 response since the gateway managed to route them to the next PSTN entity? I don't think 200 OK is a good idea, because it may mess things up at the UAC gateway (which has to map the "correct" 200 OK into an ISUP message), and it is also against the statement that 200 OK indicates that the call has been succesfully routed. Yes, in this case it HAS been, but only for one call-leg, ie for the latest INVITE. The closest I can think of is 484, but I don't know that is a good idea either. For example, what happens if one of the 484 reaches the UAC gateway before the 200 OK? The UAC gateway will realise it doesn't have more digits, so it will release the call - unless, of course, it is smart enough to know that it has sent a newer INVITE, with more digits. Again, like with the 186 provisional response, some kind of final response which will not be mapped into ISUP, or affect the call in any other way, would be good? A final response only to "get rid" of the INVITE transactions we don't care about anymore. In Dallas, a 202 response was proposed for another case, and maybe that could be here too? A response that simply says: "Ok, your INVITE was fine, but we don't need it anymore. So, please terminate it but don't make a big noise about it". Regards, Christer Holmberg Ericsson Finland --------------A1D19DBBB8E7BEE123E82D23 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 --------------A1D19DBBB8E7BEE123E82D23-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 17:57:32 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02028 for ; Thu, 15 Feb 2001 17:57:32 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4578044376; Thu, 15 Feb 2001 17:52:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 664F14436A for ; Thu, 15 Feb 2001 17:51:45 -0500 (EST) 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 f1FMphC08412; Thu, 15 Feb 2001 23:51:44 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id AAA09472; Fri, 16 Feb 2001 00:51:41 +0200 (EET) Message-ID: <3A8C5D80.E8D9DC87@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: hurtig@iex.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Cancel of Invite and affect (if any) on prack and reliableprovisionalresponses References: <3A8C4F50.F0F6E7D2@mail.iex.com> <3A8C5416.5B75125B@lmf.ericsson.se> <3A8C5AE0.77C5C6F5@mail.iex.com> Content-Type: multipart/mixed; boundary="------------896366723557A1C7D1BF76BF" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 00:51:44 +0200 This is a multi-part message in MIME format. --------------896366723557A1C7D1BF76BF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >Christer, > > Thanks for the response. No problemo :) Please let us know if you have a good solution for this, or a proposal how you think it should be solved. Regards, Christer Holmberg Ericsson Finland > > Christer Holmberg wrote: > > > Hi, > > > > >Hi, > > > > > >I have a question related to what should the UAC and UAS do with > > >outstanding PRACK requests and reliable provisional responses when the > > >associated INVITE is canceled? > > > > > > UAC UAS > > > > > > INVITE --------------------------> > > > > > > <-------------------------- 100 provisional response > > > <-------------------------- 18x reliable provisional > > > response > > > > > > PRACK ------------> lost > > > > > > CANCEL --------------------------> > > > > > > > > >At this point the UAC is waiting the 200 OK for CANCEL and will > > >resend PRACK on time-out. UAS is awaiting PRACK for 18x and will resend > > 18x > > >on time-out. > > > > > >Should UAC abort the PRACK or let it continue? > > > > I see no reason why you would keep the PRACK alive, since you have > > canceled your setup request. The problem is that if you simply kill your > > transaction the UAS is going to re-transmit the 18x response until > > timeout. One answer would be to also CANCEL to PRACK, but that is > > related to the issue about if CANCEL is allowed for other requests than > > INVITE... > > I agree with you. However, the 100Rel draft states that CANCEL of > PRACK is not valid. > > > > > > > Also, you have a similar case if you receive the final respones to your > > INVITE while you still have ongoing PRACK transactions. Why would you > > then want to keep the PRACK transactions alive, since you (the UAC) > > KNOWS you have received the provisional responses (otherwise you would > > never have started the PRACK transaction), and you already have received > > the final response? I think that CANCEL should be used here. > > > > You are correct in that it does not seem to be the best use of resources to keep > the PRACK's going. However, since CANCEL is not allowed can I assume that > server will stop 18x retransmission at this point? May need to allow PRACKs to > complete. > > > > > Also (I have a number of issues on PRACK :), what should the UAS do, if > > it get triggered to send a final response to the INVITE it received, but > > it is still sending 18x provisional responses it hasn't received a PRACK > > for? Maybe this is more an implementation issue, but I wanted to point > > it out. > > Given the way the 100rel draft is currently written I suspect that you > need to allow the PRACKs to continue. > > The 100rel draft does recommend that the UAS not send the next provisional > response until it the previous one is acknowledged. If this is the case, then > you could drop unsent provisional responses at the UAS if it was determined > that a final response was to be sent. This works if media is sent in first > provisional response or in the final response. If however, media could be > in one of the dropped provisional responses you could have a problem. > > > > > > > >UAS must send the 200 OK for the CANCEL and should send a 487 > > >response for the INVITE. Should the UAS abort the timer associated with > > any > > >active 18x response? That is, stop waiting for the PRACK. > > > > This is also an issue. It is related to what I just wrote, but the > > difference is that now the UAS hasn't received a CANCEL, but it has > > still sent the final response to the INVITE. > > > > My personal opinion about PRACK is that it is a little weird to spend > > more resources to ack provisional responses, (PRACK request + response) > > than to ack the final response (only an ACK request), but I guess that > > is not related to your question, so... :) > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > > > -- > > > Regards, > > > Doug Hurtig > > > > > > Tekelec > > > 2425 N. Central Expressway > > > Richardson, Texas 75080 > > > > > > hurtig@iex.com > > > 972.301.1203 > > > _______________________________________________ This list is for > > > continuing development of the SIP protocol. The sip-implementer's list > > > is the place to discuss implementation, and to receive advice on > > > understanding existing sip. To subscribe to it, send mail to > > > majordomo@cs.columbia.edu with "subscribe sip-implementors" in the > > > body. > > (See attached file: christer.holmberg.vcf) > > (See attached file: InterScan_Disclaimer.txt) > > > > -------------------------------------------------------------------------------- > > Name: InterScan_Disclaimer.txt > > InterScan_Disclaimer.txt Type: Plain Text (text/plain) > > Encoding: base64 > > -- > Regards, > Doug Hurtig > > Tekelec > 2425 N. Central Expressway > Richardson, Texas 75080 > > hurtig@iex.com > 972.301.1203 --------------896366723557A1C7D1BF76BF 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 --------------896366723557A1C7D1BF76BF-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 18:48:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02390 for ; Thu, 15 Feb 2001 18:48:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E92DA44380; Thu, 15 Feb 2001 18:48:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 788B744337 for ; Thu, 15 Feb 2001 18:47:32 -0500 (EST) 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 f1FNlVC29625 for ; Fri, 16 Feb 2001 00:47:31 +0100 (MET) Received: from lmf.ericsson.se (racom107045.am.ericsson.se [147.117.107.45]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id AAA19336; Fri, 16 Feb 2001 00:47:27 +0100 (MET) Message-ID: <3A8C68EC.F9B8B30E@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: sip@lists.bell-labs.com References: <3A8C5CE2.78E70A61@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: Overlap dialing Part II: We reached the UAS Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 01:40:28 +0200 Content-Transfer-Encoding: 7bit Hi, 186 is not needed because we have already 183 means session progress. Since the gateway knows that the last INVITE was successful, it can safely answer 484 to all the previous transactions. No new response code needed. Regards, Gonzalo Christer Holmberg wrote: > > Hi, > > I started a separate thread on this, since I assume two things: > > 1. We only use INVITEs for the overlap dialing > > 2. The INVITE has reached the UAS, in this case a PSTN gateway. > > Ok, as long as the gateway UAS doesn't have enough digits to forward the > call to the next entity it will send 484 responses. No problem there. > > But, when it does find the next PSTN entity, the following issues come > up: > > 1. The gateway can not send a final response to the INVITE, since it > doesn't know what it is, IF is is, going to receive from ISUP. The > proxies on the path, and the UAC, will probably receive a 100 > provisional responses, that will extend the re-transmission timer. > However, these re-transmissions are not necessary, and they MAY even end > up in another gateway, when we come back to the routing issue, and the > issue of multiple IAMs. > > So, I would again like to raise the 186 issue. Ie, the UAS gateway could > send a "186 Call Routed Forward" provisional response which, IF the > proxies and the UAC supports it, would stop the re-transmission. Yes, > there may have been a re-transmission before the 186 is received, but at > least the chance of the problems above to occur is smaller. If the UAC > also is a gateway, this provisional response would not trigger any ISUP > message, it would simply be used for the SIP part of the gateway to stop > the re-transmission. > > 2. The call is routed to the end PSTN user, and the gateway receives a > an ISUP indication for that. Now, it generates a 200 OK for the previous > INVITE. BUT, what final response does it send to all the other existing > INVITE transactions, which arrived earlier, and did NOT trigger a 484 > response since the gateway managed to route them to the next PSTN > entity? I don't think 200 OK is a good idea, because it may mess things > up at the UAC gateway (which has to map the "correct" 200 OK into an > ISUP message), and it is also against the statement that 200 OK > indicates that the call has been succesfully routed. Yes, in this case > it HAS been, but only for one call-leg, ie for the latest INVITE. The > closest I can think of is 484, but I don't know that is a good idea > either. > > For example, what happens if one of the 484 reaches the UAC gateway > before the 200 OK? The UAC gateway will realise it doesn't have more > digits, so it will release the call - unless, of course, it is smart > enough to know that it has sent a newer INVITE, with more digits. Again, > like with the 186 provisional response, some kind of final response > which will not be mapped into ISUP, or affect the call in any other way, > would be good? A final response only to "get rid" of the INVITE > transactions we don't care about anymore. > > In Dallas, a 202 response was proposed for another case, and maybe that > could be here too? A response that simply says: "Ok, your INVITE was > fine, but we don't need it anymore. So, please terminate it but don't > make a big noise about it". > > Regards, > > Christer Holmberg > Ericsson Finland -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Thu Feb 15 20:54:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04019 for ; Thu, 15 Feb 2001 20:54:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E10C44337; Thu, 15 Feb 2001 20:54:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 88BD444336 for ; Thu, 15 Feb 2001 20:53:49 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id IAA12950 for ; Fri, 16 Feb 2001 08:00:38 -0600 Message-ID: <00a301c097ba$c3c2f920$bc036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Slides and Notes from Interim Meeting Posted Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 15 Feb 2001 19:49:52 -0600 Content-Transfer-Encoding: 7bit Material on the recent Interim Meeting of the SIP WG can be retrieved from: http://www.softarmor.com/sipwg/meets/interim-feb-01/index.html -- Dean _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 05:41:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25916 for ; Fri, 16 Feb 2001 05:41:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 978CA44337; Fri, 16 Feb 2001 05:41:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id 2D52644336 for ; Fri, 16 Feb 2001 05:39:53 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Fri, 16 Feb 2001 10:33:49 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <102C95YF>; Fri, 16 Feb 2001 10:33:47 -0000 Message-ID: From: "Mark Watson" To: "'Christer Holmberg'" , "Mark Watson" Cc: "'Gonzalo Camarillo'" , Keith Robinson , Jonathan Rosenberg , "Tom-PT Taylor" , sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09803.EEECBCF0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 10:33:42 -0000 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_01C09803.EEECBCF0 Content-Type: text/plain; charset="iso-8859-1" Christer, I think this is being made a lot more complicated than necessary. By negotiation, I just meant that when the call reached a UAS which supported INFOs, it would return an indication (e.g. 186)that the UAC could switch to using INFOs. Until the call reached the UAS (i.e. PSTN Gateway), then INFOs would not be used - you would just have INVITE/484 exchanges until you had enough digits to reach the UAS. For proxies which need to see all the digits, they can still operate in INVITE/484 mode until they have enough digits to route - the proxy would not trigger the UAC to send INFOs, but if a downstream UAS *did*, the proxy could examine subsequent INFOs which come past in order to update its record of the destination number. Regards...Mark > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: 15 February 2001 21:42 > To: Watson, Mark [MAIFP:EP11-M:EXCH] > Cc: 'Gonzalo Camarillo'; Keith Robinson; Jonathan Rosenberg; Taylor, > Tom-PT [NORSE:B901:EXCH]; sip@lists.bell-labs.com > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > Hi, > > Again, I am Gonzalo, but I will also comment... :) > > Mark Watson wrote: > > > >Gonzalo, > > > >I don't understand your comment about the INFO Overlap proposals > >causing problems for 'vanilla' SIP UAs. My suggestion was > that the use > >of INFOs for overlap digits be negotiated between UAC and UAS. > > My personal opinion is that, even if this overlap dialing thing seems > like a very difficult problem to solve, the functionality itself is > pretty minor, so I don't think that a UA should have to > negotiate about > the method to use for this... Also, I don't think your negotiation > proposal would work. You should remember that you have to > reach the UAS > before you can do this negotiation in the first place, which means you > may have to send a number of INVITEs, and receive 484 responses from > proxies. And, even when you reach the UAS (let's assume it's a PSTN > gateway), it may be able to forward the digits, so the only answer you > are going to get is 100 - which you will get from the first proxy, so > the UAS can't include the negotiation result there. > > This response-from-the-UAS thing is, however, related to another issue > which I will describe in another mail. > > >So, the UAC would include a 'Supported' tag if it could do overlap > >INFOs and the mechanism would then only be used if both ends > supported > >it. Otherwise you would just kill session requests without enough > >digits with 484s. > > See my comment above why I don't this would work very well. > > >Regarding Application Servers, the INFOs should certainly contain all > >the digits so far (otherwise we get the problems with lost messages). > >I do not believe any proxies exist which are being used today in > >overlap situations and which need access to the whole called number, > >so we can add this capability to the specification without > hurting any > >existing implementations. > > Well, well, well... Let's assume it's a proxy that sends the 484 > response. Then, if you want to start using INFO, this proxy must > remember the INVITE, and collect the INFOs. Then, when the proxy has > enough digits, what shall it do then? Create an INVITE of > it's own? What > will then happen when the UAC receive the response for an INVITE it > never created? Also, when the proxy sends the INVITE, it may > receive 484 > responses from the NEXT proxy in the network, asking for more digits. > Ie, your proxy would have to both collect digits from the UAC, and > handle the next entity (in this example, another proxy) in the SIP > nework. All this would DEFINITELY hurt existing > implementations, so you > would also have to negotiate with the proxies if they are able to do > this... > > In this case I think Keith's proposal, ie that the proxy is > smart enough > to see that the only thing that has changed in the new INVITE is the > receiver digits, is MUCH easier to implement :) > > >Finally, there are many reasons other than simple load balancing why > >one INVITE might be routed differently to a subsequent, apparently > >identical, one. e.g. Time of day routing - which is certainly not > >'random'. Stateful proxies may also remember where they sent the > >INVITE so that subsequent requests on the same call leg can be routed > >the same way. > > I agree, routing is a problem, but there has been proposals > to solve it, > ie the one Keith gave. Also, I think that routing, and forking, is the > reason for a number of SIP related problems, so I think it is > better to > find a generic solution to that. Allowing ROUTE headers in specific > situations (again, see Keith's proposal) in initial requests > is partly a > solution. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > Regards, > > > > Mark Watson > > Nortel Networks > > > > > -----Original Message----- > > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > Sent: 14 February 2001 14:31 > > > To: Keith Robinson > > > Cc: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B901:EXCH]; Christer > > > Holmberg; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > Hello Keith, > > > > > > Keith Robinson wrote: > > > > > > > > Gonzalo, > > > > > > > > It seems you have two main reasons against the use of the > > INFO > > > > method for the conveyance of subsequent ISUP information: > > > > > > > > 1) Lack of ordered delivery of the INFO messages > > > > > > > > Ordered delivery could be maintained by the UAC not sending > > > the next INFO > > > > until a 200 OK response for the previous one had been received. > > > > > > > > 2) Lack of state carried in the INFO messge > > > > > > > > The digits received so far could be carried in a header > within the > > > > > > INFO message. Each INFO message would then carry the same > > > information > > > > as a re-INVITE. > > > > > > > > > > Actually my main reason against the use of INFO is that it > > > does not work > > > with vanilla SIP UAs and vanilla SIP Application Servers. How you > > > resolve the technical issues related to INFO does not > really matter > > to > > > me. It is not "vanilla" SIP, and I am against this kind of > > > non-standard > > > mechanisms. > > > > > > > > > > My reason for exploring the use of INFO is not to save on > > > messages. It is > > > > to do with the issue of source routing. Again, my concern of > > source > > > > routing is not one of a technical nature. What if an > > > administration has a > > > > security policy that states source routing (a ROUTE header in > > > > an initial INVITE) will not take place in its SIP network > > > but it also requires > > > > that > > > > the same network interworks with the PSTN; if any part of > > > the PSTN interworking > > > > mechanism > > > > relies on source routing then there is a conflict of > > > requirements. It is this > > > > conflict > > > > I wish to address. > > > > > > > > > > OK, let's address this. Source routing is proposed in the draft to > > > address load balancing. This is, a proxy that sends INVITEs > > > to different > > > egrees gateways. > > > > > > So, if an IAM and one SAM are received, the second INVITE > might end > > up > > > in another gateway than the fist INVITE. This would trigger 2 IAMs > > > instead of 1 IAM and 1 SAM. > > > > > > OK, this is the problem that has to be solved. What I > wanted to say > > in > > > the draft (I did not have lot of time and it has to be rephrased), > > was > > > the following: > > > > > > It is strongly RECOMMENDED that proxies route requests that are > > > basically identical and just differ in the to field (more > > > digits) in the > > > same way. So, if such as proxy performs load balancing, all the > > > subsequent INVITEs will reach the same egrees gateway. > > > > > > This is not difficult to do, because most likely a call to > > > +1234 has to > > > be routed in the same way as a call to +12345. So, the only real > > > requirement in that proxies do not make routing decisions based on > > > random variables (such as internal clocks). > > > > > > Then, just in case folks did not feel comfortable with > this solution > > > > > (which I believe is the good one), I outlined the source routing > > > solution. > > > > > > And what about load balancing? You can still have load balancing. > > Your > > > proxy makes the routing decision based on to, from, and what > > > ever fields > > > it wants. Then, it can calculate a digest of some fields, > and make a > > > > > "random" routing decision based on that hash. This provides load > > > balancing but still routes INVITEs carrying SAMs in the > proper way. > > > > > > Does this resolve your issue? > > > > > > Best regards, > > > > > > Gonzalo > > > > > > > > > > > > > Regards, > > > > > > > > K. Robinson. > > > > > > > > Gonzalo Camarillo on > > > 01/01/88 00:39:14 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Jonathan Rosenberg > > > > > > > > cc: "'Tom-PT Taylor'" , > > > > Christer Holmberg > > > > , > > > > sip@lists.bell-labs.com(bcc: Keith > > > > Robinson/MAIN/MC1) > > > > > > > > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hello, > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > I think the correct answer about which approach to use > > > (INFO vs. multiple > > > > > call legs) depends on your view of the scope of the > > > address within the sip > > > > > cloud. If you believe that the sip role has ended once > > > you have enough > > > > > digits to select an egress gateway (which may be as few > > > as one, i.e., +1 > > > > > selects a US gateway), then the sip address of that > > > gateway can be viewed as > > > > > sip:+1@provider.com, and all subsequent digits are PSTN > > > issues, outside the > > > > > scope of SIP. > > > > > > > > I definitively agree that this is the view that INFO fans > > > have of a SIP > > > > cloud. What I am saying is that this view is wrong. This > > > usage of SIP > > > > falls outside the scope of SIP. > > > > If they want to use SIP for locating a gateway, it is > > > fine. But after > > > > the gateway has been located, let's use another method for > > > transporting > > > > ISUP signalling. > > > > > > > > Let's assume that I get an IAM with "+1", as Jonathan > says in his > > > > example. Then the INVITE generated by the gateway will reach the > > US > > > > gateway. Now, the mission of SIP has finished, since the gateway > > has > > > > been located. Why don't we put in the body of this INVITE a > > session > > > > description that comprises a media session and a SIGTRAN > > > session? This > > > > way we would have established these two sessions between > > > the gateways > > > > and all the subsequent ISUP messages would be sent over the > > SIGTRAN > > > > session. > > > > > > > > I find that the usage of SIP that I have just described would be > > OK. > > > > What I do not understand is why folks want to use SIP for > > > transporting > > > > subsequent ISUP messages. SIP does not have good transport > > > properties > > > > (big overhead, it can run over UDP...). Besides, it does not > > provide > > > > ordered delivery. > > > > > > > > If the INVITE has Cseq=1 and the next message that the > > > egrees gateway > > > > receives is a INFO with Cseq=7... what should the gateway do? > > Maybe > > > > there were several proxies in the middle asking for > > > credentials for the > > > > INFO, so the ingrees gateway had to add authentication > > > stuff and resend > > > > the INFO. If this was the case, the SAM contained in the > > > INFO would be > > > > the second digit of the called party number... However, maybe 5 > > INFO > > > > messages got lost, and the SAM that we have received in the > > > body of the > > > > INFO makes no sense without the previous ones because is > > > the 7th digit > > > > of the number... > > > > > > > > This is not usually a problem in SIP, since all > messages have full > > > > > > state. However, using INFO for sending SAMs breaks this > rule, and > > > > therefore it breaks the SIP model. > > > > > > > > I believe that considering that the session is established after > > the > > > > first INVITE and sending the following SAMs using INFO is > > > making one of > > > > the mistakes described in the guidelines for SIP authors: > > > "We need to > > > > transport ISUP signalling over IP between two gateways. > > > Both gateways > > > > already implement SIP... why do we have to implement > > > another protocol? > > > > Let's use SIP to transport ISUP signalling". We are just > > > trying to use > > > > SIP for this just because it would save implementing yet another > > > > protocol in the gateways. > > > > > > > > I strongly disagree with this usage of SIP. SIP-T is good > > > as long as the > > > > SIP cloud provides services. If not, SIP-T is not a good > > > protocol for > > > > transporting ISUP signalling. > > > > > > > > Best regards, > > > > > > > > Gonzalo > > > > > > > > If you believe that the sip role encompasses functions that > > > > > might apply to the PSTN subscribers, then you need to > > > have the entire > > > > > number, and the multiple call leg approach is the right way to > > go. > > > > > > > > > > The multiple call leg approach is clearly ugly and > > > inelegant, but it has the > > > > > nice property of completely masking the existence of > > > overlap from proxies > > > > > and app servers within the network, allowing them to > > > provide services in the > > > > > normal way. > > > > > > > > > > -Jonathan R. > > > > > > > > > > --- > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > Chief Scientist First Floor > > > > > dynamicsoft East Hanover, NJ > > 07936 > > > > > jdrosen@dynamicsoft.com FAX: (973) > > 952-5050 > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) > > 952-5000 > > > > > http://www.dynamicsoft.com > > > > > > > > > > -----Original Message----- > > > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > > > Sent: Thursday, February 08, 2001 7:00 AM > > > > > To: Gonzalo Camarillo > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > > > > > > > You are correct about using some other means of transport if > > ISUP > > > > > trans-shipment is all your network is doing. If the call > > > destination (to a > > > > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) > > > varies on a per-call > > > > > basis, however, using SIP to establish your call routing > > > leads to using SIP > > > > > to carry the ISUP. > > > > > > -----Original Message----- > > > > > > From: Gonzalo Camarillo > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > Still I want to have full state in every SIP message. > > > If the call is > > > > > > addresed to the phone number 1234, I want to have a to > > > field that says > > > > > > 1234. I do not care if there is a leg routed thru the > > > PSTN and another > > > > > > thru SIP. > > > > > > > > > > > > Carrying full state is one of the beauties of SIP. If > > > we begin using > > > > > > INFO for this, it would be the same as using SAMs. > > > Differen names, the > > > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > > > believe that > > > > > > if the session has a destination, it should be > present in the > > > > > > to field. > > > > > > > > > > > > Again, if a proxy is providing services for this > > > particular call, it > > > > > > will want to see the called party number in order to trigger > > > > > > the proper > > > > > > service. This is a very good reason for updating > the to field > > > > > > every time > > > > > > we have more digits. > > > > > > > > > > > > I like to use SIP between two gateways because it > is possible > > > > > > to provide > > > > > > SIP services for a PSTN to PSTN call. If all we > want to do is > > > > > > finding a > > > > > > egrees gateway, we would probably want to use other > > > protocols (TRIP & > > > > > > SIGTRAN for instance). > > > > > > > > > > > > Regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > > > statements is > > > > > > > that an INVITE has reached a UAS which has accepted > > > it. It follows > > > > > > > that the UAS did not send back a 484, but rather > an interim > > > > > > response. > > > > > > > IF more digits come along, the INFO method is there > > > to carry them. > > > > > > > They do not affect the SIP call state; they are used > > > beyond the UAS, > > > > > > > either in a PSTN call or in another SIP call as the > > > case may be. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Gonzalo Camarillo > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP > context, once call > > > > > > > > > signalling > > > > > > > > > has reached an egress gateway, SIP has done its job -- > > > > > > additional > > > > > > > > > digits will not change call state. It is therefore > > > > > > > > reasonable to use > > > > > > > > > INFO to carry the additional digits. If we > are talking > > > > > > > > ISUP-SIP, once > > > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > > > reached, the same > > > > > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > > > vanilla SIP UA. > > > > > > > I > > > > > > > > will return a Not Found or a 484 Address incomplete. The > > > > > > > > subsequent INFO > > > > > > > > carrying more digits will be discarded. Thus, the > > > PSTN to SIP > > > > > > > gateway > > > > > > > > will have to re issue a new INVITE with all the digits. > > > > > > > > Therefore, it is > > > > > > > > better to begin directly using er-INVITEs rather than > > INFO. > > > > > > > > > > > > > > > > Besides, I do not think that SIP is just a > > > transport protocol that > > > > > > > > carries ISUP messages between two gateways. For > > > that, we have > > > > > > > already > > > > > > > > SIGTRAN. SIP might be used to provide services, > > > even when the > > > > > > > > call is a > > > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST > carry complete > > > > > > > > > > state. And a > > > > > > > > SIP message with an incomplete to field does not > > > carry complete > > > > > > > state. > > > > > > > > What if my SIP proxy provides a service for a > > > PSTN-SIP-PSTN call > > > > > > > based > > > > > > > > on the to field (called party number). That proxy would > > > > > > like to see > > > > > > > an > > > > > > > > updated to field, not just a to field that contains > > > just some > > > > > > > digits. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Christer Holmberg > > > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > > > To: Gonzalo Camarillo > > > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP > > network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that > > > is what has > > > > > > > > > > been proposed > > > > > > > > > > earlier in this thread, so I assumed INFO would > > > be used. The > > > > > > > > > > reason for > > > > > > > > > > the discussion from the beginning was that > the overlap > > > > > > > > > signalling, > > > > > > > > > > according to the SIP-ISUP mapping draft, > may not work > > > > > > > > very well, and > > > > > > > > > a > > > > > > > > > > solution using 18x responses and INFO messages, > > > instead of 484 > > > > > > > and > > > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, overlap > > > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has > > > been pretty much > > > > > > > > > > about calls > > > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > > > SIP UAS > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > > | <- 200 (INFO) | > > > -- INVITE > > > > > > > > > > > > --> > > > > > > > > > > > > | <- 200 (INVITE)| > > > <- 200 ------ > > > > > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I > > > am not using > > > > > > > > > > the word 'proxy') > > > > > > > > > > > > must collect digits, sent from the PSTN > side using > > > > > > > > > > > > overlap dialing, to > > > > > > > > > > > > be able to find the SIP UAS, and INFO is > > > used to provide > > > > > > > > > > the digits > > > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > > > if you like) > > > > > > > > > > be allowed to > > > > > > > > > > > > behave like this, or MUST it send 486s, and > > > receive new > > > > > > > > > > INVITEs, until > > > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Gonzalo Camarillo Phone : +358 > 9 299 33 71 > > > > > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 > 40 702 35 35 > > > > > > > > > > > > > Telecom R&D Fax : +358 > 9 299 30 52 > > > > > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > > > Finland > http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > FIN-02420 Jorvas Email : > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : > > > Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > FIN-02420 Jorvas Email : > Gonzalo.Camarillo@ericsson.com > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > _______________________________________________ > > > > This list is for continuing development of the SIP protocol. > > > > The sip-implementer's list is the place to discuss > implementation, > > > > > > and to receive advice on understanding existing sip. > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > > "subscribe sip-implementors" in the body. > > > > > > -- > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > Columbia University Mobile: +358 40 702 35 35 > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > New York, NY 10027 > > > USA Gonzalo.Camarillo@ericsson.com > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > > > ------_=_NextPart_001_01C09803.EEECBCF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Operlap dialing within a SIP network

Christer,

I think this is being made a lot more complicated = than necessary.

By negotiation, I just meant that when the call = reached a UAS which supported INFOs, it would return an indication = (e.g. 186)that the UAC could switch to using INFOs. Until the call = reached the UAS (i.e. PSTN Gateway), then INFOs would not be used - you = would just have INVITE/484 exchanges until you had enough digits to = reach the UAS.

For proxies which need to see all the digits, they = can still operate in INVITE/484 mode until they have enough digits to = route - the proxy would not trigger the UAC to send INFOs, but if a = downstream UAS *did*, the proxy could examine subsequent INFOs which = come past in order to update its record of the destination = number.

Regards...Mark



> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: 15 February 2001 21:42
> To: Watson, Mark [MAIFP:EP11-M:EXCH]
> Cc: 'Gonzalo Camarillo'; Keith Robinson; = Jonathan Rosenberg; Taylor,
> Tom-PT [NORSE:B901:EXCH]; = sip@lists.bell-labs.com
> Subject: Re: [SIP] Operlap dialing within a SIP = network
>
>
>
> Hi,
>
> Again, I am Gonzalo, but I will also comment... = :)
>
> Mark Watson wrote:
> >
> >Gonzalo,
> >
> >I don't understand your comment about the = INFO Overlap proposals
> >causing problems for 'vanilla' SIP UAs. My = suggestion was
> that the use
> >of INFOs for overlap digits be negotiated = between UAC and UAS.
>
> My personal opinion is that, even if this = overlap dialing thing seems
> like a very difficult problem to solve, the = functionality itself is
> pretty minor, so I don't think that a UA should = have to
> negotiate about
> the method to use for this... Also, I don't = think your negotiation
> proposal would work. You should remember that = you have to
> reach the UAS
> before you can do this negotiation in the first = place, which means you
> may have to send a number of INVITEs, and = receive 484 responses from
> proxies. And, even when you reach the UAS = (let's assume it's a PSTN
> gateway), it may be able to forward the digits, = so the only answer you
> are going to get is 100 - which you will get = from the first proxy, so
> the UAS can't include the negotiation result = there.
>
> This response-from-the-UAS thing is, however, = related to another issue
> which I will describe in another mail.
> 
> >So, the UAC would include a 'Supported' tag = if it could do overlap
> >INFOs and the mechanism would then only be = used if both ends
> supported
> >it. Otherwise you would just kill session = requests without enough
> >digits with 484s.
>
> See my comment above why I don't this would = work very well.
> 
> >Regarding Application Servers, the INFOs = should certainly contain all
> >the digits so far (otherwise we get the = problems with lost messages).
> >I do not believe any proxies exist which = are being used today in
> >overlap situations and which need access to = the whole called number,
> >so we can add this capability to the = specification without
> hurting any
> >existing implementations.
>
> Well, well, well... Let's assume it's a proxy = that sends the 484
> response. Then, if you want to start using = INFO, this proxy must
> remember the INVITE, and collect the INFOs. = Then, when the proxy has
> enough digits, what shall it do then? Create an = INVITE of
> it's own? What
> will then happen when the UAC receive the = response for an INVITE it
> never created? Also, when the proxy sends the = INVITE, it may
> receive 484
> responses from the NEXT proxy in the network, = asking for more digits.
> Ie, your proxy would have to both collect = digits from the UAC, and
> handle the next entity (in this example, = another proxy) in the SIP
> nework. All this would DEFINITELY hurt existing =
> implementations, so you
> would also have to negotiate with the proxies = if they are able to do
> this...
>
> In this case I think Keith's proposal, ie that = the proxy is
> smart enough
> to see that the only thing that has changed in = the new INVITE is the
> receiver digits, is MUCH easier to implement = :)
> 
> >Finally, there are many reasons other than = simple load balancing why
> >one INVITE might be routed differently to a = subsequent, apparently
> >identical, one. e.g. Time of day routing - = which is certainly not
> >'random'. Stateful proxies may also = remember where they sent the
> >INVITE so that subsequent requests on the = same call leg can be routed
> >the same way.
>
> I agree, routing is a problem, but there has = been proposals
> to solve it,
> ie the one Keith gave. Also, I think that = routing, and forking, is the
> reason for a number of SIP related problems, so = I think it is
> better to
> find a generic solution to that. Allowing ROUTE = headers in specific
> situations (again, see Keith's proposal) in = initial requests
> is partly a
> solution.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
>
>
> >
> > Regards,
> >
> > Mark Watson
> > Nortel Networks
> >
> > > -----Original Message-----
> > > From: Gonzalo Camarillo [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > Sent: 14 February 2001 14:31
> > > To: Keith Robinson
> > > Cc: Jonathan Rosenberg; Taylor, = Tom-PT [NORSE:B901:EXCH]; Christer
> > > Holmberg; = sip@lists.bell-labs.com
> > > Subject: Re: [SIP] Operlap dialing = within a SIP network
> > >
> > >
> > > Hello Keith,
> > >
> > > Keith Robinson wrote:
> > > >
> > > > Gonzalo,
> > > >
> > > >      It = seems you have two main reasons against the use of the
> > INFO
> > > > method for the conveyance of = subsequent ISUP information:
> > > >
> > > > 1) Lack of ordered delivery of = the INFO messages
> > > >
> > > > Ordered delivery could be = maintained by the UAC not sending
> > > the next INFO
> > > > until a 200 OK response for the = previous one had been received.
> > > >
> > > > 2) Lack of state carried in the = INFO messge
> > > >
> > > > The digits received so far could = be carried in a header
> within the
> >
> > > > INFO message. Each INFO message = would then carry the same
> > > information
> > > > as a re-INVITE.
> > > >
> > >
> > > Actually my main reason against the = use of INFO is that it
> > > does not work
> > > with vanilla SIP UAs and vanilla SIP = Application Servers. How you
> > > resolve the technical issues related = to INFO does not
> really matter
> > to
> > > me. It is not "vanilla" = SIP, and I am against this kind of
> > > non-standard
> > > mechanisms.
> > >
> > >
> > > > My reason for exploring the use = of INFO is not to save on
> > > messages. It is
> > > > to do with the issue of source = routing. Again, my concern of
> > source
> > > > routing is not one of a = technical nature. What if an
> > > administration has a
> > > > security policy that states = source routing (a ROUTE header in
> > > > an initial INVITE) will not take = place in its SIP network
> > > but it also requires
> > > > that
> > > > the same network interworks with = the PSTN; if any part of
> > > the PSTN interworking
> > > > mechanism
> > > > relies on source routing then = there is a conflict of
> > > requirements. It is this
> > > > conflict
> > > > I wish to address.
> > > >
> > >
> > > OK, let's address this. Source = routing is proposed in the draft to
> > > address load balancing. This is, a = proxy that sends INVITEs
> > > to different
> > > egrees gateways.
> > >
> > > So, if an IAM and one SAM are = received, the second INVITE
> might end
> > up
> > > in another gateway than the fist = INVITE. This would trigger 2 IAMs
> > > instead of 1 IAM and 1 SAM.
> > >
> > > OK, this is the problem that has to = be solved. What I
> wanted to say
> > in
> > > the draft (I did not have lot of time = and it has to be rephrased),
> > was
> > > the following:
> > >
> > > It is strongly RECOMMENDED that = proxies route requests that are
> > > basically identical and just differ = in the to field (more
> > > digits) in the
> > > same way. So, if such as proxy = performs load balancing, all the
> > > subsequent INVITEs will reach the = same egrees gateway.
> > >
> > > This is not difficult to do, because = most likely a call to
> > > +1234 has to
> > > be routed in the same way as a call = to +12345. So, the only real
> > > requirement in that proxies do not = make routing decisions based on
> > > random variables (such as internal = clocks).
> > >
> > > Then, just in case folks did not feel = comfortable with
> this solution
> >
> > > (which I believe is the good one), I = outlined the source routing
> > > solution.
> > >
> > > And what about load balancing? You = can still have load balancing.
> > Your
> > > proxy makes the routing decision = based on to, from, and what
> > > ever fields
> > > it wants. Then, it can calculate a = digest of some fields,
> and make a
> >
> > > "random" routing decision = based on that hash. This provides load
> > > balancing but still routes INVITEs = carrying SAMs in the
> proper way.
> > >
> > > Does this resolve your issue?
> > >
> > > Best regards,
> > >
> > > Gonzalo
> > >
> > >
> > >
> > > > Regards,
> > > >
> > > > K. Robinson.
> > > >
> > > > Gonzalo Camarillo = <Gonzalo.Camarillo@lmf.ericsson.se> on
> > > 01/01/88 00:39:14
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  = To:      Jonathan Rosenberg = <jdrosen@dynamicsoft.com>
> > > >
> > > >  = cc:      "'Tom-PT Taylor'" = <taylor@nortelnetworks.com>,
> > > = >           = Christer Holmberg
> > > = >           = <christer.holmberg@lmf.ericsson.se>,
> > > = >           = sip@lists.bell-labs.com(bcc: Keith
> > > = >           = Robinson/MAIN/MC1)
> > > >
> > > >
> > > >
> > > >  Subject: Re: [SIP] Operlap = dialing within a SIP network
> > > >
> > > >
> > > > Hello,
> > > >
> > > > Jonathan Rosenberg wrote:
> > > > >
> > > > > I think the correct answer = about which approach to use
> > > (INFO vs. multiple
> > > > > call legs) depends on your = view of the scope of the
> > > address within the sip
> > > > > cloud. If you believe that = the sip role has ended once
> > > you have enough
> > > > > digits to select an egress = gateway (which may be as few
> > > as one, i.e., +1
> > > > > selects a US gateway), then = the sip address of that
> > > gateway can be viewed as
> > > > > sip:+1@provider.com, and = all subsequent digits are PSTN
> > > issues, outside the
> > > > > scope of SIP.
> > > >
> > > > I definitively agree that this = is the view that INFO fans
> > > have of a SIP
> > > > cloud. What I am saying is that = this view is wrong. This
> > > usage of SIP
> > > > falls outside the scope of = SIP.
> > > > If they want to use SIP for = locating a gateway,  it is
> > > fine. But after
> > > > the gateway has been located, = let's use another method for
> > > transporting
> > > > ISUP signalling.
> > > >
> > > > Let's assume that I get an IAM = with "+1", as Jonathan
> says in his
> > > > example. Then the INVITE = generated by the gateway will reach the
> > US
> > > > gateway. Now, the mission of SIP = has finished, since the gateway
> > has
> > > > been located. Why don't we put = in the body of this INVITE a
> > session
> > > > description that comprises a = media session and a SIGTRAN
> > > session? This
> > > > way we would have established = these two sessions between
> > > the gateways
> > > > and all the subsequent ISUP = messages would be sent over the
> > SIGTRAN
> > > > session.
> > > >
> > > > I find that the usage of SIP = that I have just described would be
> > OK.
> > > > What I do not understand is why = folks want to use SIP for
> > > transporting
> > > > subsequent ISUP messages. SIP = does not have good transport
> > > properties
> > > > (big overhead, it can run over = UDP...). Besides, it does not
> > provide
> > > > ordered delivery.
> > > >
> > > > If the INVITE has Cseq=3D1 and = the next message that the
> > > egrees gateway
> > > > receives is a INFO with = Cseq=3D7... what should the gateway do?
> > Maybe
> > > > there were several proxies in = the middle asking for
> > > credentials for the
> > > > INFO, so the ingrees gateway had = to add authentication
> > > stuff and resend
> > > > the INFO. If this was the case, = the SAM contained in the
> > > INFO would be
> > > > the second digit of the called = party number... However, maybe 5
> > INFO
> > > > messages got lost, and the SAM = that we have received in the
> > > body of the
> > > > INFO makes no sense without the = previous ones because is
> > > the 7th digit
> > > > of the number...
> > > >
> > > > This is not usually a problem in = SIP, since all
> messages have full
> >
> > > > state. However, using INFO for = sending SAMs breaks this
> rule, and
> > > > therefore it breaks the SIP = model.
> > > >
> > > > I believe that considering that = the session is established after
> > the
> > > > first INVITE and sending the = following SAMs using INFO is
> > > making one of
> > > > the mistakes described in the = guidelines for SIP authors:
> > > "We need to
> > > > transport ISUP signalling over = IP between two gateways.
> > > Both gateways
> > > > already implement SIP... why do = we have to implement
> > > another protocol?
> > > > Let's use SIP to transport ISUP = signalling". We are just
> > > trying to use
> > > > SIP for this just because it = would save implementing yet another
> > > > protocol in the gateways.
> > > >
> > > > I strongly disagree with this = usage of SIP. SIP-T is good
> > > as long as the
> > > > SIP cloud provides services. If = not, SIP-T is not a good
> > > protocol for
> > > > transporting ISUP = signalling.
> > > >
> > > > Best regards,
> > > >
> > > > Gonzalo
> > > >
> > > >  If you believe that the = sip role encompasses functions that
> > > > > might apply to the PSTN = subscribers, then you need to
> > > have the entire
> > > > > number, and the multiple = call leg approach is the right way to
> > go.
> > > > >
> > > > > The multiple call leg = approach is clearly ugly and
> > > inelegant, but it has the
> > > > > nice property of completely = masking the existence of
> > > overlap from proxies
> > > > > and app servers within the = network, allowing them to
> > > provide services in the
> > > > > normal way.
> > > > >
> > > > > -Jonathan R.
> > > > >
> > > > > ---
> > > > > Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
> > > > > Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> > > > > = dynamicsoft          &= nbsp;           &= nbsp;          East Hanover= , NJ
> > 07936
> > > > > = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973)
> > 952-5050
> > > > > http://www.cs.columbia.edu/~jdrosen  &nb= sp;      PHONE: (973)
> > 952-5000
> > > > > http://www.dynamicsoft.com
> > > > >
> > > > > -----Original = Message-----
> > > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c= om]
> > > > > Sent: Thursday, February = 08, 2001 7:00 AM
> > > > > To: Gonzalo = Camarillo
> > > > > Cc: Christer Holmberg; = sip@lists.bell-labs.com
> > > > > Subject: RE: [SIP] Operlap = dialing within a SIP network
> > > > >
> > > > > You are correct about using = some other means of transport if
> > ISUP
> > > > > trans-shipment is all your = network is doing.  If the call
> > > destination (to a
> > > > > SIP endpoint, to an H.323 = endpoint, to a PSTN endpoint)
> > > varies on a per-call
> > > > > basis, however, using SIP = to establish your call routing
> > > leads to using SIP
> > > > > to carry the ISUP.
> > > > > > -----Original = Message-----
> > > > > > From: Gonzalo = Camarillo
> > > [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > > > > Sent: Tuesday, = February 06, 2001 9:52 PM
> > > > > > To: Taylor, Tom-PT = [NORSE:B901:EXCH]
> > > > > > Cc: Christer Holmberg; = sip@lists.bell-labs.com
> > > > > > Subject: Re: [SIP] = Operlap dialing within a SIP network
> > > > > >
> > > > > >
> > > > > > Hi Tom,
> > > > > >
> > > > > > Still I want to have = full state in every SIP message.
> > > If the call is
> > > > > > addresed to the phone = number 1234, I want to have a to
> > > field that says
> > > > > > 1234. I do not care if = there is a leg routed thru the
> > > PSTN and another
> > > > > > thru SIP.
> > > > > >
> > > > > > Carrying full state is = one of the beauties of SIP. If
> > > we begin using
> > > > > > INFO for this, it = would be the same as using SAMs.
> > > Differen names, the
> > > > > > same thing... I do not = want to re-create ISUP using SIP. I
> > > > > > believe that
> > > > > > if the session has a = destination, it should be
> present in the
> > > > > > to field.
> > > > > >
> > > > > > Again, if a proxy is = providing services for this
> > > particular call, it
> > > > > > will want to see the = called party number in order to trigger
> > > > > > the proper
> > > > > > service. This is a = very good reason for updating
> the to field
> > > > > > every time
> > > > > > we have more = digits.
> > > > > >
> > > > > > I like to use SIP = between two gateways because it
> is possible
> > > > > > to provide
> > > > > > SIP services for a = PSTN to PSTN call. If all we
> want to do is
> > > > > > finding a
> > > > > > egrees gateway, we = would probably want to use other
> > > protocols (TRIP &
> > > > > > SIGTRAN for = instance).
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Gonzalo
> > > > > >
> > > > > > Tom-PT Taylor = wrote:
> > > > > > >
> > > > > > > Sorry, we're = talking past each other.  The premise of my
> > > > > > statements is
> > > > > > > that an INVITE = has reached a UAS which has accepted
> > > it.  It follows
> > > > > > > that the UAS did = not send back a 484, but rather
> an interim
> > > > > > response.
> > > > > > > IF more digits = come along, the INFO method is there
> > > to carry them.
> > > > > > > They do not = affect the SIP call state; they are used
> > > beyond the UAS,
> > > > > > > either in a PSTN = call or in another SIP call as the
> > > case may be.
> > > > > > >
> > > > > > > > = -----Original Message-----
> > > > > > > > From: = Gonzalo Camarillo
> > > [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > > > > > > Sent: = Tuesday, February 06, 2001 9:10 PM
> > > > > > > > To: Taylor, = Tom-PT [NORSE:B901:EXCH]
> > > > > > > > Cc: Christer = Holmberg; sip@lists.bell-labs.com
> > > > > > > > Subject: Re: = [SIP] Operlap dialing within a SIP network
> > > > > > > >
> > > > > > > >
> > > > > > > > Hello = Tom,
> > > > > > > >
> > > > > > > > Tom-PT = Taylor wrote:
> > > > > > > > >
> > > > > > > > > Just to = re-hash, in the ISUP-SIP-ISUP
> context, once call
> >
> > > > > > > signalling
> > > > > > > > > has = reached an egress gateway, SIP has done its job --
> > > > > > additional
> > > > > > > > > digits = will not change call state.  It is therefore
> > > > > > > > reasonable = to use
> > > > > > > > > INFO to = carry the additional digits.  If we
> are talking
> > > > > > > > ISUP-SIP, = once
> > > > > > > > > the = destination UAS or a UAS in a B2BUA has been
> > > > > > reached, the = same
> > > > > > >
> > > > > > > > > = consideration applies.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I do not = agree with these two statements:
> > > > > > > >
> > > > > > > > The 1st = INVITE (with just some digits) arrives to a
> > > > > > vanilla SIP UA.
> > > > > > > I
> > > > > > > > will return = a Not Found or a 484 Address incomplete. The
> > > > > > > > subsequent = INFO
> > > > > > > > carrying = more digits will be discarded. Thus, the
> > > PSTN to SIP
> > > > > > > gateway
> > > > > > > > will have to = re issue a new INVITE with all the digits.
> > > > > > > > Therefore, = it is
> > > > > > > > better to = begin directly using er-INVITEs rather than
> > INFO.
> > > > > > > >
> > > > > > > > Besides, I = do not think that SIP is just a
> > > transport protocol that
> > > > > > > > carries ISUP = messages between two gateways. For
> > > that, we have
> > > > > > > already
> > > > > > > > SIGTRAN. SIP = might be used to provide services,
> > > even when the
> > > > > > > > call is = a
> > > > > > > > = PSTN-SIP-PSTN call. Thus, SIP messages MUST
> carry complete
> >
> > > > > > > > state. And = a
> > > > > > > > SIP message = with an incomplete to field does not
> > > carry complete
> > > > > > > state.
> > > > > > > > What if my = SIP proxy provides a service for a
> > > PSTN-SIP-PSTN call
> > > > > > > based
> > > > > > > > on the to = field (called party number). That proxy would
> > > > > > like to see
> > > > > > > an
> > > > > > > > updated to = field, not just a to field that contains
> > > just some
> > > > > > > digits.
> > > > > > > >
> > > > > > > > Best = regards,
> > > > > > > >
> > > > > > > > = Gonzalo
> > > > > > > >
> > > > > > > >
> > > > > > > > > > = -----Original Message-----
> > > > > > > > > > = From: Christer Holmberg
> > > > > > > [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > > > > > > > > > = Sent: Tuesday, February 06, 2001 1:15 AM
> > > > > > > > > > = To: Gonzalo Camarillo
> > > > > > > > > > = Cc: sip@lists.bell-labs.com
> > > > > > > > > > = Subject: Re: [SIP] Operlap dialing within a SIP
> > network
> > > > > > > > > = >
> > > > > > > > > = >
> > > > > > > > > = >
> > > > > > > > > > Hi = Gonzalo,
> > > > > > > > > = >
> > > > > > > > > > I = didn't say I am going to use INFO, but that
> > > is what has
> > > > > > > > > > = been proposed
> > > > > > > > > > = earlier in this thread, so I assumed INFO would
> > > be used. The
> > > > > > > > > > = reason for
> > > > > > > > > > = the discussion from the beginning was that
> the overlap
> >
> > > > > > > = signalling,
> > > > > > > > > > = according to the SIP-ISUP mapping draft,
> may not work
> > > > > > > > very well, = and
> > > > > > > > > = a
> > > > > > > > > > = solution using 18x responses and INFO messages,
> > > instead of 484
> > > > > > > and
> > > > > > > > > > = re-INVITEs, was proposed.
> > > > > > > > > = >
> > > > > > > > > > = Regards,
> > > > > > > > > = >
> > > > > > > > > > = Christer Holmberg
> > > > > > > > > > = Ericsson Finland
> > > > > > > > > = >
> > > > > > > > > = >
> > > > > > > > > = >
> > > > > > > > > > = Gonzalo Camarillo wrote:
> > > > > > > > > > = >
> > > > > > > > > > = > Hello Christer,
> > > > > > > > > > = >
> > > > > > > > > > = > Why are you using INFO for sending extra digits?
> > > > > > > > > > = >
> > > > > > > > > > = > Please, check the SIP-ISUP mapping draft, overlap
> > > > > > > > > > = signalling section.
> > > > > > > > > > = >
> > > > > > > > > > = > Regards,
> > > > > > > > > > = >
> > > > > > > > > > = > Gonzalo
> > > > > > > > > > = >
> > > > > > > > > > = > Christer Holmberg wrote:
> > > > > > > > > > = > >
> > > > > > > > > > = > > Hi,
> > > > > > > > > > = > >
> > > > > > > > > > = > > The discussion about overlap dialing has
> > > been pretty much
> > > > > > > > > > = about calls
> > > > > > > > > > = > > from SIP to PSTN, or PSTN-SIP-PSTN.
> > > > > > > > > > = > >
> > > > > > > > > > = > > Consider the following scenario.
> > > > > > > > > > = > >
> > > > > > > > > > = > > PSTN = PHONE           &= nbsp; GW           = SIP SERVER
> > > > > >   SIP = UAS
> > > > > > > > > > = > >
> > > > > > = -----------------------------------------------------------
> > > > > > > > > > = > >
> > > > > > > > > > = > > --- 1 --->    -- IAM -> | -- INVITE = -->  |
> > > > > > > > > > = > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > > > > = > > --- 2 --->    -- SAM -> | -- INFO = ---->  |
> > > > > > > > > > = > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |
> > > > > > > > > > = > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > > > > = > > --- 3 --->    -- SAM -> | -- INFO = ---->  |
> > > > > > > > > > = > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |
> > >  -- INVITE
> > > > > > > > > > = > > -->
> > > > > > > > > > = > = >           &n= bsp;           &n= bsp; | <- 200 (INVITE)|
> > >  <- 200 ------
> > > > > > > > > > = > >
> > > > > > > > > > = > > In this case, the SIP server (note that I
> > > am not using
> > > > > > > > > > = the word 'proxy')
> > > > > > > > > > = > > must collect digits, sent from the PSTN
> side using
> >
> > > > > > > > > > = overlap dialing, to
> > > > > > > > > > = > > be able to find the SIP UAS, and INFO is
> > > used to provide
> > > > > > > > > > = the digits
> > > > > > > > > > = > > after the INVITE has been sent.
> > > > > > > > > > = > >
> > > > > > > > > > = > > My question is, should a SIP server (proxy,
> > > if you like)
> > > > > > > > > > be = allowed to
> > > > > > > > > > = > > behave like this, or MUST it send 486s, and
> > > receive new
> > > > > > > > > > = INVITEs, until
> > > > > > > > > > = > > it is able to find the UAS?
> > > > > > > > > > = > >
> > > > > > > > > > = > > Regards,
> > > > > > > > > > = > >
> > > > > > > > > > = > > Christer Holmberg
> > > > > > > > > > = > > Ericsson Finland
> > > > > > > > > > = >
> > > > > > > > > > = > --
> > > > > > > > > > = > Gonzalo Camarillo         = Phone :  +358 
> 9 299 33 71
> >
> > > > > > > > > > = > Oy L M Ericsson Ab        = Mobile:  +358
> 40 702 35 35
> >
> > > > > > > > > > = > Telecom = R&D           = ;    Fax   :  +358 
> 9 299 30 52
> >
> > > > > > > > > > = > FIN-02420 = Jorvas          Email = :
> > > > > > > > = Gonzalo.Camarillo@ericsson.com
> > > > > > > > > > = > = Finland           = ;       
> http://www.hut.fi/~gonzalo
> >
> > > > > > > > > = >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > > > > > Oy L M = Ericsson Ab        Mobile:  = +358 40 702 35 35
> > > > > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > > > > > FIN-02420 = Jorvas          Email = :
> > > Gonzalo.Camarillo@ericsson.com
> > > > > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > > > FIN-02420 = Jorvas          Email = :
> > > Gonzalo.Camarillo@ericsson.com
> > > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > > >
> > > >
> > > > --
> > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > FIN-02420 = Jorvas          Email = : 
> Gonzalo.Camarillo@ericsson.com
> > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > >
> > > > = _______________________________________________
> > > > This list is for continuing = development of the SIP protocol.
> > > > The sip-implementer's list is = the place to discuss
> implementation,
> >
> > > > and to receive advice on = understanding existing sip.
> > > > To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> > > > "subscribe = sip-implementors" in the body.
> > >
> > > --
> > > Gonzalo = Camarillo          &nb= sp;         Phone :   = +1 212 939 71 71
> > > Columbia = University          &n= bsp;       Mobile:  +358 40 702 35 = 35
> > > 472 Computer Science = Building        Fax   = :  +358  9 299 30 52
> > > 1214 Amsterdam Ave., Mail Code = 0401  http://www.hut.fi/~gonzalo
> > > New York, NY 10027
> > > = USA           &nb= sp;           &nb= sp;      Gonzalo.Camarillo@ericsson.com
> > >
> > > = _______________________________________________
> > > This list is for continuing = development of the SIP protocol.
> > > The sip-implementer's list is the = place to discuss implementation,
> > > and to receive advice on = understanding existing sip.
> > > To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> > > "subscribe = sip-implementors" in the body.
> > >
>

------_=_NextPart_001_01C09803.EEECBCF0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 09:44:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00485 for ; Fri, 16 Feb 2001 09:44:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8F72F44337; Fri, 16 Feb 2001 09:44:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 0A06E44336 for ; Fri, 16 Feb 2001 09:32:35 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1GEWXC05937 for ; Fri, 16 Feb 2001 15:32:33 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Feb 16 15:32:10 2001 +0100 Received: by esealnt746.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 16 Feb 2001 15:32:10 +0100 Message-ID: From: "Jacco de Kraker (ELN)" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] transcripts interim meeting? (esp. REFER issue) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 15:32:00 +0100 Hi all, Are any transcripts of the interim meeting of last week available somewhere on the Internet? I assumed some of the discussed issues would show up on this list, but I haven't seen anything about it. I'm especially interested in any decisions/clarifications/new problems related to the REFER issue. If anybody knows where I can find transcripts of the 8-9 February meeting, please tell the list. I'm sure I'm not the only one interested. Regards, /Jacco _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 09:46:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00574 for ; Fri, 16 Feb 2001 09:46:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 79ABC44346; Fri, 16 Feb 2001 09:46:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailstore.ttimail.com (mailstore.ttimail.com [216.86.19.120]) by lists.bell-labs.com (Postfix) with ESMTP id 71DE844336 for ; Fri, 16 Feb 2001 09:45:35 -0500 (EST) Received: from ns2.ttiweb.com ([10.10.100.7]) by mailstore.ttimail.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id IAA06239; Fri, 16 Feb 2001 08:45:30 -0600 Received: from host-1.ttimail.com [10.10.100.6] by ns2.ttiweb.com [10.10.100.7] (CMSPraetor 4.1.3395) with ESMTP id 6C5258EB024B11D5877A00105A0A6577 for plus 1 more; Fri, 16 Feb 2001 08:45:10 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [SIP] transcripts interim meeting? (esp. REFER issue) X-MIMEOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <766C3CB30588BB48B34C55C2BEDF500305CF2D@host-1.ttiworld.com> Thread-Topic: [SIP] transcripts interim meeting? (esp. REFER issue) Thread-Index: AcCYJvUZ40yOPBilTYqkUU4rGO0ohAAAAw4A From: "Kevin Summers" To: "Jacco de Kraker (ELN)" , Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 08:45:10 -0600 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA00574 http://www.softarmor.com/sipwg/meets/interim-feb-01/index.html -----Original Message----- From: Jacco de Kraker (ELN) [mailto:Jacco.de.Kraker@eln.ericsson.se] Sent: Friday, February 16, 2001 8:32 AM To: 'sip@lists.bell-labs.com' Subject: [SIP] transcripts interim meeting? (esp. REFER issue) Hi all, Are any transcripts of the interim meeting of last week available somewhere on the Internet? I assumed some of the discussed issues would show up on this list, but I haven't seen anything about it. I'm especially interested in any decisions/clarifications/new problems related to the REFER issue. If anybody knows where I can find transcripts of the 8-9 February meeting, please tell the list. I'm sure I'm not the only one interested. Regards, /Jacco _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 10:47:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02257 for ; Fri, 16 Feb 2001 10:47:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 09A0744337; Fri, 16 Feb 2001 10:47:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id 988DC44336 for ; Fri, 16 Feb 2001 10:46:57 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qhars002.nortel.com; Fri, 16 Feb 2001 15:45:24 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <102C0G0A>; Fri, 16 Feb 2001 15:45:23 -0000 Message-ID: From: "Mark Watson" To: "'Chip Sharp'" Cc: "'Christian Huitema'" , "Rosen, Brian" , William Marshall , sip Subject: RE: [SIP] Re: Location information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0982F.76EAAD30" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 15:45:19 -0000 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_01C0982F.76EAAD30 Content-Type: text/plain; charset="iso-8859-1" Chip, Comments inline... ...Mark > -----Original Message----- > From: Chip Sharp [mailto:chsharp@cisco.com] > Sent: 15 February 2001 14:49 > To: Watson, Mark [MAIFP:EP11-M:EXCH] > Cc: 'Christian Huitema'; Rosen, Brian; William Marshall; sip > Subject: RE: [SIP] Re: Location information > > > The term "public network" has regulatory implications in most > countries. Oh yes. > As you say, SIP runs end-to-end over an IP infrastructure. > It can run > between two endpoints that also terminate the RTP stream (e.g., "SIP > phones") or it can run between a SIP UA and a proxy/redirect/etc. > server. Either way, the two IP hosts running SIP are > endpoints on the IP > network and (may) have a customer relationship with the IP > network provider > (i.e., not belong to the IP access provider). > > In this case, I may go Christian's question one step further > and ask "what > is this network you are talking about." ;-) The 'network' consisting of the SIP proxies and the relationships between them. Perhaps 'network' is not the right term. It is kind of > like talking > about the email network. Yes, by which you would mean SMTP servers and the relationships between them. > > Basically, SIP exchanges are always private exchanges between > two endpoints > on the IP network as you say in the first paragraph. > :-) If the SIP 'exchanges' are owned by a third party (i.e. not one of the parties between whom the session is being set up), and the service offered by them is offered publically (i.e. to anyone with enough $$$), then I think they could be considered 'publically available telecommunications systems', not private systems. > > As for work going on for restricting users' choice, this > should *not* be a > work item for the SIP WG charter. The very thought! >I can think of at least > one regulatory > agency that would be interested in hearing more about this work. :-\ > > Chip > > At 07:06 AM 2/15/2001, Mark Watson wrote: > >Hmmm, this is perhaps a slightly larger issue than suits > this thread, but > >anyway: > > > >If there is no 'man in the middle' i.e. you can find and > connect to your > >destination directly at the IP layer, then this is > essentially a private > >transaction between you and the destination. You can do what > you like in > >this context - it's just up to you and the destination to > agree between > >youselves. (Although you still both have to respect applicable Data > >Protection Legislation in respect of any personal > information you receive > >from each other.) > > > >If you make your connection via an intermediate proxy or > proxies operated > >by a third party, presumably you do this because those > proxies offer some > >kind of service (e.g. routing). If the third party makes > this service > >publically available, then this is whom I consider the > 'public network'. > > > >Of course there will be many such service providers that a > user can choose > >from - though there is plenty of work going on to invent ways of > >restricting a users choice in certain environments. > > > >...Mark > >>-----Original Message----- > >>From: Christian Huitema [mailto:huitema@exchange.microsoft.com] > >>Sent: 06 February 2001 17:37 > >>To: Watson, Mark [MAIFP:EP11-M:EXCH]; Rosen, Brian; William Marshall > >>Cc: sip > >>Subject: RE: [SIP] Re: Location information > >> > >>Uh, what is exactly the "public network" that you are > talking about? The > >>ISP to which my entreprise network connects have no idea of > what the bits > >>in the packets are, and probably don't want to know. The basic SIP > >>solution is end-to-end, with the network being essentially > transparent. > >>Sure, there may be competing voice service providers that > want to provide > >>added value on top of the basic service, but we cannot > assume that there > >>has to be a man in the middle. > >> > >>-- Christian Huitema > >> > >> > >>-----Original Message----- > >>From: Mark Watson [mailto:mwatson@nortelnetworks.com] > >>Sent: Tuesday, February 06, 2001 8:02 AM > >>To: Rosen, Brian; William Marshall > >>Cc: sip@lists.bell-labs.com > >>Subject: RE: [SIP] Re: Location information > >>The public network will likely be trusted in the sense that > it promises > >>to obey the user's stated privacy requirements, indeed Data > Protection > >>legislation will usually oblige the public network provider > to do this. > >>Also, it will likely be a requirement of the public service that > >>terminals identify themselves in some way. > >>I do not think it likely that for Emergency calls, > terminals/networks > >>will behave differently with respect to identity > information than for > >>normal calls except that it will probably not be considered an > >>infringement of privacy to deliver identity information to > an Emergency > >>call centre even when the user has requested it be kept private. > >>More complex is how does the public service provider verify > the identity > >>and location information ? In the example above, the public service > >>provider can only be sure of the owner of the Enterprise > network from > >>which the call came, and this may not translate into a > single geographic > >>location. The network would be forced to send forward only the > >>'unverified' location information provided by the caller. > >>...Mark > >> > >> > -----Original Message----- > >> > From: Rosen, Brian > >> [mailto:Brian.Rosen@marconi.com] > >> > Sent: 05 February 2001 18:48 > >> > To: 'William Marshall' > >> > Cc: sip@lists.bell-labs.com > >> > Subject: RE: [SIP] Re: Location information > >> > > >> > > >> > If I have an enterprise network, and it connects to a public > >> > network, then > >> > the trust boundary may stop at the private/public boundary. The > >> > "subscriber" > >> > is the enterprise, not the individual. In the privacy draft, > >> > if extended to > >> > location, there is no mechanism to: > >> > Recognize that this is an emergency call > >> > Recognize that the UAS is the emergency center > >> > Pass location information despite any of the requests > >> > the UAC may > >> > make. > >> > > >> > Yet, the requirement is to identify the location of the > individual. > >> > I think the draft has some fine mechanisms in it. I just > >> > don't think they > >> > are > >> > sufficient for emergency purposes. > >> > > >> > Brian > >> > > >> > > -----Original Message----- > >> > > From: William Marshall > >> [mailto:wtm@research.att.com] > >> > > Sent: Monday, February 05, 2001 1:31 PM > >> > > To: brian.rosen@marconi.com > >> > > Cc: sip@lists.bell-labs.com > >> > > Subject: RE: [SIP] Re: Location information > >> > > > >> > > > >> > > An ordinary call must yield subscriber information. There is > >> > > not an option for the user to suppress this, by law > (although the > >> > > user may request this information not be given to the > destination). > >> > > However, the destination can always identify the caller, > >> > for purposes > >> > > of tracing an obscene or harassing call. > >> > > > >> > > Accuracy of location is certainly variable, and it is possible > >> > > the UA may permit delivery of less precise > information, but suppress > >> > > accurate information. Multiple levels are just like multiple > >> > > identities; > >> > > the privacy draft as described by Mark in previous email > >> > > allows separate > >> > > anonymity requirements to be attached to each. > >> > > > >> > > Bill Marshall > >> > > wtm@research.att.com > >> > > > >> > > -----original message----- > >> > > From: "Rosen, Brian" > >> > > To: "'William Marshall'" > >> > > Cc: sip@lists.bell-labs.com > >> > > Subject: RE: [SIP] Re: Location information > >> > > Date: Mon, 5 Feb 2001 12:01:48 -0500 > >> > > > >> > > The problem that location presents that is different from the > >> > > privacy draft (unless I missed it) is that an > emergency call must > >> > > yield location information. There is not an option > for the user > >> > > to suppress this, by law. The path by which a user > might connect > >> > > to an emergency center cannot be pre-arranged. I > believe that it > >> > > will take creation of a cryptographically secure infrastructure > >> > > to allow such a system to have the desired property > that the user > >> > > can control location information, but when required it can be > >> > > securely delivered. > >> > > > >> > > I also think that location is not an "all or nothing" kind of > >> > > thing. The privacy draft presupposes that the world > is bifurcated > >> > > into trusted and untrusted domains, and privacy is secured > >> > > when venturing into an untrusted domain. This is not > the behavior > >> > > I really want. The desired behavior I want is: > >> > > Accuracy (precision) of location is variable > >> > > I may want to give some people precise > >> > > information, others > >> > > less precise. There will be multiple levels > >> > > Time (and motion) variability - if I am mobile, > then where I > >> > > am changes over time. I need to express > this somehow, > >> > > but I also need to control it (not everyone can > >> > > be told that > >> > > I am mobile) > >> > > What we learned in the spatial effort is that the whole > >> > location thing > >> > > is more complex that you would like it to be, and it > is hard to get > >> > > an implementable subset that has enough functionality to be > >> > > interesting. > >> > > We also learned the difficulties in reaching consensus on > >> > issues that > >> > > involve privacy. > >> > > > >> > > Brian > >> > > > >> > > > >> > > > >> > > > >> > > > -----Original Message----- > >> > > > From: William Marshall > >> [mailto:wtm@research.att.com] > >> > > > Sent: Monday, February 05, 2001 11:40 AM > >> > > > To: brian.rosen@marconi.com > >> > > > Cc: sip@lists.bell-labs.com > >> > > > Subject: [SIP] Re: Location information > >> > > > > >> > > > > >> > > > Brian, > >> > > > > >> > > > It seems that the privacy draft faces up squarely to > the privacy > >> > > > concerns. The draft already deals with all the regulatory > >> > > > requirements > >> > > > about verification of identity, hiding of identity, etc. > >> > > The security > >> > > > implications of knowing who you are are just as daunting > >> > as knowing > >> > > > where you are. In some places regulations already cover > >> > > > location info, > >> > > > and the framework in the privacy draft deals with them. > >> > > > > >> > > > As with the subscriber identity - the UA may insert > it, and may > >> > > > demand (via a tag and a Proxy-Require) that it be > kept private. > >> > > > The proxies may verify the identity, and mark it > verified, or mark > >> > > > it unverified, and must delete the information if privacy was > >> > > > requested. > >> > > > The procedures are all there in the privacy draft, > and just need > >> > > > some minor extensions to handle multiple identity types, and > >> > > > per-identity > >> > > > privacy requests. > >> > > > > >> > > > The previous efforts (spatial) generated a string > giving location > >> > > > information. Sip uses "name-addr | addr-spec" > everywhere, which > >> > > > includes a display-name string; however a URL format > >> > would be nicer. > >> > > > I was sure I had heard about a URL format with this > >> > information, but > >> > > > can't find any reference to it. > >> > > > > >> > > > Bill Marshall > >> > > > wtm@research.att.com > >> > > > > >> > > > -----original message----- > >> > > > From: "Rosen, Brian" > >> > > > Subject: RE: Location information (was Re: [SIP] SIP > >> > Privacy Draft) > >> > > > Date: Mon, 5 Feb 2001 10:44:54 -0500 > >> > > > > >> > > > There was an effort started several IETFs ago to > define a PROTOCOL > >> > > > to exchange geographic location. That was shot down. > >> > > There is still > >> > > > a low level effort to define a format for exchanging such > >> > > information. > >> > > > > >> > > > Before starting another effort, you might want to look at > >> > the prior > >> > > > work (spatial). You also MUST forthrightly face up > to the privacy > >> > > > concerns that have stymied other efforts. The security > >> > > > implications of > >> > > > knowing where you are can be VERY daunting, and in general > >> > > discussions > >> > > > on the issues have yielded more problems than answers.' > >> > > > > >> > > > Brian > >> > > > > >> > > > > >> > > > _______________________________________________ > >> > > > This list is for continuing development of the SIP protocol. > >> > > > The sip-implementer's list is the place to discuss > implementation, > >> > > > and to receive advice on understanding existing sip. > >> > > > To subscribe to it, send mail to > majordomo@cs.columbia.edu with > >> > > > "subscribe sip-implementors" in the body. > >> > > > > >> > > > >> > > >> > _______________________________________________ > >> > This list is for continuing development of the SIP protocol. > >> > The sip-implementer's list is the place to discuss > implementation, > >> > and to receive advice on understanding existing sip. > >> > To subscribe to it, send mail to majordomo@cs.columbia.edu with > >> > "subscribe sip-implementors" in the body. > >> > > > > ------------------------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems > ------------------------------------------------------------------- > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > ------_=_NextPart_001_01C0982F.76EAAD30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Re: Location information

Chip,

Comments inline...

...Mark

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: 15 February 2001 14:49
> To: Watson, Mark [MAIFP:EP11-M:EXCH]
> Cc: 'Christian Huitema'; Rosen, Brian; William = Marshall; sip
> Subject: RE: [SIP] Re: Location = information
>
>
> The term "public network" has = regulatory implications in most
> countries.

Oh yes.

> As you say, SIP runs end-to-end over an IP = infrastructure. 
> It can run
> between two endpoints that also terminate the = RTP stream (e.g., "SIP
> phones") or it can run between a SIP UA = and a proxy/redirect/etc.
> server.  Either way, the two IP hosts = running SIP are
> endpoints on the IP
> network and (may) have a customer relationship = with the IP
> network provider
> (i.e., not belong to the IP access = provider).
>
> In this case, I may go Christian's question one = step further
> and ask  "what
> is this network you are talking about." = ;-) 

The 'network' consisting of the SIP proxies and the = relationships between them. Perhaps 'network' is not the right = term.

It is kind of
> like talking
> about the email network.

Yes, by which you would mean SMTP servers and the = relationships between them.

>
> Basically, SIP exchanges are always private = exchanges between
> two endpoints
> on the IP network as you say in the first = paragraph.
> :-)

If the SIP 'exchanges' are owned by a third party = (i.e. not one of the parties between whom the session is being set up), = and the service offered by them is offered publically (i.e. to anyone = with enough $$$), then I think they could be considered 'publically = available telecommunications systems', not private systems.

>
> As for work going on for restricting users' = choice,  this
> should *not* be a
> work item for the SIP WG charter. 

The very thought!

>I can think of at least
> one regulatory
> agency that would be interested in hearing more = about this work. :-\
>
> Chip
>
> At 07:06 AM 2/15/2001, Mark Watson = wrote:
> >Hmmm, this is perhaps a slightly larger = issue than suits
> this thread, but
> >anyway:
> >
> >If there is no 'man in the middle' i.e. you = can find and
> connect to your
> >destination directly at the IP layer, then = this is
> essentially a private
> >transaction between you and the = destination. You can do what
> you like in
> >this context - it's just up to you and the = destination to
> agree between
> >youselves. (Although you still both have to = respect applicable Data
> >Protection Legislation in respect of any = personal
> information you receive
> >from each other.)
> >
> >If you make your connection via an = intermediate proxy or
> proxies operated
> >by a third party, presumably you do this = because those
> proxies offer some
> >kind of service (e.g. routing). If the = third party makes
> this service
> >publically available, then this is whom I = consider the
> 'public network'.
> >
> >Of course there will be many such service = providers that a
> user can choose
> >from - though there is plenty of work going = on to invent ways of
> >restricting a users choice in certain = environments.
> >
> >...Mark
> >>-----Original Message-----
> >>From: Christian Huitema [mailto:huitema@exchange.m= icrosoft.com]
> >>Sent: 06 February 2001 17:37
> >>To: Watson, Mark [MAIFP:EP11-M:EXCH]; = Rosen, Brian; William Marshall
> >>Cc: sip
> >>Subject: RE: [SIP] Re: Location = information
> >>
> >>Uh, what is exactly the "public = network" that you are
> talking about? The
> >>ISP to which my entreprise network = connects have no idea of
> what the bits
> >>in the packets are, and probably don't = want to know. The basic SIP
> >>solution is end-to-end, with the = network being essentially
> transparent.
> >>Sure, there may be competing voice = service providers that
> want to provide
> >>added value on top of the basic = service, but we cannot
> assume that there
> >>has to be a man in the middle.
> >>
> >>-- Christian Huitema
> >>
> >>
> >>-----Original Message-----
> >>From: Mark Watson [mailto:mwatson@nortelnetworks= .com]
> >>Sent: Tuesday, February 06, 2001 8:02 = AM
> >>To: Rosen, Brian; William = Marshall
> >>Cc: sip@lists.bell-labs.com
> >>Subject: RE: [SIP] Re: Location = information
> >>The public network will likely be = trusted in the sense that
> it promises
> >>to obey the user's stated privacy = requirements, indeed Data
> Protection
> >>legislation will usually oblige the = public network provider
> to do this.
> >>Also, it will likely be a requirement = of the public service that
> >>terminals identify themselves in some = way.
> >>I do not think it likely that for = Emergency calls,
> terminals/networks
> >>will behave differently with respect to = identity
> information than for
> >>normal calls except that it will = probably not be considered an
> >>infringement of privacy to deliver = identity information to
> an Emergency
> >>call centre even when the user has = requested it be kept private.
> >>More complex is how does the public = service provider verify
> the identity
> >>and location information ? In the = example above, the public service
> >>provider can only be sure of the owner = of the Enterprise
> network from
> >>which the call came, and this may not = translate into a
> single geographic
> >>location. The network would be forced = to send forward only the
> >>'unverified' location information = provided by the caller.
> >>...Mark
> >>
> >> > -----Original Message-----
> >> > From: Rosen, Brian
> >> [<mailto:Brian.Rosen@marconi.com>mailto:Brian.Rosen@marconi.com]
> >> > Sent: 05 February 2001 = 18:48
> >> > To: 'William Marshall'
> >> > Cc: = sip@lists.bell-labs.com
> >> > Subject: RE: [SIP] Re: Location = information
> >> >
> >> >
> >> > If I have an enterprise network, = and it connects to a public
> >> > network, then
> >> > the trust boundary may stop at = the private/public boundary.  The
> >> > "subscriber"
> >> > is the enterprise, not the = individual.  In the privacy draft,
> >> > if extended to
> >> > location, there is no mechanism = to:
> >> = >       Recognize that this is an = emergency call
> >> = >       Recognize that the UAS is the = emergency center
> >> = >       Pass location information = despite any of the requests
> >> > the UAC may
> >> > make.
> >> >
> >> > Yet, the requirement is to = identify the location of the
> individual.
> >> > I think the draft has some fine = mechanisms in it.  I just
> >> > don't think they
> >> > are
> >> > sufficient for emergency = purposes.
> >> >
> >> > Brian
> >> >
> >> > > -----Original = Message-----
> >> > > From: William Marshall =
> >> [<mailto:wtm@research.att.com>= mailto:wtm@research.att.com]
> >> > > Sent: Monday, February 05, = 2001 1:31 PM
> >> > > To: = brian.rosen@marconi.com
> >> > > Cc: = sip@lists.bell-labs.com
> >> > > Subject: RE: [SIP] Re: = Location information
> >> > >
> >> > >
> >> > > An ordinary call must yield = subscriber information.  There is
> >> > > not an option for the user = to suppress this, by law
> (although the
> >> > > user may request this = information not be given to the
> destination).
> >> > > However, the destination can = always identify the caller,
> >> > for purposes
> >> > > of tracing an obscene or = harassing call.
> >> > >
> >> > > Accuracy of location is = certainly variable, and it is possible
> >> > > the UA may permit delivery = of less precise
> information, but suppress
> >> > > accurate information.  = Multiple levels are just like multiple
> >> > > identities;
> >> > > the privacy draft as = described by Mark in previous email
> >> > > allows separate
> >> > > anonymity requirements to be = attached to each.
> >> > >
> >> > > Bill Marshall
> >> > > wtm@research.att.com
> >> > >
> >> > > -----original = message-----
> >> > > From: "Rosen, = Brian" <Brian.Rosen@marconi.com>
> >> > > To: "'William = Marshall'" <wtm@research.att.com>
> >> > > Cc: = sip@lists.bell-labs.com
> >> > > Subject: RE: [SIP] Re: = Location information
> >> > > Date: Mon, 5 Feb 2001 = 12:01:48 -0500
> >> > >
> >> > > The problem that location = presents that is different from the
> >> > > privacy draft (unless I = missed it) is that an
> emergency call must
> >> > > yield location = information.  There is not an option
> for the user
> >> > > to suppress this, by = law.  The path by which a user
> might connect
> >> > > to an emergency center = cannot be pre-arranged.  I
> believe that it
> >> > > will take creation of a = cryptographically secure infrastructure
> >> > > to allow such a system to = have the desired property
> that the user
> >> > > can control location = information, but when required it can be
> >> > > securely delivered.
> >> > >
> >> > > I also think that location = is not an "all or nothing" kind of
> >> > > thing.  The privacy = draft presupposes that the world
> is bifurcated
> >> > > into trusted and untrusted = domains, and privacy is secured
> >> > > when venturing into an = untrusted domain.  This is not
> the behavior
> >> > > I really want. The desired = behavior I want is:
> >> > >     = Accuracy (precision) of location is variable
> >> > = >           &n= bsp; I may want to give some people precise
> >> > > information, others
> >> > = >           &n= bsp; less precise.  There will be multiple levels
> >> > >     Time = (and motion) variability - if I am mobile,
> then where I
> >> > = >           &n= bsp; am changes over time.  I need to express
> this somehow,
> >> > = >           &n= bsp; but I also need to control it (not everyone can
> >> > > be told that
> >> > = >           &n= bsp; I am mobile)
> >> > > What we learned in the = spatial effort is that the whole
> >> > location thing
> >> > > is more complex that you = would like it to be, and it
> is hard to get
> >> > > an implementable subset that = has enough functionality to be
> >> > > interesting.
> >> > > We also learned the = difficulties in reaching consensus on
> >> > issues that
> >> > > involve privacy.
> >> > >
> >> > > Brian
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > > -----Original = Message-----
> >> > > > From: William Marshall =
> >> [<mailto:wtm@research.att.com>= mailto:wtm@research.att.com]
> >> > > > Sent: Monday, February = 05, 2001 11:40 AM
> >> > > > To: = brian.rosen@marconi.com
> >> > > > Cc: = sip@lists.bell-labs.com
> >> > > > Subject: [SIP] Re: = Location information
> >> > > >
> >> > > >
> >> > > > Brian,
> >> > > >
> >> > > > It seems that the = privacy draft faces up squarely to
> the privacy
> >> > > > concerns.  The = draft already deals with all the regulatory
> >> > > > requirements
> >> > > > about verification of = identity, hiding of identity, etc.
> >> > > The security
> >> > > > implications of knowing = who you are are just as daunting
> >> > as knowing
> >> > > > where you are.  In = some places regulations already cover
> >> > > > location info,
> >> > > > and the framework in = the privacy draft deals with them.
> >> > > >
> >> > > > As with the subscriber = identity - the UA may insert
> it, and may
> >> > > > demand (via a tag and a = Proxy-Require) that it be
> kept private.
> >> > > > The proxies may verify = the identity, and mark it
> verified, or mark
> >> > > > it unverified, and must = delete the information if privacy was
> >> > > > requested.
> >> > > > The procedures are all = there in the privacy draft,
> and just need
> >> > > > some minor extensions = to handle multiple identity types, and
> >> > > > per-identity
> >> > > > privacy = requests.
> >> > > >
> >> > > > The previous efforts = (spatial) generated a string
> giving location
> >> > > > information.  Sip = uses "name-addr | addr-spec"
> everywhere, which
> >> > > > includes a display-name = string; however a URL format
> >> > would be nicer.
> >> > > > I was sure I had heard = about a URL format with this
> >> > information, but
> >> > > > can't find any = reference to it.
> >> > > >
> >> > > > Bill Marshall
> >> > > > = wtm@research.att.com
> >> > > >
> >> > > > -----original = message-----
> >> > > > From: "Rosen, = Brian" <Brian.Rosen@marconi.com>
> >> > > > Subject: RE: Location = information (was Re: [SIP] SIP
> >> > Privacy Draft)
> >> > > > Date: Mon, 5 Feb 2001 = 10:44:54 -0500
> >> > > >
> >> > > > There was an effort = started several IETFs ago to
> define a PROTOCOL
> >> > > > to exchange geographic = location.  That was shot down.
> >> > > There is still
> >> > > > a low level effort to = define a format for exchanging such
> >> > > information.
> >> > > >
> >> > > > Before starting another = effort, you might want to look at
> >> > the prior
> >> > > > work (spatial).  = You also MUST forthrightly face up
> to the privacy
> >> > > > concerns that have = stymied other efforts.  The security
> >> > > > implications of
> >> > > > knowing where you are = can be VERY daunting, and in general
> >> > > discussions
> >> > > > on the issues have = yielded more problems than answers.'
> >> > > >
> >> > > > Brian
> >> > > >
> >> > > >
> >> > > > = _______________________________________________
> >> > > > This list is for = continuing development of the SIP protocol.
> >> > > > The sip-implementer's = list is the place to discuss
> implementation,
> >> > > > and to receive advice = on understanding existing sip.
> >> > > > To subscribe to it, = send mail to
> majordomo@cs.columbia.edu with
> >> > > > "subscribe = sip-implementors" in the body.
> >> > > >
> >> > >
> >> >
> >> > = _______________________________________________
> >> > This list is for continuing = development of the SIP protocol.
> >> > The sip-implementer's list is the = place to discuss
> implementation,
> >> > and to receive advice on = understanding existing sip.
> >> > To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> >> > "subscribe = sip-implementors" in the body.
> >> >
>
>
> = -------------------------------------------------------------------
> Chip = Sharp           &= nbsp;           = Consulting Engineering
> Cisco Systems
> = -------------------------------------------------------------------
>
>
> = _______________________________________________
> This list is for continuing development of the = SIP protocol.
> The sip-implementer's list is the place to = discuss implementation,
> and to receive advice on understanding existing = sip.
> To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the = body.
>

------_=_NextPart_001_01C0982F.76EAAD30-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 10:55:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02412 for ; Fri, 16 Feb 2001 10:55:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94B7B44337; Fri, 16 Feb 2001 10:55:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchatl1.edgeconnect.com (smtp.edgeconnect.com [63.99.99.17]) by lists.bell-labs.com (Postfix) with ESMTP id D118144336 for ; Fri, 16 Feb 2001 10:54:55 -0500 (EST) Received: from DDCW6701 (63.113.183.106 [63.113.183.106]) by exchatl1.edgeconnect.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1TVYRPHK; Fri, 16 Feb 2001 10:46:34 -0500 From: "Victor A Paulsamy" To: "SIP" Cc: "Victor A Paulsamy" 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 Subject: [SIP] What does m-line mean here? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 10:56:26 -0500 Content-Transfer-Encoding: 7bit Hi, I'm having difficulty in understanding the following from RFC2327, SDP. "When a list of payload formats is given, this implies that all of these formats may be used in the session, but the first of these formats is the default format for the session." -- SDP Standards Track, page 20. What does default mean here? When a m-line reads as "m=audio 49230 RTP/AVP 3 4 5", does this mean that the remote UA will be requested to use GSM (PT 3) if it could support it and if it didn't support GSM, the local UA will negotiate for G723 (PT 4) with the remote UA and so on? (It's clear that I need to understand the above phrase!). Thanks for your help and valuable time. Regards, --victor _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 11:01:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02547 for ; Fri, 16 Feb 2001 11:01:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9F15544343; Fri, 16 Feb 2001 11:01:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id 9919844337 for ; Fri, 16 Feb 2001 11:00:07 -0500 (EST) Received: from nwcwi1a.europe.nortel.com by qnsgs000.nortel.com; Fri, 16 Feb 2001 15:58:04 +0000 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2650.21) id <16WQDMJA>; Fri, 16 Feb 2001 15:58:00 -0000 Message-ID: From: "Mark Watson" To: sip MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09831.3861D910" Subject: [SIP] Early media Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 15:57:53 -0000 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_01C09831.3861D910 Content-Type: text/plain; charset="iso-8859-1" All, The notes from the meeting earlier this month seem to indicate an agreement to deprecate early media i.e. to include a SHOULD NOT in respect of media before the 200 OK of the INVITE. Is this a correct understanding of what was agreed ? I seem to remember this issue being discussed extensively on this list late last year and there were strong feelings expressed against changing the semantics of the 200 response to the INVITE. Presently it corresponds to called party answer, but the change above would alter this. Was a solution to these concerns also identified at the meeting ? Does this deprecation apply to the setting up of the media path before 200 OK for QoS assurance, or just when the intention is to play the backwards media to the caller ? Regards, Mark Watson Nortel Networks > -----Original Message----- > From: Kevin Summers [mailto:Kevin.Summers@sonusnet.com] > Sent: 16 February 2001 14:45 > To: Jacco de Kraker (ELN); sip > Subject: RE: [SIP] transcripts interim meeting? (esp. REFER issue) > > > > http://www.softarmor.com/sipwg/meets/interim-feb-01/index.html > > -----Original Message----- > From: Jacco de Kraker (ELN) [mailto:Jacco.de.Kraker@eln.ericsson.se] > Sent: Friday, February 16, 2001 8:32 AM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] transcripts interim meeting? (esp. REFER issue) > > > Hi all, > > Are any transcripts of the interim meeting of last week available > somewhere on the Internet? I assumed some of the discussed issues > would show up on this list, but I haven't seen anything about it. > I'm especially interested in any decisions/clarifications/new problems > related to the REFER issue. > > If anybody knows where I can find transcripts of the 8-9 February > meeting, please tell the list. I'm sure I'm not the only one > interested. > > Regards, > > /Jacco > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > ------_=_NextPart_001_01C09831.3861D910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Early media

All,

The notes from the meeting earlier this month seem to = indicate an agreement to deprecate early media i.e. to include a SHOULD = NOT in respect of media before the 200 OK of the INVITE.

Is this a correct understanding of what was agreed = ?

I seem to remember this issue being discussed = extensively on this list late last year and there were strong feelings = expressed against changing the semantics of the 200 response to the = INVITE. Presently it corresponds to called party answer, but the change = above would alter this.

Was a solution to these concerns also identified at = the meeting ?

Does this deprecation apply to the setting up of the = media path before 200 OK for QoS assurance, or just when the intention = is to play the backwards media to the caller ?

Regards,

Mark Watson
Nortel Networks

> -----Original Message-----
> From: Kevin Summers [mailto:Kevin.Summers@sonusnet= .com]
> Sent: 16 February 2001 14:45
> To: Jacco de Kraker (ELN); sip
> Subject: RE: [SIP] transcripts interim meeting? = (esp. REFER issue)
>
>
>
> http://www.softarmor.com/sipwg/meets/interim-feb-01/in= dex.html
>
> -----Original Message-----
> From: Jacco de Kraker (ELN) [mailto:Jacco.de.Kraker@e= ln.ericsson.se]
> Sent: Friday, February 16, 2001 8:32 AM
> To: 'sip@lists.bell-labs.com'
> Subject: [SIP] transcripts interim meeting? = (esp. REFER issue)
>
>
> Hi all,
>
> Are any transcripts of the interim meeting of = last week available
> somewhere on the Internet? I assumed some of = the discussed issues
> would show up on this list, but I haven't seen = anything about it.
> I'm especially interested in any = decisions/clarifications/new problems
> related to the REFER issue.
>
> If anybody knows where I can find transcripts = of the 8-9 February
> meeting, please tell the list. I'm sure I'm not = the only one
> interested.
>
> Regards,
>
> /Jacco
>
> = _______________________________________________
> This list is for continuing development of the = SIP protocol.
> The sip-implementer's list is the place to = discuss implementation,
> and to receive advice on understanding existing = sip.
> To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the = body.
>
> = _______________________________________________
> This list is for continuing development of the = SIP protocol.
> The sip-implementer's list is the place to = discuss implementation,
> and to receive advice on understanding existing = sip.
> To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the = body.
>

------_=_NextPart_001_01C09831.3861D910-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 11:06:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02692 for ; Fri, 16 Feb 2001 11:06:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7BC3B44363; Fri, 16 Feb 2001 11:06:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207]) by lists.bell-labs.com (Postfix) with ESMTP id 96E0E44343 for ; Fri, 16 Feb 2001 11:05:22 -0500 (EST) Received: (from siplist@localhost) by fdd.com (8.10.1/8.10.1) id f1GG5Hl22838; Fri, 16 Feb 2001 10:05:17 -0600 (CST) From: Rick Dean To: Jonathan Rosenberg Cc: Billy Biggs , Robert Sparks , Ben Campbell , SIP List Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt Message-ID: <20010216100517.A15572@fdd.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jdrosen@dynamicsoft.com on Thu, Feb 08, 2001 at 08:19:03AM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 10:05:17 -0600 Jonathan, Sorry for the delay. This answers your questions if you are still interested. On Thu, Feb 08, 2001 at 08:19:03AM -0500, Jonathan Rosenberg wrote: > Sorry for being absent from sipml discussions.... I was on vacation and > generally been swamped. Following sip is a lot of work these days. > > Anyway, a few comments on this. I realize we are discussing it today during > the meeting, hopefully this note can help set the stage for those > discussions. > > Here is my summary of the differences between this draft and the REFER > draft: > > 1. additional headers for the triggered invite are specified within a body > part of the HANDOFF. In REFER, they are specified as header parameters in > the target's URL. > > I personally dislike the approach taken in HANDOFF. I don't understand why > it is needed. > There is some gripe about complexity with ? separated headers in a URL, > but multipart > is, IMHO, far harder. I agree multipart is bad. The current draft does not use multipart. http://phonectl.sfour.com/ > > 2. the body of the HANDOFF can have SDP, presumably for simultaneously > putting media on hold and initiating the transfer (I believe, please correct > if I'm wrong). SDP in REFER has no meaning. > > I also dislike the approach in HANDOFF. It is turning HANDOFF into a > re-INVITE + REFER > function. Now, ALGs in firewalls need to process HANDOFF to modify media > stream information. B2BUas need to do the same. As a matter of design, sip's > approach has been to modularize and separate functions. This is why we > changed BYE/Also to REFER followed by BYE. The argument made for the HANDOFF > approach is latency and message overhead. I believe this is a red herring in > practice, but its a matter of personal taste in protocol design. > At the time of your writing it had already been discussed on the list that continuing audio to the HANDOFF/MOVE sender should not be possible. Thus, no SDP in the HANDOFF, but it still modifies the media session which you probably won't like. The motivation is moving one end of a two-party call-leg. Continuing media to the old end point makes no sense. As a general rule I do favor SDP in all SIP messages. It makes managing the media stream easier for implementations. Your chatty preference works fine in nice network conditions with fast hosts (i.e. two PCs, same idle eithernet), but when things get bad, the chatty technique goes to hell. Add half a second for each retry. Add some more packets for authentication. Lengthen the sequence. Increase latency. Disallow overlapping transactions. My human customers will notice the delay. Of all the arguements my business team hates to hear, "The delay has to be that long because the protocol requires it." Then they call the protocol broken. They are right SDP in non-INVITES helps make actions *atomic*. I > transferor, and they are not signed. > > This is a huge security hole. It will allow me to take over call legs that > other parties have with each other. Bad. The referred-by equivalent is for the transferee's protection. If the transferor and targe wish to authenticate each other with additional headers, they are free to. The security is just as good/bad as REFER, that if I can snoop packets I can forge messages and hijack connections. MOVE requests are only honored when received in call-legs which are established. > 4. The status of the handoff is conveyed in a re-INVITE in the reverse > direction (presumably so that media on hold can be turned off?) if it fails, > else a BYE if it succeeds. > > I don't like the mis-use of INVITE as a means to convey status for a > previous transaction. What if there are multiple previous REFER? How is the > status correlated to the REFER? What if the triggered generates a 300, which > is recursed by the transferee, then a 400? Which is returned? Are reason > codes returned? What about warning headers? Sounds like a real notification > mechanism is needed here. Mis-use? My code is much easier. vs. what? protocol beauty. More messages suck for end point complexity, round trip delay, error cases, etc. Multiple (thus overlapping) MOVEs do not make sense, and should not be permitted. This guideline will be mentioned to the draft. Thanks. "If the triggered generates a 300 which recursed by the transferee then 400" the transferee decides which code to return. Mandating reports fouls a privacy issue. Hmmmm... I had not thought about warning headers. Is there a reason why they couldn't also be included in the INVITE? privacy permitting of course. > 5. The triggered INVITE from the HANDOFF can contain a Replaces used to > replace the existing call leg between the transferor and target. This causes > the target to send a BYE to the transferor. In REFER, the transferor would > send a BYE to the target, and this would be based on learning the successful > completion of the triggered INVITE. I suppose the argument here is message > overhead and latency, once more. > If the transferor sends the BYE to the target, then the target may have some time when he must support two simultaneous connections, but this is a unnecessisary difficult requirement. The HANDOFF/MOVE draft does not mandate he sends a BYE, but the replaces is requesting him to. Your beef is with the Replaces draft. I believe this behavior will be used with REFER. > > I think that covers it. > > On the issue of method names - if this draft is accepted as a wg document I > would definitely want to change the method name. I'm with Pat on this one; > it will cause confusion. Okay, how about the name "MOVE"? -- Rick > > -Jonathan R. > > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Billy Biggs [mailto:billy@billybiggs.com] > > Sent: Wednesday, February 07, 2001 4:40 PM > > To: Robert Sparks > > Cc: Rick Dean; Ben Campbell; SIP List > > Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt > > > > > > Robert Sparks (rsparks@dynamicsoft.com): > > > > > Rick - characterizing the requirement to request permission from the > > > user before proceeding as doing some form of interactive query is > > > misleading. > > > > > > The REFER draft (in fact, the original TRANSFER draft) states: > > > A UA receiving a well-formed REFER request SHOULD request > > > approval from the user to proceed (this request could be > > > interactive or through configuration). > > > > > > The parenthetical comment is there for a reason. Current generation > > > clients will have configured policy that grants this approval, then > > > next round will have at least that and maybe, hopefully, something > > > more. > > > > We should rephrase it to say that any policy decisions must not ever > > be interactive, but may be subject to local configuration policy. > > > > However, unlike your REFER draft, a HANDOFF (MOVE? TRANSFER?) is > > useless if it cannot be performed immediately. The intent is to > > smoothly transition from a 3-way bridged conference to a 2-way call > > between the unconnected participants. > > > > Regardless, in many (most?) cases the recipient of the > > HANDOFF will be > > a call control server or PSTN gateway, which will be forced to rely on > > local policy. > > > > -- > > Billy Biggs bbiggs@dumbterm.net > > http://www.billybiggs.com/ wbiggs@uwaterloo.ca > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 12:21:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04447 for ; Fri, 16 Feb 2001 12:21:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A188244343; Fri, 16 Feb 2001 12:21:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 3472844337 for ; Fri, 16 Feb 2001 12:20:29 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id XAA01353; Fri, 16 Feb 2001 23:21:57 -0600 Message-ID: <002c01c0983b$75345430$bc036e3f@dynamicsoft.com> From: "Dean Willis" To: "Mark Watson" , "sip" References: Subject: Re: [SIP] Early media MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C09809.29EED720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 11:11:09 -0600 This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C09809.29EED720 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Early mediaGee, I HOPE not. Real world scenarios -- my office uses only SIP phones with a PSTN = gateway for outside communications. The first "hello" is almost = universally clipped. Most annoying. My recollection of recent discussion of basic call flows (no special = "early media") is that the UAC SHOULD be ready to receive media at the = time the INVITE is transmitted. It SHOULD not send media until after it = has sent ACK in response to a 200 OK. -- Dean =20 ----- Original Message -----=20 From: Mark Watson=20 To: sip=20 Sent: Friday, February 16, 2001 9:57 AM Subject: [SIP] Early media All,=20 The notes from the meeting earlier this month seem to indicate an = agreement to deprecate early media i.e. to include a SHOULD NOT in = respect of media before the 200 OK of the INVITE. Is this a correct understanding of what was agreed ?=20 I seem to remember this issue being discussed extensively on this list = late last year and there were strong feelings expressed against changing = the semantics of the 200 response to the INVITE. Presently it = corresponds to called party answer, but the change above would alter = this. Was a solution to these concerns also identified at the meeting ?=20 Does this deprecation apply to the setting up of the media path before = 200 OK for QoS assurance, or just when the intention is to play the = backwards media to the caller ? Regards,=20 Mark Watson=20 Nortel Networks=20 > -----Original Message-----=20 > From: Kevin Summers [mailto:Kevin.Summers@sonusnet.com]=20 > Sent: 16 February 2001 14:45=20 > To: Jacco de Kraker (ELN); sip=20 > Subject: RE: [SIP] transcripts interim meeting? (esp. REFER issue)=20 >=20 >=20 >=20 > http://www.softarmor.com/sipwg/meets/interim-feb-01/index.html=20 >=20 > -----Original Message-----=20 > From: Jacco de Kraker (ELN) [mailto:Jacco.de.Kraker@eln.ericsson.se] = > Sent: Friday, February 16, 2001 8:32 AM=20 > To: 'sip@lists.bell-labs.com'=20 > Subject: [SIP] transcripts interim meeting? (esp. REFER issue)=20 >=20 >=20 > Hi all,=20 >=20 > Are any transcripts of the interim meeting of last week available=20 > somewhere on the Internet? I assumed some of the discussed issues=20 > would show up on this list, but I haven't seen anything about it.=20 > I'm especially interested in any decisions/clarifications/new = problems=20 > related to the REFER issue.=20 >=20 > If anybody knows where I can find transcripts of the 8-9 February=20 > meeting, please tell the list. I'm sure I'm not the only one=20 > interested.=20 >=20 > Regards,=20 >=20 > /Jacco=20 >=20 > _______________________________________________=20 > This list is for continuing development of the SIP protocol.=20 > The sip-implementer's list is the place to discuss implementation,=20 > and to receive advice on understanding existing sip.=20 > To subscribe to it, send mail to majordomo@cs.columbia.edu with=20 > "subscribe sip-implementors" in the body.=20 >=20 > _______________________________________________=20 > This list is for continuing development of the SIP protocol.=20 > The sip-implementer's list is the place to discuss implementation,=20 > and to receive advice on understanding existing sip.=20 > To subscribe to it, send mail to majordomo@cs.columbia.edu with=20 > "subscribe sip-implementors" in the body.=20 >=20 ------=_NextPart_000_0029_01C09809.29EED720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Early media
Gee, I HOPE not.
 
Real world scenarios -- my office uses = only SIP=20 phones with a PSTN gateway for outside communications. The first "hello" = is=20 almost universally clipped. Most annoying.
 
My recollection of recent discussion of = basic call=20 flows (no special "early media") is that the UAC SHOULD be ready to = receive=20 media at the time the INVITE is transmitted. It SHOULD not send media = until=20 after it has sent ACK in response to a 200 OK.
 
--
Dean
 
 
 
----- Original Message -----
From:=20 Mark Watson
To: sip
Sent: Friday, February 16, 2001 = 9:57=20 AM
Subject: [SIP] Early = media

All,

The notes from the meeting earlier this month seem = to indicate=20 an agreement to deprecate early media i.e. to include a SHOULD NOT in = respect=20 of media before the 200 OK of the INVITE.

Is this a correct understanding of what was agreed = ?=20

I seem to remember this issue being discussed = extensively on=20 this list late last year and there were strong feelings expressed = against=20 changing the semantics of the 200 response to the INVITE. Presently it = corresponds to called party answer, but the change above would alter=20 this.

Was a solution to these concerns also identified at = the=20 meeting ?

Does this deprecation apply to the setting up of the = media=20 path before 200 OK for QoS assurance, or just when the intention is to = play=20 the backwards media to the caller ?

Regards,

Mark Watson
Nortel = Networks=20

> -----Original Message-----
>=20 From: Kevin Summers [mailto:Kevin.Summers@sonusnet.= com]=20
> Sent: 16 February 2001 14:45
> To: Jacco de Kraker (ELN); sip
>=20 Subject: RE: [SIP] transcripts interim meeting? (esp. REFER = issue)=20
>
> =
>
> h= ttp://www.softarmor.com/sipwg/meets/interim-feb-01/index.html =
>
> -----Original=20 Message-----
> From: Jacco de Kraker = (ELN) [mailto:Jacco.de.Kraker@el= n.ericsson.se]=20
> Sent: Friday, February 16, 2001 8:32 AM =
> To: 'sip@lists.bell-labs.com'
>=20 Subject: [SIP] transcripts interim meeting? (esp. REFER issue)=20
>
> =
> Hi all,
>
>=20 Are any transcripts of the interim meeting of last week = available=20
> somewhere on the Internet? I assumed some of = the=20 discussed issues
> would show up on this = list, but=20 I haven't seen anything about it.
> I'm = especially=20 interested in any decisions/clarifications/new problems =
> related to the REFER issue.
>=20
> If anybody knows where I can find = transcripts of=20 the 8-9 February
> meeting, please tell = the list.=20 I'm sure I'm not the only one
> = interested.=20
>
> Regards, =
>
> /Jacco
>=20
>=20 _______________________________________________
>=20 This list is for continuing development of the SIP protocol. =
> The sip-implementer's list is the place to discuss=20 implementation,
> and to receive advice = on=20 understanding existing sip.
> To = subscribe to it,=20 send mail to majordomo@cs.columbia.edu with
>=20 "subscribe sip-implementors" in the body.
>=20
>=20 _______________________________________________
>=20 This list is for continuing development of the SIP protocol. =
> The sip-implementer's list is the place to discuss=20 implementation,
> and to receive advice = on=20 understanding existing sip.
> To = subscribe to it,=20 send mail to majordomo@cs.columbia.edu with
>=20 "subscribe sip-implementors" in the body.
>=20

------=_NextPart_000_0029_01C09809.29EED720-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 13:45:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06547 for ; Fri, 16 Feb 2001 13:45:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3FCFA44354; Fri, 16 Feb 2001 13:45:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj_ntserver3.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62]) by lists.bell-labs.com (Postfix) with ESMTP id B153D44343 for ; Fri, 16 Feb 2001 13:44:37 -0500 (EST) Received: by sj_ntserver3.sj.nuera.com with Internet Mail Service (5.5.2650.21) id <1QV268DX>; Fri, 16 Feb 2001 10:44:37 -0800 Message-ID: From: "Emami-Nouri, Mohsen" To: "'Henry Sinnreich'" , David Frascone Cc: Pat Calhoun , "Henning G. Schulzrinne" , Michael Thomas , SIP List , C.T.A.M.deLaat@phys.uu.nl, jrv@interlinknetworks.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP 3G wireless extensions! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 10:44:36 -0800 Hi all, please forgive me if this is an inappropriate distribution. I would like to know how to get hold on drafts for SIP 3G wireless extension. thanks _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 14:18:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07584 for ; Fri, 16 Feb 2001 14:18:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E12B744354; Fri, 16 Feb 2001 14:18:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 8CD4944343 for ; Fri, 16 Feb 2001 14:17:01 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id NAA00502; Fri, 16 Feb 2001 13:17:13 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Fri, 16 Feb 2001 13:12:45 -0600 Message-ID: From: "Culpepper, Bert" To: Victor A Paulsamy , SIP Subject: RE: [SIP] What does m-line mean here? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 13:12:44 -0600 comments inline.. > -----Original Message----- > From: Victor A Paulsamy [mailto:victor@voicecore.com] > Sent: Friday, February 16, 2001 10:56 AM > To: SIP > Cc: Victor A Paulsamy > Subject: [SIP] What does m-line mean here? > > > Hi, > > I'm having difficulty in understanding the following from > RFC2327, SDP. > > "When a list of payload formats is given, this implies > that all of > these formats may be used in the session, but the first of these > formats is the default format for the session." -- SDP > Standards Track, > page 20. > > What does default mean here? > > When a m-line reads as "m=audio 49230 RTP/AVP 3 4 5", does > this mean that > the remote UA will be requested to use GSM (PT 3) if it could > support it and > if it didn't support GSM, the local UA will negotiate for > G723 (PT 4) with > the remote UA and so on? (It's clear that I need to > understand the above > phrase!). The SDP in the sender's message indicates its capabilities and where any recipients (of the message) are to send the media to. In the above case, the sender is indicating it can handle any of 3 different media formats all on the same port (49230). The recipient is free to send one or more of the three formats listed. (I wonder how often a m= line like above will be seen in practice. The COTS hw and sw I'm familiar with can't handle multiple simultaneous media encoding formats on a single port, or even switching encoding format without being told.) There is no subsequent media negotiation in SIP in a single session establishment request. Each party "declares" what media formats it can support. Now UAs can negotiate media format in separate session establish requests. One way is for the UAS to respond to an INVITE with 415. The requestor can send another INVITE with a different media format and see if the other end accepts it. Another way is for the UAS to accept the request and send a reINVITE with a different SDP. This is my understanding of SDP and its use in SIP. Others may respond if I'm mistaken. regards, Bert > > Thanks for your help and valuable time. > > Regards, > > --victor > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 14:23:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07744 for ; Fri, 16 Feb 2001 14:23:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 718C044376; Fri, 16 Feb 2001 14:23:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by lists.bell-labs.com (Postfix) with ESMTP id C174044374 for ; Fri, 16 Feb 2001 14:22:22 -0500 (EST) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id OAA27633; Fri, 16 Feb 2001 14:07:19 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852569F5.00690780 ; Fri, 16 Feb 2001 14:07:12 -0500 X-Lotus-FromDomain: TELCORDIA From: "Ashutosh Dutta" To: "Emami-Nouri, Mohsen" Cc: "'Henry Sinnreich'" , David Frascone , Pat Calhoun , "Henning G. Schulzrinne" , Michael Thomas , SIP List , C.T.A.M.deLaat@phys.uu.nl, jrv@interlinknetworks.com Message-ID: <852569F5.0069054E.00@notes949.cc.telcordia.com> Subject: Re: [SIP] SIP 3G wireless extensions! Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 14:06:06 -0500 FYI, these are some of the SIP mobility drafts submitted in IETF recently. There are other useful resources like SIP mobility Paper by Henning and Elin Wedlund which can be found at : http://www.cs.columbia.edu/~hgs/papers/Wedl9908_Mobility.pdf Thanks Ashutosh http URL:draft-itsumo-sip-mobility-service-00.txt Summary Title: Supporting Service Mobility with SIP http URL:draft-itsumo-sip-mobility-req-02.txt Summary Title: Mobility Management in a SIP Environment Requirements, Functions a... http URL:draft-itsumo-sip-mobility-multimedia-00.txt Summary Title: Supporting Mobility for Multimedia with SIP http URL:draft-itsumo-sip-mobility-tcp-00.txt Summary Title: Supporting Mobility for TCP with SIP _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 14:40:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08142 for ; Fri, 16 Feb 2001 14:40:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D639944354; Fri, 16 Feb 2001 14:40:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id AF81444337 for ; Fri, 16 Feb 2001 14:39:37 -0500 (EST) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G8V000N47SJOE@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 16 Feb 2001 19:36:19 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8V004017SG0H@pmismtp04.wcomnet.com>; Fri, 16 Feb 2001 19:36:18 +0000 (GMT) Received: from hsinnreich ([166.44.58.52]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G8V001L17RSN6@pmismtp04.wcomnet.com>; Fri, 16 Feb 2001 19:36:02 +0000 (GMT) From: Henry Sinnreich Subject: RE: [SIP] SIP 3G wireless extensions! In-reply-to: <852569F5.0069054E.00@notes949.cc.telcordia.com> To: Ashutosh Dutta , "Emami-Nouri, Mohsen" Cc: David Frascone , Pat Calhoun , "Henning G. Schulzrinne" , Michael Thomas , SIP List , C.T.A.M.deLaat@phys.uu.nl, jrv@interlinknetworks.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 13:35:58 -0600 Content-Transfer-Encoding: 7bit Thanks Ashutosh! This is very timely. Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA -----Original Message----- From: Ashutosh Dutta [mailto:adutta@telcordia.com] Sent: Friday, February 16, 2001 1:06 PM To: Emami-Nouri, Mohsen Cc: 'Henry Sinnreich'; David Frascone; Pat Calhoun; Henning G. Schulzrinne; Michael Thomas; SIP List; C.T.A.M.deLaat@phys.uu.nl; jrv@interlinknetworks.com Subject: Re: [SIP] SIP 3G wireless extensions! FYI, these are some of the SIP mobility drafts submitted in IETF recently. There are other useful resources like SIP mobility Paper by Henning and Elin Wedlund which can be found at : http://www.cs.columbia.edu/~hgs/papers/Wedl9908_Mobility.pdf Thanks Ashutosh http URL:draft-itsumo-sip-mobility-service-00.txt Summary Title: Supporting Service Mobility with SIP http URL:draft-itsumo-sip-mobility-req-02.txt Summary Title: Mobility Management in a SIP Environment Requirements, Functions a... http URL:draft-itsumo-sip-mobility-multimedia-00.txt Summary Title: Supporting Mobility for Multimedia with SIP http URL:draft-itsumo-sip-mobility-tcp-00.txt Summary Title: Supporting Mobility for TCP with SIP _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 14:59:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08457 for ; Fri, 16 Feb 2001 14:59:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 89F1544379; Fri, 16 Feb 2001 14:59:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by lists.bell-labs.com (Postfix) with ESMTP id 33BBC44343 for ; Fri, 16 Feb 2001 14:58:27 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25507; Fri, 16 Feb 2001 11:58:21 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13136; Fri, 16 Feb 2001 11:58:20 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA26728; Fri, 16 Feb 2001 11:58:18 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [SIP] SIP 3G wireless extensions! To: "Emami-Nouri, Mohsen" Cc: SIP List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 11:54:09 -0800 (PST) Emami-Nouri, The 3G community is still working on understanding how it will be used in their networks. I believe that 3GPP (GSM) may be a little farther ahead than 3GPP2 (CDMA), who last year finished their All-IP architecture and requirements specification, which relies quite heavily on SIP. For access to 3GPP2 specifications, please see www.cdma-2000.org/draft-3gpp2-collaboration-00.txt. The I-D was recently approved by the 3GPP2 steering commitee, and wil be available on the IETF archives in a couple of days. There is a similar 3GPP document, which is available at ftp://ftp.isi.edu/internet-drafts/draft-3gpp-collaboration-00.txt. Currently, one of the big work items is to try to define the AAA requirements for SIP in these networks. A group of people that participate heavily in 3GPP and 3GPP2 have submitted our first revision for such a document, which can be found at ftp://ftp.isi.edu/internet-drafts/draft-calhoun-sip-aaa-reqs-01.txt. I believe that the 3G folks will be submitting additional Internet Drafts as their work continues, but for the moment the best place to find this information is through their respective web sites. Please let me know if you need additional information, PatC _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Fri Feb 16 19:12:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12070 for ; Fri, 16 Feb 2001 19:12:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1C64744337; Fri, 16 Feb 2001 19:12:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id D2A5044336 for ; Fri, 16 Feb 2001 19:11:49 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id QAA04424; Fri, 16 Feb 2001 16:11:52 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f1H0BYc10061; Fri, 16 Feb 2001 16:11:44 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id QAA28381; Fri, 16 Feb 2001 16:11:28 -0800 (PST) Message-ID: <3A8DC26C.818A7115@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: SIP Cc: Mark Watson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Privacy Draft - Next step Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 16 Feb 2001 19:14:36 -0500 Content-Transfer-Encoding: 7bit Greetings Mark Watson posted his updated comments on the privacy draft a couple of weeks ago. Since then, there was some good discussion which seems to have settled down now. With the I-D submission deadline approaching, I'd like to get some closure on this in the (perhaps naive) hope that we can get this WG item finished. Mark's overall comment on the privacy draft was that we should make Remote-Party-ID more general so that it can be used for any type of identity information. One of the key points here is, that the types of identity information should be extensible and hence can be used for new types of identity not defined in the draft. I think this is a good idea and I've seen no disagreement on this so we should accept that as our goal. Mark also suggested five specific enhancements (see http://lists.bell-labs.com/pipermail/sip/2001q1/005470.html for details): 1) Requlatory requirements 2) Types of Party 3) Types of Identity 4) Handling of Privacy Requirements 5) Location Information I've seen no disagreement on 1-4, so we should incorporate these. Location Information generated a lot of discussion though and seemed to be controversial. Based on the comments it seems unlikely that we will be able to solve this one any time soon, however, it's also not clear that it needs to be part of the privacy draft. First of all, location information is not a requirement for all applications of Remote-Party-ID, e.g. non primary-line telephony or in general just non-telephony, which however may still want to use Remote-Party-ID. Secondly, since we will be generalizing the Remote-Party-ID and make it extensible, a URL-based solution could still make use of it for Location Information, but again, I don't see this as an integral part of this extension. Thus, I propose that the specifics of Location Information will not be part of the privacy draft. Assuming nobody objects, I will work with Mark on updating the draft accordingly, so please speak up now if you disagree with any of this. Thanks Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Sat Feb 17 08:53:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04084 for ; Sat, 17 Feb 2001 08:53:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 609F34433D; Sat, 17 Feb 2001 08:53:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 9B25B44336 for ; Sat, 17 Feb 2001 08:52:17 -0500 (EST) 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 f1HDqDd11040; Sat, 17 Feb 2001 14:52:13 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA09350; Sat, 17 Feb 2001 15:52:07 +0200 (EET) Message-ID: <3A8E820E.71A4387E@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson Cc: "'Gonzalo Camarillo'" , Keith Robinson , Jonathan Rosenberg , Tom-PT Taylor , sip@lists.bell-labs.com Subject: Re: [SIP] Operlap dialing within a SIP network References: Content-Type: multipart/mixed; boundary="------------A010A01D19845E321E9039C9" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 17 Feb 2001 15:52:14 +0200 This is a multi-part message in MIME format. --------------A010A01D19845E321E9039C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >I think this is being made a lot more complicated than necessary. > >By negotiation, I just meant that when the call reached a UAS which >supported INFOs, it would return an indication (e.g. 186)that the UAC >could switch to using INFOs. Until the call reached the UAS (i.e. PSTN >Gateway), then INFOs would not be used - you would just have >INVITE/484 exchanges until you had enough digits to reach the UAS. Ok, so this is basically Tom's ogiginal proposal. So, I guess we all can agree on the fact that until we reach the UAS, we use INVITEs and 484 responses. I still agree that there are advantages using INFO. However, using INFO still raises some issues. Consider the case where the INVITE reaches the UAS, which DOES manage to route the call to the next PSTN entity. To inform the UAC about this (this is true BOTH if we use INVITEs or INFOs for the rest of the digits) the UAS sends a 18x response. In the INFO-case, the UAS include the "INFO negotiation" result in this response. However: 1. Before the UAC receives the 18x response, it may receive additional digits, and will send a new INVITE. In this case, the UAS must be able to handle new INVITEs, EVEN if it has indicated in the 18x response that it does support the method using INFOs. This case will not happen if the UAC always will wait for a response before it sends the next request, INVITE or INFO, but that may slow down the call setup, AND digig buffering must be implemented. 2. Since the UAS may not support the method using INFO, the UAC may still have to use INVITEs for the additional digits. Conclusion: No matter which method we want to use, both the UAC and UAS must be able to use both methods, and, like I mentioned, the UAS may have to process additional INVITEs even if it has sent a 18x response and indicated the support for INFO. So, from this point of view I think it costs more than it gains by using INFO. Also, if we define rules for the routing the gain is even less. The only case where I (this is my personal opinion) could agree it makes any sense at all to use INFO is when the UAC always waits for a response from the UAS before it sends the next request, but do we really want to require that? And, if we solve the routing issue in a nice way I don't think it's worth the effort - even if we also don't have to send ACKs by using INFO. Regards, Christer Holmberg Ericsson Finland > For proxies which need to see all the digits, they can still operate > in INVITE/484 mode until they have enough digits to route - the proxy > would not trigger the UAC to send INFOs, but if a downstream UAS > *did*, the proxy could examine subsequent INFOs which come past in > order to update its record of the destination number. > > Regards...Mark > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: 15 February 2001 21:42 > > To: Watson, Mark [MAIFP:EP11-M:EXCH] > > Cc: 'Gonzalo Camarillo'; Keith Robinson; Jonathan Rosenberg; Taylor, > > > Tom-PT [NORSE:B901:EXCH]; sip@lists.bell-labs.com > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > Hi, > > > > Again, I am Gonzalo, but I will also comment... :) > > > > Mark Watson wrote: > > > > > >Gonzalo, > > > > > >I don't understand your comment about the INFO Overlap proposals > > >causing problems for 'vanilla' SIP UAs. My suggestion was > > that the use > > >of INFOs for overlap digits be negotiated between UAC and UAS. > > > > My personal opinion is that, even if this overlap dialing thing > seems > > like a very difficult problem to solve, the functionality itself is > > pretty minor, so I don't think that a UA should have to > > negotiate about > > the method to use for this... Also, I don't think your negotiation > > proposal would work. You should remember that you have to > > reach the UAS > > before you can do this negotiation in the first place, which means > you > > may have to send a number of INVITEs, and receive 484 responses from > > > proxies. And, even when you reach the UAS (let's assume it's a PSTN > > gateway), it may be able to forward the digits, so the only answer > you > > are going to get is 100 - which you will get from the first proxy, > so > > the UAS can't include the negotiation result there. > > > > This response-from-the-UAS thing is, however, related to another > issue > > which I will describe in another mail. > > > > >So, the UAC would include a 'Supported' tag if it could do overlap > > >INFOs and the mechanism would then only be used if both ends > > supported > > >it. Otherwise you would just kill session requests without enough > > >digits with 484s. > > > > See my comment above why I don't this would work very well. > > > > >Regarding Application Servers, the INFOs should certainly contain > all > > >the digits so far (otherwise we get the problems with lost > messages). > > >I do not believe any proxies exist which are being used today in > > >overlap situations and which need access to the whole called > number, > > >so we can add this capability to the specification without > > hurting any > > >existing implementations. > > > > Well, well, well... Let's assume it's a proxy that sends the 484 > > response. Then, if you want to start using INFO, this proxy must > > remember the INVITE, and collect the INFOs. Then, when the proxy has > > > enough digits, what shall it do then? Create an INVITE of > > it's own? What > > will then happen when the UAC receive the response for an INVITE it > > never created? Also, when the proxy sends the INVITE, it may > > receive 484 > > responses from the NEXT proxy in the network, asking for more > digits. > > Ie, your proxy would have to both collect digits from the UAC, and > > handle the next entity (in this example, another proxy) in the SIP > > nework. All this would DEFINITELY hurt existing > > implementations, so you > > would also have to negotiate with the proxies if they are able to do > > > this... > > > > In this case I think Keith's proposal, ie that the proxy is > > smart enough > > to see that the only thing that has changed in the new INVITE is the > > > receiver digits, is MUCH easier to implement :) > > > > >Finally, there are many reasons other than simple load balancing > why > > >one INVITE might be routed differently to a subsequent, apparently > > >identical, one. e.g. Time of day routing - which is certainly not > > >'random'. Stateful proxies may also remember where they sent the > > >INVITE so that subsequent requests on the same call leg can be > routed > > >the same way. > > > > I agree, routing is a problem, but there has been proposals > > to solve it, > > ie the one Keith gave. Also, I think that routing, and forking, is > the > > reason for a number of SIP related problems, so I think it is > > better to > > find a generic solution to that. Allowing ROUTE headers in specific > > situations (again, see Keith's proposal) in initial requests > > is partly a > > solution. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > > > > > Regards, > > > > > > Mark Watson > > > Nortel Networks > > > > > > > -----Original Message----- > > > > From: Gonzalo Camarillo > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > Sent: 14 February 2001 14:31 > > > > To: Keith Robinson > > > > Cc: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B901:EXCH]; > Christer > > > > Holmberg; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hello Keith, > > > > > > > > Keith Robinson wrote: > > > > > > > > > > Gonzalo, > > > > > > > > > > It seems you have two main reasons against the use of the > > > > INFO > > > > > method for the conveyance of subsequent ISUP information: > > > > > > > > > > 1) Lack of ordered delivery of the INFO messages > > > > > > > > > > Ordered delivery could be maintained by the UAC not sending > > > > the next INFO > > > > > until a 200 OK response for the previous one had been > received. > > > > > > > > > > 2) Lack of state carried in the INFO messge > > > > > > > > > > The digits received so far could be carried in a header > > within the > > > > > > > > INFO message. Each INFO message would then carry the same > > > > information > > > > > as a re-INVITE. > > > > > > > > > > > > > Actually my main reason against the use of INFO is that it > > > > does not work > > > > with vanilla SIP UAs and vanilla SIP Application Servers. How > you > > > > resolve the technical issues related to INFO does not > > really matter > > > to > > > > me. It is not "vanilla" SIP, and I am against this kind of > > > > non-standard > > > > mechanisms. > > > > > > > > > > > > > My reason for exploring the use of INFO is not to save on > > > > messages. It is > > > > > to do with the issue of source routing. Again, my concern of > > > source > > > > > routing is not one of a technical nature. What if an > > > > administration has a > > > > > security policy that states source routing (a ROUTE header in > > > > > an initial INVITE) will not take place in its SIP network > > > > but it also requires > > > > > that > > > > > the same network interworks with the PSTN; if any part of > > > > the PSTN interworking > > > > > mechanism > > > > > relies on source routing then there is a conflict of > > > > requirements. It is this > > > > > conflict > > > > > I wish to address. > > > > > > > > > > > > > OK, let's address this. Source routing is proposed in the draft > to > > > > address load balancing. This is, a proxy that sends INVITEs > > > > to different > > > > egrees gateways. > > > > > > > > So, if an IAM and one SAM are received, the second INVITE > > might end > > > up > > > > in another gateway than the fist INVITE. This would trigger 2 > IAMs > > > > instead of 1 IAM and 1 SAM. > > > > > > > > OK, this is the problem that has to be solved. What I > > wanted to say > > > in > > > > the draft (I did not have lot of time and it has to be > rephrased), > > > was > > > > the following: > > > > > > > > It is strongly RECOMMENDED that proxies route requests that are > > > > basically identical and just differ in the to field (more > > > > digits) in the > > > > same way. So, if such as proxy performs load balancing, all the > > > > subsequent INVITEs will reach the same egrees gateway. > > > > > > > > This is not difficult to do, because most likely a call to > > > > +1234 has to > > > > be routed in the same way as a call to +12345. So, the only real > > > > > requirement in that proxies do not make routing decisions based > on > > > > random variables (such as internal clocks). > > > > > > > > Then, just in case folks did not feel comfortable with > > this solution > > > > > > > (which I believe is the good one), I outlined the source routing > > > > > solution. > > > > > > > > And what about load balancing? You can still have load > balancing. > > > Your > > > > proxy makes the routing decision based on to, from, and what > > > > ever fields > > > > it wants. Then, it can calculate a digest of some fields, > > and make a > > > > > > > "random" routing decision based on that hash. This provides load > > > > > balancing but still routes INVITEs carrying SAMs in the > > proper way. > > > > > > > > Does this resolve your issue? > > > > > > > > Best regards, > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > K. Robinson. > > > > > > > > > > Gonzalo Camarillo on > > > > 01/01/88 00:39:14 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Jonathan Rosenberg > > > > > > > > > > cc: "'Tom-PT Taylor'" , > > > > > Christer Holmberg > > > > > , > > > > > sip@lists.bell-labs.com(bcc: Keith > > > > > Robinson/MAIN/MC1) > > > > > > > > > > > > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > Hello, > > > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > > > I think the correct answer about which approach to use > > > > (INFO vs. multiple > > > > > > call legs) depends on your view of the scope of the > > > > address within the sip > > > > > > cloud. If you believe that the sip role has ended once > > > > you have enough > > > > > > digits to select an egress gateway (which may be as few > > > > as one, i.e., +1 > > > > > > selects a US gateway), then the sip address of that > > > > gateway can be viewed as > > > > > > sip:+1@provider.com, and all subsequent digits are PSTN > > > > issues, outside the > > > > > > scope of SIP. > > > > > > > > > > I definitively agree that this is the view that INFO fans > > > > have of a SIP > > > > > cloud. What I am saying is that this view is wrong. This > > > > usage of SIP > > > > > falls outside the scope of SIP. > > > > > If they want to use SIP for locating a gateway, it is > > > > fine. But after > > > > > the gateway has been located, let's use another method for > > > > transporting > > > > > ISUP signalling. > > > > > > > > > > Let's assume that I get an IAM with "+1", as Jonathan > > says in his > > > > > example. Then the INVITE generated by the gateway will reach > the > > > US > > > > > gateway. Now, the mission of SIP has finished, since the > gateway > > > has > > > > > been located. Why don't we put in the body of this INVITE a > > > session > > > > > description that comprises a media session and a SIGTRAN > > > > session? This > > > > > way we would have established these two sessions between > > > > the gateways > > > > > and all the subsequent ISUP messages would be sent over the > > > SIGTRAN > > > > > session. > > > > > > > > > > I find that the usage of SIP that I have just described would > be > > > OK. > > > > > What I do not understand is why folks want to use SIP for > > > > transporting > > > > > subsequent ISUP messages. SIP does not have good transport > > > > properties > > > > > (big overhead, it can run over UDP...). Besides, it does not > > > provide > > > > > ordered delivery. > > > > > > > > > > If the INVITE has Cseq=1 and the next message that the > > > > egrees gateway > > > > > receives is a INFO with Cseq=7... what should the gateway do? > > > Maybe > > > > > there were several proxies in the middle asking for > > > > credentials for the > > > > > INFO, so the ingrees gateway had to add authentication > > > > stuff and resend > > > > > the INFO. If this was the case, the SAM contained in the > > > > INFO would be > > > > > the second digit of the called party number... However, maybe > 5 > > > INFO > > > > > messages got lost, and the SAM that we have received in the > > > > body of the > > > > > INFO makes no sense without the previous ones because is > > > > the 7th digit > > > > > of the number... > > > > > > > > > > This is not usually a problem in SIP, since all > > messages have full > > > > > > > > state. However, using INFO for sending SAMs breaks this > > rule, and > > > > > therefore it breaks the SIP model. > > > > > > > > > > I believe that considering that the session is established > after > > > the > > > > > first INVITE and sending the following SAMs using INFO is > > > > making one of > > > > > the mistakes described in the guidelines for SIP authors: > > > > "We need to > > > > > transport ISUP signalling over IP between two gateways. > > > > Both gateways > > > > > already implement SIP... why do we have to implement > > > > another protocol? > > > > > Let's use SIP to transport ISUP signalling". We are just > > > > trying to use > > > > > SIP for this just because it would save implementing yet > another > > > > > protocol in the gateways. > > > > > > > > > > I strongly disagree with this usage of SIP. SIP-T is good > > > > as long as the > > > > > SIP cloud provides services. If not, SIP-T is not a good > > > > protocol for > > > > > transporting ISUP signalling. > > > > > > > > > > Best regards, > > > > > > > > > > Gonzalo > > > > > > > > > > If you believe that the sip role encompasses functions that > > > > > > might apply to the PSTN subscribers, then you need to > > > > have the entire > > > > > > number, and the multiple call leg approach is the right way > to > > > go. > > > > > > > > > > > > The multiple call leg approach is clearly ugly and > > > > inelegant, but it has the > > > > > > nice property of completely masking the existence of > > > > overlap from proxies > > > > > > and app servers within the network, allowing them to > > > > provide services in the > > > > > > normal way. > > > > > > > > > > > > -Jonathan R. > > > > > > > > > > > > --- > > > > > > Jonathan D. Rosenberg 72 Eagle Rock > Ave. > > > > > > Chief Scientist First Floor > > > > > > dynamicsoft East Hanover, NJ > > > > 07936 > > > > > > jdrosen@dynamicsoft.com FAX: (973) > > > 952-5050 > > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) > > > 952-5000 > > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > -----Original Message----- > > > > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > > > > Sent: Thursday, February 08, 2001 7:00 AM > > > > > > To: Gonzalo Camarillo > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > You are correct about using some other means of transport if > > > > ISUP > > > > > > trans-shipment is all your network is doing. If the call > > > > destination (to a > > > > > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) > > > > varies on a per-call > > > > > > basis, however, using SIP to establish your call routing > > > > leads to using SIP > > > > > > to carry the ISUP. > > > > > > > -----Original Message----- > > > > > > > From: Gonzalo Camarillo > > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > Still I want to have full state in every SIP message. > > > > If the call is > > > > > > > addresed to the phone number 1234, I want to have a to > > > > field that says > > > > > > > 1234. I do not care if there is a leg routed thru the > > > > PSTN and another > > > > > > > thru SIP. > > > > > > > > > > > > > > Carrying full state is one of the beauties of SIP. If > > > > we begin using > > > > > > > INFO for this, it would be the same as using SAMs. > > > > Differen names, the > > > > > > > same thing... I do not want to re-create ISUP using SIP. I > > > > > > > > believe that > > > > > > > if the session has a destination, it should be > > present in the > > > > > > > to field. > > > > > > > > > > > > > > Again, if a proxy is providing services for this > > > > particular call, it > > > > > > > will want to see the called party number in order to > trigger > > > > > > > the proper > > > > > > > service. This is a very good reason for updating > > the to field > > > > > > > every time > > > > > > > we have more digits. > > > > > > > > > > > > > > I like to use SIP between two gateways because it > > is possible > > > > > > > to provide > > > > > > > SIP services for a PSTN to PSTN call. If all we > > want to do is > > > > > > > finding a > > > > > > > egrees gateway, we would probably want to use other > > > > protocols (TRIP & > > > > > > > SIGTRAN for instance). > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > > Sorry, we're talking past each other. The premise of my > > > > > > > > statements is > > > > > > > > that an INVITE has reached a UAS which has accepted > > > > it. It follows > > > > > > > > that the UAS did not send back a 484, but rather > > an interim > > > > > > > response. > > > > > > > > IF more digits come along, the INFO method is there > > > > to carry them. > > > > > > > > They do not affect the SIP call state; they are used > > > > beyond the UAS, > > > > > > > > either in a PSTN call or in another SIP call as the > > > > case may be. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Gonzalo Camarillo > > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP > network > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP > > context, once call > > > > > > > > > > > signalling > > > > > > > > > > has reached an egress gateway, SIP has done its job > -- > > > > > > > additional > > > > > > > > > > digits will not change call state. It is therefore > > > > > > > > > reasonable to use > > > > > > > > > > INFO to carry the additional digits. If we > > are talking > > > > > > > > > ISUP-SIP, once > > > > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > > > > reached, the same > > > > > > > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > > > > vanilla SIP UA. > > > > > > > > I > > > > > > > > > will return a Not Found or a 484 Address incomplete. > The > > > > > > > > > subsequent INFO > > > > > > > > > carrying more digits will be discarded. Thus, the > > > > PSTN to SIP > > > > > > > > gateway > > > > > > > > > will have to re issue a new INVITE with all the > digits. > > > > > > > > > Therefore, it is > > > > > > > > > better to begin directly using er-INVITEs rather than > > > INFO. > > > > > > > > > > > > > > > > > > Besides, I do not think that SIP is just a > > > > transport protocol that > > > > > > > > > carries ISUP messages between two gateways. For > > > > that, we have > > > > > > > > already > > > > > > > > > SIGTRAN. SIP might be used to provide services, > > > > even when the > > > > > > > > > call is a > > > > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST > > carry complete > > > > > > > > > > > > state. And a > > > > > > > > > SIP message with an incomplete to field does not > > > > carry complete > > > > > > > > state. > > > > > > > > > What if my SIP proxy provides a service for a > > > > PSTN-SIP-PSTN call > > > > > > > > based > > > > > > > > > on the to field (called party number). That proxy > would > > > > > > > like to see > > > > > > > > an > > > > > > > > > updated to field, not just a to field that contains > > > > just some > > > > > > > > digits. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Christer Holmberg > > > > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > > > > To: Gonzalo Camarillo > > > > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP > > > network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that > > > > is what has > > > > > > > > > > > been proposed > > > > > > > > > > > earlier in this thread, so I assumed INFO would > > > > be used. The > > > > > > > > > > > reason for > > > > > > > > > > > the discussion from the beginning was that > > the overlap > > > > > > > > > > > signalling, > > > > > > > > > > > according to the SIP-ISUP mapping draft, > > may not work > > > > > > > > > very well, and > > > > > > > > > > a > > > > > > > > > > > solution using 18x responses and INFO messages, > > > > instead of 484 > > > > > > > > and > > > > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > > > > > > > Why are you using INFO for sending extra digits? > > > > > > > > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, > overlap > > > > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has > > > > been pretty much > > > > > > > > > > > about calls > > > > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW SIP SERVER > > > > > > > > SIP UAS > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > > > | <- 200 (INFO) | > > > > -- INVITE > > > > > > > > > > > > > --> > > > > > > > > > > > > > | <- 200 (INVITE)| > > > > <- 200 ------ > > > > > > > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I > > > > am not using > > > > > > > > > > > the word 'proxy') > > > > > > > > > > > > > must collect digits, sent from the PSTN > > side using > > > > > > > > > > > > > > overlap dialing, to > > > > > > > > > > > > > be able to find the SIP UAS, and INFO is > > > > used to provide > > > > > > > > > > > the digits > > > > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > > > > if you like) > > > > > > > > > > > be allowed to > > > > > > > > > > > > > behave like this, or MUST it send 486s, and > > > > receive new > > > > > > > > > > > INVITEs, until > > > > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Gonzalo Camarillo Phone : +358 > > 9 299 33 71 > > > > > > > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 > > 40 702 35 35 > > > > > > > > > > > > > > > Telecom R&D Fax : +358 > > 9 299 30 52 > > > > > > > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > > > > Finland > > http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > FIN-02420 Jorvas Email : > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > FIN-02420 Jorvas Email : > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > FIN-02420 Jorvas Email : > > Gonzalo.Camarillo@ericsson.com > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > _______________________________________________ > > > > > This list is for continuing development of the SIP protocol. > > > > > The sip-implementer's list is the place to discuss > > implementation, > > > > > > > > and to receive advice on understanding existing sip. > > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu > with > > > > > "subscribe sip-implementors" in the body. > > > > > > > > -- > > > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > > > Columbia University Mobile: +358 40 702 35 35 > > > > 472 Computer Science Building Fax : +358 9 299 30 52 > > > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > > > New York, NY 10027 > > > > USA Gonzalo.Camarillo@ericsson.com > > > > > > > > _______________________________________________ > > > > This list is for continuing development of the SIP protocol. > > > > The sip-implementer's list is the place to discuss > implementation, > > > > and to receive advice on understanding existing sip. > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > > "subscribe sip-implementors" in the body. > > > > > > --------------A010A01D19845E321E9039C9 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 --------------A010A01D19845E321E9039C9-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 19 03:09:16 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00159 for ; Mon, 19 Feb 2001 03:09:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D125744339; Mon, 19 Feb 2001 03:09:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id A52E244338 for ; Mon, 19 Feb 2001 03:08:31 -0500 (EST) 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 f1J88Td14388 for ; Mon, 19 Feb 2001 09:08:29 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id KAA23870 for ; Mon, 19 Feb 2001 10:08:23 +0200 (EET) Message-ID: <3A90D476.EF8D4FBD@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------F49030456C1F2AE626ADC9A1" Subject: [SIP] T.38 and multiple streams Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 19 Feb 2001 10:08:22 +0200 This is a multi-part message in MIME format. --------------F49030456C1F2AE626ADC9A1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a couple of questions about the t.38 call flow draft. I looked at the fax discussions in the archieve, but I could not find anything related to this. It is, however, related to SDP in general, so if it has been discussed I would be happy if someone could point me to the thread (and, hopefully, the solution :) 1. F11 INVITE IFTGW UA -> PROXY In this re-INVITE we add the fax stream to the call. However, t.38 for SIP recommendation it says that the existing voice stream should remain, so shouldn't the original voice parameters (m line etc) be included in the re-INVITE SDP? 2. This questions is depending on the first. Like I said, the recommendation says that the existing voice stream should remain, but that it should be muted during the fax transmission. The problem is that SDP uses the c line, which is for the WHOLE call (not a single stream), to mute stream(s), so I wonder if it will be possible to do this on a protocol level, or if it has to be in the implementation? Regards, Christer Holmberg Ericsson Finland --------------F49030456C1F2AE626ADC9A1 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 --------------F49030456C1F2AE626ADC9A1-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 19 03:37:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00383 for ; Mon, 19 Feb 2001 03:37:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8390844340; Mon, 19 Feb 2001 03:37:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from nt-mail.tlv.radvision.com (unknown [212.143.185.30]) by lists.bell-labs.com (Postfix) with ESMTP id 01F6644338 for ; Mon, 19 Feb 2001 03:36:50 -0500 (EST) Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Mon, 19 Feb 2001 10:39:38 +0200 Message-ID: From: Itamar Gilad To: "'Victor A Paulsamy'" , SIP Subject: RE: [SIP] What does m-line mean here? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 19 Feb 2001 10:39:37 +0200 My understanding of 'default' in this context is "I support all of the following payload types, but I prefer using the first one". Please comment if this is a wrong interpretation. Itamar > -----Original Message----- > From: Victor A Paulsamy [mailto:victor@voicecore.com] > Sent: Fri, February 16, 2001 5:56 PM > To: SIP > Cc: Victor A Paulsamy > Subject: [SIP] What does m-line mean here? > > > Hi, > > I'm having difficulty in understanding the following from > RFC2327, SDP. > > "When a list of payload formats is given, this implies > that all of > these formats may be used in the session, but the first of these > formats is the default format for the session." -- SDP > Standards Track, > page 20. > > What does default mean here? > > When a m-line reads as "m=audio 49230 RTP/AVP 3 4 5", does > this mean that > the remote UA will be requested to use GSM (PT 3) if it could > support it and > if it didn't support GSM, the local UA will negotiate for > G723 (PT 4) with > the remote UA and so on? (It's clear that I need to > understand the above > phrase!). > > Thanks for your help and valuable time. > > Regards, > > --victor > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 19 09:48:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04692 for ; Mon, 19 Feb 2001 09:48:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 91BD644338; Mon, 19 Feb 2001 09:48:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id 0768744336 for ; Mon, 19 Feb 2001 09:47:53 -0500 (EST) Received: from nwcwi1a.europe.nortel.com by qhars002.nortel.com; Mon, 19 Feb 2001 14:47:37 +0000 Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2650.21) id <16WQ1NFS>; Mon, 19 Feb 2001 14:47:35 -0000 Message-ID: From: "Mark Watson" To: sip@lists.bell-labs.com Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09A82.E5052700" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 19 Feb 2001 14:47:34 -0000 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_01C09A82.E5052700 Content-Type: text/plain; charset="iso-8859-1" Indeed. But to answer the original question, there is no requirement to encapsulate BICC in SIP - this does not make sense. BICC consists of two logical parts, (i) ISUP messages (which support the narrowband ISDN/PSTN service set) and (ii) Bearer Information (which controls the setup of the bearer connection across the ATM/IP network). SIP-T consists of three logical parts, (i) ISUP messages (ii) Bearer Information (in the form of SDP) and (iii) SIP headers (supporting integration with native SIP networks. Therefore SIP-T is already a superset of BICC. Encapsulating BICC inside SIP-T would just result in duplicating the Bearer Information. So, in the BICC-SIP-BICC case, the SIP messages will look just like the ISUP-SIP-ISUP ones. When you subtract the bearer information from a BICC message, you are essentially left with an ISUP one. In fact, for IP networks, BICC just about uses SDP to carry the Bearer Information, so it should interwork to SIP without *too* much difficulty (but don't quote me on that). Regards, Mark > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: 13 February 2001 09:35 > To: sip@lists.bell-labs.com > Subject: Re: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs > > > > Not to forget the cases where we encapsulate everything in morse code > and smoke signals - after all, SIP is newer than those > methods, so... :) > > Christer Holmberg > Ericsson Finlande > > Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Sent: Friday, February 02, 2001 9:28 AM > > > To: 'Jon.Peterson@Level3.com'; chsharp@cisco.com > > > Cc: sip@lists.bell-labs.com > > > Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs > > > > > > > > > > And is it just me, or is the idea that BICC will be > > > > encapsulated in SIP > > > > somewhat counterintuitive? Are there any services today that > > > > require that? > > > > Anyway, if there is interest I'd be inclined to say that BICC > > > > should have > > > > it's own MIME type which should be discussed on its own merits. > > > > > > So, SIP-T is used for, among other things, ISUP-SIP-ISUP. > > > You don't think anyone wants to do BICC-SIP-BICC when SIP is > > > one operator's > > > network, and the BICCs are two other operators? > > > > > > I also see BICC-SIP-ISUP and of course ISUP-BICC-SIP-ISUP and > > > variations. > > > > Seems prejudicial in favor of SIP catering to BICC. If we > do this, what > > about: > > > > SIP-BICC-SIP > > > > I think we should request the BICC guys to be able to > encapsulate SIP > > messages. After all, what about service transparency across > my SIP network! > > All these operators that are deploying SIP are doing so, in > part, because of > > the service possibilities. Shall I be forced to lose those > capabilities when > > I traverse an IP based BICC network? Why do the BICC guys > get to keep their > > services, and the SIP guys don't? After all, BICC is even > newer than SIP. > > > > Of course, once we do that, the more fun case is: > > > > ISUP-SIP-BICC-SIP-ISUP > > > > in which case the encapsulated SIP messages themselves contain ISUP > > messages, both of which are encapsulated in BICC. > > > > Of course, we should probably also consider the case of: > > > > SIP-ISUP-SIP > > > > Think about it; a SIP phone calls a PSTN number. It goes to > an ss7 gateway. > > Turns out, that this number is then forwarded to another > number, and that > > number is a VoIP terminal. So, it exits at another gateway, > and hits the > > terminal. I suppose we should also request the ISUP guys to > encapsulate SIP > > messages. > > > > Now then, we should also probably consider the case of: > > > > SIP-BICC-SIP-ISUP-SIP-BICC > > > > -Jonathan R. > > "reducio ad absurdum" > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > ------_=_NextPart_001_01C09A82.E5052700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs

Indeed. But to answer the original question, there is = no requirement to encapsulate BICC in SIP - this does not make = sense.

BICC consists of two logical parts, (i) ISUP messages = (which support the narrowband ISDN/PSTN service set) and (ii) Bearer = Information (which controls the setup of the bearer connection across = the ATM/IP network).

SIP-T consists of three logical parts, (i) ISUP = messages (ii) Bearer Information (in the form of SDP) and (iii) SIP = headers (supporting integration with native SIP networks.

Therefore SIP-T is already a superset of BICC. = Encapsulating BICC inside SIP-T would just result in duplicating the = Bearer Information. So, in the BICC-SIP-BICC case, the SIP messages = will look just like the ISUP-SIP-ISUP ones. When you subtract the = bearer information from a BICC message, you are essentially left with = an ISUP one.

In fact, for IP networks, BICC just about uses SDP to = carry the Bearer Information, so it should interwork to SIP without = *too* much difficulty (but don't quote me on that).

Regards,

Mark

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: 13 February 2001 09:35
> To: sip@lists.bell-labs.com
> Subject: Re: [SIP] Re: SIP digest, Vol 1 #750 - = 4 msgs
>
>
>
> Not to forget the cases where we encapsulate = everything in morse code
> and smoke signals - after all, SIP is newer = than those
> methods, so... :)
>
> Christer Holmberg
> Ericsson Finlande
>
> Jonathan Rosenberg wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > Sent: Friday, February 02, 2001 9:28 = AM
> > > To: 'Jon.Peterson@Level3.com'; = chsharp@cisco.com
> > > Cc: sip@lists.bell-labs.com
> > > Subject: RE: [SIP] Re: SIP digest, = Vol 1 #750 - 4 msgs
> > >
> > >
> > > > And is it just me, or is the = idea that BICC will be
> > > > encapsulated in SIP
> > > > somewhat counterintuitive? Are = there any services today that
> > > > require that?
> > > > Anyway, if there is interest I'd = be inclined to say that BICC
> > > > should have
> > > > it's own MIME type which should = be discussed on its own merits.
> > >
> > > So, SIP-T is used for, among other = things, ISUP-SIP-ISUP.
> > > You don't think anyone wants to do = BICC-SIP-BICC when SIP is
> > > one operator's
> > > network, and the BICCs are two other = operators?
> > >
> > > I also see BICC-SIP-ISUP and of = course ISUP-BICC-SIP-ISUP and
> > > variations.
> >
> > Seems prejudicial in favor of SIP catering = to BICC. If we
> do this, what
> > about:
> >
> > SIP-BICC-SIP
> >
> > I think we should request the BICC guys to = be able to
> encapsulate SIP
> > messages. After all, what about service = transparency across
> my SIP network!
> > All these operators that are deploying SIP = are doing so, in
> part, because of
> > the service possibilities. Shall I be = forced to lose those
> capabilities when
> > I traverse an IP based BICC network? Why = do the BICC guys
> get to keep their
> > services, and the SIP guys don't? After = all, BICC is even
> newer than SIP.
> >
> > Of course, once we do that, the more fun = case is:
> >
> > ISUP-SIP-BICC-SIP-ISUP
> >
> > in which case the encapsulated SIP = messages themselves contain ISUP
> > messages, both of which are encapsulated = in BICC.
> >
> > Of course, we should probably also = consider the case of:
> >
> > SIP-ISUP-SIP
> >
> > Think about it; a SIP phone calls a PSTN = number. It goes to
> an ss7 gateway.
> > Turns out, that this number is then = forwarded to another
> number, and that
> > number is a VoIP terminal. So, it exits at = another gateway,
> and hits the
> > terminal. I suppose we should also request = the ISUP guys to
> encapsulate SIP
> > messages.
> >
> > Now then, we should also probably consider = the case of:
> >
> > SIP-BICC-SIP-ISUP-SIP-BICC
> >
> > -Jonathan R.
> > "reducio ad absurdum"
> > ---
> > Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
> > Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> > = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> > = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen  &nb= sp;      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > = _______________________________________________
> > This list is for continuing development of = the SIP protocol.
> > The sip-implementer's list is the place to = discuss implementation,
> > and to receive advice on understanding = existing sip.
> > To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in = the body.
>

------_=_NextPart_001_01C09A82.E5052700-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 19 10:09:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05560 for ; Mon, 19 Feb 2001 10:09:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3621944349; Mon, 19 Feb 2001 10:09:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 8DB1344336 for ; Mon, 19 Feb 2001 10:08:00 -0500 (EST) 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 KAA11481; Mon, 19 Feb 2001 10:07:53 -0500 (EST) 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 KAA14959; Mon, 19 Feb 2001 10:07:53 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <1H2LSQ9L>; Mon, 19 Feb 2001 10:07:18 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EF65@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Mark Watson'" , sip@lists.bell-labs.com Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09A85.B20D7C50" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 19 Feb 2001 10:07:37 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C09A85.B20D7C50 Content-Type: text/plain; charset="iso-8859-1" It's all in the definitions. If I have two BICC systems, with a SIP system in the middle, I have several simple goals 1. I want the call to proceed (that is, I want it to work) 2. In support of #1, I want the BICC messages the enter the SIP system to be preserved across the sip message stream (which, btw, would include the new message BICC introduces, and the new IE that BICC introduces) 3. Also in support of #1, I want the bearer to work. Here I have two choices, depending on how I build my network. I could have gateways between the BICC networks and the SIP networks. In this case, there are 3 bearer segments, and thus the SIP network bearer is from the entry GW to the exit GW. This would be the case if there were a bearer change (ATM to IP for example). In these cases, the bearer descriptions change across the network boundaries. I could also have one big IP network, in which case the SIP network has to just carry the SDP from the originating network to the terminating network (and allow traffic in case of firewalls and NAT devices). So, what does that mean to the drafts? One is that the SIP-ISUP interwork document has to include the BICC messages and IEs that are not in base ISUP Another is that we need a document describing how the bearers work in the two cases above. The ISUP MIME type doesn't change, and the INFO method doesn't change. Brian -----Original Message----- From: Mark Watson [mailto:mwatson@nortelnetworks.com] Sent: Monday, February 19, 2001 9:48 AM To: sip@lists.bell-labs.com Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs Indeed. But to answer the original question, there is no requirement to encapsulate BICC in SIP - this does not make sense. BICC consists of two logical parts, (i) ISUP messages (which support the narrowband ISDN/PSTN service set) and (ii) Bearer Information (which controls the setup of the bearer connection across the ATM/IP network). SIP-T consists of three logical parts, (i) ISUP messages (ii) Bearer Information (in the form of SDP) and (iii) SIP headers (supporting integration with native SIP networks. Therefore SIP-T is already a superset of BICC. Encapsulating BICC inside SIP-T would just result in duplicating the Bearer Information. So, in the BICC-SIP-BICC case, the SIP messages will look just like the ISUP-SIP-ISUP ones. When you subtract the bearer information from a BICC message, you are essentially left with an ISUP one. In fact, for IP networks, BICC just about uses SDP to carry the Bearer Information, so it should interwork to SIP without *too* much difficulty (but don't quote me on that). Regards, Mark > -----Original Message----- > From: Christer Holmberg [ mailto:christer.holmberg@lmf.ericsson.se ] > Sent: 13 February 2001 09:35 > To: sip@lists.bell-labs.com > Subject: Re: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs > > > > Not to forget the cases where we encapsulate everything in morse code > and smoke signals - after all, SIP is newer than those > methods, so... :) > > Christer Holmberg > Ericsson Finlande > > Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com ] > > > Sent: Friday, February 02, 2001 9:28 AM > > > To: 'Jon.Peterson@Level3.com'; chsharp@cisco.com > > > Cc: sip@lists.bell-labs.com > > > Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs > > > > > > > > > > And is it just me, or is the idea that BICC will be > > > > encapsulated in SIP > > > > somewhat counterintuitive? Are there any services today that > > > > require that? > > > > Anyway, if there is interest I'd be inclined to say that BICC > > > > should have > > > > it's own MIME type which should be discussed on its own merits. > > > > > > So, SIP-T is used for, among other things, ISUP-SIP-ISUP. > > > You don't think anyone wants to do BICC-SIP-BICC when SIP is > > > one operator's > > > network, and the BICCs are two other operators? > > > > > > I also see BICC-SIP-ISUP and of course ISUP-BICC-SIP-ISUP and > > > variations. > > > > Seems prejudicial in favor of SIP catering to BICC. If we > do this, what > > about: > > > > SIP-BICC-SIP > > > > I think we should request the BICC guys to be able to > encapsulate SIP > > messages. After all, what about service transparency across > my SIP network! > > All these operators that are deploying SIP are doing so, in > part, because of > > the service possibilities. Shall I be forced to lose those > capabilities when > > I traverse an IP based BICC network? Why do the BICC guys > get to keep their > > services, and the SIP guys don't? After all, BICC is even > newer than SIP. > > > > Of course, once we do that, the more fun case is: > > > > ISUP-SIP-BICC-SIP-ISUP > > > > in which case the encapsulated SIP messages themselves contain ISUP > > messages, both of which are encapsulated in BICC. > > > > Of course, we should probably also consider the case of: > > > > SIP-ISUP-SIP > > > > Think about it; a SIP phone calls a PSTN number. It goes to > an ss7 gateway. > > Turns out, that this number is then forwarded to another > number, and that > > number is a VoIP terminal. So, it exits at another gateway, > and hits the > > terminal. I suppose we should also request the ISUP guys to > encapsulate SIP > > messages. > > > > Now then, we should also probably consider the case of: > > > > SIP-BICC-SIP-ISUP-SIP-BICC > > > > -Jonathan R. > > "reducio ad absurdum" > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > ------_=_NextPart_001_01C09A85.B20D7C50 Content-Type: text/html; charset="iso-8859-1" RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs
It's all in the definitions.
 
If I have two BICC systems, with a SIP system in the middle, I have several simple goals
    1.  I want the call to proceed (that is, I want it to work)
    2.  In support of #1, I want the BICC messages the enter the SIP system to be preserved across
            the sip message stream (which, btw, would include the new message BICC introduces,
            and the new IE that BICC introduces)
    3. Also in support of #1, I want the bearer to work.  Here I have two choices, depending on
            how I build my network.  I could have gateways between the BICC networks and the
            SIP networks.  In this case, there are 3 bearer segments, and thus the SIP network
            bearer is from the entry GW to the exit GW.  This would be the case if there were
            a bearer change (ATM to IP for example).  In these cases, the bearer descriptions
            change across the network boundaries.
 
            I could also have one big IP network, in which case the SIP network has to just carry
            the SDP from the originating network to the terminating network (and allow traffic
            in case of firewalls and NAT devices).
 
So, what does that mean to the drafts?
 
One is that the SIP-ISUP interwork document has to include the BICC messages and IEs
that are not in base ISUP
 
Another is that we need a document describing how the bearers work in the two cases
above. 
 
The ISUP MIME type doesn't change, and the INFO method doesn't change.
 
Brian
 
 
-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Monday, February 19, 2001 9:48 AM
To: sip@lists.bell-labs.com
Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs

Indeed. But to answer the original question, there is no requirement to encapsulate BICC in SIP - this does not make sense.

BICC consists of two logical parts, (i) ISUP messages (which support the narrowband ISDN/PSTN service set) and (ii) Bearer Information (which controls the setup of the bearer connection across the ATM/IP network).

SIP-T consists of three logical parts, (i) ISUP messages (ii) Bearer Information (in the form of SDP) and (iii) SIP headers (supporting integration with native SIP networks.

Therefore SIP-T is already a superset of BICC. Encapsulating BICC inside SIP-T would just result in duplicating the Bearer Information. So, in the BICC-SIP-BICC case, the SIP messages will look just like the ISUP-SIP-ISUP ones. When you subtract the bearer information from a BICC message, you are essentially left with an ISUP one.

In fact, for IP networks, BICC just about uses SDP to carry the Bearer Information, so it should interwork to SIP without *too* much difficulty (but don't quote me on that).

Regards,

Mark

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: 13 February 2001 09:35
> To: sip@lists.bell-labs.com
> Subject: Re: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs
>
>
>
> Not to forget the cases where we encapsulate everything in morse code
> and smoke signals - after all, SIP is newer than those
> methods, so... :)
>
> Christer Holmberg
> Ericsson Finlande
>
> Jonathan Rosenberg wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
> > > Sent: Friday, February 02, 2001 9:28 AM
> > > To: 'Jon.Peterson@Level3.com'; chsharp@cisco.com
> > > Cc: sip@lists.bell-labs.com
> > > Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs
> > >
> > >
> > > > And is it just me, or is the idea that BICC will be
> > > > encapsulated in SIP
> > > > somewhat counterintuitive? Are there any services today that
> > > > require that?
> > > > Anyway, if there is interest I'd be inclined to say that BICC
> > > > should have
> > > > it's own MIME type which should be discussed on its own merits.
> > >
> > > So, SIP-T is used for, among other things, ISUP-SIP-ISUP.
> > > You don't think anyone wants to do BICC-SIP-BICC when SIP is
> > > one operator's
> > > network, and the BICCs are two other operators?
> > >
> > > I also see BICC-SIP-ISUP and of course ISUP-BICC-SIP-ISUP and
> > > variations.
> >
> > Seems prejudicial in favor of SIP catering to BICC. If we
> do this, what
> > about:
> >
> > SIP-BICC-SIP
> >
> > I think we should request the BICC guys to be able to
> encapsulate SIP
> > messages. After all, what about service transparency across
> my SIP network!
> > All these operators that are deploying SIP are doing so, in
> part, because of
> > the service possibilities. Shall I be forced to lose those
> capabilities when
> > I traverse an IP based BICC network? Why do the BICC guys
> get to keep their
> > services, and the SIP guys don't? After all, BICC is even
> newer than SIP.
> >
> > Of course, once we do that, the more fun case is:
> >
> > ISUP-SIP-BICC-SIP-ISUP
> >
> > in which case the encapsulated SIP messages themselves contain ISUP
> > messages, both of which are encapsulated in BICC.
> >
> > Of course, we should probably also consider the case of:
> >
> > SIP-ISUP-SIP
> >
> > Think about it; a SIP phone calls a PSTN number. It goes to
> an ss7 gateway.
> > Turns out, that this number is then forwarded to another
> number, and that
> > number is a VoIP terminal. So, it exits at another gateway,
> and hits the
> > terminal. I suppose we should also request the ISUP guys to
> encapsulate SIP
> > messages.
> >
> > Now then, we should also probably consider the case of:
> >
> > SIP-BICC-SIP-ISUP-SIP-BICC
> >
> > -Jonathan R.
> > "reducio ad absurdum"
> > ---
> > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
>

------_=_NextPart_001_01C09A85.B20D7C50-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 19 11:06:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07658 for ; Mon, 19 Feb 2001 11:06:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A114644348; Mon, 19 Feb 2001 11:06:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 0CCD144336 for ; Mon, 19 Feb 2001 11:05:41 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id KAA14752; Mon, 19 Feb 2001 10:07:07 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Mon, 19 Feb 2001 10:02:56 -0600 Message-ID: From: "Culpepper, Bert" To: Christer Holmberg , sip@lists.bell-labs.com Subject: RE: [SIP] T.38 and multiple streams MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 19 Feb 2001 10:02:54 -0600 My interpretation of the message flow (message contents) in the I-D is that the egress gateway is replacing the audio stream with a T.38 stream since the original m= line and parameters are replaced with t.38 data. I guess this effectively mutes the audio session :) If the egress gateway wanted to mute the audio using the method defined in the SIP RFC, it would have included both media descriptions and an additional c= line for one of media descriptions. By having a c= line in the T.38 media description, the egress gateway could place the audio on hold (using IP address of 0.0.0.0 in the main session description) and still have the T.38 session. SDP (RFC 2327) allows c= lines in media descriptions (that only apply to the one media stream) which override c= lines in the main session description. A possibly more explicit session description would not have a c= line in the general session description and c= lines in each media description. So RFC 2327 allows placing the audio on hold while the T.38 is active at the protocol level. regards, Bert > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Monday, February 19, 2001 3:08 AM > To: sip@lists.bell-labs.com > Subject: [SIP] T.38 and multiple streams > > > > Hi, > > I have a couple of questions about the t.38 call flow draft. > I looked at > the fax discussions in the archieve, but I could not find anything > related to this. It is, however, related to SDP in general, > so if it has > been discussed I would be happy if someone could point me to > the thread > (and, hopefully, the solution :) > > 1. F11 INVITE IFTGW UA -> PROXY > > In this re-INVITE we add the fax stream to the call. However, t.38 for > SIP recommendation it says that the existing voice stream > should remain, > so shouldn't the original voice parameters (m line etc) be included in > the re-INVITE SDP? > > 2. This questions is depending on the first. > > Like I said, the recommendation says that the existing voice stream > should remain, but that it should be muted during the fax > transmission. > The problem is that SDP uses the c line, which is for the WHOLE call > (not a single stream), to mute stream(s), so I wonder if it will be > possible to do this on a protocol level, or if it has to be in the > implementation? > > > Regards, > > Christer Holmberg > Ericsson Finland > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 19 12:01:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09148 for ; Mon, 19 Feb 2001 12:01:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DD2C444358; Mon, 19 Feb 2001 12:01:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 6068244336 for ; Mon, 19 Feb 2001 12:00:27 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA20425; Mon, 19 Feb 2001 08:59:05 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f1JGwn501890; Mon, 19 Feb 2001 08:58:49 -0800 (PST) Received: from chsharp-w2k.cisco.com ([10.21.54.3]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id IAA18644; Mon, 19 Feb 2001 08:58:46 -0800 (PST) Message-Id: <4.3.2.7.2.20010219114315.038d1ca0@dogwood.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Mark Watson" From: Chip Sharp Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs Cc: sip@lists.bell-labs.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 19 Feb 2001 11:58:37 -0500 At 09:47 AM 2/19/2001, Mark Watson wrote: >Indeed. But to answer the original question, there is no requirement to >encapsulate BICC in SIP - this does not make sense. > >BICC consists of two logical parts, (i) ISUP messages (which support the >narrowband ISDN/PSTN service set) and (ii) Bearer Information (which >controls the setup of the bearer connection across the ATM/IP network). True, and item (ii) should at least allow use of existing SIP or SDP. And I believe the ISUP is slightly modified in BICC so it isn't exactly ISUP as used over SS7. >SIP-T consists of three logical parts, (i) ISUP messages (ii) Bearer >Information (in the form of SDP) and (iii) SIP headers (supporting >integration with native SIP networks. I believe there is bearer information in the ISUP message carried by SIP-T as well. It may just not apply to the IP network. >Therefore SIP-T is already a superset of BICC. Encapsulating BICC inside >SIP-T would just result in duplicating the Bearer Information. So, in the >BICC-SIP-BICC case, the SIP messages will look just like the ISUP-SIP-ISUP >ones. When you subtract the bearer information from a BICC message, you >are essentially left with an ISUP one. > >In fact, for IP networks, BICC just about uses SDP to carry the Bearer >Information, so it should interwork to SIP without *too* much difficulty >(but don't quote me on that). Except "just about uses" isn't the same as "uses". Instead of using SIP or SDP (or even H.323), SG11 has invented a new protocol by adding request/response semantics into the SDP "a = " line and calling it the "IP Bearer Control Protocol." This in addition to modifying H.248/Megaco to fit into their "architecture." >Regards, > >Mark > > > -----Original Message----- > > From: Christer Holmberg > [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: 13 February 2001 09:35 > > To: sip@lists.bell-labs.com > > Subject: Re: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs > > > > > > > > Not to forget the cases where we encapsulate everything in morse code > > and smoke signals - after all, SIP is newer than those > > methods, so... :) > > > > Christer Holmberg > > Ericsson Finlande > > > > Jonathan Rosenberg wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian > [mailto:Brian.Rosen@marconi.com] > > > > Sent: Friday, February 02, 2001 9:28 AM > > > > To: 'Jon.Peterson@Level3.com'; chsharp@cisco.com > > > > Cc: sip@lists.bell-labs.com > > > > Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs > > > > > > > > > > > > > And is it just me, or is the idea that BICC will be > > > > > encapsulated in SIP > > > > > somewhat counterintuitive? Are there any services today that > > > > > require that? > > > > > Anyway, if there is interest I'd be inclined to say that BICC > > > > > should have > > > > > it's own MIME type which should be discussed on its own merits. > > > > > > > > So, SIP-T is used for, among other things, ISUP-SIP-ISUP. > > > > You don't think anyone wants to do BICC-SIP-BICC when SIP is > > > > one operator's > > > > network, and the BICCs are two other operators? > > > > > > > > I also see BICC-SIP-ISUP and of course ISUP-BICC-SIP-ISUP and > > > > variations. > > > > > > Seems prejudicial in favor of SIP catering to BICC. If we > > do this, what > > > about: > > > > > > SIP-BICC-SIP > > > > > > I think we should request the BICC guys to be able to > > encapsulate SIP > > > messages. After all, what about service transparency across > > my SIP network! > > > All these operators that are deploying SIP are doing so, in > > part, because of > > > the service possibilities. Shall I be forced to lose those > > capabilities when > > > I traverse an IP based BICC network? Why do the BICC guys > > get to keep their > > > services, and the SIP guys don't? After all, BICC is even > > newer than SIP. > > > > > > Of course, once we do that, the more fun case is: > > > > > > ISUP-SIP-BICC-SIP-ISUP > > > > > > in which case the encapsulated SIP messages themselves contain ISUP > > > messages, both of which are encapsulated in BICC. > > > > > > Of course, we should probably also consider the case of: > > > > > > SIP-ISUP-SIP > > > > > > Think about it; a SIP phone calls a PSTN number. It goes to > > an ss7 gateway. > > > Turns out, that this number is then forwarded to another > > number, and that > > > number is a VoIP terminal. So, it exits at another gateway, > > and hits the > > > terminal. I suppose we should also request the ISUP guys to > > encapsulate SIP > > > messages. > > > > > > Now then, we should also probably consider the case of: > > > > > > SIP-BICC-SIP-ISUP-SIP-BICC > > > > > > -Jonathan R. > > > "reducio ad absurdum" > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen > PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems ------------------------------------------------------------------- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 19 15:03:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13458 for ; Mon, 19 Feb 2001 15:03:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 65BE84433B; Mon, 19 Feb 2001 15:03:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 4249B44336 for ; Mon, 19 Feb 2001 15:02:19 -0500 (EST) 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 f1JK2GC25502; Mon, 19 Feb 2001 21:02:16 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id WAA00030; Mon, 19 Feb 2001 22:02:13 +0200 (EET) Message-ID: <3A917BC8.6CC674C1@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] T.38 and multiple streams References: Content-Type: multipart/mixed; boundary="------------EB6CDC5EEE5672A77992E285" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 19 Feb 2001 22:02:16 +0200 This is a multi-part message in MIME format. --------------EB6CDC5EEE5672A77992E285 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >My interpretation of the message flow (message contents) in the I-D is that >the egress gateway is replacing the audio stream with a T.38 stream since >the original m= line and parameters are replaced with t.38 data. I guess >this effectively mutes the audio session :) Yes, that is true. The recommendation, however, says that the fax stream should be ADDED to the connection, not REPLACE the voice stream. >If the egress gateway wanted to mute the audio using the method defined in >the SIP RFC, it would have included both media descriptions and an >additional c= line for one of media descriptions. By having a c= line in >the T.38 media description, the egress gateway could place the audio on hold >(using IP address of 0.0.0.0 in the main session description) and still have >the T.38 session. SDP (RFC 2327) allows c= lines in media descriptions >(that only apply to the one media stream) which override c= lines in the >main session description. A possibly more explicit session description >would not have a c= line in the general session description and c= lines in >each media description. > >So RFC 2327 allows placing the audio on hold while the T.38 is active at the >protocol level. It was my understanding from the T.38 on IP recommendation that this is the way it should work. We should add the fax stream, and mute the voice stream instead of removing it, ie using a separate c= lines for each media stream. I don't want to free resources I've used for the voice when transmitting the fax, since I will probably need them if I switch back from fax to voice. Regards, Christer Holmberg Ericsson Finland > > regards, > Bert > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Monday, February 19, 2001 3:08 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] T.38 and multiple streams > > > > > > > > Hi, > > > > I have a couple of questions about the t.38 call flow draft. > > I looked at > > the fax discussions in the archieve, but I could not find anything > > related to this. It is, however, related to SDP in general, > > so if it has > > been discussed I would be happy if someone could point me to > > the thread > > (and, hopefully, the solution :) > > > > 1. F11 INVITE IFTGW UA -> PROXY > > > > In this re-INVITE we add the fax stream to the call. However, t.38 for > > SIP recommendation it says that the existing voice stream > > should remain, > > so shouldn't the original voice parameters (m line etc) be included in > > the re-INVITE SDP? > > > > 2. This questions is depending on the first. > > > > Like I said, the recommendation says that the existing voice stream > > should remain, but that it should be muted during the fax > > transmission. > > The problem is that SDP uses the c line, which is for the WHOLE call > > (not a single stream), to mute stream(s), so I wonder if it will be > > possible to do this on a protocol level, or if it has to be in the > > implementation? > > > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > --------------EB6CDC5EEE5672A77992E285 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 --------------EB6CDC5EEE5672A77992E285-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 19 17:03:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15923 for ; Mon, 19 Feb 2001 17:03:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1FE9744353; Mon, 19 Feb 2001 17:03:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id AD75E44336 for ; Mon, 19 Feb 2001 17:02:27 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id QAA00904; Mon, 19 Feb 2001 16:04:27 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Mon, 19 Feb 2001 16:00:19 -0600 Message-ID: From: "Culpepper, Bert" To: Christer Holmberg Cc: sip@lists.bell-labs.com, jfm@clarent.com, stanley.khouw@clarent.com, jieying@clarent.com Subject: RE: [SIP] T.38 and multiple streams MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 19 Feb 2001 16:00:12 -0600 Hello Christer, I see the authors of the I-D do mention using two m= lines in section 6.2, but in the context of UDP port usage by a gateway. But, as you point out, their message contents in section 4.3 do not agree with their recommendation in section 4.1 to mute the audio stream. I too would not release audio resources if they might be needed once the fax stream ends. I guess we as application developers need to decide if we want the protocol to indicate what media support is needed for a session whether or not a particular media stream is constant. Or do we leave it up to the implementation to support the capability to restore audio without indication in the protocol. Being that the I-D promotes itself as a BCP, I would argue that the session as described is a multi (two) media session so both media descriptions should be present throughout the message exchange. Or leave the audio media description and add the fax media description in the reINVITE sent by the egress gateway. Although I can see a PSTN gateway not knowing in advance that a fax will be sent so adding the fax media description seems to be the best approach in this scenario. Anyway, I've copied the authors so they can comment if they desire. Regards, Bert > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Monday, February 19, 2001 3:02 PM > To: Culpepper, Bert > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] T.38 and multiple streams > > > > Hi, > > >My interpretation of the message flow (message contents) in the I-D is that > >the egress gateway is replacing the audio stream with a T.38 stream since > >the original m= line and parameters are replaced with t.38 data. I guess > >this effectively mutes the audio session :) > > Yes, that is true. The recommendation, however, says that the > fax stream > should be ADDED to the connection, not REPLACE the voice stream. > > >If the egress gateway wanted to mute the audio using the method defined in > >the SIP RFC, it would have included both media descriptions and an > >additional c= line for one of media descriptions. By having a c= line in > >the T.38 media description, the egress gateway could place the audio on hold > >(using IP address of 0.0.0.0 in the main session description) and still have > >the T.38 session. SDP (RFC 2327) allows c= lines in media descriptions > >(that only apply to the one media stream) which override c= lines in the > >main session description. A possibly more explicit session description > >would not have a c= line in the general session description and c= lines in > >each media description. > > > >So RFC 2327 allows placing the audio on hold while the T.38 is active at the > >protocol level. > > It was my understanding from the T.38 on IP recommendation > that this is > the way it should work. We should add the fax stream, and > mute the voice > stream instead of removing it, ie using a separate c= lines for each > media stream. I don't want to free resources I've used for the voice > when transmitting the fax, since I will probably need them if I switch > back from fax to voice. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > regards, > > Bert > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: Monday, February 19, 2001 3:08 AM > > > To: sip@lists.bell-labs.com > > > Subject: [SIP] T.38 and multiple streams > > > > > > > > > > > > Hi, > > > > > > I have a couple of questions about the t.38 call flow draft. > > > I looked at > > > the fax discussions in the archieve, but I could not find anything > > > related to this. It is, however, related to SDP in general, > > > so if it has > > > been discussed I would be happy if someone could point me to > > > the thread > > > (and, hopefully, the solution :) > > > > > > 1. F11 INVITE IFTGW UA -> PROXY > > > > > > In this re-INVITE we add the fax stream to the call. However, t.38 for > > > SIP recommendation it says that the existing voice stream > > > should remain, > > > so shouldn't the original voice parameters (m line etc) be included in > > > the re-INVITE SDP? > > > > > > 2. This questions is depending on the first. > > > > > > Like I said, the recommendation says that the existing voice stream > > > should remain, but that it should be muted during the fax > > > transmission. > > > The problem is that SDP uses the c line, which is for the WHOLE call > > > (not a single stream), to mute stream(s), so I wonder if it will be > > > possible to do this on a protocol level, or if it has to be in the > > > implementation? > > > > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 19 22:56:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23260 for ; Mon, 19 Feb 2001 22:56:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5C2B14435D; Mon, 19 Feb 2001 22:56:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id 8C1D24435A for ; Mon, 19 Feb 2001 22:55:27 -0500 (EST) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G910070BEWB92@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 20 Feb 2001 03:55:23 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G9100J01EW9HK@dgismtp03.wcomnet.com>; Tue, 20 Feb 2001 03:55:22 +0000 (GMT) Received: from hsinnreich ([166.44.137.15]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G9100GMIEVYJL@dgismtp03.wcomnet.com>; Tue, 20 Feb 2001 03:55:14 +0000 (GMT) From: Henry Sinnreich Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs In-reply-to: <4.3.2.7.2.20010219114315.038d1ca0@dogwood.cisco.com> To: Chip Sharp , Mark Watson Cc: sip@lists.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 19 Feb 2001 21:55:10 -0600 Content-Transfer-Encoding: 7bit >SG11 has invented a new protocol by adding >This in addition to modifying H.248/Megaco to fit into their "architecture." Every new protocol costs a lot of money to introduce in the network and needs a solid business case, such as new revenue that would not be possible otherwise. Just my usual skeptical outlook on reincarnations of SS7 and device control protocols... Henry -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Chip Sharp Sent: Monday, February 19, 2001 10:59 AM To: Mark Watson Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs At 09:47 AM 2/19/2001, Mark Watson wrote: >Indeed. But to answer the original question, there is no requirement to >encapsulate BICC in SIP - this does not make sense. > >BICC consists of two logical parts, (i) ISUP messages (which support the >narrowband ISDN/PSTN service set) and (ii) Bearer Information (which >controls the setup of the bearer connection across the ATM/IP network). True, and item (ii) should at least allow use of existing SIP or SDP. And I believe the ISUP is slightly modified in BICC so it isn't exactly ISUP as used over SS7. >SIP-T consists of three logical parts, (i) ISUP messages (ii) Bearer >Information (in the form of SDP) and (iii) SIP headers (supporting >integration with native SIP networks. I believe there is bearer information in the ISUP message carried by SIP-T as well. It may just not apply to the IP network. >Therefore SIP-T is already a superset of BICC. Encapsulating BICC inside >SIP-T would just result in duplicating the Bearer Information. So, in the >BICC-SIP-BICC case, the SIP messages will look just like the ISUP-SIP-ISUP >ones. When you subtract the bearer information from a BICC message, you >are essentially left with an ISUP one. > >In fact, for IP networks, BICC just about uses SDP to carry the Bearer >Information, so it should interwork to SIP without *too* much difficulty >(but don't quote me on that). Except "just about uses" isn't the same as "uses". Instead of using SIP or SDP (or even H.323), SG11 has invented a new protocol by adding request/response semantics into the SDP "a = " line and calling it the "IP Bearer Control Protocol." This in addition to modifying H.248/Megaco to fit into their "architecture." >Regards, > >Mark > > > -----Original Message----- > > From: Christer Holmberg > [mailto:christer.holmberg@lmf.eric sson.se] > > > Sent: 13 February 2001 09:35 > > To: sip@lists.bell-labs.com > > Subject: Re: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs > > > > > > > > Not to forget the cases where we encapsulate everything in morse code > > and smoke signals - after all, SIP is newer than those > > methods, so... :) > > > > Christer Holmberg > > Ericsson Finlande > > > > Jonathan Rosenberg wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian > [mailto:Brian.Rosen@marconi.com] > > > > Sent: Friday, February 02, 2001 9:28 AM > > > > To: 'Jon.Peterson@Level3.com'; chsharp@cisco.com > > > > Cc: sip@lists.bell-labs.com > > > > Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs > > > > > > > > > > > > > And is it just me, or is the idea that BICC will be > > > > > encapsulated in SIP > > > > > somewhat counterintuitive? Are there any services today that > > > > > require that? > > > > > Anyway, if there is interest I'd be inclined to say that BICC > > > > > should have > > > > > it's own MIME type which should be discussed on its own merits. > > > > > > > > So, SIP-T is used for, among other things, ISUP-SIP-ISUP. > > > > You don't think anyone wants to do BICC-SIP-BICC when SIP is > > > > one operator's > > > > network, and the BICCs are two other operators? > > > > > > > > I also see BICC-SIP-ISUP and of course ISUP-BICC-SIP-ISUP and > > > > variations. > > > > > > Seems prejudicial in favor of SIP catering to BICC. If we > > do this, what > > > about: > > > > > > SIP-BICC-SIP > > > > > > I think we should request the BICC guys to be able to > > encapsulate SIP > > > messages. After all, what about service transparency across > > my SIP network! > > > All these operators that are deploying SIP are doing so, in > > part, because of > > > the service possibilities. Shall I be forced to lose those > > capabilities when > > > I traverse an IP based BICC network? Why do the BICC guys > > get to keep their > > > services, and the SIP guys don't? After all, BICC is even > > newer than SIP. > > > > > > Of course, once we do that, the more fun case is: > > > > > > ISUP-SIP-BICC-SIP-ISUP > > > > > > in which case the encapsulated SIP messages themselves contain ISUP > > > messages, both of which are encapsulated in BICC. > > > > > > Of course, we should probably also consider the case of: > > > > > > SIP-ISUP-SIP > > > > > > Think about it; a SIP phone calls a PSTN number. It goes to > > an ss7 gateway. > > > Turns out, that this number is then forwarded to another > > number, and that > > > number is a VoIP terminal. So, it exits at another gateway, > > and hits the > > > terminal. I suppose we should also request the ISUP guys to > > encapsulate SIP > > > messages. > > > > > > Now then, we should also probably consider the case of: > > > > > > SIP-BICC-SIP-ISUP-SIP-BICC > > > > > > -Jonathan R. > > > "reducio ad absurdum" > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen > PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems ------------------------------------------------------------------- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Mon Feb 19 23:33:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23798 for ; Mon, 19 Feb 2001 23:33:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6F15A44365; Mon, 19 Feb 2001 23:33:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by lists.bell-labs.com (Postfix) with ESMTP id 70F8C4435A; Mon, 19 Feb 2001 23:32:41 -0500 (EST) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id PAA17439; Tue, 20 Feb 2001 15:32:39 +1100 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdT7TG0_; Tue Feb 20 15:32:06 2001 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id PAA01827; Tue, 20 Feb 2001 15:32:04 +1100 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0H0gxt; Tue Feb 20 15:31:12 2001 Received: from vus069.trl.telstra.com.au (vus069.trl.telstra.com.au [137.147.113.20]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA07828; Tue, 20 Feb 2001 15:31:11 +1100 (EST) Received: from castor.trl.telstra.com.au (castor.trl.telstra.com.au [137.147.111.61]) by vus069.trl.telstra.com.au (8.9.3+Sun/8.9.1) with ESMTP id PAA06843; Tue, 20 Feb 2001 15:30:53 +1100 (EST) Received: by castor.trl.telstra.com.au (Postfix, from userid 439) id B762F75E01; Tue, 20 Feb 2001 15:31:09 +1100 (EST) To: sip@lists.bell-labs.com Cc: c603273@trl.telstra.com.au, sip-admin@lists.bell-labs.com Message-Id: <20010220043109.B762F75E01@castor.trl.telstra.com.au> From: c603273@vus069.trl.telstra.com.au (Brian Keck) Subject: [SIP] error in mailing list footer Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 20 Feb 2001 15:31:09 +1100 (EST) Sorry if I've aimed this badly ... On Thu, 15 Feb 2001 14:59:58 CDT, Jonathan Rosenberg wrote: ... >This list is for continuing development of the SIP protocol. >The sip-implementer's list is the place to discuss implementation, >and to receive advice on understanding existing sip. >To subscribe to it, send mail to majordomo@cs.columbia.edu with >"subscribe sip-implementors" in the body. That majordomo hasn't heard of any sip* list Brian Keck _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 20 04:06:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09130 for ; Tue, 20 Feb 2001 04:06:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5BE3944359; Tue, 20 Feb 2001 04:06:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 6FE2F44352 for ; Tue, 20 Feb 2001 04:05:01 -0500 (EST) 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 f1K94qC02501; Tue, 20 Feb 2001 10:04:53 +0100 (MET) Received: from lmf.ericsson.se ([131.160.30.201]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA28319; Tue, 20 Feb 2001 11:04:49 +0200 (EET) Message-ID: <3A92332F.B6AAE34@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: sip@lists.bell-labs.com, jfm@clarent.com, stanley.khouw@clarent.com, jieying@clarent.com Subject: Re: [SIP] T.38 and multiple streams References: Content-Type: multipart/mixed; boundary="------------17D5983ADD3A08E04D8C12B4" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 20 Feb 2001 11:04:47 +0200 This is a multi-part message in MIME format. --------------17D5983ADD3A08E04D8C12B4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Thanks for your comments! I agree that there sure will raise a number of implementation issues later, but first I would like to get the recommendation and the call flows to "fit" each other :) Regards, Christer Holmberg Ericsson Finland "Culpepper, Bert" wrote: > > Hello Christer, > > I see the authors of the I-D do mention using two m= lines in section 6.2, > but in the context of UDP port usage by a gateway. But, as you point out, > their message contents in section 4.3 do not agree with their recommendation > in section 4.1 to mute the audio stream. > > I too would not release audio resources if they might be needed once the fax > stream ends. I guess we as application developers need to decide if we want > the protocol to indicate what media support is needed for a session whether > or not a particular media stream is constant. Or do we leave it up to the > implementation to support the capability to restore audio without indication > in the protocol. Being that the I-D promotes itself as a BCP, I would argue > that the session as described is a multi (two) media session so both media > descriptions should be present throughout the message exchange. Or leave > the audio media description and add the fax media description in the > reINVITE sent by the egress gateway. Although I can see a PSTN gateway not > knowing in advance that a fax will be sent so adding the fax media > description seems to be the best approach in this scenario. > > Anyway, I've copied the authors so they can comment if they desire. > > Regards, > Bert > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Monday, February 19, 2001 3:02 PM > > To: Culpepper, Bert > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] T.38 and multiple streams > > > > > > > > Hi, > > > > >My interpretation of the message flow (message contents) in the I-D is > that > > >the egress gateway is replacing the audio stream with a T.38 stream since > > >the original m= line and parameters are replaced with t.38 data. I guess > > >this effectively mutes the audio session :) > > > > Yes, that is true. The recommendation, however, says that the > > fax stream > > should be ADDED to the connection, not REPLACE the voice stream. > > > > >If the egress gateway wanted to mute the audio using the method defined > in > > >the SIP RFC, it would have included both media descriptions and an > > >additional c= line for one of media descriptions. By having a c= line in > > >the T.38 media description, the egress gateway could place the audio on > hold > > >(using IP address of 0.0.0.0 in the main session description) and still > have > > >the T.38 session. SDP (RFC 2327) allows c= lines in media descriptions > > >(that only apply to the one media stream) which override c= lines in the > > >main session description. A possibly more explicit session description > > >would not have a c= line in the general session description and c= lines > in > > >each media description. > > > > > >So RFC 2327 allows placing the audio on hold while the T.38 is active at > the > > >protocol level. > > > > It was my understanding from the T.38 on IP recommendation > > that this is > > the way it should work. We should add the fax stream, and > > mute the voice > > stream instead of removing it, ie using a separate c= lines for each > > media stream. I don't want to free resources I've used for the voice > > when transmitting the fax, since I will probably need them if I switch > > back from fax to voice. > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > > > regards, > > > Bert > > > > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > > Sent: Monday, February 19, 2001 3:08 AM > > > > To: sip@lists.bell-labs.com > > > > Subject: [SIP] T.38 and multiple streams > > > > > > > > > > > > > > > > Hi, > > > > > > > > I have a couple of questions about the t.38 call flow draft. > > > > I looked at > > > > the fax discussions in the archieve, but I could not find anything > > > > related to this. It is, however, related to SDP in general, > > > > so if it has > > > > been discussed I would be happy if someone could point me to > > > > the thread > > > > (and, hopefully, the solution :) > > > > > > > > 1. F11 INVITE IFTGW UA -> PROXY > > > > > > > > In this re-INVITE we add the fax stream to the call. However, t.38 > for > > > > SIP recommendation it says that the existing voice stream > > > > should remain, > > > > so shouldn't the original voice parameters (m line etc) be included in > > > > the re-INVITE SDP? > > > > > > > > 2. This questions is depending on the first. > > > > > > > > Like I said, the recommendation says that the existing voice stream > > > > should remain, but that it should be muted during the fax > > > > transmission. > > > > The problem is that SDP uses the c line, which is for the WHOLE call > > > > (not a single stream), to mute stream(s), so I wonder if it will be > > > > possible to do this on a protocol level, or if it has to be in the > > > > implementation? > > > > > > > > > > > > Regards, > > > > > > > > Christer Holmberg > > > > Ericsson Finland > > > > > > --------------17D5983ADD3A08E04D8C12B4 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 --------------17D5983ADD3A08E04D8C12B4-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 20 09:09:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12251 for ; Tue, 20 Feb 2001 09:09:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5A15444368; Tue, 20 Feb 2001 09:09:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id 6082644352 for ; Tue, 20 Feb 2001 09:08:26 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qhars002.nortel.com; Tue, 20 Feb 2001 14:07:55 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <102DBH55>; Tue, 20 Feb 2001 14:07:54 -0000 Message-ID: From: "Mark Watson" To: Chip Sharp Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09B46.833DB810" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 20 Feb 2001 14:07:51 -0000 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_01C09B46.833DB810 Content-Type: text/plain; charset="iso-8859-1" Chip, > > > >In fact, for IP networks, BICC just about uses SDP to carry > the Bearer > >Information, so it should interwork to SIP without *too* > much difficulty > >(but don't quote me on that). > > Except "just about uses" isn't the same as "uses". I know - I chose my words carefully :-) > Instead > of using SIP or > SDP (or even H.323), SG11 has invented a new protocol by adding > request/response semantics into the SDP "a = " line and > calling it the "IP > Bearer Control Protocol." Oh yes. This is because SG11 believe in 'call/bearer separation' i.e. that the setup of the bearer should be an autonomous process between Media Gateways which operates independently of the Call Control layer. Kludging SDP to do this, is, IMO, preferable to inventing something completely new or using H.245. In SIP, the semantics of the carried SDP are implicit in the messaging carrying the SDP. > This in addition to modifying H.248/Megaco to fit into their > "architecture." Indeed. We (Nortel) have been trying to prevent this, but there are those within SG11 who insist that the interface being addressed is fundamentally different from H.248/Megaco. Personally I am not convinced by this - the deviations from H.248 are more to do with starting out with an ATM-specific overall solution in BICC CS1. Broadly, H.248/Megaco can functionally do everything which the new Q.1950 can do, though there are some generic packages defined in Q.1950 which have wider application. To achieve the SG11 architectural aims with standard H.248 would mean basing transport of all bearer information in BICC on SDP - which is not how BICC CS1 works. But anyway... > > > >Regards, > > > >Mark > > > > > -----Original Message----- > > > From: Christer Holmberg > > > [mailto:christer.hol > mberg@lmf.ericsson.se] > > > > > Sent: 13 February 2001 09:35 > > > To: sip@lists.bell-labs.com > > > Subject: Re: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs > > > > > > > > > > > > Not to forget the cases where we encapsulate everything > in morse code > > > and smoke signals - after all, SIP is newer than those > > > methods, so... :) > > > > > > Christer Holmberg > > > Ericsson Finlande > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian > > [mailto:Brian.Rosen@marconi.com] > > > > > Sent: Friday, February 02, 2001 9:28 AM > > > > > To: 'Jon.Peterson@Level3.com'; chsharp@cisco.com > > > > > Cc: sip@lists.bell-labs.com > > > > > Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs > > > > > > > > > > > > > > > > And is it just me, or is the idea that BICC will be > > > > > > encapsulated in SIP > > > > > > somewhat counterintuitive? Are there any services today that > > > > > > require that? > > > > > > Anyway, if there is interest I'd be inclined to say > that BICC > > > > > > should have > > > > > > it's own MIME type which should be discussed on its > own merits. > > > > > > > > > > So, SIP-T is used for, among other things, ISUP-SIP-ISUP. > > > > > You don't think anyone wants to do BICC-SIP-BICC when SIP is > > > > > one operator's > > > > > network, and the BICCs are two other operators? > > > > > > > > > > I also see BICC-SIP-ISUP and of course ISUP-BICC-SIP-ISUP and > > > > > variations. > > > > > > > > Seems prejudicial in favor of SIP catering to BICC. If we > > > do this, what > > > > about: > > > > > > > > SIP-BICC-SIP > > > > > > > > I think we should request the BICC guys to be able to > > > encapsulate SIP > > > > messages. After all, what about service transparency across > > > my SIP network! > > > > All these operators that are deploying SIP are doing so, in > > > part, because of > > > > the service possibilities. Shall I be forced to lose those > > > capabilities when > > > > I traverse an IP based BICC network? Why do the BICC guys > > > get to keep their > > > > services, and the SIP guys don't? After all, BICC is even > > > newer than SIP. > > > > > > > > Of course, once we do that, the more fun case is: > > > > > > > > ISUP-SIP-BICC-SIP-ISUP > > > > > > > > in which case the encapsulated SIP messages themselves > contain ISUP > > > > messages, both of which are encapsulated in BICC. > > > > > > > > Of course, we should probably also consider the case of: > > > > > > > > SIP-ISUP-SIP > > > > > > > > Think about it; a SIP phone calls a PSTN number. It goes to > > > an ss7 gateway. > > > > Turns out, that this number is then forwarded to another > > > number, and that > > > > number is a VoIP terminal. So, it exits at another gateway, > > > and hits the > > > > terminal. I suppose we should also request the ISUP guys to > > > encapsulate SIP > > > > messages. > > > > > > > > Now then, we should also probably consider the case of: > > > > > > > > SIP-BICC-SIP-ISUP-SIP-BICC > > > > > > > > -Jonathan R. > > > > "reducio ad absurdum" > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East > Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > > > > > > > http://www.cs.columbia.ed u/~jdrosen > PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementer's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > > "subscribe sip-implementors" in the body. > > ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems ------------------------------------------------------------------- ------_=_NextPart_001_01C09B46.833DB810 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs

Chip,

> >
> >In fact, for IP networks, BICC just about = uses SDP to carry
> the Bearer
> >Information, so it should interwork to SIP = without *too*
> much difficulty
> >(but don't quote me on that).
>
> Except "just about uses" isn't the = same as "uses".

I know - I chose my words carefully :-)

> Instead
> of using SIP or
> SDP (or even H.323), SG11 has invented a new = protocol by adding
> request/response semantics into the SDP "a = =3D " line and
> calling it the "IP
> Bearer Control Protocol."

Oh yes. This is because SG11 believe in 'call/bearer = separation' i.e. that the setup of the bearer should be an autonomous = process between Media Gateways which operates independently of the Call = Control layer. Kludging SDP to do this, is, IMO, preferable to = inventing something completely new or using H.245.

In SIP, the semantics of the carried SDP are implicit = in the messaging carrying the SDP.


> This in addition to modifying H.248/Megaco to = fit into their
> "architecture."

Indeed. We (Nortel) have been trying to prevent this, = but there are those within SG11 who insist that the interface being = addressed is fundamentally different from H.248/Megaco. Personally I am = not convinced by this - the deviations from H.248 are more to do with = starting out with an ATM-specific overall solution in BICC CS1. = Broadly, H.248/Megaco can functionally do everything which the new = Q.1950 can do, though there are some generic packages defined in Q.1950 = which have wider application.

To achieve the SG11 architectural aims with standard = H.248 would mean basing transport of all bearer information in BICC on = SDP - which is not how BICC CS1 works. But anyway...

>
>
> >Regards,
> >
> >Mark
> >
> > > -----Original Message-----
> > > From: Christer Holmberg
> >
> [<mailto:christer.holmbe= rg@lmf.ericsson.se>mailto:christer.hol
> mberg@lmf.ericsson.se]
> >
> > > Sent: 13 February 2001 09:35
> > > To: sip@lists.bell-labs.com
> > > Subject: Re: [SIP] Re: SIP digest, = Vol 1 #750 - 4 msgs
> > >
> > >
> > >
> > > Not to forget the cases where we = encapsulate everything
> in morse code
> > > and smoke signals - after all, SIP is = newer than those
> > > methods, so... :)
> > >
> > > Christer Holmberg
> > > Ericsson Finlande
> > >
> > > Jonathan Rosenberg wrote:
> > > >
> > > >
> > > >
> > > > > -----Original = Message-----
> > > > > From: Rosen, Brian
> > [<mailto:Brian.Rosen@marconi.com>mailto:Brian.Rosen@marconi.com]
> > > > > Sent: Friday, February 02, = 2001 9:28 AM
> > > > > To: = 'Jon.Peterson@Level3.com'; chsharp@cisco.com
> > > > > Cc: = sip@lists.bell-labs.com
> > > > > Subject: RE: [SIP] Re: SIP = digest, Vol 1 #750 - 4 msgs
> > > > >
> > > > >
> > > > > > And is it just me, or = is the idea that BICC will be
> > > > > > encapsulated in = SIP
> > > > > > somewhat = counterintuitive? Are there any services today that
> > > > > > require that?
> > > > > > Anyway, if there is = interest I'd be inclined to say
> that BICC
> > > > > > should have
> > > > > > it's own MIME type = which should be discussed on its
> own merits.
> > > > >
> > > > > So, SIP-T is used for, = among other things, ISUP-SIP-ISUP.
> > > > > You don't think anyone = wants to do BICC-SIP-BICC when SIP is
> > > > > one operator's
> > > > > network, and the BICCs are = two other operators?
> > > > >
> > > > > I also see BICC-SIP-ISUP = and of course ISUP-BICC-SIP-ISUP and
> > > > > variations.
> > > >
> > > > Seems prejudicial in favor of = SIP catering to BICC. If we
> > > do this, what
> > > > about:
> > > >
> > > > SIP-BICC-SIP
> > > >
> > > > I think we should request the = BICC guys to be able to
> > > encapsulate SIP
> > > > messages. After all, what about = service transparency across
> > > my SIP network!
> > > > All these operators that are = deploying SIP are doing so, in
> > > part, because of
> > > > the service possibilities. Shall = I be forced to lose those
> > > capabilities when
> > > > I traverse an IP based BICC = network? Why do the BICC guys
> > > get to keep their
> > > > services, and the SIP guys = don't? After all, BICC is even
> > > newer than SIP.
> > > >
> > > > Of course, once we do that, the = more fun case is:
> > > >
> > > > ISUP-SIP-BICC-SIP-ISUP
> > > >
> > > > in which case the encapsulated = SIP messages themselves
> contain ISUP
> > > > messages, both of which are = encapsulated in BICC.
> > > >
> > > > Of course, we should probably = also consider the case of:
> > > >
> > > > SIP-ISUP-SIP
> > > >
> > > > Think about it; a SIP phone = calls a PSTN number. It goes to
> > > an ss7 gateway.
> > > > Turns out, that this number is = then forwarded to another
> > > number, and that
> > > > number is a VoIP terminal. So, = it exits at another gateway,
> > > and hits the
> > > > terminal. I suppose we should = also request the ISUP guys to
> > > encapsulate SIP
> > > > messages.
> > > >
> > > > Now then, we should also = probably consider the case of:
> > > >
> > > > = SIP-BICC-SIP-ISUP-SIP-BICC
> > > >
> > > > -Jonathan R.
> > > > "reducio ad = absurdum"
> > > > ---
> > > > Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock Ave.
> > > > Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> > > > = dynamicsoft          &= nbsp;           &= nbsp;          East =
> Hanover, NJ 07936
> > > > = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:  
> (973) 952-5050
> > > >
> >
> <http://www.cs.columbia.edu/~jdrosen>http://www.cs.columbia.ed
u/~jdrosen
> PHONE: (973) 952-5000
> > > <http://www.dynamicsoft.com>http://www.dynamicsoft.com
> > >
> > > = _______________________________________________
> > > This list is for continuing = development of the SIP protocol.
> > > The sip-implementer's list is the = place to discuss implementation,
> > > and to receive advice on = understanding existing sip.
> > > To subscribe to it, send mail to = majordomo@cs.columbia.edu with
> > > "subscribe = sip-implementors" in the body.
> >


---------------------------------------------------------------= ----
Chip = Sharp           &= nbsp;           = Consulting Engineering
Cisco Systems
---------------------------------------------------------------= ----

------_=_NextPart_001_01C09B46.833DB810-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 20 09:14:17 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12456 for ; Tue, 20 Feb 2001 09:14:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C1E224436F; Tue, 20 Feb 2001 09:14:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id 3FD0044352 for ; Tue, 20 Feb 2001 09:13:02 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Tue, 20 Feb 2001 14:07:56 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <102DBH58>; Tue, 20 Feb 2001 14:07:54 -0000 Message-ID: From: "Mark Watson" To: Christer Holmberg Cc: "'Gonzalo Camarillo'" , Keith Robinson , Jonathan Rosenberg , "Tom-PT Taylor" , sip@lists.bell-labs.com Subject: RE: [SIP] Operlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09B46.81E1AA80" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 20 Feb 2001 14:07:49 -0000 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_01C09B46.81E1AA80 Content-Type: text/plain; charset="iso-8859-1" Christer, Comments below. The intention was that the UAC should wait for a response before sending a new INVITE. The response is either a 484 or an 'INFO Negotiation' which allows more digits to be sent. Any other response indicates that you've got all the digits. ...Mark > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: 17 February 2001 13:52 > To: Watson, Mark [MAIFP:EP11-M:EXCH] > Cc: 'Gonzalo Camarillo'; Keith Robinson; Jonathan Rosenberg; Taylor, > Tom-PT [NORSE:B901:EXCH]; sip@lists.bell-labs.com > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > Hi, > > >I think this is being made a lot more complicated than necessary. > > > >By negotiation, I just meant that when the call reached a UAS which > >supported INFOs, it would return an indication (e.g. 186)that the UAC > >could switch to using INFOs. Until the call reached the UAS > (i.e. PSTN > >Gateway), then INFOs would not be used - you would just have > >INVITE/484 exchanges until you had enough digits to reach the UAS. > > Ok, so this is basically Tom's ogiginal proposal. > > So, I guess we all can agree on the fact that until we reach > the UAS, we > use INVITEs and 484 responses. > > I still agree that there are advantages using INFO. However, > using INFO > still raises some issues. > > Consider the case where the INVITE reaches the UAS, which > DOES manage to > route the call to the next PSTN entity. To inform the UAC about this > (this is true BOTH if we use INVITEs or INFOs for the rest of the > digits) the UAS sends a 18x response. In the INFO-case, the > UAS include > the "INFO negotiation" result in this response. However: > > 1. Before the UAC receives the 18x response, it may receive additional > digits, and will send a new INVITE. In this case, the UAS must be able > to handle new INVITEs, EVEN if it has indicated in the 18x > response that > it does support the method using INFOs. This case will not > happen if the > UAC always will wait for a response before it sends the next request, > INVITE or INFO, but that may slow down the call setup, AND digig > buffering must be implemented. Yep, you would need to wait for the response before sending more digits. If you get a 484 from a non-overlap supporting device or a "INFO negotiation" from an overlap-supporting device you can send the next digit(s). Any other response means you've got enough digits now. Digit buffering's required at an incoming PSTN gateway anyway - you can always receive overlap digits before you've finished processing the IAM. > > 2. Since the UAS may not support the method using INFO, the UAC may > still have to use INVITEs for the additional digits. > No, a UAS which did not support overlap would just 484 any calls without enough digits. The point of standardising the INFO mechanism would be to say that any UAS which did not have dial-plan information (i.e. could not detect end-of-dialling), and therefore needed overlap, would need to implement it. > Conclusion: No matter which method we want to use, both the > UAC and UAS > must be able to use both methods, and, like I mentioned, the UAS may > have to process additional INVITEs even if it has sent a 18x response > and indicated the support for INFO. > > So, from this point of view I think it costs more than it > gains by using > INFO. Also, if we define rules for the routing the gain is even less. > The only case where I (this is my personal opinion) could > agree it makes > any sense at all to use INFO is when the UAC always waits for > a response > from the UAS before it sends the next request, but do we > really want to > require that? And, if we solve the routing issue in a nice way I don't > think it's worth the effort - even if we also don't have to > send ACKs by > using INFO. > > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > For proxies which need to see all the digits, they can still operate > > in INVITE/484 mode until they have enough digits to route - > the proxy > > would not trigger the UAC to send INFOs, but if a downstream UAS > > *did*, the proxy could examine subsequent INFOs which come past in > > order to update its record of the destination number. > > > > Regards...Mark > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > > Sent: 15 February 2001 21:42 > > > To: Watson, Mark [MAIFP:EP11-M:EXCH] > > > Cc: 'Gonzalo Camarillo'; Keith Robinson; Jonathan > Rosenberg; Taylor, > > > > > Tom-PT [NORSE:B901:EXCH]; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > Hi, > > > > > > Again, I am Gonzalo, but I will also comment... :) > > > > > > Mark Watson wrote: > > > > > > > >Gonzalo, > > > > > > > >I don't understand your comment about the INFO Overlap proposals > > > >causing problems for 'vanilla' SIP UAs. My suggestion was > > > that the use > > > >of INFOs for overlap digits be negotiated between UAC and UAS. > > > > > > My personal opinion is that, even if this overlap dialing thing > > seems > > > like a very difficult problem to solve, the functionality > itself is > > > pretty minor, so I don't think that a UA should have to > > > negotiate about > > > the method to use for this... Also, I don't think your negotiation > > > proposal would work. You should remember that you have to > > > reach the UAS > > > before you can do this negotiation in the first place, which means > > you > > > may have to send a number of INVITEs, and receive 484 > responses from > > > > > proxies. And, even when you reach the UAS (let's assume > it's a PSTN > > > gateway), it may be able to forward the digits, so the only answer > > you > > > are going to get is 100 - which you will get from the first proxy, > > so > > > the UAS can't include the negotiation result there. > > > > > > This response-from-the-UAS thing is, however, related to another > > issue > > > which I will describe in another mail. > > > > > > >So, the UAC would include a 'Supported' tag if it could > do overlap > > > >INFOs and the mechanism would then only be used if both ends > > > supported > > > >it. Otherwise you would just kill session requests without enough > > > >digits with 484s. > > > > > > See my comment above why I don't this would work very well. > > > > > > >Regarding Application Servers, the INFOs should certainly contain > > all > > > >the digits so far (otherwise we get the problems with lost > > messages). > > > >I do not believe any proxies exist which are being used today in > > > >overlap situations and which need access to the whole called > > number, > > > >so we can add this capability to the specification without > > > hurting any > > > >existing implementations. > > > > > > Well, well, well... Let's assume it's a proxy that sends the 484 > > > response. Then, if you want to start using INFO, this proxy must > > > remember the INVITE, and collect the INFOs. Then, when > the proxy has > > > > > enough digits, what shall it do then? Create an INVITE of > > > it's own? What > > > will then happen when the UAC receive the response for an > INVITE it > > > never created? Also, when the proxy sends the INVITE, it may > > > receive 484 > > > responses from the NEXT proxy in the network, asking for more > > digits. > > > Ie, your proxy would have to both collect digits from the UAC, and > > > handle the next entity (in this example, another proxy) in the SIP > > > nework. All this would DEFINITELY hurt existing > > > implementations, so you > > > would also have to negotiate with the proxies if they are > able to do > > > > > this... > > > > > > In this case I think Keith's proposal, ie that the proxy is > > > smart enough > > > to see that the only thing that has changed in the new > INVITE is the > > > > > receiver digits, is MUCH easier to implement :) > > > > > > >Finally, there are many reasons other than simple load balancing > > why > > > >one INVITE might be routed differently to a subsequent, > apparently > > > >identical, one. e.g. Time of day routing - which is certainly not > > > >'random'. Stateful proxies may also remember where they sent the > > > >INVITE so that subsequent requests on the same call leg can be > > routed > > > >the same way. > > > > > > I agree, routing is a problem, but there has been proposals > > > to solve it, > > > ie the one Keith gave. Also, I think that routing, and forking, is > > the > > > reason for a number of SIP related problems, so I think it is > > > better to > > > find a generic solution to that. Allowing ROUTE headers > in specific > > > situations (again, see Keith's proposal) in initial requests > > > is partly a > > > solution. > > > > > > Regards, > > > > > > Christer Holmberg > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > Mark Watson > > > > Nortel Networks > > > > > > > > > -----Original Message----- > > > > > From: Gonzalo Camarillo > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > Sent: 14 February 2001 14:31 > > > > > To: Keith Robinson > > > > > Cc: Jonathan Rosenberg; Taylor, Tom-PT [NORSE:B901:EXCH]; > > Christer > > > > > Holmberg; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > Hello Keith, > > > > > > > > > > Keith Robinson wrote: > > > > > > > > > > > > Gonzalo, > > > > > > > > > > > > It seems you have two main reasons against the > use of the > > > > > > INFO > > > > > > method for the conveyance of subsequent ISUP information: > > > > > > > > > > > > 1) Lack of ordered delivery of the INFO messages > > > > > > > > > > > > Ordered delivery could be maintained by the UAC not sending > > > > > the next INFO > > > > > > until a 200 OK response for the previous one had been > > received. > > > > > > > > > > > > 2) Lack of state carried in the INFO messge > > > > > > > > > > > > The digits received so far could be carried in a header > > > within the > > > > > > > > > > INFO message. Each INFO message would then carry the same > > > > > information > > > > > > as a re-INVITE. > > > > > > > > > > > > > > > > Actually my main reason against the use of INFO is that it > > > > > does not work > > > > > with vanilla SIP UAs and vanilla SIP Application Servers. How > > you > > > > > resolve the technical issues related to INFO does not > > > really matter > > > > to > > > > > me. It is not "vanilla" SIP, and I am against this kind of > > > > > non-standard > > > > > mechanisms. > > > > > > > > > > > > > > > > My reason for exploring the use of INFO is not to save on > > > > > messages. It is > > > > > > to do with the issue of source routing. Again, my concern of > > > > source > > > > > > routing is not one of a technical nature. What if an > > > > > administration has a > > > > > > security policy that states source routing (a ROUTE > header in > > > > > > an initial INVITE) will not take place in its SIP network > > > > > but it also requires > > > > > > that > > > > > > the same network interworks with the PSTN; if any part of > > > > > the PSTN interworking > > > > > > mechanism > > > > > > relies on source routing then there is a conflict of > > > > > requirements. It is this > > > > > > conflict > > > > > > I wish to address. > > > > > > > > > > > > > > > > OK, let's address this. Source routing is proposed in > the draft > > to > > > > > address load balancing. This is, a proxy that sends INVITEs > > > > > to different > > > > > egrees gateways. > > > > > > > > > > So, if an IAM and one SAM are received, the second INVITE > > > might end > > > > up > > > > > in another gateway than the fist INVITE. This would trigger 2 > > IAMs > > > > > instead of 1 IAM and 1 SAM. > > > > > > > > > > OK, this is the problem that has to be solved. What I > > > wanted to say > > > > in > > > > > the draft (I did not have lot of time and it has to be > > rephrased), > > > > was > > > > > the following: > > > > > > > > > > It is strongly RECOMMENDED that proxies route > requests that are > > > > > basically identical and just differ in the to field (more > > > > > digits) in the > > > > > same way. So, if such as proxy performs load > balancing, all the > > > > > subsequent INVITEs will reach the same egrees gateway. > > > > > > > > > > This is not difficult to do, because most likely a call to > > > > > +1234 has to > > > > > be routed in the same way as a call to +12345. So, > the only real > > > > > > > requirement in that proxies do not make routing > decisions based > > on > > > > > random variables (such as internal clocks). > > > > > > > > > > Then, just in case folks did not feel comfortable with > > > this solution > > > > > > > > > (which I believe is the good one), I outlined the > source routing > > > > > > > solution. > > > > > > > > > > And what about load balancing? You can still have load > > balancing. > > > > Your > > > > > proxy makes the routing decision based on to, from, and what > > > > > ever fields > > > > > it wants. Then, it can calculate a digest of some fields, > > > and make a > > > > > > > > > "random" routing decision based on that hash. This > provides load > > > > > > > balancing but still routes INVITEs carrying SAMs in the > > > proper way. > > > > > > > > > > Does this resolve your issue? > > > > > > > > > > Best regards, > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > K. Robinson. > > > > > > > > > > > > Gonzalo Camarillo on > > > > > 01/01/88 00:39:14 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > To: Jonathan Rosenberg > > > > > > > > > > > > cc: "'Tom-PT Taylor'" , > > > > > > Christer Holmberg > > > > > > , > > > > > > sip@lists.bell-labs.com(bcc: Keith > > > > > > Robinson/MAIN/MC1) > > > > > > > > > > > > > > > > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > > > > > I think the correct answer about which approach to use > > > > > (INFO vs. multiple > > > > > > > call legs) depends on your view of the scope of the > > > > > address within the sip > > > > > > > cloud. If you believe that the sip role has ended once > > > > > you have enough > > > > > > > digits to select an egress gateway (which may be as few > > > > > as one, i.e., +1 > > > > > > > selects a US gateway), then the sip address of that > > > > > gateway can be viewed as > > > > > > > sip:+1@provider.com, and all subsequent digits are PSTN > > > > > issues, outside the > > > > > > > scope of SIP. > > > > > > > > > > > > I definitively agree that this is the view that INFO fans > > > > > have of a SIP > > > > > > cloud. What I am saying is that this view is wrong. This > > > > > usage of SIP > > > > > > falls outside the scope of SIP. > > > > > > If they want to use SIP for locating a gateway, it is > > > > > fine. But after > > > > > > the gateway has been located, let's use another method for > > > > > transporting > > > > > > ISUP signalling. > > > > > > > > > > > > Let's assume that I get an IAM with "+1", as Jonathan > > > says in his > > > > > > example. Then the INVITE generated by the gateway will reach > > the > > > > US > > > > > > gateway. Now, the mission of SIP has finished, since the > > gateway > > > > has > > > > > > been located. Why don't we put in the body of this INVITE a > > > > session > > > > > > description that comprises a media session and a SIGTRAN > > > > > session? This > > > > > > way we would have established these two sessions between > > > > > the gateways > > > > > > and all the subsequent ISUP messages would be sent over the > > > > SIGTRAN > > > > > > session. > > > > > > > > > > > > I find that the usage of SIP that I have just > described would > > be > > > > OK. > > > > > > What I do not understand is why folks want to use SIP for > > > > > transporting > > > > > > subsequent ISUP messages. SIP does not have good transport > > > > > properties > > > > > > (big overhead, it can run over UDP...). Besides, it does not > > > > provide > > > > > > ordered delivery. > > > > > > > > > > > > If the INVITE has Cseq=1 and the next message that the > > > > > egrees gateway > > > > > > receives is a INFO with Cseq=7... what should the > gateway do? > > > > Maybe > > > > > > there were several proxies in the middle asking for > > > > > credentials for the > > > > > > INFO, so the ingrees gateway had to add authentication > > > > > stuff and resend > > > > > > the INFO. If this was the case, the SAM contained in the > > > > > INFO would be > > > > > > the second digit of the called party number... > However, maybe > > 5 > > > > INFO > > > > > > messages got lost, and the SAM that we have received in the > > > > > body of the > > > > > > INFO makes no sense without the previous ones because is > > > > > the 7th digit > > > > > > of the number... > > > > > > > > > > > > This is not usually a problem in SIP, since all > > > messages have full > > > > > > > > > > state. However, using INFO for sending SAMs breaks this > > > rule, and > > > > > > therefore it breaks the SIP model. > > > > > > > > > > > > I believe that considering that the session is established > > after > > > > the > > > > > > first INVITE and sending the following SAMs using INFO is > > > > > making one of > > > > > > the mistakes described in the guidelines for SIP authors: > > > > > "We need to > > > > > > transport ISUP signalling over IP between two gateways. > > > > > Both gateways > > > > > > already implement SIP... why do we have to implement > > > > > another protocol? > > > > > > Let's use SIP to transport ISUP signalling". We are just > > > > > trying to use > > > > > > SIP for this just because it would save implementing yet > > another > > > > > > protocol in the gateways. > > > > > > > > > > > > I strongly disagree with this usage of SIP. SIP-T is good > > > > > as long as the > > > > > > SIP cloud provides services. If not, SIP-T is not a good > > > > > protocol for > > > > > > transporting ISUP signalling. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > If you believe that the sip role encompasses functions that > > > > > > > might apply to the PSTN subscribers, then you need to > > > > > have the entire > > > > > > > number, and the multiple call leg approach is the > right way > > to > > > > go. > > > > > > > > > > > > > > The multiple call leg approach is clearly ugly and > > > > > inelegant, but it has the > > > > > > > nice property of completely masking the existence of > > > > > overlap from proxies > > > > > > > and app servers within the network, allowing them to > > > > > provide services in the > > > > > > > normal way. > > > > > > > > > > > > > > -Jonathan R. > > > > > > > > > > > > > > --- > > > > > > > Jonathan D. Rosenberg 72 Eagle Rock > > Ave. > > > > > > > Chief Scientist First Floor > > > > > > > dynamicsoft East > Hanover, NJ > > > > > > 07936 > > > > > > > jdrosen@dynamicsoft.com FAX: (973) > > > > 952-5050 > > > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) > > > > 952-5000 > > > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > > > > > Sent: Thursday, February 08, 2001 7:00 AM > > > > > > > To: Gonzalo Camarillo > > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > > Subject: RE: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > You are correct about using some other means of > transport if > > > > > > ISUP > > > > > > > trans-shipment is all your network is doing. If the call > > > > > destination (to a > > > > > > > SIP endpoint, to an H.323 endpoint, to a PSTN endpoint) > > > > > varies on a per-call > > > > > > > basis, however, using SIP to establish your call routing > > > > > leads to using SIP > > > > > > > to carry the ISUP. > > > > > > > > -----Original Message----- > > > > > > > > From: Gonzalo Camarillo > > > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > > > Sent: Tuesday, February 06, 2001 9:52 PM > > > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > > > > > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > Still I want to have full state in every SIP message. > > > > > If the call is > > > > > > > > addresed to the phone number 1234, I want to have a to > > > > > field that says > > > > > > > > 1234. I do not care if there is a leg routed thru the > > > > > PSTN and another > > > > > > > > thru SIP. > > > > > > > > > > > > > > > > Carrying full state is one of the beauties of SIP. If > > > > > we begin using > > > > > > > > INFO for this, it would be the same as using SAMs. > > > > > Differen names, the > > > > > > > > same thing... I do not want to re-create ISUP > using SIP. I > > > > > > > > > > believe that > > > > > > > > if the session has a destination, it should be > > > present in the > > > > > > > > to field. > > > > > > > > > > > > > > > > Again, if a proxy is providing services for this > > > > > particular call, it > > > > > > > > will want to see the called party number in order to > > trigger > > > > > > > > the proper > > > > > > > > service. This is a very good reason for updating > > > the to field > > > > > > > > every time > > > > > > > > we have more digits. > > > > > > > > > > > > > > > > I like to use SIP between two gateways because it > > > is possible > > > > > > > > to provide > > > > > > > > SIP services for a PSTN to PSTN call. If all we > > > want to do is > > > > > > > > finding a > > > > > > > > egrees gateway, we would probably want to use other > > > > > protocols (TRIP & > > > > > > > > SIGTRAN for instance). > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > > > > Sorry, we're talking past each other. The > premise of my > > > > > > > > > > statements is > > > > > > > > > that an INVITE has reached a UAS which has accepted > > > > > it. It follows > > > > > > > > > that the UAS did not send back a 484, but rather > > > an interim > > > > > > > > response. > > > > > > > > > IF more digits come along, the INFO method is there > > > > > to carry them. > > > > > > > > > They do not affect the SIP call state; they are used > > > > > beyond the UAS, > > > > > > > > > either in a PSTN call or in another SIP call as the > > > > > case may be. > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Gonzalo Camarillo > > > > > [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > > > > > > > > > > Sent: Tuesday, February 06, 2001 9:10 PM > > > > > > > > > > To: Taylor, Tom-PT [NORSE:B901:EXCH] > > > > > > > > > > Cc: Christer Holmberg; sip@lists.bell-labs.com > > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP > > network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Tom, > > > > > > > > > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > > > > > > > > Just to re-hash, in the ISUP-SIP-ISUP > > > context, once call > > > > > > > > > > > > > signalling > > > > > > > > > > > has reached an egress gateway, SIP has > done its job > > -- > > > > > > > > additional > > > > > > > > > > > digits will not change call state. It is > therefore > > > > > > > > > > reasonable to use > > > > > > > > > > > INFO to carry the additional digits. If we > > > are talking > > > > > > > > > > ISUP-SIP, once > > > > > > > > > > > the destination UAS or a UAS in a B2BUA has been > > > > > > > > reached, the same > > > > > > > > > > > > > > > > > > > > consideration applies. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do not agree with these two statements: > > > > > > > > > > > > > > > > > > > > The 1st INVITE (with just some digits) arrives to a > > > > > > > > vanilla SIP UA. > > > > > > > > > I > > > > > > > > > > will return a Not Found or a 484 Address incomplete. > > The > > > > > > > > > > subsequent INFO > > > > > > > > > > carrying more digits will be discarded. Thus, the > > > > > PSTN to SIP > > > > > > > > > gateway > > > > > > > > > > will have to re issue a new INVITE with all the > > digits. > > > > > > > > > > Therefore, it is > > > > > > > > > > better to begin directly using er-INVITEs > rather than > > > > INFO. > > > > > > > > > > > > > > > > > > > > Besides, I do not think that SIP is just a > > > > > transport protocol that > > > > > > > > > > carries ISUP messages between two gateways. For > > > > > that, we have > > > > > > > > > already > > > > > > > > > > SIGTRAN. SIP might be used to provide services, > > > > > even when the > > > > > > > > > > call is a > > > > > > > > > > PSTN-SIP-PSTN call. Thus, SIP messages MUST > > > carry complete > > > > > > > > > > > > > > state. And a > > > > > > > > > > SIP message with an incomplete to field does not > > > > > carry complete > > > > > > > > > state. > > > > > > > > > > What if my SIP proxy provides a service for a > > > > > PSTN-SIP-PSTN call > > > > > > > > > based > > > > > > > > > > on the to field (called party number). That proxy > > would > > > > > > > > like to see > > > > > > > > > an > > > > > > > > > > updated to field, not just a to field that contains > > > > > just some > > > > > > > > > digits. > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Christer Holmberg > > > > > > > > > [mailto:christer.holmberg@lmf.ericsson.se] > > > > > > > > > > > > Sent: Tuesday, February 06, 2001 1:15 AM > > > > > > > > > > > > To: Gonzalo Camarillo > > > > > > > > > > > > Cc: sip@lists.bell-labs.com > > > > > > > > > > > > Subject: Re: [SIP] Operlap dialing within a SIP > > > > network > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Gonzalo, > > > > > > > > > > > > > > > > > > > > > > > > I didn't say I am going to use INFO, but that > > > > > is what has > > > > > > > > > > > > been proposed > > > > > > > > > > > > earlier in this thread, so I assumed INFO would > > > > > be used. The > > > > > > > > > > > > reason for > > > > > > > > > > > > the discussion from the beginning was that > > > the overlap > > > > > > > > > > > > > signalling, > > > > > > > > > > > > according to the SIP-ISUP mapping draft, > > > may not work > > > > > > > > > > very well, and > > > > > > > > > > > a > > > > > > > > > > > > solution using 18x responses and INFO messages, > > > > > instead of 484 > > > > > > > > > and > > > > > > > > > > > > re-INVITEs, was proposed. > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo Camarillo wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Christer, > > > > > > > > > > > > > > > > > > > > > > > > > > Why are you using INFO for sending > extra digits? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please, check the SIP-ISUP mapping draft, > > overlap > > > > > > > > > > > > signalling section. > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > > > Gonzalo > > > > > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > > > > > > > The discussion about overlap dialing has > > > > > been pretty much > > > > > > > > > > > > about calls > > > > > > > > > > > > > > from SIP to PSTN, or PSTN-SIP-PSTN. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Consider the following scenario. > > > > > > > > > > > > > > > > > > > > > > > > > > > > PSTN PHONE GW > SIP SERVER > > > > > > > > > > SIP UAS > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------- > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- 1 ---> -- IAM -> | -- INVITE --> | > > > > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > > > > --- 2 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > > > > | <- 200 (INFO) | > > > > > > > > > > > > > > | <- 18x ------ | > > > > > > > > > > > > > > --- 3 ---> -- SAM -> | -- INFO ----> | > > > > > > > > > > > > > > | <- 200 (INFO) | > > > > > -- INVITE > > > > > > > > > > > > > > --> > > > > > > > > > > > > > > | <- 200 (INVITE)| > > > > > <- 200 ------ > > > > > > > > > > > > > > > > > > > > > > > > > > > > In this case, the SIP server (note that I > > > > > am not using > > > > > > > > > > > > the word 'proxy') > > > > > > > > > > > > > > must collect digits, sent from the PSTN > > > side using > > > > > > > > > > > > > > > > overlap dialing, to > > > > > > > > > > > > > > be able to find the SIP UAS, and INFO is > > > > > used to provide > > > > > > > > > > > > the digits > > > > > > > > > > > > > > after the INVITE has been sent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > My question is, should a SIP server (proxy, > > > > > if you like) > > > > > > > > > > > > be allowed to > > > > > > > > > > > > > > behave like this, or MUST it send 486s, and > > > > > receive new > > > > > > > > > > > > INVITEs, until > > > > > > > > > > > > > > it is able to find the UAS? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Christer Holmberg > > > > > > > > > > > > > > Ericsson Finland > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > Gonzalo Camarillo Phone : +358 > > > 9 299 33 71 > > > > > > > > > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 > > > 40 702 35 35 > > > > > > > > > > > > > > > > > Telecom R&D Fax : +358 > > > 9 299 30 52 > > > > > > > > > > > > > > > > > FIN-02420 Jorvas Email : > > > > > > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > > > > > Finland > > > http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > > > FIN-02420 Jorvas Email : > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > > > FIN-02420 Jorvas Email : > > > > > Gonzalo.Camarillo@ericsson.com > > > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > > > > > > > > > -- > > > > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > > > > Telecom R&D Fax : +358 9 299 30 52 > > > > > > FIN-02420 Jorvas Email : > > > Gonzalo.Camarillo@ericsson.com > > > > > > Finland http://www.hut.fi/~gonzalo > > > > > > > > > > > > _______________________________________________ > > > > > > This list is for continuing development of the SIP protocol. > > > > > > The sip-implementer's list is the place to discuss > > > implementation, > > > > > > > > > > and to receive advice on understanding existing sip. > > > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu > > with > > > > > > "subscribe sip-implementors" in the body. > > > > > > > > > > -- > > > > > Gonzalo Camarillo Phone : +1 212 > 939 71 71 > > > > > Columbia University Mobile: +358 40 > 702 35 35 > > > > > 472 Computer Science Building Fax : +358 9 > 299 30 52 > > > > > 1214 Amsterdam Ave., Mail Code 0401 > http://www.hut.fi/~gonzalo > > > > > New York, NY 10027 > > > > > USA > Gonzalo.Camarillo@ericsson.com > > > > > > > > > > _______________________________________________ > > > > > This list is for continuing development of the SIP protocol. > > > > > The sip-implementer's list is the place to discuss > > implementation, > > > > > and to receive advice on understanding existing sip. > > > > > To subscribe to it, send mail to > majordomo@cs.columbia.edu with > > > > > "subscribe sip-implementors" in the body. > > > > > > > > > ------_=_NextPart_001_01C09B46.81E1AA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Operlap dialing within a SIP network

Christer,

Comments below. The intention was that the UAC should = wait for a response before sending a new INVITE. The response is either = a 484 or an 'INFO Negotiation' which allows more digits to be = sent.

Any other response indicates that you've got all the = digits.

...Mark

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> Sent: 17 February 2001 13:52
> To: Watson, Mark [MAIFP:EP11-M:EXCH]
> Cc: 'Gonzalo Camarillo'; Keith Robinson; = Jonathan Rosenberg; Taylor,
> Tom-PT [NORSE:B901:EXCH]; = sip@lists.bell-labs.com
> Subject: Re: [SIP] Operlap dialing within a SIP = network
>
>
>
> Hi,
>
> >I think this is being made a lot more = complicated than necessary.
> >
> >By negotiation, I just meant that when the = call reached a UAS which
> >supported INFOs, it would return an = indication (e.g. 186)that the UAC
> >could switch to using INFOs. Until the call = reached the UAS
> (i.e. PSTN
> >Gateway), then INFOs would not be used - = you would just have
> >INVITE/484 exchanges until you had enough = digits to reach the UAS.
>
> Ok, so this is basically Tom's ogiginal = proposal.
>
> So, I guess we all can agree on the fact that = until we reach
> the UAS, we
> use INVITEs and 484 responses.
>
> I still agree that there are advantages using = INFO. However,
> using INFO
> still raises some issues.
>
> Consider the case where the INVITE reaches the = UAS, which
> DOES manage to
> route the call to the next PSTN entity. To = inform the UAC about this
> (this is true BOTH if we use INVITEs or INFOs = for the rest of the
> digits) the UAS sends a 18x response. In the = INFO-case, the
> UAS include
> the "INFO negotiation" result in this = response. However:
>
> 1. Before the UAC receives the 18x response, it = may receive additional
> digits, and will send a new INVITE. In this = case, the UAS must be able
> to handle new INVITEs, EVEN if it has indicated = in the 18x
> response that
> it does support the method using INFOs. This = case will not
> happen if the
> UAC always will wait for a response before it = sends the next request,
> INVITE or INFO, but that may slow down the call = setup, AND digig
> buffering must be implemented.

Yep, you would need to wait for the response before = sending more digits. If you get a 484 from a non-overlap supporting = device or a "INFO negotiation" from an overlap-supporting = device you can send the next digit(s). Any other response means you've = got enough digits now.

Digit buffering's required at an incoming PSTN = gateway anyway - you can always receive overlap digits before you've = finished processing the IAM.

>
> 2. Since the UAS may not support the method = using INFO, the UAC may
> still have to use INVITEs for the additional = digits.
>

No, a UAS which did not support overlap would just = 484 any calls without enough digits. The point of standardising the = INFO mechanism would be to say that any UAS which did not have = dial-plan information (i.e. could not detect end-of-dialling), and = therefore needed overlap, would need to implement it.

> Conclusion: No matter which method we want to = use, both the
> UAC and UAS
> must be able to use both methods, and, like I = mentioned, the UAS may
> have to process additional INVITEs even if it = has sent a 18x response
> and indicated the support for INFO.
>
> So, from this point of view I think it costs = more than it
> gains by using
> INFO. Also, if we define rules for the routing = the gain is even less.
> The only case where I (this is my personal = opinion) could
> agree it makes
> any sense at all to use INFO is when the UAC = always waits for
> a response
> from the UAS before it sends the next request, = but do we
> really want to
> require that? And, if we solve the routing = issue in a nice way I don't
> think it's worth the effort - even if we also = don't have to
> send ACKs by
> using INFO.
>
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 
> > For proxies which need to see all the = digits, they can still operate
> > in INVITE/484 mode until they have enough = digits to route -
> the proxy
> > would not trigger the UAC to send INFOs, = but if a downstream UAS
> > *did*, the proxy could examine subsequent = INFOs which come past in
> > order to update its record of the = destination number.
> >
> > Regards...Mark
> >
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > > Sent: 15 February 2001 21:42
> > > To: Watson, Mark = [MAIFP:EP11-M:EXCH]
> > > Cc: 'Gonzalo Camarillo'; Keith = Robinson; Jonathan
> Rosenberg; Taylor,
> >
> > > Tom-PT [NORSE:B901:EXCH]; = sip@lists.bell-labs.com
> > > Subject: Re: [SIP] Operlap dialing = within a SIP network
> > >
> > >
> > >
> > > Hi,
> > >
> > > Again, I am Gonzalo, but I will also = comment... :)
> > >
> > > Mark Watson wrote:
> > > >
> > > >Gonzalo,
> > > >
> > > >I don't understand your comment = about the INFO Overlap proposals
> > > >causing problems for 'vanilla' = SIP UAs. My suggestion was
> > > that the use
> > > >of INFOs for overlap digits be = negotiated between UAC and UAS.
> > >
> > > My personal opinion is that, even if = this overlap dialing thing
> > seems
> > > like a very difficult problem to = solve, the functionality
> itself is
> > > pretty minor, so I don't think that a = UA should have to
> > > negotiate about
> > > the method to use for this... Also, I = don't think your negotiation
> > > proposal would work. You should = remember that you have to
> > > reach the UAS
> > > before you can do this negotiation in = the first place, which means
> > you
> > > may have to send a number of INVITEs, = and receive 484
> responses from
> >
> > > proxies. And, even when you reach the = UAS (let's assume
> it's a PSTN
> > > gateway), it may be able to forward = the digits, so the only answer
> > you
> > > are going to get is 100 - which you = will get from the first proxy,
> > so
> > > the UAS can't include the negotiation = result there.
> > >
> > > This response-from-the-UAS thing is, = however, related to another
> > issue
> > > which I will describe in another = mail.
> > >
> > > >So, the UAC would include a = 'Supported' tag if it could
> do overlap
> > > >INFOs and the mechanism would = then only be used if both ends
> > > supported
> > > >it. Otherwise you would just kill = session requests without enough
> > > >digits with 484s.
> > >
> > > See my comment above why I don't this = would work very well.
> > >
> > > >Regarding Application Servers, = the INFOs should certainly contain
> > all
> > > >the digits so far (otherwise we = get the problems with lost
> > messages).
> > > >I do not believe any proxies = exist which are being used today in
> > > >overlap situations and which need = access to the whole called
> > number,
> > > >so we can add this capability to = the specification without
> > > hurting any
> > > >existing implementations.
> > >
> > > Well, well, well... Let's assume it's = a proxy that sends the 484
> > > response. Then, if you want to start = using INFO, this proxy must
> > > remember the INVITE, and collect the = INFOs. Then, when
> the proxy has
> >
> > > enough digits, what shall it do then? = Create an INVITE of
> > > it's own? What
> > > will then happen when the UAC receive = the response for an
> INVITE it
> > > never created? Also, when the proxy = sends the INVITE, it may
> > > receive 484
> > > responses from the NEXT proxy in the = network, asking for more
> > digits.
> > > Ie, your proxy would have to both = collect digits from the UAC, and
> > > handle the next entity (in this = example, another proxy) in the SIP
> > > nework. All this would DEFINITELY = hurt existing
> > > implementations, so you
> > > would also have to negotiate with the = proxies if they are
> able to do
> >
> > > this...
> > >
> > > In this case I think Keith's = proposal, ie that the proxy is
> > > smart enough
> > > to see that the only thing that has = changed in the new
> INVITE is the
> >
> > > receiver digits, is MUCH easier to = implement :)
> > >
> > > >Finally, there are many reasons = other than simple load balancing
> > why
> > > >one INVITE might be routed = differently to a subsequent,
> apparently
> > > >identical, one. e.g. Time of day = routing - which is certainly not
> > > >'random'. Stateful proxies may = also remember where they sent the
> > > >INVITE so that subsequent = requests on the same call leg can be
> > routed
> > > >the same way.
> > >
> > > I agree, routing is a problem, but = there has been proposals
> > > to solve it,
> > > ie the one Keith gave. Also, I think = that routing, and forking, is
> > the
> > > reason for a number of SIP related = problems, so I think it is
> > > better to
> > > find a generic solution to that. = Allowing ROUTE headers
> in specific
> > > situations (again, see Keith's = proposal) in initial requests
> > > is partly a
> > > solution.
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > >
> > >
> > >
> > > >
> > > > Regards,
> > > >
> > > > Mark Watson
> > > > Nortel Networks
> > > >
> > > > > -----Original = Message-----
> > > > > From: Gonzalo = Camarillo
> > [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > > > Sent: 14 February 2001 = 14:31
> > > > > To: Keith Robinson
> > > > > Cc: Jonathan Rosenberg; = Taylor, Tom-PT [NORSE:B901:EXCH];
> > Christer
> > > > > Holmberg; = sip@lists.bell-labs.com
> > > > > Subject: Re: [SIP] Operlap = dialing within a SIP network
> > > > >
> > > > >
> > > > > Hello Keith,
> > > > >
> > > > > Keith Robinson = wrote:
> > > > > >
> > > > > > Gonzalo,
> > > > > >
> > > > > = >      It seems you have two main reasons = against the
> use of the
> >
> > > > INFO
> > > > > > method for the = conveyance of subsequent ISUP information:
> > > > > >
> > > > > > 1) Lack of ordered = delivery of the INFO messages
> > > > > >
> > > > > > Ordered delivery could = be maintained by the UAC not sending
> > > > > the next INFO
> > > > > > until a 200 OK = response for the previous one had been
> > received.
> > > > > >
> > > > > > 2) Lack of state = carried in the INFO messge
> > > > > >
> > > > > > The digits received so = far could be carried in a header
> > > within the
> > > >
> > > > > > INFO message. Each = INFO message would then carry the same
> > > > > information
> > > > > > as a re-INVITE.
> > > > > >
> > > > >
> > > > > Actually my main reason = against the use of INFO is that it
> > > > > does not work
> > > > > with vanilla SIP UAs and = vanilla SIP Application Servers. How
> > you
> > > > > resolve the technical = issues related to INFO does not
> > > really matter
> > > > to
> > > > > me. It is not = "vanilla" SIP, and I am against this kind of
> > > > > non-standard
> > > > > mechanisms.
> > > > >
> > > > >
> > > > > > My reason for = exploring the use of INFO is not to save on
> > > > > messages. It is
> > > > > > to do with the issue = of source routing. Again, my concern of
> > > > source
> > > > > > routing is not one of = a technical nature. What if an
> > > > > administration has a
> > > > > > security policy that = states source routing (a ROUTE
> header in
> > > > > > an initial INVITE) = will not take place in its SIP network
> > > > > but it also requires
> > > > > > that
> > > > > > the same network = interworks with the PSTN; if any part of
> > > > > the PSTN = interworking
> > > > > > mechanism
> > > > > > relies on source = routing then there is a conflict of
> > > > > requirements. It is = this
> > > > > > conflict
> > > > > > I wish to = address.
> > > > > >
> > > > >
> > > > > OK, let's address this. = Source routing is proposed in
> the draft
> > to
> > > > > address load balancing. = This is, a proxy that sends INVITEs
> > > > > to different
> > > > > egrees gateways.
> > > > >
> > > > > So, if an IAM and one SAM = are received, the second INVITE
> > > might end
> > > > up
> > > > > in another gateway than the = fist INVITE. This would trigger 2
> > IAMs
> > > > > instead of 1 IAM and 1 = SAM.
> > > > >
> > > > > OK, this is the problem = that has to be solved. What I
> > > wanted to say
> > > > in
> > > > > the draft (I did not have = lot of time and it has to be
> > rephrased),
> > > > was
> > > > > the following:
> > > > >
> > > > > It is strongly RECOMMENDED = that proxies route
> requests that are
> > > > > basically identical and = just differ in the to field (more
> > > > > digits) in the
> > > > > same way. So, if such as = proxy performs load
> balancing, all the
> > > > > subsequent INVITEs will = reach the same egrees gateway.
> > > > >
> > > > > This is not difficult to = do, because most likely a call to
> > > > > +1234 has to
> > > > > be routed in the same way = as a call to +12345. So,
> the only real
> >
> > > > > requirement in that proxies = do not make routing
> decisions based
> > on
> > > > > random variables (such as = internal clocks).
> > > > >
> > > > > Then, just in case folks = did not feel comfortable with
> > > this solution
> > > >
> > > > > (which I believe is the = good one), I outlined the
> source routing
> >
> > > > > solution.
> > > > >
> > > > > And what about load = balancing? You can still have load
> > balancing.
> > > > Your
> > > > > proxy makes the routing = decision based on to, from, and what
> > > > > ever fields
> > > > > it wants. Then, it can = calculate a digest of some fields,
> > > and make a
> > > >
> > > > > "random" routing = decision based on that hash. This
> provides load
> >
> > > > > balancing but still routes = INVITEs carrying SAMs in the
> > > proper way.
> > > > >
> > > > > Does this resolve your = issue?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Gonzalo
> > > > >
> > > > >
> > > > >
> > > > > > Regards,
> > > > > >
> > > > > > K. Robinson.
> > > > > >
> > > > > > Gonzalo Camarillo = <Gonzalo.Camarillo@lmf.ericsson.se> on
> > > > > 01/01/88 00:39:14
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >  = To:      Jonathan Rosenberg = <jdrosen@dynamicsoft.com>
> > > > > >
> > > > > >  = cc:      "'Tom-PT Taylor'" = <taylor@nortelnetworks.com>,
> > > > > = >           = Christer Holmberg
> > > > > = >           = <christer.holmberg@lmf.ericsson.se>,
> > > > > = >           = sip@lists.bell-labs.com(bcc: Keith
> > > > > = >           = Robinson/MAIN/MC1)
> > > > > >
> > > > > >
> > > > > >
> > > > > >  Subject: Re: = [SIP] Operlap dialing within a SIP network
> > > > > >
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > Jonathan Rosenberg = wrote:
> > > > > > >
> > > > > > > I think the = correct answer about which approach to use
> > > > > (INFO vs. multiple
> > > > > > > call legs) = depends on your view of the scope of the
> > > > > address within the = sip
> > > > > > > cloud. If you = believe that the sip role has ended once
> > > > > you have enough
> > > > > > > digits to select = an egress gateway (which may be as few
> > > > > as one, i.e., +1
> > > > > > > selects a US = gateway), then the sip address of that
> > > > > gateway can be viewed = as
> > > > > > > = sip:+1@provider.com, and all subsequent digits are PSTN
> > > > > issues, outside the
> > > > > > > scope of = SIP.
> > > > > >
> > > > > > I definitively agree = that this is the view that INFO fans
> > > > > have of a SIP
> > > > > > cloud. What I am = saying is that this view is wrong. This
> > > > > usage of SIP
> > > > > > falls outside the = scope of SIP.
> > > > > > If they want to use = SIP for locating a gateway,  it is
> > > > > fine. But after
> > > > > > the gateway has been = located, let's use another method for
> > > > > transporting
> > > > > > ISUP = signalling.
> > > > > >
> > > > > > Let's assume that I = get an IAM with "+1", as Jonathan
> > > says in his
> > > > > > example. Then the = INVITE generated by the gateway will reach
> > the
> > > > US
> > > > > > gateway. Now, the = mission of SIP has finished, since the
> > gateway
> > > > has
> > > > > > been located. Why = don't we put in the body of this INVITE a
> > > > session
> > > > > > description that = comprises a media session and a SIGTRAN
> > > > > session? This
> > > > > > way we would have = established these two sessions between
> > > > > the gateways
> > > > > > and all the subsequent = ISUP messages would be sent over the
> > > > SIGTRAN
> > > > > > session.
> > > > > >
> > > > > > I find that the usage = of SIP that I have just
> described would
> > be
> > > > OK.
> > > > > > What I do not = understand is why folks want to use SIP for
> > > > > transporting
> > > > > > subsequent ISUP = messages. SIP does not have good transport
> > > > > properties
> > > > > > (big overhead, it can = run over UDP...). Besides, it does not
> > > > provide
> > > > > > ordered = delivery.
> > > > > >
> > > > > > If the INVITE has = Cseq=3D1 and the next message that the
> > > > > egrees gateway
> > > > > > receives is a INFO = with Cseq=3D7... what should the
> gateway do?
> > > > Maybe
> > > > > > there were several = proxies in the middle asking for
> > > > > credentials for the
> > > > > > INFO, so the ingrees = gateway had to add authentication
> > > > > stuff and resend
> > > > > > the INFO. If this was = the case, the SAM contained in the
> > > > > INFO would be
> > > > > > the second digit of = the called party number...
> However, maybe
> > 5
> > > > INFO
> > > > > > messages got lost, and = the SAM that we have received in the
> > > > > body of the
> > > > > > INFO makes no sense = without the previous ones because is
> > > > > the 7th digit
> > > > > > of the = number...
> > > > > >
> > > > > > This is not usually a = problem in SIP, since all
> > > messages have full
> > > >
> > > > > > state. However, using = INFO for sending SAMs breaks this
> > > rule, and
> > > > > > therefore it breaks = the SIP model.
> > > > > >
> > > > > > I believe that = considering that the session is established
> > after
> > > > the
> > > > > > first INVITE and = sending the following SAMs using INFO is
> > > > > making one of
> > > > > > the mistakes described = in the guidelines for SIP authors:
> > > > > "We need to
> > > > > > transport ISUP = signalling over IP between two gateways.
> > > > > Both gateways
> > > > > > already implement = SIP... why do we have to implement
> > > > > another protocol?
> > > > > > Let's use SIP to = transport ISUP signalling". We are just
> > > > > trying to use
> > > > > > SIP for this just = because it would save implementing yet
> > another
> > > > > > protocol in the = gateways.
> > > > > >
> > > > > > I strongly disagree = with this usage of SIP. SIP-T is good
> > > > > as long as the
> > > > > > SIP cloud provides = services. If not, SIP-T is not a good
> > > > > protocol for
> > > > > > transporting ISUP = signalling.
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Gonzalo
> > > > > >
> > > > > >  If you believe = that the sip role encompasses functions that
> > > > > > > might apply to = the PSTN subscribers, then you need to
> > > > > have the entire
> > > > > > > number, and the = multiple call leg approach is the
> right way
> > to
> > > > go.
> > > > > > >
> > > > > > > The multiple call = leg approach is clearly ugly and
> > > > > inelegant, but it has = the
> > > > > > > nice property of = completely masking the existence of
> > > > > overlap from proxies
> > > > > > > and app servers = within the network, allowing them to
> > > > > provide services in = the
> > > > > > > normal = way.
> > > > > > >
> > > > > > > -Jonathan = R.
> > > > > > >
> > > > > > > ---
> > > > > > > Jonathan D. = Rosenberg          &nb= sp;            = 72 Eagle Rock
> > Ave.
> > > > > > > Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> > > > > > > = dynamicsoft          &= nbsp;           &= nbsp;          East =
> Hanover, NJ
> >
> > > > 07936
> > > > > > > = jdrosen@dynamicsoft.com        &= nbsp;            = FAX:   (973)
> > > > 952-5050
> > > > > > > http://www.cs.columbia.edu/~jdrosen  &nb= sp;      PHONE: (973)
> > > > 952-5000
> > > > > > > http://www.dynamicsoft.com
> > > > > > >
> > > > > > > -----Original = Message-----
> > > > > > > From: Tom-PT = Taylor [mailto:taylor@nortelnetworks.c= om]
> > > > > > > Sent: Thursday, = February 08, 2001 7:00 AM
> > > > > > > To: Gonzalo = Camarillo
> > > > > > > Cc: Christer = Holmberg; sip@lists.bell-labs.com
> > > > > > > Subject: RE: = [SIP] Operlap dialing within a SIP network
> > > > > > >
> > > > > > > You are correct = about using some other means of
> transport if
> >
> > > > ISUP
> > > > > > > trans-shipment is = all your network is doing.  If the call
> > > > > destination (to a
> > > > > > > SIP endpoint, to = an H.323 endpoint, to a PSTN endpoint)
> > > > > varies on a per-call
> > > > > > > basis, however, = using SIP to establish your call routing
> > > > > leads to using SIP
> > > > > > > to carry the = ISUP.
> > > > > > > > = -----Original Message-----
> > > > > > > > From: = Gonzalo Camarillo
> > > > > [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > > > > > > Sent: = Tuesday, February 06, 2001 9:52 PM
> > > > > > > > To: Taylor, = Tom-PT [NORSE:B901:EXCH]
> > > > > > > > Cc: Christer = Holmberg; sip@lists.bell-labs.com
> > > > > > > > Subject: Re: = [SIP] Operlap dialing within a SIP network
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi = Tom,
> > > > > > > >
> > > > > > > > Still I want = to have full state in every SIP message.
> > > > > If the call is
> > > > > > > > addresed to = the phone number 1234, I want to have a to
> > > > > field that says
> > > > > > > > 1234. I do = not care if there is a leg routed thru the
> > > > > PSTN and another
> > > > > > > > thru = SIP.
> > > > > > > >
> > > > > > > > Carrying = full state is one of the beauties of SIP. If
> > > > > we begin using
> > > > > > > > INFO for = this, it would be the same as using SAMs.
> > > > > Differen names, the
> > > > > > > > same = thing... I do not want to re-create ISUP
> using SIP. I
> >
> > > > > > > > believe = that
> > > > > > > > if the = session has a destination, it should be
> > > present in the
> > > > > > > > to = field.
> > > > > > > >
> > > > > > > > Again, if a = proxy is providing services for this
> > > > > particular call, it
> > > > > > > > will want to = see the called party number in order to
> > trigger
> > > > > > > > the = proper
> > > > > > > > service. = This is a very good reason for updating
> > > the to field
> > > > > > > > every = time
> > > > > > > > we have more = digits.
> > > > > > > >
> > > > > > > > I like to = use SIP between two gateways because it
> > > is possible
> > > > > > > > to = provide
> > > > > > > > SIP services = for a PSTN to PSTN call. If all we
> > > want to do is
> > > > > > > > finding = a
> > > > > > > > egrees = gateway, we would probably want to use other
> > > > > protocols (TRIP = &
> > > > > > > > SIGTRAN for = instance).
> > > > > > > >
> > > > > > > > = Regards,
> > > > > > > >
> > > > > > > > = Gonzalo
> > > > > > > >
> > > > > > > > Tom-PT = Taylor wrote:
> > > > > > > > >
> > > > > > > > > Sorry, = we're talking past each other.  The
> premise of my
> >
> > > > > > > > statements = is
> > > > > > > > > that an = INVITE has reached a UAS which has accepted
> > > > > it.  It follows
> > > > > > > > > that = the UAS did not send back a 484, but rather
> > > an interim
> > > > > > > > = response.
> > > > > > > > > IF more = digits come along, the INFO method is there
> > > > > to carry them.
> > > > > > > > > They do = not affect the SIP call state; they are used
> > > > > beyond the UAS,
> > > > > > > > > either = in a PSTN call or in another SIP call as the
> > > > > case may be.
> > > > > > > > >
> > > > > > > > > > = -----Original Message-----
> > > > > > > > > > = From: Gonzalo Camarillo
> > > > > [mailto:Gonzalo.Camaril= lo@lmf.ericsson.se]
> > > > > > > > > > = Sent: Tuesday, February 06, 2001 9:10 PM
> > > > > > > > > > = To: Taylor, Tom-PT [NORSE:B901:EXCH]
> > > > > > > > > > = Cc: Christer Holmberg; sip@lists.bell-labs.com
> > > > > > > > > > = Subject: Re: [SIP] Operlap dialing within a SIP
> > network
> > > > > > > > > = >
> > > > > > > > > = >
> > > > > > > > > > = Hello Tom,
> > > > > > > > > = >
> > > > > > > > > > = Tom-PT Taylor wrote:
> > > > > > > > > > = >
> > > > > > > > > > = > Just to re-hash, in the ISUP-SIP-ISUP
> > > context, once call
> > > >
> > > > > > > > > = signalling
> > > > > > > > > > = > has reached an egress gateway, SIP has
> done its job
> > --
> > > > > > > > = additional
> > > > > > > > > > = > digits will not change call state.  It is
> therefore
> > > > > > > > > > = reasonable to use
> > > > > > > > > > = > INFO to carry the additional digits.  If we
> > > are talking
> > > > > > > > > > = ISUP-SIP, once
> > > > > > > > > > = > the destination UAS or a UAS in a B2BUA has been
> > > > > > > > reached, the = same
> > > > > > > > >
> > > > > > > > > > = > consideration applies.
> > > > > > > > > > = >
> > > > > > > > > = >
> > > > > > > > > > I = do not agree with these two statements:
> > > > > > > > > = >
> > > > > > > > > > = The 1st INVITE (with just some digits) arrives to a
> > > > > > > > vanilla SIP = UA.
> > > > > > > > > = I
> > > > > > > > > > = will return a Not Found or a 484 Address incomplete.
> > The
> > > > > > > > > > = subsequent INFO
> > > > > > > > > > = carrying more digits will be discarded. Thus, the
> > > > > PSTN to SIP
> > > > > > > > > = gateway
> > > > > > > > > > = will have to re issue a new INVITE with all the
> > digits.
> > > > > > > > > > = Therefore, it is
> > > > > > > > > > = better to begin directly using er-INVITEs
> rather than
> > > > INFO.
> > > > > > > > > = >
> > > > > > > > > > = Besides, I do not think that SIP is just a
> > > > > transport protocol = that
> > > > > > > > > > = carries ISUP messages between two gateways. For
> > > > > that, we have
> > > > > > > > > = already
> > > > > > > > > > = SIGTRAN. SIP might be used to provide services,
> > > > > even when the
> > > > > > > > > > = call is a
> > > > > > > > > > = PSTN-SIP-PSTN call. Thus, SIP messages MUST
> > > carry complete
> > > >
> > > > > > > > > > = state. And a
> > > > > > > > > > = SIP message with an incomplete to field does not
> > > > > carry complete
> > > > > > > > > = state.
> > > > > > > > > > = What if my SIP proxy provides a service for a
> > > > > PSTN-SIP-PSTN call
> > > > > > > > > = based
> > > > > > > > > > on = the to field (called party number). That proxy
> > would
> > > > > > > > like to = see
> > > > > > > > > = an
> > > > > > > > > > = updated to field, not just a to field that contains
> > > > > just some
> > > > > > > > > = digits.
> > > > > > > > > = >
> > > > > > > > > > = Best regards,
> > > > > > > > > = >
> > > > > > > > > > = Gonzalo
> > > > > > > > > = >
> > > > > > > > > = >
> > > > > > > > > > >= ; > -----Original Message-----
> > > > > > > > > > = > > From: Christer Holmberg
> > > > > > > > > [mailto:christer.holmbe= rg@lmf.ericsson.se]
> > > > > > > > > > = > > Sent: Tuesday, February 06, 2001 1:15 AM
> > > > > > > > > > = > > To: Gonzalo Camarillo
> > > > > > > > > > = > > Cc: sip@lists.bell-labs.com
> > > > > > > > > > = > > Subject: Re: [SIP] Operlap dialing within a SIP
> > > > network
> > > > > > > > > > = > >
> > > > > > > > > > = > >
> > > > > > > > > > = > >
> > > > > > > > > > = > > Hi Gonzalo,
> > > > > > > > > > = > >
> > > > > > > > > > = > > I didn't say I am going to use INFO, but that
> > > > > is what has
> > > > > > > > > > = > > been proposed
> > > > > > > > > > = > > earlier in this thread, so I assumed INFO would
> > > > > be used. The
> > > > > > > > > > = > > reason for
> > > > > > > > > > = > > the discussion from the beginning was that
> > > the overlap
> > > >
> > > > > > > > > = signalling,
> > > > > > > > > > = > > according to the SIP-ISUP mapping draft,
> > > may not work
> > > > > > > > > > = very well, and
> > > > > > > > > > = > a
> > > > > > > > > > = > > solution using 18x responses and INFO messages,
> > > > > instead of 484
> > > > > > > > > = and
> > > > > > > > > > = > > re-INVITEs, was proposed.
> > > > > > > > > > = > >
> > > > > > > > > > = > > Regards,
> > > > > > > > > > = > >
> > > > > > > > > > = > > Christer Holmberg
> > > > > > > > > > = > > Ericsson Finland
> > > > > > > > > > = > >
> > > > > > > > > > = > >
> > > > > > > > > > = > >
> > > > > > > > > > = > > Gonzalo Camarillo wrote:
> > > > > > > > > > = > > >
> > > > > > > > > > = > > > Hello Christer,
> > > > > > > > > > = > > >
> > > > > > > > > > = > > > Why are you using INFO for sending
> extra digits?
> >
> > > > > > > > > > = > > >
> > > > > > > > > > = > > > Please, check the SIP-ISUP mapping draft,
> > overlap
> > > > > > > > > > = > > signalling section.
> > > > > > > > > > = > > >
> > > > > > > > > > = > > > Regards,
> > > > > > > > > > = > > >
> > > > > > > > > > = > > > Gonzalo
> > > > > > > > > > = > > >
> > > > > > > > > > = > > > Christer Holmberg wrote:
> > > > > > > > > > = > > > >
> > > > > > > > > > = > > > > Hi,
> > > > > > > > > > = > > > >
> > > > > > > > > > = > > > > The discussion about overlap dialing has
> > > > > been pretty much
> > > > > > > > > > = > > about calls
> > > > > > > > > > = > > > > from SIP to PSTN, or PSTN-SIP-PSTN.
> > > > > > > > > > = > > > >
> > > > > > > > > > = > > > > Consider the following scenario.
> > > > > > > > > > = > > > >
> > > > > > > > > > = > > > > PSTN = PHONE           &= nbsp; GW           =
> SIP SERVER
> >
> > > > > > > >   = SIP UAS
> > > > > > > > > > = > > > >
> > > > > > > >
> > = -----------------------------------------------------------
> > > > > > > > > > = > > > >
> > > > > > > > > > = > > > > --- 1 --->    -- IAM -> | -- = INVITE -->  |
> > > > > > > > > > = > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > > > > = > > > > --- 2 --->    -- SAM -> | -- = INFO ---->  |
> > > > > > > > > > = > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |
> > > > > > > > > > = > > > = >           &n= bsp;           &n= bsp; | <- 18x ------  |
> > > > > > > > > > = > > > > --- 3 --->    -- SAM -> | -- = INFO ---->  |
> > > > > > > > > > = > > > = >           &n= bsp;           &n= bsp; | <- 200 (INFO)  |
> > > > >  -- INVITE
> > > > > > > > > > = > > > > -->
> > > > > > > > > > = > > > = >           &n= bsp;           &n= bsp; | <- 200 (INVITE)|
> > > > >  <- 200 = ------
> > > > > > > > > > = > > > >
> > > > > > > > > > = > > > > In this case, the SIP server (note that I
> > > > > am not using
> > > > > > > > > > = > > the word 'proxy')
> > > > > > > > > > = > > > > must collect digits, sent from the PSTN
> > > side using
> > > >
> > > > > > > > > > = > > overlap dialing, to
> > > > > > > > > > = > > > > be able to find the SIP UAS, and INFO is
> > > > > used to provide
> > > > > > > > > > = > > the digits
> > > > > > > > > > = > > > > after the INVITE has been sent.
> > > > > > > > > > = > > > >
> > > > > > > > > > = > > > > My question is, should a SIP server (proxy,
> > > > > if you like)
> > > > > > > > > > = > > be allowed to
> > > > > > > > > > = > > > > behave like this, or MUST it send 486s, and
> > > > > receive new
> > > > > > > > > > = > > INVITEs, until
> > > > > > > > > > = > > > > it is able to find the UAS?
> > > > > > > > > > = > > > >
> > > > > > > > > > = > > > > Regards,
> > > > > > > > > > = > > > >
> > > > > > > > > > = > > > > Christer Holmberg
> > > > > > > > > > = > > > > Ericsson Finland
> > > > > > > > > > = > > >
> > > > > > > > > > = > > > --
> > > > > > > > > > = > > > Gonzalo = Camarillo         Phone :  = +358
> > > 9 299 33 71
> > > >
> > > > > > > > > > = > > > Oy L M Ericsson = Ab        Mobile:  +358
> > > 40 702 35 35
> > > >
> > > > > > > > > > = > > > Telecom = R&D           = ;    Fax   :  +358
> > > 9 299 30 52
> > > >
> > > > > > > > > > = > > > FIN-02420 = Jorvas          Email = :
> > > > > > > > > > = Gonzalo.Camarillo@ericsson.com
> > > > > > > > > > = > > > Finland
> > > http://www.hut.fi/~gonzalo
> > > >
> > > > > > > > > > = > >
> > > > > > > > > = >
> > > > > > > > > > = --
> > > > > > > > > > = Gonzalo Camarillo         Phone = :  +358  9 299 33 71
> > > > > > > > > > Oy = L M Ericsson Ab        Mobile:  = +358 40 702 35 35
> > > > > > > > > > = Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > > > > > > > = FIN-02420 Jorvas          = Email :
> > > > > = Gonzalo.Camarillo@ericsson.com
> > > > > > > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > > > > > > = >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > > > > > Oy L M = Ericsson Ab        Mobile:  = +358 40 702 35 35
> > > > > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > > > > > FIN-02420 = Jorvas          Email = :
> > > > > = Gonzalo.Camarillo@ericsson.com
> > > > > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > > > > >
> > > > > >
> > > > > > --
> > > > > > Gonzalo = Camarillo         Phone :  = +358  9 299 33 71
> > > > > > Oy L M Ericsson = Ab        Mobile:  +358 40 702 = 35 35
> > > > > > Telecom = R&D           = ;    Fax   :  +358  9 299 30 = 52
> > > > > > FIN-02420 = Jorvas          Email = :
> > > Gonzalo.Camarillo@ericsson.com
> > > > > > = Finland           = ;        http://www.hut.fi/~gonzalo
> > > > > >
> > > > > > = _______________________________________________
> > > > > > This list is for = continuing development of the SIP protocol.
> > > > > > The sip-implementer's = list is the place to discuss
> > > implementation,
> > > >
> > > > > > and to receive advice = on understanding existing sip.
> > > > > > To subscribe to it, = send mail to majordomo@cs.columbia.edu
> > with
> > > > > > "subscribe = sip-implementors" in the body.
> > > > >
> > > > > --
> > > > > Gonzalo = Camarillo          &nb= sp;         Phone :   = +1 212
> 939 71 71
> > > > > Columbia = University          &n= bsp;       Mobile:  +358 40
> 702 35 35
> > > > > 472 Computer Science = Building        Fax   = :  +358  9
> 299 30 52
> > > > > 1214 Amsterdam Ave., Mail = Code 0401 
> http://www.hut.fi/~gonzalo
> > > > > New York, NY 10027
> > > > > = USA           &nb= sp;           &nb= sp;     
> Gonzalo.Camarillo@ericsson.com
> > > > >
> > > > > = _______________________________________________
> > > > > This list is for continuing = development of the SIP protocol.
> > > > > The sip-implementer's list = is the place to discuss
> > implementation,
> > > > > and to receive advice on = understanding existing sip.
> > > > > To subscribe to it, send = mail to
> majordomo@cs.columbia.edu with
> > > > > "subscribe = sip-implementors" in the body.
> > > > >
> > >
>

------_=_NextPart_001_01C09B46.81E1AA80-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 20 12:14:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17008 for ; Tue, 20 Feb 2001 12:14:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 707984437B; Tue, 20 Feb 2001 12:14:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ns-inetext.inet.com (ns-inetext.inet.com [199.171.211.140]) by lists.bell-labs.com (Postfix) with ESMTP id 1C4B744352 for ; Tue, 20 Feb 2001 12:13:51 -0500 (EST) Received: from harpo.inetint.com (harpo [172.16.99.60]) by ns-inetext.inet.com (8.9.2/8.9.2) with ESMTP id LAA07906 for ; Tue, 20 Feb 2001 11:13:50 -0600 (CST) Received: from inet.com ([172.16.13.210]) by harpo.inetint.com (Netscape Messaging Server 3.6) with ESMTP id AAA7307 for ; Tue, 20 Feb 2001 11:13:51 -0600 Message-ID: <3A92A5C9.C9B64F9B@inet.com> From: Charles Zeng X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: zh-TW, zh-CN, en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] A question of contact header? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 20 Feb 2001 11:13:45 -0600 Content-Transfer-Encoding: 7bit Hi All, Can I use one IP process all incoming INVITE msg. And use another IP to send all 1xx and 2xx msg with the contact header associate. Does the SIP required one transation should be finish in same IP source. Best regards. Charles Zeng _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Tue Feb 20 14:22:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21574 for ; Tue, 20 Feb 2001 14:22:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 090EB44352; Tue, 20 Feb 2001 14:22:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5]) by lists.bell-labs.com (Postfix) with ESMTP id 023DE4434F for ; Tue, 20 Feb 2001 14:21:36 -0500 (EST) Received: from blv-av-01.boeing.com ([192.54.3.60]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA07304 for ; Tue, 20 Feb 2001 11:21:36 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2) with ESMTP id LAA27187 for ; Tue, 20 Feb 2001 11:21:34 -0800 (PST) Received: from xch-pssbh-03.ca.boeing.com by blv-hub-01.boeing.com with ESMTP for sip@lists.bell-labs.com; Tue, 20 Feb 2001 11:21:17 -0800 Received: by xch-pssbh-03.ca.boeing.com with Internet Mail Service (5.5.2650.21) id ; Tue, 20 Feb 2001 11:21:16 -0800 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12ADF@XCH-NW-01.ca.boeing.com> From: "Fleischman, Eric W" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Question about encrypted SIP products Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 20 Feb 2001 11:21:14 -0800 I'm new to this list and am interested in learning about any SIP applications or products that support encryption (privacy). Specifically, I would appreciate receiving private messages from anyone on this list providing me with information about SIP products or advances which support encryption. The reason for my query is that I am not aware of any existing SIP products which currently support encryption. However, many of our environments require that our collaboration sessions be encrypted due to firm privacy requirements. Thus, it seems probable to me that there must be some SIP products somewhere supporting this capability. I would appreciate pointers to any such products, as well as to technical descriptions concerning how the encryption is being done on these products (e.g., can these encrypted sessions also support QoS and multicast?). Thank you for your attention to this query. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 02:13:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20225 for ; Wed, 21 Feb 2001 02:13:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6108844342; Wed, 21 Feb 2001 02:13:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id 9124844336 for ; Wed, 21 Feb 2001 02:12:44 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <1GB0VKS8>; Tue, 20 Feb 2001 23:10:56 -0800 Received: from rwcjfmule01 (10.1.1.2 [10.1.1.2]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GB0VKS7; Tue, 20 Feb 2001 23:10:54 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Christer Holmberg'" , sip@lists.bell-labs.com Cc: stanley.khouw@clarent.com, jieying@clarent.com, "'Culpepper, Bert'" Subject: RE: [SIP] T.38 and multiple streams Message-ID: <01f201c09bd5$7b64b230$d05467d8@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A90D476.EF8D4FBD@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 20 Feb 2001 23:11:14 -0800 Content-Transfer-Encoding: 7bit Thanks for the comments & questions. Reply in the text below - in short I mostly agree with Bert's comments. Basically, the current ID on sip t.38 was a first text to stimulate comments. A couple of other errors have already been raised (Cseq, Record-route headers). From this discussion, I note the following: - sip-t38 text should be updated to better represent the possible choices (a/ fax only comm; b/ voice then fax then voice again; c/ voice, then both voice+fax back to voice only) - call flow should be updated also to follow the recommendations made in t.38 annex D for sip (note that the current call flow represents the voice then fax then voice again case which is a possible real-life case). Jean-Francois Mule Clarent Corp. Christer Holmberg wrote: > 1. F11 INVITE IFTGW UA -> PROXY > > In this re-INVITE we add the fax stream to the call. However, t.38 for > SIP recommendation it says that the existing voice stream > should remain, > so shouldn't the original voice parameters (m line etc) be included in > the re-INVITE SDP? In the current ID, we terminate the audio stream and negotiate just a fax stream (case b/ above). Yes, we should probably not shut down the voice stream to mute it, i agree ;-) --> if there is an agreement that the best practice is c/, we'll update the Internet-draft. Note however that the current call flow is not illegal... > 2. This questions is depending on the first. > > Like I said, the recommendation says that the existing voice stream > should remain, but that it should be muted during the fax > transmission. *should* yes, we should correct that by "adding" a fax stream. Will propose new call flow for review in the next couple of days. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 02:23:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20314 for ; Wed, 21 Feb 2001 02:23:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1DA5E4433E; Wed, 21 Feb 2001 02:23:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id DCA6944336 for ; Wed, 21 Feb 2001 02:22:02 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <1GB0VK4B>; Tue, 20 Feb 2001 23:20:14 -0800 Received: from rwcjfmule01 (10.1.1.2 [10.1.1.2]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GB0VK4A; Tue, 20 Feb 2001 23:20:08 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Christer Holmberg'" , "'Culpepper, Bert'" Cc: sip@lists.bell-labs.com, stanley.khouw@clarent.com, jieying@clarent.com Subject: RE: [SIP] T.38 and multiple streams Message-ID: <01f601c09bd6$c49946e0$d05467d8@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A917BC8.6CC674C1@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 20 Feb 2001 23:20:27 -0800 Content-Transfer-Encoding: 7bit Thanks Bert for the clarifications and opinions. See comments below. Jean-Francois. -------------- Bert Culpepper wrote: > Yes, that is true. The recommendation, however, says that the > fax stream > should be ADDED to the connection, not REPLACE the voice stream. This will be corrected. Again it says *SHOULD* be added. Note that there are cases where you would want to release the resources for the audio streams when a fax is detected (for e.g. when your DSP pool is running out of gas, should that ever happen...) > >If the egress gateway wanted to mute the audio using the > method defined in > >the SIP RFC, it would have included both media descriptions and an > >additional c= line for one of media descriptions. By having > a c= line in > >the T.38 media description, the egress gateway could place > the audio on hold > >(using IP address of 0.0.0.0 in the main session > description) and still have > >the T.38 session. SDP (RFC 2327) allows c= lines in media > descriptions > >(that only apply to the one media stream) which override c= > lines in the > >main session description. A possibly more explicit session > description > >would not have a c= line in the general session description > and c= lines in > >each media description. I prefer the second option (no general c= line, one c= line per media description). Shall we recommend this second option in the updated paper? > >So RFC 2327 allows placing the audio on hold while the T.38 > is active at the > >protocol level. > > It was my understanding from the T.38 on IP recommendation > that this is > the way it should work. We should add the fax stream, and > mute the voice > stream instead of removing it, ie using a separate c= lines for each > media stream. I don't want to free resources I've used for the voice > when transmitting the fax, since I will probably need them if I switch > back from fax to voice. Agreed. As a side note, how many of us send a fax and then return to an audio call once fax transmission is complete? _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 09:50:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28270 for ; Wed, 21 Feb 2001 09:50:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 464BB44344; Wed, 21 Feb 2001 09:50:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id DF9F944336 for ; Wed, 21 Feb 2001 09:49:25 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id IAA09864; Wed, 21 Feb 2001 08:48:59 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Wed, 21 Feb 2001 08:45:16 -0600 Message-ID: From: "Culpepper, Bert" To: Jean-Francois Mule , "'Christer Holmberg'" Cc: sip@lists.bell-labs.com, stanley.khouw@clarent.com, jieying.li@claren.com Subject: RE: [SIP] T.38 and multiple streams MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 21 Feb 2001 08:45:15 -0600 Hi, comments below... > -----Original Message----- > From: Jean-Francois Mule [mailto:jfmule@clarent.com] > Sent: Wednesday, February 21, 2001 2:20 AM > To: 'Christer Holmberg'; 'Culpepper, Bert' > Cc: sip@lists.bell-labs.com; stanley.khouw@clarent.com; > jieying@clarent.com > Subject: RE: [SIP] T.38 and multiple streams > > > Thanks Bert for the clarifications and opinions. See comments below. > Jean-Francois. > -------------- > Bert Culpepper wrote: > > Yes, that is true. The recommendation, however, says that the > > fax stream > > should be ADDED to the connection, not REPLACE the voice stream. > This will be corrected. Again it says *SHOULD* be added. > Note that there are cases where you would want to release the > resources for > the audio streams when a fax is detected (for e.g. when your > DSP pool is > running out of gas, should that ever happen...) > > > >If the egress gateway wanted to mute the audio using the > > >method defined in > > >the SIP RFC, it would have included both media descriptions and an > > >additional c= line for one of media descriptions. By having > > >a c= line in > > >the T.38 media description, the egress gateway could place > > >the audio on hold > > >(using IP address of 0.0.0.0 in the main session > > >description) and still have > > >the T.38 session. SDP (RFC 2327) allows c= lines in media > > >descriptions > > >(that only apply to the one media stream) which override c= > > >lines in the > > >main session description. A possibly more explicit session > > >description > > >would not have a c= line in the general session description > > >and c= lines in each media description. > I prefer the second option (no general c= line, one c= line per media > description). Shall we recommend this second option in the > updated paper? I prefer the second option too. c= lines in the media descriptions are required when a session has more than one media stream and they need to be controlled independently. > > > >So RFC 2327 allows placing the audio on hold while the T.38 > > >is active at the protocol level. > > > > It was my understanding from the T.38 on IP recommendation > > that this is > > the way it should work. We should add the fax stream, and > > mute the voice > > stream instead of removing it, ie using a separate c= lines for each > > media stream. I don't want to free resources I've used for the voice > > when transmitting the fax, since I will probably need them if I switch > > back from fax to voice. > Agreed. As a side note, how many of us send a fax and then > return to an > audio call once fax transmission is complete? My voice and fax communications are curently separate calls. But I don't have access to a SIP-enabled terminal capable of simultaneous voice and fax, yet :-) Regards, Bert > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 10:05:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28924 for ; Wed, 21 Feb 2001 10:05:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB1454435F; Wed, 21 Feb 2001 10:05:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (bounty.cisco.com [64.102.17.204]) by lists.bell-labs.com (Postfix) with ESMTP id AE6224434D for ; Wed, 21 Feb 2001 10:04:21 -0500 (EST) Received: from cisco.com (dhcp-64-102-97-116.cisco.com [64.102.97.116]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA04599; Wed, 21 Feb 2001 10:03:40 -0500 (EST) Message-ID: <3A93DA15.8040400@cisco.com> From: Suheel Hussain Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [SIP] NOTIFY response in REFER method Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 21 Feb 2001 10:09:09 -0500 Content-Transfer-Encoding: 7bit Folks, This question may have been answered before. Question: Does Transferee return NOTIFY-refersuccess if TransferTarget returns 180 ringing (in response to INVITE from Transferee)? Would appreciate help. -- Suheel Hussain ssh@cisco.com Work # (919) 392-2312 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 14:54:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07675 for ; Wed, 21 Feb 2001 14:54:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C736C44345; Wed, 21 Feb 2001 14:54:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 2A7A744336 for ; Wed, 21 Feb 2001 14:53:06 -0500 (EST) 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 f1LJovd29708; Wed, 21 Feb 2001 20:50:58 +0100 (MET) Received: from lmf.ericsson.se ([136.225.183.46]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id UAA24740; Wed, 21 Feb 2001 20:50:51 +0100 (MET) Message-ID: <3A941C23.7F83ABF2@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: mwatson@nortelnetworks.com, Gonzalo.Camarillo@lmf.ericsson.se, Keith.Robinson@marconi.com, jdrosen@dynamicsoft.com, taylor@nortelnetworks.com Subject: Re: [SIP] Operlap dialing within a SIP network References: Content-Type: multipart/mixed; boundary="------------F840677577C8EABAE1C5EDB0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 21 Feb 2001 21:50:59 +0200 This is a multi-part message in MIME format. --------------F840677577C8EABAE1C5EDB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I here try to make some kind of conclusion of the discussion. ISSUES NO MATTER WHICH METHOD IS USED: -------------------------------------- 1. We should be allowed to insert Route headers in initial INVITEs AND/OR 2. There should be some kind of routing mechnism in the proxis to make sure that additional INVITEs are routed to the same gateway. 3. If a proxy routes additional INVITEs to another gateway, we may get multiple IAMs. At least the two first issues here are general issues for SIP, and not only related to the overlap dialing. The third issue is related to PSTN interworking in general, because because of forking and/or request re-transmission INVITEs may end up at different gateways. ISSUES WITH THE INFO METHOD: ---------------------------- 4. We must wait for the response from the previous request before we send an INFO. 5. Requires new extensions (header, option-tags,...?) ISSUES WITH THE INVITE: ----------------------- 6. Depending on the number of INVITEs that the gateway mangages to route to the next PSTN entity, we will have a number of pending INVITE transactions, since we only get a provisional response to those INVITEs until one INVITE finaly has enough digits to generate a 200, plus 484 for all the pending requests. 7. One extra message, the ACK, for each INVITE. One ACK is nothing, but if you have 20000 of them... I didn't include the issue of "when a call is completely routed from a SIP point of view", because we can spend months arguing about that - and I anyway think we should make our solutions depending on what's best from a TECHNICAL point of view, not from a definition point of view. I've said it before, and I'll say it again, that I am not against the idea of using INFO. However, I PERSONALY don't think the advantages compared to INVITEs are so big that we should spend time on that (we MUST, however, clarify the provisional response thing, and which final responses will be sent to the pending INVITEs, in the ISUP-SIP draft). Instead, I think we should put our efforts on, among other things, the general SIP issues (1-3) we have no matter which overlap dialing method we have, and which we also have in other SIP scenarios. Regards, Christer Holmberg Ericsson Finland --------------F840677577C8EABAE1C5EDB0 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 --------------F840677577C8EABAE1C5EDB0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 15:24:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08737 for ; Wed, 21 Feb 2001 15:24:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EAC0E4435B; Wed, 21 Feb 2001 15:24:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 8F57444336; Wed, 21 Feb 2001 15:23:27 -0500 (EST) Received: from conrail.cs.columbia.edu (conrail.cs.columbia.edu [128.59.19.147]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA23400; Wed, 21 Feb 2001 15:23:22 -0500 (EST) Received: (from lennox@localhost) by conrail.cs.columbia.edu (8.9.3/8.9.1) id PAA42151; Wed, 21 Feb 2001 15:23:05 -0500 (EST) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14996.9129.342352.73285@conrail.cs.columbia.edu> To: c603273@vus069.trl.telstra.com.au (Brian Keck) Cc: sip@lists.bell-labs.com, c603273@trl.telstra.com.au, sip-admin@lists.bell-labs.com Subject: Re: [SIP] error in mailing list footer In-Reply-To: <20010220043109.B762F75E01@castor.trl.telstra.com.au> References: <20010220043109.B762F75E01@castor.trl.telstra.com.au> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 21 Feb 2001 15:23:05 -0500 (EST) Content-Transfer-Encoding: 7bit On Tuesday, February 20 2001, "Brian Keck" wrote to "sip@lists.bell-labs.com, c603273@trl.telstra.com.au, sip-admin@lists.bell-labs.com" saying: > > Sorry if I've aimed this badly ... > > On Thu, 15 Feb 2001 14:59:58 CDT, Jonathan Rosenberg wrote: > ... > >This list is for continuing development of the SIP protocol. > >The sip-implementer's list is the place to discuss implementation, > >and to receive advice on understanding existing sip. > >To subscribe to it, send mail to majordomo@cs.columbia.edu with > >"subscribe sip-implementors" in the body. > > That majordomo hasn't heard of any sip* list Yes, the sip-implementors list has been switched to being run by the 'mailman' program, rather than 'majordomo'. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body, or visit for a web interface. I've asked the lists.bell-labs.com sysadmins to update the list footer. -- Jonathan Lennox lennox@cs.columbia.edu sip-implementors-admin@cs.columbia.edu _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementer's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to majordomo@cs.columbia.edu with "subscribe sip-implementors" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 17:30:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12600 for ; Wed, 21 Feb 2001 17:30:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6CE384434F; Wed, 21 Feb 2001 17:30:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 1211B44336 for ; Wed, 21 Feb 2001 17:29:12 -0500 (EST) 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 f1LMT7C24022; Wed, 21 Feb 2001 23:29:07 +0100 (MET) Received: from lmf.ericsson.se ([136.225.183.50]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA01209; Wed, 21 Feb 2001 23:29:00 +0100 (MET) Message-ID: <3A944134.ED4DF2D6@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: Jean-Francois Mule , sip@lists.bell-labs.com, stanley.khouw@clarent.com, jieying.li@claren.com Subject: Re: [SIP] T.38 and multiple streams References: Content-Type: multipart/mixed; boundary="------------E391485F81F32A2996691B7D" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 00:29:08 +0200 This is a multi-part message in MIME format. --------------E391485F81F32A2996691B7D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, More of my comments. "Culpepper, Bert" wrote: > > Hi, > > comments below... > > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jfmule@clarent.com] > > Sent: Wednesday, February 21, 2001 2:20 AM > > To: 'Christer Holmberg'; 'Culpepper, Bert' > > Cc: sip@lists.bell-labs.com; stanley.khouw@clarent.com; > > jieying@clarent.com > > Subject: RE: [SIP] T.38 and multiple streams > > > > > > Thanks Bert for the clarifications and opinions. See comments below. > > Jean-Francois. > > -------------- > > Bert Culpepper wrote: >>>Yes, that is true. The recommendation, however, says that the >>>fax stream should be ADDED to the connection, not REPLACE the voice stream. >>This will be corrected. Again it says *SHOULD* be added. >>Note that there are cases where you would want to release the >>resources for the audio streams when a fax is detected (for e.g. when your >>DSP pool is running out of gas, should that ever happen...) Of course, but then I think we should include all possible scenarios in the call flows draft. Currently we only include one, and it's not even the one according to the recommendation, ie the *SHOULD* :) We should remember, though, that even if the fax initiator has enough DSP resources, the other party may not. So, another question is if he should be allowed to release the voice stream anyway, and somehow indicate that to the initiator, which then would know that it may not be possible to switch back to voice after the fax transmission... OR ...should be define some kind of "media stream could not be added" error response code, and send back. After that, the initiator could send a new re-INVITE, without the voice media description, and the receiver would terminate the voice stream and replace it with the fax stream. Things like this may of course be implementation issues, but I think it's good to define the behaviour, and include them in the call flows - to make sure we interop even when things don't work :) >>>>If the egress gateway wanted to mute the audio using the >>>>method defined in the SIP RFC, it would have included both media descriptions and an >>>>additional c= line for one of media descriptions. By having >>>>a c= line in the T.38 media description, the egress gateway could place >>>>the audio on hold (using IP address of 0.0.0.0 in the main session >>>>description) and still have the T.38 session. SDP (RFC 2327) allows c= lines in media >>>>descriptions (that only apply to the one media stream) which override c= >>>>lines in the main session description. A possibly more explicit session >>>>description would not have a c= line in the general session description >>>>and c= lines in each media description. >>I prefer the second option (no general c= line, one c= line per media >>description). Shall we recommend this second option in the >>updated paper? > >I prefer the second option too. c= lines in the media descriptions >are required when a session has more than one media stream and >they need to be controlled independently. I guess this also depends on what the SDP standard says. For example, when we establish the call for voice, we probably will have a general c= line. Is it then allowed, in the re-INVITE, to remove that and then suddenly insert the c= for the media description? >>>>So RFC 2327 allows placing the audio on hold while the T.38 >>>>is active at the protocol level. >>> >>>It was my understanding from the T.38 on IP recommendation >>>that this is the way it should work. We should add the fax stream, and >>>mute the voice stream instead of removing it, ie using a separate c= lines for each >>>media stream. I don't want to free resources I've used for the voice >>>when transmitting the fax, since I will probably need them if I switch >>>back from fax to voice. >>Agreed. As a side note, how many of us send a fax and then >>return to an audio call once fax transmission is complete? > >My voice and fax communications are curently separate calls. But >I don't have access to a SIP-enabled terminal capable of >simultaneous voice and fax, yet :-) I don't use fax at all :) Regards, Christer Holmberg Ericsson Finland > > Regards, > Bert > > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementer's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to majordomo@cs.columbia.edu with > > "subscribe sip-implementors" in the body. > > --------------E391485F81F32A2996691B7D 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 --------------E391485F81F32A2996691B7D-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 17:31:25 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12628 for ; Wed, 21 Feb 2001 17:31:24 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1C0D044366; Wed, 21 Feb 2001 17:30:22 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 5736544336 for ; Wed, 21 Feb 2001 17:29:27 -0500 (EST) 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 f1LMSud29441; Wed, 21 Feb 2001 23:28:57 +0100 (MET) Received: from lmf.ericsson.se ([136.225.183.50]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA01186; Wed, 21 Feb 2001 23:28:50 +0100 (MET) Message-ID: <3A94412A.1BA5613F@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule Cc: sip@lists.bell-labs.com, stanley.khouw@clarent.com, jieying@clarent.com, "'Culpepper, Bert'" Subject: Re: [SIP] T.38 and multiple streams References: <01f201c09bd5$7b64b230$d05467d8@rwcjfmule01> Content-Type: multipart/mixed; boundary="------------5EFB6338A2C83F516935C2D0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 00:28:58 +0200 This is a multi-part message in MIME format. --------------5EFB6338A2C83F516935C2D0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Jean-Francois Mule wrote: > > Thanks for the comments & questions. Reply in the text below - in short I > mostly agree with Bert's comments. > > Basically, the current ID on sip t.38 was a first text to stimulate > comments. A couple of other errors have already been raised (Cseq, > Record-route headers). From this discussion, I note the following: > - sip-t38 text should be updated to better represent the possible choices > (a/ fax only comm; b/ voice then fax then voice again; c/ voice, then both > voice+fax back to voice only) > - call flow should be updated also to follow the recommendations made in > t.38 annex D for sip (note that the current call flow represents the voice > then fax then voice again case which is a possible real-life case). > > Jean-Francois Mule > Clarent Corp. > > Christer Holmberg wrote: >>1. F11 INVITE IFTGW UA -> PROXY >> >>In this re-INVITE we add the fax stream to the call. However, t.38 for >>SIP recommendation it says that the existing voice stream >>should remain, >>so shouldn't the original voice parameters (m line etc) be included in >>the re-INVITE SDP? >In the current ID, we terminate the audio stream and negotiate just a fax >stream (case b/ above). >Yes, we should probably not shut down the voice stream to mute it, i agree >;-) >--> if there is an agreement that the best practice is c/, we'll update the >Internet-draft. Note however that the current call flow is not illegal... No, it's not illegal from a protocol point of view, but like you also mentioned, it doesn't follow the recommendation. >>2. This questions is depending on the first. >> >>Like I said, the recommendation says that the existing voice stream >>should remain, but that it should be muted during the fax >>transmission. >*should* >yes, we should correct that by "adding" a fax stream. Will propose new call >flow for review in the next couple of days. Great :) Regards, Christer Holmberg Ericsson Finland --------------5EFB6338A2C83F516935C2D0 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 --------------5EFB6338A2C83F516935C2D0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 17:33:06 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12658 for ; Wed, 21 Feb 2001 17:33:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 082B444370; Wed, 21 Feb 2001 17:31:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 6D78D44336 for ; Wed, 21 Feb 2001 17:30:05 -0500 (EST) 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 f1LMU4d29834 for ; Wed, 21 Feb 2001 23:30:04 +0100 (MET) Received: from lmf.ericsson.se ([136.225.183.50]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA01351 for ; Wed, 21 Feb 2001 23:30:00 +0100 (MET) Message-ID: <3A944170.91B8A1FA@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------95FA9117423177B2F88D3F7B" Subject: [SIP] Session-timer and REFER Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 00:30:08 +0200 This is a multi-part message in MIME format. --------------95FA9117423177B2F88D3F7B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, More about the session-timer... Assume user A establish a call with user B. A session-timer between A and B is also establish. Then, B wants to transfer A to user C, using REFER. A will then send INVITE to C and establish a session. However, the session between A and B is still open (even if there is no media) so the session-timer will continue between them. My first issue is that A (or B) may want to cancel the session-timer during the session with C, and then maybe use it again if the media is switched back to B at some stage. One solution would be for either A or B to increase the refresh timer during the A-to-C call, and then decrease it again if the A-to-B call continues, but is this possible? The other issue is if B re-boots. Now, if A is sending the refreshes, B will think it's a new call, so the phone will ring - AND, may start sending media to B's RTP port specified in the SDP in the re-INVITE. So, when A is talking to C, he may suddenly start hearing announcements, ring tones, or even someone talking, from B. A's call control will not know about this, since it will receive a 200 OK for the re-INVITE in either case. Comments? Regards, Christer Holmberg Ericsson Finland --------------95FA9117423177B2F88D3F7B 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 --------------95FA9117423177B2F88D3F7B-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 18:03:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13468 for ; Wed, 21 Feb 2001 18:03:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 621ED4436B; Wed, 21 Feb 2001 18:03:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4]) by lists.bell-labs.com (Postfix) with SMTP id 450C744378 for ; Wed, 21 Feb 2001 18:02:13 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 21 Feb 2001 15:01:18 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id <1SFW48Y6>; Wed, 21 Feb 2001 15:01:18 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD38D8D7@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "Christer Holmberg" , sip@lists.bell-labs.com Subject: RE: [SIP] Session-timer and REFER MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 168A9734148324-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 21 Feb 2001 15:01:17 -0800 Content-Transfer-Encoding: 7bit As far as I know you shd be able to modify session refreshes timeout anytime, by sending a new INVITE with a higher/lower Session-Expires timeout value..... The second problem of the UA mistaking a refresh for a new call is not possible, the To: tag in the INVITE would give away..... -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Wednesday, February 21, 2001 2:30 PM To: sip@lists.bell-labs.com Subject: [SIP] Session-timer and REFER Hi, More about the session-timer... Assume user A establish a call with user B. A session-timer between A and B is also establish. Then, B wants to transfer A to user C, using REFER. A will then send INVITE to C and establish a session. However, the session between A and B is still open (even if there is no media) so the session-timer will continue between them. My first issue is that A (or B) may want to cancel the session-timer during the session with C, and then maybe use it again if the media is switched back to B at some stage. One solution would be for either A or B to increase the refresh timer during the A-to-C call, and then decrease it again if the A-to-B call continues, but is this possible? The other issue is if B re-boots. Now, if A is sending the refreshes, B will think it's a new call, so the phone will ring - AND, may start sending media to B's RTP port specified in the SDP in the re-INVITE. So, when A is talking to C, he may suddenly start hearing announcements, ring tones, or even someone talking, from B. A's call control will not know about this, since it will receive a 200 OK for the re-INVITE in either case. Comments? Regards, Christer Holmberg Ericsson Finland _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 18:12:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13588 for ; Wed, 21 Feb 2001 18:12:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C29384437E; Wed, 21 Feb 2001 18:12:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id E41794437C for ; Wed, 21 Feb 2001 18:11:20 -0500 (EST) 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 f1LNBJC09472; Thu, 22 Feb 2001 00:11:20 +0100 (MET) Received: from lmf.ericsson.se ([136.225.183.50]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id AAA03261; Thu, 22 Feb 2001 00:11:14 +0100 (MET) Message-ID: <3A944B1B.60327D87@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Venkatesh Venkataramanan Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Session-timer and REFER References: <79FEAA5FABA7D411BF580001023D1BBD38D8D7@mailserver.sylantro.com> Content-Type: multipart/mixed; boundary="------------E5EC7E79E4A0C26B408AB3A9" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 01:11:23 +0200 This is a multi-part message in MIME format. --------------E5EC7E79E4A0C26B408AB3A9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >As far as I know you shd be able to modify session refreshes timeout >anytime, by sending a new INVITE with a higher/lower Session-Expires timeout >value..... > >The second problem of the UA mistaking a refresh for a new call is not >possible, the To: tag in the INVITE would give away..... Yes, but the idea of using re-INVITEs for the refreshes is because it is supposed to provide a keep-alive mechnism, to re-establish the call if a SIP node on the path has rebooted (or otherwise lost the call). So, even if there is a tag the UAS would probably still try to re-establish the call, because since it rebooted it doesn't remember it had a call which it transfered to another user. Regards, Christer Holmberg Ericsson Finland > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, February 21, 2001 2:30 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Session-timer and REFER > > Hi, > > More about the session-timer... > > Assume user A establish a call with user B. A session-timer between A > and B is also establish. > > Then, B wants to transfer A to user C, using REFER. A will then send > INVITE to C and establish a session. However, the session between A and > B is still open (even if there is no media) so the session-timer will > continue between them. > > My first issue is that A (or B) may want to cancel the session-timer > during the session with C, and then maybe use it again if the media is > switched back to B at some stage. One solution would be for either A or > B > to increase the refresh timer during the A-to-C call, and then decrease > it > again if the A-to-B call continues, but is this possible? > > The other issue is if B re-boots. Now, if A is sending the refreshes, B > will think it's a new call, so the phone will ring - AND, may start > sending media to B's RTP port specified in the SDP in the re-INVITE. So, > when A is talking to C, he may suddenly start hearing announcements, > ring tones, or even someone talking, from B. A's call control will not > know about this, since it will receive a 200 OK for the re-INVITE in > either case. > > Comments? > > Regards, > > Christer Holmberg > Ericsson Finland --------------E5EC7E79E4A0C26B408AB3A9 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 --------------E5EC7E79E4A0C26B408AB3A9-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 18:19:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13679 for ; Wed, 21 Feb 2001 18:19:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB2D64437C; Wed, 21 Feb 2001 18:19:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4]) by lists.bell-labs.com (Postfix) with SMTP id 45D404433A for ; Wed, 21 Feb 2001 18:18:42 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 21 Feb 2001 15:17:47 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id <1SFW485N>; Wed, 21 Feb 2001 15:17:47 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD38D8EE@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "Christer Holmberg" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Session-timer and REFER MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 168A9311148670-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 21 Feb 2001 15:17:46 -0800 Content-Transfer-Encoding: 7bit According to the Session refresh draft, if the one of the UA's were to crash/reboot, if they were to receive such an INVITE (page 7 of the draft), and they support Session Timer, they are supposed to respond back with a non 200 OK response and set the Session Expires time out to immediate expire value to notify the far end that this call no longer exists..... that way the sending UA knows such a reboot occurred and would tear the call down.... Venkatesh -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Wednesday, February 21, 2001 3:11 PM To: Venkatesh Venkataramanan Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Session-timer and REFER Hi, >As far as I know you shd be able to modify session refreshes timeout >anytime, by sending a new INVITE with a higher/lower Session-Expires timeout >value..... > >The second problem of the UA mistaking a refresh for a new call is not >possible, the To: tag in the INVITE would give away..... Yes, but the idea of using re-INVITEs for the refreshes is because it is supposed to provide a keep-alive mechnism, to re-establish the call if a SIP node on the path has rebooted (or otherwise lost the call). So, even if there is a tag the UAS would probably still try to re-establish the call, because since it rebooted it doesn't remember it had a call which it transfered to another user. Regards, Christer Holmberg Ericsson Finland > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, February 21, 2001 2:30 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Session-timer and REFER > > Hi, > > More about the session-timer... > > Assume user A establish a call with user B. A session-timer between A > and B is also establish. > > Then, B wants to transfer A to user C, using REFER. A will then send > INVITE to C and establish a session. However, the session between A and > B is still open (even if there is no media) so the session-timer will > continue between them. > > My first issue is that A (or B) may want to cancel the session-timer > during the session with C, and then maybe use it again if the media is > switched back to B at some stage. One solution would be for either A or > B > to increase the refresh timer during the A-to-C call, and then decrease > it > again if the A-to-B call continues, but is this possible? > > The other issue is if B re-boots. Now, if A is sending the refreshes, B > will think it's a new call, so the phone will ring - AND, may start > sending media to B's RTP port specified in the SDP in the re-INVITE. So, > when A is talking to C, he may suddenly start hearing announcements, > ring tones, or even someone talking, from B. A's call control will not > know about this, since it will receive a 200 OK for the re-INVITE in > either case. > > Comments? > > Regards, > > Christer Holmberg > Ericsson Finland _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 18:39:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13918 for ; Wed, 21 Feb 2001 18:39:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A514E44354; Wed, 21 Feb 2001 18:39:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 53A2C44336 for ; Wed, 21 Feb 2001 18:38:12 -0500 (EST) 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 f1LNcBd23988; Thu, 22 Feb 2001 00:38:11 +0100 (MET) Received: from lmf.ericsson.se ([136.225.183.50]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id AAA04505; Thu, 22 Feb 2001 00:38:07 +0100 (MET) Message-ID: <3A945165.3D6F226@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Venkatesh Venkataramanan Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Session-timer and REFER References: <79FEAA5FABA7D411BF580001023D1BBD38D8EE@mailserver.sylantro.com> Content-Type: multipart/mixed; boundary="------------26E25FCE01427653DCE6CEDA" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 01:38:13 +0200 This is a multi-part message in MIME format. --------------26E25FCE01427653DCE6CEDA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ok, so then this only works for proxies, which I guess is ok, because a user would probably notice if the remote party crashes because the media disaperars. I still think, however, that sending re-INVITEs, with all headers and message bodies, is a littly clumsy. Instead there could be "lighter" method (PING, or something), and if a 481 response is received THEN the UAC could send a re-INVITE. After all, I don't think the proxies are going to crash that often, compared to the number of bytes we are going to send with INVITEs and ACKs... But, that's another issue :) Christer Holmberg Ericsson Finland Venkatesh Venkataramanan wrote: > > According to the Session refresh draft, if the one of the UA's were to > crash/reboot, if they were to receive such an INVITE (page 7 of the draft), > and they support Session Timer, they are supposed to respond back with a non > 200 OK response and set the Session Expires time out to immediate expire > value to notify the far end that this call no longer exists..... that way > the sending UA knows such a reboot occurred and would tear the call down.... > > Venkatesh > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Wednesday, February 21, 2001 3:11 PM > To: Venkatesh Venkataramanan > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Session-timer and REFER > > Hi, > > >As far as I know you shd be able to modify session refreshes timeout > >anytime, by sending a new INVITE with a higher/lower Session-Expires > timeout > >value..... > > > >The second problem of the UA mistaking a refresh for a new call is not > >possible, the To: tag in the INVITE would give away..... > > Yes, but the idea of using re-INVITEs for the refreshes is because it is > supposed to provide > a keep-alive mechnism, to re-establish the call if a SIP node on the > path has rebooted > (or otherwise lost the call). So, even if there is a tag the UAS would > probably still > try to re-establish the call, because since it rebooted it doesn't > remember it had a > call which it transfered to another user. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > > Sent: Wednesday, February 21, 2001 2:30 PM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Session-timer and REFER > > > > Hi, > > > > More about the session-timer... > > > > Assume user A establish a call with user B. A session-timer between A > > and B is also establish. > > > > Then, B wants to transfer A to user C, using REFER. A will then send > > INVITE to C and establish a session. However, the session between A and > > B is still open (even if there is no media) so the session-timer will > > continue between them. > > > > My first issue is that A (or B) may want to cancel the session-timer > > during the session with C, and then maybe use it again if the media is > > switched back to B at some stage. One solution would be for either A or > > B > > to increase the refresh timer during the A-to-C call, and then decrease > > it > > again if the A-to-B call continues, but is this possible? > > > > The other issue is if B re-boots. Now, if A is sending the refreshes, B > > will think it's a new call, so the phone will ring - AND, may start > > sending media to B's RTP port specified in the SDP in the re-INVITE. So, > > when A is talking to C, he may suddenly start hearing announcements, > > ring tones, or even someone talking, from B. A's call control will not > > know about this, since it will receive a 200 OK for the re-INVITE in > > either case. > > > > Comments? > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland --------------26E25FCE01427653DCE6CEDA 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 --------------26E25FCE01427653DCE6CEDA-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 21 19:55:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15242 for ; Wed, 21 Feb 2001 19:55:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5A5C34433A; Wed, 21 Feb 2001 19:55:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id BE2A344336 for ; Wed, 21 Feb 2001 19:54:51 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id HAA16901 for ; Thu, 22 Feb 2001 07:01:50 -0600 Message-ID: <00ae01c09c69$80203f30$4901a8c0@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Fw: REMINDER-Internet-Draft Cut-off Dates for Minneapolis IETF Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 21 Feb 2001 18:50:49 -0600 Content-Transfer-Encoding: 7bit For those of you who do not subscribe to IETF Announce, I include the following. For those of you do, sorry for the re-spam. -- Dean ----- Original Message ----- From: "Natalie Syracuse" To: Sent: Wednesday, February 21, 2001 5:51 AM Subject: REMINDER-Internet-Draft Cut-off Dates for Minneapolis IETF > > NOTE: There are two (2) Internet-Draft Cut-off dates > > February 23: Cut-off for Initial Submissions (new documents) > > All initial submissions(-00) must be submitted by Friday, > February 23, 17:00 US-EST. Initial submissions received after this time > will NOT be made available in the Internet-Drafts directory, and will have > to be resubmitted. > > As before, all initial submissions (-00.txt) with a filename beginning > with a draft-ietf MUST be approved by the appropriate WG Chair prior to > processing and announcing. WG Chair approval must be received by > Monday, February 26. > > Please do NOT wait until the last minute to submit. > > Be advised: NO placeholders. Updates to initial submissions received > the week of February 23 will NOT be accepted. > > March 2: FINAL Internet-Draft Cut-off > > All revised Internet-Draft submissions must be submitted by Friday, > March 2, 2001 at 17:00 US-EST. Internet-Drafts received after this time > will NOT be announced NOR made available in the Internet-Drafts > Directories. > > We will begin accepting Internet-Draft submissions the week of the > meeting, though announcements will NOT be sent until the IETF meeting > is over. > > Thank you for your understanding and cooperation. Please do not hesitate > to contact us if you have any questions or concenrs. > > FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_50.html > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 05:19:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06751 for ; Thu, 22 Feb 2001 05:19:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 025C044357; Thu, 22 Feb 2001 05:19:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web9808.mail.yahoo.com (web9808.mail.yahoo.com [216.136.129.34]) by lists.bell-labs.com (Postfix) with SMTP id 26E7B44337 for ; Thu, 22 Feb 2001 05:18:05 -0500 (EST) Message-ID: <20010222101804.55408.qmail@web9808.mail.yahoo.com> Received: from [203.200.7.193] by web9808.mail.yahoo.com; Thu, 22 Feb 2001 02:18:04 PST From: lakshmi To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] To distinguish b/w user and telephone-subscriber Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 02:18:04 -0800 (PST) Hi all, There is no clear distinguish b/w the user and telephone subscriber of the SIP-URL. since both user and global phone no in tele sub are having many common characters like digits and '+'. One more doubt is it necessary to make colon as escaped in telephone subscriber, as it is used as a delimiter for password in the userinfo of the SIP-URL. Thanks lakshmi __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/ _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 07:23:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08411 for ; Thu, 22 Feb 2001 07:23:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5924444363; Thu, 22 Feb 2001 07:23:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by lists.bell-labs.com (Postfix) with ESMTP id 27E5E44337 for ; Thu, 22 Feb 2001 07:22:22 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1MCLpS00272 for ; Thu, 22 Feb 2001 14:21:51 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 22 Feb 2001 14:22:20 +0200 Received: by esebh02nok with Internet Mail Service (5.5.2652.78) id <18K7JJ4Q>; Thu, 22 Feb 2001 14:22:20 +0200 Message-ID: From: hannu.hietalahti@nokia.com To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Minutes of 3GPP CN1-SA2 SIP joint meeting Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 14:21:22 +0200 Dear all, The latest 3GPP CN1-SA2 SIP joint meeting dealt with a contribution about co-operation between IETF and those 3GPP working groups which are working on SIP protocol. First a brief introduction of these 3GPP groups for those who are not familiar with the organisation: SA2 is working group 2 in TSG (Technical Specification Group) SA (Services and System Aspects). They are responsible for the overall system architecture. CN1 is working group 1 in TSG CN (Core Network) responsible for the Gm interface, i.e. the one between the terminal and CSCF. CN1 is the WG which is most involved in 3GPP SIP work. Tdoc N1-010233 titled "Feedback from IETF interim SIP working group meeting" summarises the proposed 3GPP originated contributions and communication between IETF and 3GPP meetings. It became clear during the discussion on this document that the main reason for lack of 3GPP originated contributions has been that the 3GPP delegates have wanted to get the main 3GPP specifications more stable before contributing them to IETF meetings. However, it was also seen that sufficient stability is being reached and now it is appropriate to start closer co-operation between the relevant working groups of IETF and 3GPP. This needs to be done to provide IETF the understanding of 3GPP decisions related with mobile SIP and to collect the valuable comments and hints from the IETF SIP experts. The following decisions on necessary 3GPP actions were made during the discussion: 1. Chairman is asked to distribute a summary of CN1 SIP related discussions and decisions to the IETF SIP mailing list. 2. The dependency between IETF RFCs and 3GPP TSs needs to identified. The list of IETF SIP specifications which will be referred to will be communicated to IETF SIP group by the rapporteur. This will be the list of RFCs that are prerequisite for the publication of 3GPP specification as a standard. 3. The work on the draft specifications is twofold: 3GPP needs to review and comment on the IETF SIP drafts which are relevant for 3GPP, i.e. the ones which are referred to by 3GPP specifications AND 4. Call flows defining the 3GPP related enhancements need to be contributed to IETF by 3GPP members. This was addressed in the meeting by a drafting group of 3GPP CN1 and SA2 members to draft an extract of 24.228 signalling flows for IETF review and comments. An executive summary of the chairman's meeting report is attached. The full report and the meeting documents are available in http://www.3gpp.org/ftp/TSG_CN/WG1_mm-cc-sm/SIP_meetings/CN1_SA2_03_(New%20J ersey)/ With Best Regards, Hannu Hietalahti CN1 Chairman hannu.hietalahti@nokia.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 08:46:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10758 for ; Thu, 22 Feb 2001 08:46:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3285644371; Thu, 22 Feb 2001 08:46:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60]) by lists.bell-labs.com (Postfix) with ESMTP id D0FF944337 for ; Thu, 22 Feb 2001 08:45:07 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 22 Feb 2001 13:45:05 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id NAA23503; Thu, 22 Feb 2001 13:45:04 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569FB.004B8007 ; Thu, 22 Feb 2001 13:44:39 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Christer Holmberg Cc: sip@lists.bell-labs.com, mwatson@nortelnetworks.com, Gonzalo.Camarillo@lmf.ericsson.se, jdrosen@dynamicsoft.com, taylor@nortelnetworks.com Message-ID: <802569FB.004B7DEE.00@marconicomms.com> Subject: Re: [SIP] Operlap dialing within a SIP network Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=u1llCoPDNinuLJPTCjtjHODKUW5gJxlHu40oESCAD1mG5d5ESVLQwGBf" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 13:44:45 +0000 --0__=u1llCoPDNinuLJPTCjtjHODKUW5gJxlHu40oESCAD1mG5d5ESVLQwGBf Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello, Christer wrote : >ISSUES NO MATTER WHICH METHOD IS USED: >-------------------------------------- > > >1. We should be allowed to insert Route headers in initial INVITEs > ROUTE headers in initial INVITEs are allowed according to the latest text from J. Rosenberg (I think). Whether or not another domain's proxies can be guarenteed to honour them is a different matter. Why is a ROUTE header required in the very first initial INVITE anyway ? >AND/OR > >2. There should be some kind of routing mechnism in the proxis to make >sure that additional INVITEs are routed to the same gateway. > The ROUTE header in 'real' subsequent INVITEs will guarentee that these INVITEs do follow the same path. The conflict arises when the subsequent INVITEs look like initial INVITEs with source routing; back to the above point. >3. If a proxy routes additional INVITEs to another gateway, we may get >multiple IAMs. > If source routing cannot be guarenteed to interop between various domains and INFO method is not to be used then two alternatives are left; either accept that some extraneous IAMs are (infrequently ?) generated or mandate that the UAC always sends the digits en-bloc (wait for stop digit or timer expiry). The latter approach avoids all problems posed by overlap sending and is the most likely to interop in all scenarios (vanilla proxies, vanilla clients, application servers etc..). > >At least the two first issues here are general issues for SIP, and not >only related to the overlap dialing. The third issue is related to PSTN >interworking in general, because because of forking and/or request >re-transmission INVITEs may end up at different gateways. > > >ISSUES WITH THE INFO METHOD: >---------------------------- > >4. We must wait for the response from the previous request before we >send an INFO. I assume you are concerned with the delay in set up because of this. Well, consider the situation when additional digits are carried in initial INVITEs; a domain may require that AAA procedures are performed on all initial INVITEs which will probably be a bigger drag on set up than waiting for the first response using the INFO approach. > >5. Requires new extensions (header, option-tags,...?) > > >ISSUES WITH THE INVITE: >----------------------- > >6. Depending on the number of INVITEs that the gateway mangages to route >to the next PSTN entity, we will have a number of pending INVITE >transactions, since we only get a provisional response to those INVITEs >until one INVITE finaly has enough digits to generate a 200, plus 484 >for all the pending requests. > The INVITEs generated by the ingress g/w all belong to the same call and therefore the same state machine within the ingress g/w (or a set of associated state machines); the same applies to the the egress g/w (assuming all the INVITEs get to the correct g/w). This is very much like multiple INVITEs (subsequent INVITEs allowed before 200 OK) on the same call leg. The only thing stopping that approach is current proxies will not handle the subsequent INVITEs before 200 OK but perhaps it is something to think about for the future. >7. One extra message, the ACK, for each INVITE. One ACK is nothing, but >if you have 20000 of them... > >I didn't include the issue of "when a call is completely routed from a >SIP point of view", because we can spend months arguing about that - and >I anyway think we should make our solutions depending on what's best >from a TECHNICAL point of view, not from a definition point of view. > >I've said it before, and I'll say it again, that I am not against the >idea of using INFO. However, I PERSONALY don't think the advantages >compared to INVITEs are so big that we should spend time on that (we >MUST, however, clarify the provisional response thing, and which final >responses will be sent to the pending INVITEs, in the ISUP-SIP draft). >Instead, I think we should put our efforts on, among other things, the >general SIP issues (1-3) we have no matter which overlap dialing method >we have, and which we also have in other SIP scenarios. I don't think that implementing INFO would be difficult. I also don't think that this approach would be incompatible with existing servers and clients as these would use 484/404 if addressed with insufficient digits. However, it is clear that the only problem it is solving is the potential conflict with source routing. I am coming to the conclusion that mandating en-bloc working when sending into the SIP network is the best, and simplest option; let the initial INVITE be the actual INVITE. Regards, K. Robinson Christer Holmberg on 21/02/2001 19:50:59 To: sip@lists.bell-labs.com cc: mwatson@nortelnetworks.com, Gonzalo.Camarillo@lmf.ericsson.se, Keith Robinson/MAIN/MC1@MCMAIN, jdrosen@dynamicsoft.com, taylor@nortelnetworks.com Subject: Re: [SIP] Operlap dialing within a SIP network Hi, I here try to make some kind of conclusion of the discussion. ISSUES NO MATTER WHICH METHOD IS USED: -------------------------------------- 1. We should be allowed to insert Route headers in initial INVITEs AND/OR 2. There should be some kind of routing mechnism in the proxis to make sure that additional INVITEs are routed to the same gateway. 3. If a proxy routes additional INVITEs to another gateway, we may get multiple IAMs. At least the two first issues here are general issues for SIP, and not only related to the overlap dialing. The third issue is related to PSTN interworking in general, because because of forking and/or request re-transmission INVITEs may end up at different gateways. ISSUES WITH THE INFO METHOD: ---------------------------- 4. We must wait for the response from the previous request before we send an INFO. 5. Requires new extensions (header, option-tags,...?) ISSUES WITH THE INVITE: ----------------------- 6. Depending on the number of INVITEs that the gateway mangages to route to the next PSTN entity, we will have a number of pending INVITE transactions, since we only get a provisional response to those INVITEs until one INVITE finaly has enough digits to generate a 200, plus 484 for all the pending requests. 7. One extra message, the ACK, for each INVITE. One ACK is nothing, but if you have 20000 of them... I didn't include the issue of "when a call is completely routed from a SIP point of view", because we can spend months arguing about that - and I anyway think we should make our solutions depending on what's best from a TECHNICAL point of view, not from a definition point of view. I've said it before, and I'll say it again, that I am not against the idea of using INFO. However, I PERSONALY don't think the advantages compared to INVITEs are so big that we should spend time on that (we MUST, however, clarify the provisional response thing, and which final responses will be sent to the pending INVITEs, in the ISUP-SIP draft). Instead, I think we should put our efforts on, among other things, the general SIP issues (1-3) we have no matter which overlap dialing method we have, and which we also have in other SIP scenarios. Regards, Christer Holmberg Ericsson Finland --0__=u1llCoPDNinuLJPTCjtjHODKUW5gJxlHu40oESCAD1mG5d5ESVLQwGBf Content-type: application/octet-stream; name="christer.holmberg.vcf" Content-Disposition: attachment; filename="christer.holmberg.vcf" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOkhvbG1iZXJnO0NocmlzdGVyDQp0ZWw7Y2VsbDorMzU4LTQwLTU2MDQ0 MTINCnRlbDt3b3JrOiszNTgtOS0yOTkyOTQzDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnOkVy aWNzc29uO0lQIE11bHRpbWVkaWEgLyBBZHZhbmNlZCBTaWduYWxsaW5nIFJlc2VhcmNoIExhYm9y YXRvcnkNCmFkcjo7Ozs7OzsNCnZlcnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpjaHJpc3Rlci5o b2xtYmVyZ0BsbWYuZXJpY3Nzb24uc2UNCnRpdGxlOlN5c3RlbSBEZXNpZ25lcg0KZm46Q2hyaXN0 ZXIgSG9sbWJlcmcNCmVuZDp2Y2FyZA0KDQo= --0__=u1llCoPDNinuLJPTCjtjHODKUW5gJxlHu40oESCAD1mG5d5ESVLQwGBf-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 09:47:24 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12732 for ; Thu, 22 Feb 2001 09:47:23 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 518074434D; Thu, 22 Feb 2001 09:47:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 2D8E64433D for ; Thu, 22 Feb 2001 09:46:52 -0500 (EST) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Thu, 22 Feb 2001 08:40:59 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <15CH5MYT>; Thu, 22 Feb 2001 08:45:54 -0600 Message-ID: From: "Mary Barnes" To: sip@lists.bell-labs.com Cc: "'hannu.hietalahti@nokia.com'" Subject: RE: [SIP] Minutes of 3GPP CN1-SA2 SIP joint meeting MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09CDE.25E12A00" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 08:45:49 -0600 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_01C09CDE.25E12A00 Content-Type: text/plain; charset="iso-8859-1" Hannu, Where is the attachment containing the executive summary of this meeting? I checked the URL you included and was unable to determine from the tdoclist, which document contained the executive summary. Is this located elsewhere? Thanks, Mary H. Barnes IMS Solutions Standards Strategy mbarnes@nortelnetworks.com 972-684-5432 -----Original Message----- From: hannu.hietalahti@nokia.com [mailto:hannu.hietalahti@nokia.com] Sent: Thursday, February 22, 2001 6:21 AM To: sip@lists.bell-labs.com Subject: [SIP] Minutes of 3GPP CN1-SA2 SIP joint meeting Dear all, The latest 3GPP CN1-SA2 SIP joint meeting dealt with a contribution about co-operation between IETF and those 3GPP working groups which are working on SIP protocol. First a brief introduction of these 3GPP groups for those who are not familiar with the organisation: SA2 is working group 2 in TSG (Technical Specification Group) SA (Services and System Aspects). They are responsible for the overall system architecture. CN1 is working group 1 in TSG CN (Core Network) responsible for the Gm interface, i.e. the one between the terminal and CSCF. CN1 is the WG which is most involved in 3GPP SIP work. Tdoc N1-010233 titled "Feedback from IETF interim SIP working group meeting" summarises the proposed 3GPP originated contributions and communication between IETF and 3GPP meetings. It became clear during the discussion on this document that the main reason for lack of 3GPP originated contributions has been that the 3GPP delegates have wanted to get the main 3GPP specifications more stable before contributing them to IETF meetings. However, it was also seen that sufficient stability is being reached and now it is appropriate to start closer co-operation between the relevant working groups of IETF and 3GPP. This needs to be done to provide IETF the understanding of 3GPP decisions related with mobile SIP and to collect the valuable comments and hints from the IETF SIP experts. The following decisions on necessary 3GPP actions were made during the discussion: 1. Chairman is asked to distribute a summary of CN1 SIP related discussions and decisions to the IETF SIP mailing list. 2. The dependency between IETF RFCs and 3GPP TSs needs to identified. The list of IETF SIP specifications which will be referred to will be communicated to IETF SIP group by the rapporteur. This will be the list of RFCs that are prerequisite for the publication of 3GPP specification as a standard. 3. The work on the draft specifications is twofold: 3GPP needs to review and comment on the IETF SIP drafts which are relevant for 3GPP, i.e. the ones which are referred to by 3GPP specifications AND 4. Call flows defining the 3GPP related enhancements need to be contributed to IETF by 3GPP members. This was addressed in the meeting by a drafting group of 3GPP CN1 and SA2 members to draft an extract of 24.228 signalling flows for IETF review and comments. An executive summary of the chairman's meeting report is attached. The full report and the meeting documents are available in http://www.3gpp.org/ftp/TSG_CN/WG1_mm-cc-sm/SIP_meetings/CN1_SA2_03_(New%20J ersey)/ With Best Regards, Hannu Hietalahti CN1 Chairman hannu.hietalahti@nokia.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. ------_=_NextPart_001_01C09CDE.25E12A00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Minutes of 3GPP CN1-SA2 SIP joint meeting

Hannu,

Where is the attachment containing the executive = summary of this meeting? 
I checked the URL you included and was unable to = determine from the tdoclist, which document contained the executive = summary.  Is this located elsewhere? 

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


-----Original Message-----
From: hannu.hietalahti@nokia.com [mailto:hannu.hietalahti@nokia= .com]
Sent: Thursday, February 22, 2001 6:21 AM
To: sip@lists.bell-labs.com
Subject: [SIP] Minutes of 3GPP CN1-SA2 SIP joint = meeting


Dear all,

The latest 3GPP CN1-SA2 SIP joint meeting dealt with = a contribution about
co-operation between IETF and those 3GPP working = groups which are working on
SIP protocol.

First a brief introduction of these 3GPP groups for = those who are not
familiar with the organisation: SA2 is working group = 2 in TSG (Technical
Specification Group) SA (Services and System = Aspects). They are responsible
for the overall system architecture. CN1 is working = group 1 in TSG CN (Core
Network) responsible for the Gm interface, i.e. the = one between the terminal
and CSCF. CN1 is the WG which is most involved in = 3GPP SIP work.

Tdoc N1-010233 titled "Feedback from IETF = interim SIP working group meeting"
summarises the proposed 3GPP originated = contributions and communication
between IETF and 3GPP meetings.

It became clear during the discussion on this = document that the main reason
for lack of 3GPP originated contributions has been = that the 3GPP delegates
have wanted to get the main 3GPP specifications more = stable before
contributing them to IETF meetings.

However, it was also seen that sufficient stability = is being reached and now
it is appropriate to start closer co-operation = between the relevant working
groups of IETF and 3GPP. This needs to be done to = provide IETF the
understanding of 3GPP decisions related with mobile = SIP and to collect the
valuable comments and hints from the IETF SIP = experts.

The following decisions on necessary 3GPP actions = were made during the
discussion:

1. Chairman is asked to distribute a summary of CN1 = SIP related discussions
and decisions to the IETF SIP mailing list.

2. The dependency between IETF RFCs and 3GPP TSs = needs to identified. The
list of IETF SIP specifications which will be = referred to will be
communicated to IETF SIP group by the rapporteur. = This will be the list of
RFCs that are prerequisite for the publication of = 3GPP specification as a
standard.

3. The work on the draft specifications is twofold: = 3GPP needs to review and
comment on the IETF SIP drafts which are relevant = for 3GPP, i.e. the ones
which are referred to by 3GPP specifications = AND

4. Call flows defining the 3GPP related enhancements = need to be contributed
to IETF by 3GPP members. This was addressed in the = meeting by a drafting
group of 3GPP CN1 and SA2 members to draft an = extract of 24.228 signalling
flows for IETF review and comments.

An executive summary of the chairman's meeting report = is attached. The full
report and the meeting documents are available in =

http://www.3gpp.org/ftp/TSG_CN/WG1_mm-cc-sm/SIP_meetin= gs/CN1_SA2_03_(New%20J
ersey)/


With Best Regards,
Hannu Hietalahti
CN1 Chairman
hannu.hietalahti@nokia.com

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

------_=_NextPart_001_01C09CDE.25E12A00-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 10:02:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13189 for ; Thu, 22 Feb 2001 10:02:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7A74744386; Thu, 22 Feb 2001 10:02:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by lists.bell-labs.com (Postfix) with ESMTP id 19A2D4433D for ; Thu, 22 Feb 2001 10:01:36 -0500 (EST) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Thu, 22 Feb 2001 08:55:07 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <15CH5N3V>; Thu, 22 Feb 2001 09:00:02 -0600 Message-ID: From: "Mary Barnes" To: "'sip@lists.bell-labs.com'" Cc: "'hannu.hietalahti@nokia.com'" Subject: RE: [SIP] Minutes of 3GPP CN1-SA2 SIP joint meeting MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09CE0.1FE9D780" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 08:59:58 -0600 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_01C09CE0.1FE9D780 Content-Type: text/plain; charset="iso-8859-1" Hannu, I apologize for the pedantic postings, but I've looked at the N1-010233 tdoc you reference. Is that the "Executive summary" to which you refer? I'm just trying to clarify for folks that aren't familiar with the 3GPP document numbering process (i.e. IETF likes more user friendly words (for drafts) and we all know SIP does too). I'm thinking that instead of attaching the "Executive summary", you included it inline. Is that correct? Thanks, Mary Barnes. -----Original Message----- From: Barnes, Mary [RICH1:B602-M:EXCH] Sent: Thursday, February 22, 2001 8:46 AM To: sip@lists.bell-labs.com Cc: 'hannu.hietalahti@nokia.com' Subject: RE: [SIP] Minutes of 3GPP CN1-SA2 SIP joint meeting Hannu, Where is the attachment containing the executive summary of this meeting? I checked the URL you included and was unable to determine from the tdoclist, which document contained the executive summary. Is this located elsewhere? Thanks, Mary H. Barnes IMS Solutions Standards Strategy mbarnes@nortelnetworks.com 972-684-5432 -----Original Message----- From: hannu.hietalahti@nokia.com [mailto:hannu.hietalahti@nokia.com] Sent: Thursday, February 22, 2001 6:21 AM To: sip@lists.bell-labs.com Subject: [SIP] Minutes of 3GPP CN1-SA2 SIP joint meeting Dear all, The latest 3GPP CN1-SA2 SIP joint meeting dealt with a contribution about co-operation between IETF and those 3GPP working groups which are working on SIP protocol. First a brief introduction of these 3GPP groups for those who are not familiar with the organisation: SA2 is working group 2 in TSG (Technical Specification Group) SA (Services and System Aspects). They are responsible for the overall system architecture. CN1 is working group 1 in TSG CN (Core Network) responsible for the Gm interface, i.e. the one between the terminal and CSCF. CN1 is the WG which is most involved in 3GPP SIP work. Tdoc N1-010233 titled "Feedback from IETF interim SIP working group meeting" summarises the proposed 3GPP originated contributions and communication between IETF and 3GPP meetings. It became clear during the discussion on this document that the main reason for lack of 3GPP originated contributions has been that the 3GPP delegates have wanted to get the main 3GPP specifications more stable before contributing them to IETF meetings. However, it was also seen that sufficient stability is being reached and now it is appropriate to start closer co-operation between the relevant working groups of IETF and 3GPP. This needs to be done to provide IETF the understanding of 3GPP decisions related with mobile SIP and to collect the valuable comments and hints from the IETF SIP experts. The following decisions on necessary 3GPP actions were made during the discussion: 1. Chairman is asked to distribute a summary of CN1 SIP related discussions and decisions to the IETF SIP mailing list. 2. The dependency between IETF RFCs and 3GPP TSs needs to identified. The list of IETF SIP specifications which will be referred to will be communicated to IETF SIP group by the rapporteur. This will be the list of RFCs that are prerequisite for the publication of 3GPP specification as a standard. 3. The work on the draft specifications is twofold: 3GPP needs to review and comment on the IETF SIP drafts which are relevant for 3GPP, i.e. the ones which are referred to by 3GPP specifications AND 4. Call flows defining the 3GPP related enhancements need to be contributed to IETF by 3GPP members. This was addressed in the meeting by a drafting group of 3GPP CN1 and SA2 members to draft an extract of 24.228 signalling flows for IETF review and comments. An executive summary of the chairman's meeting report is attached. The full report and the meeting documents are available in http://www.3gpp.org/ftp/TSG_CN/WG1_mm-cc-sm/SIP_meetings/CN1_SA2_03_(New%20J ersey)/ With Best Regards, Hannu Hietalahti CN1 Chairman hannu.hietalahti@nokia.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. ------_=_NextPart_001_01C09CE0.1FE9D780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Minutes of 3GPP CN1-SA2 SIP joint meeting

Hannu,

I apologize for the pedantic postings, but I've = looked at the N1-010233 tdoc you reference.  Is that the = "Executive summary" to which you refer?  I'm just trying = to clarify for folks that aren't familiar with the 3GPP document = numbering process (i.e. IETF likes more user friendly words (for = drafts) and we all know SIP does too).  I'm thinking that instead = of attaching the "Executive summary", you included it = inline.  Is that correct?

Thanks,
Mary Barnes.

-----Original Message-----
From: Barnes, Mary [RICH1:B602-M:EXCH]
Sent: Thursday, February 22, 2001 8:46 AM
To: sip@lists.bell-labs.com
Cc: 'hannu.hietalahti@nokia.com'
Subject: RE: [SIP] Minutes of 3GPP CN1-SA2 SIP joint = meeting


Hannu,

Where is the attachment containing the executive = summary of this meeting? 
I checked the URL you included and was unable to = determine from the tdoclist, which document contained the executive = summary.  Is this located elsewhere? 

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


-----Original Message-----
From: hannu.hietalahti@nokia.com [mailto:hannu.hietalahti@nokia= .com]
Sent: Thursday, February 22, 2001 6:21 AM
To: sip@lists.bell-labs.com
Subject: [SIP] Minutes of 3GPP CN1-SA2 SIP joint = meeting


Dear all,

The latest 3GPP CN1-SA2 SIP joint meeting dealt with = a contribution about
co-operation between IETF and those 3GPP working = groups which are working on
SIP protocol.

First a brief introduction of these 3GPP groups for = those who are not
familiar with the organisation: SA2 is working group = 2 in TSG (Technical
Specification Group) SA (Services and System = Aspects). They are responsible
for the overall system architecture. CN1 is working = group 1 in TSG CN (Core
Network) responsible for the Gm interface, i.e. the = one between the terminal
and CSCF. CN1 is the WG which is most involved in = 3GPP SIP work.

Tdoc N1-010233 titled "Feedback from IETF = interim SIP working group meeting"
summarises the proposed 3GPP originated = contributions and communication
between IETF and 3GPP meetings.

It became clear during the discussion on this = document that the main reason
for lack of 3GPP originated contributions has been = that the 3GPP delegates
have wanted to get the main 3GPP specifications more = stable before
contributing them to IETF meetings.

However, it was also seen that sufficient stability = is being reached and now
it is appropriate to start closer co-operation = between the relevant working
groups of IETF and 3GPP. This needs to be done to = provide IETF the
understanding of 3GPP decisions related with mobile = SIP and to collect the
valuable comments and hints from the IETF SIP = experts.

The following decisions on necessary 3GPP actions = were made during the
discussion:

1. Chairman is asked to distribute a summary of CN1 = SIP related discussions
and decisions to the IETF SIP mailing list.

2. The dependency between IETF RFCs and 3GPP TSs = needs to identified. The
list of IETF SIP specifications which will be = referred to will be
communicated to IETF SIP group by the rapporteur. = This will be the list of
RFCs that are prerequisite for the publication of = 3GPP specification as a
standard.

3. The work on the draft specifications is twofold: = 3GPP needs to review and
comment on the IETF SIP drafts which are relevant = for 3GPP, i.e. the ones
which are referred to by 3GPP specifications = AND

4. Call flows defining the 3GPP related enhancements = need to be contributed
to IETF by 3GPP members. This was addressed in the = meeting by a drafting
group of 3GPP CN1 and SA2 members to draft an = extract of 24.228 signalling
flows for IETF review and comments.

An executive summary of the chairman's meeting report = is attached. The full
report and the meeting documents are available in =

http://www.3gpp.org/ftp/TSG_CN/WG1_mm-cc-sm/SIP_meetin= gs/CN1_SA2_03_(New%20J
ersey)/


With Best Regards,
Hannu Hietalahti
CN1 Chairman
hannu.hietalahti@nokia.com

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

------_=_NextPart_001_01C09CE0.1FE9D780-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 10:39:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14348 for ; Thu, 22 Feb 2001 10:39:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9068144339; Thu, 22 Feb 2001 10:39:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 5BA6344338 for ; Thu, 22 Feb 2001 10:38:55 -0500 (EST) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f1MFZh108546; Thu, 22 Feb 2001 10:35:43 -0500 (EST) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA27582; Thu, 22 Feb 2001 10:34:50 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Feb 2001 10:35:39 -0500 Message-ID: From: "Roy, Radhika R, ALCOO" To: Keith Robinson , Christer Holmberg Cc: sip@lists.bell-labs.com, mwatson@nortelnetworks.com, Gonzalo.Camarillo@lmf.ericsson.se, jdrosen@dynamicsoft.com, taylor@nortelnetworks.com Subject: RE: [SIP] Overlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 10:34:39 -0500 Hi, Everyone: I agree with Keith that we should mandate en-block due to the following benefits: 1. Simple solution considering the complexity, ambiguities and incompatibilities in implementing the at 2. MGC that is handling the ISUP-SIP mapping can be intelligent enough to perform en-blocking 3. First INVITE becomes the real INVITE and this solves all the potential problems (e.g., routing, inefficiency of sending the signaling messages back and forth, etc) 4. The additional delay incurring in collecting digits may not matter much because we may have to deal with authentication, policies, and other related functions to deal with the call Best regards, Radhika R. Roy AT&T -----Original Message----- From: Keith Robinson [mailto:Keith.Robinson@marconi.com] Sent: Thursday, February 22, 2001 8:45 AM To: Christer Holmberg Cc: sip@lists.bell-labs.com; mwatson@nortelnetworks.com; Gonzalo.Camarillo@lmf.ericsson.se; jdrosen@dynamicsoft.com; taylor@nortelnetworks.com Subject: Re: [SIP] Operlap dialing within a SIP network Hello, Christer wrote : >ISSUES NO MATTER WHICH METHOD IS USED: >-------------------------------------- > > >1. We should be allowed to insert Route headers in initial INVITEs > ROUTE headers in initial INVITEs are allowed according to the latest text from J. Rosenberg (I think). Whether or not another domain's proxies can be guarenteed to honour them is a different matter. Why is a ROUTE header required in the very first initial INVITE anyway ? >AND/OR > >2. There should be some kind of routing mechnism in the proxis to make >sure that additional INVITEs are routed to the same gateway. > The ROUTE header in 'real' subsequent INVITEs will guarentee that these INVITEs do follow the same path. The conflict arises when the subsequent INVITEs look like initial INVITEs with source routing; back to the above point. >3. If a proxy routes additional INVITEs to another gateway, we may get >multiple IAMs. > If source routing cannot be guarenteed to interop between various domains and INFO method is not to be used then two alternatives are left; either accept that some extraneous IAMs are (infrequently ?) generated or mandate that the UAC always sends the digits en-bloc (wait for stop digit or timer expiry). The latter approach avoids all problems posed by overlap sending and is the most likely to interop in all scenarios (vanilla proxies, vanilla clients, application servers etc..). > >At least the two first issues here are general issues for SIP, and not >only related to the overlap dialing. The third issue is related to PSTN >interworking in general, because because of forking and/or request >re-transmission INVITEs may end up at different gateways. > > >ISSUES WITH THE INFO METHOD: >---------------------------- > >4. We must wait for the response from the previous request before we >send an INFO. I assume you are concerned with the delay in set up because of this. Well, consider the situation when additional digits are carried in initial INVITEs; a domain may require that AAA procedures are performed on all initial INVITEs which will probably be a bigger drag on set up than waiting for the first response using the INFO approach. > >5. Requires new extensions (header, option-tags,...?) > > >ISSUES WITH THE INVITE: >----------------------- > >6. Depending on the number of INVITEs that the gateway mangages to route >to the next PSTN entity, we will have a number of pending INVITE >transactions, since we only get a provisional response to those INVITEs >until one INVITE finaly has enough digits to generate a 200, plus 484 >for all the pending requests. > The INVITEs generated by the ingress g/w all belong to the same call and therefore the same state machine within the ingress g/w (or a set of associated state machines); the same applies to the the egress g/w (assuming all the INVITEs get to the correct g/w). This is very much like multiple INVITEs (subsequent INVITEs allowed before 200 OK) on the same call leg. The only thing stopping that approach is current proxies will not handle the subsequent INVITEs before 200 OK but perhaps it is something to think about for the future. >7. One extra message, the ACK, for each INVITE. One ACK is nothing, but >if you have 20000 of them... > >I didn't include the issue of "when a call is completely routed from a >SIP point of view", because we can spend months arguing about that - and >I anyway think we should make our solutions depending on what's best >from a TECHNICAL point of view, not from a definition point of view. > >I've said it before, and I'll say it again, that I am not against the >idea of using INFO. However, I PERSONALY don't think the advantages >compared to INVITEs are so big that we should spend time on that (we >MUST, however, clarify the provisional response thing, and which final >responses will be sent to the pending INVITEs, in the ISUP-SIP draft). >Instead, I think we should put our efforts on, among other things, the >general SIP issues (1-3) we have no matter which overlap dialing method >we have, and which we also have in other SIP scenarios. I don't think that implementing INFO would be difficult. I also don't think that this approach would be incompatible with existing servers and clients as these would use 484/404 if addressed with insufficient digits. However, it is clear that the only problem it is solving is the potential conflict with source routing. I am coming to the conclusion that mandating en-bloc working when sending into the SIP network is the best, and simplest option; let the initial INVITE be the actual INVITE. Regards, K. Robinson Christer Holmberg on 21/02/2001 19:50:59 To: sip@lists.bell-labs.com cc: mwatson@nortelnetworks.com, Gonzalo.Camarillo@lmf.ericsson.se, Keith Robinson/MAIN/MC1@MCMAIN, jdrosen@dynamicsoft.com, taylor@nortelnetworks.com Subject: Re: [SIP] Operlap dialing within a SIP network Hi, I here try to make some kind of conclusion of the discussion. ISSUES NO MATTER WHICH METHOD IS USED: -------------------------------------- 1. We should be allowed to insert Route headers in initial INVITEs AND/OR 2. There should be some kind of routing mechnism in the proxis to make sure that additional INVITEs are routed to the same gateway. 3. If a proxy routes additional INVITEs to another gateway, we may get multiple IAMs. At least the two first issues here are general issues for SIP, and not only related to the overlap dialing. The third issue is related to PSTN interworking in general, because because of forking and/or request re-transmission INVITEs may end up at different gateways. ISSUES WITH THE INFO METHOD: ---------------------------- 4. We must wait for the response from the previous request before we send an INFO. 5. Requires new extensions (header, option-tags,...?) ISSUES WITH THE INVITE: ----------------------- 6. Depending on the number of INVITEs that the gateway mangages to route to the next PSTN entity, we will have a number of pending INVITE transactions, since we only get a provisional response to those INVITEs until one INVITE finaly has enough digits to generate a 200, plus 484 for all the pending requests. 7. One extra message, the ACK, for each INVITE. One ACK is nothing, but if you have 20000 of them... I didn't include the issue of "when a call is completely routed from a SIP point of view", because we can spend months arguing about that - and I anyway think we should make our solutions depending on what's best from a TECHNICAL point of view, not from a definition point of view. I've said it before, and I'll say it again, that I am not against the idea of using INFO. However, I PERSONALY don't think the advantages compared to INVITEs are so big that we should spend time on that (we MUST, however, clarify the provisional response thing, and which final responses will be sent to the pending INVITEs, in the ISUP-SIP draft). Instead, I think we should put our efforts on, among other things, the general SIP issues (1-3) we have no matter which overlap dialing method we have, and which we also have in other SIP scenarios. Regards, Christer Holmberg Ericsson Finland _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 10:53:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14798 for ; Thu, 22 Feb 2001 10:53:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 27C354435D; Thu, 22 Feb 2001 10:53:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id 6FF3E44353 for ; Thu, 22 Feb 2001 10:52:34 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id JAA07863; Thu, 22 Feb 2001 09:51:40 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Thu, 22 Feb 2001 09:47:49 -0600 Message-ID: From: "Culpepper, Bert" To: Christer Holmberg Cc: Jean-Francois Mule , sip@lists.bell-labs.com, stanley.khouw@clarent.com, jieying.li@claren.com Subject: RE: [SIP] T.38 and multiple streams MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 09:47:46 -0600 snip > >>I prefer the second option (no general c= line, one c= line > per media > >>description). Shall we recommend this second option in the > >>updated paper? > > > >I prefer the second option too. c= lines in the media descriptions > >are required when a session has more than one media stream and > >they need to be controlled independently. > > I guess this also depends on what the SDP standard says. For example, > when we > establish the call for voice, we probably will have a general c= line. > Is it then allowed, in the re-INVITE, to remove that and then suddenly > insert the c= for the media description? > From my reading of RFC 2327 (SDP standard) I don't see a problem with this. But it doesn't concern itself with a SIP reINVITE. I don't remember seeing this detail discussed in the SIP RFC or bis either. I also don't believe it necessarily needs to be discussed in the bis. However, I can understand an implementation having a problem with this. But it's an implementation thing. A robust implementation (one that realizes not all media streams may go to the same destination) should handle this IMO. snip regards, Bert _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 12:52:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20440 for ; Thu, 22 Feb 2001 12:52:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 71E4F44338; Thu, 22 Feb 2001 12:52:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ns-inetext.inet.com (ns-inetext.inet.com [199.171.211.140]) by lists.bell-labs.com (Postfix) with ESMTP id ACD8644337 for ; Thu, 22 Feb 2001 12:51:42 -0500 (EST) Received: from harpo.inetint.com (harpo [172.16.99.60]) by ns-inetext.inet.com (8.9.2/8.9.2) with ESMTP id LAA10241 for ; Thu, 22 Feb 2001 11:51:42 -0600 (CST) Received: from inet.com ([172.16.13.210]) by harpo.inetint.com (Netscape Messaging Server 3.6) with ESMTP id AAA2CC3 for ; Thu, 22 Feb 2001 11:51:48 -0600 Message-ID: <3A9551AD.542DEE@inet.com> From: Charles Zeng X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: zh-TW, zh-CN, en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: [SIP] Change IP in one SIP Transation? References: <3A92A5C9.C9B64F9B@inet.com> Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 11:51:41 -0600 Content-Transfer-Encoding: 7bit Hi friends, Does anyone has the experience to help for this issue? Can I use one IP process all incoming INVITE msg. And use another IP to send all 1xx and 2xx msg with the contact header associate. Does the SIP required one transation should be finish in same IP source. Best regards. Charles Zeng _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 14:56:18 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24826 for ; Thu, 22 Feb 2001 14:56:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B22CF44338; Thu, 22 Feb 2001 14:56:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ns-inetext.inet.com (ns-inetext.inet.com [199.171.211.140]) by lists.bell-labs.com (Postfix) with ESMTP id 71FB044337 for ; Thu, 22 Feb 2001 14:55:07 -0500 (EST) Received: from harpo.inetint.com (harpo [172.16.99.60]) by ns-inetext.inet.com (8.9.2/8.9.2) with ESMTP id NAA14049 for ; Thu, 22 Feb 2001 13:55:06 -0600 (CST) Received: from inet.com ([172.16.13.210]) by harpo.inetint.com (Netscape Messaging Server 3.6) with ESMTP id AAA1AD1; Thu, 22 Feb 2001 13:55:12 -0600 Message-ID: <3A956E99.7B58A9F@inet.com> From: Charles Zeng X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: zh-TW, zh-CN, en MIME-Version: 1.0 To: sip@lists.bell-labs.com, sip-implementors@cs.columbia.edu Subject: Re: [SIP] Change IP in one SIP Transation? References: <3A92A5C9.C9B64F9B@inet.com> <3A9551AD.542DEE@inet.com> <3A95638C.DD476818@lucent.com> <3A956BC1.A18EAAC9@inet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 13:55:05 -0600 Content-Transfer-Encoding: 7bit !Re-send with re-format chart Thanks Dear Vijay, Thanks for help. We are considering the high-performance SIP server design. Using one front processor (with its own IP) to receive all INVITE msg. Then forwarding these msg to main processors for msg process. For example: Using CONTACT header, we can do: ================== Multi-Processor UAS/UAC remote SIPTerminal Processor 1 Processor 0 IP: 10.0.1.1 IP: 10.0.0.1 ------------------------------------------------------------------------------------------------ INVITE send to 10.0.0.1 <--------------------------------------------------- 200 OK with contact=10.0.1.1 send from 10.0.0.1 ----------------------------------------------------> ACK send to 10.0.1.1 <---------------------------------------------------- But we want to do like this !!! ================== Multi-Processor UAS/UAC remote SIPTerminal Processor 1 Processor 0 IP: 10.0.1.1 IP: 10.0.0.1 ------------------------------------------------------------------------------------- INVITE send to 10.0.0.1 <--------------------------------------------------- Internal BUS send from Processor 0 to Processor 1 <-------INVITE 200 OK with contact=10.0.1.1 send from 10.0.1.1 (???) ----------------------------------------------------> ACK send to 10.0.1.1 <---------------------------------------------------- Is it OK? I am not sure. Because the INVITE/1xx/200OK is the one transcation define in SIP protocol, when using UDP, it sugguest use connect() to bind the destination IP to socket. The socket layer may reject the 100 Try, 183 and 200OK, treat them as the hacker packets. Best Regards Charles Zeng Vijay Gurbani wrote: > Charles Zeng wrote: > > > > Hi friends, > > [...moved to SIP Implementors...] > > > Does anyone has the experience to help for this issue? > > Can I use one IP process all incoming INVITE msg. > > And use another IP to send all 1xx and 2xx msg with > > the contact header associate. > > This is an implementation issue. For instance, you could use one process > for handling TCP SIP messages and another for handling UDP SIP messages. > Both of these processes may gather SIP messages from their respective > sockets and send it to the parser or transaction handler for further > processing. > > > > Does the SIP required one transation should be finish > > in same IP source. > > If I understand your question correctly, no. For instance, you can initiate > a CANCEL request to a previously pending INVITE transaction. > > Hope that helps. > > - vijay > -- > Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} > Internet Software and eServices Group > Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 > Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 16:03:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27335 for ; Thu, 22 Feb 2001 16:03:22 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6ED1E44338; Thu, 22 Feb 2001 16:03:19 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchatl1.edgeconnect.com (smtp.edgeconnect.com [63.99.99.17]) by lists.bell-labs.com (Postfix) with ESMTP id 312D544337 for ; Thu, 22 Feb 2001 16:02:45 -0500 (EST) Received: from DDCW6701 ([63.113.183.110]) by exchatl1.edgeconnect.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1TVYRSBT; Thu, 22 Feb 2001 15:54:15 -0500 From: "Victor A Paulsamy" To: "Ivan Wong" Cc: "SIP" , "Victor A Paulsamy" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200102020144.RAA22085@shorter.eng.sun.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Format changes but doesn't call pre-access codec's setInputFormat() method! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 22 Jan 2001 16:04:21 -0500 Content-Transfer-Encoding: 7bit Hi Ivan, PFA a mail, in which you wrote "Right when the media engine detects the format change, your pre-access codec will be notifed with the Codec.setInputFormat() call with the new format," however, that is not the case with my application. I'm working in an application which detects Comfort Noise (CN) and handles it. As per my understanding, non-voiced activity falls under CN thus a "RemotePayloadChangeEvent" should signify switching formats between audio format and CN. However, I'm faced with the following two situations when the "RemotePayloadChangeEvent" occurs and the format changes from audio format. Situation I. Pre-access codec is not called. Situation II. Pre-access codec is called; the new format is CN. The application receives/makes phone calls thro' Gateway. "Situation I" typically happens in the pauses in phone rings and also when a user pauses between voice activity. In other words the number of occurrences of "RemotePayloadChangeEvent" is *not equal* to the number of calls made to pre-access codec (the former being more frequent). Please help me understand what might happen in "Situation I"? Warm regards, --victor -----Original Message----- From: Discussion list for Java Media Framework API [mailto:JMF-INTEREST@java.sun.com]On Behalf Of Ivan Wong Sent: Thursday, February 01, 2001 8:44 PM To: JMF-INTEREST@JAVA.SUN.COM Subject: Re: [JMF] New Audio Format / Comfort Noise / Custom Codec Here some info for the record: After exchanging a few emails with Anshul, I suggested removing DirectAudioRenderer and use JavaSoundRenderer instead. He experimented with that and got better results. Here's how to switch off DirectAudioRenderer: 1) Run JMFRegistry; 2) Select the "PlugIns" tab; 3) Select the "Renderer" tab; 4) On the scrolling list, select com.sun.media.renderer.audio.DirectAudioRenderer; 5) Click "Remove" 6) Click "Commit" JavaSound uses a large mixing buffer and is better at handling data loss which is exactly the problem since the added codec artificially injects breakup to the audio stream. However, the price for that is long latency. We'll work on the DirectAudioRenderer to make it better at handling data loss. But there may still be a tradeoff between latency and quality... Ivan Wong Java Media Engineering Sun Microsystems, Inc. > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > Importance: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > Date: Thu, 1 Feb 2001 16:46:08 -0500 > From: Anshul Choudhry > Subject: Re: [JMF] New Audio Format / Comfort Noise / Custom Codec > Comments: To: Ivan Wong , achoudhry@voicecore.com > To: JMF-INTEREST@JAVA.SUN.COM > > Thanks for the reply Ivan. > > I did get the thing working as you suggested but there are still some open > issues. > > 1) I have to call DataSource.start() every time the payload changes. > 2) The setInputFormat is called only once for both for Format19 and format > 4. But I do get a payload change event in update( ReceiveStreamEvent event). > 3) I do "fool" the media engine and it works. > > Still the following problems remain. > > 1) The reception is OK as long as format does not change. As soon as it > changes I get a "broken echo" of last one second of reception. And sometimes > I get "broken echo" of the "broken echo". I have been trying all sort of > tricks to do away with it. But as yet I do not understand why it comes !! > > 2) Since the format is changing rapidly. The quality of voice is not too > good. A little amount of speech is cut every time the format changes. I > think it is the delay in the starting of datasource. > > > Ironically once I had no comfort noise coming from the transmitting side. I > had wonderful reception. > > I will appreciate your help on any of the questions above. > > regards, > > Anshul > > > > > -----Original Message----- > From: Ivan Wong [mailto:Ivan.Wong@eng.sun.com] > Sent: Tuesday, January 30, 2001 9:50 PM > To: JMF-INTEREST@JAVA.SUN.COM; achoudhry@voicecore.com > Subject: Re: [JMF] New Audio Format / Comfort Noise / Custom Codec > > > Anshul, > > There's a couple of missing details: > > 1) Right when the media engine detects the format change, > your pre-access codec will be notifed with the > Codec.setInputFormat() call with the new format. Your > codec needs to return the same format that's being set. > This is a way for the codec to reject the new format if > it's not supported. > > 2) In the Codec.process() call of your pre-access codec, you > need to explicitly set the format of the output buffer to > whatever the old format is. This is to "fool" the media > engine that no format change had occurred since your pre-access > codec is shielding the rest of the data pipeline from the > new format change. Otherwise, the new format change will > trickle down the data pipeline. That will cause what you > saw there. > > There may be other problems. But these are my guesses. > > Ivan Wong > Java Media Engineering > Sun Microsystems, Inc. > > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > X-Priority: 3 (Normal) > > X-MSMail-Priority: Normal > > Importance: Normal > > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > > Date: Mon, 29 Jan 2001 16:47:37 -0500 > > From: Anshul Choudhry > > Subject: [JMF] New Audio Format / Comfort Noise / Custom Codec > > To: JMF-INTEREST@JAVA.SUN.COM > > > > - I created a new AudioFormat for payload type 19. > > - Registered it with RTPManager. > > - Modified the FrameAccess example to take care of the new AudioFormat. > > > > The idea was to track & filter the CN data with G711/G723 data (by > > setDiscard(True) for all frames of CN data). > > > > The logic did not work however. Following is the log. > > > > PAYLOAD CHANGED..19 > > Track 0 is cn, 8000.0 Hz, 8-bit, Mono > > ..................................... > > Failed to build a graph to render the input format with the given custom > > options > > . > > Failed to realize: com.sun.media.ProcessEngine@41552289 > > Cannot build a flow graph with the customized options: > > Unable to add customed codecs: > > com.VoiceCore.Prototype.FrameAccess$PreAccessCodec@245d2284 > > com.VoiceCore.Prototype.FrameAccess$PostAccessCodec@25892284 > > Error: Unable to realize com.sun.media.ProcessEngine@41552289 > > PAYLOAD CHANGED..4 > > PAYLOAD CHANGED..19 > > > > > > What could possibly be wrong ? I appreciate your help. > > > > regards, > > > > Anshul > > > > PS : The goal remains the same. I want to play the incoming stream which > is > > alternating between format 4(G723) and format 19(Comfort Noise) say 5 > times > > a second. > > > > > > > > > > -----Original Message----- > > From: Ivan Wong [mailto:ivan.wong@eng.sun.com] > > Sent: Tuesday, January 09, 2001 1:17 PM > > To: achoudhry@voicecore.com; JMF-INTEREST@JAVA.SUN.COM > > Subject: RE: [JMF] RTP Payload type 19 > > > > > > Anshul, > > > > Good question! Mid-stream payload change are normally handled > > by creating a new Player to handle the new format. This is > > acceptable since with the new format, the data processing pipeline > > has to be rebuilt anyway. > > > > But comfort noise is such a special case that it should be handled > > more gracefully within the framework. We'll consider this case > > more thoroughly on the engineering implications. > > > > As for now, I can think of one workaround. But it's not that > > trivial. Here are the steps if you really want to try it: > > > > 1) Register a new format for Payload 19 with RTPManager.addFormat(). > > > > 2) Write a custom preprocessing effect. You can follow the > > FrameAccess sample on the solutions page: > > > > > http://java.sun.com/products/java-media/jmf/2.1/solutions/FrameAccess.html > > > > 3) Doing something similar to PreAccessCodec in the sample, except > > in this case, it's use to shield the rest of the flow graph with > > the intermitent "comfort noise" data. The idea is, when the > > input buffer's format changes to the new format representing > > payload 19, your codec can track that and do the necessary steps > > to handle the comfort noise data - by generating silence data; or > > simply ignore that data. > > > > Hope this helps somewhat. > > > > Ivan Wong > > Java Media Engineering > > Sun Microsystems, Inc. > > > > > -----Original Message----- > > > From: Discussion list for Java Media Framework API > > > [mailto:JMF-INTEREST@JAVA.SUN.COM]On Behalf Of Anshul Choudhry > > > Sent: Tuesday, January 09, 2001 7:10 AM > > > To: JMF-INTEREST@JAVA.SUN.COM > > > Subject: [JMF] RTP Payload type 19 > > > > > > > > > Hello, > > > > > > How does JMF plan to handle payload type 19 (Comfort Noise) ? > > > > > > If I am receving audio in U-Law (Payload type 0) or G.723 and > > > suddenly I get > > > payload change event to payload type 19. > > > > > > As described in JMF I should remove the old player and create a > > > new player. > > > Add new target etc. > > > > > > * But the payload 19 lasts only for one second and rapidly > > > changes between 0 > > > and 19. > > > > > > If I stick on to the old player. The audio can be heard no more. > > > > > > Even if JMF does not provide handling of payload type 19, could somebody > > > sugget a workaround ? > > > > > > Thanks, > > > > > > Anshul > > > > > > ================================================================== > > > ========= > > > FAQ: > > http://java.sun.com/products/java-media/jmf/forDevelopers/jmffaq.html > > List Archive: http://archives.java.sun.com/archives/jmf-interest.html > > > > To unsubscribe, send email to listserv@java.sun.com and include in the > body > > of the message "signoff JMF-INTEREST". > > > > > =========================================================================== > > FAQ: > http://java.sun.com/products/java-media/jmf/forDevelopers/jmffaq.html > > List Archive: http://archives.java.sun.com/archives/jmf-interest.html > > > > To unsubscribe, send email to listserv@java.sun.com and include in the > body > > of the message "signoff JMF-INTEREST". > > =========================================================================== > FAQ: http://java.sun.com/products/java-media/jmf/forDevelopers/jmffaq.html > List Archive: http://archives.java.sun.com/archives/jmf-interest.html > > To unsubscribe, send email to listserv@java.sun.com and include in the body > of the message "signoff JMF-INTEREST". =========================================================================== FAQ: http://java.sun.com/products/java-media/jmf/forDevelopers/jmffaq.html List Archive: http://archives.java.sun.com/archives/jmf-interest.html To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff JMF-INTEREST". _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 16:43:18 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28320 for ; Thu, 22 Feb 2001 16:43:17 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 91F5C44338; Thu, 22 Feb 2001 16:43:15 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchatl1.edgeconnect.com (smtp.edgeconnect.com [63.99.99.17]) by lists.bell-labs.com (Postfix) with ESMTP id AA9B944337 for ; Thu, 22 Feb 2001 16:42:01 -0500 (EST) Received: from DDCW6701 (63.113.183.106 [63.113.183.106]) by exchatl1.edgeconnect.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1TVYRSCR; Thu, 22 Feb 2001 16:33:42 -0500 From: "Victor A Paulsamy" To: "SIP" Subject: RE: [SIP] Format changes but doesn't call pre-access codec's setInputFormat() method! Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 22 Jan 2001 16:43:47 -0500 Content-Transfer-Encoding: 7bit Hi Every one, I apologize for the wrong posting! Warm regards, --victor -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Victor A Paulsamy Sent: Monday, January 22, 2001 4:04 PM To: Ivan Wong Cc: SIP; Victor A Paulsamy Subject: [SIP] Format changes but doesn't call pre-access codec's setInputFormat() method! Hi Ivan, PFA a mail, in which you wrote "Right when the media engine detects the format change, your pre-access codec will be notifed with the Codec.setInputFormat() call with the new format," however, that is not the case with my application. I'm working in an application which detects Comfort Noise (CN) and handles it. As per my understanding, non-voiced activity falls under CN thus a "RemotePayloadChangeEvent" should signify switching formats between audio format and CN. However, I'm faced with the following two situations when the "RemotePayloadChangeEvent" occurs and the format changes from audio format. Situation I. Pre-access codec is not called. Situation II. Pre-access codec is called; the new format is CN. The application receives/makes phone calls thro' Gateway. "Situation I" typically happens in the pauses in phone rings and also when a user pauses between voice activity. In other words the number of occurrences of "RemotePayloadChangeEvent" is *not equal* to the number of calls made to pre-access codec (the former being more frequent). Please help me understand what might happen in "Situation I"? Warm regards, --victor -----Original Message----- From: Discussion list for Java Media Framework API [mailto:JMF-INTEREST@java.sun.com]On Behalf Of Ivan Wong Sent: Thursday, February 01, 2001 8:44 PM To: JMF-INTEREST@JAVA.SUN.COM Subject: Re: [JMF] New Audio Format / Comfort Noise / Custom Codec Here some info for the record: After exchanging a few emails with Anshul, I suggested removing DirectAudioRenderer and use JavaSoundRenderer instead. He experimented with that and got better results. Here's how to switch off DirectAudioRenderer: 1) Run JMFRegistry; 2) Select the "PlugIns" tab; 3) Select the "Renderer" tab; 4) On the scrolling list, select com.sun.media.renderer.audio.DirectAudioRenderer; 5) Click "Remove" 6) Click "Commit" JavaSound uses a large mixing buffer and is better at handling data loss which is exactly the problem since the added codec artificially injects breakup to the audio stream. However, the price for that is long latency. We'll work on the DirectAudioRenderer to make it better at handling data loss. But there may still be a tradeoff between latency and quality... Ivan Wong Java Media Engineering Sun Microsystems, Inc. > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > X-Priority: 3 (Normal) > X-MSMail-Priority: Normal > Importance: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > Date: Thu, 1 Feb 2001 16:46:08 -0500 > From: Anshul Choudhry > Subject: Re: [JMF] New Audio Format / Comfort Noise / Custom Codec > Comments: To: Ivan Wong , achoudhry@voicecore.com > To: JMF-INTEREST@JAVA.SUN.COM > > Thanks for the reply Ivan. > > I did get the thing working as you suggested but there are still some open > issues. > > 1) I have to call DataSource.start() every time the payload changes. > 2) The setInputFormat is called only once for both for Format19 and format > 4. But I do get a payload change event in update( ReceiveStreamEvent event). > 3) I do "fool" the media engine and it works. > > Still the following problems remain. > > 1) The reception is OK as long as format does not change. As soon as it > changes I get a "broken echo" of last one second of reception. And sometimes > I get "broken echo" of the "broken echo". I have been trying all sort of > tricks to do away with it. But as yet I do not understand why it comes !! > > 2) Since the format is changing rapidly. The quality of voice is not too > good. A little amount of speech is cut every time the format changes. I > think it is the delay in the starting of datasource. > > > Ironically once I had no comfort noise coming from the transmitting side. I > had wonderful reception. > > I will appreciate your help on any of the questions above. > > regards, > > Anshul > > > > > -----Original Message----- > From: Ivan Wong [mailto:Ivan.Wong@eng.sun.com] > Sent: Tuesday, January 30, 2001 9:50 PM > To: JMF-INTEREST@JAVA.SUN.COM; achoudhry@voicecore.com > Subject: Re: [JMF] New Audio Format / Comfort Noise / Custom Codec > > > Anshul, > > There's a couple of missing details: > > 1) Right when the media engine detects the format change, > your pre-access codec will be notifed with the > Codec.setInputFormat() call with the new format. Your > codec needs to return the same format that's being set. > This is a way for the codec to reject the new format if > it's not supported. > > 2) In the Codec.process() call of your pre-access codec, you > need to explicitly set the format of the output buffer to > whatever the old format is. This is to "fool" the media > engine that no format change had occurred since your pre-access > codec is shielding the rest of the data pipeline from the > new format change. Otherwise, the new format change will > trickle down the data pipeline. That will cause what you > saw there. > > There may be other problems. But these are my guesses. > > Ivan Wong > Java Media Engineering > Sun Microsystems, Inc. > > > MIME-Version: 1.0 > > Content-Transfer-Encoding: 7bit > > X-Priority: 3 (Normal) > > X-MSMail-Priority: Normal > > Importance: Normal > > X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > > Date: Mon, 29 Jan 2001 16:47:37 -0500 > > From: Anshul Choudhry > > Subject: [JMF] New Audio Format / Comfort Noise / Custom Codec > > To: JMF-INTEREST@JAVA.SUN.COM > > > > - I created a new AudioFormat for payload type 19. > > - Registered it with RTPManager. > > - Modified the FrameAccess example to take care of the new AudioFormat. > > > > The idea was to track & filter the CN data with G711/G723 data (by > > setDiscard(True) for all frames of CN data). > > > > The logic did not work however. Following is the log. > > > > PAYLOAD CHANGED..19 > > Track 0 is cn, 8000.0 Hz, 8-bit, Mono > > ..................................... > > Failed to build a graph to render the input format with the given custom > > options > > . > > Failed to realize: com.sun.media.ProcessEngine@41552289 > > Cannot build a flow graph with the customized options: > > Unable to add customed codecs: > > com.VoiceCore.Prototype.FrameAccess$PreAccessCodec@245d2284 > > com.VoiceCore.Prototype.FrameAccess$PostAccessCodec@25892284 > > Error: Unable to realize com.sun.media.ProcessEngine@41552289 > > PAYLOAD CHANGED..4 > > PAYLOAD CHANGED..19 > > > > > > What could possibly be wrong ? I appreciate your help. > > > > regards, > > > > Anshul > > > > PS : The goal remains the same. I want to play the incoming stream which > is > > alternating between format 4(G723) and format 19(Comfort Noise) say 5 > times > > a second. > > > > > > > > > > -----Original Message----- > > From: Ivan Wong [mailto:ivan.wong@eng.sun.com] > > Sent: Tuesday, January 09, 2001 1:17 PM > > To: achoudhry@voicecore.com; JMF-INTEREST@JAVA.SUN.COM > > Subject: RE: [JMF] RTP Payload type 19 > > > > > > Anshul, > > > > Good question! Mid-stream payload change are normally handled > > by creating a new Player to handle the new format. This is > > acceptable since with the new format, the data processing pipeline > > has to be rebuilt anyway. > > > > But comfort noise is such a special case that it should be handled > > more gracefully within the framework. We'll consider this case > > more thoroughly on the engineering implications. > > > > As for now, I can think of one workaround. But it's not that > > trivial. Here are the steps if you really want to try it: > > > > 1) Register a new format for Payload 19 with RTPManager.addFormat(). > > > > 2) Write a custom preprocessing effect. You can follow the > > FrameAccess sample on the solutions page: > > > > > http://java.sun.com/products/java-media/jmf/2.1/solutions/FrameAccess.html > > > > 3) Doing something similar to PreAccessCodec in the sample, except > > in this case, it's use to shield the rest of the flow graph with > > the intermitent "comfort noise" data. The idea is, when the > > input buffer's format changes to the new format representing > > payload 19, your codec can track that and do the necessary steps > > to handle the comfort noise data - by generating silence data; or > > simply ignore that data. > > > > Hope this helps somewhat. > > > > Ivan Wong > > Java Media Engineering > > Sun Microsystems, Inc. > > > > > -----Original Message----- > > > From: Discussion list for Java Media Framework API > > > [mailto:JMF-INTEREST@JAVA.SUN.COM]On Behalf Of Anshul Choudhry > > > Sent: Tuesday, January 09, 2001 7:10 AM > > > To: JMF-INTEREST@JAVA.SUN.COM > > > Subject: [JMF] RTP Payload type 19 > > > > > > > > > Hello, > > > > > > How does JMF plan to handle payload type 19 (Comfort Noise) ? > > > > > > If I am receving audio in U-Law (Payload type 0) or G.723 and > > > suddenly I get > > > payload change event to payload type 19. > > > > > > As described in JMF I should remove the old player and create a > > > new player. > > > Add new target etc. > > > > > > * But the payload 19 lasts only for one second and rapidly > > > changes between 0 > > > and 19. > > > > > > If I stick on to the old player. The audio can be heard no more. > > > > > > Even if JMF does not provide handling of payload type 19, could somebody > > > sugget a workaround ? > > > > > > Thanks, > > > > > > Anshul > > > > > > ================================================================== > > > ========= > > > FAQ: > > http://java.sun.com/products/java-media/jmf/forDevelopers/jmffaq.html > > List Archive: http://archives.java.sun.com/archives/jmf-interest.html > > > > To unsubscribe, send email to listserv@java.sun.com and include in the > body > > of the message "signoff JMF-INTEREST". > > > > > =========================================================================== > > FAQ: > http://java.sun.com/products/java-media/jmf/forDevelopers/jmffaq.html > > List Archive: http://archives.java.sun.com/archives/jmf-interest.html > > > > To unsubscribe, send email to listserv@java.sun.com and include in the > body > > of the message "signoff JMF-INTEREST". > > =========================================================================== > FAQ: http://java.sun.com/products/java-media/jmf/forDevelopers/jmffaq.html > List Archive: http://archives.java.sun.com/archives/jmf-interest.html > > To unsubscribe, send email to listserv@java.sun.com and include in the body > of the message "signoff JMF-INTEREST". =========================================================================== FAQ: http://java.sun.com/products/java-media/jmf/forDevelopers/jmffaq.html List Archive: http://archives.java.sun.com/archives/jmf-interest.html To unsubscribe, send email to listserv@java.sun.com and include in the body of the message "signoff JMF-INTEREST". _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 16:54:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28533 for ; Thu, 22 Feb 2001 16:54:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D97BD44353; Thu, 22 Feb 2001 16:54:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by lists.bell-labs.com (Postfix) with ESMTP id BA91C44337 for ; Thu, 22 Feb 2001 16:53:40 -0500 (EST) Received: from blv-av-01.boeing.com ([192.54.3.60]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA26195 for ; Thu, 22 Feb 2001 15:53:39 -0600 (CST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3/8.9.2) with ESMTP id NAA17015 for ; Thu, 22 Feb 2001 13:53:38 -0800 (PST) Received: from xch-pssbh-03.ca.boeing.com by blv-hub-01.boeing.com with ESMTP for sip@lists.bell-labs.com; Thu, 22 Feb 2001 13:53:24 -0800 Received: by xch-pssbh-03.ca.boeing.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Feb 2001 13:53:24 -0800 Message-Id: <8006AC6A777F3F4F8B2A6383C19C5B7A01F12AFA@XCH-NW-01.ca.boeing.com> From: "Fleischman, Eric W" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Need for encrypted VoIP and Conferencing communications Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 13:53:17 -0800 Draft-ietf-sip-privacy-00.txt states that for SIP to be a viable alternative to the current PSTN, SIP must support certain popular telephony services offering privacy. However, the draft does not address a SIP privacy need having a substantially more compelling business case (for many industries) than the services identified by this draft. Specifically, if Internet-based collaboration, including VoIP, is to replace traditional telephony alternatives, including H.323-based conferencing, it is imperative that sessions initiated by SIP be optionally encrypted to ensure privacy protection. The requirement is that the parties participating in a session must be known to the other session participants, but that it be physically impossible for non-participants to eavesdrop upon that session, including thwarting all "man in the middle" exploits. The obvious approach by which this can be done is to define a "session encryption" alternative within SDP and a standard mechanism for encrypting traffic carried by RTP. It isn't clear to me whether SIP needs to be aware of the encrypted nature of this traffic or not, hence this query to this mail list: Does SIP need visibility into whether the session transports encrypt their data or not? A related question is: where should the encryption be done? Should it be done at the IPSec layer in a manner potentially transparent to the higher level protocols or should it be done at data level being conveyed by RTP -- or at some other layer? I would be very appreciative to learn what work, if any, members of this list have done to investigate these types of issues. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 17:15:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28921 for ; Thu, 22 Feb 2001 17:15:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E086E44338; Thu, 22 Feb 2001 17:15:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 9556744337 for ; Thu, 22 Feb 2001 17:14:05 -0500 (EST) 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 RAA15637; Thu, 22 Feb 2001 17:14:02 -0500 (EST) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA27916; Thu, 22 Feb 2001 17:14:05 -0500 (EST) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Feb 2001 17:14:04 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F034@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Fleischman, Eric W'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Need for encrypted VoIP and Conferencing communications MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 17:14:02 -0500 We have been trying to develop some upgrades to the security of sip, without much success. We have had interest at meetings, but no proposals or list discussion. Encryption of RTP is defined, and believed to be adequate. There is sentiment to allow integrity protection, which was done at in the PacketCable specs. Key distribution has to be done with the call control (sip). The mechanism currently used is to carry the keys in SDP, which implies that the SDP has to itself be encrypted. The PGP mechanisms in present SIP will allow you to do that, but we believe that such mechanisms are insufficient. For hop-by-hop security between sip components, IPSEC or TLS is quite satisfactory. The concern is end-to-end, or possibly domain to domain through an untrusted set of domains. You want the usual suspects, authentication, integrity protection and confidentiality, with a dose of replay protection. Some even want non-repudiation, but usually that has to do with billing, and thus may not be entirely a sip issue. I'd like to see a better way to get the keys for the RTP (D-H perhaps). Should you have expertise, you are welcome to work on this problem. There is a mailing list (sip-security@egroups.com), and we traditionally hold a bof-like meeting during each IETF meeting, to which all are welcome. Brian > -----Original Message----- > From: Fleischman, Eric W [mailto:Eric.Fleischman@PSS.Boeing.com] > Sent: Thursday, February 22, 2001 4:53 PM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] Need for encrypted VoIP and Conferencing communications > > > Draft-ietf-sip-privacy-00.txt states that for SIP to be a > viable alternative to the current PSTN, SIP must support > certain popular telephony services offering privacy. However, > the draft does not address a SIP privacy need having a > substantially more compelling business case (for many > industries) than the services identified by this draft. > > Specifically, if Internet-based collaboration, including > VoIP, is to replace traditional telephony alternatives, > including H.323-based conferencing, it is imperative that > sessions initiated by SIP be optionally encrypted to ensure > privacy protection. The requirement is that the parties > participating in a session must be known to the other session > participants, but that it be physically impossible for > non-participants to eavesdrop upon that session, including > thwarting all "man in the middle" exploits. The obvious > approach by which this can be done is to define a "session > encryption" alternative within SDP and a standard mechanism > for encrypting traffic carried by RTP. It isn't clear to me > whether SIP needs to be aware of the encrypted nature of this > traffic or not, hence this query to this mail list: Does SIP > need visibility into whether the session transports encrypt > their data or not? > > A related question is: where should the encryption be done? > Should it be done at the IPSec layer in a manner potentially > transparent to the higher level protocols or should it be > done at data level being conveyed by RTP -- or at some other > layer? I would be very appreciative to learn what work, if > any, members of this list have done to investigate these > types of issues. > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 17:33:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29193 for ; Thu, 22 Feb 2001 17:33:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9FAF544338; Thu, 22 Feb 2001 17:33:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 10E2D44337 for ; Thu, 22 Feb 2001 17:32:34 -0500 (EST) 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 f1MMWAC19772; Thu, 22 Feb 2001 23:32:10 +0100 (MET) Received: from lmf.ericsson.se ([136.225.183.37]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA20010; Thu, 22 Feb 2001 23:32:01 +0100 (MET) Message-ID: <3A959371.1690F0C0@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: sip@lists.bell-labs.com, mwatson@nortelnetworks.com, Gonzalo.Camarillo@lmf.ericsson.se, jdrosen@dynamicsoft.com, taylor@nortelnetworks.com Subject: Re: [SIP] Operlap dialing within a SIP network References: <802569FB.004B7DEE.00@marconicomms.com> Content-Type: multipart/mixed; boundary="------------02F8663F36EA032C164CC123" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 00:32:17 +0200 This is a multi-part message in MIME format. --------------02F8663F36EA032C164CC123 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Keith Robinson wrote: > > Hello, > > Christer wrote : > >>ISSUES NO MATTER WHICH METHOD IS USED: >>-------------------------------------- >> >> >>1. We should be allowed to insert Route headers in initial INVITEs >> > >ROUTE headers in initial INVITEs are allowed according to the latest >text from J. Rosenberg (I think). Whether or not another domain's proxies >can be guarenteed to honour them is a different matter. > >Why is a ROUTE header required in the very first initial INVITE anyway ? It's not required in the FIRST initial INVITE. >>AND/OR >> >>2. There should be some kind of routing mechnism in the proxis to make >>sure that additional INVITEs are routed to the same gateway. >> > >The ROUTE header in 'real' subsequent INVITEs will guarentee that >these INVITEs do follow the same path. The conflict arises when the subsequent >INVITEs look like initial INVITEs with source routing; back to the above point. >>3. If a proxy routes additional INVITEs to another gateway, we may get >>multiple IAMs. >> > >If source routing cannot be guarenteed to interop between various domains >and INFO method is not to be used then two alternatives are left; This may happend even if INFO is used, since the first INVITE having enough digits to generate IAM may be forked and reach two different gateways. I think, however, that this is more an issue of how the operator confiugres his proxies, DNS, etc. >either accept that some extraneous IAMs are (infrequently ?) generated or mandate that the >UAC always sends the digits en-bloc (wait for stop digit or timer expiry). The >latter approach avoids all problems posed by overlap sending and is the most likely to interop >in all scenarios (vanilla proxies, vanilla clients, application servers etc..). I guess this also depends very much on the requirements, and the functionality provided, by your gateway. For example, if all your INVITEs go to the same domain (ie the name host name) you MAY send the first INVITE as soon as you get the first digit. This will, however, generate LOTS of traffic, so I would assume that most gateways have some kind of dialing plan/digit timer for the outgoing SIP calls. This is also needed if INVITEs can be sent to different domains depending on the user number. For example, 12345 may be sent to sip:12345@proxy.spacecom.com, 12777 to sip:12777@sip.whatevertel.com, and all 1800 numbers may be sent to some redirect server that then returns a real phone number. In this case, the UAC gateway will have to wait for a number of digits from PSTN before the first INVITE can be sent. >>At least the two first issues here are general issues for SIP, and not >>only related to the overlap dialing. The third issue is related to PSTN >>interworking in general, because because of forking and/or request >>re-transmission INVITEs may end up at different gateways. >> >> >>ISSUES WITH THE INFO METHOD: >>---------------------------- >> >>4. We must wait for the response from the previous request before we >>send an INFO. > >I assume you are concerned with the delay in set up because of this. Well, >consider the situation when additional digits are carried in initial INVITEs; a >domain may require that AAA procedures are performed on all initial INVITEs >which will probably be a bigger drag on set up than waiting for the first >response using the INFO approach. This is true, but I think this is also much depending on how the network is configured, if the UAC gateway has some kind of dialplan etc etc etc. For example, you could agrue, like for the routing case, that INVITEs that look similar (only the To header and Request-URI has changed) will not require AAA procedures... >> >>5. Requires new extensions (header, option-tags,...?) >> > >> >>ISSUES WITH THE INVITE: >>----------------------- >> >>6. Depending on the number of INVITEs that the gateway mangages to route >>to the next PSTN entity, we will have a number of pending INVITE >>transactions, since we only get a provisional response to those INVITEs >>until one INVITE finaly has enough digits to generate a 200, plus 484 >>for all the pending requests. >> > >The INVITEs generated by the ingress g/w all belong to the same call and >therefore the same state machine within the ingress g/w (or a set of associated state >machines); Yes, but they are still separate transactions, which all have to be finished and ACKed. >the same applies to the the egress g/w (assuming all the INVITEs get to the correct g/w). This is >very much like multiple INVITEs (subsequent INVITEs allowed before 200 OK) on the same call >leg. >The only thing stopping that approach is current proxies will not handle the >subsequent INVITEs >before 200 OK but perhaps it is something to think about for the future. > >>7. One extra message, the ACK, for each INVITE. One ACK is nothing, but >>if you have 20000 of them... >> >>I didn't include the issue of "when a call is completely routed from a >>SIP point of view", because we can spend months arguing about that - and >>I anyway think we should make our solutions depending on what's best >>from a TECHNICAL point of view, not from a definition point of view. >> >>I've said it before, and I'll say it again, that I am not against the >>idea of using INFO. However, I PERSONALY don't think the advantages >>compared to INVITEs are so big that we should spend time on that (we >>MUST, however, clarify the provisional response thing, and which final >>responses will be sent to the pending INVITEs, in the ISUP-SIP draft). >>Instead, I think we should put our efforts on, among other things, the >>general SIP issues (1-3) we have no matter which overlap dialing method >>we have, and which we also have in other SIP scenarios. > >I don't think that implementing INFO would be difficult. I also don't think that >this approach would be incompatible with existing servers and clients as these would >use 484/404 if addressed with insufficient digits. However, it is clear that the >only problem it is solving is the potential conflict with source routing. I am coming >to the conclusion that mandating en-bloc working when sending into the SIP network is >the best, and simplest option; let the initial INVITE be the actual INVITE. If you can implement this for all the scenarios in the world we would never have to use overlap dialing. And, I don't think that overlap dialing will be used that much, but since it CAN be used we should make sure it works. I also think this is one case where experience will show how it works, since there are no rules saying how an operator has to configure his proxies, AAA etc. Regards, Christer Holmberg Ericsson Finland > > Regards, > > K. Robinson > > Christer Holmberg on 21/02/2001 19:50:59 > > > > > > > > To: sip@lists.bell-labs.com > > cc: mwatson@nortelnetworks.com, > Gonzalo.Camarillo@lmf.ericsson.se, Keith > Robinson/MAIN/MC1@MCMAIN, jdrosen@dynamicsoft.com, > taylor@nortelnetworks.com > > > > Subject: Re: [SIP] Operlap dialing within a SIP network > > > Hi, > > I here try to make some kind of conclusion of the discussion. > > ISSUES NO MATTER WHICH METHOD IS USED: > -------------------------------------- > > 1. We should be allowed to insert Route headers in initial INVITEs > > AND/OR > > 2. There should be some kind of routing mechnism in the proxis to make > sure that additional INVITEs are routed to the same gateway. > > 3. If a proxy routes additional INVITEs to another gateway, we may get > multiple IAMs. > > At least the two first issues here are general issues for SIP, and not > only related to the overlap dialing. The third issue is related to PSTN > interworking in general, because because of forking and/or request > re-transmission INVITEs may end up at different gateways. > > ISSUES WITH THE INFO METHOD: > ---------------------------- > > 4. We must wait for the response from the previous request before we > send an INFO. > > 5. Requires new extensions (header, option-tags,...?) > > ISSUES WITH THE INVITE: > ----------------------- > > 6. Depending on the number of INVITEs that the gateway mangages to route > to the next PSTN entity, we will have a number of pending INVITE > transactions, since we only get a provisional response to those INVITEs > until one INVITE finaly has enough digits to generate a 200, plus 484 > for all the pending requests. > > 7. One extra message, the ACK, for each INVITE. One ACK is nothing, but > if you have 20000 of them... > > I didn't include the issue of "when a call is completely routed from a > SIP point of view", because we can spend months arguing about that - and > I anyway think we should make our solutions depending on what's best > from a TECHNICAL point of view, not from a definition point of view. > > I've said it before, and I'll say it again, that I am not against the > idea of using INFO. However, I PERSONALY don't think the advantages > compared to INVITEs are so big that we should spend time on that (we > MUST, however, clarify the provisional response thing, and which final > responses will be sent to the pending INVITEs, in the ISUP-SIP draft). > Instead, I think we should put our efforts on, among other things, the > general SIP issues (1-3) we have no matter which overlap dialing method > we have, and which we also have in other SIP scenarios. > > Regards, > > Christer Holmberg > Ericsson Finland --------------02F8663F36EA032C164CC123 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 --------------02F8663F36EA032C164CC123-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 17:52:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29452 for ; Thu, 22 Feb 2001 17:52:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 889E744338; Thu, 22 Feb 2001 17:52:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 43DCA44337 for ; Thu, 22 Feb 2001 17:51:14 -0500 (EST) 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 f1MMoGd15759; Thu, 22 Feb 2001 23:50:16 +0100 (MET) Received: from lmf.ericsson.se ([164.48.155.229]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id XAA20652; Thu, 22 Feb 2001 23:50:11 +0100 (MET) Message-ID: <3A959631.E9ECA4E@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Roy, Radhika R, ALCOO" Cc: Keith Robinson , Christer Holmberg , sip@lists.bell-labs.com, mwatson@nortelnetworks.com, jdrosen@dynamicsoft.com, taylor@nortelnetworks.com Subject: Re: [SIP] Overlap dialing within a SIP network References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 00:44:01 +0200 Content-Transfer-Encoding: 7bit Hello, > I agree with Keith that we should mandate en-block due to the following > benefits: That's what I proposed in the DC IETF (long time ago), and folks insisted that overlap dialing had to be supported... Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 19:17:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01243 for ; Thu, 22 Feb 2001 19:17:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94BF144338; Thu, 22 Feb 2001 19:17:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by lists.bell-labs.com (Postfix) with ESMTP id A009144337 for ; Thu, 22 Feb 2001 19:16:35 -0500 (EST) Received: from fourier (FOURIER.INI.CMU.EDU [128.2.237.196]) by smtp1.andrew.cmu.edu (8.9.3/8.9.3) with SMTP id TAA19361 for ; Thu, 22 Feb 2001 19:16:33 -0500 (EST) From: "Janak Mehta" To: 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.2919.6600 Subject: [SIP] geographical location Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 19:13:54 -0500 Content-Transfer-Encoding: 7bit Hi, I'm extending SIP to provide geographical location of the mobile host within Wireless LAN. Basically I'm trying to send geographical location with presence information like "Online/Offline/Away" through NOTIFY method to subscriber of that particular presentity. I want to update(NOTIFY) all the subscibers of the particular presentity when that presentity moves within campus. Is there any defined header in sip through which I can send geo- graphical location in NOTIFY method? Can someone send me some pointers if work is already been done? Thanks, Janak -------------------------------------------- Janak S. Mehta Information Networking Institute Carnegie Mellon University Hamburg Hall, Room No A020, 4800 Forbes Avenue, Pittsburgh, PA 15213. Ph# (412)683-9049(R) (412)268-3029(O) ------------------------------------------- If you believe something is impossible, do not disturb the person who is doing it -- Albert Einstein ------------------------------------------- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 20:45:18 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02747 for ; Thu, 22 Feb 2001 20:45:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5004444358; Thu, 22 Feb 2001 20:45:15 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 109A044350 for ; Thu, 22 Feb 2001 20:44:39 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id RAA24288; Thu, 22 Feb 2001 17:43:50 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f1N1hsC18987; Thu, 22 Feb 2001 17:43:55 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id RAA15798; Thu, 22 Feb 2001 17:43:45 -0800 (PST) Message-ID: <3A95C112.74F18478@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule Cc: Sudipto Mukherjee , sip@lists.bell-labs.com Subject: Re: [SIP] T.38 fax calls - advertising capabilities and INVITE retransmit References: <6374EFC78443D41197DD00508B5C35DD01844DB3@rwcxch02.clarent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 20:46:58 -0500 Content-Transfer-Encoding: 7bit Joining in a bit late here, but in any case: Fundamentally, I don't understand why you view this as two separate media streams. You are muting one when you want to use the other, so why have two in the first place ? Also note, that there may be some undesirable QoS interactions that way. A couple of more specific comments on the current draft, some of which you may have already gotten: - T.30 CED is the same as as V.25 ANS and hence cannot be used as a fax detection mechanism (the V.21 fax preamble is fine). - Why must CNG tone detection not lead to a switch to T.38 ? - SIP call flow should probably include a Contact header resulting in some of your messages (e.g. ACK) going end-to-end rather than through the proxy). - Section 4.1 mentions that different UDP ports are to be used where as Section 6.2 lists that as open issue. I agree with Section 6.2 and would leave that choice to the gateways. Regards Flemming Jean-Francois Mule wrote: > Sudipto wrote: > > Is there a need for the fax enabled gateways to advertise the > > fax capability & params in the initial INVITE and 200 OK ? > > There are 2 possible approaches: > 1. UA advertises its full capabilities at the beginning of *any* call > 2. Upon fax detection, the UA initiates a re INVITE with new capabilities > Unless the Internet Fax gw is a fax terminal dedicated to fax transmissions, > I would prefer the second approach. It allows UAs to reject the re INVITE > with a 415 Unsupported Media Type if t.38 capabilities are not supported and > it allows the sender of the re INVITE to choose between t.38 fax or fax > passthrough. > Also, it could be heavy to advertize t.38 capabilities for all calls (you > would carry fax-related media attributes in the initial INVITE for all > calls...). > So at a general level, I do not believe there is 'a need' for advertizing > the fax capabilities in the initial INVITE. The only case would be when the > SIP UA knows that the call is going to be a fax (sometimes you can smell the > ink on the paper), for e.g. if it is an IP fax terminal or an analog gw with > an fxs port connected to a fax machine -- in that case, fine to advertise > both media capabilities in SDP. > Any comments on that? > > Sudipto wrote: > > Is there a timing constraint on the use of RE-INVITEs to negotiate > > the bit-rate and other parameters ? Potentially, the INVITEs could > > get lost and might need to be retransmitted. > I would think there is indeed a timing constraint based on the t.30 > protocol. The T1 timer may be adjusted when the INVITE is for a fax call > (see sections 10.4.1 and 10.5 of the rfc2543bis-01 draft on T1 and invite). > Is there a need to add some text on this in the I-D? Any suggestions? > > Thank you for your comments and questions Sudipto. > Regards, > Jean-Francois > > > -----Original Message----- > > From: Sudipto Mukherjee [mailto:sudiptom@cisco.com] > > Sent: Monday, October 30, 2000 12:26 PM > > To: Jean-Francois Mule > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] SIP and T.38 fax calls - Internet Draft > > > > > > Hello Jean, > > > > I read through the draft and had a few questions - > > > > Is there a need for the fax enabled gateways to advertise the > > fax capability & params in the initial INVITE and 200 OK ? > > > > Is there a timing constraint on the use of RE-INVITEs to negotiate > > the bit-rate and other parameters ? Potentially, the INVITEs could > > get lost and might need to be retransmitted. > > > > Thanks > > - Sudipto > > > > > > > > > > Jean-Francois Mule wrote: > > > > > > A new Internet-Draft has been submitted, dealing with real > > time fax calls > > > and SIP: call flows and BCP. > > > > > > Comments and suggestions are very much appreciated. > > > Regards, > > > Jean-Francois Mule > > > > > > -----Original Message----- > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > Sent: Tuesday, October 17, 2000 3:47 AM > > > Subject: I-D ACTION:draft-mule-sip-t38callflows-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > Title : SIP T.38 Call Flow Examples And > > Best Current > > > Practice > > > Author(s) : J. Mule > > > Filename : draft-mule-sip-t38callflows-00.txt > > > Pages : 19 > > > Date : 16-Oct-00 > > > > > > This document gives examples of SIP call flows for T.38 Internet fax > > > communications (SIP, the Session Initiation Protocol is defined in > > > RFC2543 [2] and T.38 is an ITU-T Recommendation [3]). Elements in > > > these call flows include SIP User Agents, SIP Proxy Servers, and > > > Gateways to the PSTN (Public Switch Telephone Network). > > > This document introduces best current practices for T.38 fax calls: > > > a call starts with audio capabilities, and, upon fax tone detection, > > > T.38 fax capabilities are negotiated. The T.38 fax call scenarios > > > include the detection of T.38 fax transmission by the receiving > > > side, or the emitting side, or both (in the latter case, a 'glare' > > > effect may appear). The current version of this document only > > > covers the case when the fax tone is detected by the receiving side > > > (other cases were left for discussion and may be included in the > > > future). Call flow diagrams and message details are shown. A list > > > of IANA defined SDP attribute names for T.38 is summarized in > > > section 5. > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-mule-sip-t38callflows-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-mule-sip-t38callflows-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-mule-sip-t38callflows-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. > > > > ------------------------------------------------------------------------ > > > > Part 1.2 Type: message/rfc822 > > Encoding: 7bit > > -- > > --------------------------------------------------------------------------- > Sudipto Mukherjee > Cisco Systems, Inc sudiptom@cisco.com > --------------------------------------------------------------------------- > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 21:29:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03561 for ; Thu, 22 Feb 2001 21:29:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 79BF04433D; Thu, 22 Feb 2001 21:29:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 56A454433B for ; Thu, 22 Feb 2001 21:28:08 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA25368; Thu, 22 Feb 2001 18:28:21 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f1N2S9X14217; Thu, 22 Feb 2001 18:28:09 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id SAA23884; Thu, 22 Feb 2001 18:27:58 -0800 (PST) Message-ID: <3A95CB6F.1FD49FFA@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule , Sudipto Mukherjee , sip@lists.bell-labs.com Subject: Re: [SIP] T.38 fax calls - advertising capabilities and INVITE retransmit References: <6374EFC78443D41197DD00508B5C35DD01844DB3@rwcxch02.clarent.com> <3A95C112.74F18478@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 21:31:12 -0500 Content-Transfer-Encoding: 7bit Oops - responded to the wrong one Please disregard. -- Flemming Flemming Andreasen wrote: > Joining in a bit late here, but in any case: > > Fundamentally, I don't understand why you view this as two separate media > streams. You are muting one when you want to use the other, so why have two in > the first place ? Also note, that there may be some undesirable QoS interactions > that way. > > A couple of more specific comments on the current draft, some of which you may > have already gotten: > - T.30 CED is the same as as V.25 ANS and hence cannot be used as a fax > detection mechanism (the V.21 fax preamble is fine). > - Why must CNG tone detection not lead to a switch to T.38 ? > - SIP call flow should probably include a Contact header resulting in some of > your messages (e.g. ACK) going end-to-end rather than through the proxy). > - Section 4.1 mentions that different UDP ports are to be used where as Section > 6.2 lists that as open issue. I agree with Section 6.2 and would leave that > choice to the gateways. > > Regards > > Flemming > > Jean-Francois Mule wrote: > > > Sudipto wrote: > > > Is there a need for the fax enabled gateways to advertise the > > > fax capability & params in the initial INVITE and 200 OK ? > > > > There are 2 possible approaches: > > 1. UA advertises its full capabilities at the beginning of *any* call > > 2. Upon fax detection, the UA initiates a re INVITE with new capabilities > > Unless the Internet Fax gw is a fax terminal dedicated to fax transmissions, > > I would prefer the second approach. It allows UAs to reject the re INVITE > > with a 415 Unsupported Media Type if t.38 capabilities are not supported and > > it allows the sender of the re INVITE to choose between t.38 fax or fax > > passthrough. > > Also, it could be heavy to advertize t.38 capabilities for all calls (you > > would carry fax-related media attributes in the initial INVITE for all > > calls...). > > So at a general level, I do not believe there is 'a need' for advertizing > > the fax capabilities in the initial INVITE. The only case would be when the > > SIP UA knows that the call is going to be a fax (sometimes you can smell the > > ink on the paper), for e.g. if it is an IP fax terminal or an analog gw with > > an fxs port connected to a fax machine -- in that case, fine to advertise > > both media capabilities in SDP. > > Any comments on that? > > > > Sudipto wrote: > > > Is there a timing constraint on the use of RE-INVITEs to negotiate > > > the bit-rate and other parameters ? Potentially, the INVITEs could > > > get lost and might need to be retransmitted. > > I would think there is indeed a timing constraint based on the t.30 > > protocol. The T1 timer may be adjusted when the INVITE is for a fax call > > (see sections 10.4.1 and 10.5 of the rfc2543bis-01 draft on T1 and invite). > > Is there a need to add some text on this in the I-D? Any suggestions? > > > > Thank you for your comments and questions Sudipto. > > Regards, > > Jean-Francois > > > > > -----Original Message----- > > > From: Sudipto Mukherjee [mailto:sudiptom@cisco.com] > > > Sent: Monday, October 30, 2000 12:26 PM > > > To: Jean-Francois Mule > > > Cc: sip@lists.bell-labs.com > > > Subject: Re: [SIP] SIP and T.38 fax calls - Internet Draft > > > > > > > > > Hello Jean, > > > > > > I read through the draft and had a few questions - > > > > > > Is there a need for the fax enabled gateways to advertise the > > > fax capability & params in the initial INVITE and 200 OK ? > > > > > > Is there a timing constraint on the use of RE-INVITEs to negotiate > > > the bit-rate and other parameters ? Potentially, the INVITEs could > > > get lost and might need to be retransmitted. > > > > > > Thanks > > > - Sudipto > > > > > > > > > > > > > > > Jean-Francois Mule wrote: > > > > > > > > A new Internet-Draft has been submitted, dealing with real > > > time fax calls > > > > and SIP: call flows and BCP. > > > > > > > > Comments and suggestions are very much appreciated. > > > > Regards, > > > > Jean-Francois Mule > > > > > > > > -----Original Message----- > > > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > > Sent: Tuesday, October 17, 2000 3:47 AM > > > > Subject: I-D ACTION:draft-mule-sip-t38callflows-00.txt > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > > > > > Title : SIP T.38 Call Flow Examples And > > > Best Current > > > > Practice > > > > Author(s) : J. Mule > > > > Filename : draft-mule-sip-t38callflows-00.txt > > > > Pages : 19 > > > > Date : 16-Oct-00 > > > > > > > > This document gives examples of SIP call flows for T.38 Internet fax > > > > communications (SIP, the Session Initiation Protocol is defined in > > > > RFC2543 [2] and T.38 is an ITU-T Recommendation [3]). Elements in > > > > these call flows include SIP User Agents, SIP Proxy Servers, and > > > > Gateways to the PSTN (Public Switch Telephone Network). > > > > This document introduces best current practices for T.38 fax calls: > > > > a call starts with audio capabilities, and, upon fax tone detection, > > > > T.38 fax capabilities are negotiated. The T.38 fax call scenarios > > > > include the detection of T.38 fax transmission by the receiving > > > > side, or the emitting side, or both (in the latter case, a 'glare' > > > > effect may appear). The current version of this document only > > > > covers the case when the fax tone is detected by the receiving side > > > > (other cases were left for discussion and may be included in the > > > > future). Call flow diagrams and message details are shown. A list > > > > of IANA defined SDP attribute names for T.38 is summarized in > > > > section 5. > > > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-mule-sip-t38callflows-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-mule-sip-t38callflows-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-mule-sip-t38callflows-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. > > > > > > ------------------------------------------------------------------------ > > > > > > Part 1.2 Type: message/rfc822 > > > Encoding: 7bit > > > > -- > > > > --------------------------------------------------------------------------- > > Sudipto Mukherjee > > Cisco Systems, Inc sudiptom@cisco.com > > --------------------------------------------------------------------------- > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Flemming Andreasen > Cisco Systems > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 21:33:45 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04087 for ; Thu, 22 Feb 2001 21:33:45 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D7EF644371; Thu, 22 Feb 2001 21:30:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id A841D4433B for ; Thu, 22 Feb 2001 21:29:27 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA09752; Thu, 22 Feb 2001 18:29:30 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f1N2TDx08735; Thu, 22 Feb 2001 18:29:13 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id SAA24126; Thu, 22 Feb 2001 18:29:12 -0800 (PST) Message-ID: <3A95CBB9.F9BC393B@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: Christer Holmberg , Jean-Francois Mule , sip@lists.bell-labs.com, stanley.khouw@clarent.com, jieying.li@claren.com Subject: Re: [SIP] T.38 and multiple streams References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 21:32:25 -0500 Content-Transfer-Encoding: 7bit Joining in a bit late here, but in any case: Fundamentally, I don't understand why you view this as two separate media streams. You are muting one when you want to use the other, so why have two in the first place ? Also note, that there may be some undesirable QoS interactions that way. A couple of more specific comments on the current draft, some of which you may have already gotten: - T.30 CED is the same as as V.25 ANS and hence cannot be used as a fax detection mechanism (the V.21 fax preamble is fine). - Why must CNG tone detection not lead to a switch to T.38 ? - SIP call flow should probably include a Contact header resulting in some of your messages (e.g. ACK) going end-to-end rather than through the proxy). - Section 4.1 mentions that different UDP ports are to be used where as Section 6.2 lists that as open issue. I agree with Section 6.2 and would leave that choice to the gateways. Regards Flemming "Culpepper, Bert" wrote: > snip > > > >>I prefer the second option (no general c= line, one c= line > > per media > > >>description). Shall we recommend this second option in the > > >>updated paper? > > > > > >I prefer the second option too. c= lines in the media descriptions > > >are required when a session has more than one media stream and > > >they need to be controlled independently. > > > > I guess this also depends on what the SDP standard says. For example, > > when we > > establish the call for voice, we probably will have a general c= line. > > Is it then allowed, in the re-INVITE, to remove that and then suddenly > > insert the c= for the media description? > > > > >From my reading of RFC 2327 (SDP standard) I don't see a problem > with this. But it doesn't concern itself with a SIP reINVITE. I don't > remember seeing this detail discussed in the SIP RFC or bis either. > I also don't believe it necessarily needs to be discussed in the bis. > However, I can understand an implementation having a problem with this. > But it's an implementation thing. A robust implementation (one that > realizes not all media streams may go to the same destination) should > handle this IMO. > > snip > > regards, > Bert > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Thu Feb 22 22:47:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07194 for ; Thu, 22 Feb 2001 22:47:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0103844338; Thu, 22 Feb 2001 22:47:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 1586144337 for ; Thu, 22 Feb 2001 22:46:23 -0500 (EST) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f1N3jc128617; Thu, 22 Feb 2001 22:45:38 -0500 (EST) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id WAA17044; Thu, 22 Feb 2001 22:44:47 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Feb 2001 22:45:37 -0500 Message-ID: From: "Roy, Radhika R, ALCOO" To: Gonzalo Camarillo Cc: Keith Robinson , Christer Holmberg , sip@lists.bell-labs.com, mwatson@nortelnetworks.com, jdrosen@dynamicsoft.com, taylor@nortelnetworks.com Subject: RE: [SIP] Overlap dialing within a SIP network MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 22 Feb 2001 22:45:36 -0500 Hi, Gonzalo: I appreciate that you have the first one to propose the en-blocking solution. Now, we have seen the pros and cons of all alternatives. It appears that the en-blocking is the best solution. Best regards, Radhika -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] Sent: Thursday, February 22, 2001 5:44 PM To: Roy, Radhika R, ALCOO Cc: Keith Robinson; Christer Holmberg; sip@lists.bell-labs.com; mwatson@nortelnetworks.com; jdrosen@dynamicsoft.com; taylor@nortelnetworks.com Subject: Re: [SIP] Overlap dialing within a SIP network Hello, > I agree with Keith that we should mandate en-block due to the following > benefits: That's what I proposed in the DC IETF (long time ago), and folks insisted that overlap dialing had to be supported... Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 02:25:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23831 for ; Fri, 23 Feb 2001 02:25:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA1BC44338; Fri, 23 Feb 2001 02:25:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 2D42D44337 for ; Fri, 23 Feb 2001 02:24:44 -0500 (EST) 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 f1N7ObC27461; Fri, 23 Feb 2001 08:24:37 +0100 (MET) Received: from lmf.ericsson.se ([136.225.183.42]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id IAA25129; Fri, 23 Feb 2001 08:24:30 +0100 (MET) Message-ID: <3A96103D.5CB05A6E@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Roy, Radhika R, ALCOO" Cc: Gonzalo Camarillo , Keith Robinson , sip@lists.bell-labs.com, mwatson@nortelnetworks.com, jdrosen@dynamicsoft.com, taylor@nortelnetworks.com Subject: Re: [SIP] Overlap dialing within a SIP network References: Content-Type: multipart/mixed; boundary="------------4FED02207972E6750DB37FEF" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 09:24:45 +0200 This is a multi-part message in MIME format. --------------4FED02207972E6750DB37FEF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, If we remove the support of overlap dialing now, it won't take long before we have a similar discussion again - when people want to add it back... I agree, however, that in most cases one would use en-blocking, so overlap dialing will probably be very much used. However, IF it is used, we should agree on how it's done, and that it works. Regards, Christer Holmberg Ericsson Finland "Roy, Radhika R, ALCOO" wrote: > > Hi, Gonzalo: > > I appreciate that you have the first one to propose the en-blocking > solution. > > Now, we have seen the pros and cons of all alternatives. It appears that the > en-blocking is the best solution. > > Best regards, > Radhika > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Thursday, February 22, 2001 5:44 PM > To: Roy, Radhika R, ALCOO > Cc: Keith Robinson; Christer Holmberg; sip@lists.bell-labs.com; > mwatson@nortelnetworks.com; jdrosen@dynamicsoft.com; > taylor@nortelnetworks.com > Subject: Re: [SIP] Overlap dialing within a SIP network > > Hello, > > > I agree with Keith that we should mandate en-block due to the following > > benefits: > > That's what I proposed in the DC IETF (long time ago), and folks > insisted that overlap dialing had to be supported... > > Gonzalo > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. --------------4FED02207972E6750DB37FEF 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 --------------4FED02207972E6750DB37FEF-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 03:05:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24085 for ; Fri, 23 Feb 2001 03:05:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A550044338; Fri, 23 Feb 2001 03:05:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by lists.bell-labs.com (Postfix) with ESMTP id 5FBF544337 for ; Fri, 23 Feb 2001 03:04:33 -0500 (EST) 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 f1N86JR22521 for ; Fri, 23 Feb 2001 10:06:19 +0200 (EET) Received: from esebh12nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 23 Feb 2001 10:04:30 +0200 Received: by esebh12nok with Internet Mail Service (5.5.2652.78) id ; Fri, 23 Feb 2001 10:04:30 +0200 Message-ID: From: hannu.hietalahti@nokia.com To: mbarnes@nortelnetworks.com, sip@lists.bell-labs.com Subject: RE: [SIP] Minutes of 3GPP CN1-SA2 SIP joint meeting MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 10:03:38 +0200 Dear all, I am sorry for this inaccuracy of my posting yesterday. I am still learning the netiquette of this mailing list. I had my message typed assuming there would be an attachment, then realised that huge attachments might not be liked very much and changed it to a link to the main 3GPP website. But I forgot to remove the mention about attachment, sorry! If you follow the link to 3GPP meeting documents, you should find folders: Agenda - agenda items for the meeting, this should be available before the meeting Invitation - How & when to get there, provided by the host Report - Minutes of the meeting separated here to tell it apart from the other meeting documents Tdocs - all tdocs proposed to the meeting Templates - CR-cover page, tdoc request form, etc. The executive summary I first intended to attach is Summary-NewJersey0102 and the full report containing the decisions and discussion on all documents in the meeting is NewJersey0102.zip. When reading either report you get a pointer to the actual meeting contributions which are all in Tdocs -folder. Some 3GPP WGs publish their report as tdoc but I don't do that because such a tdoc would be difficult to find among hundreds of other tdocs from a meeting. It would also need to be revised several times as I distribute an interim report with the status up to closing of business every day during the meeting. The naming convention for all 3GPP meetings is: MN-yy####, where M = 3GPP TSG or TSG working group meeting N = number of working group or P for TSG plenary yy = year (note that we used to have 3 digits for year during 2000 but then we had to hex code tdoc numbers towards the end of the year) #### = running number of the tdoc in this meeting (plenary or WG) since beginning of the year So e.g. N1-010223 is the 0223th tdoc during year 01 in TSGN (Core Network) working group 1. BTW, if you wish to follow 3GPP CN1 SIP activities more regularly then why not add a bookmark to http://www.3gpp.org/ftp/TSG_CN/WG1_mm-cc-sm/ which is the folder for CN1 related meetings, both dedicated SIP meetings and regular CN1 meetings covering GSM and UMTS issues additinally to SIP. Regards, Hannu -----Original Message----- From: Mary Barnes [mailto:mbarnes@nortelnetworks.com] Sent: 22. February 2001 17:00 To: 'sip@lists.bell-labs.com' Cc: Hietalahti Hannu (NMP/Oulu) Subject: RE: [SIP] Minutes of 3GPP CN1-SA2 SIP joint meeting Hannu, I apologize for the pedantic postings, but I've looked at the N1-010233 tdoc you reference. Is that the "Executive summary" to which you refer? I'm just trying to clarify for folks that aren't familiar with the 3GPP document numbering process (i.e. IETF likes more user friendly words (for drafts) and we all know SIP does too). I'm thinking that instead of attaching the "Executive summary", you included it inline. Is that correct? Thanks, Mary Barnes. -----Original Message----- From: Barnes, Mary [RICH1:B602-M:EXCH] Sent: Thursday, February 22, 2001 8:46 AM To: sip@lists.bell-labs.com Cc: 'hannu.hietalahti@nokia.com' Subject: RE: [SIP] Minutes of 3GPP CN1-SA2 SIP joint meeting Hannu, Where is the attachment containing the executive summary of this meeting? I checked the URL you included and was unable to determine from the tdoclist, which document contained the executive summary. Is this located elsewhere? Thanks, Mary H. Barnes IMS Solutions Standards Strategy mbarnes@nortelnetworks.com 972-684-5432 -----Original Message----- From: hannu.hietalahti@nokia.com [ mailto:hannu.hietalahti@nokia.com ] Sent: Thursday, February 22, 2001 6:21 AM To: sip@lists.bell-labs.com Subject: [SIP] Minutes of 3GPP CN1-SA2 SIP joint meeting Dear all, The latest 3GPP CN1-SA2 SIP joint meeting dealt with a contribution about co-operation between IETF and those 3GPP working groups which are working on SIP protocol. First a brief introduction of these 3GPP groups for those who are not familiar with the organisation: SA2 is working group 2 in TSG (Technical Specification Group) SA (Services and System Aspects). They are responsible for the overall system architecture. CN1 is working group 1 in TSG CN (Core Network) responsible for the Gm interface, i.e. the one between the terminal and CSCF. CN1 is the WG which is most involved in 3GPP SIP work. Tdoc N1-010233 titled "Feedback from IETF interim SIP working group meeting" summarises the proposed 3GPP originated contributions and communication between IETF and 3GPP meetings. It became clear during the discussion on this document that the main reason for lack of 3GPP originated contributions has been that the 3GPP delegates have wanted to get the main 3GPP specifications more stable before contributing them to IETF meetings. However, it was also seen that sufficient stability is being reached and now it is appropriate to start closer co-operation between the relevant working groups of IETF and 3GPP. This needs to be done to provide IETF the understanding of 3GPP decisions related with mobile SIP and to collect the valuable comments and hints from the IETF SIP experts. The following decisions on necessary 3GPP actions were made during the discussion: 1. Chairman is asked to distribute a summary of CN1 SIP related discussions and decisions to the IETF SIP mailing list. 2. The dependency between IETF RFCs and 3GPP TSs needs to identified. The list of IETF SIP specifications which will be referred to will be communicated to IETF SIP group by the rapporteur. This will be the list of RFCs that are prerequisite for the publication of 3GPP specification as a standard. 3. The work on the draft specifications is twofold: 3GPP needs to review and comment on the IETF SIP drafts which are relevant for 3GPP, i.e. the ones which are referred to by 3GPP specifications AND 4. Call flows defining the 3GPP related enhancements need to be contributed to IETF by 3GPP members. This was addressed in the meeting by a drafting group of 3GPP CN1 and SA2 members to draft an extract of 24.228 signalling flows for IETF review and comments. An executive summary of the chairman's meeting report is attached. The full report and the meeting documents are available in http://www.3gpp.org/ftp/TSG_CN/WG1_mm-cc-sm/SIP_meetings/CN1_SA2_03_(New%20J ersey)/ With Best Regards, Hannu Hietalahti CN1 Chairman hannu.hietalahti@nokia.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 04:38:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25487 for ; Fri, 23 Feb 2001 04:38:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B65FF44338; Fri, 23 Feb 2001 04:38:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis22.marconicomms.com (cvis22.marconicomms.com [195.99.244.54]) by lists.bell-labs.com (Postfix) with ESMTP id A635B44337 for ; Fri, 23 Feb 2001 04:37:14 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis22.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 23 Feb 2001 09:37:10 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id JAA15446; Fri, 23 Feb 2001 09:37:09 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569FC.0034B396 ; Fri, 23 Feb 2001 09:35:38 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Gonzalo Camarillo Cc: "Roy, Radhika R, ALCOO" , Christer Holmberg , sip@lists.bell-labs.com, mwatson@nortelnetworks.com, jdrosen@dynamicsoft.com, taylor@nortelnetworks.com Message-ID: <802569FC.0034A082.00@marconicomms.com> Subject: Re: [SIP] Overlap dialing within a SIP network Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 09:34:53 +0000 Hello, Certainly, a SIP/PSTN g/w must be able to receive digits in overlap on the PSTN side, but I can see no advantages of continuing with the overlap into the SIP network. In light of current discussion, perhaps it is worth proposing en-bloc working into the SIP network again and invite a technical discussion as to exactly why overlap should be maintained into the SIP network. Regards, K. Robinson. Gonzalo Camarillo on 22/02/2001 22:44:01 To: "Roy, Radhika R, ALCOO" cc: Keith Robinson/MAIN/MC1@MCMAIN, Christer Holmberg , sip@lists.bell-labs.com, mwatson@nortelnetworks.com, jdrosen@dynamicsoft.com, taylor@nortelnetworks.com Subject: Re: [SIP] Overlap dialing within a SIP network Hello, > I agree with Keith that we should mandate en-block due to the following > benefits: That's what I proposed in the DC IETF (long time ago), and folks insisted that overlap dialing had to be supported... Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 04:57:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25721 for ; Fri, 23 Feb 2001 04:57:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DEF1C44349; Fri, 23 Feb 2001 04:57:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 06A0844338 for ; Fri, 23 Feb 2001 04:56:18 -0500 (EST) 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 EAA20924; Fri, 23 Feb 2001 04:56:17 -0500 (EST) 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 EAA02394; Fri, 23 Feb 2001 04:56:16 -0500 (EST) Message-ID: <3A965EEC.BE0D436C@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Janak Mehta Cc: sip@lists.bell-labs.com Subject: Re: [SIP] geographical location References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 05:00:28 -0800 Content-Transfer-Encoding: 7bit I will be sending out a brief note on this topic early next week. However, you're probably looking at extensions of the presence format, rather than a SIP extension. Janak Mehta wrote: > > Hi, > > I'm extending SIP to provide geographical location of the mobile > host within Wireless LAN. Basically I'm trying to send geographical > location with presence information like "Online/Offline/Away" through > NOTIFY method to subscriber of that particular presentity. > > I want to update(NOTIFY) all the subscibers of the particular presentity > when that presentity moves within campus. > > Is there any defined header in sip through which I can send geo- > graphical location in NOTIFY method? > > Can someone send me some pointers if work is already been done? > > Thanks, > Janak > > -------------------------------------------- > Janak S. Mehta > Information Networking Institute > Carnegie Mellon University > Hamburg Hall, Room No A020, > 4800 Forbes Avenue, > Pittsburgh, PA 15213. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 05:40:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26325 for ; Fri, 23 Feb 2001 05:40:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2DEFC44338; Fri, 23 Feb 2001 05:40:08 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 0F00844337 for ; Fri, 23 Feb 2001 05:39:43 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Feb 23 05:36:55 EST 2001 Received: by lists.bell-labs.com (Postfix) id 20F8A44380; Fri, 23 Feb 2001 05:25:27 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id 518754437D for ; Fri, 23 Feb 2001 05:25:26 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Feb 2001 10:25:25 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0017453E8@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] 3GPP current needs from SIP drafts Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 10:25:22 -0000 Hannu has circulated a summary of the last 3GPP discussion on the use of SIP. As there was a discussion in the IETF SIP WG ad-hoc on what drafts 3GPP was currently looking at from the IETF, I undertook to provide the current list. Before I give the list, I must stress that it is preliminary. The basis for the list is the flows that currently exist in 24.228, and the elements of signalling that they use. Therefore the list is probably incomplete because 24.228 is incomplete, and may be wrong, because 24.228 is still at a stage where comments can significantly change its contents. We are intending contributing significant parts of 24.228 to the SIP WG for you to analyse, discuss, pull apart, comment on or whatever. The list is currently as follows: draft-ietf-sip-rfc2543bis SIP: Session Initiation Protocol draft-sip-manyfolks-resource Integration of resource management and SIP draft-ietf-sip-100rel Reliability of Provisional Responses in SIP draft-ietf-sip-privacy SIP extensions for caller identity and privacy draft-ietf-sip-call-auth SIP extensions for media authorization The N1-010273 that was referred to in previous discussion on this list, is the 3GPP work item description. This document evolves from meeting to meeting (changing tdoc numbers as it goes!!!!), and will be used to maintain the list of areas where we are dependent on IETF work. 3GPP intends to keep you directly informed as that list changes. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 05:48:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26368 for ; Fri, 23 Feb 2001 05:48:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2F1EC4433B; Fri, 23 Feb 2001 05:48:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from aurora.tsm.es (unknown [194.224.100.20]) by lists.bell-labs.com (Postfix) with ESMTP id 27A0044338 for ; Fri, 23 Feb 2001 05:47:46 -0500 (EST) Received: by aurora.tsm.es; (8.8.8/1.3/10May95) id LAA00889; Fri, 23 Feb 2001 11:47:57 +0100 (MET) From: Subject: Re: [SIP] geographical location To: Janak Mehta Cc: Henning Schulzrinne , sip@lists.bell-labs.com Message-ID: X-MIMETrack: Serialize by Router on abantos/TSM( =?iso-8859-1?q?Versi=F3n_5=2E0=2E5_|Octubre_21=2C_2000=29_at_23=2F02=2F?= =?us-ascii?q?2001?= 11:47:27 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 11:29:07 +0100 Well, it is a long time since i do not follow SIP drafts, so maybe i am talking about something already defined. Sorry if so. There are at least two features involved, one is a specific header for location information. It would be similar to GSM, which includes in every call establishment information related to the cell the call is "sent" from. It is a sort of location information, and currently most of the call-related location services are based on this cell-info. I presume probably 3GPP would require a SIP specific header for this purpose , also. The second feature is how to handle the delivery of "location change" in a not-call related basis. This problem (and also the presence information delivery) will be faced by CAMEL Phase 3 (see 3GPP TS 23.078) by defining a subscriber category (M-CSI) which is stored in the user profile in HLR and also in the visited MSC-VLR. This category includes different triggers, such as * Location update in the same VLR service area * Location update in another VLR service area * IMSI attach, i.e. 1st REGISTER from the UA) * MS initiated IMSI attach (explicit detach), i.e. un-REGISTER * Network initiated IMSI detach (implicit detach), i.e. the UA does not send another REGISTER in the specified time So it is the MSC-VLR (visited SIP server, I think) the one that generates such information from the one generated by the UA itself. Seems that your extension in the NOTIFY behaviour is a sort of Location update in the cellular environment. The difference is that in the cellular environment this Location Update procedure is standardised, but i am not sure your NOTIFY extension would be covered by all UAs. See also that CAMEL Phase 1 is the one currently deployed in GSM networks, so it will take some time to see CAMEL Phase 3 running hope this helps -----------------------------< O >----------------------------------- Javier Ferreiro Garcia Telefonica Moviles Spain Consultant Dpto. de Desarrollo de Mercado Voice Services Unit Telf.: +34 630 00 43 13 -----------------------------< O >----------------------------------- >I will be sending out a brief note on this topic early next week. >However, you're probably looking at extensions of the presence format, >rather than a SIP extension. >Janak Mehta wrote: >> >> Hi, >> >> I'm extending SIP to provide geographical location of the mobile >> host within Wireless LAN. Basically I'm trying to send geographical >> location with presence information like "Online/Offline/Away" through >> NOTIFY method to subscriber of that particular presentity. >> >> I want to update(NOTIFY) all the subscibers of the particular presentity >> when that presentity moves within campus. >> >> Is there any defined header in sip through which I can send geo- >> graphical location in NOTIFY method? >> >> Can someone send me some pointers if work is already been done? >> >> Thanks, >> Janak >> >> -------------------------------------------- >> Janak S. Mehta >> Information Networking Institute >> Carnegie Mellon University >> Hamburg Hall, Room No A020, >> 4800 Forbes Avenue, >> Pittsburgh, PA 15213. >> _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 08:01:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29933 for ; Fri, 23 Feb 2001 08:01:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9E58D44338; Fri, 23 Feb 2001 08:01:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 36AF144337 for ; Fri, 23 Feb 2001 08:00:03 -0500 (EST) 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 f1NCw9C06702; Fri, 23 Feb 2001 13:58:09 +0100 (MET) Received: from lmf.ericsson.se ([164.48.155.228]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id NAA16902; Fri, 23 Feb 2001 13:58:05 +0100 (MET) Message-ID: <3A965CEE.AD00FBF5@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: bidulock@openss7.org Cc: "Roy, Radhika R, ALCOO" , Keith Robinson , Christer Holmberg , sip@lists.bell-labs.com, mwatson@nortelnetworks.com, jdrosen@dynamicsoft.com, taylor@nortelnetworks.com Subject: Re: [SIP] Overlap dialing within a SIP network References: <3A959631.E9ECA4E@lmf.ericsson.se> <20010222221227.A10468@bfgbhome> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 14:51:58 +0200 Content-Transfer-Encoding: 7bit Hello, I am going to put together a presentation for the next IETF. There we will choose between a proposed solution for supporting overlap or doing en-bloc (regular SIP) all the time. This way we will be able to progress and move on. See you guys in Minneapolis, Gonzalo "Brian F. G. Bidulock" wrote: > > Gonzalo, > > Perhaps those which spoke up at the DC IETF who were requesting > that overlap dialing be supported could indicate why there is > a need for overlap dialing. I know of no need for overlap dialing > and an explanation of need has not been forthcoming. > > Perhaps the WG chair can ask for any objections to your original > proposal to mandate en-bloc to see if any rational objections > exist. > > --Brian > > Gonzalo Camarillo wrote: (Fri, 23 Feb 2001 00:44:01) > > Hello, > > > > > I agree with Keith that we should mandate en-block due to the following > > > benefits: > > > > That's what I proposed in the DC IETF (long time ago), and folks > > insisted that overlap dialing had to be supported... > > > > Gonzalo > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementor's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > -- > Brian F. G. Bidulock > bidulock@openss7.org > http://www.openss7.org/ -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 08:27:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00611 for ; Fri, 23 Feb 2001 08:27:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 80C3244338; Fri, 23 Feb 2001 08:27:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rsys000a.roke.co.uk (unknown [193.118.201.102]) by lists.bell-labs.com (Postfix) with ESMTP id 4E21344337 for ; Fri, 23 Feb 2001 08:26:18 -0500 (EST) Received: from rsys002a.roke.co.uk - 193.118.192.251 by rsys000a.roke.co.uk with Microsoft SMTPSVC(5.5.1774.114.11); Fri, 23 Feb 2001 13:28:22 +0000 Received: from [193.118.192.80] (ppp.roke.co.uk [193.118.192.80]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 16Y4JN84; Fri, 23 Feb 2001 13:26:12 -0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: To: sip@lists.bell-labs.com From: Lawrence Conroy Subject: Re: [SIP] geographical location Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 13:26:42 +0000 Javier said: >There are at least two features involved, one is a specific header for >location information. It would be similar to GSM, which includes in every >call establishment information related to the cell the call is "sent" from. >It is a sort of location information, and currently most of the >call-related location services are based on this cell-info. I presume >probably 3GPP would require a SIP specific header for this purpose , also. > >The second feature is how to handle the delivery of "location change" in a >not-call related basis. This problem (and also the presence information >delivery) will be faced by CAMEL Phase 3 (see 3GPP TS 23.078) by defining a >subscriber category (M-CSI) which is stored in the user profile in HLR and >also in the visited MSC-VLR. This category includes different triggers, >such as >* Location update in the same VLR service area >* Location update in another VLR service area >* IMSI attach, i.e. 1st REGISTER from the UA) >* MS initiated IMSI attach (explicit detach), i.e. un-REGISTER >* Network initiated IMSI detach (implicit detach), i.e. the UA does not >send another REGISTER in the specified time >So it is the MSC-VLR (visited SIP server, I think) the one that generates >such information from the one generated by the UA itself. >Seems that your extension in the NOTIFY behaviour is a sort of Location >update in the cellular environment. The difference is that in the cellular >environment this Location Update procedure is standardised, but i am not >sure your NOTIFY extension would be covered by all UAs. See also that CAMEL >Phase 1 is the one currently deployed in GSM networks, so it will take some >time to see CAMEL Phase 3 running > >hope this helps > To which I reply: CAMEL is not alone; there is other work being developed in 3GPP that isn't directly part of that particular "horse designed by a committee". The LCS work is being done to design a system that provides location info without being tied to the I.N./CAMEL system; the "location entities" (GMLC, SMLC,...) are separate units. These may well need to be considered. Also, as Keith commented, a "SIPish" architecture is being developed in 3GPP; the MSC-VLR is not necessarily the same beast as a V-CSCF (i.e. the first SIP proxy); it may well be the SMLC that generates the data. How this fits with a SIP architecture is not yet clear. I'm not sure that one can ASSUME that the UA knows where it is *in a form that is of any use to anyone (i.e. not a Cell Global Id)* As I understand it, for most of the LCS work, the current assumption seems to be that the Network is most likely to calculate the position of the Mobile User (i.e. the mobile user doesn't know where they are or doesn't care to tell anyone the truth - a problem with E911). I'm not sure how this fits into a SIP "end-to-end" architecture. We seem to need not only a new header (with data in a form that's usable), but also we need to decide who can put this data into the header. If it's done by a proxy somewhere in the middle of the trail between end users, this is ugly, IMHO. -- All the best, Lawrence ------------------------------------------------- | lwc@roke.co.uk |HomeGeo:50o55'15"N,1o24W| |Personal Opinions only| ?Cell Colour Code = 3? | _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 10:15:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04605 for ; Fri, 23 Feb 2001 10:15:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2C83144338; Fri, 23 Feb 2001 10:15:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 9CF7F44337 for ; Fri, 23 Feb 2001 10:14:33 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f1NFEV124552; Fri, 23 Feb 2001 10:14:32 -0500 (EST) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA01567; Fri, 23 Feb 2001 10:13:24 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Feb 2001 10:14:30 -0500 Message-ID: From: "Roy, Radhika R, ALCOO" To: "Drage, Keith (Keith)" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] 3GPP current needs from SIP drafts MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 10:14:28 -0500 Please see the following URL where you will also see couple of SIP I-Ds that deal with mobility in SIP: http://www.cs.columbia.edu/~hgs/sip/drafts.html -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Friday, February 23, 2001 5:25 AM To: 'sip@lists.bell-labs.com' Subject: [SIP] 3GPP current needs from SIP drafts Hannu has circulated a summary of the last 3GPP discussion on the use of SIP. As there was a discussion in the IETF SIP WG ad-hoc on what drafts 3GPP was currently looking at from the IETF, I undertook to provide the current list. Before I give the list, I must stress that it is preliminary. The basis for the list is the flows that currently exist in 24.228, and the elements of signalling that they use. Therefore the list is probably incomplete because 24.228 is incomplete, and may be wrong, because 24.228 is still at a stage where comments can significantly change its contents. We are intending contributing significant parts of 24.228 to the SIP WG for you to analyse, discuss, pull apart, comment on or whatever. The list is currently as follows: draft-ietf-sip-rfc2543bis SIP: Session Initiation Protocol draft-sip-manyfolks-resource Integration of resource management and SIP draft-ietf-sip-100rel Reliability of Provisional Responses in SIP draft-ietf-sip-privacy SIP extensions for caller identity and privacy draft-ietf-sip-call-auth SIP extensions for media authorization The N1-010273 that was referred to in previous discussion on this list, is the 3GPP work item description. This document evolves from meeting to meeting (changing tdoc numbers as it goes!!!!), and will be used to maintain the list of areas where we are dependent on IETF work. 3GPP intends to keep you directly informed as that list changes. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 10:41:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05625 for ; Fri, 23 Feb 2001 10:41:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 85C6844350; Fri, 23 Feb 2001 10:41:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id 778A244343 for ; Fri, 23 Feb 2001 10:40:04 -0500 (EST) Received: from gab200r1.ems.att.com ([135.37.94.32]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f1NFe1603164; Fri, 23 Feb 2001 10:40:01 -0500 (EST) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA04533; Fri, 23 Feb 2001 10:39:10 -0500 (EST) Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Fri, 23 Feb 2001 10:40:00 -0500 Message-ID: From: "Roy, Radhika R, ALCOO" To: ferreiro_j@tsm.es, Janak Mehta Cc: Henning Schulzrinne , sip@lists.bell-labs.com Subject: RE: [SIP] geographical location/SIP Mobility MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 10:39:45 -0500 Hi, Everyone: Let me propose the following to deal with 3GPP in SIP WG: 1. Let the 3GPP folks propose their requirements what need to be done in SIP based on the detail specs that they are developing (or they might have already developed). 2. People in the SIP WG can then see whether any extensions are needed in SIP to meet those requirements. (Most of the time, I have seen that no extension is needed - it is just a matter of implementation.) 3. Let us examine how 3GPP's requirements differ with respect to some of the I-Ds that are already there to deal with SIP mobility. In this way, we, in SIP WG, can have more focused discussion to meet 3GPP requirements. I am still struggling to understand what are the actual requirements that SIP does not currently have in the context of the 3GPP's SIP-specific implementation architecture. It will also help us to address all mobility related problems together seeing the big picture: Cellular wireless-, LAN wireless-, and/or wireline-mobility. Best regards, Radhika R. Roy -----Original Message----- From: ferreiro_j@tsm.es [mailto:ferreiro_j@tsm.es] Sent: Friday, February 23, 2001 5:29 AM To: Janak Mehta Cc: Henning Schulzrinne; sip@lists.bell-labs.com Subject: Re: [SIP] geographical location Well, it is a long time since i do not follow SIP drafts, so maybe i am talking about something already defined. Sorry if so. There are at least two features involved, one is a specific header for location information. It would be similar to GSM, which includes in every call establishment information related to the cell the call is "sent" from. It is a sort of location information, and currently most of the call-related location services are based on this cell-info. I presume probably 3GPP would require a SIP specific header for this purpose , also. The second feature is how to handle the delivery of "location change" in a not-call related basis. This problem (and also the presence information delivery) will be faced by CAMEL Phase 3 (see 3GPP TS 23.078) by defining a subscriber category (M-CSI) which is stored in the user profile in HLR and also in the visited MSC-VLR. This category includes different triggers, such as * Location update in the same VLR service area * Location update in another VLR service area * IMSI attach, i.e. 1st REGISTER from the UA) * MS initiated IMSI attach (explicit detach), i.e. un-REGISTER * Network initiated IMSI detach (implicit detach), i.e. the UA does not send another REGISTER in the specified time So it is the MSC-VLR (visited SIP server, I think) the one that generates such information from the one generated by the UA itself. Seems that your extension in the NOTIFY behaviour is a sort of Location update in the cellular environment. The difference is that in the cellular environment this Location Update procedure is standardised, but i am not sure your NOTIFY extension would be covered by all UAs. See also that CAMEL Phase 1 is the one currently deployed in GSM networks, so it will take some time to see CAMEL Phase 3 running hope this helps -----------------------------< O >----------------------------------- Javier Ferreiro Garcia Telefonica Moviles Spain Consultant Dpto. de Desarrollo de Mercado Voice Services Unit Telf.: +34 630 00 43 13 -----------------------------< O >----------------------------------- >I will be sending out a brief note on this topic early next week. >However, you're probably looking at extensions of the presence format, >rather than a SIP extension. >Janak Mehta wrote: >> >> Hi, >> >> I'm extending SIP to provide geographical location of the mobile >> host within Wireless LAN. Basically I'm trying to send geographical >> location with presence information like "Online/Offline/Away" through >> NOTIFY method to subscriber of that particular presentity. >> >> I want to update(NOTIFY) all the subscibers of the particular presentity >> when that presentity moves within campus. >> >> Is there any defined header in sip through which I can send geo- >> graphical location in NOTIFY method? >> >> Can someone send me some pointers if work is already been done? >> >> Thanks, >> Janak >> >> -------------------------------------------- >> Janak S. Mehta >> Information Networking Institute >> Carnegie Mellon University >> Hamburg Hall, Room No A020, >> 4800 Forbes Avenue, >> Pittsburgh, PA 15213. >> _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 11:08:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06701 for ; Fri, 23 Feb 2001 11:08:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 10D9F44338; Fri, 23 Feb 2001 11:08:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from iex.iex.com (iex.iex.com [192.153.124.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2962E44337 for ; Fri, 23 Feb 2001 11:07:08 -0500 (EST) Received: from home.iex.com ([192.153.191.100]) by iex.iex.com (8.9.1/8.9.3) with ESMTP id KAA29084 for ; Fri, 23 Feb 2001 10:06:57 -0600 (CST) Received: from mail.iex.com ([172.25.41.2]) by home.iex.com (8.9.3/8.9.3) with ESMTP id KAA16236 for ; Fri, 23 Feb 2001 10:06:26 -0600 (CST) Message-ID: <3A968BB2.4D5A9625@mail.iex.com> From: Doug Hurtig Reply-To: hurtig@iex.com Organization: IEX Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] ACK without Route header Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 10:11:30 -0600 Content-Transfer-Encoding: 7bit Hi, If after sending an Invite a Record-Route header is received in a provisional response and then a final response is received without a Record-Route header what are the ramifications of sending the ACK without a route header? If the ACK is sent with same data as the Invite will the ACK not travel the same path as teh invite? What happens in the following scenario? A final response is received out of the blue (no active transaction). It was possible that the record-route was received in a previous response. However it this example the transaction timed-out and was deleted before the final response was received. After getting the final response an ACK is built based on the data in the final response and sent. If the final response did not contain a record-route the ACK would not have a Route header. -- Regards, Doug Hurtig Tekelec 2425 N. Central Expressway Richardson, Texas 75080 hurtig@iex.com 972.301.1203 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 12:11:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09309 for ; Fri, 23 Feb 2001 12:11:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 27C1944338; Fri, 23 Feb 2001 12:11:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id CB9BC44337 for ; Fri, 23 Feb 2001 12:10:57 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id LAA02718; Fri, 23 Feb 2001 11:10:49 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Feb 2001 11:06:31 -0600 Message-ID: From: "Culpepper, Bert" To: Flemming Andreasen Cc: Christer Holmberg , Jean-Francois Mule , sip@lists.bell-labs.com, jieying.li@claren.com Subject: RE: [SIP] T.38 and multiple streams MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 11:06:28 -0600 Hello Flemming, The I-D's text talks about putting the audio on hold while the fax transmission is active. Putting a media stream on hold in SIP is done by specifying the connection address to be 0.0.0.0 (IP4). So, to support the scenario described two IP addresses must be present in the SDP. The current I-D replaces the audio with the t.38 fax as Christer pointed out, this is contrary to the text. I personally think it's fine to replace the audio with the t.38 fax if that's what the two SIP endpoints want. Christer already pointed out a potential implementation problem if an endpoint wants to resume audio after the fax completes, and it released resources since the audio session was replaced. It all depends on the service being provided and the desired goals. Regards, Bert > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Thursday, February 22, 2001 9:32 PM > To: Culpepper, Bert > Cc: Christer Holmberg; Jean-Francois Mule; sip@lists.bell-labs.com; > stanley.khouw@clarent.com; jieying.li@claren.com > Subject: Re: [SIP] T.38 and multiple streams > > > Joining in a bit late here, but in any case: > > Fundamentally, I don't understand why you view this as two > separate media > streams. You are muting one when you want to use the other, > so why have two > in > the first place ? Also note, that there may be some undesirable QoS > interactions > that way. > > A couple of more specific comments on the current draft, some > of which you > may > have already gotten: > - T.30 CED is the same as as V.25 ANS and hence cannot be > used as a fax > detection mechanism (the V.21 fax preamble is fine). > - Why must CNG tone detection not lead to a switch to T.38 ? > - SIP call flow should probably include a Contact header > resulting in some > of > your messages (e.g. ACK) going end-to-end rather than through > the proxy). > - Section 4.1 mentions that different UDP ports are to be > used where as > Section > 6.2 lists that as open issue. I agree with Section 6.2 and > would leave that > choice to the gateways. > > > > Regards > > Flemming > > "Culpepper, Bert" wrote: > > > snip > > > > > >>I prefer the second option (no general c= line, one c= line > > > per media > > > >>description). Shall we recommend this second option in the > > > >>updated paper? > > > > > > > >I prefer the second option too. c= lines in the media > descriptions > > > >are required when a session has more than one media stream and > > > >they need to be controlled independently. > > > > > > I guess this also depends on what the SDP standard says. > For example, > > > when we > > > establish the call for voice, we probably will have a > general c= line. > > > Is it then allowed, in the re-INVITE, to remove that and > then suddenly > > > insert the c= for the media description? > > > > > > > >From my reading of RFC 2327 (SDP standard) I don't see a problem > > with this. But it doesn't concern itself with a SIP > reINVITE. I don't > > remember seeing this detail discussed in the SIP RFC or bis either. > > I also don't believe it necessarily needs to be discussed > in the bis. > > However, I can understand an implementation having a > problem with this. > > But it's an implementation thing. A robust implementation (one that > > realizes not all media streams may go to the same > destination) should > > handle this IMO. > > > > snip > > > > regards, > > Bert > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementor's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to > > sip-implementors-request@cs.columbia.edu with "subscribe" > in the body. > > -- > Flemming Andreasen > Cisco Systems > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 12:42:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10885 for ; Fri, 23 Feb 2001 12:42:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B192144338; Fri, 23 Feb 2001 12:42:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id BBC8F44337 for ; Fri, 23 Feb 2001 12:41:50 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA08020; Fri, 23 Feb 2001 09:41:39 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f1NHfJp28286; Fri, 23 Feb 2001 09:41:19 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id JAA04496; Fri, 23 Feb 2001 09:41:12 -0800 (PST) Message-ID: <3A96A178.76C19D0F@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Culpepper, Bert" Cc: Christer Holmberg , Jean-Francois Mule , sip@lists.bell-labs.com, jieying.li@claren.com Subject: Re: [SIP] T.38 and multiple streams References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 12:44:24 -0500 Content-Transfer-Encoding: 7bit "Culpepper, Bert" wrote: > Hello Flemming, > > The I-D's text talks about putting the audio on hold while the fax > transmission is active. Putting a media stream on hold in SIP is done by > specifying the connection address to be 0.0.0.0 (IP4). So, to support the > scenario described two IP addresses must be present in the SDP. The current > I-D replaces the audio with the t.38 fax as Christer pointed out, this is > contrary to the text. > > I personally think it's fine to replace the audio with the t.38 fax if > that's what the two SIP endpoints want. Me too - I even think it's preferable. > Christer already pointed out a > potential implementation problem if an endpoint wants to resume audio after > the fax completes, and it released resources since the audio session was > replaced. Sorry - I missed that. Can you explain the issue again ? Thanks Flemming > It all depends on the service being provided and the desired > goals. > > Regards, > Bert > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > Sent: Thursday, February 22, 2001 9:32 PM > > To: Culpepper, Bert > > Cc: Christer Holmberg; Jean-Francois Mule; sip@lists.bell-labs.com; > > stanley.khouw@clarent.com; jieying.li@claren.com > > Subject: Re: [SIP] T.38 and multiple streams > > > > > > Joining in a bit late here, but in any case: > > > > Fundamentally, I don't understand why you view this as two > > separate media > > streams. You are muting one when you want to use the other, > > so why have two > > in > > the first place ? Also note, that there may be some undesirable QoS > > interactions > > that way. > > > > A couple of more specific comments on the current draft, some > > of which you > > may > > have already gotten: > > - T.30 CED is the same as as V.25 ANS and hence cannot be > > used as a fax > > detection mechanism (the V.21 fax preamble is fine). > > - Why must CNG tone detection not lead to a switch to T.38 ? > > - SIP call flow should probably include a Contact header > > resulting in some > > of > > your messages (e.g. ACK) going end-to-end rather than through > > the proxy). > > - Section 4.1 mentions that different UDP ports are to be > > used where as > > Section > > 6.2 lists that as open issue. I agree with Section 6.2 and > > would leave that > > choice to the gateways. > > > > > > > > Regards > > > > Flemming > > > > "Culpepper, Bert" wrote: > > > > > snip > > > > > > > >>I prefer the second option (no general c= line, one c= line > > > > per media > > > > >>description). Shall we recommend this second option in the > > > > >>updated paper? > > > > > > > > > >I prefer the second option too. c= lines in the media > > descriptions > > > > >are required when a session has more than one media stream and > > > > >they need to be controlled independently. > > > > > > > > I guess this also depends on what the SDP standard says. > > For example, > > > > when we > > > > establish the call for voice, we probably will have a > > general c= line. > > > > Is it then allowed, in the re-INVITE, to remove that and > > then suddenly > > > > insert the c= for the media description? > > > > > > > > > > >From my reading of RFC 2327 (SDP standard) I don't see a problem > > > with this. But it doesn't concern itself with a SIP > > reINVITE. I don't > > > remember seeing this detail discussed in the SIP RFC or bis either. > > > I also don't believe it necessarily needs to be discussed > > in the bis. > > > However, I can understand an implementation having a > > problem with this. > > > But it's an implementation thing. A robust implementation (one that > > > realizes not all media streams may go to the same > > destination) should > > > handle this IMO. > > > > > > snip > > > > > > regards, > > > Bert > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementor's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to > > > sip-implementors-request@cs.columbia.edu with "subscribe" > > in the body. > > > > -- > > Flemming Andreasen > > Cisco Systems > > > > -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 13:06:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12219 for ; Fri, 23 Feb 2001 13:06:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D22D044357; Fri, 23 Feb 2001 13:06:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.northstream.se (unknown [62.20.120.194]) by lists.bell-labs.com (Postfix) with SMTP id 1817144354 for ; Fri, 23 Feb 2001 13:05:50 -0500 (EST) Received: from exchange.northstream.se by mail.northstream.se via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 23 Feb 2001 18:05:49 UT Received: by ns-exchange-se.northstream.se with Internet Mail Service (5.5.2650.21) id <1MCGCT31>; Fri, 23 Feb 2001 19:05:42 +0100 Message-ID: <93E299DA8B7DD411904300D0B7D483433EFA1D@ns-exchange-se.northstream.se> From: Jerome Privat To: "'Lawrence Conroy'" , sip@lists.bell-labs.com Subject: RE: [SIP] geographical location MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 19:05:41 +0100 I think that Lawrence is on target when mentioning LCS. I think we need to distinguish two different functions in LCS: - how the location information is conveyed to the LCS server (what you discussed in your email) - how a LCS client subscribes to this LCS server and how it receives answers. IMHO, this second function could be nicely implemented using the SUBSCRIBE/NOTIFY methods. This way, location infomation could be combined with presence information and allow some new interesting services... Jerome -----Original Message----- From: Lawrence Conroy [mailto:lwc@roke.co.uk] Sent: Friday, February 23, 2001 2:27 PM To: sip@lists.bell-labs.com Subject: Re: [SIP] geographical location Javier said: >There are at least two features involved, one is a specific header for >location information. It would be similar to GSM, which includes in every >call establishment information related to the cell the call is "sent" from. >It is a sort of location information, and currently most of the >call-related location services are based on this cell-info. I presume >probably 3GPP would require a SIP specific header for this purpose , also. > >The second feature is how to handle the delivery of "location change" in a >not-call related basis. This problem (and also the presence information >delivery) will be faced by CAMEL Phase 3 (see 3GPP TS 23.078) by defining a >subscriber category (M-CSI) which is stored in the user profile in HLR and >also in the visited MSC-VLR. This category includes different triggers, >such as >* Location update in the same VLR service area >* Location update in another VLR service area >* IMSI attach, i.e. 1st REGISTER from the UA) >* MS initiated IMSI attach (explicit detach), i.e. un-REGISTER >* Network initiated IMSI detach (implicit detach), i.e. the UA does not >send another REGISTER in the specified time >So it is the MSC-VLR (visited SIP server, I think) the one that generates >such information from the one generated by the UA itself. >Seems that your extension in the NOTIFY behaviour is a sort of Location >update in the cellular environment. The difference is that in the cellular >environment this Location Update procedure is standardised, but i am not >sure your NOTIFY extension would be covered by all UAs. See also that CAMEL >Phase 1 is the one currently deployed in GSM networks, so it will take some >time to see CAMEL Phase 3 running > >hope this helps > To which I reply: CAMEL is not alone; there is other work being developed in 3GPP that isn't directly part of that particular "horse designed by a committee". The LCS work is being done to design a system that provides location info without being tied to the I.N./CAMEL system; the "location entities" (GMLC, SMLC,...) are separate units. These may well need to be considered. Also, as Keith commented, a "SIPish" architecture is being developed in 3GPP; the MSC-VLR is not necessarily the same beast as a V-CSCF (i.e. the first SIP proxy); it may well be the SMLC that generates the data. How this fits with a SIP architecture is not yet clear. I'm not sure that one can ASSUME that the UA knows where it is *in a form that is of any use to anyone (i.e. not a Cell Global Id)* As I understand it, for most of the LCS work, the current assumption seems to be that the Network is most likely to calculate the position of the Mobile User (i.e. the mobile user doesn't know where they are or doesn't care to tell anyone the truth - a problem with E911). I'm not sure how this fits into a SIP "end-to-end" architecture. We seem to need not only a new header (with data in a form that's usable), but also we need to decide who can put this data into the header. If it's done by a proxy somewhere in the middle of the trail between end users, this is ugly, IMHO. -- All the best, Lawrence ------------------------------------------------- | lwc@roke.co.uk |HomeGeo:50o55'15"N,1o24W| |Personal Opinions only| ?Cell Colour Code = 3? | _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 13:59:52 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15303 for ; Fri, 23 Feb 2001 13:59:51 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BFFAA44338; Fri, 23 Feb 2001 13:58:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 430F444337 for ; Fri, 23 Feb 2001 13:52:21 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14945; Fri, 23 Feb 2001 13:52:19 -0500 (EST) Message-Id: <200102231852.NAA14945@ietf.org> To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: The IESG Reply-To: iesg@ietf.org Subject: [SIP] Last Call: MIME media types for ISUP and QSIG Objects to Proposed Standard Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 13:52:18 -0500 The IESG has received a request from the Session Initiation Protocol Working Group to consider MIME media types for ISUP and QSIG Objects as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 9, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-07.txt _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 14:11:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15966 for ; Fri, 23 Feb 2001 14:11:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 59DDF4434F; Fri, 23 Feb 2001 14:11:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id A4B3F44338 for ; Fri, 23 Feb 2001 14:10:05 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id NAA04052; Fri, 23 Feb 2001 13:08:41 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Fri, 23 Feb 2001 13:04:51 -0600 Message-ID: From: "Culpepper, Bert" To: Flemming Andreasen Cc: Christer Holmberg , Jean-Francois Mule , sip@lists.bell-labs.com, jieying.li@claren.com Subject: RE: [SIP] T.38 and multiple streams MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 13:04:47 -0600 OK, this is what Christer wrote earlier in this thread, the message is http://lists.bell-labs.com/pipermail/sip/2001q1/005726.html "It was my understanding from the T.38 on IP recommendation that this is the way it should work. We should add the fax stream, and mute the voice stream instead of removing it, ie using a separate c= lines for each media stream. I don't want to free resources I've used for the voice when transmitting the fax, since I will probably need them if I switch back from fax to voice." Regards, Bert > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Friday, February 23, 2001 12:44 PM > To: Culpepper, Bert > Cc: Christer Holmberg; Jean-Francois Mule; sip@lists.bell-labs.com; > jieying.li@claren.com > Subject: Re: [SIP] T.38 and multiple streams > > > > > "Culpepper, Bert" wrote: > > > Hello Flemming, > > > > The I-D's text talks about putting the audio on hold while the fax > > transmission is active. Putting a media stream on hold in > SIP is done by > > specifying the connection address to be 0.0.0.0 (IP4). So, > to support the > > scenario described two IP addresses must be present in the > SDP. The current > > I-D replaces the audio with the t.38 fax as Christer > pointed out, this is > > contrary to the text. > > > > I personally think it's fine to replace the audio with the > t.38 fax if > > that's what the two SIP endpoints want. > > Me too - I even think it's preferable. > > > Christer already pointed out a > > potential implementation problem if an endpoint wants to > resume audio after > > the fax completes, and it released resources since the > audio session was > > replaced. > > Sorry - I missed that. Can you explain the issue again ? > > Thanks > > Flemming > > > It all depends on the service being provided and the desired > > goals. > > > > Regards, > > Bert > > > > > -----Original Message----- > > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > > Sent: Thursday, February 22, 2001 9:32 PM > > > To: Culpepper, Bert > > > Cc: Christer Holmberg; Jean-Francois Mule; > sip@lists.bell-labs.com; > > > stanley.khouw@clarent.com; jieying.li@claren.com > > > Subject: Re: [SIP] T.38 and multiple streams > > > > > > > > > Joining in a bit late here, but in any case: > > > > > > Fundamentally, I don't understand why you view this as two > > > separate media > > > streams. You are muting one when you want to use the other, > > > so why have two > > > in > > > the first place ? Also note, that there may be some > undesirable QoS > > > interactions > > > that way. > > > > > > A couple of more specific comments on the current draft, some > > > of which you > > > may > > > have already gotten: > > > - T.30 CED is the same as as V.25 ANS and hence cannot be > > > used as a fax > > > detection mechanism (the V.21 fax preamble is fine). > > > - Why must CNG tone detection not lead to a switch to T.38 ? > > > - SIP call flow should probably include a Contact header > > > resulting in some > > > of > > > your messages (e.g. ACK) going end-to-end rather than through > > > the proxy). > > > - Section 4.1 mentions that different UDP ports are to be > > > used where as > > > Section > > > 6.2 lists that as open issue. I agree with Section 6.2 and > > > would leave that > > > choice to the gateways. > > > > > > > > > > > > Regards > > > > > > Flemming > > > > > > "Culpepper, Bert" wrote: > > > > > > > snip > > > > > > > > > >>I prefer the second option (no general c= line, one c= line > > > > > per media > > > > > >>description). Shall we recommend this second option in the > > > > > >>updated paper? > > > > > > > > > > > >I prefer the second option too. c= lines in the media > > > descriptions > > > > > >are required when a session has more than one media > stream and > > > > > >they need to be controlled independently. > > > > > > > > > > I guess this also depends on what the SDP standard says. > > > For example, > > > > > when we > > > > > establish the call for voice, we probably will have a > > > general c= line. > > > > > Is it then allowed, in the re-INVITE, to remove that and > > > then suddenly > > > > > insert the c= for the media description? > > > > > > > > > > > > > >From my reading of RFC 2327 (SDP standard) I don't see > a problem > > > > with this. But it doesn't concern itself with a SIP > > > reINVITE. I don't > > > > remember seeing this detail discussed in the SIP RFC or > bis either. > > > > I also don't believe it necessarily needs to be discussed > > > in the bis. > > > > However, I can understand an implementation having a > > > problem with this. > > > > But it's an implementation thing. A robust > implementation (one that > > > > realizes not all media streams may go to the same > > > destination) should > > > > handle this IMO. > > > > > > > > snip > > > > > > > > regards, > > > > Bert > > > > > > > > _______________________________________________ > > > > This list is for continuing development of the SIP protocol. > > > > The sip-implementor's list is the place to discuss > implementation, > > > > and to receive advice on understanding existing sip. > > > > To subscribe to it, send mail to > > > > sip-implementors-request@cs.columbia.edu with "subscribe" > > > in the body. > > > > > > -- > > > Flemming Andreasen > > > Cisco Systems > > > > > > > > -- > Flemming Andreasen > Cisco Systems > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 14:46:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17889 for ; Fri, 23 Feb 2001 14:46:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4391944338; Fri, 23 Feb 2001 14:46:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by lists.bell-labs.com (Postfix) with ESMTP id 4DA8844337 for ; Fri, 23 Feb 2001 14:45:27 -0500 (EST) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id TAA26805; Fri, 23 Feb 2001 19:44:30 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 23 Feb 2001 19:44:30 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Feb 2001 11:44:28 -0800 Message-ID: <4148FEAAD879D311AC5700A0C969E8902D4A58@orsmsx35.jf.intel.com> From: "Gross, Gerhard" To: "'Culpepper, Bert'" , Flemming Andreasen Cc: Christer Holmberg , Jean-Francois Mule , sip@lists.bell-labs.com, jieying.li@claren.com Subject: RE: [SIP] T.38 and multiple streams MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 11:44:24 -0800 The following may already be obvious but I'll state it anyway. Consider the case where QoS has been reserved for the session, incurring a (usage based?) cost similar to current PSTN long distance. Preserving this reservation while faxing *MAY* not be an issue for some consumers since the majority of faxes may be small - seconds to a few minutes. In other cases, such as in the legal world, faxes may be quite large. One hundred page plus documents faxed between offices is not uncommon in this business. A significant cost savings could be realized by releasing the bandwidth reservation during the fax, then setting it up again when the fax is complete (assuming voice will continue). Some users may choose to hold the reservation during fax transmission to increase transmission speed at a monetary expense. -Gery XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X X X Gerhard W. Gross, Ph.D. X X Intel X X 2111 NE 25th Ave X X Hillsboro, OR 97124-5961, USA X X Internet Infrastructure Arch. Group X X - Internet and Communication Lab X X phone: (503) 264-6389 X X fax: (503) 264-3483 X X email: gerhard.gross@intel.com X X X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > -----Original Message----- > From: Culpepper, Bert [mailto:bert.culpepper@intervoice-brite.com] > Sent: Friday, February 23, 2001 11:05 AM > To: Flemming Andreasen > Cc: Christer Holmberg; Jean-Francois Mule; sip@lists.bell-labs.com; > jieying.li@claren.com > Subject: RE: [SIP] T.38 and multiple streams > > > OK, this is what Christer wrote earlier in this thread, the message is > http://lists.bell-labs.com/pipermail/sip/2001q1/005726.html > > "It was my understanding from the T.38 on IP recommendation > that this is > the way it should work. We should add the fax stream, and > mute the voice > stream instead of removing it, ie using a separate c= lines for each > media stream. I don't want to free resources I've used for the voice > when transmitting the fax, since I will probably need them if I switch > back from fax to voice." > > Regards, > Bert > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > Sent: Friday, February 23, 2001 12:44 PM > > To: Culpepper, Bert > > Cc: Christer Holmberg; Jean-Francois Mule; sip@lists.bell-labs.com; > > jieying.li@claren.com > > Subject: Re: [SIP] T.38 and multiple streams > > > > > > > > > > "Culpepper, Bert" wrote: > > > > > Hello Flemming, > > > > > > The I-D's text talks about putting the audio on hold while the fax > > > transmission is active. Putting a media stream on hold in > > SIP is done by > > > specifying the connection address to be 0.0.0.0 (IP4). So, > > to support the > > > scenario described two IP addresses must be present in the > > SDP. The current > > > I-D replaces the audio with the t.38 fax as Christer > > pointed out, this is > > > contrary to the text. > > > > > > I personally think it's fine to replace the audio with the > > t.38 fax if > > > that's what the two SIP endpoints want. > > > > Me too - I even think it's preferable. > > > > > Christer already pointed out a > > > potential implementation problem if an endpoint wants to > > resume audio after > > > the fax completes, and it released resources since the > > audio session was > > > replaced. > > > > Sorry - I missed that. Can you explain the issue again ? > > > > Thanks > > > > Flemming > > > > > It all depends on the service being provided and the desired > > > goals. > > > > > > Regards, > > > Bert > > > > > > > -----Original Message----- > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > > > Sent: Thursday, February 22, 2001 9:32 PM > > > > To: Culpepper, Bert > > > > Cc: Christer Holmberg; Jean-Francois Mule; > > sip@lists.bell-labs.com; > > > > stanley.khouw@clarent.com; jieying.li@claren.com > > > > Subject: Re: [SIP] T.38 and multiple streams > > > > > > > > > > > > Joining in a bit late here, but in any case: > > > > > > > > Fundamentally, I don't understand why you view this as two > > > > separate media > > > > streams. You are muting one when you want to use the other, > > > > so why have two > > > > in > > > > the first place ? Also note, that there may be some > > undesirable QoS > > > > interactions > > > > that way. > > > > > > > > A couple of more specific comments on the current draft, some > > > > of which you > > > > may > > > > have already gotten: > > > > - T.30 CED is the same as as V.25 ANS and hence cannot be > > > > used as a fax > > > > detection mechanism (the V.21 fax preamble is fine). > > > > - Why must CNG tone detection not lead to a switch to T.38 ? > > > > - SIP call flow should probably include a Contact header > > > > resulting in some > > > > of > > > > your messages (e.g. ACK) going end-to-end rather than through > > > > the proxy). > > > > - Section 4.1 mentions that different UDP ports are to be > > > > used where as > > > > Section > > > > 6.2 lists that as open issue. I agree with Section 6.2 and > > > > would leave that > > > > choice to the gateways. > > > > > > > > > > > > > > > > Regards > > > > > > > > Flemming > > > > > > > > "Culpepper, Bert" wrote: > > > > > > > > > snip > > > > > > > > > > > >>I prefer the second option (no general c= line, > one c= line > > > > > > per media > > > > > > >>description). Shall we recommend this second > option in the > > > > > > >>updated paper? > > > > > > > > > > > > > >I prefer the second option too. c= lines in the media > > > > descriptions > > > > > > >are required when a session has more than one media > > stream and > > > > > > >they need to be controlled independently. > > > > > > > > > > > > I guess this also depends on what the SDP standard says. > > > > For example, > > > > > > when we > > > > > > establish the call for voice, we probably will have a > > > > general c= line. > > > > > > Is it then allowed, in the re-INVITE, to remove that and > > > > then suddenly > > > > > > insert the c= for the media description? > > > > > > > > > > > > > > > > >From my reading of RFC 2327 (SDP standard) I don't see > > a problem > > > > > with this. But it doesn't concern itself with a SIP > > > > reINVITE. I don't > > > > > remember seeing this detail discussed in the SIP RFC or > > bis either. > > > > > I also don't believe it necessarily needs to be discussed > > > > in the bis. > > > > > However, I can understand an implementation having a > > > > problem with this. > > > > > But it's an implementation thing. A robust > > implementation (one that > > > > > realizes not all media streams may go to the same > > > > destination) should > > > > > handle this IMO. > > > > > > > > > > snip > > > > > > > > > > regards, > > > > > Bert > > > > > > > > > > _______________________________________________ > > > > > This list is for continuing development of the SIP protocol. > > > > > The sip-implementor's list is the place to discuss > > implementation, > > > > > and to receive advice on understanding existing sip. > > > > > To subscribe to it, send mail to > > > > > sip-implementors-request@cs.columbia.edu with "subscribe" > > > > in the body. > > > > > > > > -- > > > > Flemming Andreasen > > > > Cisco Systems > > > > > > > > > > > > -- > > Flemming Andreasen > > Cisco Systems > > > > > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementor's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to > > sip-implementors-request@cs.columbia.edu with "subscribe" > in the body. > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 14:50:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18307 for ; Fri, 23 Feb 2001 14:50:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 224B44435D; Fri, 23 Feb 2001 14:50:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141]) by lists.bell-labs.com (Postfix) with ESMTP id 93CBD44338 for ; Fri, 23 Feb 2001 14:49:11 -0500 (EST) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA04359; Fri, 23 Feb 2001 14:49:10 -0500 (EST) Received: from mhammer-nt.cisco.com (hrn3-dhcp-161-44-93-108.cisco.com [161.44.93.108]) by cia.cisco.com (Mirapoint) with ESMTP id ABF23453; Fri, 23 Feb 2001 14:49:09 -0500 (EST) Message-Id: <4.3.2.7.2.20010223144358.00b4a5c0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Lawrence Conroy , sip@lists.bell-labs.com From: hammer michael Subject: Re: [SIP] geographical location In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 14:48:27 -0800 Lawrence, We also need to keep in mind that there are two types of location: logical and physical. (At the end you seem to cross over from one type to the other.) The former is location relative to the topology of the network; that is, I can route signaling and media to you, but you could be anywhere in the world. The second is related to geographical location, ie Latitude, Longitude, Altitude, Degree of Error. There may be little correlation of one to the other, so they may need to be handled independently. Mike Hammer At 01:26 PM 02/23/2001 +0000, Lawrence Conroy wrote: >Javier said: >>There are at least two features involved, one is a specific header for >>location information. It would be similar to GSM, which includes in every >>call establishment information related to the cell the call is "sent" from. >>It is a sort of location information, and currently most of the >>call-related location services are based on this cell-info. I presume >>probably 3GPP would require a SIP specific header for this purpose , also. >> >>The second feature is how to handle the delivery of "location change" in a >>not-call related basis. This problem (and also the presence information >>delivery) will be faced by CAMEL Phase 3 (see 3GPP TS 23.078) by defining a >>subscriber category (M-CSI) which is stored in the user profile in HLR and >>also in the visited MSC-VLR. This category includes different triggers, >>such as >>* Location update in the same VLR service area >>* Location update in another VLR service area >>* IMSI attach, i.e. 1st REGISTER from the UA) >>* MS initiated IMSI attach (explicit detach), i.e. un-REGISTER >>* Network initiated IMSI detach (implicit detach), i.e. the UA does not >>send another REGISTER in the specified time >>So it is the MSC-VLR (visited SIP server, I think) the one that generates >>such information from the one generated by the UA itself. >>Seems that your extension in the NOTIFY behaviour is a sort of Location >>update in the cellular environment. The difference is that in the cellular >>environment this Location Update procedure is standardised, but i am not >>sure your NOTIFY extension would be covered by all UAs. See also that CAMEL >>Phase 1 is the one currently deployed in GSM networks, so it will take some >>time to see CAMEL Phase 3 running >> >>hope this helps >To which I reply: >CAMEL is not alone; there is other work being developed in 3GPP that >isn't directly part of that particular "horse designed by a committee". > >The LCS work is being done to design a system that provides location >info without being tied to the I.N./CAMEL system; the "location entities" >(GMLC, SMLC,...) are separate units. These may well need to be considered. > >Also, as Keith commented, a "SIPish" architecture is being developed >in 3GPP; the MSC-VLR is not necessarily the same beast as a V-CSCF >(i.e. the first SIP proxy); it may well be the SMLC that generates the >data. How this fits with a SIP architecture is not yet clear. > >I'm not sure that one can ASSUME that the UA knows where it is *in >a form that is of any use to anyone (i.e. not a Cell Global Id)* >As I understand it, for most of the LCS work, the current assumption >seems to be that the Network is most likely to calculate the position >of the Mobile User (i.e. the mobile user doesn't know where they are or >doesn't care to tell anyone the truth - a problem with E911). > >I'm not sure how this fits into a SIP "end-to-end" architecture. >We seem to need not only a new header (with data in a form that's usable), >but also we need to decide who can put this data into the header. If it's >done by a proxy somewhere in the middle of the trail between end users, >this is ugly, IMHO. >-- >All the best, Lawrence >------------------------------------------------- >| lwc@roke.co.uk |HomeGeo:50o55'15"N,1o24W| >|Personal Opinions only| ?Cell Colour Code = 3? | > >_______________________________________________ >This list is for continuing development of the SIP protocol. >The sip-implementor's list is the place to discuss implementation, >and to receive advice on understanding existing sip. >To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu >with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 21:45:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00027 for ; Fri, 23 Feb 2001 21:45:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA40A44338; Fri, 23 Feb 2001 21:45:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id EE99644337 for ; Fri, 23 Feb 2001 21:44:38 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <1GB0W17F>; Fri, 23 Feb 2001 18:42:46 -0800 Received: from rwcjfmule01 (rwc-jfmule01.clarent.com [10.1.75.229]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GB0W171; Fri, 23 Feb 2001 18:42:44 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Flemming Andreasen'" , "'Culpepper, Bert'" Cc: "'Christer Holmberg'" , sip@lists.bell-labs.com, jieying.li@claren.com Subject: RE: [SIP] T.38 - to add fax stream or to replace voice stream Message-ID: <001201c09e0b$88aef490$e54b010a@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A95CBB9.F9BC393B@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 18:43:12 -0800 Content-Transfer-Encoding: 7bit Thanks for the comments. Flemming Andreasen wrote: > Fundamentally, I don't understand why you view this as two > separate media > streams. You are muting one when you want to use the other, > so why have two in > the first place ? Also note, that there may be some undesirable QoS > interactions that way. Christer Holmberg pointed earlier that T.38 suggests to add the fax channel to the voice stream and to mute the voice stream. The only reference I found in T.38 Annex D (TD0262rev1), section 2.2.4 states: "Note that during this switch over and the facsimile call, it may be useful to mute the voice channel. The voice channel may be used again once the end of facsimile transmission is detected." => this implies that T.38 annex D recommends both streams in the same session. As I've pointed out earlier - and this is what was shown in the current draft, I also prefer to replace the voice by a fax channel for the same DSP resource consumption reasons. BTW, this "replacement" does not prevent the session to return to voice mode after the fax is over (re-INVITE with audio sdp). To keep everyone happy, I've updated the draft to accomodate both scenarios and message details with proper SDP descriptions. Flemming Andreasen wrote: > A couple of more specific comments on the current draft, some > of which you may have already gotten: > - T.30 CED is the same as as V.25 ANS and hence cannot be > used as a fax detection mechanism (the V.21 fax preamble is fine). got it, thanks. corrected - this was also noted in H.248/megaco Annex F Flemming Andreasen wrote: > - Why must CNG tone detection not lead to a switch to T.38 ? it could but my understanding is that CNG is optional so to limit the number of cases we selected the Preamble sequence. Also, because of the potential glare effect, we decided to mandate for the Preamble detection... Do you have any comments to improve the text there? > - SIP call flow should probably include a Contact header > resulting in some of > your messages (e.g. ACK) going end-to-end rather than through > the proxy). why is that useful in the sip t.38 case? fyi, a record-route header line has been added to enforce the route through proxy. > - Section 4.1 mentions that different UDP ports are to be > used where as Section > 6.2 lists that as open issue. I agree with Section 6.2 and > would leave that choice to the gateways. ok, I'll make a more affirmative statement. We've run across both cases here too and this has not been caused any interop issue so far. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Fri Feb 23 21:48:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00049 for ; Fri, 23 Feb 2001 21:48:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 54D1344350; Fri, 23 Feb 2001 21:48:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id ECB4A4434D for ; Fri, 23 Feb 2001 21:47:08 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <1GB0W17S>; Fri, 23 Feb 2001 18:45:16 -0800 Received: from rwcjfmule01 (rwc-jfmule01.clarent.com [10.1.75.229]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GB0W17P; Fri, 23 Feb 2001 18:45:05 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Culpepper, Bert'" , "'Flemming Andreasen'" Cc: "'Christer Holmberg'" , sip@lists.bell-labs.com, jieying.li@claren.com Subject: RE: [SIP] T.38 and multiple streams Message-ID: <001301c09e0b$dccf83f0$e54b010a@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 23 Feb 2001 18:45:33 -0800 Content-Transfer-Encoding: 7bit Bert Culpepper wrote: > The I-D's text talks about putting the audio on hold while the fax > transmission is active. Putting a media stream on hold in > SIP is done by > specifying the connection address to be 0.0.0.0 (IP4). So, > to support the > scenario described two IP addresses must be present in the > SDP. The current > I-D replaces the audio with the t.38 fax as Christer pointed > out, this is contrary to the text. As you know, this has been corrected in the upcoming I-D: we have 2 different flows and the text is consistent with the message details. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sat Feb 24 08:54:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19598 for ; Sat, 24 Feb 2001 08:54:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 418DC44339; Sat, 24 Feb 2001 08:54:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 9059144337 for ; Sat, 24 Feb 2001 08:53:54 -0500 (EST) 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 f1ODrmC20218; Sat, 24 Feb 2001 14:53:48 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA15904; Sat, 24 Feb 2001 15:53:45 +0200 (EET) Message-ID: <3A97BD07.DFBF5893@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen Cc: "Culpepper, Bert" , Jean-Francois Mule , sip@lists.bell-labs.com, stanley.khouw@clarent.com, jieying.li@claren.com Subject: Re: [SIP] T.38 and multiple streams References: <3A95CBB9.F9BC393B@cisco.com> Content-Type: multipart/mixed; boundary="------------7C58431FB02C524E02A4A32E" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 24 Feb 2001 15:54:15 +0200 This is a multi-part message in MIME format. --------------7C58431FB02C524E02A4A32E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Flemming Andreasen wrote: > >Joining in a bit late here, but in any case: > >Fundamentally, I don't understand why you view this as two separate media >streams. I guess there are reasons for this. One is that it is recommended that you use TCP for fax, and since you use RTP/UDP for voice you will have to use separate streams. I mean, you can modify the codecs you use for a stream etc, but I don't think you can modify a single stream from UDP to TCP... >You are muting one when you want to use the other, so why have two in the first place ? You want to continue the voice session after the fax has been sent, so by keeping the voice stream during the fax transmissoion you don't have to create a new voice stream after the fax, just "un-mute" the existing one. >Also note, that there may be some undesirable QoS interactions that way. > >A couple of more specific comments on the current draft, some of which you >may have already gotten: > - T.30 CED is the same as as V.25 ANS and hence cannot be used as a fax > detection mechanism (the V.21 fax preamble is fine). > - Why must CNG tone detection not lead to a switch to T.38 ? There are different way to detect a fax. The flows would be different for all cases, and for interop issues you would have to implement all of them. That is the reason why one mechanism was chosen. Regards, Christer Holmberg Ericsson Finland > - SIP call flow should probably include a Contact header resulting in some > of > your messages (e.g. ACK) going end-to-end rather than through the proxy). > - Section 4.1 mentions that different UDP ports are to be used where as > Section > 6.2 lists that as open issue. I agree with Section 6.2 and would leave that > choice to the gateways. > > Regards > > Flemming > > "Culpepper, Bert" wrote: > > > snip > > > > > >>I prefer the second option (no general c= line, one c= line > > > per media > > > >>description). Shall we recommend this second option in the > > > >>updated paper? > > > > > > > >I prefer the second option too. c= lines in the media descriptions > > > >are required when a session has more than one media stream and > > > >they need to be controlled independently. > > > > > > I guess this also depends on what the SDP standard says. For example, > > > when we > > > establish the call for voice, we probably will have a general c= line. > > > Is it then allowed, in the re-INVITE, to remove that and then suddenly > > > insert the c= for the media description? > > > > > > > >From my reading of RFC 2327 (SDP standard) I don't see a problem > > with this. But it doesn't concern itself with a SIP reINVITE. I don't > > remember seeing this detail discussed in the SIP RFC or bis either. > > I also don't believe it necessarily needs to be discussed in the bis. > > However, I can understand an implementation having a problem with this. > > But it's an implementation thing. A robust implementation (one that > > realizes not all media streams may go to the same destination) should > > handle this IMO. > > > > snip > > > > regards, > > Bert > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementor's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > -- > Flemming Andreasen > Cisco Systems --------------7C58431FB02C524E02A4A32E 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 --------------7C58431FB02C524E02A4A32E-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sat Feb 24 08:55:52 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19612 for ; Sat, 24 Feb 2001 08:55:51 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 853FD4434A; Sat, 24 Feb 2001 08:55:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 0555E44349 for ; Sat, 24 Feb 2001 08:54:30 -0500 (EST) 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 f1ODsRC20408; Sat, 24 Feb 2001 14:54:27 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA15917; Sat, 24 Feb 2001 15:54:25 +0200 (EET) Message-ID: <3A97BD2F.9D0F2D7E@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen Cc: "Culpepper, Bert" , Jean-Francois Mule , sip@lists.bell-labs.com, jieying.li@claren.com Subject: Re: [SIP] T.38 and multiple streams References: <3A96A178.76C19D0F@cisco.com> Content-Type: multipart/mixed; boundary="------------AD335C766B31D6BFEFBDA6B5" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 24 Feb 2001 15:54:55 +0200 This is a multi-part message in MIME format. --------------AD335C766B31D6BFEFBDA6B5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >"Culpepper, Bert" wrote: > >>Hello Flemming, >> >>The I-D's text talks about putting the audio on hold while the fax >>transmission is active. Putting a media stream on hold in SIP is done by >>specifying the connection address to be 0.0.0.0 (IP4). So, to support the >>scenario described two IP addresses must be present in the SDP. The current >>I-D replaces the audio with the t.38 fax as Christer pointed out, this is >>contrary to the text. >> >>I personally think it's fine to replace the audio with the t.38 fax if >>that's what the two SIP endpoints want. > >Me too - I even think it's preferable. I guess the reason you think so is because adding streams is not really the easiest thing to do in MGCP, right? :) At the end, I guess this is up to the user to decide, and it also depends on which transport protocols you use. For fax TCP is recommended, while you use UDP (RTP) for voice. So, no matter if you want to keep the voice stream or not, you still have to create a new stream for the fax (you can't modify a stream from UDP to TCP...). Also, if you want to continue the voice session after the fax transmission it think the best thing to do is to keep the voice stream. Otherwise you will have to, again, create a new stream after the fax, instead of simply "un-mute" the existing one. >>Christer already pointed out a >>potential implementation problem if an endpoint wants to resume audio after >>the fax completes, and it released resources since the audio session was >>replaced. >Sorry - I missed that. Can you explain the issue again ? Let's assume that the node receiving the fax tone wants to use separate streams, so it sends a re-INVITE including SDP m= lines both for the voice and fax (with the voice muted). Now, the node receiving the re-INVITE may not have resources to establish an extra session. Instead it may, if possible, want to modify to voice stream, OR to delete the voice stream and replace it with a new fax stream. It must indicate this to the other node, either by refusing to establish the fax session, or to return a SDP indicating that there will not be two separate streams. This case is not specific for fax, but whenever you have a session and want to add streams. Regards, Christer Holmberg Ericsson Finland > > Thanks > > Flemming > > > It all depends on the service being provided and the desired > > goals. > > > > Regards, > > Bert > > > > > -----Original Message----- > > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > > Sent: Thursday, February 22, 2001 9:32 PM > > > To: Culpepper, Bert > > > Cc: Christer Holmberg; Jean-Francois Mule; sip@lists.bell-labs.com; > > > stanley.khouw@clarent.com; jieying.li@claren.com > > > Subject: Re: [SIP] T.38 and multiple streams > > > > > > > > > Joining in a bit late here, but in any case: > > > > > > Fundamentally, I don't understand why you view this as two > > > separate media > > > streams. You are muting one when you want to use the other, > > > so why have two > > > in > > > the first place ? Also note, that there may be some undesirable QoS > > > interactions > > > that way. > > > > > > A couple of more specific comments on the current draft, some > > > of which you > > > may > > > have already gotten: > > > - T.30 CED is the same as as V.25 ANS and hence cannot be > > > used as a fax > > > detection mechanism (the V.21 fax preamble is fine). > > > - Why must CNG tone detection not lead to a switch to T.38 ? > > > - SIP call flow should probably include a Contact header > > > resulting in some > > > of > > > your messages (e.g. ACK) going end-to-end rather than through > > > the proxy). > > > - Section 4.1 mentions that different UDP ports are to be > > > used where as > > > Section > > > 6.2 lists that as open issue. I agree with Section 6.2 and > > > would leave that > > > choice to the gateways. > > > > > > > > > > > > Regards > > > > > > Flemming > > > > > > "Culpepper, Bert" wrote: > > > > > > > snip > > > > > > > > > >>I prefer the second option (no general c= line, one c= line > > > > > per media > > > > > >>description). Shall we recommend this second option in the > > > > > >>updated paper? > > > > > > > > > > > >I prefer the second option too. c= lines in the media > > > descriptions > > > > > >are required when a session has more than one media stream and > > > > > >they need to be controlled independently. > > > > > > > > > > I guess this also depends on what the SDP standard says. > > > For example, > > > > > when we > > > > > establish the call for voice, we probably will have a > > > general c= line. > > > > > Is it then allowed, in the re-INVITE, to remove that and > > > then suddenly > > > > > insert the c= for the media description? > > > > > > > > > > > > > >From my reading of RFC 2327 (SDP standard) I don't see a problem > > > > with this. But it doesn't concern itself with a SIP > > > reINVITE. I don't > > > > remember seeing this detail discussed in the SIP RFC or bis either. > > > > I also don't believe it necessarily needs to be discussed > > > in the bis. > > > > However, I can understand an implementation having a > > > problem with this. > > > > But it's an implementation thing. A robust implementation (one that > > > > realizes not all media streams may go to the same > > > destination) should > > > > handle this IMO. > > > > > > > > snip > > > > > > > > regards, > > > > Bert > > > > > > > > _______________________________________________ > > > > This list is for continuing development of the SIP protocol. > > > > The sip-implementor's list is the place to discuss implementation, > > > > and to receive advice on understanding existing sip. > > > > To subscribe to it, send mail to > > > > sip-implementors-request@cs.columbia.edu with "subscribe" > > > in the body. > > > > > > -- > > > Flemming Andreasen > > > Cisco Systems > > > > > > > > -- > Flemming Andreasen > Cisco Systems --------------AD335C766B31D6BFEFBDA6B5 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 --------------AD335C766B31D6BFEFBDA6B5-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sat Feb 24 09:01:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19699 for ; Sat, 24 Feb 2001 09:01:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1FB074435C; Sat, 24 Feb 2001 09:01:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 4E86744358 for ; Sat, 24 Feb 2001 09:00:46 -0500 (EST) 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 f1OE0hd09539; Sat, 24 Feb 2001 15:00:44 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA16093; Sat, 24 Feb 2001 16:00:41 +0200 (EET) Message-ID: <3A97BEA0.E3760932@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule Cc: "'Flemming Andreasen'" , "'Culpepper, Bert'" , sip@lists.bell-labs.com, jieying.li@claren.com Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream References: <001201c09e0b$88aef490$e54b010a@rwcjfmule01> Content-Type: multipart/mixed; boundary="------------D1BEF0F29542AE6E549F4D81" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 24 Feb 2001 16:01:04 +0200 This is a multi-part message in MIME format. --------------D1BEF0F29542AE6E549F4D81 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Jean-Francois Mule wrote: > >Thanks for the comments. > >Flemming Andreasen wrote: >>Fundamentally, I don't understand why you view this as two >>separate media >>streams. You are muting one when you want to use the other, >>so why have two in >>the first place ? Also note, that there may be some undesirable QoS >>interactions that way. > >Christer Holmberg pointed earlier that T.38 suggests to add the fax channel >to the voice stream and to mute the voice stream. Just to clarify: it's not T.38 that suggests this, it is the node (e.g. gateway) that detects the fax that may suggest this :) >The only reference I found in T.38 Annex D (TD0262rev1), section 2.2.4 >states: >"Note that during this switch over and the facsimile call, it may be useful >to mute the voice channel. The voice channel may be used again once the end >of facsimile transmission is detected." >=> this implies that T.38 annex D recommends both streams in the same >session. > >As I've pointed out earlier - and this is what was shown in the current >draft, I also prefer to replace the voice by a fax channel for the same DSP >resource consumption reasons. BTW, this "replacement" does not prevent the >session to return to voice mode after the fax is over (re-INVITE with audio >sdp). There may some issues here, especially if you have a PSTN gateway. If you do this, you basically want to create a new connection on the endpoint. And, since you already have a connection there this won't work. Ok, of course your gateway can be smart enough to handle this, but - again - there probably would be some interop issues... Regards, Christer Holmberg Ericsson Finland > > To keep everyone happy, I've updated the draft to accomodate both scenarios > and message details with proper SDP descriptions. > > Flemming Andreasen wrote: > > A couple of more specific comments on the current draft, some > > of which you may have already gotten: > > - T.30 CED is the same as as V.25 ANS and hence cannot be > > used as a fax detection mechanism (the V.21 fax preamble is fine). > got it, thanks. > corrected - this was also noted in H.248/megaco Annex F > > Flemming Andreasen wrote: > > - Why must CNG tone detection not lead to a switch to T.38 ? > it could but my understanding is that CNG is optional so to limit the number > of cases we selected the Preamble sequence. Also, because of the potential > glare effect, we decided to mandate for the Preamble detection... > Do you have any comments to improve the text there? > > > - SIP call flow should probably include a Contact header > > resulting in some of > > your messages (e.g. ACK) going end-to-end rather than through > > the proxy). > why is that useful in the sip t.38 case? > fyi, a record-route header line has been added to enforce the route through > proxy. > > > - Section 4.1 mentions that different UDP ports are to be > > used where as Section > > 6.2 lists that as open issue. I agree with Section 6.2 and > > would leave that choice to the gateways. > ok, I'll make a more affirmative statement. We've run across both cases > here too and this has not been caused any interop issue so far. --------------D1BEF0F29542AE6E549F4D81 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 --------------D1BEF0F29542AE6E549F4D81-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sat Feb 24 16:10:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22381 for ; Sat, 24 Feb 2001 16:10:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E4B0E4433D; Sat, 24 Feb 2001 16:10:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4]) by lists.bell-labs.com (Postfix) with SMTP id 1065F44337 for ; Sat, 24 Feb 2001 16:09:30 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Sat, 24 Feb 2001 13:08:20 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id <1SFWVCSN>; Sat, 24 Feb 2001 13:08:20 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD38E2C6@mailserver.sylantro.com> From: "Sharath Rajasekar" To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1686FD4E187028-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Subject: [SIP] Bye-Also Draft ? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 24 Feb 2001 13:08:19 -0800 Content-Transfer-Encoding: 7bit Hi, Can anyone tell me how I can get hold of the Bye-Also draft for transfers. I could not find it in the IETF Draft Repository. Thanks Sharath -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] Sent: Saturday, February 24, 2001 6:01 AM To: Jean-Francois Mule Cc: 'Flemming Andreasen'; 'Culpepper, Bert'; sip@lists.bell-labs.com; jieying.li@claren.com Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream Hi, Jean-Francois Mule wrote: > >Thanks for the comments. > >Flemming Andreasen wrote: >>Fundamentally, I don't understand why you view this as two >>separate media >>streams. You are muting one when you want to use the other, >>so why have two in >>the first place ? Also note, that there may be some undesirable QoS >>interactions that way. > >Christer Holmberg pointed earlier that T.38 suggests to add the fax channel >to the voice stream and to mute the voice stream. Just to clarify: it's not T.38 that suggests this, it is the node (e.g. gateway) that detects the fax that may suggest this :) >The only reference I found in T.38 Annex D (TD0262rev1), section 2.2.4 >states: >"Note that during this switch over and the facsimile call, it may be useful >to mute the voice channel. The voice channel may be used again once the end >of facsimile transmission is detected." >=> this implies that T.38 annex D recommends both streams in the same >session. > >As I've pointed out earlier - and this is what was shown in the current >draft, I also prefer to replace the voice by a fax channel for the same DSP >resource consumption reasons. BTW, this "replacement" does not prevent the >session to return to voice mode after the fax is over (re-INVITE with audio >sdp). There may some issues here, especially if you have a PSTN gateway. If you do this, you basically want to create a new connection on the endpoint. And, since you already have a connection there this won't work. Ok, of course your gateway can be smart enough to handle this, but - again - there probably would be some interop issues... Regards, Christer Holmberg Ericsson Finland > > To keep everyone happy, I've updated the draft to accomodate both scenarios > and message details with proper SDP descriptions. > > Flemming Andreasen wrote: > > A couple of more specific comments on the current draft, some > > of which you may have already gotten: > > - T.30 CED is the same as as V.25 ANS and hence cannot be > > used as a fax detection mechanism (the V.21 fax preamble is fine). > got it, thanks. > corrected - this was also noted in H.248/megaco Annex F > > Flemming Andreasen wrote: > > - Why must CNG tone detection not lead to a switch to T.38 ? > it could but my understanding is that CNG is optional so to limit the number > of cases we selected the Preamble sequence. Also, because of the potential > glare effect, we decided to mandate for the Preamble detection... > Do you have any comments to improve the text there? > > > - SIP call flow should probably include a Contact header > > resulting in some of > > your messages (e.g. ACK) going end-to-end rather than through > > the proxy). > why is that useful in the sip t.38 case? > fyi, a record-route header line has been added to enforce the route through > proxy. > > > - Section 4.1 mentions that different UDP ports are to be > > used where as Section > > 6.2 lists that as open issue. I agree with Section 6.2 and > > would leave that choice to the gateways. > ok, I'll make a more affirmative statement. We've run across both cases > here too and this has not been caused any interop issue so far. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Feb 25 10:50:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09898 for ; Sun, 25 Feb 2001 10:50:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D95F044338; Sun, 25 Feb 2001 10:50:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 04FFC44337 for ; Sun, 25 Feb 2001 10:49:44 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA16029; Sun, 25 Feb 2001 07:49:50 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f1PFne514918; Sun, 25 Feb 2001 07:49:40 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id HAA05580; Sun, 25 Feb 2001 07:49:31 -0800 (PST) Message-ID: <3A992A4E.7ACD72A9@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: "Culpepper, Bert" , Jean-Francois Mule , sip@lists.bell-labs.com, stanley.khouw@clarent.com, jieying.li@claren.com Subject: Re: [SIP] T.38 and multiple streams References: <3A95CBB9.F9BC393B@cisco.com> <3A97BD07.DFBF5893@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 25 Feb 2001 10:52:46 -0500 Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > Flemming Andreasen wrote: > > > >Joining in a bit late here, but in any case: > > > >Fundamentally, I don't understand why you view this as two separate media > >streams. > > I guess there are reasons for this. I have yet to hear a good one. > One is that it is recommended that > you use TCP for fax, and since you use RTP/UDP for voice you will have > to use separate streams. I mean, you can modify the codecs you use for a > stream etc, but I don't think you can modify a single stream from UDP to > TCP... Says who ? A media stream is a media stream. > > > >You are muting one when you want to use the other, so why have two in the first place ? > > You want to continue the voice session after the fax has been sent, so > by keeping the voice stream during the fax transmissoion you don't have > to create a new voice stream after the fax, just "un-mute" the existing > one. Well, first of all, how many fax calls actually turn into voice calls once they finish ? Secondly, you already need signaling to "un-mute" the stream, so what's the advantage here ? As mentioned previously, there are in fact several disadvantages, so if we were to do this, it should be based on some real good pros, and I have yet to hear any. > > > >Also note, that there may be some undesirable QoS interactions that way. > > > >A couple of more specific comments on the current draft, some of which you > >may have already gotten: > > - T.30 CED is the same as as V.25 ANS and hence cannot be used as a fax > > detection mechanism (the V.21 fax preamble is fine). > > - Why must CNG tone detection not lead to a switch to T.38 ? > > There are different way to detect a fax. True, however T.30 CED/V.25 ANS is not one of them. > The flows would be different > for all cases, and for interop issues you would have to implement all of > them. That is the reason why one mechanism was chosen. OK. I would suggest clarifying the draft to make that clear then, as it currently reads like it is forbidden to switch to T.38 on CNG. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Feb 25 11:31:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10331 for ; Sun, 25 Feb 2001 11:31:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 59F2444338; Sun, 25 Feb 2001 11:31:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id C191044337 for ; Sun, 25 Feb 2001 11:30:32 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA22573; Sun, 25 Feb 2001 08:30:41 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f1PGUOf12723; Sun, 25 Feb 2001 08:30:24 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id IAA07830; Sun, 25 Feb 2001 08:30:22 -0800 (PST) Message-ID: <3A9933E0.3D2BDF32@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: "Culpepper, Bert" , Jean-Francois Mule , sip@lists.bell-labs.com, jieying.li@claren.com Subject: Re: [SIP] T.38 and multiple streams References: <3A96A178.76C19D0F@cisco.com> <3A97BD2F.9D0F2D7E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 25 Feb 2001 11:33:37 -0500 Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > >"Culpepper, Bert" wrote: > > > >>Hello Flemming, > >> > >>The I-D's text talks about putting the audio on hold while the fax > >>transmission is active. Putting a media stream on hold in SIP is done by > >>specifying the connection address to be 0.0.0.0 (IP4). So, to support the > >>scenario described two IP addresses must be present in the SDP. The current > >>I-D replaces the audio with the t.38 fax as Christer pointed out, this is > >>contrary to the text. > >> > >>I personally think it's fine to replace the audio with the t.38 fax if > >>that's what the two SIP endpoints want. > > > >Me too - I even think it's preferable. > > I guess the reason you think so is because adding streams is not really > the easiest thing to do in MGCP, right? :) Wrong - just create a new connection. The problem I have with this is that it is in fact a single media stream. By treating it as multiple media streams you have undesirable QoS interactions, you complicate the implemenation (especially for a decompased gateway architectures) since you would normally not try and do multimedia for what basically amounts to a mono-media call (albeit admittedly with changing media parameters). If T.38 didn't happen to use a different protocol/profile than RTP/AVP, you would never have dreamed of this (in fact, I could define a T.38 payload type for RTP/AVP and you wouldn't argue this way). Also, if it turns out that you will not use T.38 for this call, but rather just passthrough, e.g. G.711, you are not going to add a new media stream either, right ? That is why I think this is a rather questionable approach. > > > At the end, I guess this is up to the user to decide, and it also > depends on which transport protocols you use. For fax TCP is > recommended, while you use UDP (RTP) for voice. So, no matter if you > want to keep the voice stream or not, you still have to create a new > stream for the fax (you can't modify a stream from UDP to TCP...). Says who ? > > > Also, if you want to continue the voice session after the fax > transmission it think the best thing to do is to keep the voice stream. > Otherwise you will have to, again, create a new stream after the fax, > instead of simply "un-mute" the existing one. > This doesn't add up. You need signaling to "un-mute" your media stream. You need signaling to change the parameters of a media stream. What is the difference here ? > > >>Christer already pointed out a > >>potential implementation problem if an endpoint wants to resume audio after > >>the fax completes, and it released resources since the audio session was > >>replaced. > >Sorry - I missed that. Can you explain the issue again ? > > Let's assume that the node receiving the fax tone wants to use separate > streams, so it sends a re-INVITE including SDP m= lines both for the > voice and fax (with the voice muted). I was looking for the argument as to why this was needed in the first place.... > Now, the node receiving the > re-INVITE may not have resources to establish an extra session. media stream I assume > Instead > it may, if possible, want to modify to voice stream, OR to delete the > voice stream and replace it with a new fax stream. It must indicate this > to the other node, either by refusing to establish the fax session, or > to return a SDP indicating that there will not be two separate streams. So if I understand correctly, you are essentially trying to negotiate what to do, i.e. T.38 or continue as voice, by putting the voice stream on hold, add a T.38 media stream, and you then expect the other end to pick either one, somehow "un-muting the muted stream" if the voice stream is continued. I think this is a serious overloading of current semantics and procedures. If you want to change the media parameters of an existing media stream, you simply send a re-INVITE with the new proposed parameters for that media stream. The receiver then either accepts or rejects that. That's the way SIP and SDP normally works - why doesn't that work here ? > > > This case is not specific for fax, but whenever you have a session and > want to add streams. Yes, but please explain why you want to do that for fax ? -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Feb 25 11:37:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10428 for ; Sun, 25 Feb 2001 11:37:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2F86144357; Sun, 25 Feb 2001 11:37:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 7B51C44354 for ; Sun, 25 Feb 2001 11:36:45 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA23706; Sun, 25 Feb 2001 08:36:58 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f1PGafv04942; Sun, 25 Feb 2001 08:36:41 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id IAA08217; Sun, 25 Feb 2001 08:36:39 -0800 (PST) Message-ID: <3A993559.1AACEC9E@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: Jean-Francois Mule , "'Culpepper, Bert'" , sip@lists.bell-labs.com, jieying.li@claren.com Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream References: <001201c09e0b$88aef490$e54b010a@rwcjfmule01> <3A97BEA0.E3760932@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 25 Feb 2001 11:39:53 -0500 Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > Hi, > > Jean-Francois Mule wrote: > > > >Thanks for the comments. > > > >Flemming Andreasen wrote: > >>Fundamentally, I don't understand why you view this as two > >>separate media > >>streams. You are muting one when you want to use the other, > >>so why have two in > >>the first place ? Also note, that there may be some undesirable QoS > >>interactions that way. > > > >Christer Holmberg pointed earlier that T.38 suggests to add the fax channel > >to the voice stream and to mute the voice stream. > > Just to clarify: it's not T.38 that suggests this, it is the node (e.g. > gateway) that detects > the fax that may suggest this :) > > >The only reference I found in T.38 Annex D (TD0262rev1), section 2.2.4 > >states: > >"Note that during this switch over and the facsimile call, it may be useful > >to mute the voice channel. The voice channel may be used again once the end > >of facsimile transmission is detected." > >=> this implies that T.38 annex D recommends both streams in the same > >session. > > > >As I've pointed out earlier - and this is what was shown in the current > >draft, I also prefer to replace the voice by a fax channel for the same DSP > >resource consumption reasons. BTW, this "replacement" does not prevent the > >session to return to voice mode after the fax is over (re-INVITE with audio > >sdp). > > There may some issues here, especially if you have a PSTN gateway. If > you do this, you basically want to create a new connection on the > endpoint. And, since you already have a connection there this won't > work. Since when could you not create more than one connection on an endpoint ? Even for implementations that can only handle a single connection per endpoint, since when could you not change the media parameters of that connection ? Can we please get some real arguments on the table here - what is the problem ? -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Feb 25 12:07:08 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10664 for ; Sun, 25 Feb 2001 12:07:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 93EA044354; Sun, 25 Feb 2001 12:07:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rsys000a.roke.co.uk (unknown [193.118.201.102]) by lists.bell-labs.com (Postfix) with ESMTP id D96904434D for ; Sun, 25 Feb 2001 12:06:57 -0500 (EST) Received: from rsys002a.roke.co.uk - 193.118.192.251 by rsys000a.roke.co.uk with Microsoft SMTPSVC(5.5.1774.114.11); Sun, 25 Feb 2001 17:08:57 +0000 Received: from [193.118.192.80] (ppp.roke.co.uk [193.118.192.80]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 16Y4J3YF; Sun, 25 Feb 2001 17:06:43 -0000 Mime-Version: 1.0 X-Sender: lwc@193.118.192.24 Message-Id: In-Reply-To: <4.3.2.7.2.20010223144358.00b4a5c0@cia.cisco.com> References: <4.3.2.7.2.20010223144358.00b4a5c0@cia.cisco.com> To: hammer michael , sip@lists.bell-labs.com From: Lawrence Conroy Subject: Re: [SIP] geographical location Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 25 Feb 2001 17:07:19 +0000 At 2:48 pm -0800 23/2/01, hammer michael wrote: >We also need to keep in mind that there are two types of location: >logical and physical. (At the end you seem to cross over from one >type to the other.) The former is location relative to the topology >of the network; that is, I can route signaling and media to you, but >you could be anywhere in the world. The second is related to >geographical location, ie Latitude, Longitude, Altitude, Degree of >Error. There may be little correlation of one to the other, so they >may need to be handled independently. To which I agree: Good point; however, the current assumptions seem to be that routing to (and from) a mobile SUAS is done by the Mobile Network Infrastructure (using "MobileIP-ish" means for the plumbing, and using a V-CSCN as the "local" SIP entity). The drafts on SIP mobility that were presented last year (i.e. mobility at the application layer) are still *very* FFS; the "mainline view" seems to be that the physical routing side of things *should* be hidden within the mobile network plumbing. In terms of the SIP level, the mobile SUAS/user will probably have a "phone number" and use something like enum - yes, that *is* mentioned in 23.228 :). Amusingly, the same discussions that entertained us in Adelaide in the SPATIAL BoF are still with us on end user location; there's physical location and civil location, and either may be required for the recipient of the info. Where one translates from what one has (somewhere along the trail) into something that the recipient end user needs is a big question. For example, with some measurement techniques, you get the "Base station Colour Code", which is as much use a chocolate soldier in a fire to most entities; how and where this is converted is "an interesting question". Finally, whether or not all of this needs any extension to SIP, rather than just a usage profile, is another good question; I for one await some concrete proposals with interest. -- All the best, Lawrence ------------------------------------------------- | lwc@roke.co.uk |HomeGeo:50o55'15"N,1o24W| |Personal Opinions only| ?Cell Colour Code = 3? | _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Feb 25 12:33:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11036 for ; Sun, 25 Feb 2001 12:33:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A3F4244350; Sun, 25 Feb 2001 12:33:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id B6D5744337 for ; Sun, 25 Feb 2001 12:32:09 -0500 (EST) 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 f1PHW5d02361; Sun, 25 Feb 2001 18:32:06 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.2/8.11.2) with ESMTP id f1PHW3H21911; Sun, 25 Feb 2001 19:32:03 +0200 (EET) Message-ID: <3A9941BA.756AE28@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen Cc: Jean-Francois Mule , "'Culpepper, Bert'" , sip@lists.bell-labs.com, jieying.li@claren.com Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream References: <001201c09e0b$88aef490$e54b010a@rwcjfmule01> <3A97BEA0.E3760932@lmf.ericsson.se> <3A993559.1AACEC9E@cisco.com> Content-Type: multipart/mixed; boundary="------------AF8B2834C6F69AEC3F7B703B" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 25 Feb 2001 19:32:42 +0200 This is a multi-part message in MIME format. --------------AF8B2834C6F69AEC3F7B703B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I guess I messed up the answers a little with the MGCP discussion for T.38... >Christer Holmberg wrote: > >>Hi, >> >>Jean-Francois Mule wrote: >>> >>>Thanks for the comments. >>> >>>Flemming Andreasen wrote: >>>>Fundamentally, I don't understand why you view this as two >>>>separate media streams. You are muting one when you want to use the other, >>>>so why have two in the first place ? Also note, that there may be some undesirable QoS >>>>interactions that way. >>> >>>Christer Holmberg pointed earlier that T.38 suggests to add the fax channel >>>to the voice stream and to mute the voice stream. >> >>Just to clarify: it's not T.38 that suggests this, it is the node (e.g. >>gateway) that detects >>the fax that may suggest this :) >> >>>The only reference I found in T.38 Annex D (TD0262rev1), section 2.2.4 >>>states: >>>"Note that during this switch over and the facsimile call, it may be useful >>>to mute the voice channel. The voice channel may be used again once the end >>>of facsimile transmission is detected." >>>=> this implies that T.38 annex D recommends both streams in the same >>>session. >>> >>>As I've pointed out earlier - and this is what was shown in the current >>>draft, I also prefer to replace the voice by a fax channel for the same DSP >>>resource consumption reasons. BTW, this "replacement" does not prevent the >>>session to return to voice mode after the fax is over (re-INVITE with audio >>>sdp). >> >>There may some issues here, especially if you have a PSTN gateway. If >>you do this, you basically want to create a new connection on the >>endpoint. And, since you already have a connection there this won't >>work. > >Since when could you not create more than one connection on an endpoint ? > >Even for implementations that can only handle a single connection per endpoint, >since when could you not change the media parameters of that connection ? > >Can we please get some real arguments on the table here - what is the problem ? The problem is when the detecting node wants to ADD the fax stream (and keep the voice stream) but the other node is not able to add the fax stream. Instead it wants to REPLACE the voice stream with the fax stream. Of course it should not be a problem to do that, but the issue was that the detecting node should be informed about this if it happens - or, should the node be able to send a "stream could not be added" response back to the detecting node, which may then send another re-INVITE where it replaces the voice with fax, instead of adding the fax to the voice. I don't see this as a problem, just as a scenario that may take place, and my proposal was that we describe it in the call flows. Regards, Christer > > -- Flemming > > -- > Flemming Andreasen > Cisco Systems --------------AF8B2834C6F69AEC3F7B703B 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 --------------AF8B2834C6F69AEC3F7B703B-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Feb 25 13:09:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11688 for ; Sun, 25 Feb 2001 13:09:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 086E744344; Sun, 25 Feb 2001 13:09:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.itvista.com (unknown [12.44.179.201]) by lists.bell-labs.com (Postfix) with ESMTP id 578F644337 for ; Sun, 25 Feb 2001 13:08:34 -0500 (EST) Received: from ipunity.com (adsl-63-199-177-242.dsl.snfc21.pacbell.net [63.199.177.242]) by mail.itvista.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id KAA01301; Sun, 25 Feb 2001 10:03:46 -0800 Message-ID: <3A99496F.B99D2256@ipunity.com> From: David Israel Organization: IP Unity X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.16-SMP i686) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: Flemming Andreasen , Jean-Francois Mule , "'Culpepper, Bert'" , sip@lists.bell-labs.com, jieying.li@clarent.com Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream References: <001201c09e0b$88aef490$e54b010a@rwcjfmule01> <3A97BEA0.E3760932@lmf.ericsson.se> <3A993559.1AACEC9E@cisco.com> <3A9941BA.756AE28@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 25 Feb 2001 10:05:35 -0800 Content-Transfer-Encoding: 7bit Christer, Are there call flows available? (I need them in SIP and MGCP.) Thank you, David Christer Holmberg wrote: > > Hi, > > I guess I messed up the answers a little with the MGCP discussion for > T.38... > I don't see this as a problem, just as a scenario that > may take place, and my proposal was that we describe it in the call > flows. > > Regards, > > Christer > > > > > -- Flemming > > > > -- > > Flemming Andreasen > > Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Feb 25 13:18:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11790 for ; Sun, 25 Feb 2001 13:18:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ABA0A44360; Sun, 25 Feb 2001 13:18:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 95EB744353 for ; Sun, 25 Feb 2001 13:17:24 -0500 (EST) 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 f1PIHKd18499; Sun, 25 Feb 2001 19:17:20 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.2/8.11.2) with ESMTP id f1PIHIH23210; Sun, 25 Feb 2001 20:17:18 +0200 (EET) Message-ID: <3A994C56.88260899@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen Cc: "Culpepper, Bert" , Jean-Francois Mule , sip@lists.bell-labs.com, stanley.khouw@clarent.com, jieying.li@claren.com Subject: Re: [SIP] T.38 and multiple streams References: <3A95CBB9.F9BC393B@cisco.com> <3A97BD07.DFBF5893@lmf.ericsson.se> <3A992A4E.7ACD72A9@cisco.com> Content-Type: multipart/mixed; boundary="------------F9C66877806E5484CEFD0DCF" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 25 Feb 2001 20:17:58 +0200 This is a multi-part message in MIME format. --------------F9C66877806E5484CEFD0DCF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Flemming Andreasen wrote: > >Christer Holmberg wrote: > >>Hi, >> >>Flemming Andreasen wrote: >>> >>>Joining in a bit late here, but in any case: >>> >>>Fundamentally, I don't understand why you view this as two separate media >>>streams. >> >>I guess there are reasons for this. > >I have yet to hear a good one. There are no reasons in the recommendation, and I guess that's why we try to think of some. >>One is that it is recommended that >>you use TCP for fax, and since you use RTP/UDP for voice you will have >>to use separate streams. I mean, you can modify the codecs you use for a >>stream etc, but I don't think you can modify a single stream from UDP to >>TCP... > >Says who ? A media stream is a media stream. Well, the ones who made the recommendation maybe assumed that a UDP stream can not be modified into a TCP stream just like that, and that you will have to create a new TCP stream instead. I do agree with you, though, that there is nothing from a protocol point of view that would prevent this. >>>You are muting one when you want to use the other, so why have two in the first place ? >> >>You want to continue the voice session after the fax has been sent, so >>by keeping the voice stream during the fax transmissoion you don't have >>to create a new voice stream after the fax, just "un-mute" the existing >>one. > >Well, first of all, how many fax calls actually turn into voice calls once they finish ? I don't know. However, these questions will come up in future whenever we want to have a multimedia session (audio + fax, audio + video, whatever), when streams may be added and removed during the session. This may not be the case for T.38, and the call flows are not supposed to solve general multimedia issues, but if it is possible to solve also I see no reason to "forbid" a voice session to continue after the fax transmission. >Secondly, you already need signaling to "un-mute" the stream, so what's the advantage here ? The only reason I can think about is what I wrote above about the UDP and TCP streams. However, I would like the ones who made the recommendation to use separate streams to define the reason why. Regards, Christer >As mentioned previously, there are in fact several disadvantages, so if we were to do this, >it should be based on some real good pros, and I have yet to hear any. > >> >> >>>Also note, that there may be some undesirable QoS interactions that way. >>> >>>A couple of more specific comments on the current draft, some of which you >>>may have already gotten: >>> - T.30 CED is the same as as V.25 ANS and hence cannot be used as a fax >>> detection mechanism (the V.21 fax preamble is fine). >>> - Why must CNG tone detection not lead to a switch to T.38 ? >> >> There are different way to detect a fax. > >True, however T.30 CED/V.25 ANS is not one of them. > >>The flows would be different >>for all cases, and for interop issues you would have to implement all of >>them. That is the reason why one mechanism was chosen. > >OK. I would suggest clarifying the draft to make that clear then, as it currently reads like >it is forbidden to switch to T.38 on CNG. > > -- Flemming > > -- > Flemming Andreasen > Cisco Systems --------------F9C66877806E5484CEFD0DCF 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 --------------F9C66877806E5484CEFD0DCF-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Feb 25 13:19:44 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11802 for ; Sun, 25 Feb 2001 13:19:43 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A46E34436E; Sun, 25 Feb 2001 13:19:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id B23104436D for ; Sun, 25 Feb 2001 13:18:58 -0500 (EST) 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 f1PIIsd19023; Sun, 25 Feb 2001 19:18:54 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.2/8.11.2) with ESMTP id f1PIIqH23238; Sun, 25 Feb 2001 20:18:53 +0200 (EET) Message-ID: <3A994CB4.7487D4E2@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: David Israel Cc: Flemming Andreasen , Jean-Francois Mule , "'Culpepper, Bert'" , sip@lists.bell-labs.com, jieying.li@clarent.com Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream References: <001201c09e0b$88aef490$e54b010a@rwcjfmule01> <3A97BEA0.E3760932@lmf.ericsson.se> <3A993559.1AACEC9E@cisco.com> <3A9941BA.756AE28@lmf.ericsson.se> <3A99496F.B99D2256@ipunity.com> Content-Type: multipart/mixed; boundary="------------44FABBE9997A3A01AE1FF937" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 25 Feb 2001 20:19:32 +0200 This is a multi-part message in MIME format. --------------44FABBE9997A3A01AE1FF937 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi David, There are call flows for SIP. They are to be updated, though, and that is what we are currently discussing. Regards, Christer David Israel wrote: > > Christer, > > Are there call flows available? (I need them in SIP and MGCP.) > > Thank you, > David > > Christer Holmberg wrote: > > > > Hi, > > > > I guess I messed up the answers a little with the MGCP discussion for > > T.38... > > I don't see this as a problem, just as a scenario that > > may take place, and my proposal was that we describe it in the call > > flows. > > > > Regards, > > > > Christer > > > > > > > > -- Flemming > > > > > > -- > > > Flemming Andreasen > > > Cisco Systems --------------44FABBE9997A3A01AE1FF937 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 --------------44FABBE9997A3A01AE1FF937-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Feb 25 14:02:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12299 for ; Sun, 25 Feb 2001 14:02:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D0D3644353; Sun, 25 Feb 2001 14:02:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id A307D44337 for ; Sun, 25 Feb 2001 14:01:25 -0500 (EST) 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 f1PJ1MC11278; Sun, 25 Feb 2001 20:01:23 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.106.10]) by fogerty.lmf.ericsson.se (8.11.2/8.11.2) with ESMTP id f1PJ1JH24476; Sun, 25 Feb 2001 21:01:19 +0200 (EET) Message-ID: <3A9956A5.1F5BA7EC@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen Cc: "Culpepper, Bert" , Jean-Francois Mule , sip@lists.bell-labs.com, jieying.li@claren.com Subject: Re: [SIP] T.38 and multiple streams References: <3A96A178.76C19D0F@cisco.com> <3A97BD2F.9D0F2D7E@lmf.ericsson.se> <3A9933E0.3D2BDF32@cisco.com> Content-Type: multipart/mixed; boundary="------------063087F2BF7F218276066C3E" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 25 Feb 2001 21:01:57 +0200 This is a multi-part message in MIME format. --------------063087F2BF7F218276066C3E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >>>>Hello Flemming, >>>> >>>>The I-D's text talks about putting the audio on hold while the fax >>>>transmission is active. Putting a media stream on hold in SIP is done by >>>>specifying the connection address to be 0.0.0.0 (IP4). So, to support the >>>>scenario described two IP addresses must be present in the SDP. The current >>>>I-D replaces the audio with the t.38 fax as Christer pointed out, this is >>>>contrary to the text. >>>> >>>>I personally think it's fine to replace the audio with the t.38 fax if >>>>that's what the two SIP endpoints want. >>> >>>Me too - I even think it's preferable. >> >>I guess the reason you think so is because adding streams is not really >>the easiest thing to do in MGCP, right? :) > >Wrong - just create a new connection. Ok, I guess we agreed on that. There is some issues on how it will be done, however, but let's discuss that elsewhere. >The problem I have with this is that it is in fact a single media stream. By >treating it as multiple media streams you have undesirable QoS interactions, you >complicate the implemenation (especially for a decompased gateway architectures) >since you would normally not try and do multimedia for what basically amounts to a >mono-media call (albeit admittedly with changing media parameters). If T.38 didn't >happen to use a different protocol/profile than RTP/AVP, you would never have >dreamed of this (in fact, I could define a T.38 payload type for RTP/AVP and you >wouldn't argue this way). Also, if it turns out that you will not use T.38 for >this call, but rather just passthrough, e.g. G.711, you are not going to add a new >media stream either, right ? I guess that is an implementation issue, and depends on your gateway. If it uses G.711, and detects fax, it may choose to use the existing voice stream. However, since TCP is recommended for fax, it may choose it wants to add a separate stream for the fax (or, modify the existing stream from UDP to TCP) anyway. That is also a reason why the voice stream must be muted during the fax transmission. Otherwise you would get the fax stuff both on the G.711 voice stream and on the fax stream (and mix it together) and the receiving fax machine would probably not be too happy... >That is why I think this is a rather questionable approach. The reason I wanted both (single- and multi stream) scenarios in the call flows is the allow the use of whatever method wanted. If someone wants to use a single stream he may do so, but if he for whatever reason wants to use multi streams he should be allowed to do so too. Both nodes may not support, or want to, use multi streams, and that is the reason why I also want that scenario described in the call flows. >>Also, if you want to continue the voice session after the fax >>transmission it think the best thing to do is to keep the voice stream. >>Otherwise you will have to, again, create a new stream after the fax, >>instead of simply "un-mute" the existing one. >> > >This doesn't add up. You need signaling to "un-mute" your media stream. You need >signaling to change the parameters of a media stream. What is the difference here >? At the end I guess the difference will be more on an implementation level, since the protocol call flows will look pretty much the same in both cases. Again, the only reason I personally can think of is the issue related to UDP and TCP. >> >>>>Christer already pointed out a >>>>potential implementation problem if an endpoint wants to resume audio after >>>>the fax completes, and it released resources since the audio session was >>>>replaced. >>>Sorry - I missed that. Can you explain the issue again ? >> >>Let's assume that the node receiving the fax tone wants to use separate >>streams, so it sends a re-INVITE including SDP m= lines both for the >>voice and fax (with the voice muted). > >I was looking for the argument as to why this was needed in the first place.... >>Now, the node receiving the >>re-INVITE may not have resources to establish an extra session. > >media stream I assume Correct. >>Instead it may, if possible, want to modify to voice stream, OR to delete the >>voice stream and replace it with a new fax stream. It must indicate this >>to the other node, either by refusing to establish the fax session, or >>to return a SDP indicating that there will not be two separate streams. > >So if I understand correctly, you are essentially trying to negotiate what to do, >i.e. T.38 or continue as voice, by putting the voice stream on hold, add a T.38 >media stream, and you then expect the other end to pick either one, somehow >"un-muting the muted stream" if the voice stream is continued. I think this is a >serious overloading of current semantics and procedures. What I said was what could happen if the detecting node wants to ADD a stream, but the other node isn't capable of doing that but it IS capable to replace/modify the voice stream with the fax stream. >If you want to change the media parameters of an existing media stream, you simply >send a re-INVITE with the new proposed parameters for that media stream. The >receiver then either accepts or rejects that. That's the way SIP and SDP normally >works - why doesn't that work here ? It DOES work here. I mentioned earlier that if the node refuses to add the new stream (which is done using re-INVITE too) it normally shall send some 4xx response. The issue I raised was if the node, instead of doing this, should be allowed to instead replace the voice stream with fax, and indicate that in the re-INVITE response. Personaly I do NOT like the idea too much, though. First, it probably should be allowed only for the specific fax case (which I mentioned earlier) and I think most of us wants solution which are general from a SIP point of view. Second, the detecting node should be informed if the fax stream can not be added (after that, it MAY choose to send a new re-INVITE where the voice is replaced with the fax). >>This case is not specific for fax, but whenever you have a session and >>want to add streams. >Yes, but please explain why you want to do that for fax ? The only reason is that we would be able to quickly establish the fax connection even if the other node is not able to ADD the fax stream, but it is able to REPLACE the voice with fax. I do think, however, that there should be a 4xx response code, or at least a Warning header code, to indicate that we were not able to add the stream. There are Warning header codes to indicate that the codec was not supported etc, but that is not the same. Regards, Christer > > -- Flemming > > -- > Flemming Andreasen > Cisco Systems --------------063087F2BF7F218276066C3E 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 --------------063087F2BF7F218276066C3E-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Feb 25 20:05:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14209 for ; Sun, 25 Feb 2001 20:05:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A59644338; Sun, 25 Feb 2001 20:05:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id 4913E44337 for ; Sun, 25 Feb 2001 20:04:46 -0500 (EST) Received: from fokus.gmd.de (dhcp012 [195.37.78.140]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id CAA22366; Mon, 26 Feb 2001 02:04:42 +0100 (MET) Message-ID: <3A99ABDD.E556F256@fokus.gmd.de> From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lawrence Conroy Cc: hammer michael , sip@lists.bell-labs.com Subject: Re: [SIP] geographical location References: <4.3.2.7.2.20010223144358.00b4a5c0@cia.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 02:05:33 +0100 Content-Transfer-Encoding: 7bit Maybe I missed some substantial point but I do not understand why users and their applications should be willing to deal with some technology-dependent geographical format. I really cannot expect a Web/SIP server to understand coordinations expressed in a format used by my local wireless company. Geographical coordinates (latitude, longitude, elevation and precision) will not change. Technological coordinates (my GSM cell id) or civil names ("Europe Blvd" formerly "Lenin Blvd" formerly "Stalin Blvd" formerly "Hitler Blvd" in the city where I was born.) will. I'd really prefer conveying *geo-coordinates* in web/sip requests, regardless how they were obtained, what their original encoding was and what the application dealing with them is. I do not think that they should be bound to a specific request method (like previously SUB-NOT or REGISTER were mentioned.) Something like INVITE reservations@hotel.com?latitutude=x;logitude=y;elevation=z would be useful as well. Jiri _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Feb 25 22:55:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16902 for ; Sun, 25 Feb 2001 22:55:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 408C044338; Sun, 25 Feb 2001 22:55:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D82BA44337 for ; Sun, 25 Feb 2001 22:54:16 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA02210; Sun, 25 Feb 2001 22:57:14 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 25 Feb 2001 22:56:39 -0500 Message-ID: From: Jonathan Rosenberg To: "'Jerome Privat'" , "'Lawrence Conroy'" , sip@lists.bell-labs.com Subject: RE: [SIP] geographical location MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 25 Feb 2001 22:56:38 -0500 > -----Original Message----- > From: Jerome Privat [mailto:jerome.privat@northstream.se] > Sent: Friday, February 23, 2001 1:06 PM > To: 'Lawrence Conroy'; sip@lists.bell-labs.com > Subject: RE: [SIP] geographical location > > > I think that Lawrence is on target when mentioning LCS. > > I think we need to distinguish two different functions in LCS: > - how the location information is conveyed to the LCS server (what you > discussed in your email) > - how a LCS client subscribes to this LCS server and how it receives > answers. There are three things, in fact. Publication: whereby information about a presentity is sent to the presence server for the presentity. Subscription: whereby users in the network can request changes in information about presence state of a presentity. Notification: whereby subscribers are told by the presence server about changes in presence state. Particularly, note that publication and notification are different. In sip for presence, REGISTER plays the role of a possible publication mechanism. There are many others, and I think future communications systems will involve presence coming from many disparate devices, through many different protocols. As a result, a presence server will speak many languages in order to collect the sum total presence information for a presentity. Note also that it is inherent to the model, and even with SIP REGISTER, that third parties can publish information for a presentity (specifically, the From field of a REGISTER need not match the To field). So, I won't pretend to understand which device in the 3gpp architecture is ideally suited to know the location of the mobile. But, once you figure it out (and it could be more than one), those devices would publish presence information to the presence server, possibly with REGISTER if its convenient, or possibly with something else altogether. Then, this information is included in the NOTIFYs generated by the presence server. This requires fields added to the presence document format for location information. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Sun Feb 25 23:08:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16960 for ; Sun, 25 Feb 2001 23:08:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A16574436D; Sun, 25 Feb 2001 23:08:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 272C544338 for ; Sun, 25 Feb 2001 23:07:51 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02255; Sun, 25 Feb 2001 23:10:49 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 25 Feb 2001 23:10:14 -0500 Message-ID: From: Jonathan Rosenberg To: "'Neil Deason'" , Alan Johnston Cc: Richard Verhoeven , Rick Dean , jundery@ubiquity.net, parolkar@tri.sbc.com, "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] RE: [Sip-implementors] SIP and Call Pickup Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 25 Feb 2001 23:10:13 -0500 [moving over to the sip list, as we are now talking about changes to sip] A few thoughts on directed pickup. 1. The mechanism in rfc2543 is a hack. It is meant to provide call pickup as a side effect of register behavior. What would happen is that the register would cause the original INVITE to fork to the second phone. The second phone then answers, which causes the first call to be CANCELed. As such, Alan's flow is wrong. The proxy would not CANCEL on receipt of REGISTER (why would it do that?). Rather, it would generate the second INVITE, and when its answered, then CANCEL. However, this mechanism has some big problems: a. its hard to do in a distributed system where the registrar and proxy are separated b. it doesn't actually provide directed call pickup, since the user experience is much different. IN this mode, the second phone will actually ring! 2. The other proposals so far, involving REFER or a REGISTER directly to the first phone, will not work. They both defined additional, service specific semantics to these requests. Bad, bad. 3. It is possible to do directed pickup with a B2BUA. I worked through a call flow for it, and it emulates completely the PSTN service. It requires no extensions to SIP, just logic for the service in the picking-up phone and in the B2BUA. Can it be done without a B2BUA in a distributed way? Maybe. But, I'm not going to get hung up on emulating every infrequently used PSTN service in a distributed way. 4. I believe we should actually remove the current text on directed pickup. Thats because: a. we said that we don't standardize services, but here is random text in the middle of a section which does just that. It was definitely an afterthought. b. it doesn't work easily when the registrar and proxy are separated c. it doesn't actually do directed pickup as defined d. I don't think its that widely implemented. Can anyone comment on d? Would anyone object to yanking this text? -Jonathan R. > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Thursday, February 22, 2001 10:23 AM > To: Alan Johnston > Cc: Richard Verhoeven; Rick Dean; jundery@ubiquity.net; > parolkar@tri.sbc.com; sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] SIP and Call Pickup > > > Alan Johnston wrote: > > > > Adding Call Pickup and Park is on my to do list for the SIP > > Service Examples I-D (draft-ietf-sip-service-examples-00.txt), > > but I haven't had any suggestions for how to do this. > > > > What about using the mechanism described in bis, but hiding it > > from the caller behind a proxy? The REGISTER message from C > > would expire immediately and be directed at B via the proxy. > > The proxy could then cross-reference the pending INVITE to B, > > consult policy to see if C is authorized to pickup B's calls, > > then cancel the pending INVITE and direct the call to C. > > > > > > Caller A Proxy B Called C Picks > > Up Call > > | | | | > > | INVITE F1 | | | > > |--------------->| INVITE F2 | | > > |(100 Trying) F3 |------------->| | > > |<---------------|180 Ringing F4| | > > | 180 Ringing F5 |<-------------| | > > |<---------------| | | > > | | | REGISTER F6 | > > | |<---------------------------------| > > | | | 200 OK F7 | > > | |--------------------------------->| > > | | | | > > | | CANCEL F8 | | > > | |------------->| | > > | | 200 OK F9 | | > > | |<-------------| | > > | | 487 F10 | | > > | |<-------------| | > > | | ACK F11 | | > > | |------------->| | > > | | | INVITE F12 | > > | |--------------------------------->| > > | | | 180 Ringing F13 | > > | 180 Ringing F14|<---------------------------------| > > |<---------------| | 200 OK F15 | > > | |<---------------------------------| > > | 200 OK F16 | | | > > |<---------------| | | > > | ACK F17 | | | > > |--------------->| | ACK F18 | > > | |--------------------------------->| > > | Both way RTP Established | > > |<=================================================>| > > > > Comments? > > I think this would work. The Proxy could perhaps just fork > again upon receipt of F6, letting both B and C ring and doing > the CANCEL on which ever leg doesn't answer 200. > > However, I don't really like promoting the use of REGISTER > for this as a good idea. It overloads REGISTER and is using > SIP as a call control protocol. The whole area of a SIP call > control framework seems to need more work so I wouldn't want > this perceived to be _the_ way. Anyway if users have intelligent > and intuitive access to forwarding services through CPL call > pick up is redundant. > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 00:12:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17697 for ; Mon, 26 Feb 2001 00:12:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AFA9C44338; Mon, 26 Feb 2001 00:12:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62]) by lists.bell-labs.com (Postfix) with ESMTP id 22A0944337 for ; Mon, 26 Feb 2001 00:11:01 -0500 (EST) Received: from SCOTT (user-2ivekem.dialup.mindspring.com [165.247.81.214]) by snipe.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id VAA17148; Sun, 25 Feb 2001 21:10:27 -0800 (PST) From: "Scott Hoffpauir" To: "Jonathan Rosenberg" , "'Neil Deason'" , "Alan Johnston" Cc: "Richard Verhoeven" , "Rick Dean" , , , Subject: RE: [SIP] RE: [Sip-implementors] SIP and Call Pickup 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: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 00:11:32 -0500 Content-Transfer-Encoding: 7bit We do call pickup with a B2BUA, which as stated doesn't require anything out of the ordinary. With wide scale deployment of voice mail, this service isn't really that useful. There are many better call completion features today (voice mail, forking, etc.) which will eventually obsolete call pickup. Last time I used it was about 10 years ago. I think it should be yanked. Scott BroadSoft 240-364-5106 -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg Sent: Sunday, February 25, 2001 11:10 PM To: 'Neil Deason'; Alan Johnston Cc: Richard Verhoeven; Rick Dean; jundery@ubiquity.net; parolkar@tri.sbc.com; 'sip@lists.bell-labs.com' Subject: [SIP] RE: [Sip-implementors] SIP and Call Pickup [moving over to the sip list, as we are now talking about changes to sip] A few thoughts on directed pickup. 1. The mechanism in rfc2543 is a hack. It is meant to provide call pickup as a side effect of register behavior. What would happen is that the register would cause the original INVITE to fork to the second phone. The second phone then answers, which causes the first call to be CANCELed. As such, Alan's flow is wrong. The proxy would not CANCEL on receipt of REGISTER (why would it do that?). Rather, it would generate the second INVITE, and when its answered, then CANCEL. However, this mechanism has some big problems: a. its hard to do in a distributed system where the registrar and proxy are separated b. it doesn't actually provide directed call pickup, since the user experience is much different. IN this mode, the second phone will actually ring! 2. The other proposals so far, involving REFER or a REGISTER directly to the first phone, will not work. They both defined additional, service specific semantics to these requests. Bad, bad. 3. It is possible to do directed pickup with a B2BUA. I worked through a call flow for it, and it emulates completely the PSTN service. It requires no extensions to SIP, just logic for the service in the picking-up phone and in the B2BUA. Can it be done without a B2BUA in a distributed way? Maybe. But, I'm not going to get hung up on emulating every infrequently used PSTN service in a distributed way. 4. I believe we should actually remove the current text on directed pickup. Thats because: a. we said that we don't standardize services, but here is random text in the middle of a section which does just that. It was definitely an afterthought. b. it doesn't work easily when the registrar and proxy are separated c. it doesn't actually do directed pickup as defined d. I don't think its that widely implemented. Can anyone comment on d? Would anyone object to yanking this text? -Jonathan R. > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Thursday, February 22, 2001 10:23 AM > To: Alan Johnston > Cc: Richard Verhoeven; Rick Dean; jundery@ubiquity.net; > parolkar@tri.sbc.com; sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] SIP and Call Pickup > > > Alan Johnston wrote: > > > > Adding Call Pickup and Park is on my to do list for the SIP > > Service Examples I-D (draft-ietf-sip-service-examples-00.txt), > > but I haven't had any suggestions for how to do this. > > > > What about using the mechanism described in bis, but hiding it > > from the caller behind a proxy? The REGISTER message from C > > would expire immediately and be directed at B via the proxy. > > The proxy could then cross-reference the pending INVITE to B, > > consult policy to see if C is authorized to pickup B's calls, > > then cancel the pending INVITE and direct the call to C. > > > > > > Caller A Proxy B Called C Picks > > Up Call > > | | | | > > | INVITE F1 | | | > > |--------------->| INVITE F2 | | > > |(100 Trying) F3 |------------->| | > > |<---------------|180 Ringing F4| | > > | 180 Ringing F5 |<-------------| | > > |<---------------| | | > > | | | REGISTER F6 | > > | |<---------------------------------| > > | | | 200 OK F7 | > > | |--------------------------------->| > > | | | | > > | | CANCEL F8 | | > > | |------------->| | > > | | 200 OK F9 | | > > | |<-------------| | > > | | 487 F10 | | > > | |<-------------| | > > | | ACK F11 | | > > | |------------->| | > > | | | INVITE F12 | > > | |--------------------------------->| > > | | | 180 Ringing F13 | > > | 180 Ringing F14|<---------------------------------| > > |<---------------| | 200 OK F15 | > > | |<---------------------------------| > > | 200 OK F16 | | | > > |<---------------| | | > > | ACK F17 | | | > > |--------------->| | ACK F18 | > > | |--------------------------------->| > > | Both way RTP Established | > > |<=================================================>| > > > > Comments? > > I think this would work. The Proxy could perhaps just fork > again upon receipt of F6, letting both B and C ring and doing > the CANCEL on which ever leg doesn't answer 200. > > However, I don't really like promoting the use of REGISTER > for this as a good idea. It overloads REGISTER and is using > SIP as a call control protocol. The whole area of a SIP call > control framework seems to need more work so I wouldn't want > this perceived to be _the_ way. Anyway if users have intelligent > and intuitive access to forwarding services through CPL call > pick up is redundant. > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 06:50:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04212 for ; Mon, 26 Feb 2001 06:50:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F32EB44368; Mon, 26 Feb 2001 06:50:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 951B244337 for ; Mon, 26 Feb 2001 06:49:59 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1QBnwC16956 for ; Mon, 26 Feb 2001 12:49:58 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Mon Feb 26 12:49:57 2001 +0100 Received: by esealnt746.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Mon, 26 Feb 2001 12:48:58 +0100 Message-ID: <7BA41B5547CCD411833B0002A52CD457D5105B@enlrynt306.etm.ericsson.se> From: "Arnoud van Wijk (ELN)" To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] VIA header encryption? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 12:49:52 +0100 Hello everybody. I have the following question. When a SIP server receives a SIP message, it will insert itself into the VIA header en most likely also encrypt it. Is there a consensus or "rule" to say that the border (proxy) SIP server of a network (the first SIP proxy of a network where external SIP messages enter the network before getting forwarded to other SIP servers inside the network)is not allowed to encrypt the VIA header? My undestanding is that the VIA header encryption is desired to prevent others to read the internal SIP traffic pathway of a network. By encrypting all the VIA headers but the top most one by a bordering SIP proxy should be enough. (the top most header is the proxy itself in this case). Why? In this way, we can identify a network domain via the bordering proxies. Asuming that those proxies do not encrypt the VIA header after adding themself into the VIA header. This can be useful if a certain network is spanned over 6 seperate domains. Any suggestions? Thanks! Arnoud van Wijk _______________________________________________________________ ERICSSON EUROLABS NETHERLANDS BV Arnoud van Wijk Research & Development (ELN/V) Charging Competence Centre Fax: +31-161 247569 Mobile: +31-6-10782760 (SMS only!) Ericsson EuroLab Netherlands b.v. P.O. Box 8 5120 AA Rijen The Netherlands mailto:Arnoud.van.Wijk@eln.ericsson.se Ericsson Homepage: http://www.ericsson.se Ericsson Intranet: http://www.etm.ericsson.se/Abacus_lab/ _______________________________________________________________ _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 07:21:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06425 for ; Mon, 26 Feb 2001 07:21:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A326B44376; Mon, 26 Feb 2001 07:21:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from aurora.tsm.es (unknown [194.224.100.20]) by lists.bell-labs.com (Postfix) with ESMTP id 1B75744375 for ; Mon, 26 Feb 2001 07:20:22 -0500 (EST) Received: by aurora.tsm.es; (8.8.8/1.3/10May95) id NAA03542; Mon, 26 Feb 2001 13:20:35 +0100 (MET) From: Subject: RE: [SIP] geographical location To: "'Lawrence Conroy'" Cc: sip@lists.bell-labs.com Message-ID: X-MIMETrack: Serialize by Router on abantos/TSM( =?iso-8859-1?q?Versi=F3n_5=2E0=2E5_|Octubre_21=2C_2000=29_at_26=2F02=2F?= =?us-ascii?q?2001?= 01:20:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 13:20:04 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA06425 Hi, Lawrence, thank you some comments below -----Original Message----- From: Lawrence Conroy [mailto:lwc@roke.co.uk] Sent: Friday, February 23, 2001 2:27 PM To: sip@lists.bell-labs.com Subject: Re: [SIP] geographical location >To which I reply: >CAMEL is not alone; there is other work being developed in 3GPP that >isn't directly part of that particular "horse designed by a committee". >The LCS work is being done to design a system that provides location >info without being tied to the I.N./CAMEL system; the "location entities" >(GMLC, SMLC,...) are separate units. These may well need to be considered. >Also, as Keith commented, a "SIPish" architecture is being developed >in 3GPP; the MSC-VLR is not necessarily the same beast as a V-CSCF >(i.e. the first SIP proxy); it may well be the SMLC that generates the >data. How this fits with a SIP architecture is not yet clear. >I'm not sure that one can ASSUME that the UA knows where it is *in >a form that is of any use to anyone (i.e. not a Cell Global Id)* Well, as it happens now with location based services in GSM every CellID needs to be mapped on the geographical position of the antenna covering that Cell, as I mentioned it is a 'kind of' location information, the only one currently used so far by cellular operators. I agree with you that if this information is to be delivered to third parties it must be translated before, i.e. a server in the network should translate it into Latitude, Longitude, Altitude, Degree of Error. I´ve just read a few documents covering LCS a couple of years ago, and if I understood it properly, one of the location methods proposed needed a GPS-capable terminal, that, for "real" time bahaviour, should be "assisted", i.e. need an interaction with a server placed in the network which helps with positioning the satellites and saves some time in the process. There was two more methods which offered triangulation processes, but it seems you are used to work with LCS and know the current status of that architecture. What I am not sure is if LCS provides real-time information, which is needed in some scenarios. I wanted to focus also the posibility to define triggers in the network (CAMEL categories) to propagate location information to 3rd parties whenever this location info. related to a particular subscriber changes. I think this approach is more elegant than a continuous polling from the 3rd party to the subscriber, and it is also more similar to the SUBSCRIBE/NOTIFY model discussed here. Anyway CAMEL Phase 3 and LCS both have pros and cons, and it will take some time to see both of them in real networks. What I wanted to point out is the UA will handle the Cell Global Id, and it is already available and it is included in the signalling messages (i.e. IAM) that supports the ISUP based session stablishment. It is real-time, call-related, currently available, and it is better than nothing :) >As I understand it, for most of the LCS work, the current assumption >seems to be that the Network is most likely to calculate the position >of the Mobile User (i.e. the mobile user doesn't know where they are or >doesn't care to tell anyone the truth - a problem with E911). >I'm not sure how this fits into a SIP "end-to-end" architecture. You are right, if a translation is needed, it doesn't fit in the SIP "end-to-end" architecture. Neither assisted GPS nor network-based triangulation methods fit in a "end-to-end" architecture. >We seem to need not only a new header (with data in a form that's usable), The location information handled by a terminal is provided by the network in most of the cases, i.e. the terminal handles measurements related to the radio subsystem, which are converted into location information. The only scenario I know (i´m not an expert) with no interaction with the cellular network is pure GPS, which do not provide real-time performance. Take into account that GPS does not interact with the cellular network but with a satellite network, which acts as a "server" providing some sort of information to the GPS "client" . So, a "pure-end-to-end" solution for location seems to me impossible, you need to trust on a server (let´s call it CAMEL CSE, LCS, GPS satellite, or whatever suits your needs better) regards Javier F. >but also we need to decide who can put this data into the header. If it's >done by a proxy somewhere in the middle of the trail between end users, >this is ugly, IMHO. -- >All the best, Lawrence >------------------------------------------------- >| lwc@roke.co.uk |HomeGeo:50o55'15"N,1o24W| >|Personal Opinions only| ?Cell Colour Code = 3? | >_______________________________________________ >This list is for continuing development of the SIP protocol. >The sip-implementor's list is the place to discuss implementation, >and to receive advice on understanding existing sip. >To subscribe to it, send mail to >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 07:47:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06959 for ; Mon, 26 Feb 2001 07:47:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D58E344383; Mon, 26 Feb 2001 07:47:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from aurora.tsm.es (unknown [194.224.100.20]) by lists.bell-labs.com (Postfix) with ESMTP id 35C864437B for ; Mon, 26 Feb 2001 07:46:26 -0500 (EST) Received: by aurora.tsm.es; (8.8.8/1.3/10May95) id NAA09684; Mon, 26 Feb 2001 13:46:36 +0100 (MET) From: Subject: Re: [SIP] geographical location To: Jiri Kuthan Cc: sip@lists.bell-labs.com Message-ID: X-MIMETrack: Serialize by Router on abantos/TSM( =?iso-8859-1?q?Versi=F3n_5=2E0=2E5_|Octubre_21=2C_2000=29_at_26=2F02=2F?= =?us-ascii?q?2001?= 01:46:06 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 13:45:59 +0100 hi, jiri, thank you some comments below >Maybe I missed some substantial point but I do not >understand why users and their applications should >be willing to deal with some technology-dependent >geographical format. I really cannot expect >a Web/SIP server to understand coordinations expressed >in a format used by my local wireless company. NO, we are not willing to use technology-dependent formats, but with the already existing technologies, in some scenarios (like real-time) we are forced to handle such "strange" formats and need network-based real-time translations. >Geographical coordinates (latitude, longitude, elevation >and precision) will not change. Technological coordinates >(my GSM cell id) or civil names ("Europe Blvd" formerly >"Lenin Blvd" formerly "Stalin Blvd" formerly "Hitler >Blvd" in the city where I was born.) will. Yes, geographical coordinates is the goal I think ALL OF US are willing, the point -at least for me- is IF the UA itself can by itself include geographical coordinates on all different cellular scenarios. I know if the UA includes GPS funtionality it will provide this info for you, the problem is that it will take a couple of minutes for GPS to get this info. Does it mean that the INVITE needs to be delayed for such a long period? If it takes so much time for the UA with GPS capabilities to offer this kind of info this means it will be only valid for non-real time services (i.e. I am traking you on the web, you send me after two minutes your geographical position obtained via GPRS) IF (AND ONLY IF) there are not means for a UA to obtain geographical coordinates on a real time basis BY ITSELF (i mean without interacting with the cellular network) then it means if you want to provide such services you WILL BE FORCED to do a translation in the visited cellular network in terms of: INVITE reservations@hotel.com?cellid=lewkjf into INVITE reservations@hotel.com?latitutude=x;logitude=y;elevation=z actually IF a translation is required I would rather prefer to handle this location info in a specific header. I hope this clarifies why we started discussing about "strange" Cell-Id codes. See I have always mentioned "...IF a translation is required...", "...in certain scenarios..." regards javier >I'd really prefer conveying *geo-coordinates* in web/sip >requests, regardless how they were obtained, what their >original encoding was and what the application dealing with >them is. >I do not think that they should be bound to a specific >request method (like previously SUB-NOT or REGISTER were >mentioned.) Something like >INVITE reservations@hotel.com?latitutude=x;logitude=y;elevation=z >would be useful as well. >Jiri _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 08:07:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07639 for ; Mon, 26 Feb 2001 08:07:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8C6454437C; Mon, 26 Feb 2001 08:07:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 27F0844378 for ; Mon, 26 Feb 2001 08:06:32 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 26 Feb 2001 13:06:30 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id NAA27088; Mon, 26 Feb 2001 13:05:25 GMT Message-ID: <3A9A5494.A5408430@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Arnoud van Wijk (ELN)" Cc: sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: <7BA41B5547CCD411833B0002A52CD457D5105B@enlrynt306.etm.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 13:05:24 +0000 Content-Transfer-Encoding: 7bit "Arnoud van Wijk (ELN)" wrote: > > Hello everybody. > I have the following question. > When a SIP server receives a SIP message, it will insert itself into the VIA header en most likely also encrypt it. > Is there a consensus or "rule" to say that the border (proxy) SIP server of a network (the first SIP proxy of a network where external SIP messages enter the network before getting forwarded to other SIP servers inside the network)is not allowed to encrypt the VIA header? In a 3GPP network encryption of Via headers may be likely, in RFC2453bis based one it isn't. Remember Via hiding was removed from the bis 02 spec due to concerns that it: - interferes with loop detection - operates on a trust model - is widely ignored in implementations Also network information is not just revealed in Vias but can also appear in Record-Route, Route, SDP and any SIP URLs. (Path header too if this is used by 3GPP). > My undestanding is that the VIA header encryption is desired to prevent others to read the internal SIP traffic pathway of a network. By encrypting all the VIA headers but the top most one by a bordering SIP proxy should be enough. (the top most header is the proxy itself in this case). > > Why? > > In this way, we can identify a network domain via the bordering proxies. Asuming that those proxies do not encrypt the VIA header after adding themself into the VIA header. This can be useful if a certain network is spanned over 6 seperate domains. I think the motivation in 3GPP is more to do with providers hiding internal network topography rather than the fact signalling ever passed through them. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 09:05:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09664 for ; Mon, 26 Feb 2001 09:05:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8DBBE44372; Mon, 26 Feb 2001 09:05:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 16DFB44337 for ; Mon, 26 Feb 2001 09:04:35 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA27634; Mon, 26 Feb 2001 09:04:29 -0500 (EST) Message-ID: <3A9A626D.E83DFE3@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: "Arnoud van Wijk (ELN)" , sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: <7BA41B5547CCD411833B0002A52CD457D5105B@enlrynt306.etm.ericsson.se> <3A9A5494.A5408430@ubiquity.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 09:04:29 -0500 Content-Transfer-Encoding: 7bit > > I think the motivation in 3GPP is more to do with providers > hiding internal network topography rather than the fact > signalling ever passed through them. Why hiding the IP addresses or names of servers is of any value has always baffled me. This strikes me as having no security value, but making diagnosis of problems that much more difficult. After all, nobody (except spammers) worries about "exposing the topology of email servers" and does Received header hiding (I hope...). I think rather than rolling over and saying "3GPP must know best", some effort at education should be made by those active in that community. This strikes me as a requirement where the best approach is to say "you really don't want to do this" rather than devising ever more ingenious and complicated ways to pursue the elusive goal of address hiding. If you truly want to hide the IP address of the end system (for which arguments can be made, as that address may reveal location information), you'll need some form of B2B UA, with media handling. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 09:18:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10045 for ; Mon, 26 Feb 2001 09:18:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 22F9A4438D; Mon, 26 Feb 2001 09:18:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (witbier.cisco.com [171.71.152.57]) by lists.bell-labs.com (Postfix) with ESMTP id 645BD4438C for ; Mon, 26 Feb 2001 09:17:08 -0500 (EST) Received: from Ramalho-Family (rtp-vpn-62.cisco.com [10.82.192.62]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id GAA29248; Mon, 26 Feb 2001 06:16:35 -0800 (PST) Message-Id: <4.1.20010226090522.00a286a0@witbier.cisco.com> X-Sender: mramalho@witbier.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Flemming Andreasen , Christer Holmberg From: "Michael A. Ramalho" Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream Cc: Jean-Francois Mule , "'Culpepper, Bert'" , sip@lists.bell-labs.com, jieying.li@claren.com In-Reply-To: <3A993559.1AACEC9E@cisco.com> References: <001201c09e0b$88aef490$e54b010a@rwcjfmule01> <3A97BEA0.E3760932@lmf.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 09:17:13 -0500 This email thread is getting monotonous. Please provide Flemming with a *reason* why you desire two streams that makes sense. Flemming has provided many reasons why you would not desire to do this ... the most persuasive being the fact that you would "double book" the QoS requirements for the session (in the sense of two QoS reservations - not necessarily double the bandwidth reservation). If you desire - at any given instant - to have either stream "active" (i.e., non-muted) - and never desire both to be active at a given time - then Flemming's arguments should be sufficient. The QoS argument is particularly persuasive for access (last mile) systems where bandwidth is precious (e.g., wireless, cable, DSL). Even if this is not the case you are considering (e.g., you are only concerned with VoIP over large backbone networks) ... I'd still suggest, for generality, that you do what Flemming says. This is because you, IN GENERAL, won't know the bandwidth limitations, if any, of the other "IP end". And whoever "pays" for the connection might have to pay and/or account for two reservations instead of one. Q.E.D. Michael Ramalho At 11:39 AM 2/25/01 -0500, Flemming Andreasen wrote: > > >Christer Holmberg wrote: > >> Hi, >> >> Jean-Francois Mule wrote: >> > >> >Thanks for the comments. >> > >> >Flemming Andreasen wrote: >> >>Fundamentally, I don't understand why you view this as two >> >>separate media >> >>streams. You are muting one when you want to use the other, >> >>so why have two in >> >>the first place ? Also note, that there may be some undesirable QoS >> >>interactions that way. >> > >> >Christer Holmberg pointed earlier that T.38 suggests to add the fax channel >> >to the voice stream and to mute the voice stream. >> >> Just to clarify: it's not T.38 that suggests this, it is the node (e.g. >> gateway) that detects >> the fax that may suggest this :) >> >> >The only reference I found in T.38 Annex D (TD0262rev1), section 2.2.4 >> >states: >> >"Note that during this switch over and the facsimile call, it may be useful >> >to mute the voice channel. The voice channel may be used again once the end >> >of facsimile transmission is detected." >> >=> this implies that T.38 annex D recommends both streams in the same >> >session. >> > >> >As I've pointed out earlier - and this is what was shown in the current >> >draft, I also prefer to replace the voice by a fax channel for the same DSP >> >resource consumption reasons. BTW, this "replacement" does not prevent the >> >session to return to voice mode after the fax is over (re-INVITE with audio >> >sdp). >> >> There may some issues here, especially if you have a PSTN gateway. If >> you do this, you basically want to create a new connection on the >> endpoint. And, since you already have a connection there this won't >> work. > >Since when could you not create more than one connection on an endpoint ? > >Even for implementations that can only handle a single connection per endpoint, >since when could you not change the media parameters of that connection ? > > >Can we please get some real arguments on the table here - what is the problem ? > >-- Flemming > > >-- >Flemming Andreasen >Cisco Systems > > > >_______________________________________________ >This list is for continuing development of the SIP protocol. >The sip-implementor's list is the place to discuss implementation, >and to receive advice on understanding existing sip. >To subscribe to it, send mail to >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.732.449.5762 Cell: +1.732.809.0188 Pager: +1.800.365.4578 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 09:26:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10280 for ; Mon, 26 Feb 2001 09:26:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 34A7044341; Mon, 26 Feb 2001 09:26:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8D4194433C for ; Mon, 26 Feb 2001 09:25:12 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA05735; Mon, 26 Feb 2001 09:28:13 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 09:27:37 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3047619@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Sharath Rajasekar'" , sip@lists.bell-labs.com Subject: RE: [SIP] Bye-Also Draft ? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 09:27:35 -0500 The draft that defined Bye-Also is long expired. New implementations should track the current work on transfer in draft-ietf-sip-cc-transfer-nn.txt (-04 will be out today). There was discussion at the interim meeting about capturing the Bye-Also behavior in a historical draft. RjS > -----Original Message----- > From: Sharath Rajasekar [mailto:Sharath.Rajasekar@sylantro.com] > Sent: Saturday, February 24, 2001 3:08 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Bye-Also Draft ? > > > > Hi, > > Can anyone tell me how I can get hold of the Bye-Also draft for > transfers. I could not find it in the IETF Draft Repository. > > Thanks > Sharath > > > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 09:30:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10370 for ; Mon, 26 Feb 2001 09:30:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 97D0A4435A; Mon, 26 Feb 2001 09:30:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id BB77444346 for ; Mon, 26 Feb 2001 09:28:59 -0500 (EST) 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 f1QEStC12564; Mon, 26 Feb 2001 15:28:57 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.11.2/8.11.2) with ESMTP id f1QESsc14919; Mon, 26 Feb 2001 16:28:54 +0200 (EET) Message-ID: <3A9A6824.E411D77E@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Michael A. Ramalho" Cc: Flemming Andreasen , Jean-Francois Mule , "'Culpepper, Bert'" , sip@lists.bell-labs.com, jieying.li@claren.com Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream References: <001201c09e0b$88aef490$e54b010a@rwcjfmule01> <3A97BEA0.E3760932@lmf.ericsson.se> <4.1.20010226090522.00a286a0@witbier.cisco.com> Content-Type: multipart/mixed; boundary="------------A16C910C38892F6F473B4C49" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 16:28:52 +0200 This is a multi-part message in MIME format. --------------A16C910C38892F6F473B4C49 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I am very happy to allow a single stream, and that's the reason why it will be added to the call flows. I DO also agree, that if nobody can give a good reason why we would need separate streams I think we should consider it to be removed from the recommendation draft. This discussion, however, was from the beginning about the bugs in call flows draft, which is based on the recommendation. However, I think we all agree that this discussion has showed that the recommendation should be updated too... Regards, Christer > This email thread is getting monotonous. > > Please provide Flemming with a *reason* why you > desire two streams that makes sense. > > Flemming has provided many reasons why you > would not desire to do this ... the most persuasive > being the fact that you would "double book" the > QoS requirements for the session (in the sense of > two QoS reservations - not necessarily double the > bandwidth reservation). > > If you desire - at any given instant - to have either > stream "active" (i.e., non-muted) - and never desire > both to be active at a given time - then Flemming's > arguments should be sufficient. > > The QoS argument is particularly persuasive > for access (last mile) systems where bandwidth > is precious (e.g., wireless, cable, DSL). > > Even if this is not the case you are considering > (e.g., you are only concerned with VoIP over > large backbone networks) ... I'd still suggest, > for generality, that you do what Flemming > says. This is because you, IN GENERAL, > won't know the bandwidth limitations, if any, > of the other "IP end". And whoever "pays" > for the connection might have to pay and/or > account for two reservations instead of one. > > Q.E.D. > > Michael Ramalho > > At 11:39 AM 2/25/01 -0500, Flemming Andreasen wrote: > > > > > >Christer Holmberg wrote: > > > >> Hi, > >> > >> Jean-Francois Mule wrote: > >> > > >> >Thanks for the comments. > >> > > >> >Flemming Andreasen wrote: > >> >>Fundamentally, I don't understand why you view this as two > >> >>separate media > >> >>streams. You are muting one when you want to use the other, > >> >>so why have two in > >> >>the first place ? Also note, that there may be some undesirable QoS > >> >>interactions that way. > >> > > >> >Christer Holmberg pointed earlier that T.38 suggests to add the fax channel > >> >to the voice stream and to mute the voice stream. > >> > >> Just to clarify: it's not T.38 that suggests this, it is the node (e.g. > >> gateway) that detects > >> the fax that may suggest this :) > >> > >> >The only reference I found in T.38 Annex D (TD0262rev1), section 2.2.4 > >> >states: > >> >"Note that during this switch over and the facsimile call, it may be useful > >> >to mute the voice channel. The voice channel may be used again once > the end > >> >of facsimile transmission is detected." > >> >=> this implies that T.38 annex D recommends both streams in the same > >> >session. > >> > > >> >As I've pointed out earlier - and this is what was shown in the current > >> >draft, I also prefer to replace the voice by a fax channel for the same DSP > >> >resource consumption reasons. BTW, this "replacement" does not prevent the > >> >session to return to voice mode after the fax is over (re-INVITE with audio > >> >sdp). > >> > >> There may some issues here, especially if you have a PSTN gateway. If > >> you do this, you basically want to create a new connection on the > >> endpoint. And, since you already have a connection there this won't > >> work. > > > >Since when could you not create more than one connection on an endpoint ? > > > >Even for implementations that can only handle a single connection per > endpoint, > >since when could you not change the media parameters of that connection ? > > > > > >Can we please get some real arguments on the table here - what is the > problem ? > > > >-- Flemming > > > > > >-- > >Flemming Andreasen > >Cisco Systems > > > > > > > >_______________________________________________ > >This list is for continuing development of the SIP protocol. > >The sip-implementor's list is the place to discuss implementation, > >and to receive advice on understanding existing sip. > >To subscribe to it, send mail to > >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > Michael A. Ramalho, Ph.D. > Office email: mramalho@cisco.com > Personal email: mar42@cornell.edu > Office: +1.732.449.5762 > Cell: +1.732.809.0188 > Pager: +1.800.365.4578 --------------A16C910C38892F6F473B4C49 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 --------------A16C910C38892F6F473B4C49-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 09:53:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11256 for ; Mon, 26 Feb 2001 09:53:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C993C4434A; Mon, 26 Feb 2001 09:53:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-42-234.dallas.net [209.44.42.234]) by lists.bell-labs.com (Postfix) with ESMTP id CF58644337 for ; Mon, 26 Feb 2001 01:50:09 -0500 (EST) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id AAA07056; Mon, 26 Feb 2001 00:47:32 -0600 From: "Brian F. G. Bidulock" To: Scott Hoffpauir Cc: Jonathan Rosenberg , "'Neil Deason'" , Alan Johnston , Richard Verhoeven , Rick Dean , jundery@ubiquity.net, parolkar@tri.sbc.com, sip@lists.bell-labs.com Subject: Re: [SIP] RE: [Sip-implementors] SIP and Call Pickup Message-ID: <20010226004732.A7007@bfgbhome> Reply-To: bidulock@openss7.org Mail-Followup-To: Scott Hoffpauir , Jonathan Rosenberg , 'Neil Deason' , Alan Johnston , Richard Verhoeven , Rick Dean , jundery@ubiquity.net, parolkar@tri.sbc.com, sip@lists.bell-labs.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from scott@broadsoft.com on Mon, Feb 26, 2001 at 12:11:32AM -0500 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 00:47:32 -0600 Scott, I agree 100%. It was a dumb feature to try and make digital Centrex phones mimic the behavior of a keyset. Nobody liked it, nobody used it. Yank it, please... --Brian Scott Hoffpauir wrote: (Mon, 26 Feb 2001 00:11:32) > > We do call pickup with a B2BUA, which as stated doesn't require anything out > of the ordinary. With wide scale deployment of voice mail, this service > isn't really that useful. There are many better call completion features > today (voice mail, forking, etc.) which will eventually obsolete call > pickup. Last time I used it was about 10 years ago. I think it should be > yanked. > > Scott > > BroadSoft > 240-364-5106 > -- Brian F. G. Bidulock bidulock@openss7.org http://www.openss7.org/ _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 09:55:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11335 for ; Mon, 26 Feb 2001 09:55:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4195A44394; Mon, 26 Feb 2001 09:53:21 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by lists.bell-labs.com (Postfix) with ESMTP id ED8494438C for ; Mon, 26 Feb 2001 08:07:36 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f1QD7PU14246; Mon, 26 Feb 2001 15:07:25 +0200 Message-Id: <200102261307.f1QD7PU14246@lohi.eng.telia.fi> From: Juha Heinanen To: sip@lists.bell-labs.com Subject: [SIP] confusion in url comparison Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 15:07:25 +0200 there is an uncertainty between some vendors if the two sip urls sip:foo@bar.com sip:foor@bar.com;user=phone should be considered to match, when the urls appear in to or from fields. according to the text of section 2.1 they seem to match, since it says o user or telephone-subscriber, password, host, port and any url-parameter parameters of the URI must match. If a component is omitted, it matches based on its default value. (For example, otherwise equivalent URLs without a port specification and with port 5060 match.) Components not found in both URLs being compared are ignored. thus in the comparison, user=phone is ignored. but this doesn't really make sense, since according to table 2, the only mandatory component in to and from fields is host. thus also the two urls sip:bar.com sip:foor@bar.com;user=phone would match. so it looks to me like section 2.1 would require some rewording. -- juha _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 10:09:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11818 for ; Mon, 26 Feb 2001 10:09:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3176544352; Mon, 26 Feb 2001 10:09:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 6E1384438B for ; Mon, 26 Feb 2001 10:08:15 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA01893 for ; Mon, 26 Feb 2001 10:08:14 -0500 (EST) Message-ID: <3A9A715E.BE5541C1@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] RE: [Sip-implementors] SIP and Call Pickup References: <20010226004732.A7007@bfgbhome> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 10:08:14 -0500 Content-Transfer-Encoding: 7bit I've removed the service description from the draft. However, this still leaves the question what, if anything, the draft should say about the desired behavior if the registration does change while sequential forking, say, is going on. The current wording is: If the registration is changed while a user agent or proxy server processes an invitation, the new information {\SHOULD} be used. I suspect the simplest behavior is to say that this is implementation-dependent. In other words, if you want to allow adding a new location to an on-going search in your proxy, fine, but you can't rely on this to build a new service. (I'm trimming the cc list, since presumably everyone is on the SIP mailing list and doesn't need to see two copies of each message.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 10:13:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11949 for ; Mon, 26 Feb 2001 10:13:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 124F644371; Mon, 26 Feb 2001 10:10:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 9B07644370 for ; Mon, 26 Feb 2001 10:09:17 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA06266; Mon, 26 Feb 2001 07:09:11 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f1QF8sb12123; Mon, 26 Feb 2001 07:08:54 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id HAA02582; Mon, 26 Feb 2001 07:08:51 -0800 (PST) Message-ID: <3A9A7245.66C04E9A@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: "Michael A. Ramalho" , Jean-Francois Mule , "'Culpepper, Bert'" , sip@lists.bell-labs.com, jieying.li@claren.com Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream References: <001201c09e0b$88aef490$e54b010a@rwcjfmule01> <3A97BEA0.E3760932@lmf.ericsson.se> <4.1.20010226090522.00a286a0@witbier.cisco.com> <3A9A6824.E411D77E@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 10:12:05 -0500 Content-Transfer-Encoding: 7bit Right. Based on all your responses (thanks) it seems we are in much more agreement than I thought we were. I also agree with your recommended next steps here. Regards Flemming Christer Holmberg wrote: > Hi, > > I am very happy to allow a single stream, and that's the reason why it > will be added to the call flows. I DO also agree, that if nobody can > give a good reason why we would need separate streams I think we should > consider it to be removed from the recommendation draft. This > discussion, however, was from the beginning about the bugs in call flows > draft, which is based on the recommendation. However, I think we all > agree that this discussion has showed that the recommendation should be > updated too... > > Regards, > > Christer > > > This email thread is getting monotonous. > > > > Please provide Flemming with a *reason* why you > > desire two streams that makes sense. > > > > Flemming has provided many reasons why you > > would not desire to do this ... the most persuasive > > being the fact that you would "double book" the > > QoS requirements for the session (in the sense of > > two QoS reservations - not necessarily double the > > bandwidth reservation). > > > > If you desire - at any given instant - to have either > > stream "active" (i.e., non-muted) - and never desire > > both to be active at a given time - then Flemming's > > arguments should be sufficient. > > > > The QoS argument is particularly persuasive > > for access (last mile) systems where bandwidth > > is precious (e.g., wireless, cable, DSL). > > > > Even if this is not the case you are considering > > (e.g., you are only concerned with VoIP over > > large backbone networks) ... I'd still suggest, > > for generality, that you do what Flemming > > says. This is because you, IN GENERAL, > > won't know the bandwidth limitations, if any, > > of the other "IP end". And whoever "pays" > > for the connection might have to pay and/or > > account for two reservations instead of one. > > > > Q.E.D. > > > > Michael Ramalho > > > > At 11:39 AM 2/25/01 -0500, Flemming Andreasen wrote: > > > > > > > > >Christer Holmberg wrote: > > > > > >> Hi, > > >> > > >> Jean-Francois Mule wrote: > > >> > > > >> >Thanks for the comments. > > >> > > > >> >Flemming Andreasen wrote: > > >> >>Fundamentally, I don't understand why you view this as two > > >> >>separate media > > >> >>streams. You are muting one when you want to use the other, > > >> >>so why have two in > > >> >>the first place ? Also note, that there may be some undesirable QoS > > >> >>interactions that way. > > >> > > > >> >Christer Holmberg pointed earlier that T.38 suggests to add the fax channel > > >> >to the voice stream and to mute the voice stream. > > >> > > >> Just to clarify: it's not T.38 that suggests this, it is the node (e.g. > > >> gateway) that detects > > >> the fax that may suggest this :) > > >> > > >> >The only reference I found in T.38 Annex D (TD0262rev1), section 2.2.4 > > >> >states: > > >> >"Note that during this switch over and the facsimile call, it may be useful > > >> >to mute the voice channel. The voice channel may be used again once > > the end > > >> >of facsimile transmission is detected." > > >> >=> this implies that T.38 annex D recommends both streams in the same > > >> >session. > > >> > > > >> >As I've pointed out earlier - and this is what was shown in the current > > >> >draft, I also prefer to replace the voice by a fax channel for the same DSP > > >> >resource consumption reasons. BTW, this "replacement" does not prevent the > > >> >session to return to voice mode after the fax is over (re-INVITE with audio > > >> >sdp). > > >> > > >> There may some issues here, especially if you have a PSTN gateway. If > > >> you do this, you basically want to create a new connection on the > > >> endpoint. And, since you already have a connection there this won't > > >> work. > > > > > >Since when could you not create more than one connection on an endpoint ? > > > > > >Even for implementations that can only handle a single connection per > > endpoint, > > >since when could you not change the media parameters of that connection ? > > > > > > > > >Can we please get some real arguments on the table here - what is the > > problem ? > > > > > >-- Flemming > > > > > > > > >-- > > >Flemming Andreasen > > >Cisco Systems > > > > > > > > > > > >_______________________________________________ > > >This list is for continuing development of the SIP protocol. > > >The sip-implementor's list is the place to discuss implementation, > > >and to receive advice on understanding existing sip. > > >To subscribe to it, send mail to > > >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > > Michael A. Ramalho, Ph.D. > > Office email: mramalho@cisco.com > > Personal email: mar42@cornell.edu > > Office: +1.732.449.5762 > > Cell: +1.732.809.0188 > > Pager: +1.800.365.4578 -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 10:17:16 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12066 for ; Mon, 26 Feb 2001 10:17:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A1E71443A4; Mon, 26 Feb 2001 10:16:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 833F9443A3 for ; Mon, 26 Feb 2001 10:15:43 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 26 Feb 2001 15:15:42 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id PAA15602; Mon, 26 Feb 2001 15:14:34 GMT Message-ID: <3A9A72DA.A374709D@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen Cc: sip@lists.bell-labs.com Subject: Re: [SIP] confusion in url comparison References: <200102261307.f1QD7PU14246@lohi.eng.telia.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 15:14:34 +0000 Content-Transfer-Encoding: 7bit Juha Heinanen wrote: > > there is an uncertainty between some vendors if the two sip urls > > sip:foo@bar.com > sip:foor@bar.com;user=phone > > should be considered to match, when the urls appear in to or from > fields. > > according to the text of section 2.1 they seem to match, since it says > > o user or telephone-subscriber, password, host, port and any url-parameter > parameters of the URI must match. If a component is omitted, it matches > based on its default value. (For example, otherwise equivalent URLs > without a port specification and with port 5060 match.) Components not > found in both URLs being compared are ignored. > > thus in the comparison, user=phone is ignored. No, if a componment is omitted it matches on it's default value. Table 2 defines the default value for user-param as 'ip' not 'phone'. > but this doesn't really > make sense, since according to table 2, the only mandatory component in > to and from fields is host. thus also the two urls > > sip:bar.com > sip:foor@bar.com;user=phone > > would match. so it looks to me like section 2.1 would require some > rewording. These don't match either - the user part is still significant in the comparison despite being omitted from one URL. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 10:34:00 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12629 for ; Mon, 26 Feb 2001 10:33:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B61664433D; Mon, 26 Feb 2001 10:33:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id F102744337 for ; Mon, 26 Feb 2001 10:32:42 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA07216 for ; Mon, 26 Feb 2001 10:35:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 10:35:17 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F304761C@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0A009.B7F82508" Subject: [SIP] REFER revision Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 10:35:15 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0A009.B7F82508 Content-Type: text/plain; charset="iso-8859-1" The attached draft-ietf-sip-cc-transfer-04 has been submitted to the draft repostitory. This draft is destined to be split into two (separating the definition of REFER from is use to achieve transfer). I've kept them as one for this iteration primarily to make sure the changes to the use of NOTIFY were available in the draft repository before the March meeting. Here's the changes section from the document: Editor's note: The changes for this revision focused on the changes to the NOTIFY response mechanism discussed at February's interim meeting, and clarification to the REFER method itself. As mentioned above, the intent is to separate this document into two. The split was postponed a version to ensure the edits to REFER/NOTIFY would be reflected in the ID repository in time for discussion at IETF 50. o Modified contents of NOTIFYs to reflect the consensus at the interim meeting. One event type, with an application/sip body representing the information to be returned. o Added message detail to the prototypical flow o More explicitly stated that REFER MAY occur outside an existing call-leg o Reinforced that REFER can be record-routed o Made the presence of a Contact header mandatory o Changed the positive response to a REFER request to 202 Accepted instead of 200 OK o Corrected editing errors in examples and message diagrams RjS ------_=_NextPart_000_01C0A009.B7F82508 Content-Type: text/plain; name="draft-ietf-sip-cc-transfer-04.txt" Content-Disposition: attachment; filename="draft-ietf-sip-cc-transfer-04.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= Internet Engineering Task Force R. = Sparks=0A= Internet-Draft = dynamicsoft=0A= Expires: August 27, 2001 February 26, = 2001=0A= =0A= =0A= SIP Call Control - Transfer=0A= draft-sip-cc-transfer-04=0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance = with=0A= all provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as=0A= Internet-Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six=0A= months and may be updated, replaced, or obsoleted by other = documents=0A= at any time. It is inappropriate to use Internet-Drafts as = reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on August 27, 2001.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2001). All Rights Reserved.=0A= =0A= Abstract=0A= =0A= This document defines a SIP extension, REFER, and demonstrates = its=0A= use to provide Call Transfer capabilities. This work is part of = the=0A= Call Control Framework. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 1]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . = 3=0A= 2. Changes from draft-sparks-sip-cc-transfer-03 . . . . . . . = 3=0A= 3. The REFER Method . . . . . . . . . . . . . . . . . . . . . = 4=0A= 3.1 The Refer-To Header . . . . . . . . . . . . . . . . . . . = 4=0A= 3.1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . = 4=0A= 3.2 The Referred-By Header . . . . . . . . . . . . . . . . . . = 5=0A= 3.2.1 A PGP based signature-scheme . . . . . . . . . . . . . . . = 5=0A= 3.2.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . = 6=0A= 3.3 Header Field Support for the REFER Method . . . . . . . . = 6=0A= 3.4 Message Body Inclusion . . . . . . . . . . . . . . . . . . = 7=0A= 3.5 Responses within the REFER transaction . . . . . . . . . . = 7=0A= 3.6 Behavior of SIP User Agents . . . . . . . . . . . . . . . = 8=0A= 3.6.1 Accessing the referred-to resource . . . . . . . . . . . . = 8=0A= 3.6.2 Reporting on the results of the reference . . . . . . . . = 8=0A= 3.6.2.1 Using NOTIFY . . . . . . . . . . . . . . . . . . . . . . . = 8=0A= 3.6.2.2 The body of the NOTIFY . . . . . . . . . . . . . . . . . . = 8=0A= 3.7 Behavior of SIP Registrars/Redirect Servers . . . . . . . = 9=0A= 3.8 Behavior of SIP Proxies . . . . . . . . . . . . . . . . . = 9=0A= 3.9 Prototypical REFER callflow . . . . . . . . . . . . . . . = 10=0A= 3.10 Security Considerations . . . . . . . . . . . . . . . . . = 11=0A= 3.10.1 Circumventing privacy . . . . . . . . . . . . . . . . . . = 11=0A= 3.10.2 Circumventing security . . . . . . . . . . . . . . . . . . = 12=0A= 3.10.3 Limiting the breach . . . . . . . . . . . . . . . . . . . = 12=0A= 4. Call Transfer . . . . . . . . . . . . . . . . . . . . . . = 13=0A= 4.1 Actors and Roles . . . . . . . . . . . . . . . . . . . . . = 13=0A= 4.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . = 13=0A= 4.3 Using REFER to achieve Call Transfer . . . . . . . . . . . = 14=0A= 4.4 Unattended Transfer . . . . . . . . . . . . . . . . . . . = 14=0A= 4.4.1 Successful Unattended Transfer . . . . . . . . . . . . . . = 15=0A= 4.4.2 Failed Unattended Transfer . . . . . . . . . . . . . . . . = 16=0A= 4.5 Unattended Transfer with Consultation Hold . . . . . . . . = 16=0A= 4.5.1 Variation 1 : Exposes transfer target . . . . . . . . . . = 17=0A= 4.5.2 Variation 2 : Protects transfer target . . . . . . . . . . = 18=0A= 4.5.3 Consultation Hold in the presence of forking proxies . . . = 18=0A= 4.6 Attended Transfer . . . . . . . . . . . . . . . . . . . . = 19=0A= 4.7 Transfer with multiple parties . . . . . . . . . . . . . . = 19=0A= 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . = 20=0A= 5.1 REFER is now dependent on sip-events . . . . . . . . . . . = 20=0A= 5.2 Registering the events with IANA . . . . . . . . . . . . . = 20=0A= 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . = 20=0A= References . . . . . . . . . . . . . . . . . . . . . . . . = 20=0A= Author's Address . . . . . . . . . . . . . . . . . . . . . = 21=0A= Full Copyright Statement . . . . . . . . . . . . . . . . . = 22=0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 2]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 1. Overview=0A= =0A= This document defines a SIP[1] extension, REFER, and details its = use=0A= to provide Call Transfer capabilities. This is part of a family = of=0A= Call Control extensions described in the Call Control = Framework[2]=0A= document. =0A= =0A= Editor's note: Per consensus at the February interim WG meeting, = the=0A= two parts of this document, the definition of REFER and its use = to=0A= achieve transfer, will be separated into separate documents. That=0A= separation will take place with the next revision of this document. = =0A= =0A= The mechanisms discussed here are most closely related to=0A= traditional unattended and consultation hold transfers. = Discussion=0A= of attended transfer (where all parties are briefly in a = conference)=0A= is deferred until the conferencing features in this framework are=0A= addressed. =0A= =0A= This work has roots in draft-ietf-sip-cc-01[4] but some basic=0A= semantics are different. In particular, transfers are achieved=0A= through a new method that does not terminate the original = signaling=0A= relationship. By disassociating transfers from the processing of=0A= BYE, these changes facilitate recovery of failed transfers and=0A= clarify state management in the participating entities. =0A= =0A= 2. Changes from draft-sparks-sip-cc-transfer-03=0A= =0A= Editor's note: The changes for this revision focused on the = changes=0A= to the NOTIFY response mechanism discussed at February's interim=0A= meeting, and clarification to the REFER method itself. As = mentioned=0A= above, the intent is to separate this document into two. The = split=0A= was postponed a version to ensure the edits to REFER/NOTIFY would = be=0A= reflected in the ID repository in time for discussion at IETF 50. = =0A= =0A= o Modified contents of NOTIFYs to reflect the consensus at the=0A= interim meeting. One event type, with an application/sip body=0A= representing the information to be returned.=0A= o Added message detail to the prototypical flow =0A= o More explicitly stated that REFER MAY occur outside an = existing=0A= call-leg =0A= o Reinforced that REFER can be record-routed=0A= o Made the presence of a Contact header mandatory=0A= o Changed the positive response to a REFER request to 202 = Accepted=0A= instead of 200 OK=0A= o Corrected editing errors in examples and message diagrams=0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 3]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 3. The REFER Method=0A= =0A= REFER is a SIP method as defined by RFC2543[1]. The REFER method=0A= indicates that the recipient (identified by the Request-URI) = should=0A= contact a third party using the contact information provided in = the=0A= method. A success response indicates that the recipient was able = to=0A= contact the third party. =0A= =0A= Unless stated otherwise, the protocol for emitting and responding = to=0A= a REFER request are identical to those for a BYE request in [1]. = The=0A= behavior of SIP entities not implementing the REFER (or any other=0A= unknown) method is explicitly defined in [1]. =0A= =0A= A REFER request MAY be placed outside the scope of a call-leg=0A= created with an INVITE. REFER MAY be Record-Routed, hence MUST=0A= contain a single Contact header. REFERs occurring inside an = existing=0A= call-leg MUST follow the Route/Record-Route logic of that = call-leg.=0A= REFERs occurring outside an existing call-leg effectively create = a=0A= new call-leg following the behavior of SUBSCRIBE specified [3]. =0A= =0A= 3.1 The Refer-To Header=0A= =0A= Refer-To is a request-header as defined by [1]. It may only = appear=0A= in a REFER request. =0A= =0A= Refer-To =3D ("Refer-To" | "r") ":" URL =0A= =0A= A REFER method MUST contain exactly one Refer-To header. =0A= =0A= The Refer-To header MAY be encrypted as part of end-end encryption. = =0A= =0A= The Contact header is an important part of the = Route/Record-Route=0A= mechanism and is not available for this task.=0A= =0A= 3.1.1 Examples=0A= =0A= Refer-To: sip:alice@atlanta.com=0A= =0A= Refer-To: sip:bob@biloxi.com?Accept-Contact=3Dsip:bobsdesk.=0A= biloxi.com&Call-ID=3D55432@alicepc.atlanta.com=0A= =0A= Refer-To: sip:carol@cleveland.com;method=3DSUBSCRIBE=0A= =0A= Refer-To: http://www.ietf.org=0A= =0A= Long headers are line-wrapped here for clarity only.=0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 4]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 3.2 The Referred-By Header=0A= =0A= Referred-By is a request-header as defined by [1]. It can appear = in=0A= any request. It conveys the identity of the original REFERrer to = the=0A= referred-to party, optionally proving the identity and that the=0A= REFERrer actually issued this reference. =0A= =0A= =0A= Referred-By =3D ("Referred-By" | "b") ":" referrer-url = ";"=0A= ( referenced-url=0A= | ( referenced-url ";" ref-signature = )=0A= | ( ref-signature ";" referenced-url = )=0A= )=0A= referrer-url =3D ( name-addr | addr-spec )=0A= referenced-url =3D "ref" "=3D" "<" URL ">"=0A= ref-signature =3D signature-scheme *( ";" sig-scheme-params = )=0A= signature-scheme =3D "scheme" "=3D" token=0A= sig-scheme-parms =3D token "=3D" ( token | quoted-string )=0A= =0A= The referrer-url contains the SIP URL of the party sending the = REFER=0A= request. The referenced-url contains a copy of the URL placed in = the=0A= Refer-To: header. Any occurrences of < or > in the referenced-url=0A= MUST be escaped. The ref-signature contains a signature over the=0A= concatenation of referrer-url and referenced-url. An example=0A= signature scheme is given in section 3.1.2. =0A= =0A= A REFER request MUST contain exactly one Referred-By header. =0A= =0A= The Referred-By header SHOULD be signed to help detection of = REFERs=0A= from unauthorized third parties. A signed Referred-By header = SHOULD=0A= include a Date header in the referrer-url to facilitate detection = of=0A= replay attacks. =0A= =0A= A UA MAY reject a request containing an unsigned Referred-By = header.=0A= A UA SHOULD verify the signature on any Referred-By header it=0A= receives. =0A= =0A= The Referred-By header MAY be encrypted as part of end-end=0A= encryption. =0A= =0A= 3.2.1 A PGP based signature-scheme=0A= =0A= One signature-scheme for Referred-By headers uses PGP as follows: = =0A= =0A= signature-scheme =3D "scheme" "=3D" "pgp"=0A= sig-scheme-parms =3D pgp-version | signed-by | pgp-signature=0A= =0A= pgp-version, signed-by and pgp-signature are defined in section = 15.1=0A= of RFC2543, with the modification that the signature is computed=0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 5]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= across the concatenation of the referrer-url and the referenced-url. = =0A= =0A= 3.2.2 Examples=0A= =0A= =0A= Referred-By: sip:alice@atlanta.com;ref=3D=0A= =0A= Referred-By: "Bob" ;=0A= ref=3D;scheme=3Dpgp;=0A= pgp-version=3D"5.0";signature=3D"the signature"=0A= =0A= =0A= (Note that in the last example, the signature would be over the=0A= string "sip:bob@biloxi.comsip:alice@atlanta.com") =0A= =0A= 3.3 Header Field Support for the REFER Method=0A= =0A= This table adds a column to tables 4 and 5 in [1], describing = header=0A= presence in a REFER method. See [1] for a key for the symbols = used.=0A= A row for the Refer-To: and Referred-By request-header should be=0A= inferred, each mandatory for REFER. Refer-To is not applicable = for=0A= all other methods. Referred-By is a general Request header. The = enc=0A= and e-e columns in [1] apply to the REFER method unmodified. =0A= =0A= Header Where REFER=0A= Accept R -=0A= Accept-Encoding R -=0A= Accept-Language R o=0A= Allow R -=0A= Allow 405 m=0A= Authorization R o=0A= Call-ID gc m=0A= Contact R m=0A= Contact 1xx -=0A= Contact 2-6xx o=0A= Content-Encoding e -=0A= Content-Length e o=0A= Content-Type e -=0A= CSeq gc m=0A= Date g o=0A= Encryption g o=0A= Expires R o=0A= From gc m=0A= Hide R o=0A= Max-Forwards R o=0A= Organization g o=0A= Priority R -=0A= Proxy-Authenticate 407 o=0A= Proxy-Authorization R o=0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 6]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= Proxy-Require R o=0A= Require R o=0A= Retry-After R -=0A= Retry-After 404,480,486 o=0A= Retry-After 503 o=0A= Retry-After 600,603 o=0A= Response-Key R o=0A= Record-Route R o=0A= Record-Route 2xx o=0A= Route R o=0A= Server r o=0A= Subject R -=0A= Timestamp g o=0A= To gc(1) m=0A= Unsupported 420 o=0A= User-Agent g o=0A= Via gc(2) m=0A= Warning r o=0A= WWW-Authenticate 401 o=0A= =0A= 3.4 Message Body Inclusion=0A= =0A= A REFER method may contain a body which SHOULD be processed=0A= according to its Content-Type. =0A= =0A= 3.5 Responses within the REFER transaction=0A= =0A= An agent responding to a REFER Method MUST return a 400 Bad = Request=0A= if the request contained zero or more than one Refer-To headers. = An=0A= agent responding to a REFER Method MUST return a 400 Bad Request = if=0A= the request contained zero or more than one Referred-By headers. = An=0A= agent (including proxies generating local responses) MAY return a=0A= 100 Trying or any appropriate 400-600 class response as = prescribed=0A= by [1]. If the recipient's agent decides to contact the resource = in=0A= the Refer-To header, a 202 Accepted response MUST be returned = before=0A= the REFER transaction expires. =0A= =0A= Editor's note - earlier versions of this draft required the agent=0A= responding to REFER to wait until the referred action completed=0A= before sending a final response to the REFER. That final response=0A= reflected the success or failure of the referred action. This was=0A= infeasible due to the transaction timeout rules defined for=0A= non-INVITE requests in [1]. A REFER must always receive an = immediate=0A= (within the lifetime of a non-INVITE transaction) final response. = =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 7]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 3.6 Behavior of SIP User Agents=0A= =0A= 3.6.1 Accessing the referred-to resource=0A= =0A= A UA receiving a well-formed REFER request SHOULD request = approval=0A= from the user to proceed (this request could be interactive or=0A= through configuration). Upon receiving approval from the user, = the=0A= UA MUST contact the resource identified by the URL in the = Refer-To:=0A= header. Note that if the URL is a SIP URL, it could contain = header=0A= fields such as Call-Id that will be used to form the resulting=0A= request. If the URL is a SIP URL, the Referred-By header in the=0A= REFER request should be copied into the request sent to the=0A= referred-to resource. =0A= =0A= 3.6.2 Reporting on the results of the reference=0A= =0A= 3.6.2.1 Using NOTIFY=0A= =0A= Once it is known whether the reference succeeded or failed, the = UA=0A= receiving the REFER SHOULD notify the agent sending the refer = using=0A= the NOTIFY mechanism defined in Event Notification in SIP[3] as = if=0A= the the REFER had established a subscription. In particular: =0A= =0A= o Each NOTIFY should reflect the To:, From:, and Call-ID headers=0A= from the REFER as if they had arrived in a SUBSCRIBE. =0A= =0A= o Each NOTIFY MUST contain an event header of Event: refer =0A= =0A= o Each NOTIFY MUST contain a body of type "application/sip". The=0A= contents of this body are detailed in Section 3.6.2.2=0A= =0A= o Analogous to the case for SUBSCRIBE described in [3], the = agent=0A= that issued the REFER MUST be prepared to receive a NOTIFY = before=0A= the REFER transaction completes. =0A= =0A= Open Issue: This makes REFER dependent on sip-events (Section = 5.1)=0A= =0A= Open Issue: The refer event will need to be registered with IANA=0A= (Section 5.2)=0A= =0A= 3.6.2.2 The body of the NOTIFY=0A= =0A= Each NOTIFY MUST contain a body of type "application/sip". This = body=0A= MUST begin with a SIP Response Status-Line as defined in [1]. The=0A= response class in this status line indicates the success of the=0A= referred action. The body MAY contain other SIP headers to = provide=0A= information about the outcome of the referenced action. =0A= =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 8]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= A minimal, but complete, implementation can respond with a single=0A= NOTIFY containing either the body: =0A= =0A= SIP/2.0 200 OK =0A= =0A= if the reference was successful or the body: =0A= =0A= SIP/2.0 503 Service Unavailable =0A= =0A= if the reference failed. =0A= =0A= An implementation MAY include more of a SIP message in that body = to=0A= convey more information. Warning headers received in responses to=0A= the referred action are good candidates. In fact, if the = reference=0A= was to a SIP URL, entire response to the referenced action could = be=0A= returned. However, doing so could have grave security = repercussions=0A= (see Section 3.10). Implementers must carefully consider what = they=0A= choose to include. =0A= =0A= Note that if the reference was to a non-SIP URL, status in any=0A= NOTIFYs to the referrer must still be in the form of SIP Response=0A= Status-Lines. The minimal implementation discussed above is=0A= sufficient to provide a basic indication of success or failure. = For=0A= example, if a client receives a REFER to a HTTP URL, and is=0A= successful in accessing the resource, its NOTIFY to the referrer = can=0A= contain the application/sip body of "SIP/2.0 200 OK" =0A= =0A= 3.7 Behavior of SIP Registrars/Redirect Servers=0A= =0A= Registrars and Redirect Servers SHOULD return a 603 to a REFER=0A= request, unless they are also playing some other SIP role. =0A= =0A= 3.8 Behavior of SIP Proxies=0A= =0A= SIP Proxies do not require modification to support the REFER = method.=0A= Specifically, as required by [1], a proxy should process a REFER=0A= request the same way it processes an OPTIONS request. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 9]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 3.9 Prototypical REFER callflow=0A= =0A= Agent A Agent B=0A= | |=0A= | REFER |=0A= |----------------------->|=0A= | 202 Accepted |=0A= |<-----------------------|=0A= | |=0A= | |------->=0A= | | (whatever)=0A= | |<------=0A= | |=0A= | NOTIFY |=0A= |<-----------------------|=0A= | 200 OK |=0A= |----------------------->|=0A= | |=0A= | |=0A= =0A= Here are examples of what the four messages between Agent A and=0A= Agent B might look like if the reference to (whatever) that Agent = B=0A= makes is successful: =0A= Message One =0A= =0A= REFER sip:b@agentland SIP/2.0=0A= Via: SIP/2.0/UDP agenta.agentland=0A= To: sip:b@agentland=0A= From: sip:a@agentland;tag=3D193402342=0A= Call-ID: 898234234@agenta.agentland=0A= CSeq: 93809823 REFER=0A= Refer-To: (whatever URL)=0A= Referred-By: ;ref=3D;=0A= scheme=3Dpgp;pgp-version=3D"5.0";signature=3D"signature goes = here"=0A= Contact: sip:a@agentland=0A= Content-Length: 0=0A= =0A= Message Two =0A= =0A= SIP/2.0 202 Accepted=0A= Via: SIP/2.0/UDP agenta.agentland=0A= To: sip:b@agentland;tag=3D4992881234=0A= From: sip:a@agentland;tag=3D193402342=0A= Call-ID: 898234234@agenta.agentland=0A= CSeq: 93809823 REFER=0A= Contact: sip:b@agentland=0A= Content-Length: 0=0A= =0A= Message Three =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 10]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= NOTIFY sip:a@agentland SIP/2.0=0A= Via: SIP/2.0/UDP agentb.agentland=0A= To: sip:a@agentland;tag=3D193402342=0A= From: sip:b@agentland;tag=3D4992881234=0A= Call-ID: 898234234@agenta.agentland=0A= CSeq: 1993402 NOTIFY=0A= Event: refer=0A= Contact: sip:b@agentland=0A= Content-Type: application/sip=0A= Content-Length: 16=0A= =0A= SIP/2.0 200 OK=0A= =0A= =0A= Message Four =0A= =0A= SIP/2.0 200 OK=0A= Via: SIP/2.0/UDP agentb.agentland=0A= To: sip:a@agentland;tag=3D193402342=0A= From: sip:b@agentland;tag=3D4992881234=0A= Call-ID: 898234234@agenta.agentland=0A= CSeq: 1993402 NOTIFY=0A= Contact: sip:a@agentland=0A= Content-Length: 0=0A= =0A= 3.10 Security Considerations=0A= =0A= The security requirements of [1] apply to the REFER method. =0A= =0A= This mechanism relies on providing contact information for the=0A= referred-to resource to the party being referred. Care should be=0A= taken to provide a suitably restricted URI if the referred to=0A= resource should be protected. =0A= =0A= Care should be taken when implementing the logic that determines=0A= whether or not to accept the REFER request. A UA not capable of=0A= accessing non-SIP URLs SHOULD NOT accept REFER requests to them. =0A= =0A= Using application/sip bodies to return the progress and results of = a=0A= REFER request is extremely powerful. Careless use of that = capability=0A= will compromise security and privacy. Here are a couple of = simple,=0A= somewhat contrived, examples to demonstrate the potential for harm. = =0A= =0A= 3.10.1 Circumventing privacy=0A= =0A= Suppose Alice has a user-agent that accepts REFER requests to SIP=0A= INVITE URLs, and NOTIFYs the referrer of the progress of the = INVITE=0A= by copying each response to the INVITE into the body of a NOTIFY. = =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 11]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= Suppose further that Carol has a reason to avoid Mallory and has=0A= configured her system at her proxy to only accept calls from a=0A= certain set of people she trusts (including Alice), so that = Mallory=0A= doesn't learn when she's around, or what user agent she's = actually=0A= using. =0A= =0A= Mallory can send a REFER to Alice, with a Refer-To: indicating=0A= Carol. If Alice can reach Carol, the 200 OK Carol sends gets=0A= returned to Mallory in a NOTIFY, letting him know not only that=0A= Carol is around, but also the IP address of the agent she's using. = =0A= =0A= 3.10.2 Circumventing security=0A= =0A= Suppose Alice, with the same user agent as above, is working at a=0A= company that is working on the greatest SIP device ever invented = -=0A= the SIP FOO. The company has been working for months building the=0A= device and the marketing materials, carefully keeping the idea, = even=0A= the name of the idea secret (since a FOO is one of those things = that=0A= anybody could do if they'd just had the idea first). FOO is up = and=0A= running, and anyone at the company can use it, but it's not=0A= available outside the company firewall. =0A= =0A= Mallory has heard rumor that Alice's company is onto something = big,=0A= and has even managed to get his hands on a URL that he suspects=0A= might have something to do with it. He sends a REFER to ALICE = with=0A= the mysterious URL and as Alice connects to the FOO, Mallory gets=0A= NOTIFYs with bodies containing =0A= =0A= Server: FOO/v0.9.7=0A= =0A= 3.10.3 Limiting the breach=0A= =0A= For each of these cases, and in general, returning a carefully=0A= selected subset of the information available about the progress = of=0A= the reference through the NOTIFYs mitigates risk. The minimal=0A= implementation described in Section 3.6.2.2 exposes the least=0A= information about what the agent operating on the REFER request = has=0A= done, and is least likely to be a useful tool for malicious users. = =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 12]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 4. Call Transfer=0A= =0A= 4.1 Actors and Roles=0A= =0A= There are three actors in a given transfer event, each playing = one=0A= of the following roles: =0A= =0A= Transferee - the party being transferred to the = Transfer=0A= Target.=0A= =0A= Transferor - the party initiating the transfer=0A= =0A= Transfer Target - the new party being introduced into a call = with=0A= the Transferee.=0A= =0A= The following roles are used to describe transfer requirements = and=0A= scenarios: =0A= =0A= Originator - wishes to place a call to the Recipient. This = actor=0A= is the source of the first INVITE in a session, = to=0A= either a Facilitator or a Screener.=0A= =0A= Facilitator - receives a call or out-of-band request from = the=0A= Originator, establishes a call to the = Recipient=0A= through the Screener, and connects the Originator = to=0A= the Recipient.=0A= =0A= Screener - receives a call ultimately intended for the = Recipient=0A= and transfers the calling party to the Recipient = if=0A= appropriate.=0A= =0A= Recipient - the party the Originator is ultimately connected = to.=0A= =0A= 4.2 Requirements=0A= 1. Any party in a SIP session MUST be able to transfer any other=0A= party in that session at any point in that session.=0A= 2. The Transferor and the Transferee MUST NOT be removed from a=0A= session as part of a transfer transaction.=0A= =0A= At first glance, requirement 2 may seem to indicate=0A= that the user experience in a transfer must be=0A= significantly different from what a current PBX or=0A= Centrex user expects. As the call-flows in this=0A= document show, this is not the case. A client MAY=0A= preserve the current experience. In fact, without=0A= this requirement, some forms of the current=0A= experience (ringback on unattended transfer failure=0A= for instance) will be lost.=0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 13]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 3. The Transferor MUST know whether or not the transfer was=0A= successful (this is significantly different from the=0A= requirements of draft-ietf-sip-cc-01).=0A= =0A= 4.3 Using REFER to achieve Call Transfer=0A= =0A= A REFER can be issued by the Transferor to cause the Transferee = to=0A= issue an INVITE to the Transfer-Target. Note that a successful = REFER=0A= transaction does not terminate the session between the Transferor=0A= and the Transferee. If those parties wish to terminate their=0A= session, they must do so with a subsequent BYE request. The media=0A= negotiated between the transferee and the transfer target is not=0A= affected by the media that had been negotiated between the=0A= transferor and the transferee. In particular, the INVITE issued = by=0A= the Transferee will have the same SDP body it would have if he=0A= Transferee had initiated that INVITE on its own. Further, the=0A= disposition of the media streams between the Transferor and the=0A= Transferee is not altered by the REFER method. Agents may alter a=0A= session's media through additional signaling. For example, they = may=0A= make use of the SIP hold re-INVITE [1] or the conferencing=0A= extensions provided by this framework. =0A= =0A= 4.4 Unattended Transfer=0A= =0A= Unattended Transfer consists of the Transferor providing the=0A= Transfer Target's contact to the Transferee. The Transferee = attempts=0A= to establish a session using that contact and reports the results = of=0A= that attempt to the Transferor. The signaling relationship = between=0A= the Transferor and Transferee is not terminated, so the call is=0A= recoverable if the Transfer Target cannot be reached. Note that = the=0A= Transfer Target's contact information has been exposed to the=0A= Transferee. The provided contact can be used to make new calls in=0A= the future. The diagrams below show indicate the first line of = each=0A= message. All messages in a particular diagram share the same=0A= Call-ID. In these diagrams, media is managed through reINVITE = holds,=0A= but other mechanisms (mixing multiple media streams at the UA or=0A= using the conferencing extensions for example) are valid. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 14]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 4.4.1 Successful Unattended Transfer=0A= =0A= Transferor Transferee Transfer=0A= | | Target=0A= | INVITE | |=0A= |<-------------------| |=0A= | 200 OK | |=0A= |------------------->| |=0A= | ACK | |=0A= |<-------------------| |=0A= | INVITE (hold) | |=0A= |------------------->| |=0A= | 200 OK | |=0A= |<-------------------| |=0A= | ACK | |=0A= |------------------->| |=0A= | REFER | |=0A= |------------------->| |=0A= | 202 Accepted | |=0A= |<-------------------| |=0A= | | INVITE |=0A= | |------------------->|=0A= | | 200 OK |=0A= | |<-------------------|=0A= | | ACK |=0A= | |------------------->|=0A= | NOTIFY (200 OK) | |=0A= |<-------------------| |=0A= | 200 OK | |=0A= |------------------->| |=0A= | BYE | |=0A= |------------------->| |=0A= | 200 OK | |=0A= |<-------------------| |=0A= | | BYE |=0A= | |<-------------------|=0A= | | 200 OK |=0A= | |------------------->|=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 15]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 4.4.2 Failed Unattended Transfer=0A= =0A= Transferor Transferee Transfer=0A= | | Target=0A= | | |=0A= | INVITE | |=0A= |<-------------------| |=0A= | 200 OK | |=0A= |------------------->| |=0A= | ACK | |=0A= |<-------------------| |=0A= | INVITE (hold) | |=0A= |------------------->| |=0A= | 200 OK | |=0A= |<-------------------| |=0A= | ACK | |=0A= |------------------->| |=0A= | REFER | |=0A= |------------------->| |=0A= | 202 Accepted | |=0A= |<-------------------| |=0A= | | INVITE |=0A= | |------------------->|=0A= | | 486 Busy Here |=0A= | |<-------------------|=0A= | | ACK |=0A= | |------------------->|=0A= | NOTIFY (503 Service Unavailable) |=0A= | or NOTIFY (486 Busy Here) |=0A= |<-------------------| |=0A= | 200 OK | |=0A= |------------------->| |=0A= | INVITE (unhold) | |=0A= |------------------->| |=0A= | 200 OK | |=0A= |<-------------------| |=0A= | ACK | |=0A= |------------------->| |=0A= | BYE | |=0A= |------------------->| |=0A= | 200 OK | |=0A= |<-------------------| |=0A= =0A= 4.5 Unattended Transfer with Consultation Hold=0A= =0A= Transfer with Consultation Hold involves a session between the=0A= transferor and the transfer target before the transfer actually=0A= takes place. This is implemented with SIP Hold and Unattended=0A= Transfer as described above. =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 16]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 4.5.1 Variation 1 : Exposes transfer target=0A= =0A= The transferor places the transferee on hold, establishes a call=0A= with the transfer target to alert them to the impending transfer,=0A= terminates the connection with the transfer target, then proceeds=0A= with unattended transfer as above. This variation can be used to=0A= provide an experience similar to that expected by current PBX and=0A= Centrex users. =0A= =0A= To (hopefully) improve clarity, non-REFER transactions have been=0A= collapsed into one indicator with the arrow showing the direction = of=0A= the request. =0A= =0A= Transferor Transferee Transfer=0A= | | Target=0A= | | |=0A= Call-ID:1 | INVITE/200 OK/ACK | |=0A= |<-------------------| |=0A= Call-ID:1 | INVITE (hold)/200 OK/ACK |=0A= |------------------->| |=0A= Call-ID:2 | INVITE/200 OK/ACK | |=0A= |---------------------------------------->|=0A= Call-ID:2 | BYE/200 OK | |=0A= |---------------------------------------->|=0A= Call-ID:1 | REFER | |=0A= |------------------->| |=0A= | 202 Accepted | |=0A= |<-------------------| |=0A= Call-ID:1 | | INVITE/200 OK/ACK |=0A= | |------------------->|=0A= Call-ID:1 | NOTIFY (200 OK) | |=0A= |<-------------------| |=0A= | 200 OK | |=0A= |------------------->| |=0A= Call-ID:1 | BYE/200 OK | |=0A= |------------------->| |=0A= Call-ID:1 | | BYE/200 OK |=0A= | |<-------------------|=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 17]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 4.5.2 Variation 2 : Protects transfer target=0A= =0A= The transferor places the transferee on hold, establishes a call=0A= with the transfer target and then reverses their roles, = transferring=0A= the original transfer target to the original transferee. This has=0A= the advantage of hiding information about the original transfer=0A= target from the original transferee. On the other hand, the=0A= Transferee's experience is different that in current systems. The=0A= Transferee is effectively "called back" by the Transfer Target. =0A= =0A= Transferor Transferee Transfer=0A= | | Target=0A= | | |=0A= Call-ID:1 | INVITE/200 OK/ACK | |=0A= |<-------------------| |=0A= Call-ID:1 | INVITE (hold)/200 OK/ACK |=0A= |------------------->| |=0A= Call-ID:2 | INVITE/200 OK/ACK | |=0A= |---------------------------------------->|=0A= Call-ID:2 | INVITE (hold)/200 OK/ACK |=0A= |---------------------------------------->|=0A= Call-ID:2 | REFER | |=0A= |---------------------------------------->|=0A= | 202 Accepted | |=0A= |<----------------------------------------|=0A= Call-ID:2 | | INVITE/200 OK/ACK |=0A= | |<-------------------|=0A= Call-ID:2 | NOTIFY (200 OK) | |=0A= |<----------------------------------------|=0A= | | 200 OK |=0A= |---------------------------------------->|=0A= Call-ID:1 | BYE/200 OK | |=0A= |------------------->| |=0A= Call-ID:2 | BYE/200 OK | |=0A= |---------------------------------------->|=0A= Call-ID:2 | | BYE/200 OK |=0A= | |------------------->|=0A= =0A= 4.5.3 Consultation Hold in the presence of forking proxies=0A= =0A= It is worth noting that the examples given above abstract away = any=0A= proxies that might be between the three parties. In 4.5.1 for=0A= example, the URL used to reach the Transfer Target may go through = a=0A= forking proxy. There is no guarantee that the Transferee's and=0A= Transferor's invitations to the Transfer Target will reach the = same=0A= endpoint. If the proxy forked in parallel, both invitations could=0A= cause multiple endpoints to ring. To increase the probability of = the=0A= desired behavior of having the referred invite reach and ring = only=0A= the same endpoint as the consultation invite, the Transferor = SHOULD=0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 18]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= issue the REFER request with the Refer-To: header containing the=0A= Contact the Transfer Target provided in its 200 OK to the=0A= Transferor's INVITE. If that REFER fails, the Transferor SHOULD=0A= issue another REFER with the Refer-To: header containing the URL = it=0A= used to reach the Transfer Target, augmented with an = Accept-Contact=0A= header containing the Contact the Transfer Target provided. =0A= =0A= 4.6 Attended Transfer=0A= =0A= In an attended transfer, the three actors participate in an = ad-hoc=0A= conference as part of the event. Discussion of the implementation = of=0A= attended transfer is thus deferred until the conferencing portion = of=0A= the Call Control framework has been addressed. =0A= =0A= 4.7 Transfer with multiple parties=0A= =0A= In this example the Originator places call to the Facilitator who=0A= reaches the Recipient through the Screener. The Recipient's = contact=0A= information is exposed to the Facilitator and the Originator. = This=0A= example is provided for clarification of the semantics of the = REFER=0A= method only and should not be used as the design of an=0A= implementation. =0A= =0A= Originator Facilitator Screener Recipient=0A= Call-ID | | | |=0A= 1 |INVITE/200 OK/ACK | |"Get Fred for = me!"=0A= |----------->| | | "Right = away!"=0A= 1 |INVITE (hold)/200 OK/ACK | |=0A= |<-----------| | |=0A= 2 | |INVITE/200 OK/ACK |"I have a = call=0A= | |----------->| |from Mary for = Fred"=0A= 2 | |INVITE (hold)/200 OK/ACK "Hold = please"=0A= | |<-----------| |=0A= 3 | | |INVITE/200 OK/ACK=0A= | | |--------->|"You have a = call=0A= | | | |from Mary"=0A= | | | | "Put her = through"=0A= 3 | | |INVITE (hold)/200 OK/ACK=0A= | | |--------->|=0A= 2 | |REFER | |=0A= | |<-----------| |=0A= | |202 Accepted| |=0A= | |----------->| |=0A= 2 | |INVITE/200 OK/ACK |=0A= | |---------------------->|"This is = Fred"=0A= 2 | |NOTIFY (200 OK) | "Please hold = for=0A= | |----------->| | = Mary"=0A= | |200 OK | |=0A= | |<-----------| |=0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 19]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= 2 | |BYE/200 OK | |=0A= | |<-----------| |=0A= 3 | | |BYE/200 OK|=0A= | | |--------->|=0A= 2 | |INVITE (hold)/200 OK/ACK=0A= | |---------------------->|=0A= 1 |REFER | | |=0A= |<-----------| | |=0A= |202 Accepted| | |=0A= |----------->| | |=0A= 1 |INVITE/200 OK/ACK | |=0A= |----------------------------------->| "Hey Fred"=0A= 1 |NOTIFY (200 OK) | | "Hello = Mary"=0A= |----------->| | |=0A= |200 OK | | |=0A= |<-----------| | |=0A= 1 |BYE/200 OK | | |=0A= |<-----------| | |=0A= 2 | |BYE/200 OK | |=0A= | |---------------------->|=0A= 1 |BYE/200 OK | | |=0A= |<-----------------------------------| "See you = later"=0A= =0A= 5. Open Issues=0A= =0A= 5.1 REFER is now dependent on sip-events=0A= =0A= By introducing NOTIFY, this work is prevented from moving to RFC=0A= until the sip-events draft moves to that level (that work is=0A= currently an individual submission). What needs to happen to our=0A= deliverable schedule to allow for completing the sip-events work? = =0A= =0A= 5.2 Registering the events with IANA=0A= =0A= When we near the end of the process, the refer event will need to = be=0A= registered with IANA per [3].=0A= =0A= 6. Acknowledgments=0A= =0A= This draft is a collaborative product of the SIP working group. = The=0A= editor thanks the following for their early contributions to this=0A= work: Ben Campbell, Chris Cunningham, Steve Donovan, Alan = Johnston,=0A= Kevin Summers and Dean Willis. =0A= =0A= References=0A= =0A= [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,=0A= "SIP: Session Initiation Protocol", RFC 2543, March 1999.=0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 20]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= [2] Campbell, B., "Framework for SIP Call Control Extensions",=0A= draft-ietf-sip-cc-framework-00 (work in progress), March = 2000.=0A= =0A= [3] Roach, A., "Event Notification in SIP",=0A= draft-roach-sip-subscibe-notify-03 (work in progress), = February=0A= 2001.=0A= =0A= [4] Schulzrinne, H. and J. Rosenberg, "SIP Call Control = Services",=0A= draft-ietf-sip-cc-01 (work in progress - expired), June = 1999.=0A= =0A= =0A= Author's Address=0A= =0A= Robert J. Sparks=0A= dynamicsoft=0A= 5100 Tennyson Parkway=0A= Suite 1200=0A= Plano, TX 75024=0A= =0A= email: rsparks@dynamicsoft.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 21]=0A= =0C=0A= Internet-Draft SIP Call Control - Transfer February = 2001=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2001). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished = to=0A= others, and derivative works that comment on or otherwise explain = it=0A= or assist in its implementation may be prepared, copied, = published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph=0A= are included on all such copies and derivative works. However, = this=0A= document itself may not be modified in any way, such as by = removing=0A= the copyright notice or references to the Internet Society or = other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other = than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not = be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on = an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Acknowledgement=0A= =0A= Funding for the RFC editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Sparks Expires August 27, 2001 [Page = 22]=0A= =0C=0A= ------_=_NextPart_000_01C0A009.B7F82508-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 10:37:47 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12802 for ; Mon, 26 Feb 2001 10:37:46 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7EBCE44396; Mon, 26 Feb 2001 10:34:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 9D37D44385 for ; Mon, 26 Feb 2001 10:33:20 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 26 Feb 2001 15:33:19 UT Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id PAA22158; Mon, 26 Feb 2001 15:32:08 GMT From: Gethin Liddell Organization: Ubiquity Software To: Juha Heinanen Subject: Re: [SIP] confusion in url comparison X-Mailer: KMail [version 1.1.99] Content-Type: text/plain; charset="us-ascii" Cc: sip@lists.bell-labs.com References: <200102261307.f1QD7PU14246@lohi.eng.telia.fi> <3A9A72DA.A374709D@ubiquity.net> In-Reply-To: <3A9A72DA.A374709D@ubiquity.net> MIME-Version: 1.0 Message-Id: <01022615355000.03296@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 15:35:50 +0000 Content-Transfer-Encoding: 8bit I believe the confusion is over the last line of the paragraph: "Components not found in both URLs being compared are ignored." What this is supposed to mean (I think) is that parameters without default values such as maddr-param or *future-parameters* should be ignored if they only exist in one sip url: e.g. the following are equivalent: sip:gethin@ubiquity.net;transport=UDP sip:gethin@ubiquity.net sip:gethin@ubiquity.net;maddr=sip.mcast.net;foo=bar but not these: sip:gethin@ubiquity.net;transport=TCP sip:gethin@ubiquity.net I do however think that this should be re-fined for parameters that are not known about. for example it is impossible for a server to make a correct decision on the equality of two unknown parameters e.g. is sip:gethin@ubiquity.net;foo=BAR equivalent to sip:gethin@ubiquity.net;foo=bar IMHO I believe that unknown parameters should be ignored when doing a comparison. This confusion isn't helped by the incomplete examples given in the latest bis, though i believe these have been correct ed for the next release. On Monday 26 February 2001 15:14, Neil Deason wrote: > Juha Heinanen wrote: > > there is an uncertainty between some vendors if the two sip urls > > > > sip:foo@bar.com > > sip:foor@bar.com;user=phone > > > > should be considered to match, when the urls appear in to or from > > fields. > > > > according to the text of section 2.1 they seem to match, since it says > > > > o user or telephone-subscriber, password, host, port and any > > url-parameter parameters of the URI must match. If a component is > > omitted, it matches based on its default value. (For example, otherwise > > equivalent URLs without a port specification and with port 5060 match.) > > Components not found in both URLs being compared are ignored. > > > > thus in the comparison, user=phone is ignored. > > No, if a componment is omitted it matches on it's default > value. Table 2 defines the default value for user-param as > 'ip' not 'phone'. > > > but this doesn't really > > make sense, since according to table 2, the only mandatory component in > > to and from fields is host. thus also the two urls > > > > sip:bar.com > > sip:foor@bar.com;user=phone > > > > would match. so it looks to me like section 2.1 would require some > > rewording. > > These don't match either - the user part is still significant > in the comparison despite being omitted from one URL. > > Cheers, > Neil -- Gethin Liddell Ubiquity Software Corp. Ubiquity House Langstone Park NP6 2LH UK Tel: 44 (0) 1633 765600 Fax: 44 (0) 1633 765601 URL: www.ubiquity.net _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 10:42:19 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12984 for ; Mon, 26 Feb 2001 10:42:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 53ECD44387; Mon, 26 Feb 2001 10:42:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id E6B6244362 for ; Mon, 26 Feb 2001 10:41:13 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1QFf6r01439; Mon, 26 Feb 2001 09:41:06 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f1QFf6324462; Mon, 26 Feb 2001 09:41:06 -0600 (CST) Received: from ericsson.com (pc050151.exu.ericsson.se [138.85.50.151]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA06883; Mon, 26 Feb 2001 09:41:05 -0600 (CST) Message-ID: <3A9A7830.2000203@ericsson.com> From: Sean Olson Organization: Ericsson Inc. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: Neil Deason , "Arnoud van Wijk (ELN)" , sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: <7BA41B5547CCD411833B0002A52CD457D5105B@enlrynt306.etm.ericsson.se> <3A9A5494.A5408430@ubiquity.net> <3A9A626D.E83DFE3@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 09:37:20 -0600 Content-Transfer-Encoding: 7bit I hope I can clarify this a bit. First, the goal is not to hide the address of the endpoint. The goal is to hide the capacity of the core or internal network. That is, the number of SIP servers in a given domain. This information is seen as a competitive advantage in the wireless arena. In 3GPP, there are essentially three SIP "servers": A Proxy CSCF (Call Session Control Function) which sits on the border between the access network and the core network, the Interrogating CSCF (I-CSCF) that sits on the border between two operator's network, and a serving CSCF (S-CSCF) that is the real SIP server for a subscriber. The goal is to hide the number of S-CSCFs in an operator's network. To do this, the I-CSCF is being tasked with this Via: hiding function. Hope this helps somewhat, sean Henning G. Schulzrinne wrote: >> I think the motivation in 3GPP is more to do with providers >> hiding internal network topography rather than the fact >> signalling ever passed through them. > > > Why hiding the IP addresses or names of servers is of any value has > always baffled me. This strikes me as having no security value, but > making diagnosis of problems that much more difficult. After all, nobody > (except spammers) worries about "exposing the topology of email servers" > and does Received header hiding (I hope...). I think rather than rolling > over and saying "3GPP must know best", some effort at education should > be made by those active in that community. This strikes me as a > requirement where the best approach is to say "you really don't want to > do this" rather than devising ever more ingenious and complicated ways > to pursue the elusive goal of address hiding. If you truly want to hide > the IP address of the end system (for which arguments can be made, as > that address may reveal location information), you'll need some form of > B2B UA, with media handling. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 10:52:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13291 for ; Mon, 26 Feb 2001 10:52:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1B5D844398; Mon, 26 Feb 2001 10:52:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 939FB443A2 for ; Mon, 26 Feb 2001 10:45:43 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA04623; Mon, 26 Feb 2001 10:45:40 -0500 (EST) Message-ID: <3A9A7A24.B3125BE3@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: <7BA41B5547CCD411833B0002A52CD457D5105B@enlrynt306.etm.ericsson.se> <3A9A5494.A5408430@ubiquity.net> <3A9A626D.E83DFE3@cs.columbia.edu> <3A9A7830.2000203@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 10:45:40 -0500 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > I hope I can clarify this a bit. First, the goal > is not to hide the address of the endpoint. The > goal is to hide the capacity of the core or internal > network. That is, the number of SIP servers in a > given domain. This information is seen as a competitive > advantage in the wireless arena. > > In 3GPP, there are essentially three SIP "servers": > A Proxy CSCF (Call Session Control Function) which > sits on the border between the access network and the > core network, the Interrogating CSCF (I-CSCF) that > sits on the border between two operator's network, > and a serving CSCF (S-CSCF) that is the real SIP server > for a subscriber. The goal is to hide the number of > S-CSCFs in an operator's network. To do this, the > I-CSCF is being tasked with this Via: hiding function. Again, this seems a peculiar notion of sensitive information. Since adding a server costs 1U and $3k, it doesn't seem like that this is a good indicator of the number of customers or anything else. Why would this matter any more than me finding out that AOL has 4 servers for inbound email: host -t mx aol.com aol.com MX 15 mailin-01.mx.aol.com aol.com MX 15 mailin-02.mx.aol.com aol.com MX 15 mailin-03.mx.aol.com aol.com MX 15 mailin-04.mx.aol.com Or that I can analyze a bunch of email messages from AOL and find out which servers generate my inbound email? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 10:52:28 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13315 for ; Mon, 26 Feb 2001 10:52:28 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 44AA744362; Mon, 26 Feb 2001 10:44:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 1ADAC44355 for ; Mon, 26 Feb 2001 10:43:46 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1QFhgr02905; Mon, 26 Feb 2001 09:43:42 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f1QFhg325033; Mon, 26 Feb 2001 09:43:42 -0600 (CST) Received: from ericsson.com (pc050151.exu.ericsson.se [138.85.50.151]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA07072; Mon, 26 Feb 2001 09:43:41 -0600 (CST) Message-ID: <3A9A78CC.2050802@ericsson.com> From: Sean Olson Organization: Ericsson Inc. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: "Arnoud van Wijk (ELN)" , sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: <7BA41B5547CCD411833B0002A52CD457D5105B@enlrynt306.etm.ericsson.se> <3A9A5494.A5408430@ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 09:39:56 -0600 Content-Transfer-Encoding: 7bit Via: "hiding" as it is being defined for 3GPP is much different than the Via: hiding that was in the bis draft. In 3GPP, we are not asking the next hop to hide our Via: headers for us. Instead a node is being given the job to hide the Via: headers of outgoing requests and "un-hide" ( I'm trying to avoid the term decrypt :) the Via: headers for inbound responses. None of the problems that exist for the 2543 mechanism of Via: hiding apply in this case. /sean Neil Deason wrote: > "Arnoud van Wijk (ELN)" wrote: > >> Hello everybody. >> I have the following question. >> When a SIP server receives a SIP message, it will insert itself into the VIA header en most likely also encrypt it. >> Is there a consensus or "rule" to say that the border (proxy) SIP server of a network (the first SIP proxy of a network where external SIP messages enter the network before getting forwarded to other SIP servers inside the network)is not allowed to encrypt the VIA header? > > > In a 3GPP network encryption of Via headers may be likely, > in RFC2453bis based one it isn't. Remember Via hiding was > removed from the bis 02 spec due to concerns that it: > > - interferes with loop detection > - operates on a trust model > - is widely ignored in implementations > > Also network information is not just revealed in Vias but > can also appear in Record-Route, Route, SDP and any SIP > URLs. (Path header too if this is used by 3GPP). > > >> My undestanding is that the VIA header encryption is desired to prevent others to read the internal SIP traffic pathway of a network. By encrypting all the VIA headers but the top most one by a bordering SIP proxy should be enough. (the top most header is the proxy itself in this case). >> >> Why? >> >> In this way, we can identify a network domain via the bordering proxies. Asuming that those proxies do not encrypt the VIA header after adding themself into the VIA header. This can be useful if a certain network is spanned over 6 seperate domains. > > > I think the motivation in 3GPP is more to do with providers > hiding internal network topography rather than the fact > signalling ever passed through them. > > Cheers, > Neil. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 10:57:04 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13412 for ; Mon, 26 Feb 2001 10:57:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E55E3443B9; Mon, 26 Feb 2001 10:52:31 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 52495443AC for ; Mon, 26 Feb 2001 10:50:18 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA07676 for ; Mon, 26 Feb 2001 10:53:28 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 10:52:52 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F304761E@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] REFER revision MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 10:52:51 -0500 It's been suggested that the referenced-url parameter to the Referred-By: header should be optional if the header does not contain a signature. Currently, the syntax is Referred-By = ("Referred-By" | "b") ":" referrer-url ";" ( referenced-url | ( referenced-url ";" ref-signature ) | ( ref-signature ";" referenced-url ) ) The minimal form is Referred-By = "b" ":" referrer-url ";" referenced-url The referenced-url was originally included in the header to make verifying the signature possible (it MUST be there if a signature is present), but without a signature it has only informational value. So, would the following be acceptable? Referred-By = ("Referred-By" | "b") ":" referrer-url ";" [( referenced-url | ( referenced-url ";" ref-signature ) | ( ref-signature ";" referenced-url ) )] RjS _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 10:58:39 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13493 for ; Mon, 26 Feb 2001 10:58:38 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D7A42443AF; Mon, 26 Feb 2001 10:52:19 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 613BB443A3 for ; Mon, 26 Feb 2001 10:48:22 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1QFmLC09408 for ; Mon, 26 Feb 2001 16:48:21 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Mon Feb 26 16:48:20 2001 +0100 Received: by esealnt746.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Mon, 26 Feb 2001 16:47:21 +0100 Message-ID: <7BA41B5547CCD411833B0002A52CD457D51060@enlrynt306.etm.ericsson.se> From: "Arnoud van Wijk (ELN)" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Multiple SIP URLS for same proxy server. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 16:48:19 +0100 Hello everybody. A SIP proxy can be addressed with a SIP URL, and via the URL the IP address can be found. If I am a crazy network provider who wants to give the same SIP Proxy server different SIP URLS, i.e. pegasus@amcrazy.net solstice@amcrazy.net 666@devil.com etc. This should be possible as long that the domains and names are owned by me. In this case if solstice@amcrazy.net is looked up..the IP address will be located, which is the same one if 666@devil.com is looked up. So, as long that the SIP Proxy server registers all the SIP URLs at the registrars. This should be possible to pull off. Is that right? Or am I forgetting something? Has this already been looked at and perhaps decreed as an illegal act? (like registrar only allowing the newest registration with the same IP address) Thanks for your time Greetings Arnoud van Wijk _______________________________________________________________ ERICSSON EUROLABS NETHERLANDS BV Arnoud van Wijk Research & Development (ELN/V) Fax: +31-161 247569 _______________________________________________________________ _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 11:04:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14003 for ; Mon, 26 Feb 2001 11:04:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7FC164438A; Mon, 26 Feb 2001 11:04:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id CEC3F443B7 for ; Mon, 26 Feb 2001 10:58:44 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id <1GB0WLWF>; Mon, 26 Feb 2001 07:56:49 -0800 Received: from rwcjfmule01 (adsl-216-103-84-208.dsl.snfc21.pacbell.net [216.103.84.208]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GB0WLW1; Mon, 26 Feb 2001 07:56:45 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Christer Holmberg'" , "'Flemming Andreasen'" Cc: sip@lists.bell-labs.com, Jieying Li Subject: RE: [SIP] T.38 and multiple streams Message-ID: <016e01c0a00c$cbd92030$e54b010a@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A97BD07.DFBF5893@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 07:57:16 -0800 Content-Transfer-Encoding: 7bit Hold on: This thread is going in every directions. First and starting now, please mention references when you state things like: > I guess there are reasons for this. One is that it is recommended that > you use TCP for fax First, t.38 recommendation is clear: either TCP or UDP. So I disagree on that statement. Second, we had polled the implementors when doing imtc inow profiles and the response was clear for gw vendors: UDP. Third, ultimately, vendors should support both and the internet-draft does not prevent TCP at all. So let's leave this out of the discussion. Jean-Francois. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Saturday, February 24, 2001 5:54 AM > To: Flemming Andreasen > Cc: Culpepper, Bert; Jean-Francois Mule; sip@lists.bell-labs.com; > stanley.khouw@clarent.com; jieying.li@claren.com > Subject: Re: [SIP] T.38 and multiple streams > > > > Hi, > > Flemming Andreasen wrote: > > > >Joining in a bit late here, but in any case: > > > >Fundamentally, I don't understand why you view this as two > separate media > >streams. > > I guess there are reasons for this. One is that it is recommended that > you use TCP for fax, and since you use RTP/UDP for voice you will have > to use separate streams. I mean, you can modify the codecs > you use for a > stream etc, but I don't think you can modify a single stream > from UDP to > TCP... > > >You are muting one when you want to use the other, so why > have two in the first place ? > > You want to continue the voice session after the fax has been sent, so > by keeping the voice stream during the fax transmissoion you > don't have > to create a new voice stream after the fax, just "un-mute" > the existing > one. > > >Also note, that there may be some undesirable QoS > interactions that way. > > > >A couple of more specific comments on the current draft, > some of which you > >may have already gotten: > > - T.30 CED is the same as as V.25 ANS and hence cannot be > used as a fax > > detection mechanism (the V.21 fax preamble is fine). > > - Why must CNG tone detection not lead to a switch to T.38 ? > > There are different way to detect a fax. The flows would be different > for all cases, and for interop issues you would have to > implement all of > them. That is the reason why one mechanism was chosen. > > Regards, > > Christer Holmberg > Ericsson Finland > > > > > > > - SIP call flow should probably include a Contact header > resulting in some > > of > > your messages (e.g. ACK) going end-to-end rather than > through the proxy). > > - Section 4.1 mentions that different UDP ports are to be > used where as > > Section > > 6.2 lists that as open issue. I agree with Section 6.2 and > would leave that > > choice to the gateways. > > > > Regards > > > > Flemming > > > > "Culpepper, Bert" wrote: > > > > > snip > > > > > > > >>I prefer the second option (no general c= line, one c= line > > > > per media > > > > >>description). Shall we recommend this second option in the > > > > >>updated paper? > > > > > > > > > >I prefer the second option too. c= lines in the media > descriptions > > > > >are required when a session has more than one media stream and > > > > >they need to be controlled independently. > > > > > > > > I guess this also depends on what the SDP standard > says. For example, > > > > when we > > > > establish the call for voice, we probably will have a > general c= line. > > > > Is it then allowed, in the re-INVITE, to remove that > and then suddenly > > > > insert the c= for the media description? > > > > > > > > > > >From my reading of RFC 2327 (SDP standard) I don't see a problem > > > with this. But it doesn't concern itself with a SIP > reINVITE. I don't > > > remember seeing this detail discussed in the SIP RFC or > bis either. > > > I also don't believe it necessarily needs to be discussed > in the bis. > > > However, I can understand an implementation having a > problem with this. > > > But it's an implementation thing. A robust > implementation (one that > > > realizes not all media streams may go to the same > destination) should > > > handle this IMO. > > > > > > snip > > > > > > regards, > > > Bert > > > > > > _______________________________________________ > > > This list is for continuing development of the SIP protocol. > > > The sip-implementor's list is the place to discuss implementation, > > > and to receive advice on understanding existing sip. > > > To subscribe to it, send mail to > > > sip-implementors-request@cs.columbia.edu with "subscribe" > in the body. > > > > -- > > Flemming Andreasen > > Cisco Systems > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 11:35:47 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15401 for ; Mon, 26 Feb 2001 11:35:47 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3354344385; Mon, 26 Feb 2001 11:35:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id DBC15443BF for ; Mon, 26 Feb 2001 11:19:37 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 26 Feb 2001 16:19:36 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA12670; Mon, 26 Feb 2001 16:18:29 GMT Message-ID: <3A9A81D5.637B07A8@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: <7BA41B5547CCD411833B0002A52CD457D5105B@enlrynt306.etm.ericsson.se> <3A9A5494.A5408430@ubiquity.net> <3A9A78CC.2050802@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 16:18:29 +0000 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > Via: "hiding" as it is being defined for 3GPP is much different > than the Via: hiding that was in the bis draft. In 3GPP, > we are not asking the next hop to hide our Via: headers > for us. Instead a node is being given the job to hide > the Via: headers of outgoing requests and "un-hide" ( > I'm trying to avoid the term decrypt :) the Via: headers > for inbound responses. None of the problems that exist > for the 2543 mechanism of Via: hiding apply in this case. I would have thought some of them could still apply: - prevention of fault diagnosis - complexity overhead - interference with loop detection Isn't there is also still a trust issue of sorts if you expect another node to hide your entry in the Via headers for you. I guess it is too early to say on implementations ignoring it ;) Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net > /sean > > Neil Deason wrote: > > > "Arnoud van Wijk (ELN)" wrote: > > > >> Hello everybody. > >> I have the following question. > >> When a SIP server receives a SIP message, it will insert itself into the VIA header en most likely also encrypt it. > >> Is there a consensus or "rule" to say that the border (proxy) SIP server of a network (the first SIP proxy of a network where external SIP messages enter the network before getting forwarded to other SIP servers inside the network)is not allowed to encrypt the VIA header? > > > > > > In a 3GPP network encryption of Via headers may be likely, > > in RFC2453bis based one it isn't. Remember Via hiding was > > removed from the bis 02 spec due to concerns that it: > > > > - interferes with loop detection > > - operates on a trust model > > - is widely ignored in implementations > > > > Also network information is not just revealed in Vias but > > can also appear in Record-Route, Route, SDP and any SIP > > URLs. (Path header too if this is used by 3GPP). > > > > > >> My undestanding is that the VIA header encryption is desired to prevent others to read the internal SIP traffic pathway of a network. By encrypting all the VIA headers but the top most one by a bordering SIP proxy should be enough. (the top most header is the proxy itself in this case). > >> > >> Why? > >> > >> In this way, we can identify a network domain via the bordering proxies. Asuming that those proxies do not encrypt the VIA header after adding themself into the VIA header. This can be useful if a certain network is spanned over 6 seperate domains. > > > > > > I think the motivation in 3GPP is more to do with providers > > hiding internal network topography rather than the fact > > signalling ever passed through them. > > > > Cheers, > > Neil. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 11:43:16 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15712 for ; Mon, 26 Feb 2001 11:43:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F67644391; Mon, 26 Feb 2001 11:17:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 193C144388 for ; Mon, 26 Feb 2001 11:11:22 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA06603; Mon, 26 Feb 2001 11:11:20 -0500 (EST) Message-ID: <3A9A8029.D51B55D1@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks Cc: sip@lists.bell-labs.com Subject: Re: [SIP] REFER revision References: <9BF66EBF6BEFD942915B4D4D45C051F304761E@DYN-TX-EXCH-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 11:11:21 -0500 Content-Transfer-Encoding: 7bit Robert Sparks wrote: > > It's been suggested that the referenced-url parameter to the > Referred-By: header should be optional if the header does not > contain a signature. Minor remark: I find the syntax description for this header very hard to parse. Having ";" outside the parameter description is odd. Also, we never specify all permutations of orderings, as they are all equivalent (i.e., ordering within a list of semicolon parameters never matters). How about some variation on Referred-By = ("Referred-By" | "b") ":" referrer-url [ referenced-URL ] referrer-url = ( name-addr | addr-spec ) referenced-url = ";" ref" "=" "<" URL ">" [ ref-signature ] ref-signature = ";" signature-scheme *( sig-scheme-params ) signature-scheme = ";" "scheme" "=" token sig-scheme-parms = ";" token "=" ( token | quoted-string ) (actually, the sig-scheme-parameter is just a generic parameter, so no need to define it again here.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 11:43:29 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15732 for ; Mon, 26 Feb 2001 11:43:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DC938443C0; Mon, 26 Feb 2001 11:36:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by lists.bell-labs.com (Postfix) with ESMTP id B182D443C8 for ; Mon, 26 Feb 2001 11:35:28 -0500 (EST) Received: from oleane (dyn-1-1-082.Vin.dialup.oleane.fr [195.25.4.82]) by smtp4.cluster.oleane.net with SMTP id f1QGZQu07293 for ; Mon, 26 Feb 2001 17:35:27 +0100 (CET) Message-ID: <009b01c0a012$28d9ed00$8001a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01C0A01A.8875F6C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SIP] IPCN 2001 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 17:35:38 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_0098_01C0A01A.8875F6C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Building and designing all-IP cellular networks: IPCN 2001 (IP-based = Cellular Networks) will take place in Paris on May 15 to 18: http://www.upperside.fr/baipcn2001.htm ------=_NextPart_000_0098_01C0A01A.8875F6C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Building and designing all-IP cellular = networks:=20 IPCN 2001  (IP-based Cellular Networks) will take = place in=20 Paris on May 15 to 18:
http://www.upperside.fr/b= aipcn2001.htm
------=_NextPart_000_0098_01C0A01A.8875F6C0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 11:46:18 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15817 for ; Mon, 26 Feb 2001 11:46:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 23B4D44393; Mon, 26 Feb 2001 11:44:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id BC44A443CE for ; Mon, 26 Feb 2001 11:37:16 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1QGbCr15368; Mon, 26 Feb 2001 10:37:12 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f1QGbC311592; Mon, 26 Feb 2001 10:37:12 -0600 (CST) Received: from ericsson.com (pc050151.exu.ericsson.se [138.85.50.151]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA10505; Mon, 26 Feb 2001 10:37:12 -0600 (CST) Message-ID: <3A9A8553.7020607@ericsson.com> From: Sean Olson Organization: Ericsson Inc. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: <7BA41B5547CCD411833B0002A52CD457D5105B@enlrynt306.etm.ericsson.se> <3A9A5494.A5408430@ubiquity.net> <3A9A78CC.2050802@ericsson.com> <3A9A81D5.637B07A8@ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 10:33:23 -0600 Content-Transfer-Encoding: 7bit Neil Deason wrote: > Sean Olson wrote: > >> Via: "hiding" as it is being defined for 3GPP is much different >> than the Via: hiding that was in the bis draft. In 3GPP, >> we are not asking the next hop to hide our Via: headers >> for us. Instead a node is being given the job to hide >> the Via: headers of outgoing requests and "un-hide" ( >> I'm trying to avoid the term decrypt :) the Via: headers >> for inbound responses. None of the problems that exist >> for the 2543 mechanism of Via: hiding apply in this case. > > > I would have thought some of them could still apply: > - prevention of fault diagnosis This doesn't prevent the diagnosis of faults. It isolates the fault diagnosis to the operator in which the fault occurs. > - complexity overhead There is more complexity involved. Add any feature and you add complexity. The question is whether the complexity is worth it. > - interference with loop detection Loop detection still works fine. Your Via: will always appear in the clear to you. Complex looping scenarios between operators may still cause problems. This is less likely with the 3GPP architecture, but is something to consider. > Isn't there is also still a trust issue of sorts if you > expect another node to hide your entry in the Via headers > for you. I guess it is too early to say on implementations > ignoring it ;) There is a trust relationship. This relationship is well defined in the 3GPP architecture and is in fact completely internal to a single operator's network. The big difference between the 3GPP mechanism and the mechanism that exists in 2543 is that there is nothing in the SIP message that is being used to signal to another SIP server that you wish for it to hide your Via:'s. There exists a priori a trust relationship between the two nodes. The hiding of Via:'s is in fact completely transparent to both inbound traffic and outbound traffic. Basically, there is a special purpose proxy that is providing this functionality. That functionality is guaranteed to be there by virtue of the architecture -- there is no concern that the next hop can't provide the necessary hiding functionality. > > Cheers, > Neil. Cheers! /sean _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 11:48:35 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15904 for ; Mon, 26 Feb 2001 11:48:34 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 42A424434E; Mon, 26 Feb 2001 11:45:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 194014438F for ; Mon, 26 Feb 2001 11:44:06 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 26 Feb 2001 16:44:05 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA22145; Mon, 26 Feb 2001 16:42:59 GMT Message-ID: <3A9A8793.9529C0AD@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: <7BA41B5547CCD411833B0002A52CD457D5105B@enlrynt306.etm.ericsson.se> <3A9A5494.A5408430@ubiquity.net> <3A9A626D.E83DFE3@cs.columbia.edu> <3A9A7830.2000203@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 16:42:59 +0000 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > I hope I can clarify this a bit. First, the goal > is not to hide the address of the endpoint. The > goal is to hide the capacity of the core or internal > network. That is, the number of SIP servers in a > given domain. This information is seen as a competitive > advantage in the wireless arena. > > In 3GPP, there are essentially three SIP "servers": > A Proxy CSCF (Call Session Control Function) which > sits on the border between the access network and the > core network, the Interrogating CSCF (I-CSCF) that > sits on the border between two operator's network, > and a serving CSCF (S-CSCF) that is the real SIP server > for a subscriber. The goal is to hide the number of > S-CSCFs in an operator's network. To do this, the > I-CSCF is being tasked with this Via: hiding function. From what I have seen of the 3GPP docs it appears there could be the potential for a lot of state information being stored in these servers. P-CSCFs might be expected to maintain mappings of hidden/unhidden Vias, user registrations, session signalling paths and even individual call path info (when they strip out all Via headers before passing INVITEs to called parties)? This type of behaviour means you lose the scalability and reliability features for network servers that were intended with SIP. Is there not the case for at least a more DCS-like approach where you at least store state info that you really need in the UEs. The revised Record-Route text means you wouldn't even need a State header extension. I appreciate that there could be issues with storing information in the UAs/UEs and retransmitting it over an air interface, but if bandwidth is the over riding concern for you SIP is not the best protocol to choose in the first place. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 11:55:15 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16172 for ; Mon, 26 Feb 2001 11:55:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C68BC4438F; Mon, 26 Feb 2001 11:55:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 5004C443CB for ; Mon, 26 Feb 2001 11:51:33 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 26 Feb 2001 16:51:32 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA26345; Mon, 26 Feb 2001 16:50:25 GMT Message-ID: <3A9A8951.ECA2459A@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: <7BA41B5547CCD411833B0002A52CD457D5105B@enlrynt306.etm.ericsson.se> <3A9A5494.A5408430@ubiquity.net> <3A9A78CC.2050802@ericsson.com> <3A9A81D5.637B07A8@ubiquity.net> <3A9A8553.7020607@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 16:50:25 +0000 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > Neil Deason wrote: > > > Sean Olson wrote: > > > >> Via: "hiding" as it is being defined for 3GPP is much different > >> than the Via: hiding that was in the bis draft. In 3GPP, > >> we are not asking the next hop to hide our Via: headers > >> for us. Instead a node is being given the job to hide > >> the Via: headers of outgoing requests and "un-hide" ( > >> I'm trying to avoid the term decrypt :) the Via: headers > >> for inbound responses. None of the problems that exist > >> for the 2543 mechanism of Via: hiding apply in this case. > > > > > > I would have thought some of them could still apply: > > - prevention of fault diagnosis > > This doesn't prevent the diagnosis of faults. > It isolates the fault diagnosis to the operator > in which the fault occurs. > > > - complexity overhead > > There is more complexity involved. Add any > feature and you add complexity. The question > is whether the complexity is worth it. So what is the competitive advantage derived from knowing how many/few servers in the network? I was guessing that the desire to hide network servers from end points was out of concerns for concealing them from people like me who might play around with Path or pre-loaded Route headers ;) Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 12:13:34 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16928 for ; Mon, 26 Feb 2001 12:13:33 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C82D6443D5; Mon, 26 Feb 2001 12:13:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 4F50B443CF for ; Mon, 26 Feb 2001 12:12:04 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA26814; Mon, 26 Feb 2001 09:12:21 -0800 (PST) Received: from rmahy-home-nt (rmahy-dsl1.cisco.com [10.19.53.122]) by imop.cisco.com (Mirapoint) with ESMTP id AAL65825; Mon, 26 Feb 2001 09:11:53 -0800 (PST) Message-Id: <4.2.0.58.20010226084627.03a4ebb0@lint.cisco.com> X-Sender: rmahy@imop.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 To: Jonathan Rosenberg From: Rohan Mahy Subject: Re: [SIP] RE: [Sip-implementors] SIP and Call Pickup Cc: "'Neil Deason'" , Alan Johnston , Richard Verhoeven , Rick Dean , jundery@ubiquity.net, parolkar@tri.sbc.com, "'sip@lists.bell-labs.com'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 09:10:24 -0800 At 08:10 PM 2/25/01 , Jonathan Rosenberg wrote: >[moving over to the sip list, as we are now talking about changes to sip] > >A few thoughts on directed pickup. > >1. The mechanism in rfc2543 is a hack. It is meant to provide call pickup as >a side effect of register behavior. What would happen is that the register >would cause the original INVITE to fork to the second phone. The second >phone then answers, which causes the first call to be CANCELed. As such, >Alan's flow is wrong. The proxy would not CANCEL on receipt of REGISTER (why >would it do that?). Rather, it would generate the second INVITE, and when >its answered, then CANCEL. However, this mechanism has some big problems: > > a. its hard to do in a distributed system where the registrar and proxy >are separated sounds like an implementation choice to me. > b. it doesn't actually provide directed call pickup, since the user >experience is much different. IN this mode, the second phone will actually >ring! this is trivial to fix: the second phone/gw just creates some local state, so that when an INVITE for that request-uri arrives, it simply replies with a 200. Note that on an analog phone, you are already "offhook" anyway. >2. The other proposals so far, involving REFER or a REGISTER directly to the >first phone, will not work. They both defined additional, service specific >semantics to these requests. Bad, bad. agreed. >3. It is possible to do directed pickup with a B2BUA. I worked through a >call flow for it, and it emulates completely the PSTN service. It requires >no extensions to SIP, just logic for the service in the picking-up phone and >in the B2BUA. Can it be done without a B2BUA in a distributed way? Maybe. >But, I'm not going to get hung up on emulating every infrequently used PSTN >service in a distributed way. All you've done is moved the problem around. Now all calls that can be picked up have to go through this B2BUA. Eventually this will need the performance of some kind of proxy (but it needs to keep more state and handle twice as many transactions), so if you want to provide redundancy or load sharing you need to add some additional state-sharing scheme, etc. Congratulations, you've just recreated the MGCP model over SIP! ;-) IMO, B2BUA is an overused crutch. I don't object to folks implementing their own services with it, but I don't want us to cripple the spec, or actively encourage others to recreate that which we try to avoid. >4. I believe we should actually remove the current text on directed pickup. >Thats because: > > a. we said that we don't standardize services, but here is random text in >the middle of a section which does just that. It was definitely an >afterthought. > b. it doesn't work easily when the registrar and proxy are separated > c. it doesn't actually do directed pickup as defined > d. I don't think its that widely implemented. > >Can anyone comment on d? Would anyone object to yanking this text? I object to yanking the text about acting on a REGISTER in progress. If you want to yank the reference to "this is how you do call pickup" that's fine with me. We have already discussed how to do this in our proxy in a distributed way, and we don't have to ring the phone. There is room for implementations using both models. thanks, -rohan >-Jonathan R. > > > > > -----Original Message----- > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > Sent: Thursday, February 22, 2001 10:23 AM > > To: Alan Johnston > > Cc: Richard Verhoeven; Rick Dean; jundery@ubiquity.net; > > parolkar@tri.sbc.com; sip-implementors@cs.columbia.edu > > Subject: Re: [Sip-implementors] SIP and Call Pickup > > > > > > Alan Johnston wrote: > > > > > > Adding Call Pickup and Park is on my to do list for the SIP > > > Service Examples I-D (draft-ietf-sip-service-examples-00.txt), > > > but I haven't had any suggestions for how to do this. > > > > > > What about using the mechanism described in bis, but hiding it > > > from the caller behind a proxy? The REGISTER message from C > > > would expire immediately and be directed at B via the proxy. > > > The proxy could then cross-reference the pending INVITE to B, > > > consult policy to see if C is authorized to pickup B's calls, > > > then cancel the pending INVITE and direct the call to C. > > > > > > > > > Caller A Proxy B Called C Picks > > > Up Call > > > | | | | > > > | INVITE F1 | | | > > > |--------------->| INVITE F2 | | > > > |(100 Trying) F3 |------------->| | > > > |<---------------|180 Ringing F4| | > > > | 180 Ringing F5 |<-------------| | > > > |<---------------| | | > > > | | | REGISTER F6 | > > > | |<---------------------------------| > > > | | | 200 OK F7 | > > > | |--------------------------------->| > > > | | | | > > > | | CANCEL F8 | | > > > | |------------->| | > > > | | 200 OK F9 | | > > > | |<-------------| | > > > | | 487 F10 | | > > > | |<-------------| | > > > | | ACK F11 | | > > > | |------------->| | > > > | | | INVITE F12 | > > > | |--------------------------------->| > > > | | | 180 Ringing F13 | > > > | 180 Ringing F14|<---------------------------------| > > > |<---------------| | 200 OK F15 | > > > | |<---------------------------------| > > > | 200 OK F16 | | | > > > |<---------------| | | > > > | ACK F17 | | | > > > |--------------->| | ACK F18 | > > > | |--------------------------------->| > > > | Both way RTP Established | > > > |<=================================================>| > > > > > > Comments? > > > > I think this would work. The Proxy could perhaps just fork > > again upon receipt of F6, letting both B and C ring and doing > > the CANCEL on which ever leg doesn't answer 200. > > > > However, I don't really like promoting the use of REGISTER > > for this as a good idea. It overloads REGISTER and is using > > SIP as a call control protocol. The whole area of a SIP call > > control framework seems to need more work so I wouldn't want > > this perceived to be _the_ way. Anyway if users have intelligent > > and intuitive access to forwarding services through CPL call > > pick up is redundant. > > > > Cheers, > > Neil. > > -- > > Ubiquity Software Corporation, UK http://www.ubiquity.net > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > >--- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 >http://www.dynamicsoft.com > >_______________________________________________ >This list is for continuing development of the SIP protocol. >The sip-implementor's list is the place to discuss implementation, >and to receive advice on understanding existing sip. >To subscribe to it, send mail to >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 12:22:22 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17293 for ; Mon, 26 Feb 2001 12:22:21 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 74AEC443E6; Mon, 26 Feb 2001 12:21:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 64E08443CF for ; Mon, 26 Feb 2001 12:20:11 -0500 (EST) 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 f1QHK7C21455; Mon, 26 Feb 2001 18:20:08 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.11.2/8.11.2) with ESMTP id f1QHK5c26588; Mon, 26 Feb 2001 19:20:05 +0200 (EET) Message-ID: <3A9A9042.235F4841@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen Cc: "Michael A. Ramalho" , Jean-Francois Mule , "'Culpepper, Bert'" , sip@lists.bell-labs.com, jieying.li@claren.com Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream References: <001201c09e0b$88aef490$e54b010a@rwcjfmule01> <3A97BEA0.E3760932@lmf.ericsson.se> <4.1.20010226090522.00a286a0@witbier.cisco.com> <3A9A6824.E411D77E@lmf.ericsson.se> <3A9A7245.66C04E9A@cisco.com> Content-Type: multipart/mixed; boundary="------------4E5534A718D304B9DECC7013" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 19:20:02 +0200 This is a multi-part message in MIME format. --------------4E5534A718D304B9DECC7013 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This is NOT a we-must-use-multiple-streams argument, but do you think the following case could have something to do with the recommendation? Let's assume that gateway B detects the fax tone. It now modifies the stream, which may lead to a new port, different from the voice stream, for the fax stream. Now, it will take a while (even if a very short one) for B to inform A about the change, so A may continue to send voice to B's voice port. If B changed port when the fax was detected, that port will not be available anymore, so A will probably start receiving ICMP messages - which COULD (depending on the time it takes for B to inform A about the modification) cause A to release the call, or something similar unwanted... Instead, if you mute the channel the voice packets will still be received on B's voice port, even if they will not be forwarded. Comments? Regards, Christer Flemming Andreasen wrote: > > Right. Based on all your responses (thanks) it seems we are in much more agreement > than I thought we were. I also agree with your recommended next steps here. > > Regards > > Flemming > > Christer Holmberg wrote: > > > Hi, > > > > I am very happy to allow a single stream, and that's the reason why it > > will be added to the call flows. I DO also agree, that if nobody can > > give a good reason why we would need separate streams I think we should > > consider it to be removed from the recommendation draft. This > > discussion, however, was from the beginning about the bugs in call flows > > draft, which is based on the recommendation. However, I think we all > > agree that this discussion has showed that the recommendation should be > > updated too... > > > > Regards, > > > > Christer > > > > > This email thread is getting monotonous. > > > > > > Please provide Flemming with a *reason* why you > > > desire two streams that makes sense. > > > > > > Flemming has provided many reasons why you > > > would not desire to do this ... the most persuasive > > > being the fact that you would "double book" the > > > QoS requirements for the session (in the sense of > > > two QoS reservations - not necessarily double the > > > bandwidth reservation). > > > > > > If you desire - at any given instant - to have either > > > stream "active" (i.e., non-muted) - and never desire > > > both to be active at a given time - then Flemming's > > > arguments should be sufficient. > > > > > > The QoS argument is particularly persuasive > > > for access (last mile) systems where bandwidth > > > is precious (e.g., wireless, cable, DSL). > > > > > > Even if this is not the case you are considering > > > (e.g., you are only concerned with VoIP over > > > large backbone networks) ... I'd still suggest, > > > for generality, that you do what Flemming > > > says. This is because you, IN GENERAL, > > > won't know the bandwidth limitations, if any, > > > of the other "IP end". And whoever "pays" > > > for the connection might have to pay and/or > > > account for two reservations instead of one. > > > > > > Q.E.D. > > > > > > Michael Ramalho > > > > > > At 11:39 AM 2/25/01 -0500, Flemming Andreasen wrote: > > > > > > > > > > > >Christer Holmberg wrote: > > > > > > > >> Hi, > > > >> > > > >> Jean-Francois Mule wrote: > > > >> > > > > >> >Thanks for the comments. > > > >> > > > > >> >Flemming Andreasen wrote: > > > >> >>Fundamentally, I don't understand why you view this as two > > > >> >>separate media > > > >> >>streams. You are muting one when you want to use the other, > > > >> >>so why have two in > > > >> >>the first place ? Also note, that there may be some undesirable QoS > > > >> >>interactions that way. > > > >> > > > > >> >Christer Holmberg pointed earlier that T.38 suggests to add the fax channel > > > >> >to the voice stream and to mute the voice stream. > > > >> > > > >> Just to clarify: it's not T.38 that suggests this, it is the node (e.g. > > > >> gateway) that detects > > > >> the fax that may suggest this :) > > > >> > > > >> >The only reference I found in T.38 Annex D (TD0262rev1), section 2.2.4 > > > >> >states: > > > >> >"Note that during this switch over and the facsimile call, it may be useful > > > >> >to mute the voice channel. The voice channel may be used again once > > > the end > > > >> >of facsimile transmission is detected." > > > >> >=> this implies that T.38 annex D recommends both streams in the same > > > >> >session. > > > >> > > > > >> >As I've pointed out earlier - and this is what was shown in the current > > > >> >draft, I also prefer to replace the voice by a fax channel for the same DSP > > > >> >resource consumption reasons. BTW, this "replacement" does not prevent the > > > >> >session to return to voice mode after the fax is over (re-INVITE with audio > > > >> >sdp). > > > >> > > > >> There may some issues here, especially if you have a PSTN gateway. If > > > >> you do this, you basically want to create a new connection on the > > > >> endpoint. And, since you already have a connection there this won't > > > >> work. > > > > > > > >Since when could you not create more than one connection on an endpoint ? > > > > > > > >Even for implementations that can only handle a single connection per > > > endpoint, > > > >since when could you not change the media parameters of that connection ? > > > > > > > > > > > >Can we please get some real arguments on the table here - what is the > > > problem ? > > > > > > > >-- Flemming > > > > > > > > > > > >-- > > > >Flemming Andreasen > > > >Cisco Systems > > > > > > > > > > > > > > > >_______________________________________________ > > > >This list is for continuing development of the SIP protocol. > > > >The sip-implementor's list is the place to discuss implementation, > > > >and to receive advice on understanding existing sip. > > > >To subscribe to it, send mail to > > > >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > > > > Michael A. Ramalho, Ph.D. > > > Office email: mramalho@cisco.com > > > Personal email: mar42@cornell.edu > > > Office: +1.732.449.5762 > > > Cell: +1.732.809.0188 > > > Pager: +1.800.365.4578 > > -- > Flemming Andreasen > Cisco Systems --------------4E5534A718D304B9DECC7013 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 --------------4E5534A718D304B9DECC7013-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 12:32:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17811 for ; Mon, 26 Feb 2001 12:32:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6FC1C443D7; Mon, 26 Feb 2001 12:04:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id D3470443D4 for ; Mon, 26 Feb 2001 12:03:06 -0500 (EST) 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 f1QH33d21827; Mon, 26 Feb 2001 18:03:03 +0100 (MET) Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.201]) by fogerty.lmf.ericsson.se (8.11.2/8.11.2) with ESMTP id f1QH32c24547; Mon, 26 Feb 2001 19:03:02 +0200 (EET) Message-ID: <3A9A8C43.23C72D27@lmf.ericsson.se> From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen Cc: "Michael A. Ramalho" , Jean-Francois Mule , "'Culpepper, Bert'" , sip@lists.bell-labs.com, jieying.li@claren.com Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream References: <001201c09e0b$88aef490$e54b010a@rwcjfmule01> <3A97BEA0.E3760932@lmf.ericsson.se> <4.1.20010226090522.00a286a0@witbier.cisco.com> <3A9A6824.E411D77E@lmf.ericsson.se> <3A9A7245.66C04E9A@cisco.com> Content-Type: multipart/mixed; boundary="------------B8138239CE9A47A2D3A1E18B" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 19:02:59 +0200 This is a multi-part message in MIME format. --------------B8138239CE9A47A2D3A1E18B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, >Right. Based on all your responses (thanks) it seems we are in much more agreement >than I thought we were. I also agree with your recommended next steps here. The "funny" thing is that the recommendation is an ITU document (ITU-T Recommendation T.38 Amendment 2)... The recommendation is also based on H.323, which could be the reason for using separate streams. They also use multiple m= lines to define options, which I don't think is the correct usage or SDP(?) Regards, Christer > > Regards > > Flemming > > Christer Holmberg wrote: > > > Hi, > > > > I am very happy to allow a single stream, and that's the reason why it > > will be added to the call flows. I DO also agree, that if nobody can > > give a good reason why we would need separate streams I think we should > > consider it to be removed from the recommendation draft. This > > discussion, however, was from the beginning about the bugs in call flows > > draft, which is based on the recommendation. However, I think we all > > agree that this discussion has showed that the recommendation should be > > updated too... > > > > Regards, > > > > Christer > > > > > This email thread is getting monotonous. > > > > > > Please provide Flemming with a *reason* why you > > > desire two streams that makes sense. > > > > > > Flemming has provided many reasons why you > > > would not desire to do this ... the most persuasive > > > being the fact that you would "double book" the > > > QoS requirements for the session (in the sense of > > > two QoS reservations - not necessarily double the > > > bandwidth reservation). > > > > > > If you desire - at any given instant - to have either > > > stream "active" (i.e., non-muted) - and never desire > > > both to be active at a given time - then Flemming's > > > arguments should be sufficient. > > > > > > The QoS argument is particularly persuasive > > > for access (last mile) systems where bandwidth > > > is precious (e.g., wireless, cable, DSL). > > > > > > Even if this is not the case you are considering > > > (e.g., you are only concerned with VoIP over > > > large backbone networks) ... I'd still suggest, > > > for generality, that you do what Flemming > > > says. This is because you, IN GENERAL, > > > won't know the bandwidth limitations, if any, > > > of the other "IP end". And whoever "pays" > > > for the connection might have to pay and/or > > > account for two reservations instead of one. > > > > > > Q.E.D. > > > > > > Michael Ramalho > > > > > > At 11:39 AM 2/25/01 -0500, Flemming Andreasen wrote: > > > > > > > > > > > >Christer Holmberg wrote: > > > > > > > >> Hi, > > > >> > > > >> Jean-Francois Mule wrote: > > > >> > > > > >> >Thanks for the comments. > > > >> > > > > >> >Flemming Andreasen wrote: > > > >> >>Fundamentally, I don't understand why you view this as two > > > >> >>separate media > > > >> >>streams. You are muting one when you want to use the other, > > > >> >>so why have two in > > > >> >>the first place ? Also note, that there may be some undesirable QoS > > > >> >>interactions that way. > > > >> > > > > >> >Christer Holmberg pointed earlier that T.38 suggests to add the fax channel > > > >> >to the voice stream and to mute the voice stream. > > > >> > > > >> Just to clarify: it's not T.38 that suggests this, it is the node (e.g. > > > >> gateway) that detects > > > >> the fax that may suggest this :) > > > >> > > > >> >The only reference I found in T.38 Annex D (TD0262rev1), section 2.2.4 > > > >> >states: > > > >> >"Note that during this switch over and the facsimile call, it may be useful > > > >> >to mute the voice channel. The voice channel may be used again once > > > the end > > > >> >of facsimile transmission is detected." > > > >> >=> this implies that T.38 annex D recommends both streams in the same > > > >> >session. > > > >> > > > > >> >As I've pointed out earlier - and this is what was shown in the current > > > >> >draft, I also prefer to replace the voice by a fax channel for the same DSP > > > >> >resource consumption reasons. BTW, this "replacement" does not prevent the > > > >> >session to return to voice mode after the fax is over (re-INVITE with audio > > > >> >sdp). > > > >> > > > >> There may some issues here, especially if you have a PSTN gateway. If > > > >> you do this, you basically want to create a new connection on the > > > >> endpoint. And, since you already have a connection there this won't > > > >> work. > > > > > > > >Since when could you not create more than one connection on an endpoint ? > > > > > > > >Even for implementations that can only handle a single connection per > > > endpoint, > > > >since when could you not change the media parameters of that connection ? > > > > > > > > > > > >Can we please get some real arguments on the table here - what is the > > > problem ? > > > > > > > >-- Flemming > > > > > > > > > > > >-- > > > >Flemming Andreasen > > > >Cisco Systems > > > > > > > > > > > > > > > >_______________________________________________ > > > >This list is for continuing development of the SIP protocol. > > > >The sip-implementor's list is the place to discuss implementation, > > > >and to receive advice on understanding existing sip. > > > >To subscribe to it, send mail to > > > >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > > > > Michael A. Ramalho, Ph.D. > > > Office email: mramalho@cisco.com > > > Personal email: mar42@cornell.edu > > > Office: +1.732.449.5762 > > > Cell: +1.732.809.0188 > > > Pager: +1.800.365.4578 > > -- > Flemming Andreasen > Cisco Systems --------------B8138239CE9A47A2D3A1E18B 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 --------------B8138239CE9A47A2D3A1E18B-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 13:30:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20204 for ; Mon, 26 Feb 2001 13:30:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 63AE144356; Mon, 26 Feb 2001 13:30:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by lists.bell-labs.com (Postfix) with ESMTP id 17FAA4434C for ; Mon, 26 Feb 2001 13:26:47 -0500 (EST) Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f1QIQg614943; Mon, 26 Feb 2001 20:26:42 +0200 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15002.40930.751639.236975@lohi.eng.telia.fi> To: Neil Deason Cc: sip@lists.bell-labs.com Subject: Re: [SIP] confusion in url comparison In-Reply-To: <3A9A72DA.A374709D@ubiquity.net> References: <200102261307.f1QD7PU14246@lohi.eng.telia.fi> <3A9A72DA.A374709D@ubiquity.net> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 20:26:42 +0200 (EET) Content-Transfer-Encoding: 7bit Neil Deason writes: > No, if a componment is omitted it matches on it's default > value. Table 2 defines the default value for user-param as > 'ip' not 'phone'. thanks for the clarification. > > sip:bar.com > > sip:foor@bar.com;user=phone > > > > would match. so it looks to me like section 2.1 would require some > > rewording. > > These don't match either - the user part is still significant > in the comparison despite being omitted from one URL. where is that rule stated in the bis? -- juha _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 13:32:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20302 for ; Mon, 26 Feb 2001 13:32:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9A4704439B; Mon, 26 Feb 2001 13:32:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id 711164434C for ; Mon, 26 Feb 2001 13:31:17 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA04777 for ; Mon, 26 Feb 2001 11:31:16 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA08447 for ; Mon, 26 Feb 2001 11:31:16 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id <1LR7Y5S7>; Mon, 26 Feb 2001 12:31:15 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8C86@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'Sean Olson'" , "Henning G. Schulzrinne" Cc: Neil Deason , "Arnoud van Wijk (ELN)" , sip@lists.bell-labs.com Subject: RE: [SIP] VIA header encryption? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 12:31:11 -0600 Hi Sean You said... > In 3GPP, there are essentially three SIP "servers": > A Proxy CSCF (Call Session Control Function) which > sits on the border between the access network and the > core network, the Interrogating CSCF (I-CSCF) that > sits on the border between two operator's network, > and a serving CSCF (S-CSCF) that is the real SIP server > for a subscriber. The goal is to hide the number of > S-CSCFs in an operator's network. To do this, the > I-CSCF is being tasked with this Via: hiding function. All what you say does make sense, Still allow me to be picky a bit and to enhance some more about the CSCF flavors, in favor of those who may learn from it. (Though I know you know it for sure and was just short in time..) The Proxy CSCF (Call Session Control Function) does not sit on the border between the access network and the core network... It does sit in the IMS sub network, which is pass the Core-Network itself... It is true though that in case of the P-CSCF it is an IMS, which is associated with the geographic Access and core (PS domain) networks, in which the user is currently roaming ( a special case would be his home network..). Also the P-CSCF is a 'real SIP proxy server' too... You may compare it to an local outbound SIP proxy server. Actually if BIS2543 have had also a local inbound proxy server then we would have said the P-CSCF mimics the functionality of both local SIP proxy servers.. Still your intention is of course good and helpful :) Uri =========================================== Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; =========================================== > -----Original Message----- > From: Sean Olson [mailto:sean.olson@ericsson.com] > Sent: Monday, February 26, 2001 9:37 AM > To: Henning G. Schulzrinne > Cc: Neil Deason; Arnoud van Wijk (ELN); sip@lists.bell-labs.com > Subject: Re: [SIP] VIA header encryption? > > > I hope I can clarify this a bit. First, the goal > is not to hide the address of the endpoint. The > goal is to hide the capacity of the core or internal > network. That is, the number of SIP servers in a > given domain. This information is seen as a competitive > advantage in the wireless arena. > > In 3GPP, there are essentially three SIP "servers": > A Proxy CSCF (Call Session Control Function) which > sits on the border between the access network and the > core network, the Interrogating CSCF (I-CSCF) that > sits on the border between two operator's network, > and a serving CSCF (S-CSCF) that is the real SIP server > for a subscriber. The goal is to hide the number of > S-CSCFs in an operator's network. To do this, the > I-CSCF is being tasked with this Via: hiding function. > > Hope this helps somewhat, > sean > > Henning G. Schulzrinne wrote: > > >> I think the motivation in 3GPP is more to do with providers > >> hiding internal network topography rather than the fact > >> signalling ever passed through them. > > > > > > Why hiding the IP addresses or names of servers is of any value has > > always baffled me. This strikes me as having no security value, but > > making diagnosis of problems that much more difficult. > After all, nobody > > (except spammers) worries about "exposing the topology of > email servers" > > and does Received header hiding (I hope...). I think rather > than rolling > > over and saying "3GPP must know best", some effort at > education should > > be made by those active in that community. This strikes me as a > > requirement where the best approach is to say "you really > don't want to > > do this" rather than devising ever more ingenious and > complicated ways > > to pursue the elusive goal of address hiding. If you truly > want to hide > > the IP address of the end system (for which arguments can > be made, as > > that address may reveal location information), you'll need > some form of > > B2B UA, with media handling. > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 13:39:20 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20683 for ; Mon, 26 Feb 2001 13:39:19 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 01A8F443B5; Mon, 26 Feb 2001 13:39:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id AE671443B0 for ; Mon, 26 Feb 2001 13:38:54 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA03208; Mon, 26 Feb 2001 10:39:00 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f1QIcS929965; Mon, 26 Feb 2001 10:38:28 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id KAA23451; Mon, 26 Feb 2001 10:38:21 -0800 (PST) Message-ID: <3A9AA35C.98B89888@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: "Michael A. Ramalho" , Jean-Francois Mule , "'Culpepper, Bert'" , sip@lists.bell-labs.com, jieying.li@claren.com Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream References: <001201c09e0b$88aef490$e54b010a@rwcjfmule01> <3A97BEA0.E3760932@lmf.ericsson.se> <4.1.20010226090522.00a286a0@witbier.cisco.com> <3A9A6824.E411D77E@lmf.ericsson.se> <3A9A7245.66C04E9A@cisco.com> <3A9A9042.235F4841@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 13:41:32 -0500 Content-Transfer-Encoding: 7bit It would probably be better to ask those that wrote the recommendation. Nevertheless, I don't see this as an argument either as B could just keep the port open for a while, e.g. until it gets the 200 OK. regardless of whether it was specified as a separate media stream in the SDP or not. -- Flemming Christer Holmberg wrote: > Hi, > > This is NOT a we-must-use-multiple-streams argument, but do you think > the following case could have something to do with the recommendation? > > Let's assume that gateway B detects the fax tone. It now modifies the > stream, which may lead to a new port, different from the voice stream, > for the fax stream. Now, it will take a while (even if a very short one) > for B to inform A about the change, so A may continue to send voice to > B's voice port. If B changed port when the fax was detected, that port > will not be available anymore, so A will probably start receiving ICMP > messages - which COULD (depending on the time it takes for B to inform A > about the modification) cause A to release the call, or something > similar unwanted... Instead, if you mute the channel the voice packets > will still be received on B's voice port, even if they will not be > forwarded. > > Comments? > > Regards, > > Christer > > Flemming Andreasen wrote: > > > > Right. Based on all your responses (thanks) it seems we are in much more agreement > > than I thought we were. I also agree with your recommended next steps here. > > > > Regards > > > > Flemming > > > > Christer Holmberg wrote: > > > > > Hi, > > > > > > I am very happy to allow a single stream, and that's the reason why it > > > will be added to the call flows. I DO also agree, that if nobody can > > > give a good reason why we would need separate streams I think we should > > > consider it to be removed from the recommendation draft. This > > > discussion, however, was from the beginning about the bugs in call flows > > > draft, which is based on the recommendation. However, I think we all > > > agree that this discussion has showed that the recommendation should be > > > updated too... > > > > > > Regards, > > > > > > Christer > > > > > > > This email thread is getting monotonous. > > > > > > > > Please provide Flemming with a *reason* why you > > > > desire two streams that makes sense. > > > > > > > > Flemming has provided many reasons why you > > > > would not desire to do this ... the most persuasive > > > > being the fact that you would "double book" the > > > > QoS requirements for the session (in the sense of > > > > two QoS reservations - not necessarily double the > > > > bandwidth reservation). > > > > > > > > If you desire - at any given instant - to have either > > > > stream "active" (i.e., non-muted) - and never desire > > > > both to be active at a given time - then Flemming's > > > > arguments should be sufficient. > > > > > > > > The QoS argument is particularly persuasive > > > > for access (last mile) systems where bandwidth > > > > is precious (e.g., wireless, cable, DSL). > > > > > > > > Even if this is not the case you are considering > > > > (e.g., you are only concerned with VoIP over > > > > large backbone networks) ... I'd still suggest, > > > > for generality, that you do what Flemming > > > > says. This is because you, IN GENERAL, > > > > won't know the bandwidth limitations, if any, > > > > of the other "IP end". And whoever "pays" > > > > for the connection might have to pay and/or > > > > account for two reservations instead of one. > > > > > > > > Q.E.D. > > > > > > > > Michael Ramalho > > > > > > > > At 11:39 AM 2/25/01 -0500, Flemming Andreasen wrote: > > > > > > > > > > > > > > >Christer Holmberg wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> Jean-Francois Mule wrote: > > > > >> > > > > > >> >Thanks for the comments. > > > > >> > > > > > >> >Flemming Andreasen wrote: > > > > >> >>Fundamentally, I don't understand why you view this as two > > > > >> >>separate media > > > > >> >>streams. You are muting one when you want to use the other, > > > > >> >>so why have two in > > > > >> >>the first place ? Also note, that there may be some undesirable QoS > > > > >> >>interactions that way. > > > > >> > > > > > >> >Christer Holmberg pointed earlier that T.38 suggests to add the fax channel > > > > >> >to the voice stream and to mute the voice stream. > > > > >> > > > > >> Just to clarify: it's not T.38 that suggests this, it is the node (e.g. > > > > >> gateway) that detects > > > > >> the fax that may suggest this :) > > > > >> > > > > >> >The only reference I found in T.38 Annex D (TD0262rev1), section 2.2.4 > > > > >> >states: > > > > >> >"Note that during this switch over and the facsimile call, it may be useful > > > > >> >to mute the voice channel. The voice channel may be used again once > > > > the end > > > > >> >of facsimile transmission is detected." > > > > >> >=> this implies that T.38 annex D recommends both streams in the same > > > > >> >session. > > > > >> > > > > > >> >As I've pointed out earlier - and this is what was shown in the current > > > > >> >draft, I also prefer to replace the voice by a fax channel for the same DSP > > > > >> >resource consumption reasons. BTW, this "replacement" does not prevent the > > > > >> >session to return to voice mode after the fax is over (re-INVITE with audio > > > > >> >sdp). > > > > >> > > > > >> There may some issues here, especially if you have a PSTN gateway. If > > > > >> you do this, you basically want to create a new connection on the > > > > >> endpoint. And, since you already have a connection there this won't > > > > >> work. > > > > > > > > > >Since when could you not create more than one connection on an endpoint ? > > > > > > > > > >Even for implementations that can only handle a single connection per > > > > endpoint, > > > > >since when could you not change the media parameters of that connection ? > > > > > > > > > > > > > > >Can we please get some real arguments on the table here - what is the > > > > problem ? > > > > > > > > > >-- Flemming > > > > > > > > > > > > > > >-- > > > > >Flemming Andreasen > > > > >Cisco Systems > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > >This list is for continuing development of the SIP protocol. > > > > >The sip-implementor's list is the place to discuss implementation, > > > > >and to receive advice on understanding existing sip. > > > > >To subscribe to it, send mail to > > > > >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > > > > > > Michael A. Ramalho, Ph.D. > > > > Office email: mramalho@cisco.com > > > > Personal email: mar42@cornell.edu > > > > Office: +1.732.449.5762 > > > > Cell: +1.732.809.0188 > > > > Pager: +1.800.365.4578 > > > > -- > > Flemming Andreasen > > Cisco Systems -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 16:50:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29259 for ; Mon, 26 Feb 2001 16:50:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9CD9C443A0; Mon, 26 Feb 2001 16:50:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id 8EAE3443A8 for ; Mon, 26 Feb 2001 16:32:49 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 13:30:46 -0800 Received: from rwcjfmule01 (adsl-216-103-84-208.dsl.snfc21.pacbell.net [216.103.84.208]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GB0WL7W; Mon, 26 Feb 2001 08:18:02 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Christer Holmberg'" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] T.38 and multiple streams Message-ID: <017b01c0a00f$c568d7b0$e54b010a@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A97BD2F.9D0F2D7E@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 08:18:34 -0800 Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > At the end, I guess this is up to the user to decide, and it also > depends on which transport protocols you use. For fax TCP is > recommended, reference? > Also, if you want to continue the voice session after the fax > transmission it think the best thing to do is to keep the > voice stream. Again, I do not think this is always "the best thing" mainly because for each fax call (and the entire duration of the fax transmission), 2 DSP channels are used and worse depending on the complexity of the codec that was selected for voice. When you have a large DSP pool in a big fat gateway, you may think it is ok. When you have a small enterprise gw with limited number of ports (8 for example), you do not want fax calls to litteraly "block" voice calls because the fax calls suck all the dsp resources. => so, and to shut down this specific point in the thread, I'll repeat: both should be allowed in our Internet-Draft. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 16:51:59 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29330 for ; Mon, 26 Feb 2001 16:51:59 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CEFFF443CA; Mon, 26 Feb 2001 16:50:34 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id E6DC6443AD for ; Mon, 26 Feb 2001 16:33:26 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 13:31:31 -0800 Received: from rwcjfmule01 (216.103.84.208 [216.103.84.208]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GB0WLZB; Mon, 26 Feb 2001 08:06:09 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Christer Holmberg'" , "'Flemming Andreasen'" Cc: "'Culpepper, Bert'" , sip@lists.bell-labs.com, Jieying Li Subject: RE: [SIP] T.38 and multiple streams Message-ID: <017701c0a00e$19648be0$e54b010a@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A97BD07.DFBF5893@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 08:06:36 -0800 Content-Transfer-Encoding: 7bit > Flemming Andreasen wrote: > >You are muting one when you want to use the other, so why > >have two in the first place ? Christer Holmberg wrote: > You want to continue the voice session after the fax has been sent, so > by keeping the voice stream during the fax transmissoion you > don't have > to create a new voice stream after the fax, just "un-mute" > the existing one. There are pros and cons for both methods and I don't think we should force a decision on this now. The SIP T.38 call flows will show both options. We should leave that to vendors' implementations and see if it does cause interop issues - I bet it does not unless your implementation does not support multiple media connections per session. Jean-Francois Mule. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 17:03:34 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29743 for ; Mon, 26 Feb 2001 17:03:33 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 99F7A443E1; Mon, 26 Feb 2001 16:50:58 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id 1D95C443B8 for ; Mon, 26 Feb 2001 16:33:45 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 13:31:49 -0800 Received: from rwcjfmule01 (adsl-216-103-84-208.dsl.snfc21.pacbell.net [216.103.84.208]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GB0WMGN; Mon, 26 Feb 2001 08:52:48 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Christer Holmberg'" Cc: sip@lists.bell-labs.com, Jieying Li Subject: RE: [SIP] T.38 - to add fax stream or to replace voice stream Message-ID: <01a201c0a014$9fc3e720$e54b010a@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A9A6824.E411D77E@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 08:53:19 -0800 Content-Transfer-Encoding: 7bit Agreeing on a common approach does not mean removing the other ones from the internet-draft, right? Based on our thread, I do not see any reason for updating the ITU-T T.38 recommendation ("recommendation") but many good reasons to update the SIP T.38 Internet-Draft. My goal is to collect all the good comments and submit an updated draft for your review this week. I'd propose to mute this thread on the points we've beaten until then. Jean-Francois Mule Clarent Corporation. > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se] > Sent: Monday, February 26, 2001 6:29 AM > To: Michael A. Ramalho > Cc: Flemming Andreasen; Jean-Francois Mule; 'Culpepper, Bert'; > sip@lists.bell-labs.com; jieying.li@claren.com > Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream > > > > Hi, > > I am very happy to allow a single stream, and that's the reason why it > will be added to the call flows. I DO also agree, that if nobody can > give a good reason why we would need separate streams I think > we should > consider it to be removed from the recommendation draft. This > discussion, however, was from the beginning about the bugs in > call flows > draft, which is based on the recommendation. However, I think we all > agree that this discussion has showed that the recommendation > should be > updated too... > > Regards, > > Christer > > > > > > This email thread is getting monotonous. > > > > Please provide Flemming with a *reason* why you > > desire two streams that makes sense. > > > > Flemming has provided many reasons why you > > would not desire to do this ... the most persuasive > > being the fact that you would "double book" the > > QoS requirements for the session (in the sense of > > two QoS reservations - not necessarily double the > > bandwidth reservation). > > > > If you desire - at any given instant - to have either > > stream "active" (i.e., non-muted) - and never desire > > both to be active at a given time - then Flemming's > > arguments should be sufficient. > > > > The QoS argument is particularly persuasive > > for access (last mile) systems where bandwidth > > is precious (e.g., wireless, cable, DSL). > > > > Even if this is not the case you are considering > > (e.g., you are only concerned with VoIP over > > large backbone networks) ... I'd still suggest, > > for generality, that you do what Flemming > > says. This is because you, IN GENERAL, > > won't know the bandwidth limitations, if any, > > of the other "IP end". And whoever "pays" > > for the connection might have to pay and/or > > account for two reservations instead of one. > > > > Q.E.D. > > > > Michael Ramalho > > > > At 11:39 AM 2/25/01 -0500, Flemming Andreasen wrote: > > > > > > > > >Christer Holmberg wrote: > > > > > >> Hi, > > >> > > >> Jean-Francois Mule wrote: > > >> > > > >> >Thanks for the comments. > > >> > > > >> >Flemming Andreasen wrote: > > >> >>Fundamentally, I don't understand why you view this as two > > >> >>separate media > > >> >>streams. You are muting one when you want to use the other, > > >> >>so why have two in > > >> >>the first place ? Also note, that there may be some > undesirable QoS > > >> >>interactions that way. > > >> > > > >> >Christer Holmberg pointed earlier that T.38 suggests to > add the fax channel > > >> >to the voice stream and to mute the voice stream. > > >> > > >> Just to clarify: it's not T.38 that suggests this, it is > the node (e.g. > > >> gateway) that detects > > >> the fax that may suggest this :) > > >> > > >> >The only reference I found in T.38 Annex D > (TD0262rev1), section 2.2.4 > > >> >states: > > >> >"Note that during this switch over and the facsimile > call, it may be useful > > >> >to mute the voice channel. The voice channel may be > used again once > > the end > > >> >of facsimile transmission is detected." > > >> >=> this implies that T.38 annex D recommends both > streams in the same > > >> >session. > > >> > > > >> >As I've pointed out earlier - and this is what was > shown in the current > > >> >draft, I also prefer to replace the voice by a fax > channel for the same DSP > > >> >resource consumption reasons. BTW, this "replacement" > does not prevent the > > >> >session to return to voice mode after the fax is over > (re-INVITE with audio > > >> >sdp). > > >> > > >> There may some issues here, especially if you have a > PSTN gateway. If > > >> you do this, you basically want to create a new connection on the > > >> endpoint. And, since you already have a connection there > this won't > > >> work. > > > > > >Since when could you not create more than one connection > on an endpoint ? > > > > > >Even for implementations that can only handle a single > connection per > > endpoint, > > >since when could you not change the media parameters of > that connection ? > > > > > > > > >Can we please get some real arguments on the table here - > what is the > > problem ? > > > > > >-- Flemming > > > > > > > > >-- > > >Flemming Andreasen > > >Cisco Systems > > > > > > > > > > > >_______________________________________________ > > >This list is for continuing development of the SIP protocol. > > >The sip-implementor's list is the place to discuss implementation, > > >and to receive advice on understanding existing sip. > > >To subscribe to it, send mail to > > >sip-implementors-request@cs.columbia.edu with "subscribe" > in the body. > > > > Michael A. Ramalho, Ph.D. > > Office email: mramalho@cisco.com > > Personal email: mar42@cornell.edu > > Office: +1.732.449.5762 > > Cell: +1.732.809.0188 > > Pager: +1.800.365.4578 > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 17:06:55 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29866 for ; Mon, 26 Feb 2001 17:06:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 84C92443EC; Mon, 26 Feb 2001 16:51:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id 53A8F443BC for ; Mon, 26 Feb 2001 16:34:53 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 13:32:57 -0800 Received: from rwcjfmule01 (216.103.84.208 [216.103.84.208]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GB0WL9K; Mon, 26 Feb 2001 08:22:57 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Christer Holmberg'" Cc: sip@lists.bell-labs.com, Jieying Li Subject: RE: [SIP] T.38 - to add fax stream or to replace voice stream Message-ID: <017c01c0a010$72136b10$e54b010a@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A97BEA0.E3760932@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 08:23:24 -0800 Content-Transfer-Encoding: 7bit Jean-Francois Mule wrote: > > BTW, this "replacement" does not prevent the > >session to return to voice mode after the fax is over > > (re-INVITE with audio sdp). Christer Holmberg > There may some issues here, especially if you have a PSTN gateway. If > you do this, you basically want to create a new connection on the > endpoint. And, since you already have a connection there this won't > work. Ok, of course your gateway can be smart enough to > handle this, but > - again - there probably would be some interop issues... first of, I believe most of the fax call are terminated when fax is over. For the cases where audio connection is required at the end of fax, we will see the interop issues at the bake-off and revise the draft accordingly, right? _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 17:17:35 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00834 for ; Mon, 26 Feb 2001 17:17:34 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BC681443D2; Mon, 26 Feb 2001 16:50:46 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id 3D6C0443B6 for ; Mon, 26 Feb 2001 16:33:30 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 13:31:34 -0800 Received: from rwcjfmule01 (216.103.84.208 [216.103.84.208]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GB0WM1V; Mon, 26 Feb 2001 08:46:08 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Michael A. Ramalho'" , "'Flemming Andreasen'" , "'Christer Holmberg'" Cc: "'Culpepper, Bert'" , sip@lists.bell-labs.com, Jieying Li Subject: RE: [SIP] T.38 - to add fax stream or to replace voice stream Message-ID: <01a101c0a013$af5ca100$e54b010a@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <4.1.20010226090522.00a286a0@witbier.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 08:46:35 -0800 Content-Transfer-Encoding: 7bit Michael A. Ramalho wrote: > would not desire to do this ... the most persuasive > being the fact that you would "double book" the > QoS requirements for the session To me, the most persuasive reason is to book the DSP resources for not much at the end... As far as QoS, why would'nt your QoS decision/enforcement points recognize the codec used or whether you're muting the channel to make appropriate choices... Flemming Andreasen wrote: > Can we please get some real arguments on the table here - > what is the problem ? I'm trying to remain neutral in this discussion because I believe both should be allowed even though, as implementors, I have a preference based on the target application... A good argument for maintaining 2 connections: let's forget the pstn handles fax on one physical line - this is the source of the pb. Let's think not about replicating the way the PSTN handles this. New kinds of IP terminals should allow users to speak while sending the fax if end-users desire to. We must not limit speech only when fax is over. This, to me, is a SUFFICIENT reason. Jean-Francois Mule > -----Original Message----- > From: Michael A. Ramalho [mailto:mramalho@cisco.com] > Sent: Monday, February 26, 2001 6:17 AM > To: Flemming Andreasen; Christer Holmberg > Cc: Jean-Francois Mule; 'Culpepper, Bert'; sip@lists.bell-labs.com; > jieying.li@claren.com > Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream > > > This email thread is getting monotonous. > > Please provide Flemming with a *reason* why you > desire two streams that makes sense. > > Flemming has provided many reasons why you > would not desire to do this ... the most persuasive > being the fact that you would "double book" the > QoS requirements for the session (in the sense of > two QoS reservations - not necessarily double the > bandwidth reservation). > > If you desire - at any given instant - to have either > stream "active" (i.e., non-muted) - and never desire > both to be active at a given time - then Flemming's > arguments should be sufficient. > > The QoS argument is particularly persuasive > for access (last mile) systems where bandwidth > is precious (e.g., wireless, cable, DSL). > > Even if this is not the case you are considering > (e.g., you are only concerned with VoIP over > large backbone networks) ... I'd still suggest, > for generality, that you do what Flemming > says. This is because you, IN GENERAL, > won't know the bandwidth limitations, if any, > of the other "IP end". And whoever "pays" > for the connection might have to pay and/or > account for two reservations instead of one. > > Q.E.D. > > Michael Ramalho _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 17:17:41 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00853 for ; Mon, 26 Feb 2001 17:17:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 24822443AD; Mon, 26 Feb 2001 16:50:22 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id 8004F443A9 for ; Mon, 26 Feb 2001 16:33:04 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 13:31:08 -0800 Received: from rwcjfmule01 (adsl-216-103-84-208.dsl.snfc21.pacbell.net [216.103.84.208]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GB0WL5J; Mon, 26 Feb 2001 08:10:05 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Christer Holmberg'" Cc: sip@lists.bell-labs.com, Jieying Li Subject: RE: [SIP] T.38 and multiple streams Message-ID: <017801c0a00e$a8e1f1e0$e54b010a@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A97BD07.DFBF5893@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 08:10:37 -0800 Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > I guess there are reasons for this. One is that it is recommended that > you use TCP for fax, and since you use RTP/UDP for voice > you will have to use separate streams. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is wrong. No matter what transport is used for voice, one single stream *can* be used when switching to fax. Jean-Francois Mule _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 17:20:41 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00951 for ; Mon, 26 Feb 2001 17:20:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 725DE443F2; Mon, 26 Feb 2001 16:51:21 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203]) by lists.bell-labs.com (Postfix) with ESMTP id 6325C443C3 for ; Mon, 26 Feb 2001 16:49:21 -0500 (EST) Received: by longmail.lboard.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 13:49:20 -0800 Message-ID: From: Sekhar Banerjee To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Call Transfer Using REFER Method. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 13:49:17 -0800 > Hi All, > > We are having a hard time trying to figure out how to make the > Transferee send the Invite to the Transfer Target through the proxy when > REFER is used to transfer the call. Could you shed some light on how this > can be achieved. > > Transferee Transferor Proxy Transfer Target > > Invite|---------------------------> > |<----------------------- 100 Trying > | <---------- Invite > | 200 --------------> > |<----------------------- 200 > Ack |---------------------------> > | <---------- Ack > | Invite(c=0)--------> > |<----------------------- Invite(c=0) > 200 Ok|---------------------------> > | <---------- 200 Ok > | Ack --------------> > |<----------------------- Ack > | Invite(TT)-----> > | Invite -------------> > | <--------------- 200 > | <-------- 200 > | Ack --------------> > | Ack --------------> > | Bye -------------> > | Bye --------------> > | <--------------- 200 > | <-------- 200 > | Refer ------------> > |<------------------------- Refer > 200 Ok|---------------------------> > | <------------- 200 OK > Invite|---------------------------------------------> > |<------------------------------------------- 200 Ok > Ack |---------------------------------------------> > Bye |---------------------------------------------> > |<------------------------------------------- 200 Ok > > We would like to see the last Invite and Bye go through the proxy > too > so that the proxy can control that call. Would a Record-Route in the Refer > help me achieve this goal ? Or a route header embedded in the referred-to > header ? Is the transferor mandated to use the route header thus provided? > > Is there anybody out there that has implemented supervised call > transfer > using the Refer method so that the proxy is involved in the messaging for > all > the three calls? If so, we would appreciate to find out how you > accomplished > this (in a billable manner). > > TIA, > Ragunath/Shriram. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 17:24:39 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01072 for ; Mon, 26 Feb 2001 17:24:38 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D782A443F6; Mon, 26 Feb 2001 16:51:33 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id BFEA3443C1 for ; Mon, 26 Feb 2001 16:34:53 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 13:32:57 -0800 Received: from rwcjfmule01 (216.103.84.208 [216.103.84.208]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GB0WM4Z; Mon, 26 Feb 2001 09:40:39 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Christer Holmberg'" Cc: sip@lists.bell-labs.com, Jieying Li Subject: RE: [SIP] T.38 - to add fax stream or to replace voice stream Message-ID: <01d201c0a01b$4d3c1c00$e54b010a@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3A9A8C43.23C72D27@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 09:41:07 -0800 Content-Transfer-Encoding: 7bit > The recommendation is also based on H.323, which could be the > reason for using separate streams. No. In H.323 provides 2 H.245 commands to control the logical channels, Replacementfor and RequestMode. A similar debate applies to H.323, MGCP, ... > They also use multiple m= lines to define options, which I don't think > is the correct usage or SDP(?) I had sent comments to Glen Parsons. Upon update of the new draft, we'll send follow-up. Jean-Francois. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 17:30:16 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01304 for ; Mon, 26 Feb 2001 17:30:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E1DFB44349; Mon, 26 Feb 2001 17:29:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id E9F144433C for ; Mon, 26 Feb 2001 17:27:01 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA14638; Mon, 26 Feb 2001 14:27:20 -0800 (PST) Received: from buckthorn-nt.cisco.com (dhcp-128-107-142-89.cisco.com [128.107.142.89]) by imop.cisco.com (Mirapoint) with ESMTP id AAL70536 (AUTH rmahy); Mon, 26 Feb 2001 14:26:53 -0800 (PST) Message-Id: <5.0.0.25.2.20010226115732.01c98eb0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: wtm@research.att.com From: Rohan Mahy Cc: sip@lists.bell-labs.com, rohan@cisco.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_12013063==_.ALT" Subject: [SIP] removing the bis draft dependency from manyfolks Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 14:24:52 -0800 --=====================_12013063==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, There is a very simple way to remove the dependency of manyfolks on the bis draft. Simply change the behavior in manyfolks such that 180/181/182 with preconditions means "I will ring/alert/notify the phone _as soon as my preconditions are satisfied_." Only a few lines of text need to be replaced: (from Section 8.1): >Upon receipt of the COMET message, the UAC/UAS continues normal SIP > call handling, by (for a UAS) alerting the user and sending e.g. a > 180-Ringing or 200-OK response. ---> "Upon receipt of the COMET message (or the 200 response to the COMET), the UAS (or UAC) continues normal SIP call handling, by performing the action normally associated with sending or recieving the 18x provisional response (e.g. for a 180, the UAC plays local ringback and the UAS alerts the user)." (from Section 9.1) >At this point it alerts the user, and sends a 180- >Ringing provisional response. This provisional response is also >sent using the reliability mechanism of [12], resulting in a PRACK >message and 200-OK of the PRACK. --> "At this point it alerts the user. Upon receipt of the 200 response to the COMET, the UAC generates local ringback." Also replace: "183-Session-Progress" with "18x". If these small changes are made, the example flow already in the draft will still work (because the 183 has empty semantics, no action is postponed; the subsequent 180 will cause ringback immediately because preconditions are already satisfied). Also the shorter flow shown below will also work. Originating (UAC) Terminating (UAS) | SIP-Proxy(s) | | INVITE | | |---------------------->|---------------------->| | | | | 180 w/SDP | 180 w/SDP | * |<----------------------|<----------------------| * | | | PRACK | |---------------------------------------------->| | 200 OK (of PRACK) | |<----------------------------------------------| | Reservation Reservation | ===========> <=========== | | | | | COMET | |---------------------------------------------->| | 200 OK (of COMET) | |<----------------------------------------------| | | ** Local Ringback Played User Alerted ** | | | time passes ... | | | | User Picks-Up | SIP-Proxy(s) the phone | | | | 200 OK | 200 OK | |<----------------------|<----------------------| | | | | | | ACK | |---------------------------------------------->| Ringing and Ringback are delayed from * until ** . The Terminating UAS rings the phone when the COMET arrives. The Originating UAC plays local ringback when the 200 OK to the COMET arrives. Please consider this proposal. I feel this is both useful technically, as well as an ideal short-cut around more process-related delay. thanks, -rohan --=====================_12013063==_.ALT Content-Type: text/html; charset="us-ascii" Hi,

There is a very simple way to remove the dependency of manyfolks on the bis draft.

Simply change the behavior in manyfolks such that 180/181/182 with preconditions means "I will ring/alert/notify the phone _as soon as my preconditions are satisfied_."

Only a few lines of text need to be replaced:

(from Section 8.1):
Upon receipt of the COMET message, the UAC/UAS continues normal SIP
   call handling, by (for a UAS) alerting the user and sending e.g. a
   180-Ringing or 200-OK response. 
    --->
"Upon receipt of the COMET message (or the 200 response to the COMET), the UAS (or UAC) continues normal SIP call handling, by performing the action normally associated with sending or recieving the 18x provisional response (e.g. for a 180, the UAC plays local ringback and the UAS alerts the user)."

(from Section 9.1)
At this point it alerts the user, and sends a 180-
Ringing provisional response.  This provisional response is also
sent using the reliability mechanism of [12], resulting in a PRACK
message and 200-OK of the PRACK.
--> "At this point it alerts the user.  Upon receipt of the 200 response to the COMET, the UAC generates local ringback."

Also replace: "183-Session-Progress" with "18x".

If these small changes are made, the example flow already in the draft will still work (because the 183 has empty semantics, no action is postponed; the subsequent 180 will cause ringback immediately because preconditions are already satisfied).  Also the shorter flow shown below will also work. 

   Originating (UAC)                            Terminating (UAS)
        |                  SIP-Proxy(s)                 |
        |  INVITE               |                       |
        |---------------------->|---------------------->|
        |                       |                       |
        |       180 w/SDP       |       180 w/SDP       |
      * |<----------------------|<----------------------| *
        |                                               |
        |                       PRACK                   |
        |---------------------------------------------->|
        |               200 OK (of PRACK)               |
        |<----------------------------------------------|
        | Reservation                       Reservation |
         ===========>                       <===========
        |                                               |
        |                                               |
        |               COMET                           |
        |---------------------------------------------->|
        |               200 OK (of COMET)               |
        |<----------------------------------------------|
        |                                               |
   **  Local Ringback Played                    User Alerted **
        |                                               |
        |              time passes ...                  |
        |                                               |
        |                                       User Picks-Up
        |                  SIP-Proxy(s)         the phone
        |                       |                       |
        |       200 OK          |       200 OK          |
        |<----------------------|<----------------------|
        |                       |                       |
        |                                               |
        |                       ACK                     |
        |---------------------------------------------->|

Ringing and Ringback are delayed from * until ** . The Terminating UAS rings the phone when the COMET arrives.  The Originating UAC plays local ringback when the 200 OK to the COMET arrives.

Please consider this proposal.  I feel this is both useful technically, as well as an ideal short-cut around more process-related delay.

thanks,
-rohan

--=====================_12013063==_.ALT-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 17:41:06 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01813 for ; Mon, 26 Feb 2001 17:41:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 69D98443D1; Mon, 26 Feb 2001 17:38:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id AC5E2443EB for ; Mon, 26 Feb 2001 17:34:52 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA21943; Mon, 26 Feb 2001 14:34:59 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f1QMYdX11092; Mon, 26 Feb 2001 14:34:39 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id OAA29994; Mon, 26 Feb 2001 14:34:38 -0800 (PST) Message-ID: <3A9ADABF.9477DD50@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule Cc: "'Culpepper, Bert'" , "'Christer Holmberg'" , sip@lists.bell-labs.com, jieying.li@claren.com Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream References: <001201c09e0b$88aef490$e54b010a@rwcjfmule01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 17:37:51 -0500 Content-Transfer-Encoding: 7bit Jean-Francois Mule wrote: > > Flemming Andreasen wrote: > > - Why must CNG tone detection not lead to a switch to T.38 ? > it could but my understanding is that CNG is optional so to limit the number > of cases we selected the Preamble sequence. Also, because of the potential > glare effect, we decided to mandate for the Preamble detection... > Do you have any comments to improve the text there? If it's just a particular call flow that shows fax detect based on V.21 fax preamble rather then T.30 CNG, then that's fine. If the text on the other hand says that in general you shall not switch based on CNG, then that's problematic, and I believe that's the way the current text reads. > > > > - SIP call flow should probably include a Contact header > > resulting in some of > > your messages (e.g. ACK) going end-to-end rather than through > > the proxy). > why is that useful in the sip t.38 case? Well, that's how SIP normally works. > > fyi, a record-route header line has been added to enforce the route through > proxy. > I suppose that's another way of solving that. I personally think it's just muddying the picture a little, but it's your I-D. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 17:50:25 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02254 for ; Mon, 26 Feb 2001 17:50:24 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1BA06443B0; Mon, 26 Feb 2001 17:49:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 67C7C44392 for ; Mon, 26 Feb 2001 17:45:48 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA03589; Mon, 26 Feb 2001 14:45:49 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f1QMjcZ29101; Mon, 26 Feb 2001 14:45:38 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id OAA04220; Mon, 26 Feb 2001 14:45:28 -0800 (PST) Message-ID: <3A9ADD49.C99FFC3B@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule Cc: "'Christer Holmberg'" , "'Culpepper, Bert'" , sip@lists.bell-labs.com, Jieying Li Subject: Re: [SIP] T.38 and multiple streams References: <017701c0a00e$19648be0$e54b010a@rwcjfmule01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 17:48:42 -0500 Content-Transfer-Encoding: 7bit Jean-Francois Mule wrote: > > Flemming Andreasen wrote: > > >You are muting one when you want to use the other, so why > > >have two in the first place ? > > Christer Holmberg wrote: > > You want to continue the voice session after the fax has been sent, so > > by keeping the voice stream during the fax transmissoion you > > don't have > > to create a new voice stream after the fax, just "un-mute" > > the existing one. > > There are pros and cons for both methods and I don't think we should force a > decision on this now. The SIP T.38 call flows will show both options. We > should leave that to vendors' implementations and see if it does cause > interop issues - I bet it does not unless your implementation does not > support multiple media connections per session. And that's the problem. There will be lots of devices out there that will not want to support more than one media stream at a time. Considering this is to be a BCP and you want to specify something that's interoperable, I'd strongly suggest that the mono-media solution is considered the base-line that all implementations should be expected to support. For those more sophisticated types of devices that allow you to send faxes and continue talking at the same time, I have no problem specifying a multi-media call flow that adds an extra active stream, however do note, that this is different from what has been discussed so far, which was a single active media stream. -- Flemming > > > Jean-Francois Mule. -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 18:16:00 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03161 for ; Mon, 26 Feb 2001 18:15:59 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 00A3044343; Mon, 26 Feb 2001 18:03:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203]) by lists.bell-labs.com (Postfix) with ESMTP id 6E8A744339 for ; Mon, 26 Feb 2001 17:58:34 -0500 (EST) Received: by longmail.lboard.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 14:58:33 -0800 Message-ID: From: Ragunath Devarasu To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Call Transfer Using REFER Method. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 14:58:24 -0800 Hi All, We are having a hard time trying to figure out how to make the Transferee send the Invite to the Transfer Target through the proxy when REFER is used to transfer the call. Could you shed some light on how this can be achieved. Transferee Transferor Proxy Transfer Target Invite|---------------------------> |<----------------------- 100 Trying | <---------- Invite | 200 --------------> |<----------------------- 200 Ack |---------------------------> | <---------- Ack | Invite(c=0)--------> |<----------------------- Invite(c=0) 200 Ok|---------------------------> | <---------- 200 Ok | Ack --------------> |<----------------------- Ack | Invite(TT)-----> | Invite -------------> | <--------------- 200 | <-------- 200 | Ack --------------> | Ack --------------> | Bye -------------> | Bye --------------> | <--------------- 200 | <-------- 200 | Refer ------------> |<------------------------- Refer 200 Ok|---------------------------> | <------------- 200 OK Invite|---------------------------------------------> |<------------------------------------------- 200 Ok Ack |---------------------------------------------> Bye |---------------------------------------------> |<------------------------------------------- 200 Ok We would like to see the last Invite and Bye go through the proxy too so that the proxy can control that call. Would a Record-Route in the Refer help me achieve this goal ? Or a route header embedded in the referred-to header ? Is the transferor mandated to use the route header thus provided? Is there anybody out there that has implemented supervised call transfer using the Refer method so that the proxy is involved in the messaging for all the three calls? If so, we would appreciate to find out how you accomplished this (in a billable manner). TIA, Ragunath/Shriram. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 18:16:46 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03214 for ; Mon, 26 Feb 2001 18:16:44 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CE28A443FE; Mon, 26 Feb 2001 17:55:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 73C5D44401 for ; Mon, 26 Feb 2001 17:52:43 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id OAA14127; Mon, 26 Feb 2001 14:52:34 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f1QMqVF02001; Mon, 26 Feb 2001 14:52:31 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id OAA06899; Mon, 26 Feb 2001 14:52:30 -0800 (PST) Message-ID: <3A9ADEEF.C85DE999@cisco.com> From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jean-Francois Mule Cc: "'Michael A. Ramalho'" , "'Christer Holmberg'" , "'Culpepper, Bert'" , sip@lists.bell-labs.com, Jieying Li Subject: Re: [SIP] T.38 - to add fax stream or to replace voice stream References: <01a101c0a013$af5ca100$e54b010a@rwcjfmule01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 17:55:43 -0500 Content-Transfer-Encoding: 7bit Jean-Francois Mule wrote: > Michael A. Ramalho wrote: > > would not desire to do this ... the most persuasive > > being the fact that you would "double book" the > > QoS requirements for the session > To me, the most persuasive reason is to book the DSP resources for not much > at the end... > As far as QoS, why would'nt your QoS decision/enforcement points recognize > the codec used or whether you're muting the channel to make appropriate > choices... That would imply that you give up the old (audio) reservation then, however I'd rather not turn this into a QoS discussion. > > > Flemming Andreasen wrote: > > Can we please get some real arguments on the table here - > > what is the problem ? > I'm trying to remain neutral in this discussion because I believe both > should be allowed even though, as implementors, I have a preference based on > the target application... > A good argument for maintaining 2 connections: let's forget the pstn handles > fax on one physical line - this is the source of the pb. Let's think not > about replicating the way the PSTN handles this. > New kinds of IP terminals should allow users to speak while sending the fax > if end-users desire to. We must not limit speech only when fax is over. > This, to me, is a SUFFICIENT reason. I agree, but that is indeed also a multi-media call (two active media streams), which is not what has been discussed so far. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 18:17:30 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03281 for ; Mon, 26 Feb 2001 18:17:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B208D44392; Mon, 26 Feb 2001 18:13:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 5E9004435D for ; Mon, 26 Feb 2001 18:12:26 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id FAA07761; Tue, 27 Feb 2001 05:19:18 -0600 Message-ID: <00bf01c0a049$e8be3450$ad036e3f@dynamicsoft.com> From: "Dean Willis" To: "Arnoud van Wijk (ELN)" , References: <7BA41B5547CCD411833B0002A52CD457D51060@enlrynt306.etm.ericsson.se> Subject: Re: [SIP] Multiple SIP URLS for same proxy server. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 17:14:45 -0600 Content-Transfer-Encoding: 7bit Anoud, I believe the speficiation allows the behaviour that you are describing. However, some proxy implementations may not allow it. Personally, I believe that a user-service proxy should be able to map multiple URLs (a@b, c@d) to a single user profile, which may REACT differently to the request depending on the original request-URI. But that's just may, and implementations will vary. Implementation-specific discussions should of course be deferred to the sip-implementors list. -- Dean ----- Original Message ----- From: "Arnoud van Wijk (ELN)" To: Sent: Monday, February 26, 2001 9:48 AM Subject: [SIP] Multiple SIP URLS for same proxy server. > Hello everybody. > > A SIP proxy can be addressed with a SIP URL, and via the URL the IP address can be found. > If I am a crazy network provider who wants to give the same SIP Proxy server different SIP URLS, i.e. > pegasus@amcrazy.net > solstice@amcrazy.net > 666@devil.com > etc. > > This should be possible as long that the domains and names are owned by me. > In this case if solstice@amcrazy.net is looked up..the IP address will be located, which is the same one if 666@devil.com is looked up. > > So, as long that the SIP Proxy server registers all the SIP URLs at the registrars. This should be possible to pull off. > > Is that right? Or am I forgetting something? Has this already been looked at and perhaps decreed as an illegal act? (like registrar only allowing the newest registration with the same IP address) > > Thanks for your time > > Greetings > > Arnoud van Wijk > _______________________________________________________________ > ERICSSON EUROLABS NETHERLANDS BV > Arnoud van Wijk > Research & Development (ELN/V) > Fax: +31-161 247569 > _______________________________________________________________ > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 18:21:31 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03530 for ; Mon, 26 Feb 2001 18:21:30 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 323384439D; Mon, 26 Feb 2001 18:21:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 910854439D for ; Mon, 26 Feb 2001 18:20:20 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1QNKIi17189; Mon, 26 Feb 2001 17:20:18 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f1QNKIr27007; Mon, 26 Feb 2001 17:20:18 -0600 (CST) Received: from ericsson.com (pc050151.exu.ericsson.se [138.85.50.151]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA00490; Mon, 26 Feb 2001 17:20:17 -0600 (CST) Message-ID: <3A9AE447.3080303@ericsson.com> From: Sean Olson Organization: Ericsson Inc. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Neil Deason Cc: sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: <7BA41B5547CCD411833B0002A52CD457D5105B@enlrynt306.etm.ericsson.se> <3A9A5494.A5408430@ubiquity.net> <3A9A626D.E83DFE3@cs.columbia.edu> <3A9A7830.2000203@ericsson.com> <3A9A8793.9529C0AD@ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 17:18:31 -0600 Content-Transfer-Encoding: 7bit Neil Deason wrote: >>From what I have seen of the 3GPP docs it appears there > could be the potential for a lot of state information being > stored in these servers. P-CSCFs might be expected to > maintain mappings of hidden/unhidden Vias, user registrations, > session signalling paths and even individual call path info > (when they strip out all Via headers before passing INVITEs > to called parties)? This type of behaviour means you lose the > scalability and reliability features for network servers > that were intended with SIP. I agree with the principle of favoring stateless proxies over stateful proxies. But there are cases where you need to store state in the network. In the particular 3GPP scenarios you mention, I don't believe scalability is at risk. Performance, yes, but not scalability. Reliability is of course an issue. Do you move reliability into the endpoints or leave it in the network? You can argue for both cases. > Is there not the case for at least > a more DCS-like approach where you at least store state info > that you really need in the UEs. The revised Record-Route text > means you wouldn't even need a State header extension. I > appreciate that there could be issues with storing information > in the UAs/UEs and retransmitting it over an air interface, > but if bandwidth is the over riding concern for you SIP is not > the best protocol to choose in the first place The problem is exactly as you stated: storing this information in the terminal and retransmitting it over the air interface. Bandwidth is one concern here. Delay is another. Delay is of course a function of the amount of data transmitted. The choice of SIP is now fixed. We are working to utilize SIP in the best manner possible while working within the constraints of a wireless network. This is a challenge, but also a tremendous opportunity for the SIP community. Given the projected growth of 3G terminals, 3G could potentially do more for the spread of SIP than anything else to date. > > Cheers, > Neil Thanks for the comments /sean _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 18:29:27 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03932 for ; Mon, 26 Feb 2001 18:29:26 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D296B44404; Mon, 26 Feb 2001 18:29:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 857AD4440E for ; Mon, 26 Feb 2001 18:25:00 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id FAA07829 for ; Tue, 27 Feb 2001 05:32:05 -0600 Message-ID: <00ff01c0a04b$b2479180$ad036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Slot Requests for IETF 50 Meeting Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 17:27:32 -0600 Content-Transfer-Encoding: 7bit One thing the ADs and many senior contributors have taken the chairs "out behind the barn" for is making more effective use of meeting time. We have rather exlicit orders not to repeat the "two minutes and then we hum" format of the last meeting. The basic idea is to use the very valuable face-to-face meeting time for working out the hard stuff, not for updating status or proposing new work. We're now the busiest group in the IETF, and we need to start working smarter. More on that later . . . So, I ask all of you who are considering a slot request for SIP WG at IETF 50 to consider: 1) Is your topic this a "hotly debated issue" or is it a status work or a proposal for a new project? 2) Can your need be effectively met by list discussion? If not, what would it take (moderation, tracking, whatever) to make the mailing list an effective forum for your needs? 3) How can we help? Thanks. -- Dean Willis SIP WG Co-Dependent, I mean Co-Chair _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 19:00:25 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05172 for ; Mon, 26 Feb 2001 19:00:24 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 060C04433B; Mon, 26 Feb 2001 19:00:09 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id A46EE44340 for ; Mon, 26 Feb 2001 18:57:44 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Feb 26 18:54:37 EST 2001 Received: by lists.bell-labs.com (Postfix) id E8D3844384; Mon, 26 Feb 2001 18:43:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id 4D6D84437D for ; Mon, 26 Feb 2001 18:43:10 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 23:43:09 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0018B4F61@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] SIP extensions and the base reference for SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 23:43:01 -0000 I have been doing some working through the table 4 and 5 in the RFC2543 and the bis draft, and looking at how the various SIP extensions affect this. I come to the following conclusions: i) when and if the SIP bis draft ever gets accepted as an RFC, we are going to have to a lot of work (much of it technical rather than editorial) on the extension drafts to make them reference the bis draft, rather than RFC2543. ii) currently there is potential conflict between some of the extensions in what they say in terms of the usage of various headers and methods, for example we have method definitions that apparently say they are special, and a lot of headers are not required, and header extensions that say the extensions are appropriate to all methods including ACK. iii) there also seems to be some inconsistency in the way the authors of the various extensions have treated these tables in completing them. I think some work therefore needs to be done in this area. I would like to at least propose the following: - That all extensions include editor's notes to specify text that can be removed at IESG review time. This will give additional text or replacement text that allows the extension to refer to the bis draft rather than RFC2543, and will allow a ready view of what needs to be updated as and when the bis draft becomes an RFC. - That a volunteer should identify the required extensions or changes to the INFO method RFC to allow it to refer to the bis draft. - That the guidelines document should contain text on how table 4 and 5 should be extended by any SIP extension, particularly in relation to that SIP extension and any other extension that has already been published or is in progress. I would note that some extensions which add either headers or methods do not include the extension material to table 4 and 5, and none of the extensions which do provide this material indicate what is appropriate in relation to the INFO header, which is in an extension that is now an RFC. - Presumably a sense of honour and spirit of benevolence will then cause all extension authors to follow these guidelines!!!!! I would be happy with any different set of actions that allows consistency between the bis draft and the various extensions when the bis draft gets published. I have noted a number of apparent errors in the use of these tables and will publish these to the list in separate mails. Comments please. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 19:06:55 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05435 for ; Mon, 26 Feb 2001 19:06:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 30D8B4434F; Mon, 26 Feb 2001 19:00:20 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id 0B4214434D for ; Mon, 26 Feb 2001 18:58:02 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Mon Feb 26 18:56:10 EST 2001 Received: by lists.bell-labs.com (Postfix) id 1F5EB44380; Mon, 26 Feb 2001 18:43:01 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150]) by lists.bell-labs.com (Postfix) with ESMTP id 81EE24437D for ; Mon, 26 Feb 2001 18:43:00 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Feb 2001 23:42:59 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB0018B4F5D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "Drage, Keith (Keith)" , "'sip@lists.bell-labs.com'" , "Roy, Radhika R, ALCOO" Subject: RE: [SIP] 3GPP current needs from SIP drafts MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 23:42:56 -0000 If I understand your point correctly, and which drafts you are referring to, then I have to reply that 3GPP are not looking at SIP for mobility, merely to use SIP for session control in a mobile environment. Mobility management in 3GPP release 5 will be handled by the underlying General Packet Radio Service (GPRS) alothough more other IP strategies are being looked at for future releases. Also the mobility related drafts expired some time ago, and I have not noted much interest in reviving them (a comment that is invariably a prelude to screams of protest!!!). Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Roy, Radhika R, ALCOO[SMTP:rrroy@att.com] > Sent: 23 February 2001 15:14 > To: Drage, Keith (Keith); 'sip@lists.bell-labs.com' > Subject: RE: [SIP] 3GPP current needs from SIP drafts > > Please see the following URL where you will also see couple of SIP I-Ds > that > deal with mobility in SIP: > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Friday, February 23, 2001 5:25 AM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] 3GPP current needs from SIP drafts > > > Hannu has circulated a summary of the last 3GPP discussion on the use of > SIP. > > As there was a discussion in the IETF SIP WG ad-hoc on what drafts 3GPP > was > currently looking at from the IETF, I undertook to provide the current > list. > > Before I give the list, I must stress that it is preliminary. The basis > for > the list is the flows that currently exist in 24.228, and the elements of > signalling that they use. Therefore the list is probably incomplete > because > 24.228 is incomplete, and may be wrong, because 24.228 is still at a stage > where comments can significantly change its contents. > > We are intending contributing significant parts of 24.228 to the SIP WG > for > you to analyse, discuss, pull apart, comment on or whatever. > > The list is currently as follows: > > draft-ietf-sip-rfc2543bis SIP: Session Initiation Protocol > draft-sip-manyfolks-resource Integration of resource management and SIP > draft-ietf-sip-100rel Reliability of Provisional Responses in SIP > draft-ietf-sip-privacy SIP extensions for caller identity > and > privacy > draft-ietf-sip-call-auth SIP extensions for media > authorization > > The N1-010273 that was referred to in previous discussion on this list, is > the 3GPP work item description. This document evolves from meeting to > meeting (changing tdoc numbers as it goes!!!!), and will be used to > maintain > the list of areas where we are dependent on IETF work. 3GPP intends to > keep > you directly informed as that list changes. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Mon Feb 26 21:10:36 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09405 for ; Mon, 26 Feb 2001 21:10:35 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8E3A44373; Mon, 26 Feb 2001 21:06:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.pingtel.com (mail.pingtel.com [216.91.1.131]) by lists.bell-labs.com (Postfix) with ESMTP id F21684434C for ; Mon, 26 Feb 2001 21:01:41 -0500 (EST) Received: from pingtel.com (cdhcp177.pingtel.com [10.1.1.177]) by mail.pingtel.com (8.9.3/8.9.3) with ESMTP id UAA11885; Mon, 26 Feb 2001 20:59:51 -0500 Message-ID: <3A9B0B48.CFE97A24@pingtel.com> From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1} (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: Jonathan Rosenberg , "'Neil Deason'" , Alan Johnston , Richard Verhoeven , Rick Dean , jundery@ubiquity.net, parolkar@tri.sbc.com, "'sip@lists.bell-labs.com'" Subject: Re: [SIP] RE: [Sip-implementors] SIP and Call Pickup References: <4.2.0.58.20010226084627.03a4ebb0@lint.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 21:04:56 -0500 Content-Transfer-Encoding: 7bit Rohan Mahy wrote: > At 08:10 PM 2/25/01 , Jonathan Rosenberg wrote: > >[moving over to the sip list, as we are now talking about changes to sip] > > > >A few thoughts on directed pickup. > > > >1. The mechanism in rfc2543 is a hack. It is meant to provide call pickup as > >a side effect of register behavior. What would happen is that the register > >would cause the original INVITE to fork to the second phone. The second > >phone then answers, which causes the first call to be CANCELed. As such, > >Alan's flow is wrong. The proxy would not CANCEL on receipt of REGISTER (why > >would it do that?). Rather, it would generate the second INVITE, and when > >its answered, then CANCEL. However, this mechanism has some big problems: > > > > a. its hard to do in a distributed system where the registrar and proxy > >are separated > It requires some additional signalling, but I would not say that it is hard. It is not as complicated as building a B2BUA that has to deal with the state and scale of every ringing phone in an environment. One not well thought out means: proxy could do a short lived implied or explicit SUBSCRIBE and get a NOTIFY from the registrar with additional contacts as added. I think the proxy/registrar is the correct place for this feature. > > sounds like an implementation choice to me. > > > b. it doesn't actually provide directed call pickup, since the user > >experience is much different. IN this mode, the second phone will actually > >ring! > > this is trivial to fix: the second phone/gw just creates some local state, > so that when an INVITE for that request-uri arrives, it simply replies with > a 200. Note that on an analog phone, you are already "offhook" anyway. > > >2. The other proposals so far, involving REFER or a REGISTER directly to the > >first phone, will not work. They both defined additional, service specific > >semantics to these requests. Bad, bad. > > agreed. > > >3. It is possible to do directed pickup with a B2BUA. I worked through a > >call flow for it, and it emulates completely the PSTN service. It requires > >no extensions to SIP, just logic for the service in the picking-up phone and > >in the B2BUA. Can it be done without a B2BUA in a distributed way? Maybe. > >But, I'm not going to get hung up on emulating every infrequently used PSTN > >service in a distributed way. > > All you've done is moved the problem around. Now all calls that can be > picked up have to go through this B2BUA. Eventually this will need the > performance of some kind of proxy (but it needs to keep more state and > handle twice as many transactions), so if you want to provide redundancy or > load sharing you need to add some additional state-sharing scheme, > etc. Congratulations, you've just recreated the MGCP model over SIP! ;-) > > IMO, B2BUA is an overused crutch. I don't object to folks implementing > their own services with it, but I don't want us to cripple the spec, or > actively encourage others to recreate that which we try to avoid. > I am with you on this. There is a great danger that B2BUAs start getting stuffed into networks where proxys are more appropriate. It then gets harder and harder to allow two end points to send messages without content and headers getting filtered out or mucked up by B2BUAs in the middle which do not explicitly support the extensions of the end points. > > >4. I believe we should actually remove the current text on directed pickup. > >Thats because: > > > > a. we said that we don't standardize services, but here is random text in > >the middle of a section which does just that. It was definitely an > >afterthought. > > b. it doesn't work easily when the registrar and proxy are separated > > c. it doesn't actually do directed pickup as defined > > d. I don't think its that widely implemented. > > > >Can anyone comment on d? Would anyone object to yanking this text? > We were planning on supporting pickup in our UA using this technique. Of course if no proxy/registrars support it we are just one hand clapping. > > I object to yanking the text about acting on a REGISTER in progress. If > you want to yank the reference to "this is how you do call pickup" that's > fine with me. > > We have already discussed how to do this in our proxy in a distributed way, > and we don't have to ring the phone. > > There is room for implementations using both models. > > thanks, > -rohan > > >-Jonathan R. > > > > > > > > > -----Original Message----- > > > From: Neil Deason [mailto:ndeason@ubiquity.net] > > > Sent: Thursday, February 22, 2001 10:23 AM > > > To: Alan Johnston > > > Cc: Richard Verhoeven; Rick Dean; jundery@ubiquity.net; > > > parolkar@tri.sbc.com; sip-implementors@cs.columbia.edu > > > Subject: Re: [Sip-implementors] SIP and Call Pickup > > > > > > > > > Alan Johnston wrote: > > > > > > > > Adding Call Pickup and Park is on my to do list for the SIP > > > > Service Examples I-D (draft-ietf-sip-service-examples-00.txt), > > > > but I haven't had any suggestions for how to do this. > > > > > > > > What about using the mechanism described in bis, but hiding it > > > > from the caller behind a proxy? The REGISTER message from C > > > > would expire immediately and be directed at B via the proxy. > > > > The proxy could then cross-reference the pending INVITE to B, > > > > consult policy to see if C is authorized to pickup B's calls, > > > > then cancel the pending INVITE and direct the call to C. > > > > > > > > > > > > Caller A Proxy B Called C Picks > > > > Up Call > > > > | | | | > > > > | INVITE F1 | | | > > > > |--------------->| INVITE F2 | | > > > > |(100 Trying) F3 |------------->| | > > > > |<---------------|180 Ringing F4| | > > > > | 180 Ringing F5 |<-------------| | > > > > |<---------------| | | > > > > | | | REGISTER F6 | > > > > | |<---------------------------------| > > > > | | | 200 OK F7 | > > > > | |--------------------------------->| > > > > | | | | > > > > | | CANCEL F8 | | > > > > | |------------->| | > > > > | | 200 OK F9 | | > > > > | |<-------------| | > > > > | | 487 F10 | | > > > > | |<-------------| | > > > > | | ACK F11 | | > > > > | |------------->| | > > > > | | | INVITE F12 | > > > > | |--------------------------------->| > > > > | | | 180 Ringing F13 | > > > > | 180 Ringing F14|<---------------------------------| > > > > |<---------------| | 200 OK F15 | > > > > | |<---------------------------------| > > > > | 200 OK F16 | | | > > > > |<---------------| | | > > > > | ACK F17 | | | > > > > |--------------->| | ACK F18 | > > > > | |--------------------------------->| > > > > | Both way RTP Established | > > > > |<=================================================>| > > > > > > > > Comments? > > > > > > I think this would work. The Proxy could perhaps just fork > > > again upon receipt of F6, letting both B and C ring and doing > > > the CANCEL on which ever leg doesn't answer 200. > > > > > > However, I don't really like promoting the use of REGISTER > > > for this as a good idea. It overloads REGISTER and is using > > > SIP as a call control protocol. The whole area of a SIP call > > > control framework seems to need more work so I wouldn't want > > > this perceived to be _the_ way. Anyway if users have intelligent > > > and intuitive access to forwarding services through CPL call > > > pick up is redundant. > > > > > > Cheers, > > > Neil. > > > -- > > > Ubiquity Software Corporation, UK http://www.ubiquity.net > > > _______________________________________________ > > > Sip-implementors mailing list > > > Sip-implementors@cs.columbia.edu > > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > > > >--- > >Jonathan D. Rosenberg 72 Eagle Rock Ave. > >Chief Scientist First Floor > >dynamicsoft East Hanover, NJ 07936 > >jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > >http://www.dynamicsoft.com > > > >_______________________________________________ > >This list is for continuing development of the SIP protocol. > >The sip-implementor's list is the place to discuss implementation, > >and to receive advice on understanding existing sip. > >To subscribe to it, send mail to > >sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 00:47:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15676 for ; Tue, 27 Feb 2001 00:47:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6018944339; Tue, 27 Feb 2001 00:47:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lists.bell-labs.com (Postfix) with ESMTP id 15F6344337 for ; Tue, 27 Feb 2001 00:46:59 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id WAA06328 for ; Mon, 26 Feb 2001 22:46:58 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id WAA27922 for ; Mon, 26 Feb 2001 22:46:57 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id <1LR7ZG2L>; Mon, 26 Feb 2001 23:46:57 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8C99@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] permanent/temporary registration Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 26 Feb 2001 23:46:47 -0600 Must a registration interval have a ceiling? I.e. Can I have my SIP phone at home be registered for ever (say as my default SIP phone) while other SIP phones I use on a temporary basis (i.e. the SIP phone at office or Lab) would be typically registered at the registrar for a limited period of time? ============================================ Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; ============================================ _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 00:58:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15750 for ; Tue, 27 Feb 2001 00:58:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E587744344; Tue, 27 Feb 2001 00:58:06 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id 77F0044337 for ; Tue, 27 Feb 2001 00:57:29 -0500 (EST) Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f1R5wZd13333; Tue, 27 Feb 2001 11:28:36 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id f1R4cPC09012; Tue, 27 Feb 2001 10:08:26 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256A00.0018A769 ; Tue, 27 Feb 2001 09:59:17 +0530 X-Lotus-FromDomain: HSSBLR From: airoy@hss.hns.com To: Robert Sparks Cc: "'sip@lists.bell-labs.com'" Message-ID: <65256A00.0018A5A2.00@sampark.hss.hns.com> Subject: RE: [SIP] REFER revision Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 09:59:12 +0530 hello, This is fine except for a minor change in the BNF. The opening ' [ ' should be before the semicolon Referred-By = ("Referred-By" | "b") ":" referrer-url [ ";" -ashok ------------------ ashok @ Hughes S/W ------------------ >>Referred-By = ("Referred-By" | "b") ":" referrer-url ";" >>So, would the following be acceptable? >>Referred-By = ("Referred-By" | "b") ":" referrer-url ";" [( referenced-url | ( referenced-url ";" ref-signature ) | ( ref-signature ";" referenced-url ) )] >>RjS _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 04:39:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02250 for ; Tue, 27 Feb 2001 04:39:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 06EED44337; Tue, 27 Feb 2001 04:39:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 96C8B44336 for ; Tue, 27 Feb 2001 04:38:39 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 27 Feb 2001 09:38:38 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA00542; Tue, 27 Feb 2001 09:20:56 GMT Message-ID: <3A9B7178.D0105CDC@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Juha Heinanen Cc: sip@lists.bell-labs.com Subject: Re: [SIP] confusion in url comparison References: <200102261307.f1QD7PU14246@lohi.eng.telia.fi> <3A9A72DA.A374709D@ubiquity.net> <15002.40930.751639.236975@lohi.eng.telia.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 09:20:56 +0000 Content-Transfer-Encoding: 7bit Juha Heinanen wrote: > > Neil Deason writes: > > > No, if a componment is omitted it matches on it's default > > value. Table 2 defines the default value for user-param as > > 'ip' not 'phone'. > > thanks for the clarification. > > > > sip:bar.com > > > sip:foor@bar.com;user=phone > > > > > > would match. so it looks to me like section 2.1 would require some > > > rewording. > > > > These don't match either - the user part is still significant > > in the comparison despite being omitted from one URL. > > where is that rule stated in the bis? This is covered by the text stating that user parameters of the URI must match and if any URI components are omitted you match against it's default value. (Section 2.1, 3rd bullet point) User has no default value defined, so for the SIP URLs: sip:bar.com sip:foo@bar.com you compare an 'empty user/null' with 'foo' which obviously don't match. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 04:46:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02289 for ; Tue, 27 Feb 2001 04:46:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 67B9444340; Tue, 27 Feb 2001 04:46:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 88C7A44336 for ; Tue, 27 Feb 2001 04:45:03 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 27 Feb 2001 09:45:02 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA09318; Tue, 27 Feb 2001 09:43:51 GMT Message-ID: <3A9B76D7.41DBD946@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Baniel Uri-CUB001 Cc: sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8C86@il27exm02.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 09:43:51 +0000 Content-Transfer-Encoding: 7bit Baniel Uri-CUB001 wrote: > > Hi Sean > > You said... > > > In 3GPP, there are essentially three SIP "servers": > > A Proxy CSCF (Call Session Control Function) which > > sits on the border between the access network and the > > core network, the Interrogating CSCF (I-CSCF) that > > sits on the border between two operator's network, > > and a serving CSCF (S-CSCF) that is the real SIP server > > for a subscriber. The goal is to hide the number of > > S-CSCFs in an operator's network. To do this, the > > I-CSCF is being tasked with this Via: hiding function. > > All what you say does make sense, Still allow me to be picky a bit and to enhance some more about the CSCF flavors, in favor of those who may learn from it. (Though I know you know it for sure and was just short in time..) > > The Proxy CSCF (Call Session Control Function) does not sit on the border between the access network and the core network... > It does sit in the IMS sub network, which is pass the Core-Network itself... It is true though that in case of the P-CSCF it is an IMS, which is associated with the geographic Access and core (PS domain) networks, in which the user is currently roaming ( a special case would be his home network..). Also the P-CSCF is a 'real SIP proxy server' too... You may compare it to an local outbound SIP proxy server. Actually if BIS2543 have had also a local inbound proxy server then we would have said the P-CSCF mimics the functionality of both local SIP proxy servers.. Thanks for the further info Uri, however please allow me to now be a little bit picky with your comments too ;) I have seen these comparisons in presentations on SIP and 3GPP and I think it is a over simplification which has potential to mislead. The functionality potentially being placed in a P-CSCF would make it a very different 'Proxy Server' to any you would conclude from reading RFC 2453bis. An example is the possible proposed behaviour of a P-CSCF on an incoming call - the 'local inbound proxy server' role. It appears possible that the P-CSCF may be expected to remove all Via headers and only pass a locally unique token on to the called party. There are quite a few other differences too. :PLEASE NOTE: I am not saying this sort of thing is right or wrong within the 3GPP. Though I do have general concerns that the proposed architecture is heading towards a networks of B2B UAs which would be wrong. I just think that as the two communities engage we need to ensure we fully understand each others terminology. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 04:52:34 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02337 for ; Tue, 27 Feb 2001 04:52:34 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9DE7544351; Tue, 27 Feb 2001 04:50:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 9FB3F44336 for ; Tue, 27 Feb 2001 04:49:22 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 27 Feb 2001 09:49:21 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA11875; Tue, 27 Feb 2001 09:48:15 GMT Message-ID: <3A9B77DF.7B4DF897@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Baniel Uri-CUB001 Cc: sip@lists.bell-labs.com Subject: Re: [SIP] permanent/temporary registration References: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8C99@il27exm02.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 09:48:15 +0000 Content-Transfer-Encoding: 7bit Baniel Uri-CUB001 wrote: > > Must a registration interval have a ceiling? I.e. Can I have my SIP phone at home be registered for ever (say as my default SIP phone) while other SIP phones I use on a temporary basis (i.e. the SIP phone at office or Lab) would be typically registered at the registrar for a limited period of time? It is really at the discretion of the registrar. You can request as long a period as you wish but the registrar can always indicate a shorter expiry time in the response. See bis 02 section 4.2.6.4. BTW this question probably belonged on the SIP Implementers List. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 05:50:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02891 for ; Tue, 27 Feb 2001 05:50:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3234C4433F; Tue, 27 Feb 2001 05:50:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 6492444336 for ; Tue, 27 Feb 2001 05:49:42 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 27 Feb 2001 10:49:40 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA02610; Tue, 27 Feb 2001 10:45:22 GMT Message-ID: <3A9B8546.1E8D0DA4@ubiquity.net> From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mayank Sharma Cc: Baniel Uri-CUB001 , sip@lists.bell-labs.com, sip-implementors@cs.columbia.edu Subject: Re: [Sip-implementors] RE: [SIP] permanent/temporary registration References: <2330401A6FE03445ADA682F5EBB7502D31BA36@mtv01ex01.mindtree.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 10:45:26 +0000 Content-Transfer-Encoding: 7bit Mayank Sharma wrote: > Hi, > > > -----Original Message----- > > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > > Sent: Tuesday, February 27, 2001 11:17 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] permanent/temporary registration > > > > > > Must a registration interval have a ceiling? I.e. Can I have > > my SIP phone at home be registered for ever (say as my > > I don't think you have a ceiling on the registaration interval. You can > register your > SIP phone for ever (well almost by specifying a very high value in the > expires). The default > interval however happens to be 2 hr. Well 1hr for sip urls and forever for non sip urls, although the registrar may shorten any registration it receives so the expires in the response must be checked. > > > > default SIP phone) while other SIP phones I use on a > > temporary basis (i.e. the SIP phone at office or Lab) would > > be typically registered at the registrar for a limited period of time? > > yes it can be done > > regards, > Mayank Sharma > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 08:06:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06655 for ; Tue, 27 Feb 2001 08:06:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A08174433A; Tue, 27 Feb 2001 08:06:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qhars002.nortel.com (qhars002.NortelNetworks.com [192.100.101.19]) by lists.bell-labs.com (Postfix) with ESMTP id 64C4544336 for ; Tue, 27 Feb 2001 08:05:28 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qhars002.nortel.com; Tue, 27 Feb 2001 13:05:16 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 13:05:03 -0000 Message-ID: From: "Mark Watson" To: "'bidulock@openss7.org'" , "Mark Watson" Cc: "'Keith Robinson'" , "'Gonzalo.Camarillo@lmf.ericsson.se'" , "'christer.holmberg@lmf.ericsson.se'" , "Joshua Moloney" , "Tom-PT Taylor" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Overlap call setup MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A0BD.BDEA0EB0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 13:03:56 -0000 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_01C0A0BD.BDEA0EB0 Content-Type: text/plain; charset="iso-8859-1" Brian, > Nevertheless, the rule for the PSTN is terminating switch always gets > digits en bloc (cause it needs all of them to route).# Not in Germay it doesn't. The dial plan is so open that not even the terminating switch knows how many digits there are going to be - it's only the CPE that knows. The only place > that overlap sending gets used heavily is calls into an international > gateway switch (which should know how many to collect anyway > because it > has country code tables and can send en bloc from there). Overlap sending is certainly used on almost all calls in the UK - admittedly not because it has to, but more because it has always been done that way. ...Mark > -----Original Message----- > From: Brian F. G. Bidulock [mailto:bidulock@openss7.org] > Sent: 09 February 2001 12:23 > To: Watson, Mark [MAIFP:EP11-M:EXCH] > Cc: Keith Robinson; Gonzalo.Camarillo@lmf.ericsson.se; > christer.holmberg@lmf.ericsson.se; Moloney, Joshua [MDN05:CT07:EXCH]; > Taylor, Tom-PT [NORSE:B901:EXCH]; sip@lists.bell-labs.com > Subject: Re: [SIP] Overlap call setup > > > Mark, > > Gee, the last DMS-100 I datafilled didn't have country code tables > filled out but seemed to work just fine using method a). Maybe that's > cause an overseas call has a post-dial delay anywhere from 30 to 40 > seconds so that 3 second delay at the end didn't matter. Maybe it was > because callers were astute enough to know that they could abbreviate > the timeout by hitting '#' at the end of the dial sequence. > > North America doesn't use overlap sending to my knowledge at all. > Perhaps it is because we don't have too many open dial-plans here (or > maybe people can find the '#' or 'send' key). > > Nevertheless, the rule for the PSTN is terminating switch always gets > digits en bloc (cause it needs all of them to route). The only place > that overlap sending gets used heavily is calls into an international > gateway switch (which should know how many to collect anyway > because it > has country code tables and can send en bloc from there). > > I still don't see a meaningful example of when this would be used and > truly believe that you are working too hard on a corner solution. > > But, don't let me stop you: knock yourself out ;) > > --Brian > > > Mark Watson wrote: (Thu, 08 Feb 2001 > 17:50:15) > > > > There are other reasons for overlap which are not to do with > > outpulsing delay/CAS interworking, but rather to do with determining > > end of dialling. > > > > 1) Support of open dial-plans, where not even the > terminating exchange > > knows how many digits to expect, only the user equipment knows this > > > > 2) Simplification of routing data, so not all exchanges have to know > > the global dial-plan in order to work out how many digits to expect > > > > In the absence of an indication of end-of-dialling from the calling > > user you have only two choices: > > a) Run an inter-digit timer and assume end of dialling if it expires > > b) Overlap digits through the network towards a point where > the end of > > dialling can be determined from dial-plan knowledge > > > > It is generally felt that for networks puporting to offer PSTN or > > better services, (a) is not acceptable as it adds post-dial > delay and > > can mis-identify end of dialling if the user is too slow. > > > > Of course an end-of-dialling indication from the user is highly > > desirable, which is why all systems more advanced than simple > > telephony are based on this (mobile phones, ISDN, SIP), but systems > > exist, and will continue to exist for many decades, which do not > > provide this. > > > > I believe there are important flaws in the mechanisms in the RFC and > > isup mapping draft. Not least the requirements to have multiple > > outstanding call legs for each extra digit, to use a whole > INVITE for > > a single digit and to tie these into a single call instance on the > > ISUP side of a gateway could not be described as elegant. > > > > We seem to be near reasonable solution based on negotiating > the use of > > INFOs - I think we should go ahead and document this so that we can > > bottom out the details. > > > > Regards, > > > > Mark Watson > > Nortel Networks > > > > -- > Brian F. G. Bidulock Ś The reasonable man adapts himself to the Ś > bidulock@openss7.org Ś world; the unreasonable one persists in Ś > http://www.openss7.org/ Ś trying to adapt the world to himself. Ś > Ś Therefore all progress depends on the Ś > Ś unreasonable man. -- George Bernard Shaw Ś > ------_=_NextPart_001_01C0A0BD.BDEA0EB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Overlap call setup

Brian,

> Nevertheless, the rule for the PSTN is = terminating switch always gets
> digits en bloc (cause it needs all of them to = route).#

Not in Germay it doesn't. The dial plan is so open = that not even the terminating switch knows how many digits there are = going to be - it's only the CPE that knows.

The only place
> that overlap sending gets used heavily is calls = into an international
> gateway switch (which should know how many to = collect anyway
> because it
> has country code tables and can send en bloc = from there).

Overlap sending is certainly used on almost all calls = in the UK - admittedly not because it has to, but more because it has = always been done that way.

...Mark

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:bidulock@openss7.org]
> Sent: 09 February 2001 12:23
> To: Watson, Mark [MAIFP:EP11-M:EXCH]
> Cc: Keith Robinson; = Gonzalo.Camarillo@lmf.ericsson.se;
> christer.holmberg@lmf.ericsson.se; Moloney, = Joshua [MDN05:CT07:EXCH];
> Taylor, Tom-PT [NORSE:B901:EXCH]; = sip@lists.bell-labs.com
> Subject: Re: [SIP] Overlap call setup
>
>
> Mark,
>
> Gee, the last DMS-100 I datafilled didn't have = country code tables
> filled out but seemed to work just fine using = method a).  Maybe that's
> cause an overseas call has a post-dial delay = anywhere from 30 to 40
> seconds so that 3 second delay at the end = didn't matter.  Maybe it was
> because callers were astute enough to know that = they could abbreviate
> the timeout by hitting '#' at the end of the = dial sequence.
>
> North America doesn't use overlap sending to my = knowledge at all.
> Perhaps it is because we don't have too many = open dial-plans here (or
> maybe people can find the '#' or 'send' = key).
>
> Nevertheless, the rule for the PSTN is = terminating switch always gets
> digits en bloc (cause it needs all of them to = route).  The only place
> that overlap sending gets used heavily is calls = into an international
> gateway switch (which should know how many to = collect anyway
> because it
> has country code tables and can send en bloc = from there).
>
> I still don't see a meaningful example of when = this would be used and
> truly believe that you are working too hard on = a corner solution.
>
> But, don't let me stop you: knock yourself out = ;)
>
> --Brian
>
>
> Mark Watson = wrote:           =             =    (Thu, 08 Feb 2001
> 17:50:15)
> >
> > There are other reasons for overlap which = are not to do with
> > outpulsing delay/CAS interworking, but = rather to do with determining
> > end of dialling.
> >   
> > 1) Support of open dial-plans, where not = even the
> terminating exchange
> > knows how many digits to expect, only the = user equipment knows this
> >   
> > 2) Simplification of routing data, so not = all exchanges have to know
> > the global dial-plan in order to work out = how many digits to expect
> >   
> > In the absence of an indication of = end-of-dialling from the calling
> > user you have only two choices:
> > a) Run an inter-digit timer and assume end = of dialling if it expires
> > b) Overlap digits through the network = towards a point where
> the end of
> > dialling can be determined from dial-plan = knowledge
> >   
> > It is generally felt that for networks = puporting to offer PSTN or
> > better services, (a) is not acceptable as = it adds post-dial
> delay and
> > can mis-identify end of dialling if the = user is too slow.
> >   
> > Of course an end-of-dialling indication = from the user is highly
> > desirable, which is why all systems more = advanced than simple
> > telephony are based on this (mobile = phones, ISDN, SIP), but systems
> > exist, and will continue to exist for many = decades, which do not
> > provide this.
> >   
> > I believe there are important flaws in the = mechanisms in the RFC and
> > isup mapping draft. Not least the = requirements to have multiple
> > outstanding call legs for each extra = digit, to use a whole
> INVITE for
> > a single digit and to tie these into a = single call instance on the
> > ISUP side of a gateway could not be = described as elegant.
> >   
> > We seem to be near reasonable solution = based on negotiating
> the use of
> > INFOs - I think we should go ahead and = document this so that we can
> > bottom out the details.
> >   
> > Regards,
> >   
> > Mark Watson
> > Nortel Networks
> >   
>
> --
> Brian F. G. Bidulock    =A6 The = reasonable man adapts himself to the =A6
> bidulock@openss7.org    =A6 = world; the unreasonable one persists in  =A6
> http://www.openss7.org/ =A6 trying  to adapt = the  world  to himself. =A6
>          = ;            = ;   =A6 Therefore  all  progress  depends on = the =A6
>          = ;            = ;   =A6 unreasonable man. -- George Bernard Shaw =A6
>

------_=_NextPart_001_01C0A0BD.BDEA0EB0-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 08:13:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06952 for ; Tue, 27 Feb 2001 08:13:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 761F24435E; Tue, 27 Feb 2001 08:13:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id E186644336 for ; Tue, 27 Feb 2001 08:12:34 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Tue, 27 Feb 2001 13:10:39 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 13:10:25 -0000 Message-ID: From: "Mark Watson" To: "'Dean Willis'" , "Mark Watson" , sip Subject: RE: [SIP] Early media MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A0BE.A4F76140" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 13:10:23 -0000 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_01C0A0BE.A4F76140 Content-Type: text/plain; charset="iso-8859-1" Hi, Perhaps I'm missing something. The notes seemed to indicate that SDP SHOULD NOT be sent backwards before the 200 OK, but you are indicating that the ability to have *backwards* media path is still available before the 200 OK. I know that in many scenarios, the backwards SDP is not required in order to allow backwards media, but we are surely not making this a blanket assumption ? What about when there is QoS reservation going on, does the manyfolks mechanism provide a way of sending the SDP backwards which is not subject to the SHOULD NOT discussed at the meeting ? Apologies if I've just misunderstood ? Regards, Mark -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: 16 February 2001 17:11 To: Watson, Mark [MAIFP:EP11-M:EXCH]; sip Subject: Re: [SIP] Early media Gee, I HOPE not. Real world scenarios -- my office uses only SIP phones with a PSTN gateway for outside communications. The first "hello" is almost universally clipped. Most annoying. My recollection of recent discussion of basic call flows (no special "early media") is that the UAC SHOULD be ready to receive media at the time the INVITE is transmitted. It SHOULD not send media until after it has sent ACK in response to a 200 OK. -- Dean ----- Original Message ----- From: Mark Watson To: sip Sent: Friday, February 16, 2001 9:57 AM Subject: [SIP] Early media All, The notes from the meeting earlier this month seem to indicate an agreement to deprecate early media i.e. to include a SHOULD NOT in respect of media before the 200 OK of the INVITE. Is this a correct understanding of what was agreed ? I seem to remember this issue being discussed extensively on this list late last year and there were strong feelings expressed against changing the semantics of the 200 response to the INVITE. Presently it corresponds to called party answer, but the change above would alter this. Was a solution to these concerns also identified at the meeting ? Does this deprecation apply to the setting up of the media path before 200 OK for QoS assurance, or just when the intention is to play the backwards media to the caller ? Regards, Mark Watson Nortel Networks > -----Original Message----- > From: Kevin Summers [ mailto:Kevin.Summers@sonusnet.com ] > Sent: 16 February 2001 14:45 > To: Jacco de Kraker (ELN); sip > Subject: RE: [SIP] transcripts interim meeting? (esp. REFER issue) > > > > http://www.softarmor.com/sipwg/meets/interim-feb-01/index.html > > -----Original Message----- > From: Jacco de Kraker (ELN) [ mailto:Jacco.de.Kraker@eln.ericsson.se ] > Sent: Friday, February 16, 2001 8:32 AM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] transcripts interim meeting? (esp. REFER issue) > > > Hi all, > > Are any transcripts of the interim meeting of last week available > somewhere on the Internet? I assumed some of the discussed issues > would show up on this list, but I haven't seen anything about it. > I'm especially interested in any decisions/clarifications/new problems > related to the REFER issue. > > If anybody knows where I can find transcripts of the 8-9 February > meeting, please tell the list. I'm sure I'm not the only one > interested. > > Regards, > > /Jacco > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementer's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to majordomo@cs.columbia.edu with > "subscribe sip-implementors" in the body. > ------_=_NextPart_001_01C0A0BE.A4F76140 Content-Type: text/html; charset="iso-8859-1" Early media
Hi,
 
Perhaps I'm missing something. The notes seemed to indicate that SDP SHOULD NOT be sent backwards before the 200 OK, but you are indicating that the ability to have *backwards* media path is still available before the 200 OK.
 
I know that in many scenarios, the backwards SDP is not required in order to allow backwards media, but we are surely not making this a blanket assumption ? What about when there is QoS reservation going on, does the manyfolks mechanism provide a way of sending the SDP backwards which is not subject to the SHOULD NOT discussed at the meeting ?
 
Apologies if I've just misunderstood ?
 
Regards,
 
Mark
 
-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: 16 February 2001 17:11
To: Watson, Mark [MAIFP:EP11-M:EXCH]; sip
Subject: Re: [SIP] Early media

Gee, I HOPE not.
 
Real world scenarios -- my office uses only SIP phones with a PSTN gateway for outside communications. The first "hello" is almost universally clipped. Most annoying.
 
My recollection of recent discussion of basic call flows (no special "early media") is that the UAC SHOULD be ready to receive media at the time the INVITE is transmitted. It SHOULD not send media until after it has sent ACK in response to a 200 OK.
 
--
Dean
 
 
 
----- Original Message -----
To: sip
Sent: Friday, February 16, 2001 9:57 AM
Subject: [SIP] Early media

All,

The notes from the meeting earlier this month seem to indicate an agreement to deprecate early media i.e. to include a SHOULD NOT in respect of media before the 200 OK of the INVITE.

Is this a correct understanding of what was agreed ?

I seem to remember this issue being discussed extensively on this list late last year and there were strong feelings expressed against changing the semantics of the 200 response to the INVITE. Presently it corresponds to called party answer, but the change above would alter this.

Was a solution to these concerns also identified at the meeting ?

Does this deprecation apply to the setting up of the media path before 200 OK for QoS assurance, or just when the intention is to play the backwards media to the caller ?

Regards,

Mark Watson
Nortel Networks

> -----Original Message-----
> From: Kevin Summers [mailto:Kevin.Summers@sonusnet.com]
> Sent: 16 February 2001 14:45
> To: Jacco de Kraker (ELN); sip
> Subject: RE: [SIP] transcripts interim meeting? (esp. REFER issue)
>
>
>
> http://www.softarmor.com/sipwg/meets/interim-feb-01/index.html
>
> -----Original Message-----
> From: Jacco de Kraker (ELN) [mailto:Jacco.de.Kraker@eln.ericsson.se]
> Sent: Friday, February 16, 2001 8:32 AM
> To: 'sip@lists.bell-labs.com'
> Subject: [SIP] transcripts interim meeting? (esp. REFER issue)
>
>
> Hi all,
>
> Are any transcripts of the interim meeting of last week available
> somewhere on the Internet? I assumed some of the discussed issues
> would show up on this list, but I haven't seen anything about it.
> I'm especially interested in any decisions/clarifications/new problems
> related to the REFER issue.
>
> If anybody knows where I can find transcripts of the 8-9 February
> meeting, please tell the list. I'm sure I'm not the only one
> interested.
>
> Regards,
>
> /Jacco
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
>

------_=_NextPart_001_01C0A0BE.A4F76140-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 10:16:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11784 for ; Tue, 27 Feb 2001 10:16:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 30BD64434B; Tue, 27 Feb 2001 10:16:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange.satyam.net.in (unknown [202.144.12.32]) by lists.bell-labs.com (Postfix) with ESMTP id B573A44361 for ; Tue, 27 Feb 2001 04:53:57 -0500 (EST) Received: from HQBNG01EXFE01.mindtree.com (lan-202-144-95-250.maa.sify.net [202.144.95.250] (may be forged)) by exchange.satyam.net.in (8.9.3/8.9.3) with ESMTP id PAA25162; Tue, 27 Feb 2001 15:23:35 +0530 Received: from mtv01ex01.mindtree.com ([172.20.32.4]) by HQBNG01EXFE01.mindtree.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 27 Feb 2001 15:23:24 +0530 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [SIP] permanent/temporary registration Content-Type: text/plain; charset="iso-8859-1" x-mimeole: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <2330401A6FE03445ADA682F5EBB7502D31BA36@mtv01ex01.mindtree.com> Thread-Topic: [SIP] permanent/temporary registration Thread-Index: AcCggN7WdcxUj/CFRQKuvmEGlfy1DgAIbeGA From: "Mayank Sharma" To: "Baniel Uri-CUB001" , Cc: X-OriginalArrivalTime: 27 Feb 2001 09:53:24.0726 (UTC) FILETIME=[203B8960:01C0A0A3] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 15:23:24 +0530 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA11784 Hi, > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Tuesday, February 27, 2001 11:17 AM > To: sip@lists.bell-labs.com > Subject: [SIP] permanent/temporary registration > > > Must a registration interval have a ceiling? I.e. Can I have > my SIP phone at home be registered for ever (say as my I don't think you have a ceiling on the registaration interval. You can register your SIP phone for ever (well almost by specifying a very high value in the expires). The default interval however happens to be 2 hr. > default SIP phone) while other SIP phones I use on a > temporary basis (i.e. the SIP phone at office or Lab) would > be typically registered at the registrar for a limited period of time? yes it can be done regards, Mayank Sharma _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 10:18:27 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11876 for ; Tue, 27 Feb 2001 10:18:26 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 49D094435B; Tue, 27 Feb 2001 10:16:25 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 6187944336 for ; Tue, 27 Feb 2001 06:51:07 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03716; Tue, 27 Feb 2001 06:51:06 -0500 (EST) Message-Id: <200102271151.GAA03716@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-sterman-sip-radius-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 06:51:05 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Digest Authentication in SIP using RADIUS Author(s) : B. Sterman Filename : draft-sterman-sip-radius-00.txt Pages : 7 Date : 26-Feb-01 This document examines the proposal for a SIP extension to allow authentication of a user-agent through a proxy to a RADIUS server using CHAP put forward by Byerly and Williams [BYERLY]. An alternative method is offered which does not require any changes to the SIP protocol as defined in [SIP]. It also will not require any modification to the way RADIUS clients communicate with RADIUS Servers [RADIUS], although it will change the way some of the fields are interpreted by the RADIUS server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sterman-sip-radius-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-sterman-sip-radius-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-sterman-sip-radius-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: <20010226143204.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sterman-sip-radius-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sterman-sip-radius-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010226143204.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 10:21:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12086 for ; Tue, 27 Feb 2001 10:21:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D210F4436D; Tue, 27 Feb 2001 10:16:39 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by lists.bell-labs.com (Postfix) with ESMTP id 0A45D44336 for ; Tue, 27 Feb 2001 10:09:56 -0500 (EST) Received: from viruswall.entp.attws.com (nproxy.attws.com [155.176.34.70]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id HAA18106; Tue, 27 Feb 2001 07:09:01 -0800 (PST) Received: from nwestmail.entp.attws.com by viruswall.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc. V8 version 2) id HAA12240; Tue, 27 Feb 2001 07:09:52 -0800 (PST) Received: from hq-msgbh.entp.attws.com (hq-msgbh.entp.attws.com [155.176.15.68]) by nwestmail.entp.attws.com (8.8.8+Sun/8.8.8) with ESMTP id HAA17441; Tue, 27 Feb 2001 07:09:52 -0800 (PST) Received: by hq-msgbh.entp.attws.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Feb 2001 07:09:52 -0800 Message-ID: From: "Daly, Brian" To: "'drage@lucent.com'" , "Roy, Radhika (AT&T)" Cc: "'sip@lists.bell-labs.com'" , "Daly, Brian" Subject: FW: [SIP] 3GPP current needs from SIP drafts MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 07:09:48 -0800 Keith: You are correct -- 3GPP and AT&T Wireless is not looking at SIP for mobility in R5; we are using GPRS for mobility management in R5. We do not believe the SIP mobility-related drafts are of interest for R5. ====================== Brian K. Daly Director - Technology Architecture AT&T Wireless Services, Inc. PO Box 97061 Redmond, WA 98073-9761 Street Address (FedEx, etc.): 7277 164th Ave NE Redmond, WA 98052 Voice: +1.425.580.6873 Fax: +1.425.580.6811 Text Messaging: 2063906792@mobile.att.net E-mail: brian.daly@attws.com -----Original Message----- From: Sennett, DeWayne Sent: Monday, February 26, 2001 9:34 PM To: Musgrove, Peter; Myhre, John; Daly, Brian; Leuca, Ileana Cc: Sennett, DeWayne Subject: FW: [SIP] 3GPP current needs from SIP drafts FYI DeWayne A. Sennett Principle Member Technical Team AT&T Wireless Office Number: +1.425.580.6847 Fax Number: +1.425.580.6811 e-mail: dewayne.sennett@attws.com U.S. Mail: P.O. Box 97061, Redmond, WA USA 98073-9761 Packages & Visits: 7277 164th Ave. N.E., Redmond, WA USA 98052 -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com] Sent: Monday, February 26, 2001 3:43 PM To: Drage, Keith (Keith); 'sip@lists.bell-labs.com'; Roy, Radhika R, ALCOO Subject: RE: [SIP] 3GPP current needs from SIP drafts If I understand your point correctly, and which drafts you are referring to, then I have to reply that 3GPP are not looking at SIP for mobility, merely to use SIP for session control in a mobile environment. Mobility management in 3GPP release 5 will be handled by the underlying General Packet Radio Service (GPRS) alothough more other IP strategies are being looked at for future releases. Also the mobility related drafts expired some time ago, and I have not noted much interest in reviving them (a comment that is invariably a prelude to screams of protest!!!). Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Roy, Radhika R, ALCOO[SMTP:rrroy@att.com] > Sent: 23 February 2001 15:14 > To: Drage, Keith (Keith); 'sip@lists.bell-labs.com' > Subject: RE: [SIP] 3GPP current needs from SIP drafts > > Please see the following URL where you will also see couple of SIP I-Ds > that > deal with mobility in SIP: > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Friday, February 23, 2001 5:25 AM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] 3GPP current needs from SIP drafts > > > Hannu has circulated a summary of the last 3GPP discussion on the use of > SIP. > > As there was a discussion in the IETF SIP WG ad-hoc on what drafts 3GPP > was > currently looking at from the IETF, I undertook to provide the current > list. > > Before I give the list, I must stress that it is preliminary. The basis > for > the list is the flows that currently exist in 24.228, and the elements of > signalling that they use. Therefore the list is probably incomplete > because > 24.228 is incomplete, and may be wrong, because 24.228 is still at a stage > where comments can significantly change its contents. > > We are intending contributing significant parts of 24.228 to the SIP WG > for > you to analyse, discuss, pull apart, comment on or whatever. > > The list is currently as follows: > > draft-ietf-sip-rfc2543bis SIP: Session Initiation Protocol > draft-sip-manyfolks-resource Integration of resource management and SIP > draft-ietf-sip-100rel Reliability of Provisional Responses in SIP > draft-ietf-sip-privacy SIP extensions for caller identity > and > privacy > draft-ietf-sip-call-auth SIP extensions for media > authorization > > The N1-010273 that was referred to in previous discussion on this list, is > the 3GPP work item description. This document evolves from meeting to > meeting (changing tdoc numbers as it goes!!!!), and will be used to > maintain > the list of areas where we are dependent on IETF work. 3GPP intends to > keep > you directly informed as that list changes. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 10:35:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12741 for ; Tue, 27 Feb 2001 10:35:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C621844378; Tue, 27 Feb 2001 10:35:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4D62D44375 for ; Tue, 27 Feb 2001 10:34:41 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13480; Tue, 27 Feb 2001 07:34:31 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09223; Tue, 27 Feb 2001 07:34:30 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA04923; Tue, 27 Feb 2001 07:34:25 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: FW: [SIP] 3GPP current needs from SIP drafts To: "Daly, Brian" Cc: "'drage@lucent.com'" , "Roy, Radhika (AT&T)" , "'sip@lists.bell-labs.com'" , "Daly, Brian" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 07:30:06 -0800 (PST) and for what it's worth, 3GPP2 is using Mobile IP as its mobility management protocol, and does not currently have any plans to use SIP as a mobility management protocol. PatC > Keith: > > You are correct -- 3GPP and AT&T Wireless is not looking at SIP for mobility > in R5; we are using GPRS for mobility management in R5. We do not believe > the SIP mobility-related drafts are of interest for R5. > > ====================== > Brian K. Daly > Director - Technology Architecture > AT&T Wireless Services, Inc. > PO Box 97061 > Redmond, WA 98073-9761 > > Street Address (FedEx, etc.): > 7277 164th Ave NE > Redmond, WA 98052 > > Voice: +1.425.580.6873 > Fax: +1.425.580.6811 > Text Messaging: 2063906792@mobile.att.net > E-mail: brian.daly@attws.com > > > > -----Original Message----- > From: Sennett, DeWayne > Sent: Monday, February 26, 2001 9:34 PM > To: Musgrove, Peter; Myhre, John; Daly, Brian; Leuca, Ileana > Cc: Sennett, DeWayne > Subject: FW: [SIP] 3GPP current needs from SIP drafts > > > FYI > > DeWayne A. Sennett > Principle Member Technical Team > AT&T Wireless > Office Number: +1.425.580.6847 > Fax Number: +1.425.580.6811 > e-mail: dewayne.sennett@attws.com > U.S. Mail: P.O. Box 97061, Redmond, WA USA 98073-9761 > Packages & Visits: 7277 164th Ave. N.E., Redmond, WA USA 98052 > > > > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: Monday, February 26, 2001 3:43 PM > To: Drage, Keith (Keith); 'sip@lists.bell-labs.com'; Roy, Radhika R, > ALCOO > Subject: RE: [SIP] 3GPP current needs from SIP drafts > > > If I understand your point correctly, and which drafts you are referring to, > then I have to reply that 3GPP are not looking at SIP for mobility, merely > to use SIP for session control in a mobile environment. > > Mobility management in 3GPP release 5 will be handled by the underlying > General Packet Radio Service (GPRS) alothough more other IP strategies are > being looked at for future releases. > > Also the mobility related drafts expired some time ago, and I have not noted > much interest in reviving them (a comment that is invariably a prelude to > screams of protest!!!). > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > ---------- > > From: Roy, Radhika R, ALCOO[SMTP:rrroy@att.com] > > Sent: 23 February 2001 15:14 > > To: Drage, Keith (Keith); 'sip@lists.bell-labs.com' > > Subject: RE: [SIP] 3GPP current needs from SIP drafts > > > > Please see the following URL where you will also see couple of SIP I-Ds > > that > > deal with mobility in SIP: > > > > http://www.cs.columbia.edu/~hgs/sip/drafts.html > > > > -----Original Message----- > > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > > Sent: Friday, February 23, 2001 5:25 AM > > To: 'sip@lists.bell-labs.com' > > Subject: [SIP] 3GPP current needs from SIP drafts > > > > > > Hannu has circulated a summary of the last 3GPP discussion on the use of > > SIP. > > > > As there was a discussion in the IETF SIP WG ad-hoc on what drafts 3GPP > > was > > currently looking at from the IETF, I undertook to provide the current > > list. > > > > Before I give the list, I must stress that it is preliminary. The basis > > for > > the list is the flows that currently exist in 24.228, and the elements of > > signalling that they use. Therefore the list is probably incomplete > > because > > 24.228 is incomplete, and may be wrong, because 24.228 is still at a stage > > where comments can significantly change its contents. > > > > We are intending contributing significant parts of 24.228 to the SIP WG > > for > > you to analyse, discuss, pull apart, comment on or whatever. > > > > The list is currently as follows: > > > > draft-ietf-sip-rfc2543bis SIP: Session Initiation Protocol > > draft-sip-manyfolks-resource Integration of resource management and SIP > > draft-ietf-sip-100rel Reliability of Provisional Responses in SIP > > draft-ietf-sip-privacy SIP extensions for caller identity > > and > > privacy > > draft-ietf-sip-call-auth SIP extensions for media > > authorization > > > > The N1-010273 that was referred to in previous discussion on this list, is > > the 3GPP work item description. This document evolves from meeting to > > meeting (changing tdoc numbers as it goes!!!!), and will be used to > > maintain > > the list of areas where we are dependent on IETF work. 3GPP intends to > > keep > > you directly informed as that list changes. > > > > Keith > > > > Keith Drage > > Lucent Technologies > > Tel: +44 1793 776249 > > Email: drage@lucent.com > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementor's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > > _______________________________________________ > > This list is for continuing development of the SIP protocol. > > The sip-implementor's list is the place to discuss implementation, > > and to receive advice on understanding existing sip. > > To subscribe to it, send mail to > > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 11:01:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14117 for ; Tue, 27 Feb 2001 11:01:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A102044359; Tue, 27 Feb 2001 11:01:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id 2247044350 for ; Tue, 27 Feb 2001 11:00:09 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA00951 for ; Tue, 27 Feb 2001 08:59:59 -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 IAA02041 for ; Tue, 27 Feb 2001 08:55:30 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58) id <13DSZH78>; Tue, 27 Feb 2001 09:59:59 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8C9F@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'James Undery'" , Mayank Sharma Cc: Baniel Uri-CUB001 , sip@lists.bell-labs.com, sip-implementors@cs.columbia.edu Subject: RE: [Sip-implementors] RE: [SIP] permanent/temporary registration MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="ISO-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 09:59:46 -0600 >Well 1hr for sip urls and forever for non sip urls, although the registrar >may shorten any registration it receives so the expires in the response must >be checked. That is exactly the Bis02 section which made me concerned... Say I want to register the FQDN (Host name) or either IP address of my SIP phone at home as my 'permanent' contact. Does that fall under the definition of a SIP URL and thus forbidden or other URL and thus is OK? I mean is it just a matter of 'tricking' the registrar and providing it my 'contact' information as a non SIP URL? e.g. SIP:user1@myMachine.sip.xxx.com => myMachine.sip.xxx.com =========================================== Uri.Baniel@motorola.com, Tel: (847) 632 4616; Fax: (847) 632 3963; =========================================== > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Tuesday, February 27, 2001 4:45 AM > To: Mayank Sharma > Cc: Baniel Uri-CUB001; sip@lists.bell-labs.com; > sip-implementors@cs.columbia.edu > Subject: Re: [Sip-implementors] RE: [SIP] permanent/temporary > registration > > > > > Mayank Sharma wrote: > > > Hi, > > > > > -----Original Message----- > > > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > > > Sent: Tuesday, February 27, 2001 11:17 AM > > > To: sip@lists.bell-labs.com > > > Subject: [SIP] permanent/temporary registration > > > > > > > > > Must a registration interval have a ceiling? I.e. Can I have > > > my SIP phone at home be registered for ever (say as my > > > > I don't think you have a ceiling on the registaration > interval. You can > > register your > > SIP phone for ever (well almost by specifying a very high > value in the > > expires). The default > > interval however happens to be 2 hr. > > Well 1hr for sip urls and forever for non sip urls, although > the registrar > may shorten any registration it receives so the expires in > the response must > be checked. > > > > > > > > default SIP phone) while other SIP phones I use on a > > > temporary basis (i.e. the SIP phone at office or Lab) would > > > be typically registered at the registrar for a limited > period of time? > > > > yes it can be done > > > > regards, > > Mayank Sharma > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 11:57:10 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17619 for ; Tue, 27 Feb 2001 11:57:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E776744381; Tue, 27 Feb 2001 11:57:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from bfgbhome.inetint.com (tnt-dal-171.dallas.net [209.44.41.171]) by lists.bell-labs.com (Postfix) with ESMTP id 25F4744336 for ; Tue, 27 Feb 2001 11:53:18 -0500 (EST) Received: (from brian@localhost) by bfgbhome.inetint.com (8.9.3/8.9.3) id KAA03689; Tue, 27 Feb 2001 10:46:14 -0600 From: "Brian F. G. Bidulock" To: Mark Watson Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Overlap call setup Message-ID: <20010227104613.A22669@bfgbhome> Reply-To: bidulock@openss7.org Mail-Followup-To: Mark Watson , sip@lists.bell-labs.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from mwatson@nortelnetworks.com on Tue, Feb 27, 2001 at 01:03:56PM -0000 Organization: http://www.openss7.org/ Dsn-Notification-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 10:46:14 -0600 Content-Transfer-Encoding: 8bit Mark, On Tue, 27 Feb 2001, Mark Watson wrote: > > > Nevertheless, the rule for the PSTN is terminating switch always > > gets digits en bloc (cause it needs all of them to route).# > > Not in Germay it doesn't. The dial plan is so open that not even > the terminating switch knows how many digits there are going to be > - it's only the CPE that knows. This is still not a reason to do overlap. Collect all of the digits at the UA (or at the gateway) and send them en bloc. If the terminating CPE doesn't have enough to connect, send PSPD treatment. If it does connect. If the caller doesn't know how many digits to provide, they're hosed anyway. This is really a numbering plan issue (more for the likes of ENUM) rather than a SIP issue. If a numbering plan routing database cannot provide information concerning the minimum and maximum number of digits to collect and when to go into short timing, what will ever provide it? Digit by digit collection is not a solution. If the CPE knows the private dial plan, it should export that numbering plan information to the network in the form of a dial plan usable at the gateway. If not part of a numbering plan, it should at least be part of registration. The only reason this persists in the PSTN is because of the inability of terminating equipment to communicate with the network and the unwillingness of operators to make up for it with manual provisioning. Would you suggest that we overlap from SIP UA to PSTN as well? > > > The only place that overlap sending gets used heavily is calls > > into an international gateway switch (which should know how many > > to collect anyway because it has country code tables and can send > > en bloc from there). > > Overlap sending is certainly used on almost all calls in the UK - > admittedly not because it has to, but more because it has always > been done that way. Convert from overlap to en bloc at the gateway. Noone is questioning whether a gateway should accept SAMs, just don't propagate them through the SIP network. -- Brian F. G. Bidulock Ś The reasonable man adapts himself to the Ś bidulock@openss7.org Ś world; the unreasonable one persists in Ś http://www.openss7.org/ Ś trying to adapt the world to himself. Ś Ś Therefore all progress depends on the Ś Ś unreasonable man. -- George Bernard Shaw Ś _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 16:42:15 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01144 for ; Tue, 27 Feb 2001 16:42:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 964AD4433C; Tue, 27 Feb 2001 16:42:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 5F9D944336 for ; Tue, 27 Feb 2001 16:41:28 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA03366; Tue, 27 Feb 2001 13:41:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABS04909; Tue, 27 Feb 2001 13:41:25 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA19247; Tue, 27 Feb 2001 13:41:25 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15004.7941.141548.556514@thomasm-u1.cisco.com> To: Sean Olson Cc: Neil Deason , sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? In-Reply-To: <3A9AE447.3080303@ericsson.com> References: <7BA41B5547CCD411833B0002A52CD457D5105B@enlrynt306.etm.ericsson.se> <3A9A5494.A5408430@ubiquity.net> <3A9A626D.E83DFE3@cs.columbia.edu> <3A9A7830.2000203@ericsson.com> <3A9A8793.9529C0AD@ubiquity.net> <3A9AE447.3080303@ericsson.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 13:41:25 -0800 (PST) Content-Transfer-Encoding: 7bit Sean Olson writes: > > Neil Deason wrote: > > > >>From what I have seen of the 3GPP docs it appears there > > could be the potential for a lot of state information being > > stored in these servers. P-CSCFs might be expected to > > maintain mappings of hidden/unhidden Vias, user registrations, > > session signalling paths and even individual call path info > > (when they strip out all Via headers before passing INVITEs > > to called parties)? This type of behaviour means you lose the > > scalability and reliability features for network servers > > that were intended with SIP. > > I agree with the principle of favoring stateless > proxies over stateful proxies. But there are cases > where you need to store state in the network. In the > particular 3GPP scenarios you mention, I don't believe > scalability is at risk. While it's hard to tell whether my hearsay understanding of CSCF is screwed up, or whether it's just the general murkiness of all of this, I was under the impression that the CSCF was more akin to a proxy bolted to a B2BUA. If this is still the case, I'd say that both scalability, but more importantly *robustness* are at issue. Not to mention e2e transparency. > Performance, yes, but not > scalability. Reliability is of course an issue. Do > you move reliability into the endpoints or leave it > in the network? You can argue for both cases. Sure, but fate sharing is very nice property. The CSCF isn't fate shared and that's troubling. > The choice of SIP is now fixed. We are working to > utilize SIP in the best manner possible while > working within the constraints of a wireless network. I'm having a hard time understanding what constraints that the wireless network would put on doing this right (ie, the handsets are real, not crippled, UA's). I got the impression that this was born out of some weird assumptions of garden walls, rationalized with a helping of "phones too stupid." Mike _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Tue Feb 27 17:37:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03496 for ; Tue, 27 Feb 2001 17:37:22 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 690104434C; Tue, 27 Feb 2001 17:37:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id B8A9344336 for ; Tue, 27 Feb 2001 17:36:42 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 30A751E0A4; Tue, 27 Feb 2001 17:36:42 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA19651; Tue, 27 Feb 2001 17:36:38 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (SGI-8.9.3/8.8.5) id RAA81062; Tue, 27 Feb 2001 17:36:38 -0500 (EST) Message-Id: <200102272236.RAA81062@fish-ha.research.att.com> To: rohan@cisco.com Cc: sip@lists.bell-labs.com Subject: [SIP] Re: removing the bis draft dependency from manyfolks Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 17:36:38 -0500 (EST) Rohan, Your approach was certainly considered; the main problem was a UAS that doesn't ring -- it would then send a 200-OK that means "I will complete the call _as soon as my preconditions are satisfied_." Now there is no way to signal an error, and all the semantics of media flow timings are different. Further, it means the manyfolks-based-on-2543 would have different call flows than manyfolks-based-on-bis; not desirable. Seems much better to slightly increase the documentation, and keep the semantics of each message the same as the draft had previously defined. I expect the updated draft will be out shortly.... Bill Marshall wtm@research.att.com -----original message----- Date: Mon, 26 Feb 2001 14:24:52 -0800 To: wtm@research.att.com From: Rohan Mahy Subject: removing the bis draft dependency from manyfolks Cc: sip@lists.bell-labs.com, rohan@cisco.com Hi, There is a very simple way to remove the dependency of manyfolks on the bis draft. Simply change the behavior in manyfolks such that 180/181/182 with preconditions means "I will ring/alert/notify the phone _as soon as my preconditions are satisfied_." Only a few lines of text need to be replaced: (from Section 8.1): >Upon receipt of the COMET message, the UAC/UAS continues normal SIP > call handling, by (for a UAS) alerting the user and sending e.g. a > 180-Ringing or 200-OK response. ---> "Upon receipt of the COMET message (or the 200 response to the COMET), the UAS (or UAC) continues normal SIP call handling, by performing the action normally associated with sending or recieving the 18x provisional response (e.g. for a 180, the UAC plays local ringback and the UAS alerts the user)." (from Section 9.1) >At this point it alerts the user, and sends a 180- >Ringing provisional response. This provisional response is also >sent using the reliability mechanism of [12], resulting in a PRACK >message and 200-OK of the PRACK. --> "At this point it alerts the user. Upon receipt of the 200 response to the COMET, the UAC generates local ringback." Also replace: "183-Session-Progress" with "18x". If these small changes are made, the example flow already in the draft will still work (because the 183 has empty semantics, no action is postponed; the subsequent 180 will cause ringback immediately because preconditions are already satisfied). Also the shorter flow shown below will also work. Originating (UAC) Terminating (UAS) | SIP-Proxy(s) | | INVITE | | |---------------------->|---------------------->| | | | | 180 w/SDP | 180 w/SDP | * |<----------------------|<----------------------| * | | | PRACK | |---------------------------------------------->| | 200 OK (of PRACK) | |<----------------------------------------------| | Reservation Reservation | ===========> <=========== | | | | | COMET | |---------------------------------------------->| | 200 OK (of COMET) | |<----------------------------------------------| | | ** Local Ringback Played User Alerted ** | | | time passes ... | | | | User Picks-Up | SIP-Proxy(s) the phone | | | | 200 OK | 200 OK | |<----------------------|<----------------------| | | | | | | ACK | |---------------------------------------------->| Ringing and Ringback are delayed from * until ** . The Terminating UAS rings the phone when the COMET arrives. The Originating UAC plays local ringback when the 200 OK to the COMET arrives. Please consider this proposal. I feel this is both useful technically, as well as an ideal short-cut around more process-related delay. thanks, -rohan _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 02:04:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA25595 for ; Wed, 28 Feb 2001 02:04:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 16E1B4433E; Wed, 28 Feb 2001 02:04:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.130]) by lists.bell-labs.com (Postfix) with ESMTP id 889DD4433E for ; Wed, 28 Feb 2001 02:03:48 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Feb 2001 23:01:50 -0800 Received: from rwcjfmule01 (216.103.84.208 [216.103.84.208]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FXK3WW56; Tue, 27 Feb 2001 23:01:45 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Flemming Andreasen'" , "'Christer Holmberg'" , "'Culpepper, Bert'" Cc: sip@lists.bell-labs.com, Jieying Li Subject: RE: [SIP] T.38 - summary and upcoming draft 01 Message-ID: <039e01c0a154$6129fb80$e54b010a@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3A9ADD49.C99FFC3B@cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 27 Feb 2001 23:02:13 -0800 Content-Transfer-Encoding: 7bit To end this thread properly: Flemming, Bert and Christer: we would like to thank you for all the comments. As you have seen in the preliminary draft01 text, we believe the major comments have been addressed: - fax stream: the replacement of audio stream by fax stream which was really the only call flow in draft00 is the recommended one; a multi-media call flow has been added to illustrate the t38 annex D recommendations, - several call flows have been added accordingly, - section 4 has been completely rewritten and addresses your comments: CNG may trigger fax detection, CED must not be used to trigger fax switch-over, - the text has been clarified on the voice muting and msg details updated. We look forward to receiving more comments on draft01 and, more importantly, to demonstrating the true value of this BCP draft in the interop events, Jean-Francois. Clarent Corp. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Monday, February 26, 2001 2:49 PM > To: Jean-Francois Mule > Cc: 'Christer Holmberg'; 'Culpepper, Bert'; sip@lists.bell-labs.com; > Jieying Li > Subject: Re: [SIP] T.38 and multiple streams > > > > > Jean-Francois Mule wrote: > > > > Flemming Andreasen wrote: > > > >You are muting one when you want to use the other, so why > > > >have two in the first place ? > > > > Christer Holmberg wrote: > > > You want to continue the voice session after the fax has > been sent, so > > > by keeping the voice stream during the fax transmissoion you > > > don't have > > > to create a new voice stream after the fax, just "un-mute" > > > the existing one. > > > > There are pros and cons for both methods and I don't think > we should force a > > decision on this now. The SIP T.38 call flows will show > both options. We > > should leave that to vendors' implementations and see if it > does cause > > interop issues - I bet it does not unless your > implementation does not > > support multiple media connections per session. > > And that's the problem. There will be lots of devices out > there that will not > want to support more than one media stream at a time. > Considering this is to be > a BCP and you want to specify something that's interoperable, > I'd strongly > suggest that the mono-media solution is considered the > base-line that all > implementations should be expected to support. For those more > sophisticated > types of devices that allow you to send faxes and continue > talking at the same > time, I have no problem specifying a multi-media call flow > that adds an extra > active stream, however do note, that this is different from > what has been > discussed so far, which was a single active media stream. > > -- Flemming > > > > > > > Jean-Francois Mule. > > -- > Flemming Andreasen > Cisco Systems > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 07:07:16 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03611 for ; Wed, 28 Feb 2001 07:07:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B931544338; Wed, 28 Feb 2001 07:07:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id B2A7C44337 for ; Wed, 28 Feb 2001 07:06:15 -0500 (EST) Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com; Wed, 28 Feb 2001 12:03:52 +0000 Received: by znsgd00t.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Feb 2001 12:03:51 -0000 Message-ID: From: "Mark Watson" To: "'bidulock@openss7.org'" , "Mark Watson" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Overlap call setup MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A17E.7D6FE410" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 12:03:40 -0000 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_01C0A17E.7D6FE410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, You wrote: > This is still not a reason to do overlap. Collect all of the digits > at the UA (or at the gateway) and send them en bloc. If the=20 > terminating > CPE doesn't have enough to connect, send PSPD treatment. If it does > connect. If the caller doesn't know how many digits to=20 > provide, they're > hosed anyway. >=20 Of course the caller knows how many digits they have. The problem = occurs when they have no way to indicate end-of-dialling to their equipment. Of course whenever we can we will collect all the digits and go en-bloc = from there, but there remain cases where we simply cannot determine end-of-dialling. Our experience has universally been that our customers (service = providers) are not happy with using an inter-digit timer to guess when = end-of-dialling has occured - hence the need for overlap. Believe me, I do not *want* to support overlap. If there was any way of avoiding the requirement altogether, I would do so. The unfortunate = fact is that there exist scenarios where overlap is the only way of meeting our customers requirements. > The only reason this persists in the PSTN is because of the inability > of terminating equipment to communicate with the network and the > unwillingness of operators to make up for it with manual = provisioning. >=20 Yes, and the fact that the manual provisioning required is, in certain cases, completely impractical, or even impossible because the operator = does not have the information about number lengths in the PBXs. > Would you suggest that we overlap from SIP UA to PSTN as well? If you mean a 'real' UA (rather than a PSTN gateway), then no. I expect = that true SIP UAs will provide a means for the user to indicate = end-of-dialling, or indeed require the user to indicate end-of-dialling. Regards, Mark > > =20 > > > The only place that overlap sending gets used heavily is calls > > > into an international gateway switch (which should=20 > know how many > > > to collect anyway because it has country code tables=20 > and can send > > > en bloc from there). > > =20 > > Overlap sending is certainly used on almost all calls in the UK = - > > admittedly not because it has to, but more because it has always > > been done that way. >=20 > Convert from overlap to en bloc at the gateway. Noone is questioning > whether a gateway should accept SAMs, just don't propagate=20 > them through > the SIP network. >=20 > --=20 > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the = =A6 > bidulock@openss7.org =A6 world; the unreasonable one persists in = =A6 > http://www.openss7.org/ =A6 trying to adapt the world to himself. = =A6 > =A6 Therefore all progress depends on the = =A6 > =A6 unreasonable man. -- George Bernard Shaw = =A6 >=20 ------_=_NextPart_001_01C0A17E.7D6FE410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Overlap call setup

Brian,

You wrote:

> This is still not a reason to do overlap.  = Collect all of the digits
> at the UA (or at the gateway) and send them en = bloc.  If the
> terminating
> CPE doesn't have enough to connect, send PSPD = treatment.  If it does
> connect.  If the caller doesn't know how = many digits to
> provide, they're
> hosed anyway.
>

Of course the caller knows how many digits they have. = The problem occurs when they have no way to indicate end-of-dialling to = their equipment.

Of course whenever we can we will collect all the = digits and go en-bloc from there, but there remain cases where we = simply cannot determine end-of-dialling.

Our experience has universally been that our = customers (service providers) are not happy with using an inter-digit = timer to guess when end-of-dialling has occured - hence the need for = overlap.

Believe me, I do not *want* to support overlap. If = there was any way of avoiding the requirement altogether, I would do = so. The unfortunate fact is that there exist scenarios where overlap is = the only way of meeting our customers requirements.

<snip>

> The only reason this persists in the PSTN is = because of the inability
> of terminating equipment to communicate with = the network and the
> unwillingness of operators to make up for it = with manual provisioning.
>

Yes, and the fact that the manual provisioning = required is, in certain cases, completely impractical, or even = impossible because the operator does not have the information about = number lengths in the PBXs.


> Would you suggest that we overlap from SIP UA to = PSTN as well?

If you mean a 'real' UA (rather than a PSTN gateway), = then no. I expect that true SIP UAs will provide a means for the user = to indicate end-of-dialling, or indeed require the user to indicate = end-of-dialling.

Regards,

Mark

> >   
> >    > The only place that = overlap sending gets used heavily is calls
> >    > into an = international gateway switch (which should
> know how many
> >    > to collect anyway = because it has country code tables
> and can send
> >    > en bloc from = there).
> >   
> >    Overlap sending is = certainly used on almost all calls in the UK -
> >    admittedly not because = it has to, but more because it has always
> >    been done that = way.
>
> Convert from overlap to en bloc at the gateway.&= nbsp; Noone is questioning
> whether a gateway should accept SAMs, just = don't propagate
> them through
> the SIP network.
>
> --
> Brian F. G. Bidulock    =A6 The = reasonable man adapts himself to the =A6
> bidulock@openss7.org    =A6 = world; the unreasonable one persists in  =A6
> http://www.openss7.org/ =A6 trying  to adapt = the  world  to himself. =A6
>          = ;            = ;   =A6 Therefore  all  progress  depends on = the =A6
>          = ;            = ;   =A6 unreasonable man. -- George Bernard Shaw =A6
>

------_=_NextPart_001_01C0A17E.7D6FE410-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 07:09:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03635 for ; Wed, 28 Feb 2001 07:09:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 222F644340; Wed, 28 Feb 2001 07:07:26 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 225F744337 for ; Wed, 28 Feb 2001 07:06:32 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id HAA07220; Wed, 28 Feb 2001 07:09:23 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 07:08:44 -0500 Message-ID: From: Jonathan Rosenberg To: "'Daniel G. Petrie'" , Rohan Mahy Cc: Jonathan Rosenberg , "'Neil Deason'" , Alan Johnston , Richard Verhoeven , Rick Dean , jundery@ubiquity.net, parolkar@tri.sbc.com, "'sip@lists.bell-labs.com'" Subject: RE: [SIP] RE: [Sip-implementors] SIP and Call Pickup MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 07:08:35 -0500 > -----Original Message----- > From: Daniel G. Petrie [mailto:dpetrie@pingtel.com] > Sent: Monday, February 26, 2001 9:05 PM > To: Rohan Mahy > Cc: Jonathan Rosenberg; 'Neil Deason'; Alan Johnston; Richard > Verhoeven; > Rick Dean; jundery@ubiquity.net; parolkar@tri.sbc.com; > 'sip@lists.bell-labs.com' > Subject: Re: [SIP] RE: [Sip-implementors] SIP and Call Pickup > > > > > Rohan Mahy wrote: > > > At 08:10 PM 2/25/01 , Jonathan Rosenberg wrote: > > >[moving over to the sip list, as we are now talking about > changes to sip] > > > > > >A few thoughts on directed pickup. > > > > > >1. The mechanism in rfc2543 is a hack. It is meant to > provide call pickup as > > >a side effect of register behavior. What would happen is > that the register > > >would cause the original INVITE to fork to the second > phone. The second > > >phone then answers, which causes the first call to be > CANCELed. As such, > > >Alan's flow is wrong. The proxy would not CANCEL on > receipt of REGISTER (why > > >would it do that?). Rather, it would generate the second > INVITE, and when > > >its answered, then CANCEL. However, this mechanism has > some big problems: > > > > > > a. its hard to do in a distributed system where the > registrar and proxy > > >are separated > > > > It requires some additional signalling, but I would not say > that it is hard. It is not as complicated as building a B2BUA that > has to deal with the state and scale of every ringing phone in an > environment. One not well thought out means: proxy could do a > short lived implied or explicit SUBSCRIBE and get a NOTIFY > from the registrar with additional contacts as added. I think the > proxy/registrar is the correct place for this feature. Indeed, it is exactly a sub/not mechanism thats needed. Its a pretty complex one, though, in terms of scalability. Basically, every single active transaction through a proxy needs to generate a subcsription from the transaction, towards the registrar, for those registrations used to proxy the call. This means that your subscription count scales with the number of simultaneous transactions through the proxy. Yuck. Note that this is the case even when the registrar/proxy are co-located. In this case, the communication is between software components in the same process, but the need is identical. Is it harder than a B2BUA? Hard to say. > > this is trivial to fix: the second phone/gw just creates > some local state, > > so that when an INVITE for that request-uri arrives, it > simply replies with > > a 200. Note that on an analog phone, you are already > "offhook" anyway. I think that can work; you need to be careful about what Contact URI you place in the REGISTER for directed pickups. It can't be the same thing you put in REGISTER for receiving normal phone calls. > > >3. It is possible to do directed pickup with a B2BUA. I > worked through a > > >call flow for it, and it emulates completely the PSTN > service. It requires > > >no extensions to SIP, just logic for the service in the > picking-up phone and > > >in the B2BUA. Can it be done without a B2BUA in a > distributed way? Maybe. > > >But, I'm not going to get hung up on emulating every > infrequently used PSTN > > >service in a distributed way. > > > > All you've done is moved the problem around. Now all calls > that can be > > picked up have to go through this B2BUA. Eventually this > will need the > > performance of some kind of proxy (but it needs to keep > more state and > > handle twice as many transactions), so if you want to > provide redundancy or > > load sharing you need to add some additional state-sharing scheme, > > etc. Congratulations, you've just recreated the MGCP model > over SIP! ;-) Not really. THere is more state, yes. But, we don't have the other drawbacks of the MGCP approach. Thats a separate flame war that I'd rather not start. > > > > IMO, B2BUA is an overused crutch. I don't object to folks > implementing > > their own services with it, but I don't want us to cripple > the spec, or > > actively encourage others to recreate that which we try to avoid. > > > > I am with you on this. There is a great danger that B2BUAs start > getting stuffed into networks where proxys are more appropriate. > It then gets harder and harder to allow two end points to send > messages without content and headers getting filtered out or > mucked up by B2BUAs in the middle which do not explicitly > support the extensions of the end points. The drawbacks in terms of scalability, reliability and performance of a B2BUA are well known (at least, I hope they are), so I think that will cause people to think a bit before using a B2BUA when a proxy will do. That aside, there are just lots of services that can't be done any other way. Perhaps call park isn't one of them, and thats fine. I do recall someone posted a note on why the mechanism in rfc2543 was not call pickup, for many reasons. I couldn't find the note in the archive, so maybe I just imagined it. Anyway, the issue at hand is twofold: 1. should the spec say anything about call pickup Given our trend not to define services, I would say no. 2. should the spec still have this capability of sending a register in the middle of a call to add contacts Given that several people said they rely on this feature, it looks like it stays. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 08:23:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05205 for ; Wed, 28 Feb 2001 08:23:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B813844341; Wed, 28 Feb 2001 08:23:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F1F24433D for ; Wed, 28 Feb 2001 08:22:06 -0500 (EST) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-33 #47837) with ESMTP id <0G9G003HNYGG55@firewall.mcit.com> for sip@lists.bell-labs.com; Wed, 28 Feb 2001 13:21:52 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G9G00101YGEGW@pmismtp03.wcomnet.com>; Wed, 28 Feb 2001 13:21:52 +0000 (GMT) Received: from wcom.com ([166.46.20.160]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G9G0011HYG42E@pmismtp03.wcomnet.com>; Wed, 28 Feb 2001 13:21:42 +0000 (GMT) From: Alan Johnston Subject: Re: [SIP] RE: [Sip-implementors] SIP and Call Pickup To: Jonathan Rosenberg Cc: "'Daniel G. Petrie'" , Rohan Mahy , "'Neil Deason'" , Richard Verhoeven , Rick Dean , jundery@ubiquity.net, parolkar@tri.sbc.com, "'sip@lists.bell-labs.com'" Message-id: <3A9CFB28.AB028C0B@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 07:20:41 -0600 Content-Transfer-Encoding: 7bit All, I plan to add the corrected call flow (forking INVITE instead of CANCEL) to the new draft of the Service Examples so we can all take a look at the details - such as the Request-URI of the REGISTER as Jonathan points out. Alan Johnston WorldCom sip:alan@sip.digitalari.com Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: Daniel G. Petrie [mailto:dpetrie@pingtel.com] > > Sent: Monday, February 26, 2001 9:05 PM > > To: Rohan Mahy > > Cc: Jonathan Rosenberg; 'Neil Deason'; Alan Johnston; Richard > > Verhoeven; > > Rick Dean; jundery@ubiquity.net; parolkar@tri.sbc.com; > > 'sip@lists.bell-labs.com' > > Subject: Re: [SIP] RE: [Sip-implementors] SIP and Call Pickup > > > > > > > > > > Rohan Mahy wrote: > > > > > At 08:10 PM 2/25/01 , Jonathan Rosenberg wrote: > > > >[moving over to the sip list, as we are now talking about > > changes to sip] > > > > > > > >A few thoughts on directed pickup. > > > > > > > >1. The mechanism in rfc2543 is a hack. It is meant to > > provide call pickup as > > > >a side effect of register behavior. What would happen is > > that the register > > > >would cause the original INVITE to fork to the second > > phone. The second > > > >phone then answers, which causes the first call to be > > CANCELed. As such, > > > >Alan's flow is wrong. The proxy would not CANCEL on > > receipt of REGISTER (why > > > >would it do that?). Rather, it would generate the second > > INVITE, and when > > > >its answered, then CANCEL. However, this mechanism has > > some big problems: > > > > > > > > a. its hard to do in a distributed system where the > > registrar and proxy > > > >are separated > > > > > > > It requires some additional signalling, but I would not say > > that it is hard. It is not as complicated as building a B2BUA that > > has to deal with the state and scale of every ringing phone in an > > environment. One not well thought out means: proxy could do a > > short lived implied or explicit SUBSCRIBE and get a NOTIFY > > from the registrar with additional contacts as added. I think the > > proxy/registrar is the correct place for this feature. > > Indeed, it is exactly a sub/not mechanism thats needed. Its a pretty complex > one, though, in terms of scalability. Basically, every single active > transaction through a proxy needs to generate a subcsription from the > transaction, towards the registrar, for those registrations used to proxy > the call. This means that your subscription count scales with the number of > simultaneous transactions through the proxy. Yuck. Note that this is the > case even when the registrar/proxy are co-located. In this case, the > communication is between software components in the same process, but the > need is identical. > > Is it harder than a B2BUA? Hard to say. > > > > this is trivial to fix: the second phone/gw just creates > > some local state, > > > so that when an INVITE for that request-uri arrives, it > > simply replies with > > > a 200. Note that on an analog phone, you are already > > "offhook" anyway. > > I think that can work; you need to be careful about what Contact URI you > place in the REGISTER for directed pickups. It can't be the same thing you > put in REGISTER for receiving normal phone calls. > > > > >3. It is possible to do directed pickup with a B2BUA. I > > worked through a > > > >call flow for it, and it emulates completely the PSTN > > service. It requires > > > >no extensions to SIP, just logic for the service in the > > picking-up phone and > > > >in the B2BUA. Can it be done without a B2BUA in a > > distributed way? Maybe. > > > >But, I'm not going to get hung up on emulating every > > infrequently used PSTN > > > >service in a distributed way. > > > > > > All you've done is moved the problem around. Now all calls > > that can be > > > picked up have to go through this B2BUA. Eventually this > > will need the > > > performance of some kind of proxy (but it needs to keep > > more state and > > > handle twice as many transactions), so if you want to > > provide redundancy or > > > load sharing you need to add some additional state-sharing scheme, > > > etc. Congratulations, you've just recreated the MGCP model > > over SIP! ;-) > > Not really. THere is more state, yes. But, we don't have the other drawbacks > of the MGCP approach. Thats a separate flame war that I'd rather not start. > > > > > > > IMO, B2BUA is an overused crutch. I don't object to folks > > implementing > > > their own services with it, but I don't want us to cripple > > the spec, or > > > actively encourage others to recreate that which we try to avoid. > > > > > > > I am with you on this. There is a great danger that B2BUAs start > > getting stuffed into networks where proxys are more appropriate. > > It then gets harder and harder to allow two end points to send > > messages without content and headers getting filtered out or > > mucked up by B2BUAs in the middle which do not explicitly > > support the extensions of the end points. > > The drawbacks in terms of scalability, reliability and performance of a > B2BUA are well known (at least, I hope they are), so I think that will cause > people to think a bit before using a B2BUA when a proxy will do. > > That aside, there are just lots of services that can't be done any other > way. Perhaps call park isn't one of them, and thats fine. I do recall > someone posted a note on why the mechanism in rfc2543 was not call pickup, > for many reasons. I couldn't find the note in the archive, so maybe I just > imagined it. > > Anyway, the issue at hand is twofold: > > 1. should the spec say anything about call pickup > > Given our trend not to define services, I would say no. > > 2. should the spec still have this capability of sending a register in the > middle of a call > to add contacts > > Given that several people said they rely on this feature, it looks like > it stays. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 09:16:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06593 for ; Wed, 28 Feb 2001 09:16:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 724A24434A; Wed, 28 Feb 2001 09:16:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 066AF44342 for ; Wed, 28 Feb 2001 09:15:50 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA08368; Wed, 28 Feb 2001 09:18:57 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 09:18:18 -0500 Message-ID: From: Jonathan Rosenberg To: "'Sean Olson'" , Neil Deason Cc: sip@lists.bell-labs.com Subject: RE: [SIP] VIA header encryption? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 09:18:14 -0500 > -----Original Message----- > From: Sean Olson [mailto:sean.olson@ericsson.com] > Sent: Monday, February 26, 2001 6:19 PM > To: Neil Deason > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] VIA header encryption? > > > > Is there not the case for at least > > a more DCS-like approach where you at least store state info > > that you really need in the UEs. The revised Record-Route text > > means you wouldn't even need a State header extension. I > > appreciate that there could be issues with storing information > > in the UAs/UEs and retransmitting it over an air interface, > > but if bandwidth is the over riding concern for you SIP is not > > the best protocol to choose in the first place > > The problem is exactly as you stated: storing this > information in the terminal and retransmitting it > over the air interface. > > Bandwidth is one concern here. Delay is another. > Delay is of course a function of the amount of data > transmitted. The conversation on this thread has been moving between several different via header issues. It was my understanding that via mucking was happening in two places: 1. P-CSCF removes via, RR before sending an INVITE to a called party, to save bits on the air. This requires transaction stateful proxies to restore the information in the response. No call-statefulness required. 2. I-CSCF will encrypt the via headers, and record-routes, to avoid exposing the information outside the network. Please note that via hiding was removed from the spec primarily because of a security issue. The element that wanted the encryption needed to ask the next hop, possibly in a different domain, to perform it. Encryption and hiding can still be done in a number of ways, none of which require standardization. Some of them can be done statelessly. The issue with bandwidth has to do only with the P-CSCF removal of via and RR headers. Henning writes: > Again, this seems a peculiar notion of sensitive information. Since > adding a server costs 1U and $3k, it doesn't seem like that this is a > good indicator of the number of customers or anything else. Why would > this matter any more than me finding out that AOL has 4 servers for > inbound email: > > host -t mx aol.com > aol.com MX 15 mailin-01.mx.aol.com > aol.com MX 15 mailin-02.mx.aol.com > aol.com MX 15 mailin-03.mx.aol.com > aol.com MX 15 mailin-04.mx.aol.com > > Or that I can analyze a bunch of email messages from AOL and find out > which servers generate my inbound email? I've seen this requirement for hiding from wireline providers as well - not because the number of servers is sensitive information to be hidden from competitors - but because of hackers. The primary issue, in my mind, is allowing outside parties to learn the IP address of servers within the network. Once that happens, lots of tools are at their disposal to attack these machines. Given that phone companies have historically been a favorite attack point for hackers, and given that these attacks are much easier when we are talking voip, I think paranoia is a good thing here. Sean wrote: > Via: "hiding" as it is being defined for 3GPP is much different > than the Via: hiding that was in the bis draft. In 3GPP, > we are not asking the next hop to hide our Via: headers > for us. Instead a node is being given the job to hide > the Via: headers of outgoing requests and "un-hide" ( > I'm trying to avoid the term decrypt :) the Via: headers > for inbound responses. None of the problems that exist > for the 2543 mechanism of Via: hiding apply in this case. That depends entirely on the implementation. Any hiding mechanism that is transaction stateful will suffer from robustness problems, and call stateful mechanisms will be even worse. If done statelessly (which is possible), you get the robustness benefits stateless proxies can offer. I think loop detection is generally going to suffer. A complex implementation might look for a spiraled request, and when it sees one, attempt to locate/decrypt the hidden headers to look for a loop. That may or may not be possible depending on how the hiding is implemented. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 09:21:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06798 for ; Wed, 28 Feb 2001 09:21:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1017C44353; Wed, 28 Feb 2001 09:21:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 9316544346 for ; Wed, 28 Feb 2001 09:20:40 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA23390; Wed, 28 Feb 2001 09:20:37 -0500 (EST) Message-ID: <3A9D0935.42FDEDD2@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Sean Olson'" , Neil Deason , sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 09:20:37 -0500 Content-Transfer-Encoding: 7bit > > I've seen this requirement for hiding from wireline providers as well - not > because the number of servers is sensitive information to be hidden from > competitors - but because of hackers. The primary issue, in my mind, is > allowing outside parties to learn the IP address of servers within the > network. Once that happens, lots of tools are at their disposal to attack > these machines. Given that phone companies have historically been a favorite > attack point for hackers, and given that these attacks are much easier when > we are talking voip, I think paranoia is a good thing here. These providers should be informed that they are clueless :-) There are port scanners around that search millions of IP addresses very quickly, automatically and without the hacker lifting a finger. Thus, this offers almost no protection, except assuring PHBs that "yes, we're hiding our network". -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 09:44:15 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07655 for ; Wed, 28 Feb 2001 09:44:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AD0CC44339; Wed, 28 Feb 2001 09:44:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60]) by lists.bell-labs.com (Postfix) with ESMTP id 0C5FE44336 for ; Wed, 28 Feb 2001 09:43:09 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 28 Feb 2001 14:43:05 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id OAA15512; Wed, 28 Feb 2001 14:43:05 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80256A01.0050CDBB ; Wed, 28 Feb 2001 14:42:35 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: "Mark Watson" Cc: "'bidulock@openss7.org'" , "Mark Watson" , sip@lists.bell-labs.com Message-ID: <80256A01.0050CA7D.00@marconicomms.com> Subject: RE: [SIP] Overlap call setup Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=a9AFW6hlYIW1GDT7UdbSYHAddZU3DGn1EsTkNcbzQZisLKbpHEolwFXN" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 14:42:36 +0000 --0__=a9AFW6hlYIW1GDT7UdbSYHAddZU3DGn1EsTkNcbzQZisLKbpHEolwFXN Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello, >Our experience has universally been that our customers (service providers) >are not happy with using an inter-digit timer to guess when end-of-dialling >has occured - hence the need for overlap. Is this because of concern of the delay in setup ? As discussion on this thread has shown,supporting overlap within the SIP model, whether using the INFO method or multiple INVITEs, is going to lead to a lot more processing than just the sending of the extra digits, E.g., waiting for responses, processing ACKs, AAA procedures, all of which may be a bigger drag on setup than waiting for an EOD timer to mature. Add to that the administrative issues of making sure that networks to which yours connects supports the SIP procedures necessary to make overlap work the way your network wants it to work and we introduce a lot of extra complexity for no discernable gain. Regards, Keith. "Mark Watson" on 28/02/2001 12:03:40 To: "'bidulock@openss7.org'" , "Mark Watson" cc: sip@lists.bell-labs.com(bcc: Keith Robinson/MAIN/MC1) Subject: RE: [SIP] Overlap call setup --0__=a9AFW6hlYIW1GDT7UdbSYHAddZU3DGn1EsTkNcbzQZisLKbpHEolwFXN Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Brian, You wrote: > This is still not a reason to do overlap. Collect all of the digits > at the UA (or at the gateway) and send them en bloc. If the > terminating > CPE doesn't have enough to connect, send PSPD treatment. If it does > connect. If the caller doesn't know how many digits to > provide, they're > hosed anyway. > Of course the caller knows how many digits they have. The problem occur= s when they have no way to indicate end-of-dialling to their equipment. Of course whenever we can we will collect all the digits and go en-bloc= from there, but there remain cases where we simply cannot determine end-of-dialling. Our experience has universally been that our customers (service provide= rs) are not happy with using an inter-digit timer to guess when end-of-dial= ling has occured - hence the need for overlap. Believe me, I do not *want* to support overlap. If there was any way of= avoiding the requirement altogether, I would do so. The unfortunate fac= t is that there exist scenarios where overlap is the only way of meeting our= customers requirements. > The only reason this persists in the PSTN is because of the inability= > of terminating equipment to communicate with the network and the > unwillingness of operators to make up for it with manual provisioning= . > Yes, and the fact that the manual provisioning required is, in certain cases, completely impractical, or even impossible because the operator = does not have the information about number lengths in the PBXs. > Would you suggest that we overlap from SIP UA to PSTN as well? If you mean a 'real' UA (rather than a PSTN gateway), then no. I expect= that true SIP UAs will provide a means for the user to indicate end-of-diall= ing, or indeed require the user to indicate end-of-dialling. Regards, Mark > > > > > The only place that overlap sending gets used heavily is calls= > > > into an international gateway switch (which should > know how many > > > to collect anyway because it has country code tables > and can send > > > en bloc from there). > > > > Overlap sending is certainly used on almost all calls in the UK = - > > admittedly not because it has to, but more because it has always= > > been done that way. > > Convert from overlap to en bloc at the gateway. Noone is questioning= > whether a gateway should accept SAMs, just don't propagate > them through > the SIP network. > > -- > Brian F. G. Bidulock =A6 The reasonable man adapts himself to the = =A6 > bidulock@openss7.org =A6 world; the unreasonable one persists in = =A6 > http://www.openss7.org/ =A6 trying to adapt the world to himself. = =A6 > =A6 Therefore all progress depends on the = =A6 > =A6 unreasonable man. -- George Bernard Shaw = =A6 > = --0__=a9AFW6hlYIW1GDT7UdbSYHAddZU3DGn1EsTkNcbzQZisLKbpHEolwFXN Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC4xOSI+DQo8VElUTEU+UkU6IFtT SVBdIE92ZXJsYXAgY2FsbCBzZXR1cDwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZP TlQgU0laRT0yPkJyaWFuLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPllvdSB3cm90 ZTo8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4mZ3Q7IFRoaXMgaXMgc3RpbGwgbm90 IGEgcmVhc29uIHRvIGRvIG92ZXJsYXAuJm5ic3A7IENvbGxlY3QgYWxsIG9mIHRoZSBkaWdpdHM8 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgYXQgdGhlIFVBIChvciBhdCB0aGUgZ2F0ZXdh eSkgYW5kIHNlbmQgdGhlbSBlbiBibG9jLiZuYnNwOyBJZiB0aGUgPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IHRlcm1pbmF0aW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IENQ RSBkb2Vzbid0IGhhdmUgZW5vdWdoIHRvIGNvbm5lY3QsIHNlbmQgUFNQRCB0cmVhdG1lbnQuJm5i c3A7IElmIGl0IGRvZXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgY29ubmVjdC4mbmJz cDsgSWYgdGhlIGNhbGxlciBkb2Vzbid0IGtub3cgaG93IG1hbnkgZGlnaXRzIHRvIDwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBwcm92aWRlLCB0aGV5J3JlPC9GT05UPg0KPEJSPjxGT05U IFNJWkU9Mj4mZ3Q7IGhvc2VkIGFueXdheS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsg PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+T2YgY291cnNlIHRoZSBjYWxsZXIga25v d3MgaG93IG1hbnkgZGlnaXRzIHRoZXkgaGF2ZS4gVGhlIHByb2JsZW0gb2NjdXJzIHdoZW4gdGhl eSBoYXZlIG5vIHdheSB0byBpbmRpY2F0ZSBlbmQtb2YtZGlhbGxpbmcgdG8gdGhlaXIgZXF1aXBt ZW50LjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5PZiBjb3Vyc2Ugd2hlbmV2ZXIgd2Ug Y2FuIHdlIHdpbGwgY29sbGVjdCBhbGwgdGhlIGRpZ2l0cyBhbmQgZ28gZW4tYmxvYyBmcm9tIHRo ZXJlLCBidXQgdGhlcmUgcmVtYWluIGNhc2VzIHdoZXJlIHdlIHNpbXBseSBjYW5ub3QgZGV0ZXJt aW5lIGVuZC1vZi1kaWFsbGluZy48L0ZPTlQ+PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+T3VyIGV4 cGVyaWVuY2UgaGFzIHVuaXZlcnNhbGx5IGJlZW4gdGhhdCBvdXIgY3VzdG9tZXJzIChzZXJ2aWNl IHByb3ZpZGVycykgYXJlIG5vdCBoYXBweSB3aXRoIHVzaW5nIGFuIGludGVyLWRpZ2l0IHRpbWVy IHRvIGd1ZXNzIHdoZW4gZW5kLW9mLWRpYWxsaW5nIGhhcyBvY2N1cmVkIC0gaGVuY2UgdGhlIG5l ZWQgZm9yIG92ZXJsYXAuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPkJlbGlldmUgbWUs IEkgZG8gbm90ICp3YW50KiB0byBzdXBwb3J0IG92ZXJsYXAuIElmIHRoZXJlIHdhcyBhbnkgd2F5 IG9mIGF2b2lkaW5nIHRoZSByZXF1aXJlbWVudCBhbHRvZ2V0aGVyLCBJIHdvdWxkIGRvIHNvLiBU aGUgdW5mb3J0dW5hdGUgZmFjdCBpcyB0aGF0IHRoZXJlIGV4aXN0IHNjZW5hcmlvcyB3aGVyZSBv dmVybGFwIGlzIHRoZSBvbmx5IHdheSBvZiBtZWV0aW5nIG91ciBjdXN0b21lcnMgcmVxdWlyZW1l bnRzLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4mbHQ7c25pcCZndDs8L0ZPTlQ+DQo8 L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4mZ3Q7IFRoZSBvbmx5IHJlYXNvbiB0aGlzIHBlcnNpc3Rz IGluIHRoZSBQU1ROIGlzIGJlY2F1c2Ugb2YgdGhlIGluYWJpbGl0eTwvRk9OVD4NCjxCUj48Rk9O VCBTSVpFPTI+Jmd0OyBvZiB0ZXJtaW5hdGluZyBlcXVpcG1lbnQgdG8gY29tbXVuaWNhdGUgd2l0 aCB0aGUgbmV0d29yayBhbmQgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IHVud2ls bGluZ25lc3Mgb2Ygb3BlcmF0b3JzIHRvIG1ha2UgdXAgZm9yIGl0IHdpdGggbWFudWFsIHByb3Zp c2lvbmluZy48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTI+WWVzLCBhbmQgdGhlIGZhY3QgdGhhdCB0aGUgbWFudWFsIHByb3Zpc2lv bmluZyByZXF1aXJlZCBpcywgaW4gY2VydGFpbiBjYXNlcywgY29tcGxldGVseSBpbXByYWN0aWNh bCwgb3IgZXZlbiBpbXBvc3NpYmxlIGJlY2F1c2UgdGhlIG9wZXJhdG9yIGRvZXMgbm90IGhhdmUg dGhlIGluZm9ybWF0aW9uIGFib3V0IG51bWJlciBsZW5ndGhzIGluIHRoZSBQQlhzLjwvRk9OVD48 L1A+DQo8QlI+DQoNCjxQPjxGT05UIFNJWkU9Mj4mZ3Q7IFdvdWxkIHlvdSBzdWdnZXN0IHRoYXQg d2Ugb3ZlcmxhcCBmcm9tIFNJUCBVQSB0byBQU1ROIGFzIHdlbGw/PC9GT05UPg0KPC9QPg0KDQo8 UD48Rk9OVCBTSVpFPTI+SWYgeW91IG1lYW4gYSAncmVhbCcgVUEgKHJhdGhlciB0aGFuIGEgUFNU TiBnYXRld2F5KSwgdGhlbiBuby4gSSBleHBlY3QgdGhhdCB0cnVlIFNJUCBVQXMgd2lsbCBwcm92 aWRlIGEgbWVhbnMgZm9yIHRoZSB1c2VyIHRvIGluZGljYXRlIGVuZC1vZi1kaWFsbGluZywgb3Ig aW5kZWVkIHJlcXVpcmUgdGhlIHVzZXIgdG8gaW5kaWNhdGUgZW5kLW9mLWRpYWxsaW5nLjwvRk9O VD48L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5SZWdhcmRzLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPk1hcms8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7ICZndDsmbmJz cDsmbmJzcDsmbmJzcDsgJmd0OyBUaGUgb25seSBwbGFjZSB0aGF0IG92ZXJsYXAgc2VuZGluZyBn ZXRzIHVzZWQgaGVhdmlseSBpcyBjYWxsczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgaW50byBhbiBpbnRlcm5hdGlvbmFsIGdhdGV3YXkg c3dpdGNoICh3aGljaCBzaG91bGQgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGtub3cg aG93IG1hbnk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyAmZ3Q7IHRvIGNvbGxlY3QgYW55d2F5IGJlY2F1c2UgaXQgaGFzIGNvdW50cnkgY29kZSB0 YWJsZXMgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGFuZCBjYW4gc2VuZDwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgZW4gYmxv YyBmcm9tIHRoZXJlKS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyBPdmVybGFwIHNlbmRpbmcgaXMgY2VydGFpbmx5IHVzZWQgb24gYWxtb3N0IGFsbCBj YWxscyBpbiB0aGUgVUsgLTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyAmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGFkbWl0dGVkbHkgbm90IGJlY2F1c2UgaXQgaGFzIHRvLCBidXQgbW9yZSBi ZWNhdXNlIGl0IGhhcyBhbHdheXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyBiZWVuIGRvbmUgdGhhdCB3YXkuPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBDb252ZXJ0IGZyb20gb3Zl cmxhcCB0byBlbiBibG9jIGF0IHRoZSBnYXRld2F5LiZuYnNwOyBOb29uZSBpcyBxdWVzdGlvbmlu ZzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyB3aGV0aGVyIGEgZ2F0ZXdheSBzaG91bGQg YWNjZXB0IFNBTXMsIGp1c3QgZG9uJ3QgcHJvcGFnYXRlIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF PTI+Jmd0OyB0aGVtIHRocm91Z2g8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgdGhlIFNJ UCBuZXR3b3JrLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyA8L0ZPTlQ+DQo8QlI+PEZP TlQgU0laRT0yPiZndDsgLS0gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IEJyaWFuIEYu IEcuIEJpZHVsb2NrJm5ic3A7Jm5ic3A7Jm5ic3A7IKYgVGhlIHJlYXNvbmFibGUgbWFuIGFkYXB0 cyBoaW1zZWxmIHRvIHRoZSCmPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGJpZHVsb2Nr QG9wZW5zczcub3JnJm5ic3A7Jm5ic3A7Jm5ic3A7IKYgd29ybGQ7IHRoZSB1bnJlYXNvbmFibGUg b25lIHBlcnNpc3RzIGluJm5ic3A7IKY8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPEEg SFJFRj0iaHR0cDovL3d3dy5vcGVuc3M3Lm9yZy8iIFRBUkdFVD0iX2JsYW5rIj5odHRwOi8vd3d3 Lm9wZW5zczcub3JnLzwvQT4gpiB0cnlpbmcmbmJzcDsgdG8gYWRhcHQgdGhlJm5ic3A7IHdvcmxk Jm5ic3A7IHRvIGhpbXNlbGYuIKY8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgpiBUaGVyZWZvcmUmbmJzcDsgYWxsJm5ic3A7IHByb2dy ZXNzJm5ic3A7IGRlcGVuZHMgb24gdGhlIKY8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgpiB1bnJlYXNvbmFibGUgbWFuLiAtLSBHZW9y Z2UgQmVybmFyZCBTaGF3IKY8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPiZndDsgPC9GT05UPg0K PC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ --0__=a9AFW6hlYIW1GDT7UdbSYHAddZU3DGn1EsTkNcbzQZisLKbpHEolwFXN-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 09:55:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08025 for ; Wed, 28 Feb 2001 09:55:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 67EBE4435A; Wed, 28 Feb 2001 09:55:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 7DD0A44352 for ; Wed, 28 Feb 2001 09:54:59 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 28 Feb 2001 14:54:57 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id OAA23832; Wed, 28 Feb 2001 14:53:48 GMT Message-ID: <3A9D10FB.842965F6@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 14:53:47 +0000 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > -----Original Message----- > > From: Sean Olson [mailto:sean.olson@ericsson.com] > > Sent: Monday, February 26, 2001 6:19 PM > > To: Neil Deason > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] VIA header encryption? > > > > > Is there not the case for at least > > > a more DCS-like approach where you at least store state info > > > that you really need in the UEs. The revised Record-Route text > > > means you wouldn't even need a State header extension. I > > > appreciate that there could be issues with storing information > > > in the UAs/UEs and retransmitting it over an air interface, > > > but if bandwidth is the over riding concern for you SIP is not > > > the best protocol to choose in the first place > > > > The problem is exactly as you stated: storing this > > information in the terminal and retransmitting it > > over the air interface. > > > > Bandwidth is one concern here. Delay is another. > > Delay is of course a function of the amount of data > > transmitted. > > The conversation on this thread has been moving between several different > via header issues. It was my understanding that via mucking was happening in > two places: > > 1. P-CSCF removes via, RR before sending an INVITE to a called party, to > save bits on the air. This requires transaction stateful proxies to restore > the information in the response. No call-statefulness required. True, the 3GPP expectation for the P-CSCF being call stateful must come from elsewhere. I'ld like to learn more about exactly why this is thought to be needed, it is definitely in the docs. There is the idea of storing state in the P-CSCF for things like return-call service to caller-id blocked calls. Although caller-id blocking is another can of worms without using a B2BUA as an anonymizer. > 2. I-CSCF will encrypt the via headers, and record-routes, to avoid exposing > the information outside the network. > > Please note that via hiding was removed from the spec primarily because of a > security issue. The element that wanted the encryption needed to ask the > next hop, possibly in a different domain, to perform it. Encryption and > hiding can still be done in a number of ways, none of which require > standardization. Some of them can be done statelessly. > > The issue with bandwidth has to do only with the P-CSCF removal of via and > RR headers. > > Henning writes: > > Again, this seems a peculiar notion of sensitive information. Since > > adding a server costs 1U and $3k, it doesn't seem like that this is a > > good indicator of the number of customers or anything else. Why would > > this matter any more than me finding out that AOL has 4 servers for > > inbound email: > > > > host -t mx aol.com > > aol.com MX 15 mailin-01.mx.aol.com > > aol.com MX 15 mailin-02.mx.aol.com > > aol.com MX 15 mailin-03.mx.aol.com > > aol.com MX 15 mailin-04.mx.aol.com > > > > Or that I can analyze a bunch of email messages from AOL and find out > > which servers generate my inbound email? > > I've seen this requirement for hiding from wireline providers as well - not > because the number of servers is sensitive information to be hidden from > competitors - but because of hackers. The primary issue, in my mind, is > allowing outside parties to learn the IP address of servers within the > network. Once that happens, lots of tools are at their disposal to attack > these machines. Given that phone companies have historically been a favorite > attack point for hackers, and given that these attacks are much easier when > we are talking voip, I think paranoia is a good thing here. The trusted next hop was one of the security issues that lead to the deprecation of Via hiding. But another was just false impression of security doing this could create for the naive as hiding a box's IP doesn't make it secure. After all old style Via hiding could have 'worked' within a single providers network where the servers could trust each other. > Sean wrote: > > Via: "hiding" as it is being defined for 3GPP is much different > > than the Via: hiding that was in the bis draft. In 3GPP, > > we are not asking the next hop to hide our Via: headers > > for us. Instead a node is being given the job to hide > > the Via: headers of outgoing requests and "un-hide" ( > > I'm trying to avoid the term decrypt :) the Via: headers > > for inbound responses. None of the problems that exist > > for the 2543 mechanism of Via: hiding apply in this case. > > That depends entirely on the implementation. > > Any hiding mechanism that is transaction stateful will suffer from > robustness problems, and call stateful mechanisms will be even worse. If > done statelessly (which is possible), you get the robustness benefits > stateless proxies can offer. > > I think loop detection is generally going to suffer. A complex > implementation might look for a spiraled request, and when it sees one, > attempt to locate/decrypt the hidden headers to look for a loop. That may or > may not be possible depending on how the hiding is implemented. Yeah that bothers me with the potential for complex service based routing in the future. I remember the time when our proxy had to look through Via headers figuring out if it could decrypt any before doing loop detection. Not pretty. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 09:58:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08125 for ; Wed, 28 Feb 2001 09:58:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E93D044362; Wed, 28 Feb 2001 09:56:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 87E2344362 for ; Wed, 28 Feb 2001 09:55:19 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA09164; Wed, 28 Feb 2001 09:58:25 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 09:57:46 -0500 Message-ID: From: Jonathan Rosenberg To: "'Henning G. Schulzrinne'" , Jonathan Rosenberg Cc: "'Sean Olson'" , Neil Deason , sip@lists.bell-labs.com Subject: RE: [SIP] VIA header encryption? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 09:57:43 -0500 > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, February 28, 2001 9:21 AM > To: Jonathan Rosenberg > Cc: 'Sean Olson'; Neil Deason; sip@lists.bell-labs.com > Subject: Re: [SIP] VIA header encryption? > > > > > > > I've seen this requirement for hiding from wireline > providers as well - not > > because the number of servers is sensitive information to > be hidden from > > competitors - but because of hackers. The primary issue, in > my mind, is > > allowing outside parties to learn the IP address of servers > within the > > network. Once that happens, lots of tools are at their > disposal to attack > > these machines. Given that phone companies have > historically been a favorite > > attack point for hackers, and given that these attacks are > much easier when > > we are talking voip, I think paranoia is a good thing here. > > These providers should be informed that they are clueless :-) > There are > port scanners around that search millions of IP addresses > very quickly, > automatically and without the hacker lifting a finger. Thus, > this offers > almost no protection, except assuring PHBs that "yes, we're hiding our > network". Well, there is a big difference. With the port scans, you find a device, but don't necessarily know what it does or why you might want to beat it up. Without via hiding, an attacker can know what the device is (a proxy), what provider its with, what calls get routed through it, and so on. It makes for much more selective, focused attacks. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 10:09:35 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08666 for ; Wed, 28 Feb 2001 10:09:34 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C9E8B44371; Wed, 28 Feb 2001 10:04:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 1DB5A44352 for ; Wed, 28 Feb 2001 10:03:11 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA26600; Wed, 28 Feb 2001 10:03:06 -0500 (EST) Message-ID: <3A9D1329.2EA04012@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Sean Olson'" , Neil Deason , sip@lists.bell-labs.com Subject: Re: [SIP] VIA header encryption? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 10:03:05 -0500 Content-Transfer-Encoding: 7bit > > Well, there is a big difference. With the port scans, you find a device, but > don't necessarily know what it does or why you might want to beat it up. > Without via hiding, an attacker can know what the device is (a proxy), what > provider its with, what calls get routed through it, and so on. It makes for > much more selective, focused attacks. > Scan for TCP port 5060 and you'll know it's a proxy. You'll know the IP address range by looking at the packet to your 3GPP device (or the public allocations and domain names). I agree Via hiding makes the work somewhat more difficult, but I doubt that it offers any real protection, given other leakage (such as Record-Route) and other ways to find out things (max-forward). My primary concern is that 3GPP seems to be mandating architectures that are, at best, useful for a subset of providers and scenarios, imposing complexity on everyone. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 10:17:02 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08908 for ; Wed, 28 Feb 2001 10:17:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 816BA44377; Wed, 28 Feb 2001 10:05:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2640544376 for ; Wed, 28 Feb 2001 10:04:48 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA09369; Wed, 28 Feb 2001 10:07:44 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 10:07:05 -0500 Message-ID: From: Jonathan Rosenberg To: "'Gethin Liddell'" , Juha Heinanen Cc: sip@lists.bell-labs.com Subject: RE: [SIP] confusion in url comparison MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 10:06:55 -0500 > -----Original Message----- > From: Gethin Liddell [mailto:gethin@ubiquity.net] > Sent: Monday, February 26, 2001 10:36 AM > To: Juha Heinanen > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] confusion in url comparison > > > > I believe the confusion is over the last line of the paragraph: > > "Components not found in both URLs being compared are ignored." > > What this is supposed to mean (I think) is that parameters > without default > values such as maddr-param or *future-parameters* should be > ignored if they > only exist in one sip url: > > e.g. the following are equivalent: > > sip:gethin@ubiquity.net;transport=UDP > sip:gethin@ubiquity.net > sip:gethin@ubiquity.net;maddr=sip.mcast.net;foo=bar > > but not these: > > sip:gethin@ubiquity.net;transport=TCP > sip:gethin@ubiquity.net > > I do however think that this should be re-fined for > parameters that are not > known about. for example it is impossible for a server to make a > correct decision on the equality of two unknown parameters I think the most correct statement is that "URL parameters that have no default value are ignored for purposes of comparison if they are not present in both URLs". This covers unknown parameters as well as a few of the known ones. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 10:26:15 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09183 for ; Wed, 28 Feb 2001 10:26:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5140D44346; Wed, 28 Feb 2001 10:26:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id B9C6C44336 for ; Wed, 28 Feb 2001 10:25:09 -0500 (EST) Received: from mr3.exu.ericsson.se (mr3u3.ericy.com [208.237.135.126]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f1SFP9i22173 for ; Wed, 28 Feb 2001 09:25:09 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr3.exu.ericsson.se (8.10.2/8.10.2) with SMTP id f1SFP8U07717 for ; Wed, 28 Feb 2001 09:25:08 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Feb 28 09:26:36 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Feb 2001 09:26:35 -0600 Message-ID: From: "Sean Olson (EUS)" To: "'Jonathan Rosenberg'" , "'Neil Deason'" Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] VIA header encryption? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A19A.D6080820" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 09:26:35 -0600 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_01C0A19A.D6080820 Content-Type: text/plain; charset="iso-8859-1" > The conversation on this thread has been moving between > several different > via header issues. It was my understanding that via mucking > was happening in > two places: > > 1. P-CSCF removes via, RR before sending an INVITE to a > called party, to > save bits on the air. This requires transaction stateful > proxies to restore > the information in the response. No call-statefulness required. Call statefulness is required for the BYE. In order for the P-CSCF to insert the proper Route: in the BYE, it must maintain call state. This is not the *only* reason the P-CSCF maintains call state however. > > 2. I-CSCF will encrypt the via headers, and record-routes, to > avoid exposing > the information outside the network. > Correct. > > Please note that via hiding was removed from the spec > primarily because of a > security issue. The element that wanted the encryption needed > to ask the > next hop, possibly in a different domain, to perform it. This is not a concern for 3GPP since Via: hiding is not being requested through signalling. > Encryption and > hiding can still be done in a number of ways, none of which require > standardization. Some of them can be done statelessly. > Exactly. > The issue with bandwidth has to do only with the P-CSCF > removal of via and > RR headers. As well, of course, as the removal of the need for the UA to insert Route: headers. > Any hiding mechanism that is transaction stateful will suffer from > robustness problems, and call stateful mechanisms will be > even worse. If > done statelessly (which is possible), you get the robustness benefits > stateless proxies can offer. Robustness is then left in the hands of the UA. I'm not saying that is a bad thing. That is the Internet model after all. But it is a tradeoff. > I think loop detection is generally going to suffer. A complex > implementation might look for a spiraled request, and when it > sees one, > attempt to locate/decrypt the hidden headers to look for a > loop. That may or > may not be possible depending on how the hiding is implemented. Spiralling between operator's networks is the complex case that needs to be handled. This definitely needs more investigation. > > -Jonathan R. /sean ------_=_NextPart_001_01C0A19A.D6080820 Content-Type: text/html; charset="iso-8859-1" RE: [SIP] VIA header encryption?

> The conversation on this thread has been moving between
> several different
> via header issues. It was my understanding that via mucking
> was happening in
> two places:
>
> 1. P-CSCF removes via, RR before sending an INVITE to a
> called party, to
> save bits on the air. This requires transaction stateful
> proxies to restore
> the information in the response. No call-statefulness required.

Call statefulness is required for the BYE. In order for the
P-CSCF to insert the proper Route: in the BYE, it must maintain
call state. This is not the *only* reason the P-CSCF maintains
call state however.

>
> 2. I-CSCF will encrypt the via headers, and record-routes, to
> avoid exposing
> the information outside the network.
>

Correct.

>
> Please note that via hiding was removed from the spec
> primarily because of a
> security issue. The element that wanted the encryption needed
> to ask the
> next hop, possibly in a different domain, to perform it.

This is not a concern for 3GPP since Via: hiding is not
being requested through signalling.

> Encryption and
> hiding can still be done in a number of ways, none of which require
> standardization. Some of them can be done statelessly.
>

Exactly.

> The issue with bandwidth has to do only with the P-CSCF
> removal of via and
> RR headers.

As well, of course, as the removal of the need for the
UA to insert Route: headers.

> Any hiding mechanism that is transaction stateful will suffer from
> robustness problems, and call stateful mechanisms will be
> even worse. If
> done statelessly (which is possible), you get the robustness benefits
> stateless proxies can offer.

Robustness is then left in the hands of the UA.
I'm not saying that is a bad thing. That is the Internet
model after all. But it is a tradeoff.

> I think loop detection is generally going to suffer. A complex
> implementation might look for a spiraled request, and when it
> sees one,
> attempt to locate/decrypt the hidden headers to look for a
> loop. That may or
> may not be possible depending on how the hiding is implemented.

Spiralling between operator's networks is the complex case that
needs to be handled. This definitely needs more investigation.

>
> -Jonathan R.

/sean

------_=_NextPart_001_01C0A19A.D6080820-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 10:42:21 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09948 for ; Wed, 28 Feb 2001 10:42:20 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A25F74438C; Wed, 28 Feb 2001 10:41:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ss3000e.cselt.it (ss3000e.cselt.it [163.162.41.5]) by lists.bell-labs.com (Postfix) with ESMTP id 9F29944337 for ; Wed, 28 Feb 2001 10:40:33 -0500 (EST) Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0G9H00ICQ1KINI@ss3000e.cselt.it> for sip@lists.bell-labs.com; Wed, 28 Feb 2001 15:29:06 +0100 (MET) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 15:29:42 +0100 Received: from cselt.it (hpi8329.cselt.it [163.162.3.115]) by EXC2K01.cselt.it with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id F3BC99XN; Wed, 28 Feb 2001 15:29:16 +0100 Content-return: allowed From: Alberto Cuda To: sip@lists.bell-labs.com Message-id: <3A9D08F4.D8764B19@cselt.it> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (WinNT; I) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Subject: [SIP] NATs and firewalls: yet another approach? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 15:19:32 +0100 Content-Transfer-Encoding: 7bit Hi, I was looking for a workaround for the NAT/firewall problem concerning RTP flows when the UA *knows* it is not capable of creating a "good" SDP description. In particular I was wondering if there's a way to avoid the deployment of a B2BUA and stick with a vanilla proxy. So the question is: what if UAs could "declare" in an header the address they'll need, in order to let SIP proxies allocate an address and return it to the sender? For instance, if "caller@a.com" wants to call "callee@b.com" the message flow could be: caller@x.a.com proxy.a.com | | |-------M1------->| |<------M2--------| |-------M3------->| M1: INVITE sip:callee@b.com SIP/2.0 ... Address-Request: 10.0.0.1:24445;transport=udp ... c=IN IP4 10.0.0.1 ... M2: SIP/2.0 4xx Address Needs Translation ... Address-Request: 100.0.0.1:24445;transport=udp;map=163.162.3.19:1029;expires=3600 ... M3: INVITE sip:callee@b.com SIP/2.0 ... Address-Request: 10.0.0.1:24445;transport=udp;map=163.162.3.19:1029 ... c=IN IP4 163.162.3.19 ... And so on. Of course this requires also a new request method to let the callee allocate its address[es] (it can't do it within the INVITE transaction, because it can't receive a response from the proxy). This new method could also be useful to reallocate the same addresses or if this operation requires some kind of authentication. This SIP-extension should work even if the message body is not SDP, and has no side effects when one of the two peers does not understand it. It works when there are one or more NATs and/or firewalls (if an RTP proxy is also deployed): it looks too good to be true. What I'm missing? Thanks in advance. Alberto. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 11:03:01 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10684 for ; Wed, 28 Feb 2001 11:02:58 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8E6B4434F; Wed, 28 Feb 2001 11:02:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 076D444342 for ; Wed, 28 Feb 2001 11:01:21 -0500 (EST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f1SG1Kd11627 for ; Wed, 28 Feb 2001 17:01:20 +0100 (MET) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Feb 28 17:01:19 2001 +0100 Received: by esealnt746.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Wed, 28 Feb 2001 17:01:19 +0100 Message-ID: <7BA41B5547CCD411833B0002A52CD457D51079@enlrynt306.etm.ericsson.se> From: "Arnoud van Wijk (ELN)" To: "'Jonathan Rosenberg'" , sip@lists.bell-labs.com Subject: RE: [SIP] VIA header encryption? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 17:01:12 +0100 True, but sofar I understand now. a SIP message that leaves a P-CSCF will leave its own address in the topmost VIA header. So, evil hackers can intercept it before the SIP message is received by the proxy of the other network.(before next hop) (probably by cutting the cable :-)since the mobile operator may hope that the other network does encrypt the VIA header of the SIP message that passes the bordering proxy of that network. About Portscans, there are enough programs that prevent proxies to respond back to a portscan. That is known as Stealth mode of the ports. greetz Arnoud van Wijk -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: woensdag 28 feb 2001 15:58 To: 'Henning G. Schulzrinne'; Jonathan Rosenberg Cc: Sean Olson (EUS); Neil Deason; sip@lists.bell-labs.com Subject: RE: [SIP] VIA header encryption? > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, February 28, 2001 9:21 AM > To: Jonathan Rosenberg > Cc: 'Sean Olson'; Neil Deason; sip@lists.bell-labs.com > Subject: Re: [SIP] VIA header encryption? > > > > > > > I've seen this requirement for hiding from wireline > providers as well - not > > because the number of servers is sensitive information to > be hidden from > > competitors - but because of hackers. The primary issue, in > my mind, is > > allowing outside parties to learn the IP address of servers > within the > > network. Once that happens, lots of tools are at their > disposal to attack > > these machines. Given that phone companies have > historically been a favorite > > attack point for hackers, and given that these attacks are > much easier when > > we are talking voip, I think paranoia is a good thing here. > > These providers should be informed that they are clueless :-) > There are > port scanners around that search millions of IP addresses > very quickly, > automatically and without the hacker lifting a finger. Thus, > this offers > almost no protection, except assuring PHBs that "yes, we're hiding our > network". Well, there is a big difference. With the port scans, you find a device, but don't necessarily know what it does or why you might want to beat it up. Without via hiding, an attacker can know what the device is (a proxy), what provider its with, what calls get routed through it, and so on. It makes for much more selective, focused attacks. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 11:37:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11990 for ; Wed, 28 Feb 2001 11:37:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AAB4944337; Wed, 28 Feb 2001 11:37:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id CD9D644336 for ; Wed, 28 Feb 2001 11:36:29 -0500 (EST) Received: from cowboys (localhost.localdomain [127.0.0.1]) by kevlar (8.11.0/8.11.0) with SMTP id f1SGgTd02551 for ; Wed, 28 Feb 2001 10:42:29 -0600 Message-ID: <003001c0a1a4$f3d365c0$a3036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Proposal for ogranizing WG efforts Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 10:38:59 -0600 Content-Transfer-Encoding: 7bit The WG chairs and the ADs were talking this morning about how to make the working group more effective.One idea that came up sounds interesting, and I'd like to share it with you. There are really two sorts of tasks that happen in the WG today: 1) Defining the protocol: SIP and extensions to SIP using its extension mechanisms. 2) Describing the mechanisms and requirements of doing useful things with SIP. Many of the discussions over the past years have started as application-specific extensions that have pointed toward general-purpose reusable solutions. For example, Message Waiting Indicator proposals led to our understanding of the general usefulness of Subscribe/Notify (Events) mechanisms. We sometimes didn't notice the generalizability of a mechanism until several iterations into implementation discussions (Refer). We've started to learn to differentiate our drafts between protocol specifics and usage rationales. Unfortunately, sometimes the "how could we" discussions have distracted from the immediate goals of completing the base specifications. Even the core protocol draft has drawn criticism for intermixing usage and specification, and the authors have proposed a rewrite to separate those components. So here's the idea: What if we were to split the SIP WG into two pieces? Maybe two WGs? The first part would handle the actual protocol specifications -- things like 2543bis, and would deal with new methods, new headers, new response codes, and other things in response to requirements generated by the second part. Hard standards-track stuff, tightly controlled charter. The second part would deal with using SIP, primarily from a rationale-and-requirements perspective. This would include call flows, application of SIP mechanisms (like using Events for Message Waiting), and with things like RFCs to register new MIME types and DHCP options and the like. I believe Allison suggested calling such a group the "SIPPING" effort. Such a group would of course do a lot of discussios and would be likely to generate several informational and BCP track documents as well as standards-track documents where appropriate. This might let us get a little more clarity in the discussions and discipline in the process -- and separate some of the topics on the rather busy mailing list. So, what do you think? -- Dean Willis SIP WG CoChair _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 11:39:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12161 for ; Wed, 28 Feb 2001 11:39:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D465644346; Wed, 28 Feb 2001 11:39:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id BEBE244342 for ; Wed, 28 Feb 2001 11:38:44 -0500 (EST) Received: from cowboys (localhost.localdomain [127.0.0.1]) by kevlar (8.11.0/8.11.0) with SMTP id f1SGihd02568 for ; Wed, 28 Feb 2001 10:44:43 -0600 Message-ID: <003801c0a1a5$4433b8d0$a3036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Heads Up on List management Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 10:41:14 -0600 Content-Transfer-Encoding: 7bit The ADs have advised the chairs of a preference to move discussions onto listservs provided by the secretariat. This clears up all sorts of archival issues going forward. Over the next few months, we'll be undertaking efforts to relocate the various SIP discussion lists appropriately. We'll let you know as things happen. -- Dean _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 11:52:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12854 for ; Wed, 28 Feb 2001 11:52:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D102A44355; Wed, 28 Feb 2001 11:52:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id B5A2444355 for ; Wed, 28 Feb 2001 11:51:16 -0500 (EST) 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 LAA14981; Wed, 28 Feb 2001 11:51:10 -0500 (EST) 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 LAA21330; Wed, 28 Feb 2001 11:51:08 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 11:50:57 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F0C6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Dean Willis'" , "IETF SIP (E-mail)" Subject: RE: [SIP] Proposal for ogranizing WG efforts MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 11:50:56 -0500 Just to be real clear, the idea is that the SIPPING group would probably, in it's work, come up with things that needed to be changed in SIP. If it did, the actual change would be done in the SIP core group. The SIPPING group MIGHT do a requirements document, or just hand the problem off. All extensions and changes to SIP would be done in the SIP WG. This might affect some existing drafts that combine a how/why to accomplish a task with the actual change/extension to SIP. Those might have to be split. The hope is, as Dean point out, to have few, general mechanisms rather than lots of applications specific thingies. Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, February 28, 2001 11:39 AM > To: IETF SIP (E-mail) > Subject: [SIP] Proposal for ogranizing WG efforts > > > The WG chairs and the ADs were talking this morning about how > to make the > working group more effective.One idea that came up sounds > interesting, and > I'd like to share it with you. > > There are really two sorts of tasks that happen in the WG today: > > 1) Defining the protocol: SIP and extensions to SIP using its > extension > mechanisms. > > 2) Describing the mechanisms and requirements of doing useful > things with > SIP. > > Many of the discussions over the past years have started as > application-specific extensions that have pointed toward > general-purpose > reusable solutions. For example, Message Waiting Indicator > proposals led to > our understanding of the general usefulness of > Subscribe/Notify (Events) > mechanisms. We sometimes didn't notice the generalizability > of a mechanism > until several iterations into implementation discussions > (Refer). We've > started to learn to differentiate our drafts between protocol > specifics and > usage rationales. Unfortunately, sometimes the "how could we" > discussions > have distracted from the immediate goals of completing the base > specifications. Even the core protocol draft has drawn criticism for > intermixing usage and specification, and the authors have > proposed a rewrite > to separate those components. > > So here's the idea: What if we were to split the SIP WG into > two pieces? > Maybe two WGs? > > The first part would handle the actual protocol > specifications -- things > like 2543bis, and would deal with new methods, new headers, > new response > codes, and other things in response to requirements generated > by the second > part. Hard standards-track stuff, tightly controlled charter. > > The second part would deal with using SIP, primarily from a > rationale-and-requirements perspective. This would include call flows, > application of SIP mechanisms (like using Events for Message > Waiting), and > with things like RFCs to register new MIME types and DHCP > options and the > like. I believe Allison suggested calling such a group the > "SIPPING" effort. > Such a group would of course do a lot of discussios and would > be likely to > generate several informational and BCP track documents as well as > standards-track documents where appropriate. > > This might let us get a little more clarity in the discussions and > discipline in the process -- and separate some of the topics > on the rather > busy mailing list. > > So, what do you think? > > -- > Dean Willis > SIP WG CoChair > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 11:54:33 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12958 for ; Wed, 28 Feb 2001 11:54:32 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E858A44362; Wed, 28 Feb 2001 11:52:25 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id DC5F244351 for ; Wed, 28 Feb 2001 11:50:39 -0500 (EST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA10344; Wed, 28 Feb 2001 08:49:07 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABS18181; Wed, 28 Feb 2001 08:48:48 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA19481; Wed, 28 Feb 2001 08:48:48 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15005.11248.211460.300194@thomasm-u1.cisco.com> To: "Rosen, Brian" Cc: "'Fleischman, Eric W'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Need for encrypted VoIP and Conferencing communications In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6F034@whq-msgusr-02.pit.comms.marconi.com> References: <4FBEA8857476D311A03300204840E1CF01A6F034@whq-msgusr-02.pit.comms.marconi.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 08:48:48 -0800 (PST) Content-Transfer-Encoding: 7bit Rosen, Brian writes: > We have been trying to develop some upgrades to the security of > sip, without much success. We have had interest at meetings, but no > proposals or list discussion. > > Encryption of RTP is defined, and believed to be adequate. Surely you're not talking about the encryption in RFC 1889? Help is on the way with draft-ietf-avt-srtp-00 though. > There is > sentiment to allow integrity protection, which was done at in the > PacketCable specs. I believe this, as well as RTCP payload encryption are part of the SRTP proposal. > Key distribution has to be done with the call control > (sip). The mechanism currently used is to carry the keys in SDP, > which implies that the SDP has to itself be encrypted. The PGP mechanisms > in present SIP will allow you to do that, but we believe that such > mechanisms are insufficient. I would say that it's mostly to do with the lack of integration with MIME more than anything else that make the current PGP solution less than adequate. > For hop-by-hop security between sip components, IPSEC or TLS is quite > satisfactory. The concern is end-to-end, or possibly domain to domain > through an untrusted set of domains. You want the usual suspects, > authentication, integrity protection and confidentiality, with a dose of > replay protection. Some even want non-repudiation, but usually that has to > do with billing, and thus may not be entirely a sip issue. I'd like to see > a better way to get the keys for the RTP (D-H perhaps). I believe that if we can secure e-2-e MIME attachments within SIP. The larger question is whether we have a single MUST/SHOULD (say, SMIME or PGP in MIME), or whether we should allow for several MAY's. I'm conflicted by this because although I think that things are already way too complex, neither SMIME or PGP allow for Kerberos credentials. Ick. The alternate is to allow many different kinds of schemes and require negotiation... double ick. I generally object to hard wiring a single authentication/encryption scheme even beyond not allowing Kerberos: it's seems quite possible and likely that it's not just end to end authentication that's important; we already know that we need to be able to do proxy challenges. If we had a single means of creating an attachment with the proper authentication credentials (possibly encrypted) for whatever entity in the path desires a cryptographically transmogrified blob, we would kill two birds with one stone. What it seems to me that we need is something that is authentication-system neutral for the MIME attachments -- sort of in the spirit of EAP for PPP. Disclaimer: I do not follow the SMIME stuff. However, draft-ietf-smime-symkeydist-02 seems to be on the right general track, but there are other possible avenues as well: RFC 2712 describes a means of doing Kerberized TLS which basically replaces X.509 credentials with Kerberos credentials... same could probably be done for SMIME. So, unfortunately, I'm pretty deep into solution space here, but I do have one question which should drag us back into the requirements space: is there any encryption/authentication need for which a MIME attachment would *not* be suitable as the envelope, given enough flexibility with the attachment authentication and crypto-systems? It sure seems like it would be a clean solution to me to allow any proxy/UA to just add an attachment which is directed toward something else farther downstream of the method or response. If nothing else, it would stop all of this feature creep of special headers for this and that encryption/authentication need. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 11:59:14 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13170 for ; Wed, 28 Feb 2001 11:59:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 65B6844378; Wed, 28 Feb 2001 11:55:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 200A744377 for ; Wed, 28 Feb 2001 11:54:04 -0500 (EST) 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 LAA15227; Wed, 28 Feb 2001 11:54:01 -0500 (EST) 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 LAA22234; Wed, 28 Feb 2001 11:54:02 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Feb 2001 11:54:01 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6F0C7@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "Robinson, Keith" , Mark Watson Cc: "'bidulock@openss7.org'" , sip@lists.bell-labs.com Subject: RE: [SIP] Overlap call setup MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 11:54:00 -0500 Could we bring this issue to a head: Could we ask that those with strongly held opinions compose an email that states: How you want endpoints with dial pads to address another SIP endpoint: One that is a pure SIP device (a SIP phone) One that is a gateway to the PSTN What you want changed, in what RFCs or Drafts Why your way is the best way If we can reach consensus quickly, great. If not, we will Schedule some time at the meeting to discuss If necessary, form a design team or other subgroup to work it out Brian > -----Original Message----- > From: Keith Robinson [mailto:Keith.Robinson@marconi.com] > Sent: Wednesday, February 28, 2001 9:43 AM > To: Mark Watson > Cc: 'bidulock@openss7.org'; Mark Watson; sip@lists.bell-labs.com > Subject: RE: [SIP] Overlap call setup > > > > > Hello, > > > > >Our experience has universally been that our customers > (service providers) > >are not happy with using an inter-digit timer to guess when > end-of-dialling > >has occured - hence the need for overlap. > > Is this because of concern of the delay in setup ? > As discussion on this thread has shown,supporting overlap > within the SIP model, > whether using the > INFO method or multiple INVITEs, is going to lead to a lot > more processing than > just the sending of the extra digits, E.g., waiting for > responses, processing > ACKs, > AAA procedures, all of which may be a bigger drag on setup than > waiting for an EOD timer to mature. Add to that the > administrative issues of > making sure > that networks to which yours connects supports the SIP > procedures necessary to > make overlap work > the way your network wants it to work and we introduce a lot > of extra complexity > for no discernable gain. > > Regards, > > Keith. > > > > > > > > "Mark Watson" on 28/02/2001 12:03:40 > > > > > > > > > > > > To: "'bidulock@openss7.org'" , > "Mark Watson" > > cc: sip@lists.bell-labs.com(bcc: Keith > Robinson/MAIN/MC1) > > > > Subject: RE: [SIP] Overlap call setup > > > > > > > > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 12:03:46 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13372 for ; Wed, 28 Feb 2001 12:03:45 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A0404436A; Wed, 28 Feb 2001 11:59:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id 6D8C14434C for ; Wed, 28 Feb 2001 11:58:35 -0500 (EST) Received: from fokus.gmd.de (dhcp011 [195.37.78.139]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA13662; Wed, 28 Feb 2001 17:58:18 +0100 (MET) Message-ID: <3A9D2CDB.17C6AF8A@fokus.gmd.de> From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ferreiro_j@tsm.es Cc: sip@lists.bell-labs.com Subject: Re: [SIP] geographical location References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 17:52:43 +0100 Content-Transfer-Encoding: 7bit ferreiro_j@tsm.es wrote: > IF (AND ONLY IF) there are not means for a UA to obtain geographical > coordinates on a real time basis BY ITSELF (i mean without interacting with > the cellular network) then it means if you want to provide such services > you WILL BE FORCED to do a translation in the visited cellular network in > terms of: I think this is a possible solution but not the only one. There are solutions which do not require the coordinate translation logic to be built in SIP proxies. Which I would actually like to avoid as it may have some tricky side-effects, for example failure if encryption is used or used outbound proxy is not able to perform a correct translation. The other solutions could be in order of my preference 1) having a "where am I" service in the access network (which performs exactly the same translation logic but enables end-devices to insert geo-coordinates) 2) having the translation logic in end-devices > INVITE reservations@hotel.com?cellid=lewkjf > into > INVITE reservations@hotel.com?latitutude=x;logitude=y;elevation=z > > actually IF a translation is required I would rather prefer to handle this > location info in a specific header. In fact, the syntax above indicates headers. I like the ability to specify header field values in URLs. Location information actually identifies services and this is what URLs are used for in a protocol- independent manner. For example, it allows the following link to be included in a webpage: Turkey: Look at hotels and call a reservation office Jiri _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 12:57:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16328 for ; Wed, 28 Feb 2001 12:57:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F3C794433C; Wed, 28 Feb 2001 12:57:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from aurora.tsm.es (unknown [194.224.100.20]) by lists.bell-labs.com (Postfix) with ESMTP id E374144337 for ; Wed, 28 Feb 2001 12:55:58 -0500 (EST) Received: by aurora.tsm.es; (8.8.8/1.3/10May95) id SAA28430; Wed, 28 Feb 2001 18:55:56 +0100 (MET) From: Subject: Re: [SIP] geographical location To: Jiri Kuthan Cc: sip@lists.bell-labs.com Message-ID: X-MIMETrack: Serialize by Router on abantos/TSM( =?iso-8859-1?q?Versi=F3n_5=2E0=2E5_|Octubre_21=2C_2000=29_at_28=2F02=2F?= =?us-ascii?q?2001?= 06:55:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 18:55:25 +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA16328 Hi, jiri, thank you. Comments below ferreiro_j@tsm.es wrote: >> IF (AND ONLY IF) there are not means for a UA to obtain geographical >> coordinates on a real time basis BY ITSELF (i mean without interacting with >> the cellular network) then it means if you want to provide such services >> you WILL BE FORCED to do a translation in the visited cellular network in >> terms of: >I think this is a possible solution but not the only one. There are solutions >which do not require the coordinate translation logic to be built in >SIP proxies. Which I would actually like to avoid as it may have some >tricky side-effects, for example failure if encryption is used or >used outbound proxy is not able to perform a correct translation. Well, I see what you mean. See I just mention "... translation in the visited cellular network..." so it sounds quite generic for me (SIP server, application server, etc.). I am too new in SIP to suggest the right entity. Your arguments, anyway, sounds to me quite appropriate. >The other solutions could be in order of my preference >1) having a "where am I" service in the access network (which performs > exactly the same translation logic but enables end-devices to insert > geo-coordinates) Ummm, are you suggesting not to include the location info. in the session establishment but to offer a server in the visited network to perform location queries? This is LCS, and for some scenarios it is the best option. Anyway any realtime response will depend on the location technology deployed in the visited network (assisted GPS, triangulation takes some seconds, Cell-Id doesn´t) >2) having the translation logic in end-devices Does it mean the translation is to be performed on the end-device that establishes the call? Probably the easiest scenario would be a)to offer a public match between Cell-Ids and geographical coordinates b)include in the Cell-Ids structure the geographical coordinates Anyway no Cellular Operator has offered such information as far as i know. By the way visited operators could change slightly the geographical coordinates every time a Cell-Id is translated in order to hide the exact position of their radio systems to competitors. That's more or less what the US goverment used to do with GPS in every positioning query:( For everyone interested in location staff, i would recommend to read the different scenarios described in LCS architecture (mobile originated queries, third party originated queries, call-related, non-call-related) and also the ones covered by CAMEL Phase 3 (subscription to Presentity and location-changes) and SoLSA (location-based billing). Every different scenario requires different performance in terms of accuracy, traffic volume, real time constraints, authorisation, etc. and also targets different needs. LCS is primary for E911, so LCS servers do not handle heavy traffic, are more focused on accuracy rather than real-time. CAMEL Phase 3 is based on Cell-Id and offers call-related location info, presence & location-change notifications, so CAMEL "servers" will handle heavy traffic, are more focused on real-time rather than accuracy. SoLSA covers location-based billing and is a more network-centric vision than the others. >> INVITE reservations@hotel.com?cellid=lewkjf >> into >> INVITE reservations@hotel.com?latitutude=x;logitude=y;elevation=z >> >> actually IF a translation is required I would rather prefer to handle this >> location info in a specific header. >In fact, the syntax above indicates headers. I like the ability to >specify header field values in URLs. Location information actually >identifies services and this is what URLs are used for in a protocol- >independent manner. For example, it allows the following link to be >included in a webpage: > Turkey: > Look at hotels > and call a > reservation office >Jiri I must agree with you. By the way, SIP proxies can change URLs. Is that correct? 3GPP seems to have defined a kind of Visited Proxy Server/Outbound Proxy :) Anyway, as you mention, visited network real time translation is not the best solution with encryption scenarios regards javier f. -----------------------------< O >----------------------------------- Javier Ferreiro Garcia Consultant Telefonica Moviles Spain Div. de Nuevos Productos/Voice Services Unit Telf.: +34 630 00 43 13 -----------------------------< O >----------------------------------- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 13:47:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18619 for ; Wed, 28 Feb 2001 13:47:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 25D8744337; Wed, 28 Feb 2001 13:47:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id E142E44337 for ; Wed, 28 Feb 2001 06:57:22 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02532; Wed, 28 Feb 2001 06:57:22 -0500 (EST) Message-Id: <200102281157.GAA02532@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-jfp-sip-isup-header-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 06:57:22 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mapping of ISUP parameters to SIP headers in SIP-T Author(s) : J. Peterson, L. Ong Filename : draft-jfp-sip-isup-header-00.txt Pages : 11 Date : 27-Feb-01 This document defines procedures within SIP-T for translation of ISUP call context to SIP call context and vice versa to allow ISUP calls to pass through SIP networks while preserving feature transparency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jfp-sip-isup-header-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-jfp-sip-isup-header-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-jfp-sip-isup-header-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: <20010227123708.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jfp-sip-isup-header-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jfp-sip-isup-header-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010227123708.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 13:48:32 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18679 for ; Wed, 28 Feb 2001 13:48:31 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BCA4144341; Wed, 28 Feb 2001 13:47:25 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by lists.bell-labs.com (Postfix) with ESMTP id 9125F44336 for ; Wed, 28 Feb 2001 11:30:19 -0500 (EST) Received: from src-news.pa.dec.com (src-news.pa.dec.com [16.4.16.111]) by mail2.digital.com (8.9.2/8.9.3/WV2.0h) with ESMTP id IAA29485 for ; Wed, 28 Feb 2001 08:30:18 -0800 (PST) Received: by src-news.pa.dec.com; id IAA31649; Wed, 28 Feb 2001 08:29:02 -0800 (PST) To: dec-mail-lists-ietf@usenet.pa.dec.com Path: pa.dec.com!owner-ietf-redist From: Internet-Drafts@ietf.org Newsgroups: dec.mail.lists.ietf Organization: Systems Research Center, Compaq Computer Corporation Lines: 79 Distribution: dec Message-ID: <200102281157.GAA02532@ietf.org> To: IETF-Announce: ;;;, @pa.dec.com;;;;;;, @pa.dec.com;;;;;;;;;;;;;;;;;;;;;;;;, @pa.dec.com;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Cc: sip@lists.bell-labs.com In-Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" X-Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id LAA01684 for ietf-123-outbound.02@ietf.org; Wed, 28 Feb 2001 11:05:00 -0500 (EST) X-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 GAA29829 for ; Wed, 28 Feb 2001 06:57:21 -0500 (EST) X-Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02532; Wed, 28 Feb 2001 06:57:22 -0500 (EST) X-Received: by src-news.pa.dec.com; id IAA25129; Wed, 28 Feb 2001 08:29:01 -0800 (PST) X-Received: by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA26731; Wed, 28 Feb 2001 08:29:00 -0800 X-Received: from nsl-too.pa.dec.com by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA24489; Wed, 28 Feb 2001 08:29:00 -0800 X-Received: by nsl-too.pa.dec.com; (5.65v4.0/1.1.8.2/06Jun96-0357PM) id AA15800; Wed, 28 Feb 2001 08:29:00 -0800 X-Received: from pobox1.pa.dec.com by nsl-too.pa.dec.com; (5.65v4.0/1.1.8.2/06Jun96-0357PM) id AA15701; Wed, 28 Feb 2001 08:28:59 -0800 X-Received: by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA24395; Wed, 28 Feb 2001 08:28:59 -0800 X-Received: from zmamail02.nz-tay.cpqcorp.net by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA23934; Wed, 28 Feb 2001 08:28:58 -0800 X-Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 0FFF95EB9; Wed, 28 Feb 2001 11:28:58 -0500 (EST) X-Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id A87EC490B for ; Wed, 28 Feb 2001 11:28:57 -0500 (EST) Subject: [SIP] I-D ACTION:draft-jfp-sip-isup-header-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 28 Feb 2001 08:29:02 -0800 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mapping of ISUP parameters to SIP headers in SIP-T Author(s) : J. Peterson, L. Ong Filename : draft-jfp-sip-isup-header-00.txt Pages : 11 Date : 27-Feb-01 This document defines procedures within SIP-T for translation of ISUP call context to SIP call context and vice versa to allow ISUP calls to pass through SIP networks while preserving feature transparency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jfp-sip-isup-header-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-jfp-sip-isup-header-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-jfp-sip-isup-header-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: <20010227123708.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jfp-sip-isup-header-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jfp-sip-isup-header-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010227123708.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 13:59:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19087 for ; Wed, 28 Feb 2001 13:59:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0F7B044348; Wed, 28 Feb 2001 13:59:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id CD1464433A for ; Wed, 28 Feb 2001 13:58:24 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA17670 for ; Wed, 28 Feb 2001 13:58:24 -0500 (EST) Message-ID: <3A9D4A50.7C838D5A@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Interesting report on deploying PKI Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 13:58:24 -0500 Content-Transfer-Encoding: 7bit http://www.gao.gov/cgi-bin/getrpt?rptno=gao-01-277 -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 14:46:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20811 for ; Wed, 28 Feb 2001 14:46:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B952344337; Wed, 28 Feb 2001 14:46:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 2429C44336 for ; Wed, 28 Feb 2001 14:45:39 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f1SJjY114224; Wed, 28 Feb 2001 14:45:34 -0500 (EST) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id OAA17099; Wed, 28 Feb 2001 14:44:27 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Feb 2001 14:45:33 -0500 Message-ID: From: "Roy, Radhika R, ALCOO" To: Dean Willis , "IETF SIP (E-mail)" Subject: RE: [SIP] Proposal for organizing WG efforts MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 14:45:27 -0500 Hi, Dean: The proposal sounds good to me. I like to get a little more clarifications. Let us take an example. If we start a work in SIPPING WG and find that there needs to an extension in SIP, should we then bring back that discussion in the SIP WG? In another example, we have started an effort in SIP-AAA group discussion. Will that discussion be a part of the SIPPING WG? Best regards, Radhika R. Roy AT&T -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Wednesday, February 28, 2001 11:39 AM To: IETF SIP (E-mail) Subject: [SIP] Proposal for ogranizing WG efforts The WG chairs and the ADs were talking this morning about how to make the working group more effective.One idea that came up sounds interesting, and I'd like to share it with you. There are really two sorts of tasks that happen in the WG today: 1) Defining the protocol: SIP and extensions to SIP using its extension mechanisms. 2) Describing the mechanisms and requirements of doing useful things with SIP. Many of the discussions over the past years have started as application-specific extensions that have pointed toward general-purpose reusable solutions. For example, Message Waiting Indicator proposals led to our understanding of the general usefulness of Subscribe/Notify (Events) mechanisms. We sometimes didn't notice the generalizability of a mechanism until several iterations into implementation discussions (Refer). We've started to learn to differentiate our drafts between protocol specifics and usage rationales. Unfortunately, sometimes the "how could we" discussions have distracted from the immediate goals of completing the base specifications. Even the core protocol draft has drawn criticism for intermixing usage and specification, and the authors have proposed a rewrite to separate those components. So here's the idea: What if we were to split the SIP WG into two pieces? Maybe two WGs? The first part would handle the actual protocol specifications -- things like 2543bis, and would deal with new methods, new headers, new response codes, and other things in response to requirements generated by the second part. Hard standards-track stuff, tightly controlled charter. The second part would deal with using SIP, primarily from a rationale-and-requirements perspective. This would include call flows, application of SIP mechanisms (like using Events for Message Waiting), and with things like RFCs to register new MIME types and DHCP options and the like. I believe Allison suggested calling such a group the "SIPPING" effort. Such a group would of course do a lot of discussios and would be likely to generate several informational and BCP track documents as well as standards-track documents where appropriate. This might let us get a little more clarity in the discussions and discipline in the process -- and separate some of the topics on the rather busy mailing list. So, what do you think? -- Dean Willis SIP WG CoChair _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 15:06:13 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21899 for ; Wed, 28 Feb 2001 15:06:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8C00F44339; Wed, 28 Feb 2001 15:06:07 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 5C52344337 for ; Wed, 28 Feb 2001 15:05:53 -0500 (EST) Received: from cowboys (localhost.localdomain [127.0.0.1]) by kevlar (8.11.0/8.11.0) with SMTP id f1SKBod02862; Wed, 28 Feb 2001 14:11:50 -0600 Message-ID: <003101c0a1c2$33138ae0$ad036e3f@dynamicsoft.com> From: "Dean Willis" To: "Roy, Radhika R, ALCOO" , "IETF SIP (E-mail)" References: Subject: Re: [SIP] Proposal for organizing WG efforts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 14:08:21 -0600 Content-Transfer-Encoding: 7bit I would say that work started in SIPPING might lead to publication of requirements and "umbrella" or "framework" documents that would indicate (perhaps indirectly) the need for a specific extension to SIP. The requirements would then be referred from SIPPING to SIP, and teh SIP group would hash out the extension. AAA work might be a special case. My guess is that the same model could apply -- requirements work would be done in SIPPING, and any changes or extensions needed to SIP might be in SIP. -- Dean ----- Original Message ----- From: "Roy, Radhika R, ALCOO" To: "Dean Willis" ; "IETF SIP (E-mail)" Sent: Wednesday, February 28, 2001 1:45 PM Subject: RE: [SIP] Proposal for organizing WG efforts > Hi, Dean: > > The proposal sounds good to me. > > I like to get a little more clarifications. Let us take an example. > > If we start a work in SIPPING WG and find that there needs to an extension > in SIP, should we then bring back that discussion in the SIP WG? > > In another example, we have started an effort in SIP-AAA group discussion. > Will that discussion be a part of the SIPPING WG? > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, February 28, 2001 11:39 AM > To: IETF SIP (E-mail) > Subject: [SIP] Proposal for ogranizing WG efforts > > > The WG chairs and the ADs were talking this morning about how to make the > working group more effective.One idea that came up sounds interesting, and > I'd like to share it with you. > > There are really two sorts of tasks that happen in the WG today: > > 1) Defining the protocol: SIP and extensions to SIP using its extension > mechanisms. > > 2) Describing the mechanisms and requirements of doing useful things with > SIP. > > Many of the discussions over the past years have started as > application-specific extensions that have pointed toward general-purpose > reusable solutions. For example, Message Waiting Indicator proposals led to > our understanding of the general usefulness of Subscribe/Notify (Events) > mechanisms. We sometimes didn't notice the generalizability of a mechanism > until several iterations into implementation discussions (Refer). We've > started to learn to differentiate our drafts between protocol specifics and > usage rationales. Unfortunately, sometimes the "how could we" discussions > have distracted from the immediate goals of completing the base > specifications. Even the core protocol draft has drawn criticism for > intermixing usage and specification, and the authors have proposed a rewrite > to separate those components. > > So here's the idea: What if we were to split the SIP WG into two pieces? > Maybe two WGs? > > The first part would handle the actual protocol specifications -- things > like 2543bis, and would deal with new methods, new headers, new response > codes, and other things in response to requirements generated by the second > part. Hard standards-track stuff, tightly controlled charter. > > The second part would deal with using SIP, primarily from a > rationale-and-requirements perspective. This would include call flows, > application of SIP mechanisms (like using Events for Message Waiting), and > with things like RFCs to register new MIME types and DHCP options and the > like. I believe Allison suggested calling such a group the "SIPPING" effort. > Such a group would of course do a lot of discussios and would be likely to > generate several informational and BCP track documents as well as > standards-track documents where appropriate. > > This might let us get a little more clarity in the discussions and > discipline in the process -- and separate some of the topics on the rather > busy mailing list. > > So, what do you think? > > -- > Dean Willis > SIP WG CoChair > > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > > _______________________________________________ > This list is for continuing development of the SIP protocol. > The sip-implementor's list is the place to discuss implementation, > and to receive advice on understanding existing sip. > To subscribe to it, send mail to > sip-implementors-request@cs.columbia.edu with "subscribe" in the body. > _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 17:59:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00388 for ; Wed, 28 Feb 2001 17:59:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A38D444337; Wed, 28 Feb 2001 17:59:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id D669F44336 for ; Wed, 28 Feb 2001 17:58:19 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 7959D1E06C for ; Wed, 28 Feb 2001 17:58:19 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA03054 for ; Wed, 28 Feb 2001 17:58:18 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (SGI-8.9.3/8.8.5) id RAA83171 for sip@lists.bell-labs.com; Wed, 28 Feb 2001 17:58:18 -0500 (EST) Message-Id: <200102282258.RAA83171@fish-ha.research.att.com> To: sip@lists.bell-labs.com Subject: [SIP] DCS drafts updated Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 17:58:18 -0500 (EST) I have submitted updated versions of five dcsgroup drafts; until they are in the usual places they may be obtained from ftp://ftp.research.att.com/dist/wtm/draft* (also in that same place is my genealogy file, marshall.zip, in case that may be more interesting) Changes since the last IETF: removed references to other internet-drafts, including draft-dcsgroup-sip-arch-xx and draft-ietf-sip-2543bis-xx some authors have changed companies Other specific changes are: draft-ietf-sip-manyfolks-resource-01 removal of dependencies on 2543bis, specifically 183 provisional response Content-Disposition header addition of an option tag for Require and Support headers clarified the use of 180 vs. 183 at UAS draft-ietf-sip-state-01 changed "host" to "hostport" in syntax draft-ietf-sip-call-auth-01 addition of text specifying the handling of the token value from the Media-Authorization header draft-dcsgroup-sip-arch-04 changes usage of tel: urls, particularly routing number and local number portability indication draft-dcsgroup-sip-proxy-proxy-04 addition of option tags for each individual new header, so a UA/proxy can indicate support for only a subset. changes to the Dcs-Billing-ID header to add financial entity ID fixes to syntax description of Dcs-Billing-Info Bill Marshall wtm@research.att.com _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 18:30:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01409 for ; Wed, 28 Feb 2001 18:30:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B79E64433B; Wed, 28 Feb 2001 18:30:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4]) by lists.bell-labs.com (Postfix) with SMTP id A91AB44336 for ; Wed, 28 Feb 2001 18:29:29 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 28 Feb 2001 15:28:30 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 28 Feb 2001 15:28:30 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD3C7E40@mailserver.sylantro.com> From: "Sharath Rajasekar" To: "Henning G. Schulzrinne" , sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1683561452698-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Subject: [SIP] Interacting with CAs that dont support BYE Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 15:28:25 -0800 Content-Transfer-Encoding: 7bit Hi, An interesting call flow resulted when interacting with a Call Agent that does not support CANCELs. Lets say we have two CAs, one supporting CANCEL and the other that does not support CANCEL and uses BYE instead. A B | | | | | | | | | | _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 18:31:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01475 for ; Wed, 28 Feb 2001 18:31:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E98EC44340; Wed, 28 Feb 2001 18:31:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4]) by lists.bell-labs.com (Postfix) with SMTP id C75C54433E for ; Wed, 28 Feb 2001 18:30:19 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 28 Feb 2001 15:29:20 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 28 Feb 2001 15:29:20 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD3C7E43@mailserver.sylantro.com> From: "Sharath Rajasekar" To: "Henning G. Schulzrinne" , sip@lists.bell-labs.com Expiry-Date: Fri, 2 Mar 2001 15:25:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1683565A52715-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Recall: Interacting with CAs that dont support BYE Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 15:29:10 -0800 Content-Transfer-Encoding: 7bit Sharath Rajasekar would like to recall the message, "Interacting with CAs that dont support BYE". _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 18:52:11 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01976 for ; Wed, 28 Feb 2001 18:52:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 685C044348; Wed, 28 Feb 2001 18:52:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lists.bell-labs.com (Postfix) with ESMTP id ACDED44346 for ; Wed, 28 Feb 2001 18:51:14 -0500 (EST) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1SNnro05102 for ; Wed, 28 Feb 2001 15:49:53 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f1SNpDX05371 for ; Wed, 28 Feb 2001 15:51:13 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A01.00832D52 ; Wed, 28 Feb 2001 15:52:48 -0800 X-Lotus-FromDomain: 3COM From: Aaron_Madsen@3com.com To: sip@lists.bell-labs.com Message-ID: <88256A01.00832ABF.00@hqoutbound.ops.3com.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] How to deal with too large/malformed 200 OK? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 17:49:31 -0600 Hi, Anyone have any ideas on what to do with a 200 OK to an INVITE that is too large for a UA to handle (for example, because of a very large route) or that is malformed? For a request, there's 413 Request Entity Too Large and 400 Bad Request, easy. But there's no SIP way to respond to a bad response... Perhaps NACK instead of ACK? ;-) Thanks, Aaron _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 18:53:17 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02080 for ; Wed, 28 Feb 2001 18:53:17 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 71E564434C; Wed, 28 Feb 2001 18:52:30 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4]) by lists.bell-labs.com (Postfix) with SMTP id A94C444346 for ; Wed, 28 Feb 2001 18:51:40 -0500 (EST) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 28 Feb 2001 15:50:41 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 28 Feb 2001 15:50:41 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD3C7E6C@mailserver.sylantro.com> From: "Sharath Rajasekar" To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1683515B53124-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Subject: [SIP] Interacting with CAs that dont support CANCEL Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 28 Feb 2001 15:50:39 -0800 Content-Transfer-Encoding: 7bit Hi, An interesting call flow resulted when interacting with a Call Agent that does not support CANCELs. Lets say we have two CAs, one (A)supporting CANCEL and the other (B) that does not support CANCEL and uses BYE instead. (Support for CANCELs is a "should" not "must" as per bis02) Do you treat the CANCEL as a "CANCEL" or as a "BYE" ? A B | | |<-----INVITE-----------| |-----180-------------->| |<-----BYE--------------| |------200------------->| | | Is this legal ? If we treat it as a BYE, as per bis-02, the INVITE must be completed with a final response and an ACK ? So will the previous flow, result in another 200OK and an ACK for that. In the other case, when we send the CANCEL, since the other CA does not support CANCELs, they drop the CANCELs and continue to ring the phone after the A has disconnected. A B | | |------INVITE---------->| |<-----180--------------| |------CANCEL---------->| |<-----180--------------| |<-----180--------------| | | In this case, should B, send back a 405 Not supported in response to a CANCEL ? And should we follow that with a BYE and wait for a 200OK. Regards Sharath _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body. From sip-admin@lists.bell-labs.com Wed Feb 28 20:14:12 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04361 for ; Wed, 28 Feb 2001 20:14:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F11C4433B; Wed, 28 Feb 2001 20:14:08 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id C43AB44336 for ; Wed, 28 Feb 2001 20:13:13 -0500 (EST) Received: from fokus.gmd.de (dhcp011 [195.37.78.139]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id CAA27856; Thu, 1 Mar 2001 02:13:11 +0100 (MET) Message-ID: <3A9DA251.4263E4B5@fokus.gmd.de> From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ferreiro_j@tsm.es Cc: SIP mailing list Subject: Re: [SIP] geographical location References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 01 Mar 2001 02:13:53 +0100 Content-Transfer-Encoding: 7bit ferreiro_j@tsm.es wrote: > >The other solutions could be in order of my preference > >1) having a "where am I" service in the access network (which performs > > exactly the same translation logic but enables end-devices to insert > > geo-coordinates) > > Ummm, are you suggesting not to include the location info. in the session > establishment but to offer a server in the visited network to perform > location queries? cell phone "where am I" service SIP destination | | | | "where am I (d)?"| | | --------------------->| | | x,y,z | d->x,y,z | | <---------------------| | | INVITE a@b?geo-info=xyz | | ------------------------------------------------------------>| > >2) having the translation logic in end-devices > > Does it mean the translation is to be performed on the end-device that > establishes the call? > > Probably the easiest scenario would be > a)to offer a public match between Cell-Ids and geographical coordinates > b)include in the Cell-Ids structure the geographical coordinates > > Anyway no Cellular Operator has offered such information as far as i know. Is this such a hard problem? If the operators do not offer this information, after-market competitors may possibly do this job as well. There are actually websites (sorry, I cannot find an illustrating bookmark right now) that maintain such translation info. [...] > By the way, SIP proxies can change URLs. Is that correct? "The Request URI MAY be re-written by proxies". (2543bis, Section 4.3) Regards, Jiri _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request@cs.columbia.edu with "subscribe" in the body.