RFC Errata

Errata Search

Source of RFC  
Summary Table Full Records

RFC 7044, "An Extension to the Session Initiation Protocol (SIP) for Request History Information", February 2014

Source of RFC: sipcore (rai)

Errata ID: 5014
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Dinoop Paloli
Date Reported: 2017-05-10

Section 9.1 and 10.3 says:


Ambiguity exists regarding the handling of missing history info entry

Section 9.1 says,
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 an hi-entry to the end of the cache on
behalf of the previous SIP entity

According to that, for example, if request is received with,
Request URI : sip:peter@example.com
and History info : <sip:bob@example.com>;index=1

Then processing entity has to add an history info in to cache on behalf of previous entity as,
History info : <sip:bob@example.com>;index=1

But in section 10.3 basic rules 6 states,
If the request clearly has a gap in the hi-entry
(i.e., the last hi-entry and Request-URI differ), the entity
adding an hi-entry MUST add a single index with a value of "0"
(i.e., the non negative integer zero) prior to adding the
appropriate index for the action to be taken. For example, if
the index of the last hi-entry in the request received was 1.1.2
and there was a missing hi-entry and the request was being
forwarded to the next hop, the resulting index will be

But as per 9.1 stated above, once an entity receive a request with missing history info
it has to add an entry to cache on behalf of previous one.
So referring the previous example the added index would be
And by applying the rule in 10.3, the index for the new request created by this entity would be not

Report New Errata

Advanced Search