Hi,
Perhaps this thread is not worth continuing for long, so
please feel free to cut it down, but there are a few
remarks that I would like to make:
>Need something more clear-cut? Something you can apply empirically?
>Here's a litmus test for you: if the initial signaling between two
>network elements can't negotiate down to base SIP without any
>extensions, then it's no longer SIP.
What you say above implies that if there is a NAT between those two
network elements so that the communication between those can only
be established with help of rport extension, then the result is
no longer SIP.
Well ... you could start arguing that there are extensions and
extensions ... but the bottom line is that the simplicity of
the test is lost with any exceptions. Unfortunately the world
is a bit complex to fit simple rules.
>> What is "IETF SIP"? What do I have to implement in order to be "IETF
>> SIP" compliant? RFC3261? RFC3261 plus each and every extension out
>> there?
>>
>RFC 3261 plus proper negotiation of any extensions you choose to
>support. More emphatically: any behavior that is not in 3261 or its
>references needs to be explicitly negotiated before it is
>engaged. This applies to both clients and network servers.
Concept of dynamic negotiation is architecturally nice, but
unfortunately often undesirable in practical deployments.
The registration procedure between a full-fledged UA and a
typical SIP network deployment would look like this:
1. UA sends DHCPINFORM for SIP Option to find local SIP proxy
2. DCHP server answers that it has no value for SIP Option
3. UA sends OPTIONS request to SIP proxy resolved from the
host part of the AOR
4. Proxy responds to OPTIONS and tells e.g. that it does not
support sigcomp or sec-agree
5. UA sends REGISTER request without compression or requiring
sec-agree, containing Require: outbound
6. Registrar responds with 420 Bad extension, Unsupported: Outbound
7. UA sends REGISTER again after removing extensions which
the registrar did not support
8. Registrar responds with 401
9. UA sends REGISTER again with proper credentials
10. Reistrar responds with 200 OK
11. UA sends SUBCRIBE for reg-event
12. Network responds with 489 Bad Event (or in worst case loops
the SUBSCRIBE back to the UA as it contains the AOR of the
user as its Request-URI)
In practice the service provides most often do not want all
this to happen but instead would like to configure the UAs
to suppress any extensions which the deployment does not support.
>I said the bifurcation exists _in_ _the_ _market_. Did you follow the
>link I included? It's extraordinarily relevant. If you need more
>context: these are screenshots from the SIP account configuration
>screens on the Nokia E61:
>
><http://www.nostrum.com/~adam/images/too-late.png>
>
>We can argue over whether the split is real on the technical
>level (and there are several reasons that it is -- for
>example, using SigComp without proper signaling of the
>intention to do so ahead of time), but it's all a moot point:
>products are already being designed with two distinct modes of
>operation.
Having working at Nokia I can give some perspective to the
design of this UI. Even if the E61 product is relatively new
the concept of the split was created a few years ago when the
world looked polarized like this:
3GPP was promoting IMS as a SIP profile, mandating extensions
like RFC 3310 (HTTP Digest AKA), RFC 3327 (Path) RFC 3329 (sec-agree),
RFC 3455 (P-headers), RFC 3489 (Compressing SIP), RFC 3608 (service
route)
and RFC 3680 (reg-event). This is a whole bunch of things to be
implemented, but the behaviour of the environment was supposed
to be quite deterministic.
IETF was promoting a toolbox approach for SIP so that service
providers were able to deploy any combination of extensions.
In practice however most of the deployments supported minimum
amount of extensions and there was a requirement for the UA
to cope with such deployments with minimal amount of config
settings and minimum amount of dynamic negotiation.
Thus the design team ended up with two modes, one for each
environment to control whether or not certain extensions
would be applied. The modes mostly defined some default
values, which thereafter could be separately changed with
the UI, but usage of a few extensions was hardcoded by the
mode.
----
Whether that design was good or bad is another subject of
discussion but with the knowledge of today it is clear that
the "SIP" world is not polarized between IETF and 3GPP but
fragmented to a number of different environments like:
- Every SIP service provider tends to define their own SIP
profile which they wish the UAs to comply as close as possible
- Some providers even create their own proprietary extensions
(like Yahoo for authentication)
- "Cellular IMS" like the original 3GPP IMS
- "CableLabs IMS" promoting new NAT traveral techniques to IMS
- "Fixed Broadband IMS" of ETSI TISPAN style
- "Early IMS" implementations supporting just a subset
of extensions defined for 3GPP IMS
- and so on ...
Thus all this means that design of an SIP UA aiming to worldwide
coverage of different SIP-based deployments is an enormously
complex task. Autoconfiguration solutions would be highly
desirable to manage the complexity, but unfortunately for
that there is no unified solution: many VoIP providers
use TFTP or manual configuration while cellular IMS operators
may rely on factory settings, OMA Device Management or OMA Client
Provisioning and in IETF the SIP Configuration Framework is
still on drawing board ...
Having a world with one unified "SIP" approach is a nice
dream, but unfortunately the reality is already far from
that and there are only some weak signs of convergence :(
Regards,
Erkki
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
