Columbia VoIP Testbed

Overview

Architecture

SIP End Clients

Interoperability

 

 

 

   Home   |   Issues   1   2   3   4   5   6   |   Robustness Tests   |

 

Issue #4: Different levels of support for DNS queries

 

Category

Incomplete implementation of the specification

 

Description

RFC 3263 proposes DNS procedures that allow a client to resolve a SIP Uniform Resource Identifier (URI) to the IP address, port, and transport protocol of the next hop to contact.  A high percentage of UAs support only DNS A query, few others have DNS SRV as an advanced feature (which needs to be configured manually), and very few have all of A, SRV and NAPTR queries by default.

 

Implications

This difference in support for DNS queries could lead to situations where two UAs select different transport protocols (e.g., TCP rather than UDP) for the same next hop server (registrars or proxies).  While this behavior should have no problem in theory, in practice we have seen that SIP signaling over TCP generally failing in a multi-vendor environment.

 

 

Instance #1

Eyebeam and Cisco 7960 select TCP and UDP transport protocols respectively, when registering to Sipphone server.

 

Packet traces / Call-flows

Eyebeam registration

Cisco 7960 registration

 

Fixes / Workarounds

None.

 

References

1. RFC 3263: SIP: Locating SIP Servers (www.ietf.org/rfc/rfc3263.txt)