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

[Paul Kyzivat]

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
>