Add support for SIP configuration#782
Conversation
|
Suggestion to move these new APIs into a SIP specification. Will be working on that shortly. |
| <!--===============================--> | ||
| <xs:complexType name="ServerConfiguration"> | ||
| <xs:sequence> | ||
| <xs:element name="Registrar" type="xs:anyURI" minOccurs="1" maxOccurs="unbounded"/> |
There was a problem hiding this comment.
I think we need to support either multiple ServerConfiguration entries, or replace the Registrar array with an array of Registrar structs (or SIPAccount/SIPServer) and put the Authentication config within that struct.
Possibly some of the config in CallConfiguration such as AllowIncomingCalls and AutoAnswer belongs within that struct as well?
Also make it possible to support peer-to-peer accounts that does not use a registrar.
There was a problem hiding this comment.
What would be the use cases of having multiple SIP server configurations? As it is currently defined, we already have redundancy and resilience using the multiple registrar URIs within the configuration.
| <xs:documentation>The user info/extension of the Address of Record (AoR) in SIP, identifying the recipient on the registrar.</xs:documentation> | ||
| </xs:annotation> | ||
| </xs:element> | ||
| <xs:element name="Order" minOccurs="1"> |
There was a problem hiding this comment.
Suggest replacing this with a "CallTrigger" string,which should be one of the values returned from a new GetCallTriggers call or similar so there is a clear way to see if a call is triggered from what physical button or I/O, e.g: "Callbutton 1", "Callbutton 2", "External IO1", "External IO2", "TouchDisplay"
For calls triggered by a touch display, the value could be e.g "TouchDisplay" could be part of the supported CallTriggers.
And let the order in the array control the order of display based call triggers. Ok to have multiple recipients that share the same CallTrigger.
johado
left a comment
johado
left a comment
There was a problem hiding this comment.
Like the idea in general. Hard to balance making it simple enough without make it to limited and hard to map to our current implementation.
| <!--===============================--> | ||
| <xs:complexType name="ServerConfiguration"> | ||
| <xs:sequence> | ||
| <xs:element name="Registrar" type="xs:anyURI" minOccurs="1" maxOccurs="unbounded"/> |
There was a problem hiding this comment.
I think the following configuration should be added as part of registrar configuration.
- Transport protocol [UDP, TCP, TLS, SIPS] ==> Mandatory field
- Outbound proxy server (I think is important for Multitenant SIP platforms, Service provider routing,Security and policy enforcement, NAT traversal) ==> Optional field.
- Is it important for the client to know the registration status of the SIP configuration? I think we can add it as event or part of the get configuration response, to notify the client on registered, failed to register state.
There was a problem hiding this comment.
- We will propose something for this
- I don't mind adding this, what other than a URI would be needed for the proxy config?
- It is great idea to add this event. Do you already have a suggestion for which fields to include in the event?
There was a problem hiding this comment.
Proposed something for the transport. Might be missing a bit of documentation though
| </xs:complexType> | ||
| </xs:element> | ||
| <!--===============================--> | ||
| <xs:complexType name="CallRecipient"> |
There was a problem hiding this comment.
DTMF can be added as part of CallRecipient configuration.
DTMF can be used to trigger actions like lock or open the door. I am not very clear of the use-case.
There was a problem hiding this comment.
We weren't initially planning to add DTMFs in the specification. I know that ONVIF already supports relay outputs which seems to be what would be used to trigger the door opening. Wouldn't that specification work better than plugging it here with recipients?
| <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <!-- first ONVIF then Vendor --> | ||
| </xs:sequence> | ||
| </xs:complexType> | ||
| <xs:complexType name="StreamingConfigurationOptions"> |
There was a problem hiding this comment.
In streamingConfiguration media encryption options can be added.
Like SRTP mandatory, best-effort or just plain RTP without encryption.
There was a problem hiding this comment.
True. It doesn't really match the way the configuration models in ONVIF operate, but maybe we could add a global SIP config to this model to have these types of settings?
There was a problem hiding this comment.
I've checked the SipStreamingConfiguration model and Srtp configuration is already part of it in the VideoEncoder configuration, the field is named SecureStreamingProtocolAlgorithm
| <xs:complexType name="ServerConfiguration"> | ||
| <xs:sequence> | ||
| <xs:element name="Registrar" type="xs:anyURI" minOccurs="1" maxOccurs="unbounded"/> | ||
| <xs:element name="UserId" type="xs:string"> |
There was a problem hiding this comment.
Is this the sip address and the AuthenticationId use the UserName in Authentication/Credential below?
Or can the sip address be part of the Registrar uri?
(In SIP those could be two different things)
Does use of AuthorizationServer require a special AuthenticationId if it is not the UsertId?
Added transport for the SIP registrar Misc changes based on discussions or comments made from F2F
| </xs:attribute> | ||
| <xs:anyAttribute processContents="lax"/> | ||
| </xs:complexType> | ||
| <xs:element name="Capabilities" type="tsip:Capabilities"/> |
| </xs:element> | ||
| <!--===============================--> | ||
| <xs:complexType name="Capabilities"> | ||
| <xs:attribute name="MaximumRecipients" type="xs:int" use="required"> |
There was a problem hiding this comment.
Prepare for an extendable sequence of elements for future extendability?
| <xs:documentation>If not configured, server certificate validation behavior is undefined and the device may either apply a vendor specific default validation policy or skip validation at all.</xs:documentation> | ||
| </xs:annotation> | ||
| </xs:element> | ||
| <xs:element name="Authentication" minOccurs="1"> |
There was a problem hiding this comment.
Avoid inline types? Add an explicit SipAuthentication type?
| <xs:documentation>List of call recipients.</xs:documentation> | ||
| </xs:annotation> | ||
| </xs:element> | ||
| </xs:sequence> |
There was a problem hiding this comment.
Add extendability (both attributes and elements)
| <xs:annotation> | ||
| <xs:documentation>Collection of STUN server URIs used for NAT traversal.</xs:documentation> | ||
| </xs:annotation> | ||
| <xs:complexType> |
| <xs:annotation> | ||
| <xs:documentation>Collection of TURN servers used for NAT traversal.</xs:documentation> | ||
| </xs:annotation> | ||
| <xs:complexType> |
johado
left a comment
johado
left a comment
There was a problem hiding this comment.
Some inconsistencies to function arguments, sometimes optional, sometimes not.
5 participants
New API specifications for configuring some settings related to SIP.
SipServerConfiguration: How a SIP device can connect to a SIP registrar
NatConfiguration: If a device needs STUN/TURN servers to reach a SIP registrar (for example in a cloud setup)
CallConfiguration: Settings related to establish a call, for example which recipient are you calling when pressing on a button on an intercom
StreamingConfiguration: Configuration to be used when streaming through a SIP call.