Any Idea What Causes “Oooh, Got A Frame With Format Of G729 On Channel ‘PJSIP/121-000001d2’ When We’re Sending ‘ulaw’, Switching To Match”
The PJSIP endpoint is configured for ulaw only. Not sure how or why we are seeing the g729 on calls for this endpoint.
Would this be a case that asterisk detects the rtp stream is g729 even though it’s negotiated as ulaw?
Why would asterisk change the format to g729 when disallow = all and allow = ulaw are the endpoint settings?
[121]
type = endpoint context = IS
transport = transport1
aors = 121
accountcode = 2
dtmf_mode = inband device_state_busy_at = 96
force_rport = no identify_by = username,ip disallow = all allow = ulaw from_user = 121
acl = acl1
[10/03 11:29:34.240] DEBUG[21414][C-00000226] chan_pjsip.c: Oooh, got a frame with format of g729 on channel ‘PJSIP/121-000001d2’ when we’re sending ‘ulaw’, switching to match
INVITE sip:2197@XXX.XXX.XXX.XXX:5060 SIP/2.0
Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;branch=z9hG4bKxqyYl2Jg84158000
To:
From:
Contact:
Call-ID: OlrmFuyOq-0000-@ YYY.YYY.YYY.YYY
CSeq: 2223 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY
Supported: replaces Content-Type: application/sdp Content-Length: 335
v=0
o=- 11264000 11264000 IN IP4 YYY.YYY.YYY.YYY
s=-
c=IN IP4 192.168.10.213
t=0 0
m=audio 32768 RTP/AVP 0 2 8 18 110 120 100
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:110 G723/5300
a=rtpmap:120 G723/6300
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=sendrecv
Send SIP/2.0 200 OK
Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;received=YYY.YYY.YYY.YYY;branch=z9hG4bKxqyYl2Jg84158000
Call-ID: OlrmFuyOq-0000-@YYY.YYY.YYY.YYY
From:
To:
CSeq: 2223 INVITE
Server: Asterisk PBX 13.20.0
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Contact:
Supported: 100rel, timer, replaces, norefersub Content-Type: application/sdp Content-Length: 181
v=0
o=- 11264000 11264002 IN IP4 YYY.YYY.YYY.YYY
s=Asterisk c=IN IP4 192.168.11.176
t=0 0
m=audio 18380 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=maxptime:150
a=sendrecv
Receive ACK sip:XXX.XXX.XXX.XXX:5060 SIP/2.0
Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;branch=z9hG4bKCIJuiRuH8415a000
To:
From:
Max-Forwards: 70
Call-ID: OlrmFuyOq-0000-@YYY.YYY.YYY.YYY
CSeq: 2223 ACK
Asterisk debugging outputs the following.
[10/03 11:29:34.240] DEBUG[21414][C-00000226] chan_pjsip.c: Oooh, got a frame with format of g729 on channel ‘PJSIP/121-000001d2’ when we’re sending ‘ulaw’, switching to match
[10/03 11:29:34.240] DEBUG[21414][C-00000226] channel.c: Channel PJSIP/121-000001d2 setting write format path: ulaw -> g729
[10/03 11:29:34.240] DEBUG[21414][C-00000226] channel.c: Channel PJSIP/121-000001d2 setting read format path: ulaw -> g729
[10/03 11:29:34.240] DEBUG[21414][C-00000226] channel.c: Channel PJSIP/121-000001d2 setting read format path: g729 -> g729
3 thoughts on - Any Idea What Causes “Oooh, Got A Frame With Format Of G729 On Channel ‘PJSIP/121-000001d2’ When We’re Sending ‘ulaw’, Switching To Match”
I’m reaching out to the asterisk users e-mail list in hopes someone there can provide guidance. A couple of Digium’s developers check this e-mail group so they may respond. Unfortunately, they are basically in the get ready for show mode. Major show is next week and they are also releasing the next major version in a matter of days.
Asking if them… What causes asterisk to output the Oooh, got a frame with format of g729 on channel ‘PJSIP/121-000001d2’ when we’re sending ‘ulaw’, switching to match message?
Is it asterisk detecting rtp stream with g729?
Why would asterisk change to g729 stream if the codec negotiation is clearly ulaw in the SIP packets?
Dan Cropp Senior Software Engineer, R&D Software Dept. AMTELCO, 4800 Curtin Drive, McFarland, WI 53558-9424
608 838-4197 ext. 291
1-800-238-5275 ext 291
http://www.amtelco.com<http://www.amtelco.com/>
Statement of Confidentiality The contents of this e-mail message and any attachments are confidential to American Tel-A-Systems, Inc. (AMTELCO), and are intended solely for the addressee(s). The information contained in this transmission also may be of a legally privileged nature. This transmission is sent in trust and is meant solely for delivery to the intended recipient(s). Receipt of this transmission does not convey any right to reproduce or disseminate any of the information it contains. If you are not the intended recipient, please immediately notify the sender by reply e-mail or telephone and delete this message and any attachments.
From: Dan Cropp Sent: Wednesday, October 3, 2018 1:57 PM
To: asterisk-users@lists.digium.com Subject: Any idea what causes “Oooh, got a frame with format of g729 on channel ‘PJSIP/121-000001d2’ when we’re sending ‘ulaw’, switching to match”
The PJSIP endpoint is configured for ulaw only. Not sure how or why we are seeing the g729 on calls for this endpoint.
Would this be a case that asterisk detects the rtp stream is g729 even though it’s negotiated as ulaw?
Why would asterisk change the format to g729 when disallow = all and allow = ulaw are the endpoint settings?
[121]
type = endpoint context = IS
transport = transport1
aors = 121
accountcode = 2
dtmf_mode = inband device_state_busy_at = 96
force_rport = no identify_by = username,ip disallow = all allow = ulaw from_user = 121
acl = acl1
[10/03 11:29:34.240] DEBUG[21414][C-00000226] chan_pjsip.c: Oooh, got a frame with format of g729 on channel ‘PJSIP/121-000001d2’ when we’re sending ‘ulaw’, switching to match
INVITE sip:2197@XXX.XXX.XXX.XXX:5060 SIP/2.0 > >;tag=I0n4X7KK>
Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;branch=z9hG4bKxqyYl2Jg84158000
To:
From:
Contact:
Call-ID: OlrmFuyOq-0000-@ YYY.YYY.YYY.YYY
CSeq: 2223 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY
Supported: replaces Content-Type: application/sdp Content-Length: 335
v=0
o=- 11264000 11264000 IN IP4 YYY.YYY.YYY.YYY
s=-
c=IN IP4 192.168.10.213
t=0 0
m=audio 32768 RTP/AVP 0 2 8 18 110 120 100
a=rtpmap:0 PCMU/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=rtpmap:110 G723/5300
a=rtpmap:120 G723/6300
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=sendrecv
Send SIP/2.0 200 OK;tag=I0n4X7KK >;tag=b4134118-08f4-4dbc-a145-573d04438092
Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;received=YYY.YYY.YYY.YYY;branch=z9hG4bKxqyYl2Jg84158000
Call-ID: OlrmFuyOq-0000-@YYY.YYY.YYY.YYY
From:
To:
CSeq: 2223 INVITE
Server: Asterisk PBX 13.20.0
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Contact:
Supported: 100rel, timer, replaces, norefersub Content-Type: application/sdp Content-Length: 181
v=0
o=- 11264000 11264002 IN IP4 YYY.YYY.YYY.YYY
s=Asterisk c=IN IP4 192.168.11.176
t=0 0
m=audio 18380 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
a=maxptime:150
a=sendrecv
Receive ACK sip:XXX.XXX.XXX.XXX:5060 SIP/2.0 >;tag=b4134118-08f4-4dbc-a145-573d04438092 >;tag=I0n4X7KK
Via: SIP/2.0/UDP YYY.YYY.YYY.YYY:5060;branch=z9hG4bKCIJuiRuH8415a000
To:
From:
Max-Forwards: 70
Call-ID: OlrmFuyOq-0000-@YYY.YYY.YYY.YYY
CSeq: 2223 ACK
Asterisk debugging outputs the following.
[10/03 11:29:34.240] DEBUG[21414][C-00000226] chan_pjsip.c: Oooh, got a frame with format of g729 on channel ‘PJSIP/121-000001d2’ when we’re sending ‘ulaw’, switching to match
[10/03 11:29:34.240] DEBUG[21414][C-00000226] channel.c: Channel PJSIP/121-000001d2 setting write format path: ulaw -> g729
[10/03 11:29:34.240] DEBUG[21414][C-00000226] channel.c: Channel PJSIP/121-000001d2 setting read format path: ulaw -> g729
[10/03 11:29:34.240] DEBUG[21414][C-00000226] channel.c: Channel PJSIP/121-000001d2 setting read format path: g729 -> g729
Because Asterisk received a G729 RTP packet from the other side and is being accommodating because asymmetric_rtp_codec=no is set. In this case the other side is in error by not honoring the negotiation.
This is mostly historical. chan_sip didn’t keep track of the truly negotiated codecs in the channel’s native capabilities. So if the peer’s INVITE
asked for five codecs and Asterisk supported three of them, we would respond with the three and then pick the one we were going to use and put it into the channel’s native capabilities. chan_pjsip has the asymmetric_rtp_codec option to emulate this same behavior which results in the “Oooh”
message you are seeing. If that option were disabled we would put those three codecs in the channel’s native capabilities. Then you would get this debug message instead:
“Oooh, got a frame with format of %s on channel ‘%s’ when it has not been negotiated”
and the frame would be discarded.
The primary reason for chan_sip’s behavior and chan_pjsip’s asymmetric_rtp_codec=no option is because phone DSP’s can only handle a single codec at a time. Technically if the peer’s INVITE offered five and we responded with three the peer should immediately renegotiate to narrow the codec choice to one.
Richard
VGhhbmsgeW91IFJpY2hhcmQuDQoNClRoYXTigJlzIHdoYXQgSSB0aG91Z2h0IHdhcyBoYXBwZW5p bmcuICBIZWxwcyB0byBoYXZlIGd1aWRhbmNlIGZyb20gYW4gZXhwZXJ0Lg0KDQpIYXZlIGEgZ3Jl YXQgZGF5IQ0KDQpEYW4NCg0KRnJvbTogYXN0ZXJpc2stdXNlcnMgPGFzdGVyaXNrLXVzZXJzLWJv dW5jZXNAbGlzdHMuZGlnaXVtLmNvbT4gT24gQmVoYWxmIE9mIFJpY2hhcmQgTXVkZ2V0dA0KU2Vu dDogV2VkbmVzZGF5LCBPY3RvYmVyIDMsIDIwMTggMzowMiBQTQ0KVG86IEFzdGVyaXNrIFVzZXJz IE1haWxpbmcgTGlzdCAtIE5vbi1Db21tZXJjaWFsIERpc2N1c3Npb24gPGFzdGVyaXNrLXVzZXJz QGxpc3RzLmRpZ2l1bS5jb20+DQpTdWJqZWN0OiBSZTogW2FzdGVyaXNrLXVzZXJzXSBBbnkgaWRl YSB3aGF0IGNhdXNlcyAiT29vaCwgZ290IGEgZnJhbWUgd2l0aCBmb3JtYXQgb2YgZzcyOSBvbiBj aGFubmVsICdQSlNJUC8xMjEtMDAwMDAxZDInIHdoZW4gd2UncmUgc2VuZGluZyAndWxhdycsIHN3
aXRjaGluZyB0byBtYXRjaCINCg0KDQpPbiBXZWQsIE9jdCAzLCAyMDE4IGF0IDI6MDkgUE0gRGFu IENyb3BwIDxkYW5AYW10ZWxjby5jb208bWFpbHRvOmRhbkBhbXRlbGNvLmNvbT4+IHdyb3RlOg0K
SeKAmW0gcmVhY2hpbmcgb3V0IHRvIHRoZSBhc3RlcmlzayB1c2VycyBlLW1haWwgbGlzdCBpbiBo b3BlcyBzb21lb25lIHRoZXJlIGNhbiBwcm92aWRlIGd1aWRhbmNlLiAgQSBjb3VwbGUgb2YgRGln aXVt4oCZcyBkZXZlbG9wZXJzIGNoZWNrIHRoaXMgZS1tYWlsIGdyb3VwIHNvIHRoZXkgbWF5IHJl c3BvbmQuICBVbmZvcnR1bmF0ZWx5LCB0aGV5IGFyZSBiYXNpY2FsbHkgaW4gdGhlIGdldCByZWFk eSBmb3Igc2hvdyBtb2RlLiAgTWFqb3Igc2hvdyBpcyBuZXh0IHdlZWsgYW5kIHRoZXkgYXJlIGFs c28gcmVsZWFzaW5nIHRoZSBuZXh0IG1ham9yIHZlcnNpb24gaW4gYSBtYXR0ZXIgb2YgZGF5cy4N
Cg0KQXNraW5nIGlmIHRoZW3igKYNCldoYXQgY2F1c2VzIGFzdGVyaXNrIHRvIG91dHB1dCB0aGUg T29vaCwgZ290IGEgZnJhbWUgd2l0aCBmb3JtYXQgb2YgZzcyOSBvbiBjaGFubmVsICdQSlNJUC8x MjEtMDAwMDAxZDInIHdoZW4gd2UncmUgc2VuZGluZyAndWxhdycsIHN3aXRjaGluZyB0byBtYXRj aA0KbWVzc2FnZT8NCg0KQmVjYXVzZSBBc3RlcmlzayByZWNlaXZlZCBhIEc3MjkgUlRQIHBhY2tl dCBmcm9tIHRoZSBvdGhlciBzaWRlIGFuZCBpcyBiZWluZyBhY2NvbW1vZGF0aW5nIGJlY2F1c2Ug YXN5bW1ldHJpY19ydHBfY29kZWM9bm8gaXMgc2V0Lg0KSW4gdGhpcyBjYXNlIHRoZSBvdGhlciBz aWRlIGlzIGluIGVycm9yIGJ5IG5vdCBob25vcmluZyB0aGUgbmVnb3RpYXRpb24uDQoNCklzIGl0
IGFzdGVyaXNrIGRldGVjdGluZyBydHAgc3RyZWFtIHdpdGggZzcyOT8NCldoeSB3b3VsZCBhc3Rl cmlzayBjaGFuZ2UgdG8gZzcyOSBzdHJlYW0gaWYgdGhlIGNvZGVjIG5lZ290aWF0aW9uIGlzIGNs ZWFybHkgdWxhdyBpbiB0aGUgU0lQIHBhY2tldHM/DQoNClRoaXMgaXMgbW9zdGx5IGhpc3Rvcmlj YWwuICBjaGFuX3NpcCBkaWRuJ3Qga2VlcCB0cmFjayBvZiB0aGUgdHJ1bHkgbmVnb3RpYXRlZCBj b2RlY3MgaW4gdGhlIGNoYW5uZWwncyBuYXRpdmUgY2FwYWJpbGl0aWVzLiAgU28gaWYgdGhlIHBl ZXIncyBJTlZJVEUNCmFza2VkIGZvciBmaXZlIGNvZGVjcyBhbmQgQXN0ZXJpc2sgc3VwcG9ydGVk IHRocmVlIG9mIHRoZW0sIHdlIHdvdWxkIHJlc3BvbmQgd2l0aCB0aGUgdGhyZWUgYW5kIHRoZW4g cGljayB0aGUgb25lIHdlIHdlcmUgZ29pbmcgdG8gdXNlIGFuZCBwdXQgaXQgaW50byB0aGUNCmNo YW5uZWwncyBuYXRpdmUgY2FwYWJpbGl0aWVzLiAgY2hhbl9wanNpcCBoYXMgdGhlIGFzeW1tZXRy aWNfcnRwX2NvZGVjIG9wdGlvbiB0byBlbXVsYXRlIHRoaXMgc2FtZSBiZWhhdmlvciB3aGljaCBy ZXN1bHRzIGluIHRoZSAiT29vaCINCm1lc3NhZ2UgeW91IGFyZSBzZWVpbmcuICBJZiB0aGF0IG9w dGlvbiB3ZXJlIGRpc2FibGVkIHdlIHdvdWxkIHB1dCB0aG9zZSB0aHJlZSBjb2RlY3MgaW4gdGhl IGNoYW5uZWwncyBuYXRpdmUgY2FwYWJpbGl0aWVzLiAgVGhlbiB5b3Ugd291bGQgZ2V0DQp0aGlz IGRlYnVnIG1lc3NhZ2UgaW5zdGVhZDoNCiJPb29oLCBnb3QgYSBmcmFtZSB3aXRoIGZvcm1hdCBv ZiAlcyBvbiBjaGFubmVsICclcycgd2hlbiBpdCBoYXMgbm90IGJlZW4gbmVnb3RpYXRlZCINCmFu ZCB0aGUgZnJhbWUgd291bGQgYmUgZGlzY2FyZGVkLg0KDQpUaGUgcHJpbWFyeSByZWFzb24gZm9y IGNoYW5fc2lwJ3MgYmVoYXZpb3IgYW5kIGNoYW5fcGpzaXAncyBhc3ltbWV0cmljX3J0cF9jb2Rl Yz1ubyBvcHRpb24gaXMgYmVjYXVzZSBwaG9uZSBEU1AncyBjYW4gb25seSBoYW5kbGUNCmEgc2lu Z2xlIGNvZGVjIGF0IGEgdGltZS4gIFRlY2huaWNhbGx5IGlmIHRoZSBwZWVyJ3MgSU5WSVRFIG9m ZmVyZWQgZml2ZSBhbmQgd2UgcmVzcG9uZGVkIHdpdGggdGhyZWUgdGhlIHBlZXIgc2hvdWxkIGlt bWVkaWF0ZWx5IHJlbmVnb3RpYXRlIHRvIG5hcnJvdyB0aGUNCmNvZGVjIGNob2ljZSB0byBvbmUu DQoNClJpY2hhcmQNCg0KRnJvbTogRGFuIENyb3BwDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIg MywgMjAxOCAxOjU3IFBNDQpUbzogYXN0ZXJpc2stdXNlcnNAbGlzdHMuZGlnaXVtLmNvbTxtYWls dG86YXN0ZXJpc2stdXNlcnNAbGlzdHMuZGlnaXVtLmNvbT4NClN1YmplY3Q6IEFueSBpZGVhIHdo YXQgY2F1c2VzICJPb29oLCBnb3QgYSBmcmFtZSB3aXRoIGZvcm1hdCBvZiBnNzI5IG9uIGNoYW5u ZWwgJ1BKU0lQLzEyMS0wMDAwMDFkMicgd2hlbiB3ZSdyZSBzZW5kaW5nICd1bGF3Jywgc3dpdGNo aW5nIHRvIG1hdGNoIg0KDQpUaGUgUEpTSVAgZW5kcG9pbnQgaXMgY29uZmlndXJlZCBmb3IgdWxh dyBvbmx5LiAgTm90IHN1cmUgaG93IG9yIHdoeSB3ZSBhcmUgc2VlaW5nIHRoZSBnNzI5IG9uIGNh bGxzIGZvciB0aGlzIGVuZHBvaW50Lg0KDQpXb3VsZCB0aGlzIGJlIGEgY2FzZSB0aGF0IGFzdGVy aXNrIGRldGVjdHMgdGhlIHJ0cCBzdHJlYW0gaXMgZzcyOSBldmVuIHRob3VnaCBpdOKAmXMgbmVn b3RpYXRlZCBhcyB1bGF3Pw0KV2h5IHdvdWxkIGFzdGVyaXNrIGNoYW5nZSB0aGUgZm9ybWF0IHRv IGc3Mjkgd2hlbiBkaXNhbGxvdyA9IGFsbCBhbmQgYWxsb3cgPSB1bGF3IGFyZSB0aGUgZW5kcG9p bnQgc2V0dGluZ3M/DQoNClsxMjFdDQp0eXBlID0gZW5kcG9pbnQNCmNvbnRleHQgPSBJUw0KdHJh bnNwb3J0ID0gdHJhbnNwb3J0MQ0KYW9ycyA9IDEyMQ0KYWNjb3VudGNvZGUgPSAyDQpkdG1mX21v ZGUgPSBpbmJhbmQNCmRldmljZV9zdGF0ZV9idXN5X2F0ID0gOTYNCmZvcmNlX3Jwb3J0ID0gbm8N
CmlkZW50aWZ5X2J5ID0gdXNlcm5hbWUsaXANCmRpc2FsbG93ID0gYWxsDQphbGxvdyA9IHVsYXcN
CmZyb21fdXNlciA9IDEyMQ0KYWNsID0gYWNsMQ0KDQpbMTAvMDMgMTE6Mjk6MzQuMjQwXSBERUJV
R1syMTQxNF1bQy0wMDAwMDIyNl0gY2hhbl9wanNpcC5jOiBPb29oLCBnb3QgYSBmcmFtZSB3aXRo IGZvcm1hdCBvZiBnNzI5IG9uIGNoYW5uZWwgJ1BKU0lQLzEyMS0wMDAwMDFkMicgd2hlbiB3ZSdy ZSBzZW5kaW5nICd1bGF3Jywgc3dpdGNoaW5nIHRvIG1hdGNoDQoNCg0KSU5WSVRFIHNpcDoyMTk3
QFhYWC5YWFguWFhYLlhYWDo1MDYwIFNJUC8yLjANClZpYTogU0lQLzIuMC9VRFAgWVlZLllZWS5Z
WVkuWVlZOjUwNjA7YnJhbmNoPXo5aEc0Ykt4cXlZbDJKZzg0MTU4MDAwDQpUbzogPHNpcDoyMTk3
QCBYWFguWFhYLlhYWC5YWFggPHNpcDoyMTk3QCUyMFhYWC5YWFguWFhYLlhYWCUyMD4gPg0KRnJv bTogPHNpcDpTVFVGRkBZWVkuWVlZLllZWS5ZWVkgPHNpcDpTVFVGRkBZWVkuWVlZLllZWS5ZWVkl MjA+ID47dGFnPUkwbjRYN0tLDQpDb250YWN0OiA8c2lwOlNUVUZGIEBZWVkuWVlZLllZWS5ZWVk6
NTA2MDxzaXA6U1RVRkYlMjBAWVlZLllZWS5ZWVkuWVlZOjUwNjA+Pg0KQ2FsbC1JRDogT2xybUZ1
eU9xLTAwMDAtQCBZWVkuWVlZLllZWS5ZWVkgPG1haWx0bzpPbHJtRnV5T3EtMDAwMC1AMTkyLjE2
OC4xMC4yMTM+DQpDU2VxOiAyMjIzIElOVklURQ0KTWF4LUZvcndhcmRzOiA3MA0KQWxsb3c6IElO
VklURSxBQ0ssQ0FOQ0VMLEJZRSxPUFRJT05TLFJFRkVSLE5PVElGWQ0KU3VwcG9ydGVkOiByZXBs YWNlcw0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9zZHANCkNvbnRlbnQtTGVuZ3RoOiAzMzUN
Cg0Kdj0wDQpvPS0gMTEyNjQwMDAgMTEyNjQwMDAgSU4gSVA0IFlZWS5ZWVkuWVlZLllZWQ0Kcz0t DQpjPUlOIElQNCAxOTIuMTY4LjEwLjIxMw0KdD0wIDANCm09YXVkaW8gMzI3NjggUlRQL0FWUCAw IDIgOCAxOCAxMTAgMTIwIDEwMA0KYT1ydHBtYXA6MCBQQ01VLzgwMDANCmE9cnRwbWFwOjIgRzcy Ni0zMi84MDAwDQphPXJ0cG1hcDo4IFBDTUEvODAwMA0KYT1ydHBtYXA6MTggRzcyOS84MDAwDQph PXJ0cG1hcDoxMTAgRzcyMy81MzAwDQphPXJ0cG1hcDoxMjAgRzcyMy82MzAwDQphPXJ0cG1hcDox MDAgdGVsZXBob25lLWV2ZW50LzgwMDANCmE9Zm10cDoxMDAgMC0xNQ0KYT1zZW5kcmVjdg0KDQpT
ZW5kDQpTSVAvMi4wIDIwMCBPSw0KVmlhOiBTSVAvMi4wL1VEUCBZWVkuWVlZLllZWS5ZWVk6NTA2
MDtyZWNlaXZlZD1ZWVkuWVlZLllZWS5ZWVk7YnJhbmNoPXo5aEc0Ykt4cXlZbDJKZzg0MTU4MDAw DQpDYWxsLUlEOiBPbHJtRnV5T3EtMDAwMC1AWVlZLllZWS5ZWVkuWVlZIDxtYWlsdG86T2xybUZ1
eU9xLTAwMDAtQFlZWS5ZWVkuWVlZLllZWSUyMD4NCkZyb206IDxzaXA6U1RVRkZAWVlZLllZWS5Z
WVkuWVlZIDxzaXA6U1RVRkZAWVlZLllZWS5ZWVkuWVlZJTIwPiA+O3RhZz1JMG40WDdLSw0KVG86
IDxzaXA6MjE5N0BYWFguWFhYLlhYWC5YWFggPHNpcDoyMTk3QFhYWC5YWFguWFhYLlhYWCUyMD4g Pjt0YWc9YjQxMzQxMTgtMDhmNC00ZGJjLWExNDUtNTczZDA0NDM4MDkyDQpDU2VxOiAyMjIzIElO
VklURQ0KU2VydmVyOiBBc3RlcmlzayBQQlggMTMuMjAuMA0KQWxsb3c6IE9QVElPTlMsIFNVQlND
UklCRSwgTk9USUZZLCBQVUJMSVNILCBJTlZJVEUsIEFDSywgQllFLCBDQU5DRUwsIFVQREFURSwg UFJBQ0ssIFJFR0lTVEVSLCBSRUZFUiwgTUVTU0FHRQ0KQ29udGFjdDogPHNpcDpZWVkuWVlZLllZ
WS5ZWVk6NTA2MD4NClN1cHBvcnRlZDogMTAwcmVsLCB0aW1lciwgcmVwbGFjZXMsIG5vcmVmZXJz dWINCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vc2RwDQpDb250ZW50LUxlbmd0aDogICAxODEN
Cg0Kdj0wDQpvPS0gMTEyNjQwMDAgMTEyNjQwMDIgSU4gSVA0IFlZWS5ZWVkuWVlZLllZWQ0Kcz1B
c3Rlcmlzaw0KYz1JTiBJUDQgMTkyLjE2OC4xMS4xNzYNCnQ9MCAwDQptPWF1ZGlvIDE4MzgwIFJU
UC9BVlAgMA0KYT1ydHBtYXA6MCBQQ01VLzgwMDANCmE9cHRpbWU6MjANCmE9bWF4cHRpbWU6MTUw DQphPXNlbmRyZWN2DQoNCg0KUmVjZWl2ZQ0KQUNLIHNpcDpYWFguWFhYLlhYWC5YWFg6NTA2MCBT
SVAvMi4wDQpWaWE6IFNJUC8yLjAvVURQIFlZWS5ZWVkuWVlZLllZWTo1MDYwO2JyYW5jaD16OWhH
NGJLQ0lKdWlSdUg4NDE1YTAwMA0KVG86IDxzaXA6MjE5N0AgWFhYLlhYWC5YWFguWFhYIDxzaXA6
MjE5N0AlMjBYWFguWFhYLlhYWC5YWFglMjA+ID47dGFnPWI0MTM0MTE4LTA4ZjQtNGRiYy1hMTQ1
LTU3M2QwNDQzODA5Mg0KRnJvbTogPHNpcDpTVFVGRkAgWVlZLllZWS5ZWVkuWVlZIDxzaXA6U1RV
RkZAJTIwWVlZLllZWS5ZWVkuWVlZJTIwPiA+O3RhZz1JMG40WDdLSw0KTWF4LUZvcndhcmRzOiA3
MA0KQ2FsbC1JRDogT2xybUZ1eU9xLTAwMDAtQFlZWS5ZWVkuWVlZLllZWTxtYWlsdG86T2xybUZ1
eU9xLTAwMDAtQFlZWS5ZWVkuWVlZLllZWT4NCkNTZXE6IDIyMjMgQUNLDQoNCg0KQXN0ZXJpc2sg ZGVidWdnaW5nIG91dHB1dHMgdGhlIGZvbGxvd2luZy4NClsxMC8wMyAxMToyOTozNC4yNDBdIERF
QlVHWzIxNDE0XVtDLTAwMDAwMjI2XSBjaGFuX3Bqc2lwLmM6IE9vb2gsIGdvdCBhIGZyYW1lIHdp dGggZm9ybWF0IG9mIGc3Mjkgb24gY2hhbm5lbCAnUEpTSVAvMTIxLTAwMDAwMWQyJyB3aGVuIHdl J3JlIHNlbmRpbmcgJ3VsYXcnLCBzd2l0Y2hpbmcgdG8gbWF0Y2gNClsxMC8wMyAxMToyOTozNC4y NDBdIERFQlVHWzIxNDE0XVtDLTAwMDAwMjI2XSBjaGFubmVsLmM6IENoYW5uZWwgUEpTSVAvMTIx LTAwMDAwMWQyIHNldHRpbmcgd3JpdGUgZm9ybWF0IHBhdGg6IHVsYXcgLT4gZzcyOQ0KWzEwLzAz IDExOjI5OjM0LjI0MF0gREVCVUdbMjE0MTRdW0MtMDAwMDAyMjZdIGNoYW5uZWwuYzogQ2hhbm5l bCBQSlNJUC8xMjEtMDAwMDAxZDIgc2V0dGluZyByZWFkIGZvcm1hdCBwYXRoOiB1bGF3IC0+IGc3
MjkNClsxMC8wMyAxMToyOTozNC4yNDBdIERFQlVHWzIxNDE0XVtDLTAwMDAwMjI2XSBjaGFubmVs LmM6IENoYW5uZWwgUEpTSVAvMTIxLTAwMDAwMWQyIHNldHRpbmcgcmVhZCBmb3JtYXQgcGF0aDog ZzcyOSAtPiBnNzI5DQoNCi0tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCi0tIEJhbmR3aWR0aCBhbmQgQ29sb2Nh dGlvbiBQcm92aWRlZCBieSBodHRwOi8vd3d3LmFwaS1kaWdpdGFsLmNvbSAtLQ0KDQpBc3RyaWNv biBpcyBjb21pbmcgdXAgT2N0b2JlciA5LTExISAgU2lnbnVwIGlzIGF2YWlsYWJsZSBhdDogaHR0
cHM6Ly93d3cuYXN0ZXJpc2sub3JnL2NvbW11bml0eS9hc3RyaWNvbi11c2VyLWNvbmZlcmVuY2UN
Cg0KQ2hlY2sgb3V0IHRoZSBuZXcgQXN0ZXJpc2sgY29tbXVuaXR5IGZvcnVtIGF0OiBodHRwczov L2NvbW11bml0eS5hc3Rlcmlzay5vcmcvDQoNCk5ldyB0byBBc3Rlcmlzaz8gU3RhcnQgaGVyZToN
CiAgICAgIGh0dHBzOi8vd2lraS5hc3Rlcmlzay5vcmcvd2lraS9kaXNwbGF5L0FTVC9HZXR0aW5n K1N0YXJ0ZWQNCg0KYXN0ZXJpc2stdXNlcnMgbWFpbGluZyBsaXN0DQpUbyBVTlNVQlNDUklCRSBv ciB1cGRhdGUgb3B0aW9ucyB2aXNpdDoNCiAgIGh0dHA6Ly9saXN0cy5kaWdpdW0uY29tL21haWxt YW4vbGlzdGluZm8vYXN0ZXJpc2stdXNlcnMNCg=