Re: [rtcweb] Another reason not to use SDP (was: Draft agenda for IETF 87)

[Roman Shpount <[e-mail]>]

On Fri, Jul 12, 2013 at 2:28 PM, Martin Thomson <[e-mail]>wrote:

> That depends entirely on the nature of the instructions.  Allowing for
> extensibility is always really, really hard, but maybe there is enough
> experience with SDP now that this sort of scenario could be supported.
>
>
Unless my past 10 years of experience building SIP systems mislead me, the
current way of dealing with SDP extensibility is to define all features
supported by network or device, go through the interop with every new
network or device you need to connect to, and then, when in doubt, put an
SBC in front of it. We currently need to go through interop testing every
time we setup a new connection with a new VoIP service provider, and this
is for simple PSTN to VoIP G.711+RFC2833 calls. Adding an unusual codec,
like getting a direct interconnect in AMR-WB to cell phone networks, or
SILK to Skype, requires years of testing and still not typically available
commercially. SIP interworking for anything more complex (like even simple
video end points) is virtually non existent. So, I guess, we are building
on a very solid foundation of interprable solutions which require extensive
testing after every sneeze.
_____________
Roman Shpount