Subject: Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package

From: Charles Shen <[email-masked]>
Date: Fri, 12 Oct 2012 12:43:53 -0400

HI Bruno,

So I am defining a "target-sip-entity" condition element parallel to the
"call-identity" elements as below. I think it should help in the situation
you mentioned, without adding too much complexity. I am making it optional,
unless people have strong opposite opinions.

   <!-- CONDITIONS -->

   <!-- TARGET SIP ENTITY -->
   <xs:element name="TARGET-SIP-ENTITY" type="xs:anyURI" minOccurs="0"/>

  <!-- CALL IDENTITY -->
  ...

Thanks

Charles

On Wed, Aug 1, 2012 at 10:56 AM, <[email-masked]> wrote:

> Hi Charles,
>
> "Route" may be a bit misleading as the matching should be performed on the
> identity or address obtained after applying RFC3263 procedures to the first
> value of the route header or to the R-URI rather than on the contents the
> route header as such.
>
> BC
>
>
> > -----Message d'origine-----
> > De : [email-masked] [mailto:[email-masked]] De la
> > part de Charles Shen
> > Envoyé : lundi 30 juillet 2012 05:07
> > À : CHATRAS Bruno RD-CORE
> > Cc : Salvatore Loreto; [email-masked]; Volker Hilt; Henning
> > Schulzrinne; Arata Koike
> > Objet : Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-
> > package
> >
> > Hi Bruno, sorry for the delayed response!
> >
> > I've updated the local number grouping text. For the multi-path
> > filtering policy problem, since it will affect texts in multiple
> > sections, I'd like to discuss a bit more in terms of the solution.
> >
> > Assuming the following scenario,
> >
> >                                      P3A
> > alice@p1 --- P1 --- P2 -- /       \ --- P4 --- bob@p4
> >                                     \      /
> >                                      P3B
> >
> > where P2 can reach bob through either P3A or P3B, the call identity in
> > the existing policy does not distinguish the calls to bob@p4 through
> > P3A from those through P3B. Therefore it would be good for the load
> > control
> > policy to include not only the call destination (e.g., bob@p4 in
> > this case), but also through which path the call is routed.
> >
> > One possible solution could be to add a new sub-element called
> > <route> under the existing <call-identity> schema. In the simple case,
> > the new <route> element can be of the same type as the <identity>
> > element in [RFC4745]. The contents of the <route> element holds what
> > you call target SIP entities.
> >
> > Using the same example above, server P1 may receive a policy
> > containing the new element as below:
> >
> > <call-identity>
> >     <sip>
> >         <to>
> >             <one id="sip:[email-masked]">
> >         </to>
> >         <route>
> >             <many domain="p2.example.com">
> >             <many domain="p3a.example.com">
> >             <many domain="p4.example.com">
> >         </route>
> >     </sip>
> > </call-identity>
> >
> >
> > Similarly server P2 may receive a policy containing the new element as
> > below:
> >
> > <call-identity>
> >     <sip>
> >         <to>
> >             <one id="sip:[email-masked]">
> >         </to>
> >         <route>
> >             <many domain="p3a.example.com">
> >             <many domain="p4.example.com">
> >         </route>
> >     </sip>
> > </call-identity>
> >
> >
> > Then the call filtering can match both the call destination and the
> > path (assuming either a SIP Route header is included, or a next hop
> > SIP server is chosen dynamically).
> >
> > There is still a small problem though - if the new <route> element is
> > defined as one of <identity> element in RFC4745, then the <many>
> > sub-elements under it are not ordered, while here we seem to need an
> > ordered list (as in the list of SIP Route headers). Therefore, we
> > might have to define new rules for the <route> element to make its
> > sub-elements ordered.
> >
> > Any thoughts?
> >
> > Charles
> >
> >
> >
> >
> >
> > On Tue, Jul 17, 2012 at 1:07 PM,  <[email-masked]> wrote:
> > > Hi Charles,
> > >
> > > See below.
> > >
> > >> -----Message d'origine-----
> > >> De : [email-masked] [mailto:[email-masked]] De
> > la
> > >> part de Charles Shen
> > >> Envoyé : mardi 17 juillet 2012 18:37
> > >> À : CHATRAS Bruno RD-CORE
> > >> Cc : Salvatore Loreto; [email-masked]; Volker Hilt; Henning
> > >> Schulzrinne; Arata Koike
> > >> Objet : Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-
> > >> package
> > >>
> > >> Hi Bruno, thank you so much for the detailed review and comments!
> > I've
> > >> addressed 8 out of the total 10, except the following two which I'd
> > >> appreciate more clarification.
> > >>
> > >> > 2) Section 5.8, line 525-528
> > >> >
> > >> > The current text suggests that incoming requests are filtered
> > >> irrespective of their actual destination. The subscriber should
> > rather
> > >> apply filters on requests that are outgoing to the pre-overloaded
> > >> destination. One solution would be to rephrase the following text:
> > >> >
> > >> > "A subscriber receiving the notification first installs these rules
> > >> and then filter incoming requests to enforce actions on appropriate
> > >> requests, for example, limiting the sending rate of call requests
> > >> destined for a specific SIP entity."
> > >> >
> > >> > With
> > >> >
> > >> > "A subscriber receiving the notification first installs these rules
> > >> and then filter outgoing requests towards the notifier to enforce
> > >> actions on appropriate requests, for example, limiting the sending
> > rate
> > >> of call requests destined for a specific SIP entity."
> > >> >
> > >> > This would however not permit the use of external state agents as
> > >> described in section 5.12. Therefore it seems that a "target sip
> > entity"
> > >> parameter should be added to overload control documents.
> > >> >
> > >>
> > >> I think I might have not understood your point. The requests are
> > >> filtered based on the call identities, which can convey information
> > >> including the call destination. Could you elaborate what this "target
> > >> sip entity" is exactly for?
> > > [BC]
> > >
> > > Let's take two examples that I think are not covered by the current
> > wording.
> > >
> > > 1) Example 1
> > >
> > > Call configuration: A is connected so SP1, B is connected to SP2. SP1
> > and SP2 are connected via SP3. SP3 is connected to an Application Server
> > (AS). Under normal load conditions, a call from A to B is routed along
> > the following path: A-SP1-SP3-AS-SP2-B. The AS provides a non-essential
> > service and can be bypassed in case of overload.
> > >
> > > Now let's assume that AS is overloaded and sends to SP3 a filter
> > requesting that 50% of INVITE messages be dropped, regardless of the
> > contents of the from/to/PAI/R-URI.
> > >
> > > According to the current wording, SP3 will indeed filter 50% of the
> > INVITE requests while they could be routed to B via SP2.
> > >
> > > 2) Example 2
> > >
> > > Call Configuration: An 800 translation service is installed on two
> > Application Servers AS-1 and AS-2. A is connected to SP1 and calls 800
> > 1234 4529, which is translated by AS-1 and AS-2 into a regular E164
> > number, depending on e.g. the caller's location. SP1 forwards INVITE
> > requests with R-URI = "800 number" to AS-1 or AS-2 based on a load
> > balancing strategy.
> > >
> > > As calls to 800 1234 4529 creates a pre-overload condition in AS-1,
> > AS-1 sends to SP-1 a filter requesting that 50% of calls towards 800
> > 1234 4529 be rejected.
> > >
> > > According to the current wording, SP3 will apply the filter on
> > incoming INVITE requests, irrespective of whether they are intended to
> > be sent to AS1 or AS2.
> > >
> > > ==> It seems that these use cases could be solved by applying the
> > filters to outgoing requests (not incoming requests) that are to be
> > routed to the AS that sent these filters. This means that the SP has to
> > store the AS address together with the received filters or this address
> > has to be included explicitly as a new filter criteria.
> > >
> > >>
> > >>
> > >> > 5) Section 6.3.1, local number grouping:
> > >> >
> > >> > The proposed solution for local numbers is not suitable. For
> > example,
> > >> if the phone-context for short service numbers in a country is the
> > >> country code, the solution does not permit to define a filter that
> > >> excludes all E.164 numbers in that country but retain all short
> > service
> > >> numbers. I think we should either define another solution or state
> > that
> > >> grouping of local numbers is not supported or state that grouping of
> > >> local numbers only works under specific assumptions on the use of
> > phone-
> > >> context values.
> > >> >
> > >>
> > >> How about adding the following text?
> > >>
> > >> It should be noted that the method of grouping local numbers as
> > >> defined in this document does not support all cases. For example, if
> > >> the phone-context for short service numbers in a country is the
> > >> country code, this solution does not permit to define a filter that
> > >> excludes all E.164 numbers in that country but retain all short
> > >> service numbers. A complete solution for local number grouping
> > >> requires a separate method outside the scope of this document.
> > > [BC]
> > >
> > > Looks OK for me.
> > >
> > >
> > >>
> > >>
> > >> Thanks!
> > >>
> > >> Charles
> > >>
> > >>
> > >> On Wed, Jul 11, 2012 at 3:33 AM,  <[email-masked]> wrote:
> > >> > Hi!
> > >> >
> > >> > Here are my comments about this I-D.
> > >> >
> > >> > 1) Section 4.3, move paragraph 7 (line 376 - 386) after paragraph 5
> > >> (i.e. after line 360) and modifies the first two sentences as follows:
> > >> >
> > >> > "In the above case, the network entity where load filtering policy
> > is
> > >> first introduced is the SIP server providing access to the resource
> > that
> > >> creates the overload condition. In other cases, the network entry
> > point
> > >> of load filtering policy could also be an entity that hosts this
> > >> resource. "
> > >> >
> > >> > 2) Section 5.8, line 525-528
> > >> >
> > >> > The current text suggests that incoming requests are filtered
> > >> irrespective of their actual destination. The subscriber should
> > rather
> > >> apply filters on requests that are outgoing to the pre-overloaded
> > >> destination. One solution would be to rephrase the following text:
> > >> >
> > >> > "A subscriber receiving the notification first installs these rules
> > >> and then filter incoming requests to enforce actions on appropriate
> > >> requests, for example, limiting the sending rate of call requests
> > >> destined for a specific SIP entity."
> > >> >
> > >> > With
> > >> >
> > >> > "A subscriber receiving the notification first installs these rules
> > >> and then filter outgoing requests towards the notifier to enforce
> > >> actions on appropriate requests, for example, limiting the sending
> > rate
> > >> of call requests destined for a specific SIP entity."
> > >> >
> > >> > This would however not permit the use of external state agents as
> > >> described in section 5.12. Therefore it seems that a "target sip
> > entity"
> > >> parameter should be added to overload control documents.
> > >> >
> > >> > 3) Section 5.8, add the following text (adapted from draft-ietf-
> > soc-
> > >> overload-control) after line 537:
> > >> >
> > >> > "When enforcing actions on requests matching the filters,
> > subscribers
> > >> SHOULD honor the local policy for prioritizing SIP requests such as
> > >> policies based on the content of the Resource-Priority header (RPH,
> > >> RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
> > >> indicate high priority requests that should be  preserved as much as
> > >> possible during overload.  The RPH contents can also indicate a low-
> > >> priority request that is eligible to be dropped during times of
> > overload.
> > >> Other indicators, such as the SOS URN [RFC5031] indicating an
> > emergency
> > >> request, may also be used for prioritization."
> > >> >
> > >> > 4) Section 6.3.1, matching identities: After line 699, add the
> > >> following text:
> > >> >
> > >> > "Before evaluating call-identity conditions, the subscriber shall
> > >> convert URIs received in SIP header fields in canonical form as per
> > RFC
> > >> 3261, except that the phone-context parameter shall not be removed,
> > if
> > >> present."
> > >> >
> > >> > 5) Section 6.3.1, local number grouping:
> > >> >
> > >> > The proposed solution for local numbers is not suitable. For
> > example,
> > >> if the phone-context for short service numbers in a country is the
> > >> country code, the solution does not permit to define a filter that
> > >> excludes all E.164 numbers in that country but retain all short
> > service
> > >> numbers. I think we should either define another solution or state
> > that
> > >> grouping of local numbers is not supported or state that grouping of
> > >> local numbers only works under specific assumptions on the use of
> > phone-
> > >> context values.
> > >> >
> > >> > 6) Section 6.3.1, line 746 - 753, remove the last but one sentence
> > and
> > >> reword the rest of the text accordingly. Reason: The use of local
> > number
> > >> 'tel' URI in the R-URI and To header field is not rare. In several
> > >> countries, short numbers are used quite extensively to access special
> > >> services.
> > >> >
> > >> > "Second, use of the local number 'tel' URI in practice is expected
> > to
> > >> be rare."
> > >> >
> > >> > 7) Clause 6.3.3, after line 800, add:
> > >> >
> > >> > "SUBSCRIBE requests are not filtered if the event-type header field
> > >> indicates the event package defined in this document."
> > >> >
> > >> > 8) Section 7, line 985 - 990: replace "call type" with "call
> > identity
> > >> type" (3 times)
> > >> >
> > >> > 9) Section 8.1
> > >> >
> > >> > Line 1048, add "except in specific cases when the Intelligent
> > Network
> > >> architecture is used [AINGR].
> > >> >
> > >> > Line 1060, remove the last part of the first sentence starting with
> > >> "and the number of prefix to be matched.": ITU IN specifications
> > allow
> > >> for dynamic sets.
> > >> >
> > >> > Line 1068, remove the last part of the first sentence staring with
> > >> "with a fixed set.": Reason: ITU IN specifications allow for dynamic
> > >> sets.
> > >> >
> > >> > 10)          Miscellaneous points
> > >> > Section 1, line 106, replace RFC3265 with RFC3261
> > >> > Section 4.1, line 231, replace "proxy" with "node" (this text
> > should
> > >> apply to any type of SIP entity)
> > >> > Section 4.3, line 265, replace "proxy" with "node" (this text
> > should
> > >> apply to any type of SIP entity)
> > >> > Section 4.3, Line 341, replace "singling" with "signaling"
> > >> > Section 4.3, Line 342, replace "all signaling relationship in
> > Figure 1
> > >> is" with "all signaling relationships in Figure 1 are"
> > >> > Section 5.6, Line 503, add "request" after "SUBSCRIBE"
> > >> > Section 5.11, Line 585, remove "is"
> > >> > Section 6.5, Line 851, replace "vliad" with "valid"
> > >> >
> > >> > Bruno
> > >> >
> > >> >
> > >> >> -----Message d'origine-----
> > >> >> De : [email-masked] [mailto:sip-overload-
> > >> [email-masked]]
> > >> >> De la part de Salvatore Loreto
> > >> >> Envoyé : lundi 2 juillet 2012 21:09
> > >> >> À : [email-masked]
> > >> >> Cc : Volker Hilt
> > >> >> Objet : [sip-overload] WGLC: draft-ietf-soc-oload-control-event-
> > >> package
> > >> >>
> > >> >> [as chair]
> > >> >>
> > >> >> based on the mailing list discussion and the one we had during the
> > >> last
> > >> >> SoC f2f meeting in Paris,
> > >> >> the chairs think the draft-ietf-soc-oload-control-event-package is
> > >> ready
> > >> >> for the WGLC.
> > >> >>
> > >> >> Today we are starting a two-week working group last call.
> > >> >> This call ends on Wednesday, July 16th.
> > >> >>
> > >> >> the last version of the document can be retrieved here:
> > >> >> http://tools.ietf.org/html/draft-ietf-soc-load-control-event-
> > package-
> > >> 03
> > >> >>
> > >> >>
> > >> >> reviews and comments are really appreciate and requested from all
> > the
> > >> >> participants
> > >> >>
> > >> >>
> > >> >> cheers
> > >> >> /Sal
> > >> >>
> > >> >> --
> > >> >> Salvatore Loreto, PhD
> > >> >> www.sloreto.com
> > >> >>
> > >> >> _______________________________________________
> > >> >> sip-overload mailing list
> > >> >> [email-masked]
> > >> >> https://www.ietf.org/mailman/listinfo/sip-overload
> > >> >
> > >> >
> > >>
> > ________________________________________________________________________
> > >> _________________________________________________
> > >> >
> > >> > Ce message et ses pieces jointes peuvent contenir des informations
> > >> confidentielles ou privilegiees et ne doivent donc
> > >> > pas etre diffuses, exploites ou copies sans autorisation. Si vous
> > avez
> > >> recu ce message par erreur, veuillez le signaler
> > >> > a l'expediteur et le detruire ainsi que les pieces jointes. Les
> > >> messages electroniques etant susceptibles d'alteration,
> > >> > France Telecom - Orange decline toute responsabilite si ce message
> > a
> > >> ete altere, deforme ou falsifie. Merci.
> > >> >
> > >> > This message and its attachments may contain confidential or
> > >> privileged information that may be protected by law;
> > >> > they should not be distributed, used or copied without
> > authorisation.
> > >> > If you have received this email in error, please notify the sender
> > and
> > >> delete this message and its attachments.
> > >> > As emails may be altered, France Telecom - Orange is not liable for
> > >> messages that have been modified, changed or falsified.
> > >> > Thank you.
> > >> >
> > >> > _______________________________________________
> > >> > sip-overload mailing list
> > >> > [email-masked]
> > >> > https://www.ietf.org/mailman/listinfo/sip-overload
> > >
> > >
> > ________________________________________________________________________
> > _________________________________________________
> > >
> > > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc
> > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> > recu ce message par erreur, veuillez le signaler
> > > a l'expediteur et le detruire ainsi que les pieces jointes. Les
> > messages electroniques etant susceptibles d'alteration,
> > > France Telecom - Orange decline toute responsabilite si ce message a
> > ete altere, deforme ou falsifie. Merci.
> > >
> > > This message and its attachments may contain confidential or
> > privileged information that may be protected by law;
> > > they should not be distributed, used or copied without authorisation.
> > > If you have received this email in error, please notify the sender and
> > delete this message and its attachments.
> > > As emails may be altered, France Telecom - Orange is not liable for
> > messages that have been modified, changed or falsified.
> > > Thank you.
> > >
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>