[SIPForum-techwg] SIP phone task group; revisiting group scope / activity

[Francois Audet]

I had the exact same tought. 

> -----Original Message-----
> From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org] On Behalf Of 
> peter_blatherwick at mitel.com
> Sent: Friday, December 15, 2006 12:01
> To: Paul Kyzivat
> Cc: SIP Forum Tech WG; techwg-bounces at sipforum.org
> Subject: Re: [SIPForum-techwg] SIP phone task group; 
> revisiting group scope / activity
> 
> Hi Paul,
> Unless I'm grossly mis-interpreting what you are saying, this 
> is really about the SIP PBX interface spec, or possibly 
> follow-on work from that, not the SIP Phone spec (Jay's 
> question).  Am I confused? 
> -- Peter Blatherwick
> 
> 
> 
> 
> 
> 
> Paul Kyzivat <pkyzivat at cisco.com>
> Sent by: techwg-bounces at sipforum.org
> 15.12.06 14:41
>  
>         To:     Jay Batson <batsonjay at mac.com>
>         cc:     SIP Forum Tech WG <techwg at sipforum.org>
>         Subject:        Re: [SIPForum-techwg] SIP phone task group; 
> revisiting group scope / activity
> 
> 
> Jay,
> 
> One thing that came up during some discussion of SipConnect 
> is that as written it really only addresses connection for 
> purposes of PSTN interconnect. However its reasonable to 
> assume that if somebody is offering PSTN interconnect to 
> multiple enterprises, or to multiple branches of an 
> enterprise, then one would like to directly route calls 
> between those enterprises and branches, without going to the 
> PSTN. While this is not explicitly excluded, the addressing 
> rules are such that a B2BUA is needed in the middle to handle 
> the address transformations. 
> While using a B2BUA should not be excluded, neither should it 
> be mandated for such a case. So I think more work is 
> necessary to properly address that those added cases.
> 
> Also, some ambiguity remains regarding how registration works 
> in SipConnect, that could stand to be clarified.
> 
>                  Thanks,
>                  Paul
> 
> Jay Batson wrote:
> > All --
> > 
> > When the original SIP Phone Task Group meeting was held 
> about a year 
> > ago, the following items were listed by Rohan (and Francois) as 
> > specific objectives of the Task Group:
> > 
> > - Specify DHCP, DNS, ENUM, Network configuration, software 
> upgrades, 
> > configuration and management requirements
> > - Specify SIP protocol feature requirements (MWI, Caller 
> ID, Transfer, 
> > etc.)
> > - Specify Numbering and Dialing Plan requirements
> > - Specific Presence and Instant Messaging requirements
> > - Specify Emergency, Security, QoS, Media, Codec requirements
> > - Specify NAT Traversal requirements
> > - Specify other requirements as necessary
> > 
> > Francois' notes after the meeting recorded the following 
> other items 
> > of interest from the kickoff meeting:
> > - We should focus on obviously on SIP aspects for Interop.
> > - We may refer to other documents (such as the TIA 
> document) for other 
> > complementary aspects (acoustics, etc.). No need to reinvent the 
> > wheel.
> > - Layer 2/Layer 3 aspects are not in scope (i.e., we won't 
> specify how 
> > to support an IP stack, or Ethernet). However, 
> configuration of layer 
> > 2 or layer 3 parameters such as Diffserv codpoints on devices is in 
> > scope.
> > - We should not forget features that are not traditional 
> "telephony" 
> > features, but which make SIP so attractive:
> > -- Presence, Instant messaging.
> > -- Even devices with limited capablities (like no screen) should be 
> > able to play nice by publishing presence state for example.
> > - Lots of talk about NOT defining "profiles" that define the phones 
> > themselves (not to repeat past mistakes). We should instead define 
> > profiles for certain types of features (e.g, for basic 
> telephony, for 
> > presence, for instant messaging, for NAT traversal, etc.).
> > 
> > Other relevant progress came from stuff by Markus Isomaki 
> from Nokia 
> > (here and here), who was trying to write some stuff down.
> > 
> > Since the last real work that was done in this Task Group, 
> a couple of 
> > IETF activities have tried to take a stab at configuration-related 
> > items.  It probably makes sense, therefore, to hold off on 
> additional 
> > configuration-related work in the SIP Phone Task Group to see what 
> > comes out of the IETF.
> > 
> > However, what do people think about continuing the work on 
> the other 
> > items?  And knowing what we know now, have we listed "enough" other 
> > items?  The basic underlying question is this:  is there effective 
> > work we can do in the SIP Phone Task Group while the IETF is still 
> > hashing out configuration-related drafts?
> > 
> > IMHO, in reviewing the list archives, I think there's 
> plenty that can 
> > go on in parallel with the config stuff at the IETF.  But 
> we need to 
> > restart a conversation, and (potentially) find people who 
> are willing 
> > to be co-scriveners.
> > 
> > Comments, people, please?
> > -jb
> > 
> > -----------------
> > Jay Batson
> > batsonjay at mac.com
> > +1-978-824-0111 (w)
> > +1-978-758-1599 (m)
> > 
> > 
> > _______________________________________________
> > 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
> 
> 
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:  
> http://sipforum.org/mailman/listinfo/techwg
>