voipeer-10----Page:9
1 2 3 4 5 6 7 8 9 10
|
Lessons Learned VoIP SIP peering today No common way of addressing basic VoIP SIP requirements among SIP service providers Issues not limited to service provider model and not necessarily due to “walled garden approach”: end-user model also impacted (SIP UA vendors) Border elements seen as the current “patching solutions” for SIP ‘protocol normalization’ Difficult definition of trust boundaries between providers Various levels of support for common IETF SIP extensions (PRACK, p-asserted-id, UPDATE, etc.) but IETF SIP private extensions perceived as industry specific (e.g. RFC3603) CMSS Specification Enhancements: SIP Implementers should Build standard-based mechanisms for negotiating SIP extensions (Supported, Allow, Require headers) Provide configuration means for end-users and/or providers to be capable of configuring the mandatory/optional SIP extensions advertised in the SIP signaling and provide means for enforcing SIP signaling “policies” |