Due to the wide number of people attending this most recent
bakeoff, it is virtually assured that no-one got around to
testing with every implementation there. To that end, I'd
like to share some lessons learned from our interop tests.
These are't aimed at any teams in particular; I'm only
including issues I saw in at least two different implementations.
I guess most of these count as common pitfalls. Note that
these are subject to my interpretation of the draft,
and may not be absolutely correct; if you think I've
erred somewhere, please point it out.
1) There is some confusion between ceratain sets of status
codes. These are largely error codes, so the behavior
is usually okay if you mix them up; however, since the
spec goes through all the trouble of defining new codes,
it seems sensible to use them correctly.
- 408 vs 504
408 is to be used when a request cannot be completed in the
time specified in the "Expires" header.
504 is to be used when a proxy or other type of gateway
doesn't receive a response from a next-hop node.
- 480 vs 603
480 indicates that the user is, for some reason, unavailable.
This would be appropriate, for example, if a phone
is in a "do not disturb" mode.
603 means that the user you are trying to contact has been
reached, and has explicitly declined this particular
phone call. This would be appropriate if, for example,
your device/program displays the name of the caller,
and the called party presses a "reject" button.
486 vs 600
486 is a device busy state. This is what you normally think
of when you get a busy tone.
600 is a user busy state. There is no analogous situation in
today's telephony system. It means that you have
contacted the correct user, but he has indicated
that he will not take the call because he is busy.
It is completely inappropriate to return a 600 for a
device busy state, since it termintates outstanding
searches.
406 vs 415 vs 606
406 means that the called device cannot create SIP bodies
of the type indicated in the request's "Accept" header.
415 means that the body of the request (e.g. the type
specified in the "Content-Type" header) is of a
format that the server cannot understand.
606 means that you have contacted the correct user,
and that user has attempted to answer the call;
however, the device with which he answered is
incapable of participating in the session indicated
in the body of the message.
2) Many proxy implementations were doing overaggressive parsing.
While the performance implications of this don't affect
the other nodes in the network, the interoperability issues
it introduces do cause problems. In keeping with the
premise of "be strict in what you generate, but forgiving
in what you accept," I strongly recommend that you don't
validate fields unless you intend to use the information
contained in them.
For example, I found that several proxies validate the date
field in messages they are proxying, although the implementors
freely admit that they don't actually use the date for any
processing. The same goes for many other fields that most
proxies should not care about (e.g. To:, From:, Timestamp:, etc.).
Proxies are not supposed to be syntax police; they're supposed to
proxy messages.
If the far end node is capable of setting up a call based on the
information in the INVITE, it is just plain mean for an
intermediate proxy to stubbornly refuse to proxy the messages
just because he doesn't understand every tiny detail of
the messages. The real damage comes in when we try to add
extensions that, in theory, shouldn't involve any proxy extensions.
3) This is actually a disagreement I have with RFC2543, and
one that I raised some time ago; however, no one seemed
interested at the time. Since it actively prevented us from
running one of the test cases we wanted to run at this bakeoff,
I'm going to raise the issue again. Take discussion on this
topic to the SIP working group mailing list, please.
According to section 6.37, an implementation should reject
messages containing unknown URIs in the "To:" field with
a 400 response. Many implementations actually did this.
The test case we were attempting was as follows:
UAC1 ----> tel: mapping proxy -----> UAC2
UAC1 then sends a message to the tel: mapping proxy like:
INVITE tel:5551234 SIP/2.0
To: <tel:5551234>
From: <sip:bob@uac1>;tag=12345
Call-ID: fffff@uac1
CSeq: 7654 INVITE
Because the proxy mapped the request URI, the INVITE that
UAC2 received ends up looking like:
INVITE sip:5551234@uac2 SIP/2.0
To: <tel:5551234>
From: <sip:bob@uac1>;tag=12345
Call-ID: fffff@uac1
CSeq: 7654 INVITE
UAC2 definitely has quite enough information to service the
call. In fact, if not for this clause in 2543, the call would
be set up perfectly. I contend that clients shouldn't
care if they understand the URI in the To: field, as long
as they can process the call, and I encourage implementations
to exhibit this behavior.
This also follows naturally from what I suggested above: don't
validate fields unless you intend to use the information
contained in them.
4) SDP is still causing some problems. The most common problems
I'm seeing are still:
- failure to include a t= line
- inability to parse m= lines which include a port count; e.g.:
m=audio 5000/1 ATP/AVP 0
Also, something that was recently pointed out to me: SDP is
required to include at least one of a p= or e= line. On page
11 of RFC2327, it says:
"Either an email field or a phone field must be specified.
Additional email and phone fields are allowed."
--
Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[EMAIL PROTECTED] | Fax: +1 972 669 0154 | Richardson, TX 75081 USA
