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

Fri Dec 15 16:01:09 EST 2006

Well, actually....

The posting people were originally responding to was the **SIP  
Phone** task group.  Paul K's comments were (mistakenly) about  
SIPconnect....

Given that there are now two topics in the air, I have two comments:

1)  SIPconnect v2.  There are a number things that need tweaked in  
the SIPconnect Recommendation that have come to light since the  
Recommendation reached "Proposed" status late in the summer.  I think  
(though I'd have to review to be sure) these things fall into two  
categories:
- Things that need fixed in the *existing* functionality /  
definitions.  Think of these as bugs, unclear things, etc.
- Things that reach beyond the current capabilities, e.g. the need to  
define a proxy-type use case (vs. "only" B2BUA).

IMHO, I'd rather we split these two across multiple steps.  I'd  
personally prefer to see the existing Recommendation get its "errors"  
resolved, get some interoperable implementations (and fix whatever  
"errors" get revealed during implementation testing), and advance it  
to final (completed) status.  THEN, go back and add capabilities and  
additional use cases, e.g. proxy support, etc., as a V2.  (This  
conclusion is definitely debatable....)

My reasoning:  Perfect is the enemy of good.  If we re-open a larger  
can of worms, we run the risk of it never being called "Complete  
enough" to get vendors to implement *something*.  I am aware of the  
contrary:  Early implementers may only implement V1, and never get  
around to V2; so not getting V1 right could preclude V2 from ever  
happening.  In the case of the Proxy vs. B2BUA issue, however, I  
think that those who *have* proxy-type implementations won't  
implement a B2BUA type solution; and so if we wait to put the Proxy  
solution in V2, there's no harm:  Those who want the proxy solution  
will implement it when V2 rolls out.

2)  SIP Phone TG. Despite the hesitancy of the august persons who  
have responded so far, I'm personally not convinced we should re- 
start the Phone TG work.  There are at least 7-8 items that showed up  
on the list of things to work on.  Henry's response adds more.   
Though we want to know how to *specify* configuration items in a  
config standard (from the IETF), knowing *what things to specify*  
could be of assistance to the IETF work.  And some of the "other"  
things to work on had nothing to do with SIP (e.g. codecs, security,  
etc.)

So (again IMHO), it is my continued belief (and, by the way, the  
feeling of the Board) that there is definitely work that could be  
done in parallel.

I acknowledge that there could be (or *is*) a human resource issue;  
the people who may be involved in the IETF config work might be the  
same people who would drive the SIP Forum work.  And given that they  
have day jobs, working on two projects might be out of reach for  
those same people.  But that is (theoretically) a separate question  
vs. whether there is work to do now.

-jb

On Dec 15, 2006, at 3:00 PM, peter_blatherwick at mitel.com wrote:

> 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
>
>

-------------
Jay Batson
batsonjay at plumcanary.com
+1-978-824-0111 (w)
+1-978-758-1599 (m)