From HKaplan at acmepacket.com Wed Oct 1 01:49:35 2008 From: HKaplan at acmepacket.com (Hadriel Kaplan) Date: Wed, 1 Oct 2008 01:49:35 -0400 Subject: [SIPForum-techwg] Reliable provisional responses in SIPconnect 1.1 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0011FF65C@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0011FF65C@GBNTHT12009MSX.gb002.siemens.net> Message-ID: Hey John, Inline... > -----Original Message----- > From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On > Behalf Of Elwell, John > > There was also an opposing view that suggested that RFC 3262 support > should be mandatory for IPPBXs. The reason given was that a service > provider wanting to provide early media would want to be sure that SDP > answer in a provisional response reaches the IP-PBX. It's actually for either side really - some Enterprises need it too. And for those which send offer-less Invites it's even more important. > However, this would > raise the bar for adoption by IP-PBXs. Yes, it would. PRACK sucks due to the offer/answer complexity it creates. But providing ring-tone and announcements is a pretty big deal. :( > The mechanism is know to be > rather complex, and the need for it will be diminished or even removed > in the future as ICE and DTLS-SRTP get deployed (since in-band > mechanisms will achieve the desired result). Uh huh. That'll be real soon now. :) BTW, DTLS-SRTP does not achieve the same result, fwiw, and even ICE should work better with reliable provisional responses. > Furthermore, assuming TCP transport, the only benefit of reliable > provisional responses is when a SIP intermediary somehow "loses" the > SDP. That's assuming TCP transport for the whole path, not just the Ent-SP hop. > Also the mechanism is not helpful if SIP intermediaries (B2BUA) > generate PRACK on a hop-by-hop basis, rather than ensuring it operates > end-to-end. Indeed, that's exactly what I'm trying to avoid. We fought off doing that for years and eventually succumbed to customer demand, but it sucks to do it. If we don't mandate support for PRACK, then B2BUA's will continue to need to "interwork" it for those devices which Require it. (and yes, I've tried to tell them to stop Requiring it) In fact, I suggest we put in a "MUST NOT Require it in Requests" - where "Require" means putting it in the Require header of a request. That's bad mojo. "MUST Support it" is a different thing, as you know. If we don't put in a "MUST Support", then we can't assure early media. -hadriel From john.elwell at siemens.com Wed Oct 1 05:35:37 2008 From: john.elwell at siemens.com (Elwell, John) Date: Wed, 01 Oct 2008 10:35:37 +0100 Subject: [SIPForum-techwg] Reliable provisional responses in SIPconnect 1.1 In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D0011FF65C@GBNTHT12009MSX.gb002.siemens.net> Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0011FF85F@GBNTHT12009MSX.gb002.siemens.net> Hadriel, > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com] > Sent: 01 October 2008 06:50 > To: Elwell, John; techwg at sipforum.org > Subject: RE: Reliable provisional responses in SIPconnect 1.1 > > Hey John, > Inline... > > > -----Original Message----- > > From: techwg-bounces at sipforum.org > [mailto:techwg-bounces at sipforum.org] On > > Behalf Of Elwell, John > > > > There was also an opposing view that suggested that RFC 3262 support > > should be mandatory for IPPBXs. The reason given was that a service > > provider wanting to provide early media would want to be > sure that SDP > > answer in a provisional response reaches the IP-PBX. > > It's actually for either side really - some Enterprises need > it too. And for those which send offer-less Invites it's > even more important. [JRE] Good point, since with an offer-less INVITE, you can't send SDP offer in an unreliable response, and waiting for the 200 OK would deny the possibility of early media. So perhaps an IP-PBX that supports the sending of offerless INVITEs MUST support 100rel, and a SP that supports early media in response to offerless INVITEs MUST support 100rel. > > > > However, this would > > raise the bar for adoption by IP-PBXs. > > Yes, it would. PRACK sucks due to the offer/answer > complexity it creates. But providing ring-tone and > announcements is a pretty big deal. :( > > > > The mechanism is know to be > > rather complex, and the need for it will be diminished or > even removed > > in the future as ICE and DTLS-SRTP get deployed (since in-band > > mechanisms will achieve the desired result). > > Uh huh. That'll be real soon now. :) [JRE] Probably not that soon, but the point I was making was avoid making things mandatory now that would not be needed in the longer term. It sounds like a good principle, although it might not be practicable in this particular case. > BTW, DTLS-SRTP does > not achieve the same result, fwiw, and even ICE should work > better with reliable provisional responses. [JRE] Why would ICE work better - wouldn't the STUN packets typically get there quicker than PRACK? I guess not if you have to wait for several candidates to be tried before one gets through, but in the majority of cases I would have thought it would work better (if better means faster). > > > Furthermore, assuming TCP transport, the only benefit of reliable > > provisional responses is when a SIP intermediary somehow "loses" the > > SDP. > > That's assuming TCP transport for the whole path, not just > the Ent-SP hop. > > > > Also the mechanism is not helpful if SIP intermediaries (B2BUA) > > generate PRACK on a hop-by-hop basis, rather than ensuring > it operates > > end-to-end. > > Indeed, that's exactly what I'm trying to avoid. We fought > off doing that for years and eventually succumbed to customer > demand, but it sucks to do it. If we don't mandate support > for PRACK, then B2BUA's will continue to need to "interwork" > it for those devices which Require it. (and yes, I've tried > to tell them to stop Requiring it) > > In fact, I suggest we put in a "MUST NOT Require it in > Requests" - where "Require" means putting it in the Require > header of a request. [JRE] Agreed. > That's bad mojo. > > "MUST Support it" is a different thing, as you know. If we > don't put in a "MUST Support", then we can't assure early media. [JRE] Well, offerless INVITES apart, if you support PRACK you essentially have to repeat the 18x if you get a timeout. You can repeat an unreliable 18x at intervals anyway, although the recommended frequency is too slow. However, if you really want to increase the chances of an unreliable 18x arriving, repeat it a couple of times, with a delay of say 2*T1 before each retransmission. Note that the early media RTP itself is also not guaranteed to arrive, so ensuring that the UAC has received the SDP answer will not ensure that it receives early media. I don't necessarily disagree with your points. I just want to explore whether there is a way of avoiding mandating 100rel. John From john.elwell at siemens.com Wed Oct 1 05:46:02 2008 From: john.elwell at siemens.com (Elwell, John) Date: Wed, 01 Oct 2008 10:46:02 +0100 Subject: [SIPForum-techwg] Proposed new text for SIPconnect 1.1 section15.2 (Ringback tone and early media) In-Reply-To: A References: <0D5F89FAC29E2C41B98A6A762007F5D0011FF65B@GBNTHT12009MSX.gb002.siemens.net> A Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0011FF871@GBNTHT12009MSX.gb002.siemens.net> > -----Original Message----- > From: Mark Trayer [mailto:mtrayer at sta.samsung.com] > Sent: 30 September 2008 20:33 > To: Elwell, John; techwg at sipforum.org > Subject: RE: [SIPForum-techwg] Proposed new text for > SIPconnect 1.1 section15.2 (Ringback tone and early media) > > Hi John, > > A few initial comments: > > - outside of use of SDP (which is MAY strength) how are we > defining what > we mean by "valid RTP packets"? [JRE] I was hoping we could avoid that - the present text talks about "RTP stream ... that is described by the SDP answer", which I thought was equally vague, but if people prefer that formulation.... > - use cases certainly exist where some kind of network media (i.e. a > branding announcement) needs to be followed by ringback. As you note > the in the proposal once RTP is being received a 18x (no SDP) does not > result in local ringback. So to achieve the > "branding-then-ringing" use > case is the assumption that the network/service provider once it > provides early media also provides all subsequent audible > call progress > indications (such as application of ringing tone)? [JRE] Good point, but I am not sure how we resolve this. We could say that if RTP stops, then you go back to playing local ringback tone (if there was a 180 earlier), but how do you detect that it has stopped? Or you could say that if you receive a 180, you play local ringback tone until further RTP arrives, but what if there is some residual RTP that was sent before the 180 and somehow got delayed? I guess the latter case is unlikely. > - how does the proposed text handle multiple answering SDPs > on multiple > early dialogs or in lieu of SDP reception multiple RTP > "streams" all of > which conform to the offer? [JRE] I think the text does handle it, except that it does not tell you which RTP stream to render if you receive multiple RTP streams. John From abjohnston at avaya.com Wed Oct 1 09:37:42 2008 From: abjohnston at avaya.com (Johnston, Alan B (Alan)) Date: Wed, 1 Oct 2008 09:37:42 -0400 Subject: [SIPForum-techwg] Reliable provisional responses in SIPconnect1.1 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0011FF85F@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0011FF65C@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0011FF85F@GBNTHT12009MSX.gb002.siemens.net> Message-ID: <73C8B82BCF7C1A4BA3149FCF6CB6D4FCD4AEC5@300815ANEX3.global.avaya.com> I agree 100% with John. Making PRACK mandatory just adds complexity to this specification. And saying that early media does not work without it is just plain wrong. The whole point of doing 1.1 was to reduce and refine this spec, getting rid of things that are not completely necessary. To do otherwise is to fail at our task at hand. See a few comments below. Thanks, Alan -----Original Message----- From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Elwell, John Sent: Wednesday, October 01, 2008 5:36 AM To: Hadriel Kaplan; techwg at sipforum.org Subject: Re: [SIPForum-techwg] Reliable provisional responses in SIPconnect1.1 Hadriel, > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com] > Sent: 01 October 2008 06:50 > To: Elwell, John; techwg at sipforum.org > Subject: RE: Reliable provisional responses in SIPconnect 1.1 > > Hey John, > Inline... > > > -----Original Message----- > > From: techwg-bounces at sipforum.org > [mailto:techwg-bounces at sipforum.org] On > > Behalf Of Elwell, John > > > > There was also an opposing view that suggested that RFC 3262 support > > should be mandatory for IPPBXs. The reason given was that a service > > provider wanting to provide early media would want to be > sure that SDP > > answer in a provisional response reaches the IP-PBX. > > It's actually for either side really - some Enterprises need > it too. And for those which send offer-less Invites it's > even more important. [JRE] Good point, since with an offer-less INVITE, you can't send SDP offer in an unreliable response, and waiting for the 200 OK would deny the possibility of early media. So perhaps an IP-PBX that supports the sending of offerless INVITEs MUST support 100rel, and a SP that supports early media in response to offerless INVITEs MUST support 100rel. AJ> If you send an offer-less INVITE, you can expect to have some media clipping. We are not going to support all kinds of offer/answer scenarios - this is a huge source of interop failure with SIP. We do not want to mandate this in SIPConnect. > > > > However, this would > > raise the bar for adoption by IP-PBXs. > > Yes, it would. PRACK sucks due to the offer/answer > complexity it creates. But providing ring-tone and > announcements is a pretty big deal. :( > > > > The mechanism is know to be > > rather complex, and the need for it will be diminished or > even removed > > in the future as ICE and DTLS-SRTP get deployed (since in-band > > mechanisms will achieve the desired result). > > Uh huh. That'll be real soon now. :) [JRE] Probably not that soon, but the point I was making was avoid making things mandatory now that would not be needed in the longer term. It sounds like a good principle, although it might not be practicable in this particular case. AJ> The point is that PRACK is a bad SIP extension and a dead-end in terms of future development of the protocol. We should drop it sooner rather than later. > BTW, DTLS-SRTP does > not achieve the same result, fwiw, and even ICE should work > better with reliable provisional responses. [JRE] Why would ICE work better - wouldn't the STUN packets typically get there quicker than PRACK? I guess not if you have to wait for several candidates to be tried before one gets through, but in the majority of cases I would have thought it would work better (if better means faster). > > > Furthermore, assuming TCP transport, the only benefit of reliable > > provisional responses is when a SIP intermediary somehow "loses" the > > SDP. > > That's assuming TCP transport for the whole path, not just > the Ent-SP hop. > > > > Also the mechanism is not helpful if SIP intermediaries (B2BUA) > > generate PRACK on a hop-by-hop basis, rather than ensuring > it operates > > end-to-end. > > Indeed, that's exactly what I'm trying to avoid. We fought > off doing that for years and eventually succumbed to customer > demand, but it sucks to do it. If we don't mandate support > for PRACK, then B2BUA's will continue to need to "interwork" > it for those devices which Require it. (and yes, I've tried > to tell them to stop Requiring it) > > In fact, I suggest we put in a "MUST NOT Require it in > Requests" - where "Require" means putting it in the Require > header of a request. [JRE] Agreed. > That's bad mojo. > > "MUST Support it" is a different thing, as you know. If we > don't put in a "MUST Support", then we can't assure early media. [JRE] Well, offerless INVITES apart, if you support PRACK you essentially have to repeat the 18x if you get a timeout. You can repeat an unreliable 18x at intervals anyway, although the recommended frequency is too slow. However, if you really want to increase the chances of an unreliable 18x arriving, repeat it a couple of times, with a delay of say 2*T1 before each retransmission. Note that the early media RTP itself is also not guaranteed to arrive, so ensuring that the UAC has received the SDP answer will not ensure that it receives early media. I don't necessarily disagree with your points. I just want to explore whether there is a way of avoiding mandating 100rel. John _______________________________________________ techwg mailing list Send mail to: techwg at sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg From HKaplan at acmepacket.com Wed Oct 1 11:07:45 2008 From: HKaplan at acmepacket.com (Hadriel Kaplan) Date: Wed, 1 Oct 2008 11:07:45 -0400 Subject: [SIPForum-techwg] Reliable provisional responses in SIPconnect1.1 In-Reply-To: <73C8B82BCF7C1A4BA3149FCF6CB6D4FCD4AEC5@300815ANEX3.global.avaya.com> References: <0D5F89FAC29E2C41B98A6A762007F5D0011FF65C@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0011FF85F@GBNTHT12009MSX.gb002.siemens.net> <73C8B82BCF7C1A4BA3149FCF6CB6D4FCD4AEC5@300815ANEX3.global.avaya.com> Message-ID: > -----Original Message----- > From: Johnston, Alan B (Alan) [mailto:abjohnston at avaya.com] > > I agree 100% with John. Making PRACK mandatory just adds complexity to > this specification. And saying that early media does not work without > it is just plain wrong. No one said it doesn't work without it. What I said was it wasn't assured without it. (and yes I know nothing is 100% guaranteed in life) -hadriel From HKaplan at acmepacket.com Wed Oct 1 11:31:50 2008 From: HKaplan at acmepacket.com (Hadriel Kaplan) Date: Wed, 1 Oct 2008 11:31:50 -0400 Subject: [SIPForum-techwg] Reliable provisional responses in SIPconnect 1.1 In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0011FF85F@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0011FF65C@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0011FF85F@GBNTHT12009MSX.gb002.siemens.net> Message-ID: > -----Original Message----- > From: Elwell, John [mailto:john.elwell at siemens.com] > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com] > > > > It's actually for either side really - some Enterprises need > > it too. And for those which send offer-less Invites it's > > even more important. > [JRE] Good point, since with an offer-less INVITE, you can't send SDP > offer in an unreliable response, and waiting for the 200 OK would deny > the possibility of early media. So perhaps an IP-PBX that supports the > sending of offerless INVITEs MUST support 100rel, and a SP that supports > early media in response to offerless INVITEs MUST support 100rel. That brings you right back to having middle-boxes fake it out. Enterprise-A sends offerless Invite, SP routes it to Enterprise-B, Enterprise-B doesn't support 100rel, so SP has to "interwork" it to comply with SIP-Connect? I'd rather we just decide either both MUST Support 100rel, or neither. :) > > BTW, DTLS-SRTP does > > not achieve the same result, fwiw, and even ICE should work > > better with reliable provisional responses. > [JRE] Why would ICE work better - wouldn't the STUN packets typically > get there quicker than PRACK? I guess not if you have to wait for > several candidates to be tried before one gets through, but in the > majority of cases I would have thought it would work better (if better > means faster). I've been told many Enterprises have symmetric Firewalls. If the Enterprise sends an SDP offer, the Service-Provider/far-end-peer can't send it's STUN back through to that SDP-provided candidate until the Enterprise sends one first, which requires getting the peer's SDP. (Even with TURN I believe the Enterprise client would need to know the peer's address to create the TURN permission, but IANAE) -hadriel From john.elwell at siemens.com Thu Oct 2 12:16:29 2008 From: john.elwell at siemens.com (Elwell, John) Date: Thu, 02 Oct 2008 17:16:29 +0100 Subject: [SIPForum-techwg] Next conference call - UA configuration task group Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0012308DC@GBNTHT12009MSX.gb002.siemens.net> Time 2008-10-13, 17.00 British Summer Time (12.00 EDT). Bridge: +44 208 413 5082 Duration: 1 hour Please try to carry out your actions (see draft minutes from 2008-09-29). John From richard at shockey.us Thu Oct 2 12:40:48 2008 From: richard at shockey.us (Richard Shockey) Date: Thu, 2 Oct 2008 12:40:48 -0400 Subject: [SIPForum-techwg] Avaiability for Conference Call on Resolving sticky issues in SIPconnect 1.1 Message-ID: <01af01c924ad$b588bfb0$209a3f10$@us> As I mentioned in my previous note I'm trying to poll for a date where we could complete discussion on some of the more contentious issues we raised in Denver at the face to face. You can mark your availability here and I'll try and pick a reasonable time. http://www.doodle.ch/tnmr5r9mv225drfz Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 From richard at shockey.us Mon Oct 6 12:19:01 2008 From: richard at shockey.us (Richard Shockey) Date: Mon, 6 Oct 2008 12:19:01 -0400 Subject: [SIPForum-techwg] Avaiability for Conference Call on Resolving sticky issues in SIPconnect 1.1 In-Reply-To: <01af01c924ad$b588bfb0$209a3f10$@us> References: <01af01c924ad$b588bfb0$209a3f10$@us> Message-ID: <01ce01c927cf$54491900$fcdb4b00$@us> >From the current poll results this is not the best week for a call. I'm proposing then we do the call on Monday Sept 13 at 10 AM. We'll figure out a bridge shortly. > -----Original Message----- > From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] > On Behalf Of Richard Shockey > Sent: Thursday, October 02, 2008 12:41 PM > To: techwg at sipforum.org > Subject: [SIPForum-techwg] Avaiability for Conference Call on > Resolving sticky issues in SIPconnect 1.1 > > > As I mentioned in my previous note I'm trying to poll for a date where > we > could complete discussion on some of the more contentious issues we > raised > in Denver at the face to face. > > You can mark your availability here and I'll try and pick a reasonable > time. > > > http://www.doodle.ch/tnmr5r9mv225drfz > > Richard Shockey > Director, Member of the Technical Staff > NeuStar > 46000 Center Oak Plaza - Sterling, VA 20166 > PSTN Office +1 571.434.5651 > PSTN Mobile: +1 703.593.2683 > > > > > > > _______________________________________________ > techwg mailing list > Send mail to: techwg at sipforum.org > Unsubscribe or edit options at: > http://sipforum.org/mailman/listinfo/techwg From Adam.Uzelac at globalcrossing.com Mon Oct 6 12:38:15 2008 From: Adam.Uzelac at globalcrossing.com (Uzelac, Adam) Date: Mon, 6 Oct 2008 12:38:15 -0400 Subject: [SIPForum-techwg] Avaiability for Conference Call on Resolving sticky issues in SIPconnect 1.1 In-Reply-To: <01ce01c927cf$54491900$fcdb4b00$@us> References: <01af01c924ad$b588bfb0$209a3f10$@us> <01ce01c927cf$54491900$fcdb4b00$@us> Message-ID: <4DAE5E60BA49D8419D7C8832503F5FFC07733E7E8C@EVS10.ams.gblxint.com> I propose that the call occur on Monday OCTOBER 13th instead. ;) > -----Original Message----- > From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] > On Behalf Of Richard Shockey > Sent: Monday, October 06, 2008 12:19 PM > To: techwg at sipforum.org > Subject: Re: [SIPForum-techwg] Avaiability for Conference Call on > Resolving sticky issues in SIPconnect 1.1 > > >From the current poll results this is not the best week for a call. > > I'm proposing then we do the call on Monday Sept 13 at 10 AM. > > We'll figure out a bridge shortly. > > > -----Original Message----- > > From: techwg-bounces at sipforum.org [mailto:techwg- > bounces at sipforum.org] > > On Behalf Of Richard Shockey > > Sent: Thursday, October 02, 2008 12:41 PM > > To: techwg at sipforum.org > > Subject: [SIPForum-techwg] Avaiability for Conference Call on > > Resolving sticky issues in SIPconnect 1.1 > > > > > > As I mentioned in my previous note I'm trying to poll for a date > where > > we > > could complete discussion on some of the more contentious issues we > > raised > > in Denver at the face to face. > > > > You can mark your availability here and I'll try and pick a > reasonable > > time. > > > > > > http://www.doodle.ch/tnmr5r9mv225drfz > > > > Richard Shockey > > Director, Member of the Technical Staff > > NeuStar > > 46000 Center Oak Plaza - Sterling, VA 20166 > > PSTN Office +1 571.434.5651 > > PSTN Mobile: +1 703.593.2683 > > > > > > > > > > > > > > _______________________________________________ > > techwg mailing list > > Send mail to: techwg at sipforum.org > > Unsubscribe or edit options at: > > http://sipforum.org/mailman/listinfo/techwg > > _______________________________________________ > techwg mailing list > Send mail to: techwg at sipforum.org > Unsubscribe or edit options at: > http://sipforum.org/mailman/listinfo/techwg From richard at shockey.us Mon Oct 6 15:59:04 2008 From: richard at shockey.us (Richard Shockey) Date: Mon, 6 Oct 2008 15:59:04 -0400 Subject: [SIPForum-techwg] Avaiability for Conference Call onResolving sticky issues in SIPconnect 1.1 In-Reply-To: <67048CBE51B1644D89DDD3B7C9F2D19E064E3E15@ecamlmw720.eamcs.ericsson.se> References: <01af01c924ad$b588bfb0$209a3f10$@us> <01ce01c927cf$54491900$fcdb4b00$@us> <67048CBE51B1644D89DDD3B7C9F2D19E064E3E15@ecamlmw720.eamcs.ericsson.se> Message-ID: <02c501c927ee$11db1540$35913fc0$@us> DUH ... yes Oct 13 10 AM > -----Original Message----- > From: Eric Turcotte [mailto:eric.turcotte at ericsson.com] > Sent: Monday, October 06, 2008 12:30 PM > To: Richard Shockey > Subject: RE: [SIPForum-techwg] Avaiability for Conference Call > onResolving sticky issues in SIPconnect 1.1 > > Oct 13 I suppose? > > -----Original Message----- > From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] > On Behalf Of Richard Shockey > Sent: October 6, 2008 12:19 PM > To: techwg at sipforum.org > Subject: Re: [SIPForum-techwg] Avaiability for Conference Call > onResolving sticky issues in SIPconnect 1.1 > > >From the current poll results this is not the best week for a call. > > I'm proposing then we do the call on Monday Sept 13 at 10 AM. > > We'll figure out a bridge shortly. > > > -----Original Message----- > > From: techwg-bounces at sipforum.org > > [mailto:techwg-bounces at sipforum.org] > > On Behalf Of Richard Shockey > > Sent: Thursday, October 02, 2008 12:41 PM > > To: techwg at sipforum.org > > Subject: [SIPForum-techwg] Avaiability for Conference Call on > > Resolving sticky issues in SIPconnect 1.1 > > > > > > As I mentioned in my previous note I'm trying to poll for a date > > where we could complete discussion on some of the more contentious > > issues we raised in Denver at the face to face. > > > > You can mark your availability here and I'll try and pick a > > reasonable time. > > > > > > http://www.doodle.ch/tnmr5r9mv225drfz > > > > Richard Shockey > > Director, Member of the Technical Staff NeuStar 46000 Center Oak > > Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN > Mobile: > > +1 703.593.2683 > > > > > > > > > > > > _______________________________________________ > > techwg mailing list > > Send mail to: techwg at sipforum.org > > Unsubscribe or edit options at: > > http://sipforum.org/mailman/listinfo/techwg > > _______________________________________________ > techwg mailing list > Send mail to: techwg at sipforum.org > Unsubscribe or edit options at: > http://sipforum.org/mailman/listinfo/techwg From richard at shockey.us Mon Oct 6 16:00:28 2008 From: richard at shockey.us (Richard Shockey) Date: Mon, 6 Oct 2008 16:00:28 -0400 Subject: [SIPForum-techwg] Avaiability for Conference Call onResolving sticky issues in SIPconnect 1.1 In-Reply-To: <85F44DA6A27446709DC9FA1BF3192064@china.huawei.com> References: <01af01c924ad$b588bfb0$209a3f10$@us> <01ce01c927cf$54491900$fcdb4b00$@us> <85F44DA6A27446709DC9FA1BF3192064@china.huawei.com> Message-ID: <02c601c927ee$49b9e8b0$dd2dba10$@us> Yes as had in the Poll list. > -----Original Message----- > From: Spencer Dawkins [mailto:spencer at wonderhamster.org] > Sent: Monday, October 06, 2008 1:57 PM > To: Richard Shockey > Subject: Re: [SIPForum-techwg] Avaiability for Conference Call > onResolving sticky issues in SIPconnect 1.1 > > EDT? > > Spencer > > ----- Original Message ----- > From: "Richard Shockey" > To: > Sent: Monday, October 06, 2008 11:19 AM > Subject: Re: [SIPForum-techwg] Avaiability for Conference Call > onResolving > sticky issues in SIPconnect 1.1 > > > > >From the current poll results this is not the best week for a call. > > > > I'm proposing then we do the call on Monday Sept 13 at 10 AM. > > > > We'll figure out a bridge shortly. > > > >> -----Original Message----- > >> From: techwg-bounces at sipforum.org [mailto:techwg- > bounces at sipforum.org] > >> On Behalf Of Richard Shockey > >> Sent: Thursday, October 02, 2008 12:41 PM > >> To: techwg at sipforum.org > >> Subject: [SIPForum-techwg] Avaiability for Conference Call on > >> Resolving sticky issues in SIPconnect 1.1 > >> > >> > >> As I mentioned in my previous note I'm trying to poll for a date > where > >> we > >> could complete discussion on some of the more contentious issues > we > >> raised > >> in Denver at the face to face. > >> > >> You can mark your availability here and I'll try and pick a > reasonable > >> time. > >> > >> > >> http://www.doodle.ch/tnmr5r9mv225drfz > >> > >> Richard Shockey > >> Director, Member of the Technical Staff > >> NeuStar > >> 46000 Center Oak Plaza - Sterling, VA 20166 > >> PSTN Office +1 571.434.5651 > >> PSTN Mobile: +1 703.593.2683 > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> techwg mailing list > >> Send mail to: techwg at sipforum.org > >> Unsubscribe or edit options at: > >> http://sipforum.org/mailman/listinfo/techwg > > > > _______________________________________________ > > techwg mailing list > > Send mail to: techwg at sipforum.org > > Unsubscribe or edit options at: > > http://sipforum.org/mailman/listinfo/techwg > > From eburger at sipforum.org Mon Oct 6 21:04:34 2008 From: eburger at sipforum.org (Eric Burger) Date: Mon, 6 Oct 2008 21:04:34 -0400 Subject: [SIPForum-techwg] [UAS] Fwd: Call for Comments: Principles of Internet Host Configuration References: <20081006101429.DF8E23A689D@core3.amsl.com> Message-ID: Something to think about while we are configuring SIP UA's. Begin forwarded message: > From: IAB Chair > Date: October 6, 2008 6:14:29 AM EDT > To: IETF Announcement list > Cc: iab at iab.org > Subject: Call for Comments: Principles of Internet Host Configuration > > The IAB is ready to ask the RFC-Editor to publish: > > Principles of Internet Host Configuration > draft-iab-ip-config-08.txt > > as an informational RFC. Before doing so the IAB wants to solicit from > the community any last comments on this document. > > Abstract > This document describes principles of Internet host configuration. > It covers issues relating to configuration of Internet layer > parameters, as well as parameters affecting higher layer protocols. > > > Please provide your comments to the IAB by November , 2008. Please > send > comments to the IAB (iab at iab.org), or to ietf at ietf.org. > > The document can be found at: > > http://www.ietf.org/internet-drafts/draft-iab-ip-config-08.txt > or > http://tools.ietf.org/html/draft-iab-ip-config > > > For the IAB, > > -- Olaf Kolkman > _______________________________________________ > IETF-Announce mailing list > IETF-Announce at ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce -------------- next part -------------- An HTML attachment was scrubbed... URL: http://sipforum.org/pipermail/techwg/attachments/20081006/26b2eb7c/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2671 bytes Desc: not available Url : http://sipforum.org/pipermail/techwg/attachments/20081006/26b2eb7c/attachment.bin From richard at shockey.us Wed Oct 8 15:13:16 2008 From: richard at shockey.us (Richard Shockey) Date: Wed, 8 Oct 2008 15:13:16 -0400 Subject: [SIPForum-techwg] Avaiability for Conference Call to resolve 1.1 issues V2 In-Reply-To: <01ce01c927cf$54491900$fcdb4b00$@us> References: <01af01c924ad$b588bfb0$209a3f10$@us> <01ce01c927cf$54491900$fcdb4b00$@us> Message-ID: <02fc01c9297a$00c1a750$0244f5f0$@us> Some people have privately indicated that Monday 10:00 AM EST Oct 13 might be a problem Would Wed 15 work same time EST? Only 11 folks participated in the poll. . > > I'm proposing then we do the call on Monday Sept 13 at 10 AM. > > We'll figure out a bridge shortly. > From sumanth at CableLabs.com Thu Oct 9 15:16:34 2008 From: sumanth at CableLabs.com (Sumanth Channabasappa) Date: Thu, 9 Oct 2008 13:16:34 -0600 Subject: [SIPForum-techwg] Status of the SIP Configuration Framework In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C601482DFE@srvxchg3.cablelabs.com> References: <0D5F89FAC29E2C41B98A6A762007F5D001194872@GBNTHT12009MSX.gb002.siemens.net><9AAEDF491EF7CA48AB587781B8F5D7C601482DEE@srvxchg3.cablelabs.com><18C9693D-6DC0-4BBB-9BAF-CC5E6CF4F482@cs.columbia.edu> <9AAEDF491EF7CA48AB587781B8F5D7C601482DFE@srvxchg3.cablelabs.com> Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C60150B1CA@srvxchg3.cablelabs.com> Folks, On the last call, I was asked to check on the status of the SIP Configuration Framework. I pinged Mary Barnes who informed me that it is still in the AD evaluation phase, and she plans to ping the AD (Jon Peterson) on this. If you are interested in tracking the status of the draft, you can use the following link: https://datatracker.ietf.org/idtracker/draft-ietf-sipping-config-framewo rk/ The latest version can be found at: http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework- 15.txt >From the design team's perspective, we addressed all the comments and suggestions as a result of the WGLC process earlier this year (Jan, Feb), i.e., we don't plan on any changes other than as a result of the AD evaluation (or future) processes. - S From sumanth at cablelabs.com Thu Oct 9 15:35:09 2008 From: sumanth at cablelabs.com (Sumanth Channabasappa) Date: Thu, 9 Oct 2008 13:35:09 -0600 Subject: [SIPForum-techwg] Follow-up: SIP Forum: Use Cases for the SIP configuration framework In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0011FF10D@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0011FF10D@GBNTHT12009MSX.gb002.siemens.net> Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C60150B1D0@srvxchg3.cablelabs.com> --- Action Sumanth: Investigate further explanatory material to accompany SIP config framework for use cases concerned. --- On the last call I took on the action item to look at the config framework and see if we can author additional use cases that can help with the bootstrapping case. (To clarify the plan is not to add use cases to the config framework, but to propose complementary use cases for the current effort.) My proposal would be to author use cases to describe the bootstrapping of: - a software client; - an ATA. This is inline with Henning's findings that we discussed on the last call, i.e., there are two classes of devices and we need to tackle both. The use cases will identify: - the pre-requisites in each case (e.g., obtaining a for a software client); - the procedure to initiate the configuration framework procedures (e.g., obtaining the domain name from the minimal information). This minimal set should give us what we need, i.e., how do we bootstrap a client? The rest is covered by the use case in the config framework. The actual configuration data will be obtained via a separate action item. I would appreciate any thoughts if I am missing something here, i.e., do we need more use cases? Is this proposal too much? (Unfortunately I will not be able to make Monday's call.) - S From sumanth at cablelabs.com Thu Oct 9 16:03:04 2008 From: sumanth at cablelabs.com (Sumanth Channabasappa) Date: Thu, 9 Oct 2008 14:03:04 -0600 Subject: [SIPForum-techwg] Follow-up: configuring basic UI devices In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0011FF10D@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0011FF10D@GBNTHT12009MSX.gb002.siemens.net> Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C60150B1D9@srvxchg3.cablelabs.com> I am reproducing partial notes from the last meeting, and my thoughts follow... ---- 1. Review of action items from Dublin: - Henning Schulzrinne will examine the needs for configuring basic UI devices (username, password, domain). Henning had made some proposals by email (attached), which he summarised. The emphasis was on consumer-style access. One class of user devices with a full UI (e.g., a soft client) would operate in a SKYPE-like manner with an email-style identifier and sign-up via web page - more a UI issue than a specification issue. Concerns are consistent labelling and avoiding exposure of unnecessary information. So action item for SIP Forum would be to write a recommendation of the UI for use in non-expert mode. Discussion: Could try the SIP config framework to start with, but if it fails could try to register as above using just the 3 basic parameters (user name, domain and password). Without being configured with dial plan, still should be able to dial full numbers. May not work in an ideal manner, but should at least get to point of being able to make/receive calls. The second class or user devices were ATAs (audio terminal adaptors), i.e., a basic phone, no display (or very limited display), possible with some interactive audio / touch tone interface. Configuration framework keying off the hardware ID may work. Need to associate an account with a hardware ID, e.g., a number printed on the device that the user keys in via a web page. Just have to type in telephone number and password, but leaves problem of who is the service provider. Proposal to use an ATAD-like IANA registry, and then have some mechanism whereby the ATA can interrogate a server to get mapping from this number to a domain. SIP Forum would probably need to specify this mechanism. Discussion: Sumanth: close to a CableLabs proposal. Henning: Would not work if the registry process is expensive, so hopefully a simple solution based on IANA would be possible. Would Enum be a solution? Henning: Problem that global Enum deployment is not what we had hoped for, and also the privacy aspect is a concern, since it could lead to unsolicited approaches from other service providers to use their services. An alternative might be to key in a customer service number and do Enum look-up, to overcome the privacy problem somehow, but still a concern about the state of deployment of public Enum. Sumanth to post some further thoughts on the mailing list. ---- [S] The last statement is the reason for this email :)! Here are some thoughts: - For the software client, I agree with Henning. If you have a username, password and domain name, you should be set to obtain a configuration. - For ATAs, there are multiple ways to solve the issue. I am enclosing a subset of scenarios that I had explored for CableLabs a while ago (with some modifications for general usage): > Scenario A. The subscriber signs up externally (e.g., web page) and then wants to associate an off-the-shelf generic ATA with the subscribed service. = In this scenario, the web page would provide a 'service provider code' along with a PIN (you will probably be allowed to select your phone number at this stage). The subscriber would then dial the 'service provider code' and 'PIN' into the ATA. This could be via a user interface, or just the dial-pad. (In fancy ATAs you could have a local announcement to request this information.) The ATA then connects to a well-known registry (e.g., IANA, as we discussed) and requests a translation of the service code into a domain name. This results in initial configuration that can also provide the device credentials. The advantage of a 'service provider code' is the concern raised on the last call that { phone number => domain } mapping raises privacy issues. > Scenario B. The subscriber signs up via the ATA. = In this scenario, the ATA connects to 'generic' hosted site. The site provides minimal configuration that connects the ATA to an announcement server. The user connects a phone, goes off-hook, and is connected to the announcement server that can provide a list of options to the user (e.g., based on location, based on price, or by asking the user to type in the first few letters of the service provider s/he wants to connect to.) When the user selects a service provider, the ATA is provided with new configuration that identifies the domain name of the selected service provider, and further prompts allow the user to subscribe and get configured with the service provider. Scenario A is relatively easier to implement (requires a registry), while Scenario B is relatively complex for the 'generic use case' (requires config and announcement servers). - S From hgs at cs.columbia.edu Thu Oct 9 19:52:07 2008 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Thu, 9 Oct 2008 19:52:07 -0400 Subject: [SIPForum-techwg] Follow-up: configuring basic UI devices In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C60150B1D9@srvxchg3.cablelabs.com> References: <0D5F89FAC29E2C41B98A6A762007F5D0011FF10D@GBNTHT12009MSX.gb002.siemens.net> <9AAEDF491EF7CA48AB587781B8F5D7C60150B1D9@srvxchg3.cablelabs.com> Message-ID: <9EA9C117-CEBB-4FD5-99E6-2B34A9F82316@cs.columbia.edu> It's a little hard to follow who said what below, but I agree that scenario B can also work, most likely with a server operated by the hardware (ATA) vendor. The difficulty with that scenario is that every service provider has to contact every hardware vendor and get added to their respective lists. I suspect the ATA vendor will like that option since they can probably extract money from the service provider for the privilege of being listed... The solution I mentioned involves the ITAD numbers that are already registered by IANA. (This is a free registry.) The DNS SRV entry for NNN.itad.arpa would point to the SIP server of the service provider with ITAD registration NNN. This is a relatively short number, likely 4 to 5 digits once everyone registers. Henning On Oct 9, 2008, at 4:03 PM, Sumanth Channabasappa wrote: > I am reproducing partial notes from the last meeting, and my thoughts > follow... > > > . > ---- > > [S] The last statement is the reason for this email :)! Here are some > thoughts: > - For the software client, I agree with Henning. If you have a > username, > password and domain name, you should be set to obtain a configuration. > - For ATAs, there are multiple ways to solve the issue. I am > enclosing a > subset of scenarios that I had explored for CableLabs a while ago > (with > some modifications for general usage): > >> > Scenario A. The subscriber signs up externally (e.g., web page) and > then > wants to associate an off-the-shelf generic ATA with the subscribed > service. > > = In this scenario, the web page would provide a 'service provider > code' > along with a PIN (you will probably be allowed to select your phone > number at this stage). The subscriber would then dial the 'service > provider code' and 'PIN' into the ATA. This could be via a user > interface, or just the dial-pad. (In fancy ATAs you could have a local > announcement to request this information.) The ATA then connects to a > well-known registry (e.g., IANA, as we discussed) and requests a > translation of the service code into a domain name. This results in > initial configuration that can also provide the device credentials. > > The advantage of a 'service provider code' is the concern raised on > the > last call that { phone number => domain } mapping raises privacy > issues. > > >> > Scenario B. The subscriber signs up via the ATA. > > = In this scenario, the ATA connects to 'generic' hosted site. The > site > provides minimal configuration that connects the ATA to an > announcement > server. The user connects a phone, goes off-hook, and is connected to > the announcement server that can provide a list of options to the user > (e.g., based on location, based on price, or by asking the user to > type > in the first few letters of the service provider s/he wants to connect > to.) > > When the user selects a service provider, the ATA is provided with new > configuration that identifies the domain name of the selected service > provider, and further prompts allow the user to subscribe and get > configured with the service provider. > > > Scenario A is relatively easier to implement (requires a registry), > while Scenario B is relatively complex for the 'generic use case' > (requires config and announcement servers). > > > - S > > > _______________________________________________ > techwg mailing list > Send mail to: techwg at sipforum.org > Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg From john.elwell at siemens.com Fri Oct 10 03:17:48 2008 From: john.elwell at siemens.com (Elwell, John) Date: Fri, 10 Oct 2008 08:17:48 +0100 Subject: [SIPForum-techwg] Reminder and agenda: Next conference call - UA configuration task group Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0012A162A@GBNTHT12009MSX.gb002.siemens.net> Time 2008-10-13, 17.00 British Summer Time (12.00 EDT). Bridge: +44 208 413 5082 Duration: 1 hour Please try to carry out your actions - see below. Agenda: 1. Review of actions outstanding from Dublin. - Scott Lawrence will examine the needs for configuring rich UI devices. Fran?ois Audet and John Elwell will assist. - Henning Schulzrinne will engage his students and the open source community to implement the SIP Forum Phone Configuration profile (on hold until something to work on). - Robert Sparks will allocate time at SIPit 23 (probably on Tuesday morning, 14 October 2008) for testing Phone Configuration UA and server implementations - Markus Isom?ki will look to see if there can be a phone implementation prototyped for SIPit. - Eric Burger will shepherd chartering the work with the TWG chairs, Richard Shockey and Scott Hoffpauir. 2. Review of actions from last call: - Henning: Propose text for bootstrapping. - Martin: Propose minimal list of configurable parameters for discussion. - Sumanth: Investigate further explanatory material to accompany SIP config framework for use cases concerned. 3. Discussion of any other input. 4. Next steps. 5. Date of next meeting. John From john.elwell at siemens.com Fri Oct 10 03:30:36 2008 From: john.elwell at siemens.com (Elwell, John) Date: Fri, 10 Oct 2008 08:30:36 +0100 Subject: [SIPForum-techwg] Reminder and updated agenda: Next conference call - UA configuration task group Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0012A162F@GBNTHT12009MSX.gb002.siemens.net> Agenda updated - I missed one of Sumanth's actions. Also thanks, Sumanth, for your input, which we will discuss in your absence. ######################################################### Time 2008-10-13, 17.00 British Summer Time (12.00 EDT). Bridge: +44 208 413 5082 Duration: 1 hour Please try to carry out your actions - see below. Agenda: 1. Review of actions outstanding from Dublin. - Scott Lawrence will examine the needs for configuring rich UI devices. Fran?ois Audet and John Elwell will assist. - Henning Schulzrinne will engage his students and the open source community to implement the SIP Forum Phone Configuration profile (on hold until something to work on). - Robert Sparks will allocate time at SIPit 23 (probably on Tuesday morning, 14 October 2008) for testing Phone Configuration UA and server implementations - Markus Isom?ki will look to see if there can be a phone implementation prototyped for SIPit. - Eric Burger will shepherd chartering the work with the TWG chairs, Richard Shockey and Scott Hoffpauir. 2. Review of actions from last call: - Henning: Propose text for bootstrapping. - Martin: Propose minimal list of configurable parameters for discussion. - Sumanth: Investigate further explanatory material to accompany SIP config framework for use cases concerned. - Sumanth: Post some further thoughts concerning the ATA case on the mailing list. 3. Discussion of any other input. 4. Next steps. 5. Date of next meeting. John From dyork at voxeo.com Fri Oct 10 09:37:43 2008 From: dyork at voxeo.com (Dan York) Date: Fri, 10 Oct 2008 09:37:43 -0400 Subject: [SIPForum-techwg] Avaiability for Conference Call to resolve 1.1 issues V2 In-Reply-To: <02fc01c9297a$00c1a750$0244f5f0$@us> References: <01af01c924ad$b588bfb0$209a3f10$@us> <01ce01c927cf$54491900$fcdb4b00$@us> <02fc01c9297a$00c1a750$0244f5f0$@us> Message-ID: Weds the 15th at 10am EST works fine for me. (Even if it is actually "EDT" ... but why don't we just call it "US Eastern" and forget about the S vs D thing...) Dan On Oct 8, 2008, at 3:13 PM, Richard Shockey wrote: > > Some people have privately indicated that Monday 10:00 AM EST Oct 13 > might > be a problem > > Would Wed 15 work same time EST? > > Only 11 folks participated in the poll. > . >> >> I'm proposing then we do the call on Monday Sept 13 at 10 AM. >> >> We'll figure out a bridge shortly. >> > > _______________________________________________ > techwg mailing list > Send mail to: techwg at sipforum.org > Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork at voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free From richard at shockey.us Fri Oct 10 15:26:45 2008 From: richard at shockey.us (Richard Shockey) Date: Fri, 10 Oct 2008 15:26:45 -0400 Subject: [SIPForum-techwg] resend ... WED message invite. Message-ID: <002501c92b0e$222f1fe0$668d5fa0$@us> Some people have privately indicated that Monday 10:00 AM EST Oct 13 was a problem. Needless to say juggling schedules is a problem as well but lets do Wed OCT 15 10:00 AM US EST. Which I think is +5 BST. A reminder those of you that agreed to rewrite sections of the draft 00 1.1 Spencer would like to have them by Friday if possible. We'd like to have the updated version ready shortly for review. Bridge information below.... +1 571 434 5750 CCode - 5651 No PW necessary. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 From john.elwell at siemens.com Mon Oct 13 02:58:03 2008 From: john.elwell at siemens.com (Elwell, John) Date: Mon, 13 Oct 2008 07:58:03 +0100 Subject: [SIPForum-techwg] Reminder and updated agenda: Next conference call - UA configuration task group Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0012A19B5@GBNTHT12009MSX.gb002.siemens.net> http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&year=2008&hour=17&min=0&sec=0&p1=136 Bridge: +44 208 413 5082 Duration: 1 hour Please try to carry out your actions - see below. Agenda: 1. Review of actions outstanding from Dublin. - Scott Lawrence will examine the needs for configuring rich UI devices. Fran?ois Audet and John Elwell will assist. - Henning Schulzrinne will engage his students and the open source community to implement the SIP Forum Phone Configuration profile (on hold until something to work on). - Robert Sparks will allocate time at SIPit 23 (probably on Tuesday morning, 14 October 2008) for testing Phone Configuration UA and server implementations - Markus Isom?ki will look to see if there can be a phone implementation prototyped for SIPit. - Eric Burger will shepherd chartering the work with the TWG chairs, Richard Shockey and Scott Hoffpauir. 2. Review of actions from last call: - Henning: Propose text for bootstrapping. - Martin: Propose minimal list of configurable parameters for discussion. - Sumanth: Investigate further explanatory material to accompany SIP config framework for use cases concerned. - Sumanth: Post some further thoughts concerning the ATA case on the mailing list. 3. Discussion of any other input. 4. Next steps. 5. Date of next meeting. John From john.elwell at siemens.com Mon Oct 13 05:28:22 2008 From: john.elwell at siemens.com (Elwell, John) Date: Mon, 13 Oct 2008 10:28:22 +0100 Subject: [SIPForum-techwg] [UAS] Fwd: Call for Comments: Principles of Internet Host Configuration In-Reply-To: References: <20081006101429.DF8E23A689D@core3.amsl.com> Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0012A1AEB@GBNTHT12009MSX.gb002.siemens.net> Yes, we should evaluate our solutions against this. John ________________________________ From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Eric Burger Sent: 07 October 2008 02:05 To: techwg at sipforum.org Subject: [SIPForum-techwg] [UAS] Fwd: Call for Comments: Principles of Internet Host Configuration Something to think about while we are configuring SIP UA's. Begin forwarded message: From: IAB Chair Date: October 6, 2008 6:14:29 AM EDT To: IETF Announcement list Cc: iab at iab.org Subject: Call for Comments: Principles of Internet Host Configuration The IAB is ready to ask the RFC-Editor to publish: Principles of Internet Host Configuration draft-iab-ip-config-08.txt as an informational RFC. Before doing so the IAB wants to solicit from the community any last comments on this document. Abstract This document describes principles of Internet host configuration. It covers issues relating to configuration of Internet layer parameters, as well as parameters affecting higher layer protocols. Please provide your comments to the IAB by November , 2008. Please send comments to the IAB (iab at iab.org), or to ietf at ietf.org. The document can be found at: http://www.ietf.org/internet-drafts/draft-iab-ip-config-08.txt or http://tools.ietf.org/html/draft-iab-ip-config For the IAB, -- Olaf Kolkman _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -------------- next part -------------- An HTML attachment was scrubbed... URL: http://sipforum.org/pipermail/techwg/attachments/20081013/a3fb3696/attachment.html From john.elwell at siemens.com Mon Oct 13 12:15:05 2008 From: john.elwell at siemens.com (Elwell, John) Date: Mon, 13 Oct 2008 17:15:05 +0100 Subject: [SIPForum-techwg] Reminder and updated agenda: Next conference call - UA configuration task group Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0012A1EC9@GBNTHT12009MSX.gb002.siemens.net> Well, we didn't get enough people calling in (just Andy Hutton, Marek Dutkiewicz and myself, with apologies from Martin and Sumanth). So I will reschedule the meeting for Monday 20th, same time. In the meantime, please try to continue discussions be email, in particular in response to Sumanth's postings on 9th. John _____________________________________________ From: Elwell, John Sent: 13 October 2008 07:58 To: 'techwg at sipforum.org' Subject: Reminder and updated agenda: Next conference call - UA configuration task group http://www.timeanddate.com/worldclock/fixedtime.html?day=13&month=10&year=2008&hour=17&min=0&sec=0&p1=136 Bridge: +44 208 413 5082 Duration: 1 hour Please try to carry out your actions - see below. Agenda: 1. Review of actions outstanding from Dublin. - Scott Lawrence will examine the needs for configuring rich UI devices. Fran?ois Audet and John Elwell will assist. - Henning Schulzrinne will engage his students and the open source community to implement the SIP Forum Phone Configuration profile (on hold until something to work on). - Robert Sparks will allocate time at SIPit 23 (probably on Tuesday morning, 14 October 2008) for testing Phone Configuration UA and server implementations - Markus Isom?ki will look to see if there can be a phone implementation prototyped for SIPit. - Eric Burger will shepherd chartering the work with the TWG chairs, Richard Shockey and Scott Hoffpauir. 2. Review of actions from last call: - Henning: Propose text for bootstrapping. - Martin: Propose minimal list of configurable parameters for discussion. - Sumanth: Investigate further explanatory material to accompany SIP config framework for use cases concerned. - Sumanth: Post some further thoughts concerning the ATA case on the mailing list. 3. Discussion of any other input. 4. Next steps. 5. Date of next meeting. John From john.elwell at siemens.com Mon Oct 13 12:21:23 2008 From: john.elwell at siemens.com (Elwell, John) Date: Mon, 13 Oct 2008 17:21:23 +0100 Subject: [SIPForum-techwg] Reminder and updated agenda: Next conference call - UA configuration task group Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0012A1ED0@GBNTHT12009MSX.gb002.siemens.net> I hereby reschedule the meeting for 20th October, same time: http://www.timeanddate.com/worldclock/fixedtime.html?day=20&month=10&year=2008&hour=17&min=0&sec=0&p1=136 Bridge: +44 208 413 5082 Duration: 1 hour Please try to carry out your actions - see below - and continue discussions by email. Agenda: 1. Review of actions outstanding from Dublin. - Scott Lawrence will examine the needs for configuring rich UI devices. Fran?ois Audet and John Elwell will assist. - Henning Schulzrinne will engage his students and the open source community to implement the SIP Forum Phone Configuration profile (on hold until something to work on). - Robert Sparks will allocate time at SIPit 23 (probably on Tuesday morning, 14 October 2008) for testing Phone Configuration UA and server implementations - Markus Isom?ki will look to see if there can be a phone implementation prototyped for SIPit. - Eric Burger will shepherd chartering the work with the TWG chairs, Richard Shockey and Scott Hoffpauir. 2. Review of actions from last call: - Henning: Propose text for bootstrapping. - Martin: Propose minimal list of configurable parameters for discussion. - Sumanth: Investigate further explanatory material to accompany SIP config framework for use cases concerned. - Sumanth: Post some further thoughts concerning the ATA case on the mailing list. 3. Discussion of any other input. 4. Next steps. 5. Date of next meeting. John From marek.dutkiewicz at polycom.com Mon Oct 13 12:26:31 2008 From: marek.dutkiewicz at polycom.com (Dutkiewicz, Marek) Date: Mon, 13 Oct 2008 09:26:31 -0700 Subject: [SIPForum-techwg] Follow-up: SIP Forum: Use Cases for the SIPconfiguration framework In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C60150B1D0@srvxchg3.cablelabs.com> References: <0D5F89FAC29E2C41B98A6A762007F5D0011FF10D@GBNTHT12009MSX.gb002.siemens.net> <9AAEDF491EF7CA48AB587781B8F5D7C60150B1D0@srvxchg3.cablelabs.com> Message-ID: <4280DB4085C0FC4BAA41AB503C1024D004DB42C7@vanmail01.vancouver.polycom.com> I would recommend we add a third device category - a VoIP phone. These devices typically have a display that can be used to interact with the device installer, but have limited capabilities for entering data (typically only a standard 12-digit phone key-pad). The methods developed for the ATA device would work for VoIP phones as well, however it is feasible to enter a URL from the phone key-pad. Regards Marek -----Original Message----- From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Sumanth Channabasappa Sent: Thursday, October 09, 2008 12:35 PM To: techwg at sipforum.org Subject: [SIPForum-techwg] Follow-up: SIP Forum: Use Cases for the SIPconfiguration framework --- Action Sumanth: Investigate further explanatory material to accompany SIP config framework for use cases concerned. --- On the last call I took on the action item to look at the config framework and see if we can author additional use cases that can help with the bootstrapping case. (To clarify the plan is not to add use cases to the config framework, but to propose complementary use cases for the current effort.) My proposal would be to author use cases to describe the bootstrapping of: - a software client; - an ATA. This is inline with Henning's findings that we discussed on the last call, i.e., there are two classes of devices and we need to tackle both. The use cases will identify: - the pre-requisites in each case (e.g., obtaining a for a software client); - the procedure to initiate the configuration framework procedures (e.g., obtaining the domain name from the minimal information). This minimal set should give us what we need, i.e., how do we bootstrap a client? The rest is covered by the use case in the config framework. The actual configuration data will be obtained via a separate action item. I would appreciate any thoughts if I am missing something here, i.e., do we need more use cases? Is this proposal too much? (Unfortunately I will not be able to make Monday's call.) - S _______________________________________________ techwg mailing list Send mail to: techwg at sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg From marek.dutkiewicz at polycom.com Mon Oct 13 12:32:01 2008 From: marek.dutkiewicz at polycom.com (Dutkiewicz, Marek) Date: Mon, 13 Oct 2008 09:32:01 -0700 Subject: [SIPForum-techwg] Feedback on bootstrapping In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C601482DEE@srvxchg3.cablelabs.com> References: <0D5F89FAC29E2C41B98A6A762007F5D001194872@GBNTHT12009MSX.gb002.siemens.net> <9AAEDF491EF7CA48AB587781B8F5D7C601482DEE@srvxchg3.cablelabs.com> Message-ID: <4280DB4085C0FC4BAA41AB503C1024D004DB42C8@vanmail01.vancouver.polycom.com> DHCP is a very useful method to deliver the 'bootstrap server' address to VoIP devices. However as pointed out below the customer does not always have the ability to control the content of options (such as 66 or 160) for delivering the bootstrap server address. In cases where setting it is not possible for a phone installer to deliver the bootstrap server address in the DHCP option from the primary DHCP server, a secondary DHCP server can be used to respond to a DHCP INFORM request from the VoIP device. This 'secondary server' could be resident on a PC used by the installer or placed onto a machine within the customer network DHCP domain. In many cases this method could be easier to implement than creating methods to enter the bootstrap server address from the UI of the phone (e.g. if it is an ATA). Regards Marek -----Original Message----- From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Sumanth Channabasappa Sent: Friday, September 26, 2008 4:18 PM To: techwg at sipforum.org Subject: [SIPForum-techwg] Feedback on bootstrapping Folks, Martin and I discussed the action item regarding the support for bootstrapping within the SIP configuration framework (http://tools.ietf.org/html/draft-ietf-sipping-config-framework-15). Based on previous discussions, the understanding is that bootstrapping involves two aspects: A. How does the client figure out where it needs to go for initial configuration? B. How is it provided with identities and credentials for initial authentication and authorization, if required? The SIP configuration framework currently includes text to address the above, but stops short of mandating or recommending specific solutions. Section 5.3.1 of the document provides various ways in which a client can be bootstrapped with identities and credentials: pre-configuration, out-of-band, end-user-interface as well as using the framework. Within each of these options it provides some guidance, e.g., one can use X.509 certificates for identifying the client requesting initial configuration (without pre-configuration when a PKI is used) or an end-user can provide the necessary information. These methods can be used for both A and B, above. Additionally, it also provides sample scenarios on a per-profile basis. For example, the local-network profile in Section 5.1.4.1 allows for the device to obtain a domain name via DHCP. This can be helpful in the case of enterprise clients where the DHCP server can be influenced by the service provider. Once this is obtained, the resulting configuration can provide all the other details. Martin and I agree that given the scope of the SIP configuration framework, this is sufficient guidance. Implementations are going to use one or more of the proposed methods, and the framework will support it. We validated this by discussing a few planned deployments (that we are aware of) and the framework meets the needs of the scenarios we came up with. --- In addition to what Martin and I discussed, this group can potentially take the guidelines within the framework and create a subset of procedures for reasons such as interoperability. This would be independent of the action item we took. We can discuss both the summary, and other related work on Monday. Thanks! - S _______________________________________________ techwg mailing list Send mail to: techwg at sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg From john.elwell at siemens.com Tue Oct 14 12:00:27 2008 From: john.elwell at siemens.com (Elwell, John) Date: Tue, 14 Oct 2008 17:00:27 +0100 Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> I have had some off-line discussions with some IETF experts, and I have detected some concern about the direction that SIPconnect is heading with its use of registration. There was already concern during the Denver meeting about the complexities of the registration-based approach. I could try to summarise the registration-based approach as follows: With registration, a PBX to registers a default AoR such as: sip:+123456000 at enterprise.com;user=phone and as a result can receive all inbound requests to that enterprise. In principle, this should mean all requests targeted at sip:*@enterprise.com, e.g.: sip:alice at enterprise.com sip:12345 at enterprise.com sip:+123456789 at enterprise.com;user=phone should be delivered to the PBX. In these cases, the domain part is enterprise.com, so the SP shouldn't look at the user part. However, in practice, the SP is also going to receive requests targeted at, for example: tel:+123456789 sip:+123456789 at serviceprovider.net;user=phone In these cases, the E.164 number is "assigned" to enterprise.com, the SP needs to recognise this and forward the request to the PBX, but with, enterprise.com in the domain part (otherwise the PBX will reject the request, or try to forward it back to the SP). So it would end up being forwarded as: sip:+123456789 at enterprise.com;user=phone The fact that the PBX has registered really makes no difference to the SP's decision to forward a request to the PBX: - whether or not the PBX has registered, requests targeted at *@enterprise.com need to be delivered to the PBX; - whether or not the PBX has registered, requests targeted at an E.164 number assigned to the PBX need to be retargeted to a SIP URI with enterprise.com in the domain part, and then delivered to the PBX as above. The only difference that registration makes is that it provides a "flow" over which requests can be delivered (rather than using RFC 3263 to determine where to route to) and that "flow" is kept alive. It seems that a similar result could be obtained by using connection re-use and some sort of keep-alive (e.g., SIP OPTIONS). For example, the PBX could establish a connection to the SP using OPTIONS and keep it alive using OPTIONS, and the SP could re-use this connection for inbound requests to the PBX. This would avoid the use of REGISTER, and would be closer to SIPconnect 1.0 (where the PBX was not required to register). By doing something like this, we could converge on a single mode of operation and keep the basic implementation requirements to a minimum. If something along these lines does not satisfy requirements, let's get the requirements on the table so that we can see which items in the SIP tool kit would do the job. John From steve.carr at nsn.com Tue Oct 14 14:22:39 2008 From: steve.carr at nsn.com (Carr, Steve (NSN - US/Boca Raton)) Date: Tue, 14 Oct 2008 13:22:39 -0500 Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> Message-ID: <173AF02905E8F14C9CC1D4F2B003DD110133507C@USCHEXC006.nsn-intra.net> We have a Service Provider customer (Cable MSO) who wants to use SIPConnect to connect very small enterprises (eg retail stores) over his existing access network. The service provider supplies the IP-PBX devices. He does not want to provide any additional infrastructure to manage IP addresses and hostnames, beyond what he already does for consumer services. That means the IP_PBX has to be assigned IP addresses by DHCP and does not get a domain name. Therefore, it has to be able to register. I think SIPConnect should cover this use case. Steve -----Original Message----- From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of ext Elwell, John Sent: Tuesday, October 14, 2008 12:00 PM To: techwg at sipforum.org Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect I have had some off-line discussions with some IETF experts, and I have detected some concern about the direction that SIPconnect is heading with its use of registration. There was already concern during the Denver meeting about the complexities of the registration-based approach. I could try to summarise the registration-based approach as follows: With registration, a PBX to registers a default AoR such as: sip:+123456000 at enterprise.com;user=phone and as a result can receive all inbound requests to that enterprise. In principle, this should mean all requests targeted at sip:*@enterprise.com, e.g.: sip:alice at enterprise.com sip:12345 at enterprise.com sip:+123456789 at enterprise.com;user=phone should be delivered to the PBX. In these cases, the domain part is enterprise.com, so the SP shouldn't look at the user part. However, in practice, the SP is also going to receive requests targeted at, for example: tel:+123456789 sip:+123456789 at serviceprovider.net;user=phone In these cases, the E.164 number is "assigned" to enterprise.com, the SP needs to recognise this and forward the request to the PBX, but with, enterprise.com in the domain part (otherwise the PBX will reject the request, or try to forward it back to the SP). So it would end up being forwarded as: sip:+123456789 at enterprise.com;user=phone The fact that the PBX has registered really makes no difference to the SP's decision to forward a request to the PBX: - whether or not the PBX has registered, requests targeted at *@enterprise.com need to be delivered to the PBX; - whether or not the PBX has registered, requests targeted at an E.164 number assigned to the PBX need to be retargeted to a SIP URI with enterprise.com in the domain part, and then delivered to the PBX as above. The only difference that registration makes is that it provides a "flow" over which requests can be delivered (rather than using RFC 3263 to determine where to route to) and that "flow" is kept alive. It seems that a similar result could be obtained by using connection re-use and some sort of keep-alive (e.g., SIP OPTIONS). For example, the PBX could establish a connection to the SP using OPTIONS and keep it alive using OPTIONS, and the SP could re-use this connection for inbound requests to the PBX. This would avoid the use of REGISTER, and would be closer to SIPconnect 1.0 (where the PBX was not required to register). By doing something like this, we could converge on a single mode of operation and keep the basic implementation requirements to a minimum. If something along these lines does not satisfy requirements, let's get the requirements on the table so that we can see which items in the SIP tool kit would do the job. John _______________________________________________ techwg mailing list Send mail to: techwg at sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg From vrastogi at avaya.com Wed Oct 15 01:30:45 2008 From: vrastogi at avaya.com (Rastogi, Vipul (Vipul)) Date: Wed, 15 Oct 2008 13:30:45 +0800 Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> Message-ID: <093D2B5834E6DC44BE3154B96726A4E5B75CA7@301081ANEX2.global.avaya.com> When PBX Registers with SP with option 2, SP thinks whole PBX as a single UA (just like any other endpoint). I am not sure if it is proper to say SP thinks PBX as proxy (and hence doing DNS etc). It is fare assumption that there are multiple such PBX in single enterprise working with single of multiple SP. In that case sip:*@enterprise.com might not work. Vipul Rastogi -----Original Message----- From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Elwell, John Sent: Tuesday, October 14, 2008 9:30 PM To: techwg at sipforum.org Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect I have had some off-line discussions with some IETF experts, and I have detected some concern about the direction that SIPconnect is heading with its use of registration. There was already concern during the Denver meeting about the complexities of the registration-based approach. I could try to summarise the registration-based approach as follows: With registration, a PBX to registers a default AoR such as: sip:+123456000 at enterprise.com;user=phone and as a result can receive all inbound requests to that enterprise. In principle, this should mean all requests targeted at sip:*@enterprise.com, e.g.: sip:alice at enterprise.com sip:12345 at enterprise.com sip:+123456789 at enterprise.com;user=phone should be delivered to the PBX. In these cases, the domain part is enterprise.com, so the SP shouldn't look at the user part. However, in practice, the SP is also going to receive requests targeted at, for example: tel:+123456789 sip:+123456789 at serviceprovider.net;user=phone In these cases, the E.164 number is "assigned" to enterprise.com, the SP needs to recognise this and forward the request to the PBX, but with, enterprise.com in the domain part (otherwise the PBX will reject the request, or try to forward it back to the SP). So it would end up being forwarded as: sip:+123456789 at enterprise.com;user=phone The fact that the PBX has registered really makes no difference to the SP's decision to forward a request to the PBX: - whether or not the PBX has registered, requests targeted at *@enterprise.com need to be delivered to the PBX; - whether or not the PBX has registered, requests targeted at an E.164 number assigned to the PBX need to be retargeted to a SIP URI with enterprise.com in the domain part, and then delivered to the PBX as above. The only difference that registration makes is that it provides a "flow" over which requests can be delivered (rather than using RFC 3263 to determine where to route to) and that "flow" is kept alive. It seems that a similar result could be obtained by using connection re-use and some sort of keep-alive (e.g., SIP OPTIONS). For example, the PBX could establish a connection to the SP using OPTIONS and keep it alive using OPTIONS, and the SP could re-use this connection for inbound requests to the PBX. This would avoid the use of REGISTER, and would be closer to SIPconnect 1.0 (where the PBX was not required to register). By doing something like this, we could converge on a single mode of operation and keep the basic implementation requirements to a minimum. If something along these lines does not satisfy requirements, let's get the requirements on the table so that we can see which items in the SIP tool kit would do the job. John _______________________________________________ techwg mailing list Send mail to: techwg at sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg From dyork at voxeo.com Wed Oct 15 08:36:06 2008 From: dyork at voxeo.com (Dan York) Date: Wed, 15 Oct 2008 08:36:06 -0400 Subject: [SIPForum-techwg] resend ... WED message invite. In-Reply-To: <002501c92b0e$222f1fe0$668d5fa0$@us> References: <002501c92b0e$222f1fe0$668d5fa0$@us> Message-ID: Richard, Just to confirm, are we on for this call today at 10:00am US Eastern time? (about 1.5 hours from now?) Do we have a defined agenda? Or is it just "resolve contentious issues"? Dan On Oct 10, 2008, at 3:26 PM, Richard Shockey wrote: > > Some people have privately indicated that Monday 10:00 AM EST Oct 13 > was a > problem. > > Needless to say juggling schedules is a problem as well but lets do > Wed OCT > 15 10:00 AM US EST. Which I think is +5 BST. > > A reminder those of you that agreed to rewrite sections of the draft > 00 1.1 > Spencer would like to have them by Friday if possible. We'd like to > have the > updated version ready shortly for review. > > > Bridge information below.... > > +1 571 434 5750 > > CCode - 5651 > > No PW necessary. > > > Richard Shockey > Director, Member of the Technical Staff > NeuStar > 46000 Center Oak Plaza - Sterling, VA 20166 > PSTN Office +1 571.434.5651 > PSTN Mobile: +1 703.593.2683 > > > > > > > _______________________________________________ > techwg mailing list > Send mail to: techwg at sipforum.org > Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTO Voxeo Corporation dyork at voxeo.com Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Build voice applications based on open standards. Find out how at http://www.voxeo.com/free From richard at shockey.us Wed Oct 15 10:04:34 2008 From: richard at shockey.us (Richard Shockey) Date: Wed, 15 Oct 2008 10:04:34 -0400 Subject: [SIPForum-techwg] the call is on BTW Message-ID: <002401c92ecf$0a1954b0$1e4bfe10$@us> Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 From HKaplan at acmepacket.com Wed Oct 15 10:22:11 2008 From: HKaplan at acmepacket.com (Hadriel Kaplan) Date: Wed, 15 Oct 2008 10:22:11 -0400 Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> Message-ID: I think we agreed in Denver that registering an Enterprise's domain into an SP would be a valid use-case, but the more rare case. Just to make sure we're on the same page, the more common case was the Enterprise would register an AoR in the SP's domain, such as: sip:+123456000 at serviceprovider.net;user=phone And I think we agreed in that case that if a call came to the SP destined to the Enterprise, such as: sip:+1234561234 at serviceprovider.net That the Service Provider would not change the req-uri to the registered AoR's Contact-uri, but rather just insert a Route header to the registered contact. Right? (or am I forgetting what we agreed to?) That's still consistent, BTW. In this case no retargeting is occurring, because the target is within the same domain context. In the Enterprise.com registered case, it is a retarget because it's changing the domain context. -hadriel > -----Original Message----- > From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On > Behalf Of Elwell, John > Sent: Tuesday, October 14, 2008 12:00 PM > To: techwg at sipforum.org > Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect > > I have had some off-line discussions with some IETF experts, and I have > detected some concern about the direction that SIPconnect is heading > with its use of registration. There was already concern during the > Denver meeting about the complexities of the registration-based > approach. > > I could try to summarise the registration-based approach as follows: > > With registration, a PBX to registers a default AoR such as: > sip:+123456000 at enterprise.com;user=phone > and as a result can receive all inbound requests to that enterprise. > > In principle, this should mean all requests targeted at > sip:*@enterprise.com, e.g.: > sip:alice at enterprise.com > sip:12345 at enterprise.com > sip:+123456789 at enterprise.com;user=phone > should be delivered to the PBX. > > In these cases, the domain part is enterprise.com, so the SP shouldn't > look at the user part. > > However, in practice, the SP is also going to receive requests targeted > at, for example: > tel:+123456789 > sip:+123456789 at serviceprovider.net;user=phone > > In these cases, the E.164 number is "assigned" to enterprise.com, the SP > needs to recognise this and forward the request to the PBX, but with, > enterprise.com in the domain part (otherwise the PBX will reject the > request, or try to forward it back to the SP). So it would end up being > forwarded as: > sip:+123456789 at enterprise.com;user=phone > > The fact that the PBX has registered really makes no difference to the > SP's decision to forward a request to the PBX: > - whether or not the PBX has registered, requests targeted at > *@enterprise.com need to be delivered to the PBX; > - whether or not the PBX has registered, requests targeted at an E.164 > number assigned to the PBX need to be retargeted to a SIP URI with > enterprise.com in the domain part, and then delivered to the PBX as > above. > > The only difference that registration makes is that it provides a "flow" > over which requests can be delivered (rather than using RFC 3263 to > determine where to route to) and that "flow" is kept alive. > > It seems that a similar result could be obtained by using connection > re-use and some sort of keep-alive (e.g., SIP OPTIONS). For example, the > PBX could establish a connection to the SP using OPTIONS and keep it > alive using OPTIONS, and the SP could re-use this connection for inbound > requests to the PBX. This would avoid the use of REGISTER, and would be > closer to SIPconnect 1.0 (where the PBX was not required to register). > > By doing something like this, we could converge on a single mode of > operation and keep the basic implementation requirements to a minimum. > > If something along these lines does not satisfy requirements, let's get > the requirements on the table so that we can see which items in the SIP > tool kit would do the job. > > John > > _______________________________________________ > techwg mailing list > Send mail to: techwg at sipforum.org > Unsubscribe or edit options at: > http://sipforum.org/mailman/listinfo/techwg From john.elwell at siemens.com Wed Oct 15 12:57:10 2008 From: john.elwell at siemens.com (Elwell, John) Date: Wed, 15 Oct 2008 17:57:10 +0100 Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0012DB549@GBNTHT12009MSX.gb002.siemens.net> > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com] > Sent: 15 October 2008 15:22 > To: Elwell, John; techwg at sipforum.org > Subject: RE: Thoughts on registration in SIPconnect > > > I think we agreed in Denver that registering an Enterprise's > domain into an SP would be a valid use-case, but the more rare case. > > Just to make sure we're on the same page, the more common > case was the Enterprise would register an AoR in the SP's > domain, such as: > sip:+123456000 at serviceprovider.net;user=phone [JRE] In fact, I had neglected to cover the case where the enterprise does not have its own domain name or a permanent IP address. However, I had in mind section 11.4 of the spec, which currently mandates use of the enterprise domain name. I don't recall reviewing that section. > > And I think we agreed in that case that if a call came to the > SP destined to the Enterprise, such as: > sip:+1234561234 at serviceprovider.net > That the Service Provider would not change the req-uri to the > registered AoR's Contact-uri, but rather just insert a Route > header to the registered contact. Right? (or am I forgetting > what we agreed to?) [JRE] Yes, I think we agreed on this loose routing concept, in which the AoR of the target (as opposed to the registered contact URI) is in the Request URI when delivered to the enterprise. But I had assumed this would have the enterprise domain in the domain part - otherwise, if the enterprise receives the SP's domain, it is likely either to reject the request (404) or route it back to the SP, since the enterprise is not responsible for the SP's domain. > > That's still consistent, BTW. In this case no retargeting is > occurring, because the target is within the same domain > context. In the Enterprise.com registered case, it is a > retarget because it's changing the domain context. [JRE] Yes. John > > -hadriel > > > > -----Original Message----- > > From: techwg-bounces at sipforum.org > [mailto:techwg-bounces at sipforum.org] On > > Behalf Of Elwell, John > > Sent: Tuesday, October 14, 2008 12:00 PM > > To: techwg at sipforum.org > > Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect > > > > I have had some off-line discussions with some IETF > experts, and I have > > detected some concern about the direction that SIPconnect is heading > > with its use of registration. There was already concern during the > > Denver meeting about the complexities of the registration-based > > approach. > > > > I could try to summarise the registration-based approach as follows: > > > > With registration, a PBX to registers a default AoR such as: > > sip:+123456000 at enterprise.com;user=phone > > and as a result can receive all inbound requests to that enterprise. > > > > In principle, this should mean all requests targeted at > > sip:*@enterprise.com, e.g.: > > sip:alice at enterprise.com > > sip:12345 at enterprise.com > > sip:+123456789 at enterprise.com;user=phone > > should be delivered to the PBX. > > > > In these cases, the domain part is enterprise.com, so the > SP shouldn't > > look at the user part. > > > > However, in practice, the SP is also going to receive > requests targeted > > at, for example: > > tel:+123456789 > > sip:+123456789 at serviceprovider.net;user=phone > > > > In these cases, the E.164 number is "assigned" to > enterprise.com, the SP > > needs to recognise this and forward the request to the PBX, > but with, > > enterprise.com in the domain part (otherwise the PBX will reject the > > request, or try to forward it back to the SP). So it would > end up being > > forwarded as: > > sip:+123456789 at enterprise.com;user=phone > > > > The fact that the PBX has registered really makes no > difference to the > > SP's decision to forward a request to the PBX: > > - whether or not the PBX has registered, requests targeted at > > *@enterprise.com need to be delivered to the PBX; > > - whether or not the PBX has registered, requests targeted > at an E.164 > > number assigned to the PBX need to be retargeted to a SIP URI with > > enterprise.com in the domain part, and then delivered to the PBX as > > above. > > > > The only difference that registration makes is that it > provides a "flow" > > over which requests can be delivered (rather than using RFC 3263 to > > determine where to route to) and that "flow" is kept alive. > > > > It seems that a similar result could be obtained by using connection > > re-use and some sort of keep-alive (e.g., SIP OPTIONS). For > example, the > > PBX could establish a connection to the SP using OPTIONS and keep it > > alive using OPTIONS, and the SP could re-use this > connection for inbound > > requests to the PBX. This would avoid the use of REGISTER, > and would be > > closer to SIPconnect 1.0 (where the PBX was not required to > register). > > > > By doing something like this, we could converge on a single mode of > > operation and keep the basic implementation requirements to > a minimum. > > > > If something along these lines does not satisfy > requirements, let's get > > the requirements on the table so that we can see which > items in the SIP > > tool kit would do the job. > > > > John > > > > _______________________________________________ > > techwg mailing list > > Send mail to: techwg at sipforum.org > > Unsubscribe or edit options at: > > http://sipforum.org/mailman/listinfo/techwg > From Chris.Gatch at cbeyond.net Wed Oct 15 13:21:19 2008 From: Chris.Gatch at cbeyond.net (Chris Gatch) Date: Wed, 15 Oct 2008 13:21:19 -0400 Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> Message-ID: <67343F3352A8754E810F595B99255BDC0151ECC0@EXMBX00.corp.cbeyond.net> In practice, registration by the PBX of a single AOR that is associated by the service provider with other AORs of the same enterprise is broadly implemented under SIPconnect 1.0. The primary use of this registration is providing the IP address of the system registering and creating an initial outbound session through firewalls and ALGs for purposes of providing SIP-friendly address translation. The idea below of a wildcard as outlined below doesn't apply b/c the association is made only by the service provider, and all addresses within a domain are not assumed to be associated to a single SIP Trunk. In fact, customers with a single domain may have many SIP Trunks with a subject of their numbers routing to that trunk. A dynamic method of the PBX making itself known to the SIP is essential to a successful specification. Registration is broadly implemented and seems to currently service this purpose very well. Chris -----Original Message----- From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Elwell, John Sent: Tuesday, October 14, 2008 12:00 PM To: techwg at sipforum.org Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect I have had some off-line discussions with some IETF experts, and I have detected some concern about the direction that SIPconnect is heading with its use of registration. There was already concern during the Denver meeting about the complexities of the registration-based approach. I could try to summarise the registration-based approach as follows: With registration, a PBX to registers a default AoR such as: sip:+123456000 at enterprise.com;user=phone and as a result can receive all inbound requests to that enterprise. In principle, this should mean all requests targeted at sip:*@enterprise.com, e.g.: sip:alice at enterprise.com sip:12345 at enterprise.com sip:+123456789 at enterprise.com;user=phone should be delivered to the PBX. In these cases, the domain part is enterprise.com, so the SP shouldn't look at the user part. However, in practice, the SP is also going to receive requests targeted at, for example: tel:+123456789 sip:+123456789 at serviceprovider.net;user=phone In these cases, the E.164 number is "assigned" to enterprise.com, the SP needs to recognise this and forward the request to the PBX, but with, enterprise.com in the domain part (otherwise the PBX will reject the request, or try to forward it back to the SP). So it would end up being forwarded as: sip:+123456789 at enterprise.com;user=phone The fact that the PBX has registered really makes no difference to the SP's decision to forward a request to the PBX: - whether or not the PBX has registered, requests targeted at *@enterprise.com need to be delivered to the PBX; - whether or not the PBX has registered, requests targeted at an E.164 number assigned to the PBX need to be retargeted to a SIP URI with enterprise.com in the domain part, and then delivered to the PBX as above. The only difference that registration makes is that it provides a "flow" over which requests can be delivered (rather than using RFC 3263 to determine where to route to) and that "flow" is kept alive. It seems that a similar result could be obtained by using connection re-use and some sort of keep-alive (e.g., SIP OPTIONS). For example, the PBX could establish a connection to the SP using OPTIONS and keep it alive using OPTIONS, and the SP could re-use this connection for inbound requests to the PBX. This would avoid the use of REGISTER, and would be closer to SIPconnect 1.0 (where the PBX was not required to register). By doing something like this, we could converge on a single mode of operation and keep the basic implementation requirements to a minimum. If something along these lines does not satisfy requirements, let's get the requirements on the table so that we can see which items in the SIP tool kit would do the job. John _______________________________________________ techwg mailing list Send mail to: techwg at sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg From Chris.Gatch at cbeyond.net Wed Oct 15 13:29:13 2008 From: Chris.Gatch at cbeyond.net (Chris Gatch) Date: Wed, 15 Oct 2008 13:29:13 -0400 Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect In-Reply-To: <67343F3352A8754E810F595B99255BDC0151ECC0@EXMBX00.corp.cbeyond.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> <67343F3352A8754E810F595B99255BDC0151ECC0@EXMBX00.corp.cbeyond.net> Message-ID: <67343F3352A8754E810F595B99255BDC0151ECE4@EXMBX00.corp.cbeyond.net> Forgive the typo in my previous e-mail. I meant to say, " In fact, customers with a single domain may have many SIP Trunks with a subset of their numbers routing to that trunk." -----Original Message----- From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Chris Gatch Sent: Wednesday, October 15, 2008 1:21 PM To: Elwell, John; techwg at sipforum.org Subject: Re: [SIPForum-techwg] Thoughts on registration in SIPconnect In practice, registration by the PBX of a single AOR that is associated by the service provider with other AORs of the same enterprise is broadly implemented under SIPconnect 1.0. The primary use of this registration is providing the IP address of the system registering and creating an initial outbound session through firewalls and ALGs for purposes of providing SIP-friendly address translation. The idea below of a wildcard as outlined below doesn't apply b/c the association is made only by the service provider, and all addresses within a domain are not assumed to be associated to a single SIP Trunk. In fact, customers with a single domain may have many SIP Trunks with a subject of their numbers routing to that trunk. A dynamic method of the PBX making itself known to the SIP is essential to a successful specification. Registration is broadly implemented and seems to currently service this purpose very well. Chris -----Original Message----- From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of Elwell, John Sent: Tuesday, October 14, 2008 12:00 PM To: techwg at sipforum.org Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect I have had some off-line discussions with some IETF experts, and I have detected some concern about the direction that SIPconnect is heading with its use of registration. There was already concern during the Denver meeting about the complexities of the registration-based approach. I could try to summarise the registration-based approach as follows: With registration, a PBX to registers a default AoR such as: sip:+123456000 at enterprise.com;user=phone and as a result can receive all inbound requests to that enterprise. In principle, this should mean all requests targeted at sip:*@enterprise.com, e.g.: sip:alice at enterprise.com sip:12345 at enterprise.com sip:+123456789 at enterprise.com;user=phone should be delivered to the PBX. In these cases, the domain part is enterprise.com, so the SP shouldn't look at the user part. However, in practice, the SP is also going to receive requests targeted at, for example: tel:+123456789 sip:+123456789 at serviceprovider.net;user=phone In these cases, the E.164 number is "assigned" to enterprise.com, the SP needs to recognise this and forward the request to the PBX, but with, enterprise.com in the domain part (otherwise the PBX will reject the request, or try to forward it back to the SP). So it would end up being forwarded as: sip:+123456789 at enterprise.com;user=phone The fact that the PBX has registered really makes no difference to the SP's decision to forward a request to the PBX: - whether or not the PBX has registered, requests targeted at *@enterprise.com need to be delivered to the PBX; - whether or not the PBX has registered, requests targeted at an E.164 number assigned to the PBX need to be retargeted to a SIP URI with enterprise.com in the domain part, and then delivered to the PBX as above. The only difference that registration makes is that it provides a "flow" over which requests can be delivered (rather than using RFC 3263 to determine where to route to) and that "flow" is kept alive. It seems that a similar result could be obtained by using connection re-use and some sort of keep-alive (e.g., SIP OPTIONS). For example, the PBX could establish a connection to the SP using OPTIONS and keep it alive using OPTIONS, and the SP could re-use this connection for inbound requests to the PBX. This would avoid the use of REGISTER, and would be closer to SIPconnect 1.0 (where the PBX was not required to register). By doing something like this, we could converge on a single mode of operation and keep the basic implementation requirements to a minimum. If something along these lines does not satisfy requirements, let's get the requirements on the table so that we can see which items in the SIP tool kit would do the job. John _______________________________________________ techwg mailing list Send mail to: techwg at sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg _______________________________________________ techwg mailing list Send mail to: techwg at sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg From pkyzivat at cisco.com Wed Oct 15 14:41:19 2008 From: pkyzivat at cisco.com (Paul Kyzivat) Date: Wed, 15 Oct 2008 14:41:19 -0400 Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0012DB549@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0012DB549@GBNTHT12009MSX.gb002.siemens.net> Message-ID: <48F6394F.1060100@cisco.com> inline... Elwell, John wrote: > > >> -----Original Message----- >> From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com] >> Sent: 15 October 2008 15:22 >> To: Elwell, John; techwg at sipforum.org >> Subject: RE: Thoughts on registration in SIPconnect >> >> >> I think we agreed in Denver that registering an Enterprise's >> domain into an SP would be a valid use-case, but the more rare case. >> >> Just to make sure we're on the same page, the more common >> case was the Enterprise would register an AoR in the SP's >> domain, such as: >> sip:+123456000 at serviceprovider.net;user=phone > [JRE] In fact, I had neglected to cover the case where the enterprise > does not have its own domain name or a permanent IP address. However, I > had in mind section 11.4 of the spec, which currently mandates use of > the enterprise domain name. I don't recall reviewing that section. > >> And I think we agreed in that case that if a call came to the >> SP destined to the Enterprise, such as: >> sip:+1234561234 at serviceprovider.net >> That the Service Provider would not change the req-uri to the >> registered AoR's Contact-uri, but rather just insert a Route >> header to the registered contact. Right? (or am I forgetting >> what we agreed to?) > [JRE] Yes, I think we agreed on this loose routing concept, in which the > AoR of the target (as opposed to the registered contact URI) is in the > Request URI when delivered to the enterprise. But I had assumed this > would have the enterprise domain in the domain part - otherwise, if the > enterprise receives the SP's domain, it is likely either to reject the > request (404) or route it back to the SP, since the enterprise is not > responsible for the SP's domain. I guess this could be made to work either way. In either case, the registration isn't used for its conventional purpose at all. Instead, all it does is provide a contact address / flow that the SP will then bind to a particular service contract based on the AOR of the registration. In one approach, a service contract binds a set of phone numbers to a domain name. It also binds the flow associated with the registration to the dedicated AOR with that same domain name. When the SP receives a request directed to a phone number and the SP domain, it retargets the request to the same phone number, but in the domain specified by some service contract. Then, or if it receives a request for some other domain, it finds the service contract that has that domain name, and then routes to the contract address / flow that has been registered for the service contract. In the other approach that Hadriel is suggesting, things are similar to the above, but there is no domain name associated with the service contract. The R-URI is not translated. Rather, it is simply routed using the contact/flow of the service contract that matches the target phone number. In this case of course the receiving ipPBX would have to recognize particular phone numbers in the SP domain as being its responsibility. Seems a bit cleaner to have the domain name per pbx. Thanks, Paul >> That's still consistent, BTW. In this case no retargeting is >> occurring, because the target is within the same domain >> context. In the Enterprise.com registered case, it is a >> retarget because it's changing the domain context. > [JRE] Yes. > > John > >> -hadriel >> >> >>> -----Original Message----- >>> From: techwg-bounces at sipforum.org >> [mailto:techwg-bounces at sipforum.org] On >>> Behalf Of Elwell, John >>> Sent: Tuesday, October 14, 2008 12:00 PM >>> To: techwg at sipforum.org >>> Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect >>> >>> I have had some off-line discussions with some IETF >> experts, and I have >>> detected some concern about the direction that SIPconnect is heading >>> with its use of registration. There was already concern during the >>> Denver meeting about the complexities of the registration-based >>> approach. >>> >>> I could try to summarise the registration-based approach as follows: >>> >>> With registration, a PBX to registers a default AoR such as: >>> sip:+123456000 at enterprise.com;user=phone >>> and as a result can receive all inbound requests to that enterprise. >>> >>> In principle, this should mean all requests targeted at >>> sip:*@enterprise.com, e.g.: >>> sip:alice at enterprise.com >>> sip:12345 at enterprise.com >>> sip:+123456789 at enterprise.com;user=phone >>> should be delivered to the PBX. >>> >>> In these cases, the domain part is enterprise.com, so the >> SP shouldn't >>> look at the user part. >>> >>> However, in practice, the SP is also going to receive >> requests targeted >>> at, for example: >>> tel:+123456789 >>> sip:+123456789 at serviceprovider.net;user=phone >>> >>> In these cases, the E.164 number is "assigned" to >> enterprise.com, the SP >>> needs to recognise this and forward the request to the PBX, >> but with, >>> enterprise.com in the domain part (otherwise the PBX will reject the >>> request, or try to forward it back to the SP). So it would >> end up being >>> forwarded as: >>> sip:+123456789 at enterprise.com;user=phone >>> >>> The fact that the PBX has registered really makes no >> difference to the >>> SP's decision to forward a request to the PBX: >>> - whether or not the PBX has registered, requests targeted at >>> *@enterprise.com need to be delivered to the PBX; >>> - whether or not the PBX has registered, requests targeted >> at an E.164 >>> number assigned to the PBX need to be retargeted to a SIP URI with >>> enterprise.com in the domain part, and then delivered to the PBX as >>> above. >>> >>> The only difference that registration makes is that it >> provides a "flow" >>> over which requests can be delivered (rather than using RFC 3263 to >>> determine where to route to) and that "flow" is kept alive. >>> >>> It seems that a similar result could be obtained by using connection >>> re-use and some sort of keep-alive (e.g., SIP OPTIONS). For >> example, the >>> PBX could establish a connection to the SP using OPTIONS and keep it >>> alive using OPTIONS, and the SP could re-use this >> connection for inbound >>> requests to the PBX. This would avoid the use of REGISTER, >> and would be >>> closer to SIPconnect 1.0 (where the PBX was not required to >> register). >>> By doing something like this, we could converge on a single mode of >>> operation and keep the basic implementation requirements to >> a minimum. >>> If something along these lines does not satisfy >> requirements, let's get >>> the requirements on the table so that we can see which >> items in the SIP >>> tool kit would do the job. >>> >>> John >>> >>> _______________________________________________ >>> techwg mailing list >>> Send mail to: techwg at sipforum.org >>> Unsubscribe or edit options at: >>> http://sipforum.org/mailman/listinfo/techwg > > _______________________________________________ > techwg mailing list > Send mail to: techwg at sipforum.org > Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg > From richard at shockey.us Wed Oct 15 15:03:59 2008 From: richard at shockey.us (Richard Shockey) Date: Wed, 15 Oct 2008 15:03:59 -0400 Subject: [SIPForum-techwg] Notes from the telecon on the Rathole issues. Message-ID: <015101c92ef8$dd9bc470$98d34d50$@us> On the call.. 14 October 2008 10:AM Richard Shockey Spencer Dawkins Bernard Aboba Dan York Jamie Palmer(broadsoft) John Elwell Mark Enstrom Martin Dolly (ATT) Russ Bennett (MS) Cisco person ?? sorry. Shockey suggests that authors of revised sections from the face to face get those to Spencer ASAP The 4 major issues on the table were. TLS support TCP Support NAT ICE Etc. IPV6 support etc. 1. TLS there was continued consensus on SHOULD where secure managed connections exist but add language on unsecured connections where Enterprise to SSP should be MUST. Should include in an Appendix (Additional Guidelines). Core document should reflect MUST issues as much as possible. 2. NAT- ICE STUN etc - Continued consensus that these issues should NOT be called out in the 1.1 document 3. IPv6 - Again an issue for Additional Guidelines section. The issue of V4 exhaust should be called out some form of additional guidelines appendix out and a reminder to SSP and Enterprises alike that the issue is not going away. Many Asian carriers are very well along in V6 deployments etc and that work onV4-V6 migration and translations SHOULD be undertaken. Text here is clearly needed. Volunteers needed. 4. TCP. Emerging consensus that MUST is required but considerable confusion on operational issues surrounding TCP and ISUP integration where timing issues may be seriously impacted. Registration vs Static provisioning has impact on this. Ideally one TCP connection between PBX and SSP SHOULD be implemented but how Multi-homing impacts this is unclear. Discussion of current draft on draft-ietf-sip-connect-reuse-11 and status. Unresolved if this draft is required for 1.1. Martin Dolly to send note to the list outlining his concerns here. Reconfirmation on need for: https://datatracker.ietf.org/drafts/draft-ietf-sip-outbound/ https://datatracker.ietf.org/drafts/draft-ietf-sipping-cc-transfer/ Meeting adjourns 11:30 Did I miss anyting? Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 From D.Hancock at CableLabs.com Wed Oct 15 18:12:31 2008 From: D.Hancock at CableLabs.com (David Hancock) Date: Wed, 15 Oct 2008 16:12:31 -0600 Subject: [SIPForum-techwg] Proposal for Action Item 8 from SIPconnect face-to-face Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C60150B550@srvxchg3.cablelabs.com> Regarding action-item 8 from SIPconnect face-to-face... 8. Action Item to integrate/align sections 10,11,12,13. Dave Hancock and Jamie Palmer of Broadsoft to lead. Jamie and I reviewed these sections and the various technical comments against them, and propose that the 4 existing sections be collapsed into 2 sections. The organization of the two new sections will follow the organization of the existing 12 & 13, so that the new/combined section 10 covers SP Network --> SIP-PBX calls, and the new 11 covers calls from the SIP-PBX --> SP Network calls. One of the v00 review comments noted that the procedures in the existing 10/11/12/13 don't account for the use-case where the SIP-PBX forwards an incoming call from the SP network back to the SP network in a new INVITE. For example, the procedures don't support the case where the PAI of the new INVITE sent from SIP-PBX identifies a user external to the SIP-PBX. Another comment noted that the procedures don't align w.r.t., handling of emergency calls. We decided to resolve these issues by limiting the scope of the new section 11 to basic 2-way calls originated by a user in the SIP-PBX. Calls incoming to the SIP-PBX that are forwarded back to the SP network will be described in the subsequent "Retargeting" section (currently 15.5). Emergency calls will be covered in a subsequent separate chapter dedicated to emergency calls (currently 15.6.1). Another review comment noted that existing section 15.3 "Basic 2-way Calling" contained duplicate material to existing sections 10/11/12/13. We decided to move any unique text from 15.3 into the new sections 10/11, and delete 15.3. With this (proposed) re-org, sections 10 and beyond describe call signaling for different call types, such as - basic 2-way calls originating from or terminating to SIP-PBX, - calls retargeted by SIP-PBX, - emergency calls originated by SIP-PBX - etc Existing section 14 "Media Attributes and Minimum Requirements" seems like an odd-man-out in this series. Therefore, we propose that this media-centric section 14 be moved to later in the document, so that all the sections related to call signaling can be grouped together. The new proposed document organization would then look like this... 10 Incoming Calls from the Service Provider to the Enterprise {covers basic 2-way DOD calls originated locally by SIP-PBX user} 11 Outgoing Calls from the Enterprise to the Service Provider {covers basic 2-way DID calls into SIP-PBX} 12 Service Interactions 12.1 Call Hold 12.2 Retargeting Related Services {includes call-fwding & xfer, and redirect to SP-based voice message server} 12.3 Regulatory Services {Describes everything related to emergency calls} 12.4 Message Waiting Indication {Describes how to signal the signal message-waiting info to the SIP-PBX when the SP network provides the voice-mail service. This wasn't in the v00 version - did we miss it, or agree to leave it out?) 13. Media Requirements I'll submit the proposed text for new sections 10 & 11 in a subsequent email. Once we see how that looks, we may want to make additional changes (such as moving 10 and 11 into level-2 subsections of section 12, and change the level-1 name to something like "Call Signaling Requirements"). Comments welcome. David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://sipforum.org/pipermail/techwg/attachments/20081015/4885cc38/attachment-0001.html From john.elwell at siemens.com Thu Oct 16 02:30:37 2008 From: john.elwell at siemens.com (Elwell, John) Date: Thu, 16 Oct 2008 07:30:37 +0100 Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect In-Reply-To: <67343F3352A8754E810F595B99255BDC0151ECC0@EXMBX00.corp.cbeyond.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> <67343F3352A8754E810F595B99255BDC0151ECC0@EXMBX00.corp.cbeyond.net> Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0012DB5BA@GBNTHT12009MSX.gb002.siemens.net> > -----Original Message----- > From: Chris Gatch [mailto:Chris.Gatch at cbeyond.net] > Sent: 15 October 2008 18:21 > To: Elwell, John; techwg at sipforum.org > Subject: RE: Thoughts on registration in SIPconnect > > In practice, registration by the PBX of a single AOR that is > associated by the service provider with other AORs of the > same enterprise is broadly implemented under SIPconnect 1.0. > The primary use of this registration is providing the IP > address of the system registering and creating an initial > outbound session through firewalls and ALGs for purposes of > providing SIP-friendly address translation. [JRE] We said yesterday that it was the PBX's responsibility to get through firewalls/NATs on the enterprise side. However, I agree that registration helps in the case where the PBX doesn't have a permanent IP address, if this is a requirement we expect to address with SIPconnect 1.1. > > The idea below of a wildcard as outlined below doesn't apply > b/c the association is made only by the service provider, and > all addresses within a domain are not assumed to be > associated to a single SIP Trunk. In fact, customers with a > single domain may have many SIP Trunks with a subject of > their numbers routing to that trunk. > > A dynamic method of the PBX making itself known to the SIP is > essential to a successful specification. Registration is > broadly implemented and seems to currently service this > purpose very well. [JRE] OK, but we just need to keep the PBX-side requirements for registration to a minimum. We may need some aspects of sip-outbound as a means of addressing resilience. Other things suggested such as P-Associated-URI and the registration event package do not seem to be essential and should be left out. John > > Chris > > > > -----Original Message----- > From: techwg-bounces at sipforum.org > [mailto:techwg-bounces at sipforum.org] On Behalf Of Elwell, John > Sent: Tuesday, October 14, 2008 12:00 PM > To: techwg at sipforum.org > Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect > > I have had some off-line discussions with some IETF experts, > and I have > detected some concern about the direction that SIPconnect is heading > with its use of registration. There was already concern during the > Denver meeting about the complexities of the registration-based > approach. > > I could try to summarise the registration-based approach as follows: > > With registration, a PBX to registers a default AoR such as: > sip:+123456000 at enterprise.com;user=phone > and as a result can receive all inbound requests to that enterprise. > > In principle, this should mean all requests targeted at > sip:*@enterprise.com, e.g.: > sip:alice at enterprise.com > sip:12345 at enterprise.com > sip:+123456789 at enterprise.com;user=phone > should be delivered to the PBX. > > In these cases, the domain part is enterprise.com, so the SP shouldn't > look at the user part. > > However, in practice, the SP is also going to receive > requests targeted > at, for example: > tel:+123456789 > sip:+123456789 at serviceprovider.net;user=phone > > In these cases, the E.164 number is "assigned" to > enterprise.com, the SP > needs to recognise this and forward the request to the PBX, but with, > enterprise.com in the domain part (otherwise the PBX will reject the > request, or try to forward it back to the SP). So it would > end up being > forwarded as: > sip:+123456789 at enterprise.com;user=phone > > The fact that the PBX has registered really makes no difference to the > SP's decision to forward a request to the PBX: > - whether or not the PBX has registered, requests targeted at > *@enterprise.com need to be delivered to the PBX; > - whether or not the PBX has registered, requests targeted at an E.164 > number assigned to the PBX need to be retargeted to a SIP URI with > enterprise.com in the domain part, and then delivered to the PBX as > above. > > The only difference that registration makes is that it > provides a "flow" > over which requests can be delivered (rather than using RFC 3263 to > determine where to route to) and that "flow" is kept alive. > > It seems that a similar result could be obtained by using connection > re-use and some sort of keep-alive (e.g., SIP OPTIONS). For > example, the > PBX could establish a connection to the SP using OPTIONS and keep it > alive using OPTIONS, and the SP could re-use this connection > for inbound > requests to the PBX. This would avoid the use of REGISTER, > and would be > closer to SIPconnect 1.0 (where the PBX was not required to register). > > By doing something like this, we could converge on a single mode of > operation and keep the basic implementation requirements to a minimum. > > If something along these lines does not satisfy requirements, > let's get > the requirements on the table so that we can see which items > in the SIP > tool kit would do the job. > > John > > _______________________________________________ > techwg mailing list > Send mail to: techwg at sipforum.org > Unsubscribe or edit options at: > http://sipforum.org/mailman/listinfo/techwg > From john.elwell at siemens.com Thu Oct 16 02:37:28 2008 From: john.elwell at siemens.com (Elwell, John) Date: Thu, 16 Oct 2008 07:37:28 +0100 Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect In-Reply-To: <48F6394F.1060100@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0012DB549@GBNTHT12009MSX.gb002.siemens.net> <48F6394F.1060100@cisco.com> Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0012DB5BD@GBNTHT12009MSX.gb002.siemens.net> > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat at cisco.com] > Sent: 15 October 2008 19:41 > To: Elwell, John > Cc: Hadriel Kaplan; techwg at sipforum.org > Subject: Re: [SIPForum-techwg] Thoughts on registration in SIPconnect > > inline... > > Elwell, John wrote: > > > > > >> -----Original Message----- > >> From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com] > >> Sent: 15 October 2008 15:22 > >> To: Elwell, John; techwg at sipforum.org > >> Subject: RE: Thoughts on registration in SIPconnect > >> > >> > >> I think we agreed in Denver that registering an Enterprise's > >> domain into an SP would be a valid use-case, but the more > rare case. > >> > >> Just to make sure we're on the same page, the more common > >> case was the Enterprise would register an AoR in the SP's > >> domain, such as: > >> sip:+123456000 at serviceprovider.net;user=phone > > [JRE] In fact, I had neglected to cover the case where the > enterprise > > does not have its own domain name or a permanent IP > address. However, I > > had in mind section 11.4 of the spec, which currently > mandates use of > > the enterprise domain name. I don't recall reviewing that section. > > > >> And I think we agreed in that case that if a call came to the > >> SP destined to the Enterprise, such as: > >> sip:+1234561234 at serviceprovider.net > >> That the Service Provider would not change the req-uri to the > >> registered AoR's Contact-uri, but rather just insert a Route > >> header to the registered contact. Right? (or am I forgetting > >> what we agreed to?) > > [JRE] Yes, I think we agreed on this loose routing concept, > in which the > > AoR of the target (as opposed to the registered contact > URI) is in the > > Request URI when delivered to the enterprise. But I had assumed this > > would have the enterprise domain in the domain part - > otherwise, if the > > enterprise receives the SP's domain, it is likely either to > reject the > > request (404) or route it back to the SP, since the > enterprise is not > > responsible for the SP's domain. > > I guess this could be made to work either way. > > In either case, the registration isn't used for its > conventional purpose > at all. Instead, all it does is provide a contact address / flow that > the SP will then bind to a particular service contract based > on the AOR > of the registration. > > In one approach, a service contract binds a set of phone numbers to a > domain name. It also binds the flow associated with the > registration to > the dedicated AOR with that same domain name. When the SP receives a > request directed to a phone number and the SP domain, it > retargets the > request to the same phone number, but in the domain specified by some > service contract. Then, or if it receives a request for some other > domain, it finds the service contract that has that domain name, and > then routes to the contract address / flow that has been > registered for > the service contract. > > In the other approach that Hadriel is suggesting, things are > similar to > the above, but there is no domain name associated with the service > contract. The R-URI is not translated. Rather, it is simply > routed using > the contact/flow of the service contract that matches the > target phone > number. In this case of course the receiving ipPBX would have to > recognize particular phone numbers in the SP domain as being its > responsibility. > > Seems a bit cleaner to have the domain name per pbx. [JRE] I agree with your summary. Furthermore, if non-E.164-based identifiers are to be used, e.g., sip:alice at example.com, it seems the enterprise domain name will need to be used. In this case the second half of the procedure would apply, i.e., the SP "finds the service contract that has that domain name, and then routes to the contract address / flow that has been registered for the service contract." Hadriel's approach seems unsuitable for non-E.164-based identifiers. Although such identifiers would not arise with PSTN interworking, they may arise when using SIP end-to-end. John From john.elwell at siemens.com Thu Oct 16 02:58:35 2008 From: john.elwell at siemens.com (Elwell, John) Date: Thu, 16 Oct 2008 07:58:35 +0100 Subject: [SIPForum-techwg] Proposal for Action Item 8 from SIPconnectface-to-face In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C60150B550@srvxchg3.cablelabs.com> References: <9AAEDF491EF7CA48AB587781B8F5D7C60150B550@srvxchg3.cablelabs.com> Message-ID: <0D5F89FAC29E2C41B98A6A762007F5D0012DB5C1@GBNTHT12009MSX.gb002.siemens.net> David, No specific comments, except that 12.2 "Retargeting-related services" seems like it will need to cover a multitude of sins, so may need to break down further. But let's see what it looks like. Also, if 10 and 11 are going to disregard retargeted calls, they should at least make it clear that additional requirements for retargeted calls occur later. John ________________________________ From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On Behalf Of David Hancock Sent: 15 October 2008 23:13 To: techwg at sipforum.org Subject: [SIPForum-techwg] Proposal for Action Item 8 from SIPconnectface-to-face Regarding action-item 8 from SIPconnect face-to-face... 8. Action Item to integrate/align sections 10,11,12,13. Dave Hancock and Jamie Palmer of Broadsoft to lead. Jamie and I reviewed these sections and the various technical comments against them, and propose that the 4 existing sections be collapsed into 2 sections. The organization of the two new sections will follow the organization of the existing 12 & 13, so that the new/combined section 10 covers SP Network --> SIP-PBX calls, and the new 11 covers calls from the SIP-PBX --> SP Network calls. One of the v00 review comments noted that the procedures in the existing 10/11/12/13 don't account for the use-case where the SIP-PBX forwards an incoming call from the SP network back to the SP network in a new INVITE. For example, the procedures don't support the case where the PAI of the new INVITE sent from SIP-PBX identifies a user external to the SIP-PBX. Another comment noted that the procedures don't align w.r.t., handling of emergency calls. We decided to resolve these issues by limiting the scope of the new section 11 to basic 2-way calls originated by a user in the SIP-PBX. Calls incoming to the SIP-PBX that are forwarded back to the SP network will be described in the subsequent "Retargeting" section (currently 15.5). Emergency calls will be covered in a subsequent separate chapter dedicated to emergency calls (currently 15.6.1). Another review comment noted that existing section 15.3 "Basic 2-way Calling" contained duplicate material to existing sections 10/11/12/13. We decided to move any unique text from 15.3 into the new sections 10/11, and delete 15.3. With this (proposed) re-org, sections 10 and beyond describe call signaling for different call types, such as - basic 2-way calls originating from or terminating to SIP-PBX, - calls retargeted by SIP-PBX, - emergency calls originated by SIP-PBX - etc Existing section 14 "Media Attributes and Minimum Requirements" seems like an odd-man-out in this series. Therefore, we propose that this media-centric section 14 be moved to later in the document, so that all the sections related to call signaling can be grouped together. The new proposed document organization would then look like this... 10 Incoming Calls from the Service Provider to the Enterprise {covers basic 2-way DOD calls originated locally by SIP-PBX user} 11 Outgoing Calls from the Enterprise to the Service Provider {covers basic 2-way DID calls into SIP-PBX} 12 Service Interactions 12.1 Call Hold 12.2 Retargeting Related Services {includes call-fwding & xfer, and redirect to SP-based voice message server} 12.3 Regulatory Services {Describes everything related to emergency calls} 12.4 Message Waiting Indication {Describes how to signal the signal message-waiting info to the SIP-PBX when the SP network provides the voice-mail service. This wasn't in the v00 version - did we miss it, or agree to leave it out?) 13. Media Requirements I'll submit the proposed text for new sections 10 & 11 in a subsequent email. Once we see how that looks, we may want to make additional changes (such as moving 10 and 11 into level-2 subsections of section 12, and change the level-1 name to something like "Call Signaling Requirements"). Comments welcome. David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://sipforum.org/pipermail/techwg/attachments/20081016/62f84897/attachment-0001.html From pkyzivat at cisco.com Thu Oct 16 10:55:41 2008 From: pkyzivat at cisco.com (Paul Kyzivat) Date: Thu, 16 Oct 2008 10:55:41 -0400 Subject: [SIPForum-techwg] Thoughts on registration in SIPconnect In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0012DB5BD@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0012A23EF@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0012DB549@GBNTHT12009MSX.gb002.siemens.net> <48F6394F.1060100@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0012DB5BD@GBNTHT12009MSX.gb002.siemens.net> Message