Subject: [sipcore] RFC 7044 issues

From: Jörgen Axell <[email-masked]>
Date: Fri, 5 Dec 2014 12:51:42 +0000

Hello,

I am having some difficulty when reading RFC 7044. Is it mandated that a SIP entity supporting History-Info always inserts a hi-entry? As an example, in IMS there is an application server handling a diversion service on behalf of UE-B. For communication forwarding busy, we would have a simplified flow as below. Is the hi-entry with the np-parameter mandated by RFC 7044? If so, would it be allowed to have index set to 1.1.1 instead of 1.2 for the diverted INVITE to UE-C?

UE-A                                           AS-B                                         UE-B                            UE-C
---------------INVITE UE-B---->
                         History-Info:<URI-B>;index=1
                                                          INVITE UE-B--------------->
                                                          History-Info: :<URI-B>;index=1,
                                                                                      <URI-B>;index=1.1,np=1
                                                           <-----------------486 (Busy)
                                                          INVITE UE-C--------------------------------------->
                                                          History-Info:<URI-B>;index=1,
                                                                                    <URI-B>;Reason:sip; cause=486;index=1.1,np=1
                                                                                    <URI-C;cause=486>;index=1.2,mp=1.1

Another issue with the RFC is rule 2 in section 10.3. In particular the text "as prescribed for basic forwarding" is confusing as basic forwarding is not defined anywhere. I suspect this text is a remnant from rule 1 in section 4.3.3.1.3 in RFC 4244 which used Basic Forwarding in a more defining manner. My guess is that the "basic forwarding" text in RFC 7044 should be a reference pointing to the text just above the rules in section 10.3. Can anyone confirm?

Regards,
Jörgen

Dr. JÖRGEN AXELL
Senior specialist
Business Unit Cloud and IP

Ericsson
Kistavägen 25
164 80 Stockholm, Sweden
Phone +46 10 719 4450
Mobile +46 70 519 4450
[email-masked]
www.ericsson.com

Legal entity: Ericsson AB, registered office in Kista. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 10 Dec 2014 18:45:06 +0900

Hi,

>I am having some difficulty when reading RFC 7044. Is it mandated that a SIP 
>entity supporting History-Info always inserts a hi-entry?

9.2.  Sending a Request with History-Info
   When sending a request, a SIP entity MUST include all the hi-entries
   from the cache that was created per Section 9.1.  In addition, the
   SIP entity MUST add a new hi-entry to the outgoing request, but the

as mentioned above, a SIP entity MUST add a new hi-entry.

> As an example, in 
>IMS there is an application server handling a diversion service on behalf of 
>UE-B. For communication forwarding busy, we would have a simplified flow as 
>below. Is the hi-entry with the np-parameter mandated by RFC 7044?

9.2.  Sending a Request with History-Info
   rc/mp/np:  The SIP entity MUST include an "rc", "mp", or "np" header
      field parameter in the hi-entry, if applicable, per the procedures
      in Section 10.4.

as mentioned above, an application server MUST include a hi-target-param
in the hi-entry.

> If so, 
>would it be allowed to have index set to 1.1.1 instead of 1.2 for the 
>diverted INVITE to UE-C?

10.3.  Indexing in the History-Info Header Field
   Each dot
   reflects a SIP forwarding hop.  The nonnegative integer following
   each dot reflects the order in which a request was retargeted at the
   hop.

each dot means a SIP proxy and hi-indices describe a request's forwarding path.
therefore 3rd hi-index MUST be 1.2.
But whether the mp-param is 1.1 or 1 depends on an implementation of AS.

Shinji

>                           INVITE UE-B-------------------->
>                           <---------------------486 (Busy)
>                           INVITE UE-C-------------------------------->
>Another issue with the RFC is rule 2 in section 10.3. In particular the text 
>"as prescribed for basic forwarding" is confusing as basic forwarding is not 
>defined anywhere. I suspect this text is a remnant from rule 1 in section 4.3.
>3.1.3 in RFC 4244 which used Basic Forwarding in a more defining manner. My 
>guess is that the "basic forwarding" text in RFC 7044 should be a reference 
>pointing to the text just above the rules in section 10.3. Can anyone 
>confirm?

---
このEメールはアバスト アンチウイルスによりウイルススキャンされています。
http://www.avast.com

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 10 Dec 2014 11:14:51 -0500

Jörgen Axell <[email-masked]> writes:
> I am having some difficulty when reading RFC 7044. Is it mandated that
> a SIP entity supporting History-Info always inserts a hi-entry?

Yes -- Inserting hi-entry is what is meant by "supporting History-Info".

> If so, would it be allowed to have index set to
> 1.1.1 instead of 1.2 for the diverted INVITE to UE-C?

No, 1.2 is required, because "INVITE UE-C" is a fork of the first
"INVITE UE-B".  The index values mirror the sets of Via headers, which
I have inserted below.  The second and third requests copy the Via
headers of the first request, hence their index values are the index
value of the first request, with one more integer appended.

> ---------------INVITE UE-B---->
                 Via: SIP/2.0/UDP UE-A;branch=z9hG4bKnashds8
>                                                INVITE UE-B--------------->
                                                 Via: SIP/2.0/UDP UE-B;branch=z9hG4bK77ef4c2312983.1
                                                 Via: SIP/2.0/UDP UE-A;branch=z9hG4bKnashds8
>                                                INVITE UE-C--------------------------------------->
                                                 Via: SIP/2.0/UDP UE-B;branch=z9hG4bK77ef4c2312543.23
                                                 Via: SIP/2.0/UDP UE-A;branch=z9hG4bKnashds8
>                                                             <URI-B>;Reason:sip; cause=486;index=1.1,np=1
Of course, the previous entry should be: <URI-B?Reason=SIP%3Bcause%3D486>;index=1.1,np=1,
>                                                             <URI-C;cause=486>;index=1.2,mp=1.1

Dale

---

From: <[email-masked]>
Date: Thu, 11 Dec 2014 08:53:59 +0000

Hi,

> Is it mandated that a SIP entity supporting History-Info always inserts a hi-entry?
Yes

> If so, would it be allowed to have index set to 1.1.1 instead of 1.2 for the diverted INVITE to UE-C?

Yes, IMO a new ".1" level is adapted to this situation for the following reasons:
a) It is a clear application of the RFC4244 Basic Forwarding rule which recommends a new index level in case of forwarding and for backward compatibility reasons... 
b) UE-C is not a fork of UE-B, it is a clear different target that is not under AS-B's responsibility. Outgoing leg from AS-B towards UE-C is an originating-CDIV leg. Then, it is a forwarding hop and the text to be applied from RFC7044 is "For each forward hop (i.e., each new level of indexing), the last integers of the hi-indexes of the new requests MUST be generated starting at 1 and incrementing by 1 for each additional request." 

BR,
Marianne

De : sipcore [mailto:[email-masked]] De la part de Jörgen Axell
Envoyé : vendredi 5 décembre 2014 13:52
À : [email-masked]
Objet : [sipcore] RFC 7044 issues

Hello,

UE-A                                           AS-B                                         UE-B                            UE-C

Regards,
Jörgen

Dr. JÖRGEN AXELL
Senior specialist 

Ericsson
Kistavägen 25
164 80 Stockholm, Sweden
Phone +46 10 719 4450
Mobile +46 70 519 4450

Legal entity: Ericsson AB, registered office in Kista. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer 

_________________________________________________________________________________________________________________________

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 12 Dec 2014 14:06:18 +0900

Hi,

>a) It is a clear application of the RFC4244 Basic Forwarding rule which 
>recommends a new index level in case of forwarding and for backward 
>compatibility reasons... 
>b) UE-C is not a fork of UE-B, it is a clear different target that is not 
>under AS-B's responsibility. Outgoing leg from AS-B towards UE-C is an 
>originating-CDIV leg. Then, it is a forwarding hop and the text to be applied 
>from RFC7044 is "For each forward hop (i.e., each new level of indexing), the 
>last integers of the hi-indexes of the new requests MUST be generated 
>starting at 1 and incrementing by 1 for each additional request." 

This scenario is a sequential fork, and indexing by RFC7044 doesn't differ much from RFC4244.
plz confirm Appendix A of RFC4244.
http://tools.ietf.org/html/rfc4244#appendix-A

shinji

---

From: <[email-masked]>
Date: Fri, 12 Dec 2014 09:33:54 +0000

Hi Shinji,

My answer inline [MM]

BR,
Marianne

-----Message d'origine-----
De : OKUMURA Shinji [mailto:[email-masked]] 
Envoyé : vendredi 12 décembre 2014 06:06
À : [email-masked]
Cc : MOHALI Marianne IMT/OLN; Jörgen Axell
Objet : Re: [sipcore] RFC 7044 issues

Hi,

>Yes, IMO a new ".1" level is adapted to this situation for the 
>following
>reasons:
>b) UE-C is not a fork of UE-B, it is a clear different target that is 
>not under AS-B's responsibility. Outgoing leg from AS-B towards UE-C is 
>an originating-CDIV leg. Then, it is a forwarding hop and the text to 
>be applied from RFC7044 is "For each forward hop (i.e., each new level 
>of indexing), the last integers of the hi-indexes of the new requests 
>MUST be generated starting at 1 and incrementing by 1 for each additional request."

[MM] This scenario (with an AS) is a basic forwarding rule from RFC4244 which is mentioned but no longer described in RFC7044 (as Jörgen pointed):
[MM] [1. Basic Forwarding:  In the case of a Request that is being forwarded, the index is determined by adding another level of indexing since the depth/length of the branch is increasing. 	To accomplish this, the proxy reads the value from the History-Info header in the received request, if available, and adds another level of indexing by appending the dot delimiter 	followed by an initial index for the new level RECOMMENDED to be 1. For example, if the index in the last History-Info header field in the received request is 1.1, this proxy would 	initialize its index to 1.1.1 and forward the request.]
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 12 Dec 2014 19:11:09 +0900

Hi Marianne,

IIUC this scenario is not "1. Basic Forwarding" but "4. Retargeting based upon a Response".

>[MM] This scenario (with an AS) is a basic forwarding rule from RFC4244 which 
>is mentioned but no longer described in RFC7044 (as Jörgen pointed):
>[MM] [1. Basic Forwarding:  In the case of a Request that is being forwarded, 
>the index is determined by adding another level of indexing since the depth/
>length of the branch is increasing. 	To accomplish this, the proxy reads 
>the value from the History-Info header in the received request, if available, 
>and adds another level of indexing by appending the dot delimiter 	followed 
>by an initial index for the new level RECOMMENDED to be 1. For example, if 
>the index in the last History-Info header field in the received request is 1.
>1, this proxy would 	initialize its index to 1.1.1 and forward the 
>request.]

---

From: <[email-masked]>
Date: Fri, 12 Dec 2014 11:11:20 +0000

I would say that this scenario is a basic forwarding based upon a response :-) 
In the call forwarding busy example presented by Jörgen, it couldn't be only considered that the call forwarding is due to the SIP response 486. In the signaling path there is an AS that decided to do the retargeting after some checking, adds a new hi-entry with the cause URI parameter, a privacy... It is more the rule 2 of RFC7044 to be applied "Retargeting within a processing entity - first instance: For the first instance of retargeting within a processing entity, the SIP entity MUST calculate the hi-index as prescribed for basic forwarding." 

However, I agree that it is not clear which rule should be applied when both can be considered (rules 2 and 4). 

BR,
Marianne

-----Message d'origine-----
De : OKUMURA Shinji [mailto:[email-masked]] 
Envoyé : vendredi 12 décembre 2014 11:11
À : [email-masked]
Cc : MOHALI Marianne IMT/OLN; Jörgen Axell
Objet : RE: [sipcore] RFC 7044 issues

Hi Marianne,

>De : OKUMURA Shinji [mailto:[email-masked]] Envoyé : vendredi 12 
>décembre 2014 06:06 À : [email-masked] Cc : MOHALI Marianne IMT/OLN; 
>Jörgen Axell Objet : Re: [sipcore] RFC 7044 issues
>
>Hi,
>
>>a) It is a clear application of the RFC4244 Basic Forwarding rule 
>>which recommends a new index level in case of forwarding and for 
>>backward compatibility reasons...
>>not under AS-B's responsibility. Outgoing leg from AS-B towards UE-C 
>>is an originating-CDIV leg. Then, it is a forwarding hop and the text 
>>to be applied from RFC7044 is "For each forward hop (i.e., each new 
>>level of indexing), the last integers of the hi-indexes of the new 
>>requests MUST be generated starting at 1 and incrementing by 1 for 
>>each additional request."
>
>[MM] This scenario (with an AS) is a basic forwarding rule from RFC4244 
>which is mentioned but no longer described in RFC7044 (as Jörgen pointed):
>[MM] [1. Basic Forwarding:  In the case of a Request that is being 
>forwarded, the index is determined by adding another level of indexing since the depth/
>by an initial index for the new level RECOMMENDED to be 1. For example, 
>if the index in the last History-Info header field in the received request is 1.