Asterisk 1.8.7.0 Connectivity To Avaya SM

Home » Asterisk Users » Asterisk 1.8.7.0 Connectivity To Avaya SM
Asterisk Users 4 Comments

Hello all, I hope someone can help me with this old Asterisk version. I have to run this version because of a custom IVR written on it. Porting it would take much too long and we’d have to hire a consultant because of all the hooks it has into Oracle databases and real-time information.

We have a brand-new Avaya phone system in place and we will be cutting over to it in late March 2019.

Presently:

* We have an Asterisk 13.3.2 server with no phones registered to it, acting as a PSTN gateway. Calls come into it and get distributed to other Asterisk boxes with phones.
* If a call comes in from the provider marked as having been dialed as xxx-xxx-6711 (those are digits, not a pattern) it gets routed to the IVR box
* The IVR box runs Asterisk 1.8.7.0 and a custom IVR.

Where we have to get to:

* The new Avaya Session Manager has to have a working SIP trunk to the IVR so it can pass calls that come into xxx-xxx-6711 to it.

What the problem is:

* I don’t fully understand what’s going on here, neither how it works now, nor what I need to do to make Avaya’s SM happy.
* When I do sip show peers on my IVR box, I see the Avaya session manager:

jerec*CLI> sip show peers

Name/username Host Dyn Forcerport ACL Port Status

sessionmgr1 10.10.0.17 5060 OK (1 ms)

* The Avaya engineer says he is seeing “SIP/2.0 400 Bad FROM header” in his trace screen, and his SM status screen shows “500 NOT REACHABLE” as the status for our IVR.
* He says we are sending

“asterisk” sip:asterisk@(null):0;tag=as682f2c53

as the “From” in the SIP header.

* He wants us to send
10.10.0.103@mcts.org
or more likely
>

instead.

* Pings from either end to the other work just fine.
* nmap doesn’t show port 5060 open. It shows only port 22/tcp open. But then again, my main asterisk PBX doesn’t show that port open either. So I don’t think that means anything.

The IVR machine (Asterisk 1.8.7.0) sip.conf file has an old section for the old PSTN gateway, and a new section I just added for the session manager. Old section for existing connections to the IVR:

[general]
;context=transit-ivr context=incoming disallow=all allow=ulaw canreinvite=no

[sipivr]
host=dynamic secret=1NA6oZjTg1rjhZN8lArDgzLI7z8V2fxV
type=peer
;context=transit-ivr context=incoming dtmfmode=inband

The new section, with many failed experiments commented out, is after the [sipivr] section:
[sessionmgr1]
type=peer
;type=friend port=5060
host=10.90.0.17
dtmfmode=inband allowguest=yes qualify=yes realm=mcts.org promiscredir=yes
;Some have suggested using canreinvite=no with Avaya- didn’t try that yet
;canreinvite=no canreinvite=yes transport=tcp
;context=incoming context=from-internal
;username=10.90.0.103
fromdomain=mcts.org disallow=all allow=ulaw allow=alaw tcpenable=yes tcpbindaddr=0.0.0.0:5060

Nothing I tried seems to make it stop sending asterisk@(null) in the header. This is supposed to be a sip trunk, not an extension, so I think I should NOT be user a username or secret. I’m not even sure what promiscredir does, or if it’s helping or harming me.

There’s virtually nothing in the logs about this connection, other than this:
[Feb 26 16:05:42] NOTICE[32142] chan_sip.c: Peer ‘sessionmgr1’ is now Reachable. (1ms / 2000ms)

Can anyone help?

Thomas M. Peters | Sr. Systems Administrator | tpeters@mcts.org
Desk: 414.343.1720 | Helpdesk: x3400 or helpdesk@mcts.org
Milwaukee County Transit System

1942 N 17th Street | Milwaukee, WI 53205
Check us out on Facebook & Twitter

4 thoughts on - Asterisk 1.8.7.0 Connectivity To Avaya SM

  • Thomas,

    Does the Asterisk box need to do anything other than handle calls for this one specific IVR? IE does it ever originate calls?

    If it’s only recieving calls then I’d turn on guest access and not even bother with a peer. Just set

    [general]
    context=transit-ivr allowguest=yes

  • Thanks for the reply John.

    About 85-90% of what this box has to do is just handle calls, but it also has options to transfer calls to the main phone system, which up to now has been another asterisk box. For example, you can hit 6 to be transferred to the Lost & Found Department.

    I do have allowguest set to “yes” already, but of course I also have type=peer and the other stuff for a sip trunk.

    The Avaya engineer is telling me that I need to change my “From” header, and I don’t know how to do that.

    I tried various things in sip.conf and now I get
    … Callerid : “10.90.0.103@mcts.org” <>

    My sip.conf file now has:
    fromdomain=mcts.org realm=mcts.org callerid=”10.90.0.103@mcts.org”

    I have to figure this out in the next few days, or I’m in deep doo-doo.

    -T

    Thomas M. Peters | Sr. Systems Administrator |  mailto:tpeters@mcts.org 

    From: asterisk-users Hello all, I hope someone can help me with this old Asterisk version. I have to run this version because of a custom IVR written on it. Porting it would take much too long and we’d have to hire a consultant because of all the hooks it has into Oracle databases and real-time information. We have a brand-new Avaya phone system in place and we will be cutting over to it in late March 2019. Presently:
    • We have an Asterisk 13.3.2 server with no phones registered to it, acting as a PSTN gateway. Calls come into it and get distributed to other Asterisk boxes with phones.
    • If a call comes in from the provider marked as having been dialed as xxx-xxx-6711 (those are digits, not a pattern) it gets routed to the IVR box
    • The IVR box runs Asterisk 1.8.7.0 and a custom IVR.
     
    Where we have to get to:
    • The new Avaya Session Manager has to have a working SIP trunk to the IVR so it can pass calls that come into xxx-xxx-6711 to it.
     
    What the problem is:
    • I don’t fully understand what’s going on here, neither how it works now, nor what I need to do to make Avaya’s SM happy.
    • When I do sip show peers on my IVR box, I see the Avaya session manager:
    jerec*CLI> sip show peers Name/username              Host                                    Dyn Forcerport ACL Port     Status sessionmgr1                10.10.0.17                                          5060     OK (1 ms)
    • The Avaya engineer says he is seeing “SIP/2.0 400 Bad FROM header” in his trace screen, and his SM status screen shows “500 NOT REACHABLE” as the status for our IVR. o He says we are sending
    “asterisk” sip:asterisk@(null):0;tag=as682f2c53
    as the “From” in the SIP header.
    • He wants us to send mailto:10.10.0.103@mcts.org 
    or more likely

    instead.
    • Pings from either end to the other work just fine.
    • nmap doesn’t show port 5060 open. It shows only port 22/tcp open. But then again, my main asterisk PBX doesn’t show that port open either. So I don’t think that means anything.
     
    The IVR machine (Asterisk 1.8.7.0) sip.conf file has an old section for the old PSTN gateway, and a new section I just added for the session manager. Old section for existing connections to the IVR:
     
    [general]
    ;context=transit-ivr context=incoming disallow=all allow=ulaw canreinvite=no
     
    [sipivr]
    host=dynamic secret=1NA6oZjTg1rjhZN8lArDgzLI7z8V2fxV
    type=peer
    ;context=transit-ivr context=incoming dtmfmode=inband
     
    The new section, with many failed experiments commented out, is after the [sipivr] section:
    [sessionmgr1]
    type=peer
    ;type=friend port=5060
    host=10.90.0.17
    dtmfmode=inband allowguest=yes qualify=yes realm=http://mcts.org promiscredir=yes
    ;Some have suggested using canreinvite=no with Avaya- didn’t try that yet
    ;canreinvite=no canreinvite=yes transport=tcp
    ;context=incoming context=from-internal
    ;username=10.90.0.103
    fromdomain=http://mcts.org disallow=all allow=ulaw allow=alaw tcpenable=yes tcpbindaddr=http://0.0.0.0:5060
     
    Nothing I tried seems to make it stop sending asterisk@(null) in the header. This is supposed to be a sip trunk, not an extension, so I think I should NOT be user a username or secret. I’m not even sure what promiscredir does, or if it’s helping or harming me.
     
    There’s virtually nothing in the logs about this connection, other than this:
    [Feb 26 16:05:42] NOTICE[32142] chan_sip.c: Peer ‘sessionmgr1’ is now Reachable. (1ms / 2000ms)
     
    Can anyone help?

    Thomas M. Peters | Sr. Systems Administrator |  mailto:tpeters@mcts.org 
    Desk: 414.343.1720 | Helpdesk: x3400 or  mailto:helpdesk@mcts.org http://www.ridemcts.com/
    1942 N 17th Street | Milwaukee, WI  53205
    Check us out on https://www.facebook.com/mcts & https://twitter.com/RideMCTS
     

  • All:

    We have made progress.

    We have the Avaya Session Manager showing a good connection now and we’re looking at getting calls across to the Asterisk IVR machine now.

    Seems we were defaulting to UDP and the Avaya SM wanted TCP. They switched the Avaya end to UDP and I made some other settings changes in sip.conf, and it’s working better.

    I’m using a trimmed-down sip.conf suggested by John Kiniston. Thank you very much indeed for your suggestions John.

    My sip.conf file now consists of
    [sessionmgr1]
    host=10.10.0.17
    type=peer qualify=yes fromuser=10.10.0.103

    But I don’t think it’s the final product; Some tweaking might still be needed. The 10.10.0.17 device is the Avaya Session Manager, and the .103 is the Asterisk-based IVR.

    Thanks again,
    -T

    Thomas M. Peters | Sr. Systems Administrator | tpeters@mcts.org
    Desk: 414.343.1720 | Helpdesk: x3400 or helpdesk@mcts.org
    Milwaukee County Transit System <http://www.ridemcts.com/>

    1942 N 17th Street | Milwaukee, WI 53205
    Check us out on Facebook<https://www.facebook.com/mcts> & Twitter <https://twitter.com/RideMCTS>

    From: asterisk-users On Behalf Of Thomas Peters Sent: Tuesday, February 26, 2019 4:11 PM
    To: Asterisk User List (asterisk-users@lists.digium.com)
    Subject: [asterisk-users] Asterisk 1.8.7.0 connectivity to Avaya SM

    Hello all, I hope someone can help me with this old Asterisk version. I have to run this version because of a custom IVR written on it. Porting it would take much too long and we’d have to hire a consultant because of all the hooks it has into Oracle databases and real-time information.

    We have a brand-new Avaya phone system in place and we will be cutting over to it in late March 2019.

  • VGhhbmtzIGZvciB0aGUgcmVwbHkgSm9obi4NCg0KQWJvdXQgODUtOTAlIG9mIHdoYXQgdGhpcyBi b3ggaGFzIHRvIGRvIGlzIGp1c3QgaGFuZGxlIGNhbGxzLCBidXQgaXQgYWxzbyBoYXMgb3B0aW9u cyB0byB0cmFuc2ZlciBjYWxscyB0byB0aGUgbWFpbiBwaG9uZSBzeXN0ZW0sIHdoaWNoIHVwIHRv IG5vdyBoYXMgYmVlbiBhbm90aGVyIGFzdGVyaXNrIGJveC4gRm9yIGV4YW1wbGUsIHlvdSBjYW4g aGl0IDYgdG8gYmUgdHJhbnNmZXJyZWQgdG8gdGhlIExvc3QgJiBGb3VuZCBEZXBhcnRtZW50Lg0K
    DQpJIGRvIGhhdmUgYWxsb3dndWVzdCBzZXQgdG8g4oCceWVz4oCdIGFscmVhZHksIGJ1dCBvZiBj b3Vyc2UgSSBhbHNvIGhhdmUgdHlwZT1wZWVyIGFuZCB0aGUgb3RoZXIgc3R1ZmYgZm9yIGEgc2lw IHRydW5rLg0KDQpUaGUgQXZheWEgZW5naW5lZXIgaXMgdGVsbGluZyBtZSB0aGF0IEkgbmVlZCB0
    byBjaGFuZ2UgbXkg4oCcRnJvbeKAnSBoZWFkZXIsIGFuZCBJIGRvbuKAmXQga25vdyBob3cgdG8g ZG8gdGhhdC4NCg0KSSBoYXZlIHRvIGZpZ3VyZSB0aGlzIG91dCBpbiB0aGUgbmV4dCBmZXcgZGF5
    cywgb3IgSeKAmW0gaW4gZGVlcCBkb28tZG9vLg0KDQotVA0KDQpUaG9tYXMgTS4gUGV0ZXJzIHwg U3IuIFN5c3RlbXMgQWRtaW5pc3RyYXRvciB8ICB0cGV0ZXJzQG1jdHMub3JnPG1haWx0bzp0cGV0
    ZXJzQG1jdHMub3JnPg0KRGVzazogNDE0LjM0My4xNzIwIHwgSGVscGRlc2s6IHgzNDAwIG9yICBo ZWxwZGVza0BtY3RzLm9yZzxtYWlsdG86aGVscGRlc2tAbWN0cy5vcmc+DQpNaWx3YXVrZWUgQ291
    bnR5IFRyYW5zaXQgU3lzdGVtIDxodHRwOi8vd3d3LnJpZGVtY3RzLmNvbS8+DQoNCjE5NDIgTiAx N3RoIFN0cmVldCB8IE1pbHdhdWtlZSwgV0kgIDUzMjA1DQpDaGVjayB1cyBvdXQgb24gRmFjZWJv b2s8aHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL21jdHM+ICYgVHdpdHRlciA8aHR0cHM6Ly90d2l0
    dGVyLmNvbS9SaWRlTUNUUz4NCg0KRnJvbTogYXN0ZXJpc2stdXNlcnMgPGFzdGVyaXNrLXVzZXJz LWJvdW5jZXNAbGlzdHMuZGlnaXVtLmNvbT4gT24gQmVoYWxmIE9mIEpvaG4gS2luaXN0b24NClNl bnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE5IDQ6NDYgUE0NClRvOiBBc3RlcmlzayBVc2Vy cyBNYWlsaW5nIExpc3QgLSBOb24tQ29tbWVyY2lhbCBEaXNjdXNzaW9uIDxhc3Rlcmlzay11c2Vy c0BsaXN0cy5kaWdpdW0uY29tPg0KU3ViamVjdDogUmU6IFthc3Rlcmlzay11c2Vyc10gQXN0ZXJp c2sgMS44LjcuMCBjb25uZWN0aXZpdHkgdG8gQXZheWEgU00NCg0KVGhvbWFzLA0KRG9lcyB0aGUg QXN0ZXJpc2sgYm94IG5lZWQgdG8gZG8gYW55dGhpbmcgb3RoZXIgdGhhbiBoYW5kbGUgY2FsbHMg Zm9yIHRoaXMgb25lIHNwZWNpZmljIElWUj8gSUUgZG9lcyBpdCBldmVyIG9yaWdpbmF0ZSBjYWxs cz8NCklmIGl0J3Mgb25seSByZWNpZXZpbmcgY2FsbHMgdGhlbiBJJ2QgdHVybiBvbiBndWVzdCBh Y2Nlc3MgYW5kIG5vdCBldmVuIGJvdGhlciB3aXRoIGEgcGVlci4NCkp1c3Qgc2V0DQpbZ2VuZXJh bF0NCmNvbnRleHQ9dHJhbnNpdC1pdnINCmFsbG93Z3Vlc3Q9eWVzDQoNCk9uIFR1ZSwgRmViIDI2
    LCAyMDE5IGF0IDM6MTMgUE0gVGhvbWFzIFBldGVycyA8VFBldGVyc0BtY3RzLm9yZzxtYWlsdG86
    VFBldGVyc0BtY3RzLm9yZz4+IHdyb3RlOg0KSGVsbG8gYWxsLCBJIGhvcGUgc29tZW9uZSBjYW4g aGVscCBtZSB3aXRoIHRoaXMgb2xkIEFzdGVyaXNrIHZlcnNpb24uIEkgaGF2ZSB0byBydW4gdGhp cyB2ZXJzaW9uIGJlY2F1c2Ugb2YgYSBjdXN0b20gSVZSIHdyaXR0ZW4gb24gaXQuIFBvcnRpbmcg aXQgd291bGQgdGFrZSBtdWNoIHRvbyBsb25nIGFuZCB3ZeKAmWQgaGF2ZSB0byBoaXJlIGEgY29u c3VsdGFudCBiZWNhdXNlIG9mIGFsbCB0aGUgaG9va3MgaXQgaGFzIGludG8gT3JhY2xlIGRhdGFi YXNlcyBhbmQgcmVhbC10aW1lIGluZm9ybWF0aW9uLg0KDQpXZSBoYXZlIGEgYnJhbmQtbmV3IEF2
    YXlhIHBob25lIHN5c3RlbSBpbiBwbGFjZSBhbmQgd2Ugd2lsbCBiZSBjdXR0aW5nIG92ZXIgdG8g aXQgaW4gbGF0ZSBNYXJjaCAyMDE5Lg0KDQpQcmVzZW50bHk6DQoNCiAgKiAgIFdlIGhhdmUgYW4g QXN0ZXJpc2sgMTMuMy4yIHNlcnZlciB3aXRoIG5vIHBob25lcyByZWdpc3RlcmVkIHRvIGl0LCBh Y3RpbmcgYXMgYSBQU1ROIGdhdGV3YXkuIENhbGxzIGNvbWUgaW50byBpdCBhbmQgZ2V0IGRpc3Ry aWJ1dGVkIHRvIG90aGVyIEFzdGVyaXNrIGJveGVzIHdpdGggcGhvbmVzLg0KICAqICAgSWYgYSBj YWxsIGNvbWVzIGluIGZyb20gdGhlIHByb3ZpZGVyIG1hcmtlZCBhcyBoYXZpbmcgYmVlbiBkaWFs ZWQgYXMgeHh4LXh4eC02NzExICh0aG9zZSBhcmUgZGlnaXRzLCBub3QgYSBwYXR0ZXJuKSBpdCBn ZXRzIHJvdXRlZCB0byB0aGUgSVZSIGJveA0KICAqICAgVGhlIElWUiBib3ggcnVucyBBc3Rlcmlz ayAxLjguNy4wIGFuZCBhIGN1c3RvbSBJVlIuDQoNCldoZXJlIHdlIGhhdmUgdG8gZ2V0IHRvOg0K
    DQogICogICBUaGUgbmV3IEF2YXlhIFNlc3Npb24gTWFuYWdlciBoYXMgdG8gaGF2ZSBhIHdvcmtp bmcgU0lQIHRydW5rIHRvIHRoZSBJVlIgc28gaXQgY2FuIHBhc3MgY2FsbHMgdGhhdCBjb21lIGlu dG8geHh4LXh4eC02NzExIHRvIGl0Lg0KDQpXaGF0IHRoZSBwcm9ibGVtIGlzOg0KDQogICogICBJ
    IGRvbuKAmXQgZnVsbHkgdW5kZXJzdGFuZCB3aGF04oCZcyBnb2luZyBvbiBoZXJlLCBuZWl0aGVy IGhvdyBpdCB3b3JrcyBub3csIG5vciB3aGF0IEkgbmVlZCB0byBkbyB0byBtYWtlIEF2YXlh4oCZ
    cyBTTSBoYXBweS4NCiAgKiAgIFdoZW4gSSBkbyBzaXAgc2hvdyBwZWVycyBvbiBteSBJVlIgYm94
    LCBJIHNlZSB0aGUgQXZheWEgc2Vzc2lvbiBtYW5hZ2VyOg0KDQpqZXJlYypDTEk+IHNpcCBzaG93
    IHBlZXJzDQoNCk5hbWUvdXNlcm5hbWUgICAgICAgICAgICAgIEhvc3QgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBEeW4gRm9yY2VycG9ydCBBQ0wgUG9ydCAgICAgU3RhdHVzDQoN
    CnNlc3Npb25tZ3IxICAgICAgICAgICAgICAgIDEwLjEwLjAuMTcgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICA1MDYwICAgICBPSyAoMSBtcykNCg0KICAqICAgVGhlIEF2
    YXlhIGVuZ2luZWVyIHNheXMgaGUgaXMgc2VlaW5nIOKAnFNJUC8yLjAgNDAwIEJhZCBGUk9NIGhl YWRlcuKAnSBpbiBoaXMgdHJhY2Ugc2NyZWVuLCBhbmQgaGlzIFNNIHN0YXR1cyBzY3JlZW4gc2hv d3Mg4oCcNTAwIE5PVCBSRUFDSEFCTEXigJ0gYXMgdGhlIHN0YXR1cyBmb3Igb3VyIElWUi4NCg0K
    ICAgICAqICAgSGUgc2F5cyB3ZSBhcmUgc2VuZGluZw0KDQrigJxhc3Rlcmlza+KAnSBzaXA6YXN0
    ZXJpc2tAKG51bGwpOjA7dGFnPWFzNjgyZjJjNTMNCg0KYXMgdGhlIOKAnEZyb23igJ0gaW4gdGhl IFNJUCBoZWFkZXIuDQoNCiAgKiAgIEhlIHdhbnRzIHVzIHRvIHNlbmQNCjEwLjEwLjAuMTAzQG1j dHMub3JnPG1haWx0bzoxMC4xMC4wLjEwM0BtY3RzLm9yZz4NCm9yIG1vcmUgbGlrZWx5DQo8c2lw OjEwLjEwLjAuMTAzQG1jdHMub3JnPG1haWx0bzoxMC4xMC4wLjEwM0BtY3RzLm9yZz4+DQoNCmlu c3RlYWQuDQoNCiAgKiAgIFBpbmdzIGZyb20gZWl0aGVyIGVuZCB0byB0aGUgb3RoZXIgd29yayBq dXN0IGZpbmUuDQogICogICBubWFwIGRvZXNu4oCZdCBzaG93IHBvcnQgNTA2MCBvcGVuLiBJdCBz aG93cyBvbmx5IHBvcnQgMjIvdGNwIG9wZW4uIEJ1dCB0aGVuIGFnYWluLCBteSBtYWluIGFzdGVy aXNrIFBCWCBkb2VzbuKAmXQgc2hvdyB0aGF0IHBvcnQgb3BlbiBlaXRoZXIuIFNvIEkgZG9u4oCZ
    dCB0aGluayB0aGF0IG1lYW5zIGFueXRoaW5nLg0KDQpUaGUgSVZSIG1hY2hpbmUgKEFzdGVyaXNr IDEuOC43LjApIHNpcC5jb25mIGZpbGUgaGFzIGFuIG9sZCBzZWN0aW9uIGZvciB0aGUgb2xkIFBT
    VE4gZ2F0ZXdheSwgYW5kIGEgbmV3IHNlY3Rpb24gSSBqdXN0IGFkZGVkIGZvciB0aGUgc2Vzc2lv biBtYW5hZ2VyLg0KT2xkIHNlY3Rpb24gZm9yIGV4aXN0aW5nIGNvbm5lY3Rpb25zIHRvIHRoZSBJ
    VlI6DQoNCltnZW5lcmFsXQ0KO2NvbnRleHQ9dHJhbnNpdC1pdnINCmNvbnRleHQ9aW5jb21pbmcN
    CmRpc2FsbG93PWFsbA0KYWxsb3c9dWxhdw0KY2FucmVpbnZpdGU9bm8NCg0KW3NpcGl2cl0NCmhv c3Q9ZHluYW1pYw0Kc2VjcmV0PTFOQTZvWmpUZzFyamhaTjhsQXJEZ3pMSTd6OFYyZnhWDQp0eXBl PXBlZXINCjtjb250ZXh0PXRyYW5zaXQtaXZyDQpjb250ZXh0PWluY29taW5nDQpkdG1mbW9kZT1p bmJhbmQNCg0KVGhlIG5ldyBzZWN0aW9uLCB3aXRoIG1hbnkgZmFpbGVkIGV4cGVyaW1lbnRzIGNv bW1lbnRlZCBvdXQsIGlzIGFmdGVyIHRoZSBbc2lwaXZyXSBzZWN0aW9uOg0KW3Nlc3Npb25tZ3Ix XQ0KdHlwZT1wZWVyDQo7dHlwZT1mcmllbmQNCnBvcnQ9NTA2MA0KaG9zdD0xMC45MC4wLjE3DQpk dG1mbW9kZT1pbmJhbmQNCmFsbG93Z3Vlc3Q9eWVzDQpxdWFsaWZ5PXllcw0KcmVhbG09bWN0cy5v cmc8aHR0cDovL21jdHMub3JnPg0KcHJvbWlzY3JlZGlyPXllcw0KO1NvbWUgaGF2ZSBzdWdnZXN0
    ZWQgdXNpbmcgY2FucmVpbnZpdGU9bm8gd2l0aCBBdmF5YS0gZGlkbid0IHRyeSB0aGF0IHlldA0K
    O2NhbnJlaW52aXRlPW5vDQpjYW5yZWludml0ZT15ZXMNCnRyYW5zcG9ydD10Y3ANCjtjb250ZXh0
    PWluY29taW5nDQpjb250ZXh0PWZyb20taW50ZXJuYWwNCjt1c2VybmFtZT0xMC45MC4wLjEwMw0K
    ZnJvbWRvbWFpbj1tY3RzLm9yZzxodHRwOi8vbWN0cy5vcmc+DQpkaXNhbGxvdz1hbGwNCmFsbG93
    PXVsYXcNCmFsbG93PWFsYXcNCnRjcGVuYWJsZT15ZXMNCnRjcGJpbmRhZGRyPTAuMC4wLjA6NTA2
    MDxodHRwOi8vMC4wLjAuMDo1MDYwPg0KDQpOb3RoaW5nIEkgdHJpZWQgc2VlbXMgdG8gbWFrZSBp dCBzdG9wIHNlbmRpbmcgYXN0ZXJpc2tAKG51bGwpIGluIHRoZSBoZWFkZXIuIFRoaXMgaXMgc3Vw cG9zZWQgdG8gYmUgYSBzaXAgdHJ1bmssIG5vdCBhbiBleHRlbnNpb24sIHNvIEkgdGhpbmsgSSBz aG91bGQgTk9UIGJlIHVzZXIgYSB1c2VybmFtZSBvciBzZWNyZXQuIEnigJltIG5vdCBldmVuIHN1
    cmUgd2hhdCBwcm9taXNjcmVkaXIgZG9lcywgb3IgaWYgaXTigJlzIGhlbHBpbmcgb3IgaGFybWlu ZyBtZS4NCg0KVGhlcmXigJlzIHZpcnR1YWxseSBub3RoaW5nIGluIHRoZSBsb2dzIGFib3V0IHRo aXMgY29ubmVjdGlvbiwgb3RoZXIgdGhhbiB0aGlzOg0KW0ZlYiAyNiAxNjowNTo0Ml0gTk9USUNF
    WzMyMTQyXSBjaGFuX3NpcC5jOiBQZWVyICdzZXNzaW9ubWdyMScgaXMgbm93IFJlYWNoYWJsZS4g KDFtcyAvIDIwMDBtcykNCg0KQ2FuIGFueW9uZSBoZWxwPw0KVGhvbWFzIE0uIFBldGVycyB8IFNy LiBTeXN0ZW1zIEFkbWluaXN0cmF0b3IgfCAgdHBldGVyc0BtY3RzLm9yZzxtYWlsdG86dHBldGVy c0BtY3RzLm9yZz4NCkRlc2s6IDQxNC4zNDMuMTcyMCB8IEhlbHBkZXNrOiB4MzQwMCBvciAgaGVs cGRlc2tAbWN0cy5vcmc8bWFpbHRvOmhlbHBkZXNrQG1jdHMub3JnPg0KTWlsd2F1a2VlIENvdW50
    eSBUcmFuc2l0IFN5c3RlbSA8aHR0cDovL3d3dy5yaWRlbWN0cy5jb20vPg0KMTk0MiBOIDE3dGgg U3RyZWV0IHwgTWlsd2F1a2VlLCBXSSAgNTMyMDUNCkNoZWNrIHVzIG91dCBvbiBGYWNlYm9vazxo dHRwczovL3d3dy5mYWNlYm9vay5jb20vbWN0cz4gJiBUd2l0dGVyIDxodHRwczovL3R3aXR0ZXIu Y29tL1JpZGVNQ1RTPg0KDQotLQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQotLSBCYW5kd2lkdGggYW5kIENvbG9j YXRpb24gUHJvdmlkZWQgYnkgaHR0cDovL3d3dy5hcGktZGlnaXRhbC5jb20gLS0NCg0KQ2hlY2sg b3V0IHRoZSBuZXcgQXN0ZXJpc2sgY29tbXVuaXR5IGZvcnVtIGF0OiBodHRwczovL2NvbW11bml0
    eS5hc3Rlcmlzay5vcmcvDQoNCk5ldyB0byBBc3Rlcmlzaz8gU3RhcnQgaGVyZToNCiAgICAgIGh0
    dHBzOi8vd2lraS5hc3Rlcmlzay5vcmcvd2lraS9kaXNwbGF5L0FTVC9HZXR0aW5nK1N0YXJ0ZWQN
    Cg0KYXN0ZXJpc2stdXNlcnMgbWFpbGluZyBsaXN0DQpUbyBVTlNVQlNDUklCRSBvciB1cGRhdGUg b3B0aW9ucyB2aXNpdDoNCiAgIGh0dHA6Ly9saXN0cy5kaWdpdW0uY29tL21haWxtYW4vbGlzdGlu Zm8vYXN0ZXJpc2stdXNlcnMNCg0KDQotLQ0KQSBodW1hbiBiZWluZyBzaG91bGQgYmUgYWJsZSB0
    byBjaGFuZ2UgYSBkaWFwZXIsIHBsYW4gYW4gaW52YXNpb24sIGJ1dGNoZXIgYSBob2csIGNvbm4g YSBzaGlwLCBkZXNpZ24gYSBidWlsZGluZywgd3JpdGUgYSBzb25uZXQsIGJhbGFuY2UgYWNjb3Vu dHMsIGJ1aWxkIGEgd2FsbCwgc2V0IGEgYm9uZSwgY29tZm9ydCB0aGUgZHlpbmcsIHRha2Ugb3Jk ZXJzLCBnaXZlIG9yZGVycywgY29vcGVyYXRlLCBhY3QgYWxvbmUsIHNvbHZlIGVxdWF0aW9ucywg YW5hbHl6ZSBhIG5ldyBwcm9ibGVtLCBwaXRjaCBtYW51cmUsIHByb2dyYW0gYSBjb21wdXRlciwg Y29vayBhIHRhc3R5IG1lYWwsIGZpZ2h0IGVmZmljaWVudGx5LCBkaWUgZ2FsbGFudGx5LiBTcGVj aWFsaXphdGlvbiBpcyBmb3IgaW5zZWN0cy4NCi0tLUhlaW5sZWluDQo