#658 restore_uri not working properly for To: address in BYE message

Tom van der Geer

In our setup the Original To: and From: addresses are modified using the uac_replace_* methods. Opensips will add a vst and vsf parameter in the Route information. When the BYE message comes from the callee the To: and From: addresses are replaced to their original values. However this restore_uri process will garble the To: address field. I will look something like:


while it is supposed to be something like:

(replaced sensitive info with x-es)

A bit of digging around showed me that the garbled value is a BASE64 decode of the vsf parameter. (should the vsf parameter contain a BASE64 encoded representation of the original address?)

In some cases the garbled address contains a (hex) 0x0a character (CR/LF) which would mess up the whole SIP message.

I've tried this with 1.8.2 and 1.8.3 release. Both versions have the same problem.

Do you have any idea what's going on here?


  • Hi Tom,

    Are you using the UAC module in combination with dialog ? Asking just to be 100% sure, but I guess not as you mention seeing the vsf and vst params.

    Such messing of restorde TO/FROM uris may be because of bogus returning of the vsX params - double check if those params have exactly the same values in Record-Route hdr (in the outbound INVITE) and in the Route hdr in BYE.


  • Hi Bogdan,

    Thanks for your swift reply!

    To answer your first question. No, we're not using dialog.

    And the second question:
    The Record-Route header in the initial INVITE looks like:

    Record-Route: <sip:;lr;ftag=04777564-51947EFD00012164-B5942BB0;vst=AAAAABsDAgcEBQcAAgAHDHl2QEtRVEFfUh9dUEV2ZXJzLnB1c2hjYWxsLmNvbQ--;vsf=AAAAAF9WXVMATEVUUl9DUCx4QktdWEFfUhZdVEFBZXJzLnB1c2hjYWxsLmNvbQ-->

    The Route header in the BYE looks like:

    Route: <sip:;lr;ftag=04777564-51947EFD00012164-B5942BB0;vst=AAAAABsDAgcEBQcAAgAHDHl2QEtRVEFfUh9dUEV2ZXJzLnB1c2hjYWxsLmNvbQ--;vsf=AAAAAF9WXVMATEVUUl9DUCx4QktdWEFfUhZdVEFBZXJzLnB1c2hjYWxsLmNvbQ-->

    They are identical, so it's not being messed up.

    Just for my understanding; Should the vsf header contain a base64 encoded value of the To: address? If so, then it's not working as expected. At least when we assume that encode_uri is encoding the correct address value.

    In the logs I found these entries where the vsf value is generated:

    May 16 08:38:53 <servername> /usr/sbin/opensips[22099]: DBG:uac:replace_uri: uri to replace [sip:tele2xxxxxxxx@xxxxxxx.servers.pushcall.com]
    May 16 08:38:53 <servername> /usr/sbin/opensips[22099]: DBG:uac:replace_uri: replacement uri is [sip:+3162xxxxxxx@nn.nn.nnn.nnn]
    May 16 08:38:53 <servername> /usr/sbin/opensips[22099]: DBG:uac:replace_uri: encode is=<AAAAAF9WXVMATEVUUl9DUCx4QktdWEFfUhZdVEFBZXJzLnB1c2hjYWxsLmNvbQ--> len=64

    (I intentionaly obfuscated the uri values, but left the first characters intact)

    It looks like there is a XOR operation being performed on the 2 URI's which results in a new address (which is malformed) and then being encoded

    character# 1 2 3 4 5 6 7 8 9
    original uri s i p : t e l e 2
    orig. uri hex 73 69 70 3A 74 65 6C 65 32
    replacement uri s i p : + 3 1 6 2
    repl. uri hex 73 69 70 3A 2B 33 31 36 32
    XOR value hex 00 00 00 00 5f 56 5d 53 00
    vsf BASE64dec hex 00 00 00 00 5f 56 5d 53 00

    Either this is intentional, but somehow we "forget" to reverse this operation when the opposite action is performed (decode_uri) or this operation is performed by accident.

    Or am I way off?

    Best regards,


  • Hi Bogdan,

    On second (or third) thought the problem might be in the action to reverse the operation on the URI. I just found that the To: Address received in the BYE message is missing a few characters. Where the URI in the original INVITE is sip:+3162xxxxxxx@nn.nn.nnn.nnn the URI in the BYE is sip:62xxxxxxx@nn.nn.nnn.nnn
    Somehow the countrycode (+31) went missing. This explains the current behaviour. This ticket can be closed.

    One question remains; Is there anything I can do on the opensips side to become resiliant for this?

    Best regards,


  • Hi Tom,

    Aside presrving the vsX cookies, th URI module expects that TO/FROM URIs do not change at all - otherwise it will not work; going deep into tech part, the cookie is an XOR between the old and new URI - so having any of the URIS (old or new) and the cookie you can get the other URI. This is why it is important to have same TO/FROM URIs across the dialog.

    Even if you use the dialog module, it will not solve the problem for you - as only the cookie will be saved into dialog (and not the actual URIs).

    Something to completly make opensips independent of signalling issues is to also store the TO/FROM URIs in the dialog.


  • Hi Bogdan,

    Thank you for your clear explanation of the situation! Eventually I had the part of the XOR figured out by observing the logs (and some reverse engineering). It makes sense.

    Please close the ticket.


    • status: open --> closed-invalid