Support customizing the transport protocol used for Via headers #1026
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows for transport protocols that are not based solely on
Transport.server
's URL scheme.This provides a path for eliminating the deprecated
UserAgentOptions.hackViaTcp
configuration option, as the transport options can now have{ headerProtocol: "TCP" }
in its place.This change is also useful when working with SIP endpoints that are behind a load balancer with SSL termination at the balancer. In that case, the transport protocol between the browser and the load balancer would use the SIPS/WSS/TLS protocol, but I believe the transport protocol indicated in the Via header would need to be SIP/WS/TCP when it reaches the SIP endpoints.
Potential Alternative
Instead of impacting
Transport.protocol
, I considered adding an alternateTransport.headerProtocol
property that would be referenced insetViaHeader
calls.However, the core
Transport.protocol
property states that it is formatted "as defined for the Via header sent-protocol transport", andTransport.protocol
is currently only referenced for the purposes ofsetViaHeader
calls, so I felt this would be redundant.