klaus++

Alle die mit uns auf Kaperfahrt fahren, müssen Männer mit Bärten sein. Jan und Hein und Klaas und Pit, die haben Bärte, die haben Bärte. Jan und Hein und Klaas und Pit, die haben Bärte, die fahren mit.

  • An Introduction to the SIP Diversion Header
    https://andrewjprokop.wordpress.com/2014/09/22/an-introduction-to-the-sip-diversion-header

    The SIP Diversion Header

    RFC 5806 defines SIP diversion as follows:

    A change to the ultimate destination endpoint of a request. A change in the Request-URI of a request that was not caused by a routing decision. This is also sometimes called a deflection or redirection.
    A diversion can occur when the “user” portion of the Request-URI is changed for a reason other than expansion or translation.
    A diversion can occur when only the “host” portion of the Request-URI has changed if the change was due to a non-routing decision.

    This usually boils down to the scenario where A calls B and A is redirected (not transferred) to C.

    Imagine Sarah setting call forward on her SIP telephone to send all incoming calls to Debbie. Now, when Andrew calls Sarah, his call will be automatically sent to Debbie. Debbie’s SIP telephone will know that the call was diverted by the presence of a Diversion header in the INVITE request she receives from Andrew.

    Who inserted the Diversion header? It won’t be Andrew since he is unaware of the state of Sarah’s telephone. It won’t be Sarah since her telephone never saw Andrew’s call. It certainly can’t be Debbie since it’s her telephone that is ringing. This means that it must be something between Andrew and Debbie.

    That something will be some form of a Back-to-Back User Agent (B2BUA) and in most cases it will be a SIP proxy that is aware of the forward conditions of the endpoints it serves. The Diversion header will be added by the proxy when it sees Andrew’s INVITE to Sarah. That altered INVITE will then be proxied to Debbie.

    You can read all about B2BUAs in my article, The Back to Back User Agent (B2BUA).

    In my example, I stated that Sarah’s telephone was forwarded to Debbie. Of course, there are a number of different call forward conditions. In the SIP world, these are designated as diversion-reasons with the following permissible values:

    unknown
    user-busy
    no-answer
    unavailable
    unconditional
    time-of-day
    do-not-disturb
    deflection
    follow-me
    out-of-service
    away

    Additionally, a Diversion header supports three other parameters:

    counter: This contains the total number of diversions that have occurred.
    screened: This indicates if the diversion number is user provided (“no”) or network provided (“yes”).
    privacy: Certain conditions require that the diversion information be encrypted. This parameter shows how privacy has been applied.

    The following is an example of a fully populated Diversion header:

    Diversion: <sip:2000@192.168.254.254>;privacy=off;reason=no-answer;counter=1;screen=no

    Anyone receiving an INVITE with this header knows that 2000 was the originally called number, no privacy was applied, the call was forwarded due to a no answer condition, this is the only diversion, and the diversion number was user provided.

    A single INVITE may contain multiple Diversion headers. Those headers are ordered such that the last or most recent diversion is at the top of the list and all subsequent diversions are below it.
    Making SIP Trunks Happy

    In the past, I have encountered situations that required a Diversion header that had nothing to do with call forwarding. The most common is when you need to call out through a carrier SIP trunk and the From header in the INVITE contains a number not provisioned by the carrier. The carrier would look at the From value, not recognize it, and subsequently reject the call. In some cases, a Diversion header can be used to provide the carrier with a number that it does recognize.

    The reasons why the carrier might reject the call are varied, but the most common one I’ve encountered is that carriers need to see a number in its pool of DIDs to properly handle 9-1-1 calls. The value in the Diversion header can be used to satisfy that requirement.
    Mischief Managed

    This article was meant to be an introduction to the Diversion header and I hope that I accomplished that. You are more than welcome to dig through the SIP RFCs for a deeper explanation, but for most of you that won’t be necessary.

    Happy diverting!

    #VoIP #SIP #téléphone