Subject: [sipcore] WGLC 4244bis-callflows 3.3

From: <[email-masked]>
Date: Thu, 18 Oct 2012 10:57:07 +0000

Section 3.3
MM#6: About Roland's comments 1): If the UAC (must) add a H-I when initiating a request, please note that H-I is missing in the initial request of examples 3.6, 3.7 and 3.11... IMO, the sentence in section 6.2 in the draft-4244bis needs to be more explicit:

"In the case of an initial request, except where the UAC is part of a B2BUA, there is no cache of hi- entries with which to populate the History-Info header field and the hi-index is set to 1 per Section 10.3. "

I think this sentence need to be change as following:

"In the case of an initial request, except where the UAC is part of a B2BUA, there is no cache of hi- entries with which to populate the History-Info header field, so the UAC populates the History-Info header field with the outgoing Request-URI and the hi-index is set to 1 per Section 10.3. "

My last question is: Is it really mandatory that the UAC inserts the H-I? A SHOULD/CAN/MUST would be welcomed.

Section 9.1 mentions the case where no H-I is received by a proxy: "If the Request-URI of the incoming request does not match the hi-targeted-to-uri in the last hi-entry (i.e., the previous SIP entity that sent the request did not include a History-Info header field), the SIP entity MUST add a hi-entry to end of the cache, on behalf of the previous SIP entity before proceeding to Section 9.2, as follows:"

IMO a MUST would be too strong because the case where the proxy add the received URI before the outgoing URI is described and because I think it is unrealistic to ask UAC to add a H-I.

MM#7: About Roland's comments 2): sections 3.3(F2) and 3.2(F2): I also think that the parameter should not be "rc" but "np" because the address remains unchanged. Even if it is certain for 3.3, for 3.2 I have a doubt because putting a "np" parameter (saying -it is the same-) to a visible identity pointing at the anonymized identity is a non sense... but it is the truth and this non sense exist because the anonymized address is not handled by the domain requesting privacy.

MM#8: About Roland's comments 3): I think UAS can receive H-I if no privacy is asked for the hi-entries or the global request. A number presentation service could propose to display the last retargeting user so that the final destination is able to know that the call was first intended to another target (and is not a direct call).

MM#9 About Roland's comments 4): Indeed, a different Privacy use case from 3.2 would be better because this one is too similar.

Best Regards,
Marianne

_________________________________________________________________________________________________________________________

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.