[SIPForum-techwg] Avaya Contribution for SIPconnect 1.1

[Elwell, John]

> -----Original Message-----
> From: techwg-bounces at sipforum.org 
> [mailto:techwg-bounces at sipforum.org] On Behalf Of Dan Wing
> Sent: 10 June 2008 01:37
> To: 'Richard Shockey'
> Cc: techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] Avaya Contribution for SIPconnect 1.1
> 
> 
> > My curiosity was about enterprise to SP where the SP its 
> theoretically
> > terminating on the PSTN.
> 
> But nobody can predict, prior to sending the Invite, if the call is
> going to terminate on the enterprise or on a service provider's PSTN
> gateway.  Call forwarding (from your office number to your 
> home number)
> is a good example where you can't 'know'.
[JRE] This just highlights the fact that we need to be clear on the
scope of 1.1 - is it just for PSTN access (as 1.0 appears to be) or is
it indeed for SIP-SIP cases too? In the latter case end-to-end
transparency of SDP, different media, etc. becomes a lot more important.

> 
> > Do the carrier proxy platforms support SRTP?
> 
> As in, do they remove a=crypto or a=fingerprint, or break DTLS-SRTP
> or ZRTP?  I dunno; it depends on how they are configured, I am sure,
> and they could be configured to permit those attributes or to block
> them.
> 
> I know Cisco makes PSTN gateways that support SRTP, and I bet a beer
> that others do to (Avaya and Nortel would be high on my list, as they
> already support SRTP on their IP PBXs, too).
[JRE] I believe the Avaya proposal was for Sdescriptions. This is only
viable if all signalling hops are known to be secured (SIPS?) and even
then exposes the key to any SIP intermediary. The IETF still has some
issues before DTLS-SRTP becomes feasible (E.164 numbers, impact of
SBCs). Furthermore SRTP without best effort SRTP does not seem very
useful, so we need SDP capability negotiation (still not finished after
the initial draft was pretty stable about a year ago). Whilst SRTP is
certainly an important capability, I am not sure we are ready to specify
it for 1.1, and mandating support would certainly raise the bar rather
high if we want to get a good population of compliant implementations to
prove that SIP really is interoperable.

John