[SIPForum-techwg] SIPconnect 2.0 requirements kick offdiscussion

[Michael Procter]

Dale Worley wrote:
> Certainly stating it right is a worthwhile goal; otherwise some people
> will start deviating from the stated standard while staying within the
> intended standard, and eventually people will start straying from the
> intended standard.

> The rule we really want is that any IP address (or DNS name, for that
> matter) that is "exposed" for the use of other SIP agents should be
> publicly resolvable and routable.

> However, someone suggested that the Contact header be exempt, but I
> think that's a bad idea -- the Contact URI is there to be used under
> various circumstances.  (Providing globally resolvable Contact URIs was
> the motivation for inventing the GRUU mechanism.)

Exactly.  Maybe there are two actions here.  Firstly, we need to make sure that the SIPconnect document doesn't try to impose constraints that are uneccessarily tight.  My original comment reflects a change in this area.
 
Secondly, maybe we need to generate a document suggesting ways in which a 'pure' proxy + UAs implementation can meet the requirements of the interface.  Suggesting gruu support in all UAs to ensure that the Contact URIs are publically routable is one aspect of that.  I am sure we can get some ICE requirements in there to make any IP addresses in the SDP appropriate too.  There are bound to be other suggested implementation choices that can be enumerated.
 
The distinction between the two is that the first (SIPconnect) defines the ISP interface, but the second describes how that may be implemented without using B2BUAs.  You can ignore the second document if you plan to use a B2BUA on the interface, without impacting your ability to implement the the SIPconnect interface.
 
This second document could also tie up with the proposed Phone task group work, in that it will start to outline the basic requirements that UAs will need to meet, in order to work when deployed in an enterprise using proxies, and connecting to the rest of the world via SIPconnect.  Of course, there is more to the Phone Task Group work than this, but it might be a useful starting point.
 
Regards,
 
Michael