Add support for SIP configuration - #782
jflevesque-genetec wants to merge 27 commits into
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?
There was a problem hiding this comment.
Sips ensures end to end encryption, tls just ensures encryption between device and server. But its not really a transport, it is more of a policy thing.
Using sips:adress@domain instead of sip:adress@domain;transport=tls
Should fail if tls is not used all the way to destination.
Perhaps an EnforceSIPS boolean is better, but not sure if its needed or up to client to use sip: or sips: in uri?
There was a problem hiding this comment.
There are some settings to control the encryption within the StreamingConfiguration, specifically the SecureStreamingProtocolAlgorithm fields within the encoders. I believe this should be sufficient to cover both sips/tls use cases right?
Added transport for the SIP registrar Misc changes based on discussions or comments made from F2F
johado
left a comment
johado
left a comment
There was a problem hiding this comment.
Some inconsistencies to function arguments, sometimes optional, sometimes not.
johado
left a comment
johado
left a comment
There was a problem hiding this comment.
the references to relay should probably be changed to digital input,
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.