transport
Click on the red underlined text to get to the source
... proxy 1 specifically needs to determine the IP
address, port, and transport protocol for the server in domain B.
The choice of transport protocol ...
... transport protocol for the server in domain B.
The choice of transport protocol is particularly noteworthy. Unlike
many other protocols, SIP can run over a variety of transport
protocols ...
... transport protocol is particularly noteworthy. Unlike
many other protocols, SIP can run over a variety of transport
protocols, including TCP, UDP, and SCTP ...
... TCP only. Thus, clients need to
be able to automatically determine which transport protocols are
available. The proxy sending the request has a particular set of
...
... available. The proxy sending the request has a particular set of
transport protocols it supports and a preference for using those
transport protocols. Proxy ...
... transport protocols it supports and a preference for using those
transport protocols. Proxy 2 has its own set of transport protocols
...
... transport protocols. Proxy 2 has its own set of transport protocols
it supports, and relative preferences for those transport protocols.
...
... Proxy 2 has its own set of transport protocols
it supports, and relative preferences for those transport protocols.
All proxies must implement both UDP ...
... DNS procedures are needed for proxy 1 to discover the available
transport protocols for SIP services at domain ...
... services at domain B, and the relative
preferences of those transport protocols. Proxy 1 intersects its
list of supported transport protocols ...
... transport protocols. Proxy 1 intersects its
list of supported transport protocols with those of proxy 2 and then
chooses the protocol preferred by proxy ...
... determine the IP address, port, and transport of the host to which
the request is to be sent.
...
... Selecting a Transport Protocol ...
...
If the URI specifies a transport protocol in the transport parameter,
that transport protocol ...
... If the URI specifies a transport protocol in the transport parameter,
that transport protocol SHOULD be used.
...
... transport protocol in the transport parameter,
that transport protocol SHOULD be used.
Otherwise, if no transport protocol ...
... transport protocol SHOULD be used.
Otherwise, if no transport protocol is specified, but the TARGET is a
numeric IP address ...
... TCP
for a SIPS URI. Similarly, if no transport protocol is specified,
and the TARGET is not numeric, but an explicit port ...
... SIPS URI. This is
because UDP is the only mandatory transport in RFC 2543(-> 3265prop | 3264prop | 3263prop | 3262prop | 3261prop) [6], and thus
...
... the only one guaranteed to be interoperable for a SIP URI. It was
also specified as the default transport in RFC 2543(-> 3265prop | 3264prop | 3263prop | 3262prop | 3261prop) when no transport
...
... also specified as the default transport in RFC 2543(-> 3265prop | 3264prop | 3263prop | 3262prop | 3261prop) when no transport
was present in the SIP URI. However, another transport ...
... transport
was present in the SIP URI. However, another transport, such as TCP,
MAY be used if the guidelines of SIP ...
... URI. The services relevant for the task
of transport protocol selection are those with NAPTR service fields
...
... with values "SIP+D2X" and "SIPS+D2X", where X is a letter that
corresponds to a transport protocol supported by the domain. This
specification defines D2U for UDP ...
... domain to the SRV record
for contacting a server with the specific transport protocol in the
NAPTR services ...
... regular expression and a replacement value, which is the SRV record
for that particular transport protocol. If the server supports
multiple transport protocols, there will be multiple NAPTR records ...
... for that particular transport protocol. If the server supports
multiple transport protocols, there will be multiple NAPTR records,
each with a different service ...
... a resolution service whose value is not "D2X", for values of X that
indicate transport protocols supported by the client. The NAPTR
...
... processing as described in RFC 2915(-> 3404prop | 3403prop | 3402prop | 3401) will result in the discovery of
the most preferred transport protocol of the server that is supported
by the client, as well as an SRV record ...
... URIs and
"_sips" for SIPS URIs. A particular transport is supported if the
query is successful. The client ...
... query is successful. The client MAY use any transport protocol it
desires which is supported by the server.
...
... lookup SRV records for all transports it supported, and merge the
priority values across those records. Then, it would choose the
...
... SIPS
URI, and UDP for a SIP URI. However, another transport protocol,
such as TCP, MAY be used if the guidelines of SIP ...
...
Once the transport protocol has been determined, the next step is to
determine the IP address and port ...
... port is
specified, it uses the default port for the particular transport
protocol.
If the TARGET ...
... be contacted at the specific port from the URI and transport protocol
determined previously. The client ...
... from the NAPTR processing of Section 4.1, if such processing was
performed. If it was not, because a transport was specified
explicitly, the client performs an SRV ...
... service
identifier "_sips" for that specific transport, otherwise, it uses
"_sip". If the NAPTR processing was not done because no NAPTR
records ...
... NAPTR
records were found, but an SRV query for a supported transport
protocol was successful, those SRV records are selected. Irregardless
of how the SRV records ...
... lookup of the domain name. The result will be a list of IP
addresses, each of which can be contacted using the transport
protocol determined previously, at the default port for that
transport ...
... transport
protocol determined previously, at the default port for that
transport. Processing then proceeds as described above for an
explicit port once the A or AAAA records ...
... layer reports a
503 error response or a transport failure of some sort (generally,
due to fatal ICMP errors in UDP ...
... port contained in the Via header. For reliable
transport protocols, the response is sent over the connection the
request arrived on. However, it is important to provide failover
...
... 1], will send a response on the
connection it arrived on (in the case of reliable transport
protocols), and for unreliable transport protocols, to the source
address of the request, and the port ...
... connection it arrived on (in the case of reliable transport
protocols), and for unreliable transport protocols, to the source
address of the request, and the port in the Via header field ...
... detailed in RFC 3261prop). "Fails" is defined as any closure of the
transport connection the request came in on before the response can
be sent, or communication of a fatal error from the transport layer ...
... transport connection the request came in on before the response can
be sent, or communication of a fatal error from the transport layer.
In these cases, the server examines the value of the sent-by
...
... IP
address, the server attempts to send the response to that address,
using the transport protocol from the Via header, and the port from
...
... header, and the port from
sent-by, if present, else the default for that transport protocol.
The transport protocol in the Via header ...
... sent-by, if present, else the default for that transport protocol.
The transport protocol in the Via header can indicate "TLS", which
...
... IP addresses, using the port from the Via, and the transport protocol
from the Via (again, a value of TLS refers to TLS ...
... service identifier "_sips" if the Via transport is "TLS", "_sip"
otherwise, and the transport ...
... records, resulting in a client using a non-secure transport when TLS
is in fact available and preferred.
...
... The Transport Determination Application ...
... NAPTR record for specific resolution services. This application
is called the Transport Determination Application, and its goal is to
map an incoming SIP or SIPS URI ...
... NAPTR records described here requires well known values
for the service fields for each transport supported by SIP. The
table of mappings from service field ...
... SIP. The
table of mappings from service field values to transport protocols is
to be maintained by IANA. New entries in the table MAY be added
...
... Service Field: The service field being registered. An example for
a new fictitious transport protocol called NCTP might be
"SIP+D2N".
...
... SIP+D2N".
Protocol: The specific transport protocol associated with that
service field. This MUST include the name and acronym ...
... acronym for the
protocol, along with reference to a document that describes the
transport protocol. For example - "New Connectionless
Transport Protocol (NCTP), RFC ".
...
... protocol, along with reference to a document that describes the
transport protocol. For example - "New Connectionless
Transport Protocol (NCTP), RFC ".
...