Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12

[<[e-mail]>]

Hi Vijay,

I realize that the relation between my question and 5.10.2 was a bit confusing. I had in mind the following scenario:

A SIP Client (Proxy or a B2BUA) receives a request from a UAC and has to forward it to an overloaded downstream server. This Proxy or B2BUA has received overloaded control feedback from the overloaded server. Because of that it has to reject some requests received from the upstream UAC (It could also send it to another destination but as mentioned in clause 5.10: "In many cases, however, it will need to reject these requests"). 

So my question is: Which SIP response to send in this case? I assume & "503 (Service Unavailable)" response without the Retry-After header would be appropriate but I did not find it explicitly stated in the document.

Regards,
Bruno



> -----Message d'origine-----
> De : Vijay K. Gurbani [mailto:[e-mail]]
> Envoyé : vendredi 22 mars 2013 16:27
> À : CHATRAS Bruno OLNC/OLN
> Cc : Salvatore Loreto; [e-mail]; Volker Hilt
> Objet : Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12
> 
> On 02/11/2013 02:59 AM, [e-mail] wrote:
> > I just have one comment:
> >
> > Section 5.10.2 says that the response sent by a SIP server to
> > non-participants clients in case of overload is a 503 without the
> > Retry-After header. I did not find any text about the response sent by
> > participating clients when they have to reject a request. I assume
> > they should send a 503 without the Retry-After header as well. I would
> > suggest adding the following sentence at the end of 5.10, after "it
> > will need to reject these requests": In such cases, the SIP client
> > shall reply to the requests with a 503 response without the Retry-After
> header.
> 
> Bruno: Sorry for the delay.  Catching up with pending email on SOC.
> 
> I had a look at Section 5.10.2 and Section 5.10 where you propose to add the
> above sentence.
> 
> S5.10 talks about a "SIP client" --- I am trying to figure out if we meant a
> UAC or a proxy.
> 
> If this is a proxy, then the behaviour of that is already enumerated in
> S5.10.2 using the same sentence you specify above.
> 
> If this is a UAC and it supports overload control, then it has already
> received overload control feedback from the downstream overloaded server.  It
> will act accordingly.
> 
> If this is a UAC and it does not support overload control, then it will simply
> wait for a final response from the downstream server.  The UAC, since it does
> not support overload control, will unfortunately keep sending requests
> downstream.
> 
> As such, I am not sure if we need to add anything at all.  But I am open to
> suggestions.
> 
> Thanks,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / [e-mail]
> Web:   http://ect.bell-labs.com/who/vkg/

_________________________________________________________________________________________________________________________

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.