Hi,

>> 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>

I did follow the link. My question was not directly towards you. It was
a more generic question, because this IETF SIP versus 3GPP SIP thing
comes up quite often.

>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.

I think that SigComp is a special case. SigComp is needed when you
connect to IMS using certain access technologies (I don't think SigComp
is mandatory for all IMS access technologies), so you need to study what
the requirements are for those access technologies. It's not necessarily
something you negotiate in SIP - it's a "pre-condition".

>>> 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.

Just because you are able to negotiate it doesn't mean that you are able
to fulfill the requirements the operator has.

>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.

If that is true, everything would work with 3261, and we wouldn't need
any extensions...

There are reasons we have defined extensions, and way to require support
of them, and that is because they are needed in certain environements,
and for certain services, features and use-cases. That is nothing 3GPP
specific - anyone designing/deploying a SIP based network and services
may require certain extensions in order to make things work.

Regards,

Christer

 

_______________________________________________
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

Reply via email to