Subject: [Speermint] Extension negotiation in SIP Interconnect Guidelines

From: David Hancock <[email-masked]>
Date: Thu, 4 Mar 2010 22:13:14 -0700

During EITF#76 review of the SIP Interconnect Guidelines, the Extension Negotiation section was discussed, and specifically the sentence ...

    "The SBE MAY support configuration controls to disable
     certain extensions based on bilateral agreement between 
     peer networks. "

Here's a high-level summary of the discussion...

On the one hand, the above requirement is only a MAY, and therefore seems pretty benign. However, restricting the set of extensions supported on the interface has a downside -- it disables extension negotiation between endpoints, making it difficult to roll out new services. It would be preferable if the SSP network was transparent to extension negotiation, so if both endpoints in a call support a new extension they can use it. Conclusion of the discussion was that it's OK to leave the requirement in as long as text is added to identify the disadvantages of blocking transparent end-to-end extension negotiation.

Here's a proposed resolution of this issue...

The "MAY" requirement under discussion was included as a general requirement to cover a specific case where an operator wanted to disable the use of PRACK in their network because they deemed its value in terms of increased reliability wasn't warranted by the cost of the extra signaling traffic load. The majority of endpoints in the network supported PRACK, and would therefore include '100rel' in the Supported header of originating INVITEs. On receiving such an INVITE, most endpoints would in fact use PRACK. So the only way to turn it off was to remove '100rel' from the Supported header.  

Regarding the general requirement, a Service Provider can always choose to enforce a policy which limits extensions supported/used in their network. Whether and how they do it is really out-of-scope of the draft, and in that spirit maybe we should remove the requirement. However, since applying this kind of policy is fairly common practice, it would probably be a good idea to add a note pointing out the negative aspects of doing so (impedes deployment of new services, etc). Proposed text is shown below...

========= OLD TEXT BEGIN ==========================================

4.1.  Extension Negotiation

   It is RECOMMENDED that originating SBEs facing other peer networks be
   configured in such a way that they do not require any SIP extensions
   to be supported by the other end.  The SBE MUST identify all
   supported SIP extensions in the Supported header.  The SBE MAY
   support configuration controls to disable certain extensions based on
   bilateral agreement between peer networks.  For example, the SBE
   could be configured to remove '100rel' from the Supported header in
   order to disable the use of reliable provisional response (PRACK).

========= OLD TEXT END ==========================================

========= NEW TEXT BEGIN =======================================

4.1.  Extension Negotiation

   It is RECOMMENDED that originating SBEs facing other peer networks be
   configured in such a way that they do not require any SIP extensions
   to be supported by the other end. The SBE MUST identify all
   supported SIP extensions in the Supported header.  The SBE MAY
   support configuration controls to disable certain extensions based on
   bilateral agreement between peer networks.  For example, the SBE
   could be configured to remove '100rel' from the Supported header in
   order to disable the use of reliable provisional response (PRACK).

      Note: Policies that limit or block the use of SIP extensions 
      should be applied with care, since their application tends to
      disable SIP's native extension negotiation mechanism, and 
      therefore inhibit the deployment of new services. 

========= NEW TEXT END ==========================================

Comments welcome.

Thanks
David

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 5 Mar 2010 18:12:20 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Hancock
> Sent: 05 March 2010 05:13
> To: [email-masked]
> Subject: [Speermint] Extension negotiation in SIP 
> Interconnect Guidelines
> 
> 
> During EITF#76 review of the SIP Interconnect Guidelines, the 
> Extension Negotiation section was discussed, and specifically 
> the sentence ...
> 
> On the one hand, the above requirement is only a MAY, and 
> therefore seems pretty benign. However, restricting the set 
> of extensions supported on the interface has a downside -- it 
> disables extension negotiation between endpoints, making it 
> difficult to roll out new services. It would be preferable if 
> the SSP network was transparent to extension negotiation, so 
> if both endpoints in a call support a new extension they can 
> use it. Conclusion of the discussion was that it's OK to 
> leave the requirement in as long as text is added to identify 
> the disadvantages of blocking transparent end-to-end 
> extension negotiation.
> 
> The "MAY" requirement under discussion was included as a 
> general requirement to cover a specific case where an 
> operator wanted to disable the use of PRACK in their network 
> because they deemed its value in terms of increased 
> reliability wasn't warranted by the cost of the extra 
> signaling traffic load. The majority of endpoints in the 
> network supported PRACK, and would therefore include '100rel' 
> in the Supported header of originating INVITEs. On receiving 
> such an INVITE, most endpoints would in fact use PRACK. So 
> the only way to turn it off was to remove '100rel' from the 
> Supported header.  
> 
> Regarding the general requirement, a Service Provider can 
> always choose to enforce a policy which limits extensions 
> supported/used in their network. Whether and how they do it 
> is really out-of-scope of the draft, and in that spirit maybe 
> we should remove the requirement. However, since applying 
> this kind of policy is fairly common practice, it would 
> probably be a good idea to add a note pointing out the 
> negative aspects of doing so (impedes deployment of new 
> services, etc). Proposed text is shown below...
> 
>    supported SIP extensions in the Supported header.  
[JRE] I find this text problematic. Does it mean all SIP extensions supported by the SBE or all SIP extensions supported by the UA? The former is problematic because advertising support for something that the UA might not support is wrong. The latter is problematic because the SBE cannot know that a UA supports something if the UA doesn't include it in the Supported header field.

John

> The SBE MAY
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/speermint
>

---

From: David Hancock <[email-masked]>
Date: Fri, 5 Mar 2010 10:43:26 -0700

John,

Comments below...

David

> From: Elwell, John [mailto:[email-masked]]
> Sent: Friday, March 05, 2010 10:12 AM
> To: David Hancock; [email-masked]
> Subject: RE: Extension negotiation in SIP Interconnect Guidelines
> 
> 
> 
> [JRE] I find this text problematic. Does it mean all SIP extensions
> supported by the SBE or all SIP extensions supported by the UA? The former
> is problematic because advertising support for something that the UA might
> not support is wrong. The latter is problematic because the SBE cannot
> know that a UA supports something if the UA doesn't include it in the
> Supported header field.

[dch] This goes back to the discussion on what is the target entity of normative statements in this draft. It was a long time ago, but there was a discussion on the SPEERMINT list where we agreed to redefine the term "SBE" within the context of this draft to mean all the SIP entities in the SIP signaling chain that can affect the SIP/SDP peering interface. Here's the thread...

http://www.ietf.org/mail-archive/web/speermint/current/msg02606.html

In other words, within the scope of this draft, the SBE isn't the entity that sits at the egress/ingress point; rather it's the whole SSP network (similar to the model used in SIPconnect1.1).

Does this resolve your concern?

By the way, at IETF#76 discussion on this draft you pointed out that even with this new definition of SBE, there is a problem when the SIP signaling chain extends beyond the SSP network into some other network (in other words, the UA is not part of this redefined SBE, so how can the SBE ensure it meets the guidelines?). I think I need to address this concern, and will propose some text in a separate email.

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 12 Mar 2010 17:28:49 +0100

> From: David Hancock [mailto:[email-masked]] 
> Sent: 05 March 2010 17:43
> To: Elwell, John; [email-masked]
> > > ========= OLD TEXT BEGIN 
> ==========================================
> > >
> [dch] This goes back to the discussion on what is the target 
> entity of normative statements in this draft. It was a long 
> time ago, but there was a discussion on the SPEERMINT list 
> where we agreed to redefine the term "SBE" within the context 
> of this draft to mean all the SIP entities in the SIP 
> signaling chain that can affect the SIP/SDP peering 
> interface. Here's the thread...
> 
> In other words, within the scope of this draft, the SBE isn't 
> the entity that sits at the egress/ingress point; rather it's 
> the whole SSP network (similar to the model used in SIPconnect1.1).
> 
> By the way, at IETF#76 discussion on this draft you pointed 
> out that even with this new definition of SBE, there is a 
> problem when the SIP signaling chain extends beyond the SSP 
> network into some other network (in other words, the UA is 
> not part of this redefined SBE, so how can the SBE ensure it 
> meets the guidelines?). I think I need to address this 
> concern, and will propose some text in a separate email. 
[JRE] Yes, I have less of a problem with the SBE encompassing the whole of the SP's domain, but much more of a problem with it encompassing what is upstream of the SP's domain.

John