|
Hi, I have a question regarding Section 5 (Server Usage) of
RFC3263 that I am requesting your opinion on. IMHO, there appears to be an issue with server-side Via
header processing rules as currently specified in RFC 3263, when a Via header
of the received request sent-by address field has an SRV name (a port is not
specified on the header) and the SRV name resolves to non-default SIP ports. Section 5 of RFC3263 references section 18.2.2 of RFC3261, and
states that for unreliable transports, the initial response transmission sent
by a UAS should be attempted towards the source address of the received request
and the default destination port (5060) if none is specified in the Via header.
If this initial response encounters a failure and there wasn’t any port
specified in the Via, the UAS should resolve the domain name in the sent-by
field using SRV procedures, and the response should be sent to the address and
port selected based on that SRV query. My question is regarding the first step of the above
response processing logic. Since SRV lookups are performed on a domain-name only when
no port is specified, this obligates the sender of a request to not encode a
port in its Via header if that sender wishes to be reachable using SRV
resolution. Consequently, this appears to imply that the sender needs to be
listening for responses on the default SIP port in addition to any of the ports
resolved from the SRV query, since the first transmission of any incoming
response will always be directed towards the default port as per section 18.2.2
of RFC3261. As I understand it, based on how this rule is currently worded,
if none of the SRV resolutions of Via Sent-By domain-name resolve to port 5060 AND
if a UAC is not listening for responses on port 5060, the initial transmission
of every response will always encounter a failure before resorting to SRV
procedures. thanks, -Sachin |
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip