Add support for SIP configuration - #782
Conversation
|
Suggestion to move these new APIs into a SIP specification. Will be working on that shortly. |
| <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
There was a problem hiding this comment.
SIPS gives some more assuurance compared to TLS, so perhaps SIPS should be added as well.
There was a problem hiding this comment.
Can you explain the difference between SIPS and TLS? My understanding was that TLS infers SIP over TLS. Isn't SIPS the exact same thing?
| </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: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?
There was a problem hiding this comment.
Registrar is an URI in this format: domain:port
UserId is the extension.
So it ends up something like this: "sips:{UserId}@{registrar.Uri}"
AuthorizationServer would contain the token of the configuration if bearer authentication is used (not typical)
Authentication.Credential.Username+Password is more standard, most probably using digest auth challenge through a header.
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>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)
johado
left a comment
johado
left a comment
There was a problem hiding this comment.
Some inconsistencies to function arguments, sometimes optional, sometimes not.
| <wsdl:input message="tsip:SetCallButtonsRequest"/> | ||
| <wsdl:output message="tsip:SetCallButtonsResponse"/> | ||
| </wsdl:operation> | ||
| <wsdl:operation name="GetCallButtonOptions"> |
There was a problem hiding this comment.
Why do we need this GetCallButtonOptions ? we can only findout the callbutton type and description using this method. Instead suggestion is to add this Type (Physical, Virtual, Relay ) to the GetCallButtons Response and remove this options. Additionally here in the options we use token and in ButtonConfiguration we use ButtonId which is not matching.
| <xs:documentation>Indicates whether the device shall allow incoming calls.</xs:documentation> | ||
| </xs:annotation> | ||
| </xs:element> | ||
| <xs:element name="AutoAnswer" type="xs:boolean"> |
There was a problem hiding this comment.
What happens when AllowIncomingCalls is set to true and AutoAnswer is set to false? Will ringtone be played during this time. If that is the case better to associate with a AudioClip Token.
There was a problem hiding this comment.
Should the service support more than configuration? E.g operations for Call, Answer, TerminateCall ?
There was a problem hiding this comment.
To answer @sujithhanwha's question, yes, if AutoAnswer=false, then it would go in a ringing mode.
What is the relationship with ringing and audio clip playing?
@johado what do you propose?
There was a problem hiding this comment.
To answer @sujithhanwha's question, yes, if AutoAnswer=false, then it would go in a ringing mode.
What is the relationship with ringing and audio clip playing?
@johado what do you propose?
Looks like we are assuming that device will play a ringtone on receiving call, was suggesting to map a audio clip token for ringtoken, incase if user wants to customize the ringtone.
| </xs:element> | ||
| <xs:element name="Stun" minOccurs="0" maxOccurs="1"> | ||
| <xs:annotation> | ||
| <xs:documentation>Collection of STUN server URIs used for NAT traversal.</xs:documentation> |
There was a problem hiding this comment.
Do we need parameter to enable and disable ICE ?
There was a problem hiding this comment.
Good question. I know ICE can be provided through the SDP, but I assume here you were referring to trickle ICE?
There was a problem hiding this comment.
Yes, both in general. An explicit control allows clients or devices to enable/disable ICE support when interacting with legacy servers or middleboxes that do not support Full ICE or Trickle ICE.
| <xs:sequence> | ||
| <xs:element name="Configuration" type="tsip:ServerConfigurationTokenPair" minOccurs="0" maxOccurs="unbounded"> | ||
| <xs:annotation> | ||
| <xs:documentation>A SIP server configuration of the device.</xs:documentation> |
There was a problem hiding this comment.
"One or more SIP server configuration of the device."
| </xs:restriction> | ||
| </xs:simpleType> | ||
|
|
||
| <xs:complexType name="ServerConfiguration"> |
There was a problem hiding this comment.
Add a token attribute to ServerConfiguration and skip the TokenPair structure etc.
There was a problem hiding this comment.
If I do that, I still need to define a custom type to be able to create the server configuration, since it is the device that will decide the token. And token is always mandatory, so I can't put it optional and have it null only for creation.
| <!--===============================--> | ||
| <xs:complexType name="CallConfiguration"> | ||
| <xs:sequence> | ||
| <xs:element name="ServerConfiguration" type="tt:ReferenceToken"> |
There was a problem hiding this comment.
Why not let CallConfiguration be an element within ServerConfiguration and skip this reference?
There was a problem hiding this comment.
Separation of concerns. It help to determine and also have a configuration to add other options related to calls in general, which have no consequence on how you connect to a SIP server.
| </xs:element> | ||
| <xs:element name="Relay" type="tsip:ButtonDescription" minOccurs="0" maxOccurs="unbounded"> | ||
| <xs:annotation> | ||
| <xs:documentation>List of relay button ids.</xs:documentation> |
There was a problem hiding this comment.
What is a relay button?
Do you mean a button wired to a digital input?
| <xs:documentation>Display name of the call recipient.</xs:documentation> | ||
| </xs:annotation> | ||
| </xs:element> | ||
| <xs:element name="UserId" type="xs:string" minOccurs="1"> |
There was a problem hiding this comment.
Maybe a better term than "UserId" should be used. "SIPUri"? "To", "Address" ?
|
|
||
| <xs:complexType name="ButtonConfiguration"> | ||
| <xs:sequence> | ||
| <xs:element name="ServerConfiguration" type="tt:ReferenceToken"> |
There was a problem hiding this comment.
Perhaps this should be optional an the server could deduced by the UserId/SIPUri/To/Address in the Button?
Or move it to CallButton? Is ButtonConfiguration needed or is CallButton type enough?
There was a problem hiding this comment.
The list of buttons being configured (line 491) will be part/related to this server configuration and not any other. No need to repeat registrar information over every button.
| <wsdl:output message="tsip:GetServerConfigurationsResponse"/> | ||
| </wsdl:operation> | ||
| <wsdl:operation name="SetServerConfiguration"> | ||
| <wsdl:documentation>This operation sets the SIP server configuration of the device. The device shall support this command. Only one SIP server configuration is supported. If the configuration is absent, the device shall remove the existing SIP server configuration.</wsdl:documentation> |
There was a problem hiding this comment.
Update doc. Not only one supported anymore. The remove is handled with new operation now.
| </xs:sequence> | ||
| </xs:complexType> | ||
|
|
||
| <xs:simpleType name="TransportType"> |
There was a problem hiding this comment.
Add a doc section clarifying that this is a non -normative enum that may be extended in the future.
There was a problem hiding this comment.
But it is normative. It is specified as the only valid values for Transport in the Registrar type (see spec .xml file). This is the standard way to have extensibility for types (Transport is still string, but requires to be one of this enum)
| <xs:element name="AddNatConfiguration"> | ||
| <xs:complexType> | ||
| <xs:sequence> | ||
| <xs:element name="NatConfiguration" type="tsip:NatConfiguration" minOccurs="0"> |
There was a problem hiding this comment.
Possibly to call Add without specifying a NatConfiguration?
Should probably be minOccurs=1
Clearer with a SetNatConfiguration operation instead since you can only have one per server config?
Or should the operation be skipped and NatConfiguration be an element in ServerConfiguration?
| <xs:documentation>List of relay button ids.</xs:documentation> | ||
| </xs:annotation> | ||
| </xs:element> | ||
| <xs:element name="Virtual" type="tsip:ButtonDescription" minOccurs="0" maxOccurs="unbounded"> |
There was a problem hiding this comment.
Not sure if it makes sense to expose Virtual call buttons like this. If they are dynamically created, there really is no list until the button is created?
Would a product have to expose a fake number of possible buttons?
There was a problem hiding this comment.
My point of view is that the device provides what is currently possible. If the user first needs to go on the webpage to create the button layout, then that's a prerequisite to use virtual buttons. Once the layout exists, then the options provide their reference tokens and a short description so that the user can make sense of it once part of the VMS.
This is one such compromise required to be able to have button configuration for a wide range of devices without having to pull/support a complex array of functions (ex: create/update/delete button layouts with screen displays, etc.)
| </xs:element> | ||
| </xs:sequence> | ||
| </xs:complexType> | ||
| <xs:complexType name="CallButtonOptions"> |
There was a problem hiding this comment.
Please make duplicate ButtonId semantics explicit: treat same ButtonId entries as one logical button group and either define mandatory call strategy + ordering/fallback + capability advertisement, or let behavior be up to vendor.
| <xs:documentation>Optional name of the server configuration.</xs:documentation> | ||
| </xs:annotation> | ||
| </xs:element> | ||
| <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <!-- first ONVIF then Vendor --> |
There was a problem hiding this comment.
Add extendability for attributes
| </xs:sequence> | ||
| </xs:complexType> | ||
| </xs:element> | ||
| <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <!-- first ONVIF then Vendor --> |
There was a problem hiding this comment.
Add extendability for attributes?
| <xs:documentation>Indicates whether the device shall automatically answer incoming calls.</xs:documentation> | ||
| </xs:annotation> | ||
| </xs:element> | ||
| <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> <!-- first ONVIF then Vendor --> |
There was a problem hiding this comment.
Add extendability for attributes?
| <xs:documentation>A button's description.</xs:documentation> | ||
| </xs:annotation> | ||
| </xs:element> | ||
| </xs:sequence> |
There was a problem hiding this comment.
Add extendability for elements and attributes?
6 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.