Christer Holmberg wrote:
I don't understand this "IETF SIP" versus "3GPP SIP" thing.
"3GPP SIP" is a SIP profile, including a number of SIP extensions, all
done in IETF. There is nothing which a non-3GPP entity can't use.
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.
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.
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.
/a
_______________________________________________
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