Re: More on SIP hard phones

[Andrew Rutherford <>]

At 1:26 PM -0400 8/10/03, Ben Teitelbaum wrote:

> Are we talking about a matrix of {phones} X {proxies} or list of SIP
> gear or all sorts, or what?  Would the content be based on anecdotal
> reports, official vendor claims, or formal interop testing?

Unfortunately it's not always quite that easy. Often the problems are 
end-device to end-device, but the proxy server can try and mitigate 
the issues.

Classic case: When using G.729, Cisco IOS devices advertise the codec as:

        a=rtpmap:18 G729/8000
        a=fmtp:18 annexb=no

But if Cisco's 79[46]0 phones receive this in an INVITE, and there is 
a lower codec in the list, they ignore the G.729 codec and fall 
through to the lower codecs unless the proxy server removes either 
the "fmtp" line or the lower codecs, in which case the phone will 
quite happily accept G.729.

(Yes, preferred_codec is set to "none", if anyone else is familiar 
with that fix for standards breaches in those phones.)

Quite often we see proxy servers trying to fix up things so 
implementations can talk to each other. Other common ones include 
changing loose source routing (RFC 3261) to strict source routing 
(RFC 2543) for devices that will reject inbound calls if the newer 
form of routing is used, such as the ubiquitous Windows XP Instant 
Messenger.

So the matrix could actually be {phones} X {proxies} X {phones}, 
which isn't fun to represent. I'd suggest instead doing {phones} X 
{phones}, specifying "yes", "with fixups A, B, and C", or "no", and 
then listing the proxies with what fixups they do.

There's also another class of issues when the chain gets four devices 
long instead of the typical LAN environment of three - that is, phone 
talks to local proxy server, which talks to target proxy server, 
which talks to target phone - the typical long-distance environment.

We see all kinds of fun things when one proxy server uses strict 
routing and the other uses loose routing, and one of the devices in 
the chain doesn't handle the mix right and tries to route to the 
second device (which it can't reach because of security policy) 
instead of the first. In one case, a lab test was done and they 
didn't pick it - the INVITE and 200 worked, but the ACK didn't get 
through after the media stream was set up - so the phone timed out 
the call on not getting the ACK after 30 seconds - but none of their 
test calls went to 30 seconds so they never noticed it. :-(

--
Andrew Rutherford      
sip:
      244 Pirie Street
Iagu Networks          tel:+61-8-8425-2255       Adelaide SA 5000
http://www.iagu.net/   
mailto:
   Australia

---------------------------------------------------------------wg-voip-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

---------------------------------------------------------------wg-voip--