PJSIP Configuration Question
I’m working with a SIP provider to try and transition our sip connection with them to PJSIP. I thought I had transitioned the settings correctly, but whenever I attempt an Originate it never even tries to send any PJSIP messages.
I’m currently running Asterisk 13.0.0.
Anyone have any suggestions as to what I am doing wrong?
The SIP provider says the latest version of Asterisk they have anyone using is Asterisk 11, so they have no PJSIP configuration experience.
The only setting that I believe I haven’t found a PJSIP settting for is the “insecure=invite” from sip.conf I thought that would be the equivalent of no authentication object, so I tried that. However, that did not work either.
I tried changing the endpoint to have no auth and outbound_auth settings. I tried changing the endpoint to use the auth instead of the outbound_auth.
The SIP provider even changed the username and passwords to blank. I followed suit and changed the pjsip.conf user and password related settings to blank.
Our sip.conf (running in a different VM on Asterisk 13.0.0) settings look like this…
[xxxxx]
type = friend qualify = no nat = yes host = xxxxx defaultuser = yyyyy secret = zzzzz incominglimit = 4
accountcode = 9
port = 5060
context = TestApp dtmfmode = auto insecure = invite fromdomain = xxxxx fromuser = yyyyy sendrpid = yes trustrpid = yes canreinvite = no
For the pjsip.conf settings (Asterisk 13.0.0), I have
[transport1]
type = transport bind = 0.0.0.0
protocol = udp
[xxxxx]
type = aor max_contacts = 1
remove_existing = yes contact = sip:yyyyy@xxxxx:5060
[auth9]
type = auth username = yyyyy password = zzzzz
[xxxxx]
type = endpoint context = TestApp transport = transport1
outbound_auth = auth9
aors = xxxxx accountcode = 9
dtmf_mode = rfc4733
device_state_busy_at = 4
;force_rport = yes ; also tried with this setting, but it still didn’t help rtp_symmetric = yes rewrite_contact = yes from_domain = xxxxxx from_user = yyyyy send_rpid = yes trust_id_inbound = yes direct_media = no
Have a great day!
Dan
43 thoughts on - PJSIP Configuration Question
Kia ora,
Dan Cropp wrote:
What dial string are you providing to Originate?
That functionality exists in the form of the “identify” object. It does IP based matching of incoming traffic and to associate it with an endpoint.
Authentication controls authentication, it doesn’t control how PJSIP
associates traffic with a specific endpoint. They are separate things.
I think before we get into config we need to see the dial string for your origination.
Cheers,
Thank you for the speedy reply.
My originate string is something like the following where xxxxx is really the sip provider’s supplied IP address
1234567890 is really the phone number I am dialing
PJSIP/outbound.vitelity.net/1234567890
In the chan_sip based solution, it’s… SIP/outbound.vitelity.net/1234567890
Have a great day!
Dan
—–Original Message—
I should mention, I am actually sending this via AMI in both the chan_sip and the pjsip case.
Pjsip originate…
Action: Originate ActionID: S8
Channel: PJSIP/outbound.vitelity.net/1234567890
Exten: createcall Context: TestApp Priority: 1
Timeout: 60000
CallerID: Dan Cropp<1234>
Variable: CALLERID(num-pres)=allowed_passed_screened Async: true
Chan_sip based originate…
Action: Originate ActionID: S8
Channel: SIP/outbound.vitelity.net/1234567890
Exten: createcall Context: TestApp Priority: 1
Timeout: 60000
CallerID: Dan Cropp<1234>
Variable: CALLERID(num-pres)=allowed_passed_screened Async: true
Have a great day!
Dan
—–Original Message—
Not sure why, but Vitelity changed the settings to IP based authentication on me. Here’s the new sip.conf settings they sent me.
type=friend dtmfmode=auto hostd.2.142.93
allow=all nat=yes canreinvite=no trustrpid=yes sendrpid=yes
When I use these settings to originate calls using the sip.conf they sent me, everything works.
Action: Originate ActionID: S8
Channel: SIP/outbound.vitelity.net/8005555555
Exten: createcall Context: TestApp Priority: 1
Timeout: 60000
CallerID: John Doe <1234>
Variable: CALLERID(num-pres)=allowed_passed_screened Async: true
I translated those settings to the following for pjsip.conf…
[transport1]
type = transport bind = 0.0.0.0
protocol = udp
[outbound.vitelity.net]
type = aor remove_existing = yes contact = sip:64.2.142.93@5060
[outbound.vitelity.net]
type = endpoint context = TestApp transport = transport1
aors = outbound.vitelity.net dtmf_mode = rfc4733
force_rport = yes rtp_symmetric = yes rewrite_contact = yes send_rpid = yes trust_id_inbound = yes allow = all direct_media = no
[identify1]
type = identify endpoint = outbound.vitelity.net match = 64.2.142.93
When I attempt to use AMI Originate, it’s failing. I am not seeing anything with pjsip logging turned on, so it seems to be something with the settings.
Action: Originate ActionID: S8
Channel: PJSIP/outbound.vitelity.net/8005555555
Exten: createcall Context: TestApp Priority: 1
Timeout: 60000
CallerID: John Doe <1234>
Variable: CALLERID(num-pres)=allowed_passed_screened Async: true
NOTE: I am able to use AMI Originate to other PJSIP endpoints.
Action: Originate ActionID: S9
Channel: PJSIP/1003/1003
Exten: createcall Context: TestApp Priority: 1
Timeout: 60000
CallerID: John Doe <1234>
Variable: CALLERID(num-pres)=allowed_passed_screened Async: true
Anyone have any suggestions as to what I am doing wrong?
Have a great day!
Dan
You might want to set a qualify_frequency here to see if the server responds to OPTIONS messages. Also 64.2.142.93 isn’t currently one of their outbound servers. Are you using one of their inbound* servers as outbound? IIRC unless you ask them, they don’t allow it.
VGhhbmtzIEdlb3JnZS4NCg0KVGhhdCB3YXMgdGhlIGlwIGFkZHJlc3MgSSB3YXMgZ2l2ZW4uICBV
bmZvcnR1bmF0ZWx5LCBteSBjb250YWN0IGF0IFZpdGVsaXR5IGlzIGdvbmUgZm9yIHRoZSBkYXkg c28gSSBjYW7igJl0IHZlcmlmeSBpdCB3aXRoIGhpbS4NCg0KSSBhZGRlZCB0aGUgcXVhbGlmeV9m cmVxdWVuY3kgYXMgeW91IHN1Z2dlc3RlZCBhbmQgaXQgZG9lcyBhcHBlYXIgdGhhdCBJIGhhdmUg c29tZXRoaW5nIGNvbmZpZ3VyZWQgaW5jb3JyZWN0bHnigKYuDQoNCjwtLS0gVHJhbnNtaXR0aW5n IFNJUCByZXF1ZXN0ICg0ODMgYnl0ZXMpIHRvIFVEUDowLjAuMTkuMTk2OjUwNjAgLS0tPg0KT1BU
SU9OUyBzaXA6NjQuMi4xNDIuOTNANTA2MCBTSVAvMi4wDQpWaWE6IFNJUC8yLjAvVURQIHh4eC54
eHgueHgueHh4OjUwNjA7cnBvcnQ7YnJhbmNoPXo5aEc0YktQamNlYTYzOTE0LWI4ZDEtNDgzZC05
NmRiLTExOTY4YWJhYjcwNA0KRnJvbTogPHNpcDplMzFkNTgwOS1mMjZhLTQyMTktODM2NS03MDkz MTQyODA3MmJAeHh4Lnh4eC54eC54eHg+O3RhZz03Y2ZhYjNiYS03M2RlLTQyNDMtOTk2Ny1kMWU2
YTVlN2IwYjQNClRvOiA8c2lwOjY0LjIuMTQyLjkzQDUwNjA+DQpDb250YWN0OiA8c2lwOmUzMWQ1
ODA5LWYyNmEtNDIxOS04MzY1LTcwOTMxNDI4MDcyYkB4eHgueHh4Lnh4Lnh4eDo1MDYwPg0KQ2Fs bC1JRDogN2JhNzY2YmYtMzYzYi00N2QwLWEzODgtNjJhNThkMWRmODhkDQpDU2VxOiAzMzc3OCBP
UFRJT05TDQpNYXgtRm9yd2FyZHM6IDcwDQpVc2VyLUFnZW50OiBBc3RlcmlzayBQQlggMTMuMC4w DQpDb250ZW50LUxlbmd0aDogIDANCg0KDQpbRGVjIDE3IDE5OjIyOjMxXSBXQVJOSU5HWzQ5NDc2
XTogcGpzaXA6MCA8Pz46ICAgIHRzeDB4M2M1MDFlOCAuRmFpbGVkIHRvIHNlbmQgUmVxdWVzdCBt c2cgT1BUSU9OUy9jc2VxPTMzNzc4ICh0ZHRhMHgzMmM3YzkwKSEgZXJyPTEyMDAyMiAoSW52YWxp ZCBhcmd1bWVudCkNCltEZWMgMTcgMTk6MjI6MzFdIEVSUk9SWzQ5NDc2XTogcmVzX3Bqc2lwLmM6
MjUzMiBlbmRwdF9zZW5kX3JlcXVlc3Q6IEVycm9yIDEyMDAyMiAnSW52YWxpZCBhcmd1bWVudCcg c2VuZGluZyBPUFRJT05TIHJlcXVlc3QgdG8gZW5kcG9pbnQgPHVua25vd24+DQoNCg0KVGhlIDY0
LjIuMTQyLjkzIGlzIHRoZSBleGFjdCB2YWx1ZSBJIHdhcyBnaXZlbiB0byB1c2UgZm9yIHRoZSBv dXRib3VuZCB0cnVuayAod29ya3Mgd2l0aCBzaXAuY29uZikNCmhvc3Q9NjQuMi4xNDIuOTMNCkFu eSB0aG91Z2h0cz8NCkkgd2FzIHJlYWxseSBob3BpbmcgdGhleSBoYWQgd29ya2VkIHdpdGggdGhl IFBKU0lQLCBidXQgYXBwYXJlbnRseSB0aGUgbGF0ZXN0IEFzdGVyaXNrIHZlcnNpb24gYW55IG9m IHRoZWlyIGN1c3RvbWVycyBhcmUgdXNpbmcgaXMgQXN0ZXJpc2sgMTEuDQoNCkhhdmUgYSBncmVh dCBkYXkhDQoNCkRhbg0KDQpGcm9tOiBhc3Rlcmlzay11c2Vycy1ib3VuY2VzQGxpc3RzLmRpZ2l1
bS5jb20gW21haWx0bzphc3Rlcmlzay11c2Vycy1ib3VuY2VzQGxpc3RzLmRpZ2l1bS5jb21dIE9u IEJlaGFsZiBPZiBHZW9yZ2UgSm9zZXBoDQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDEwLCAy MDE0IDI6NDAgUE0NClRvOiBBc3RlcmlzayBVc2VycyBNYWlsaW5nIExpc3QgLSBOb24tQ29tbWVy Y2lhbCBEaXNjdXNzaW9uDQpTdWJqZWN0OiBSZTogW2FzdGVyaXNrLXVzZXJzXSBQSlNJUCBjb25m aWd1cmF0aW9uIHF1ZXN0aW9uDQoNCg0KT24gV2VkLCBEZWMgMTAsIDIwMTQgYXQgMToyNyBQTSwg RGFuIENyb3BwIDxkYW5AYW10ZWxjby5jb208bWFpbHRvOmRhbkBhbXRlbGNvLmNvbT4+IHdyb3Rl Og0KTm90IHN1cmUgd2h5LCBidXQgVml0ZWxpdHkgY2hhbmdlZCB0aGUgc2V0dGluZ3MgdG8gSVAg YmFzZWQgYXV0aGVudGljYXRpb24gb24gbWUuICBIZXJlJ3MgdGhlIG5ldyBzaXAuY29uZiBzZXR0
aW5ncyB0aGV5IHNlbnQgbWUuDQoNCnR5cGU9ZnJpZW5kDQpkdG1mbW9kZT1hdXRvDQpob3N0PTY0
LjIuMTQyLjkzDQphbGxvdz1hbGwNCm5hdD15ZXMNCmNhbnJlaW52aXRlPW5vDQp0cnVzdHJwaWQ9
eWVzDQpzZW5kcnBpZD15ZXMNCg0KV2hlbiBJIHVzZSB0aGVzZSBzZXR0aW5ncyB0byBvcmlnaW5h dGUgY2FsbHMgdXNpbmcgdGhlIHNpcC5jb25mIHRoZXkgc2VudCBtZSwgZXZlcnl0aGluZyB3b3Jr cy4NCg0KQWN0aW9uOiBPcmlnaW5hdGUNCkFjdGlvbklEOiBTOA0KQ2hhbm5lbDogU0lQL291dGJv dW5kLnZpdGVsaXR5Lm5ldC84MDA1NTU1NTU1PGh0dHA6Ly9vdXRib3VuZC52aXRlbGl0eS5uZXQv ODAwNTU1NTU1NT4NCkV4dGVuOiBjcmVhdGVjYWxsDQpDb250ZXh0OiBUZXN0QXBwDQpQcmlvcml0
eTogMQ0KVGltZW91dDogNjAwMDANCkNhbGxlcklEOiBKb2huIERvZSA8MTIzND4NClZhcmlhYmxl OiBDQUxMRVJJRChudW0tcHJlcyk9YWxsb3dlZF9wYXNzZWRfc2NyZWVuZWQNCkFzeW5jOiB0cnVl DQoNCg0KSSB0cmFuc2xhdGVkIHRob3NlIHNldHRpbmdzIHRvIHRoZSBmb2xsb3dpbmcgZm9yIHBq c2lwLmNvbmYuLi4NCg0KW3RyYW5zcG9ydDFdDQp0eXBlID0gdHJhbnNwb3J0DQpiaW5kID0gMC4w LjAuMA0KcHJvdG9jb2wgPSB1ZHANCg0KW291dGJvdW5kLnZpdGVsaXR5Lm5ldDxodHRwOi8vb3V0
Ym91bmQudml0ZWxpdHkubmV0Pl0NCnR5cGUgPSBhb3INCnJlbW92ZV9leGlzdGluZyA9IHllcw0K
Y29udGFjdCA9IHNpcDo2NC4yLjE0Mi45M0A1MDYwDQoNCllvdSBtaWdodCB3YW50IHRvIHNldCBh IHF1YWxpZnlfZnJlcXVlbmN5IGhlcmUgIHRvIHNlZSBpZiB0aGUgc2VydmVyIHJlc3BvbmRzIHRv IE9QVElPTlMgbWVzc2FnZXMuICBBbHNvIDY0LjIuMTQyLjkzIGlzbid0IGN1cnJlbnRseSBvbmUg b2YgdGhlaXIgb3V0Ym91bmQgc2VydmVycy4gIEFyZSB5b3UgdXNpbmcgb25lIG9mIHRoZWlyIGlu Ym91bmQqIHNlcnZlcnMgYXMgb3V0Ym91bmQ/ICBJSVJDIHVubGVzcyB5b3UgYXNrIHRoZW0sIHRo ZXkgZG9uJ3QgYWxsb3cgaXQuDQoNCltvdXRib3VuZC52aXRlbGl0eS5uZXQ8aHR0cDovL291dGJv dW5kLnZpdGVsaXR5Lm5ldD5dDQp0eXBlID0gZW5kcG9pbnQNCmNvbnRleHQgPSBUZXN0QXBwDQp0
cmFuc3BvcnQgPSB0cmFuc3BvcnQxDQphb3JzID0gb3V0Ym91bmQudml0ZWxpdHkubmV0PGh0dHA6
Ly9vdXRib3VuZC52aXRlbGl0eS5uZXQ+DQpkdG1mX21vZGUgPSByZmM0NzMzDQpmb3JjZV9ycG9y dCA9IHllcw0KcnRwX3N5bW1ldHJpYyA9IHllcw0KcmV3cml0ZV9jb250YWN0ID0geWVzDQpzZW5k X3JwaWQgPSB5ZXMNCnRydXN0X2lkX2luYm91bmQgPSB5ZXMNCmFsbG93ID0gYWxsDQpkaXJlY3Rf bWVkaWEgPSBubw0KDQpbaWRlbnRpZnkxXQ0KdHlwZSA9IGlkZW50aWZ5DQplbmRwb2ludCA9IG91
dGJvdW5kLnZpdGVsaXR5Lm5ldDxodHRwOi8vb3V0Ym91bmQudml0ZWxpdHkubmV0Pg0KbWF0Y2gg PSA2NC4yLjE0Mi45Mw0KDQpXaGVuIEkgYXR0ZW1wdCB0byB1c2UgQU1JIE9yaWdpbmF0ZSwgaXQn cyBmYWlsaW5nLiAgSSBhbSBub3Qgc2VlaW5nIGFueXRoaW5nIHdpdGggcGpzaXAgbG9nZ2luZyB0
dXJuZWQgb24sIHNvIGl0IHNlZW1zIHRvIGJlIHNvbWV0aGluZyB3aXRoIHRoZSBzZXR0aW5ncy4N
Cg0KQWN0aW9uOiBPcmlnaW5hdGUNCkFjdGlvbklEOiBTOA0KQ2hhbm5lbDogUEpTSVAvb3V0Ym91
bmQudml0ZWxpdHkubmV0LzgwMDU1NTU1NTU8aHR0cDovL291dGJvdW5kLnZpdGVsaXR5Lm5ldC84
MDA1NTU1NTU1Pg0KRXh0ZW46IGNyZWF0ZWNhbGwNCkNvbnRleHQ6IFRlc3RBcHANClByaW9yaXR5
OiAxDQpUaW1lb3V0OiA2MDAwMA0KQ2FsbGVySUQ6IEpvaG4gRG9lIDwxMjM0Pg0KVmFyaWFibGU6
IENBTExFUklEKG51bS1wcmVzKT1hbGxvd2VkX3Bhc3NlZF9zY3JlZW5lZA0KQXN5bmM6IHRydWUN
Cg0KTk9URTogSSBhbSBhYmxlIHRvIHVzZSBBTUkgT3JpZ2luYXRlIHRvIG90aGVyIFBKU0lQIGVu ZHBvaW50cy4NCg0KQWN0aW9uOiBPcmlnaW5hdGUNCkFjdGlvbklEOiBTOQ0KQ2hhbm5lbDogUEpT
SVAvMTAwMy8xMDAzDQpFeHRlbjogY3JlYXRlY2FsbA0KQ29udGV4dDogVGVzdEFwcA0KUHJpb3Jp dHk6IDENClRpbWVvdXQ6IDYwMDAwDQpDYWxsZXJJRDogSm9obiBEb2UgPDEyMzQ+DQpWYXJpYWJs ZTogQ0FMTEVSSUQobnVtLXByZXMpPWFsbG93ZWRfcGFzc2VkX3NjcmVlbmVkDQpBc3luYzogdHJ1
ZQ0KDQpBbnlvbmUgaGF2ZSBhbnkgc3VnZ2VzdGlvbnMgYXMgdG8gd2hhdCBJIGFtIGRvaW5nIHdy b25nPw0KDQpIYXZlIGEgZ3JlYXQgZGF5IQ0KDQpEYW4NCg0KLS0NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KLS0g QmFuZHdpZHRoIGFuZCBDb2xvY2F0aW9uIFByb3ZpZGVkIGJ5IGh0dHA6Ly93d3cuYXBpLWRpZ2l0
YWwuY29tIC0tDQpOZXcgdG8gQXN0ZXJpc2s/IEpvaW4gdXMgZm9yIGEgbGl2ZSBpbnRyb2R1Y3Rv cnkgd2ViaW5hciBldmVyeSBUaHVyczoNCiAgICAgICAgICAgICAgIGh0dHA6Ly93d3cuYXN0ZXJp c2sub3JnL2hlbGxvDQoNCmFzdGVyaXNrLXVzZXJzIG1haWxpbmcgbGlzdA0KVG8gVU5TVUJTQ1JJ
QkUgb3IgdXBkYXRlIG9wdGlvbnMgdmlzaXQ6DQogICBodHRwOi8vbGlzdHMuZGlnaXVtLmNvbS9t YWlsbWFuL2xpc3RpbmZvL2FzdGVyaXNrLXVzZXJzDQoNCg=
Well, THAT’s not right. Did you obfuscate the 0.0.19.196 or is that how it really is? Are you NATed?
This is incorrect. The contact should be:
contact = sip:64.2.142.93
It will use a default port of 5060.
I also believe I’ve covered your origination issue in a separate email. Your dial string should be:
PJSIP/8005555555@outbound.vitelity.net
Cheers,
Thank you Joshua.
I will make the modifications this morning and give it a try.
Have a great day!
Dan
—–Original Message—
VGhhbmtzIEdlb3JnZS4NCg0KSSBhbSBOQVRlZC4NCkkgZGlkIG5vdCBvYmZ1c2NhdGUgdGhlIDAu MC4xOS4xOTYuICBUaGF0IGlzIHJlYWxseSB3aGF0IGlzIHNob3dpbmcgdXAuDQpUaGUgb25seSBw b3J0aW9uIHRoYXQgSSBoaWQgaXMgdGhlIElQIGFkZHJlc3Mgb2YgbXkgYm94Lg0KDQpIYXZlIGEg Z3JlYXQgZGF5IQ0KDQpEYW4NCg0KDQpPbiBXZWQsIERlYyAxMCwgMjAxNCBhdCAyOjAzIFBNLCBE
YW4gQ3JvcHAgPGRhbkBhbXRlbGNvLmNvbTxtYWlsdG86ZGFuQGFtdGVsY28uY29tPj4gd3JvdGU6
DQpUaGFua3MgR2VvcmdlLg0KDQpUaGF0IHdhcyB0aGUgaXAgYWRkcmVzcyBJIHdhcyBnaXZlbi4g IFVuZm9ydHVuYXRlbHksIG15IGNvbnRhY3QgYXQgVml0ZWxpdHkgaXMgZ29uZSBmb3IgdGhlIGRh eSBzbyBJIGNhbuKAmXQgdmVyaWZ5IGl0IHdpdGggaGltLg0KDQpJIGFkZGVkIHRoZSBxdWFsaWZ5
X2ZyZXF1ZW5jeSBhcyB5b3Ugc3VnZ2VzdGVkIGFuZCBpdCBkb2VzIGFwcGVhciB0aGF0IEkgaGF2
ZSBzb21ldGhpbmcgY29uZmlndXJlZCBpbmNvcnJlY3RseeKApi4NCg0KPC0tLSBUcmFuc21pdHRp bmcgU0lQIHJlcXVlc3QgKDQ4MyBieXRlcykgdG8gVURQOjAuMC4xOS4xOTY6NTA2MDxodHRwOi8v MC4wLjE5LjE5Njo1MDYwPiAtLS0+DQoNCldlbGwsIFRIQVQncyBub3QgcmlnaHQuICBEaWQgeW91
IG9iZnVzY2F0ZSB0aGUgMC4wLjE5LjE5NiBvciBpcyB0aGF0IGhvdyBpdCByZWFsbHkgaXM/ICBB
cmUgeW91IE5BVGVkPw0KDQoNCk9QVElPTlMgc2lwOjY0LjIuMTQyLjkzQDUwNjAgU0lQLzIuMA0K
VmlhOiBTSVAvMi4wL1VEUCB4eHgueHh4Lnh4Lnh4eDo1MDYwO3Jwb3J0O2JyYW5jaD16OWhHNGJL
UGpjZWE2MzkxNC1iOGQxLTQ4M2QtOTZkYi0xMTk2OGFiYWI3MDQNCkZyb206IDxzaXA6ZTMxZDU4
MDktZjI2YS00MjE5LTgzNjUtNzA5MzE0MjgwNzJiQHh4eC54eHgueHgueHh4Pjt0YWc9N2NmYWIz YmEtNzNkZS00MjQzLTk5NjctZDFlNmE1ZTdiMGI0DQpUbzogPHNpcDo2NC4yLjE0Mi45M0A1MDYw Pg0KQ29udGFjdDogPHNpcDplMzFkNTgwOS1mMjZhLTQyMTktODM2NS03MDkzMTQyODA3MmJAeHh4
Lnh4eC54eC54eHg6NTA2MD4NCkNhbGwtSUQ6IDdiYTc2NmJmLTM2M2ItNDdkMC1hMzg4LTYyYTU4
ZDFkZjg4ZA0KQ1NlcTogMzM3NzggT1BUSU9OUw0KTWF4LUZvcndhcmRzOiA3MA0KVXNlci1BZ2Vu dDogQXN0ZXJpc2sgUEJYIDEzLjAuMA0KQ29udGVudC1MZW5ndGg6ICAwDQoNCg0K
This fixed the problem.
Developer before me wrote some code to build up the dial string. Always thought that string appeared off, but it worked so I left it alone.
Thanks Joshua and George for helping with this.
Have a great day!
Dan
—–Original Message—
Ok, it didn’t quite solve everything.
There is one slight issue. When I answer the call on my cell phone, Asterisk sees it as answered. I can play audio, send dtmfs, etc and hear it on my phone. However, a short while later, Vitelity tears down that call and Asterisk is never notified about it.
I tell Asterisk to hang up the call (via AMI) and it is removed from Asterisk.
I gather the pjsip trace. Then, I shut down that VM, fired up another running chan_sip. Did the same behavior and gathered the sip trace. Using chan_sip, the call worked flawlessly.
Vitelity sends Asterisk the ACK (for the answer). Asterisk send an ACK in response. For the sip.conf system, the ACK includes the Contact for the response. For PJSIP, the Contact field is not in the ACK
Is there a setting to indicate whether the Contact field should be sent as part of the ACK (response to the OK)?
Have a great day!
Dan
—–Original Message—
I had my screenshots flipped. Is there a way to make sure the Contact field is NOT included in the ACK response to the OK (for the Answer)?
PJSIP is including the Contact for the ACK response to the OK. Contact:
When using the chan_sip, it does not include that field in the ACK response to the OK.
(Been a long couple weeks)
Have a great day!
Dan
—–Original Message—
Dan Cropp wrote:
There is no configuration option to configure this behavior. What is the full SIP signaling?
I am not sure what you mean by the ful SIP signaling?
Here is the trace for the sip.conf which works successfully. Below that, I will include the trace for the pjsip.conf which it seems Vitelity isn’t accepting the ACK in response to the OK
—- SIP –
Ugh.
I’m having a bad day. The two traces were swapped.
The one on Asterisk 13 is PJSIP. The one on Asterisk 12 is using chan_sip.
—–Original Message—
Trying this again after my first away from work in a couple weeks.
Running Asterisk 13.0.0
IP authentication with Vitelity
I can Originate with sip, but not pjsip. Here is the sip settings and trace.
Action: Originate ActionID: S8
Channel: SIP/8005555555@outbound.vitelity.net Exten: createcall Context: TestApp Priority: 1
Timeout: 60000
CallerID: John Doe <1234>
Variable: CALLERID(num-pres)=allowed_passed_screen Async: true
sip.conf
[HVout]
type=friend dtmfmode=auto host=64.2.142.93
disallow=all allow=ulaw canreinvite=no trustrpid=yes sendrpid=yes nat=yes context=TestApp
== Using SIP RTP CoS mark 5;tag=as466267de To:
Audio is at 18226
Adding codec ulaw to SDP
Adding codec alaw to SDP
Adding codec gsm to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 64.2.142.189:5060:
INVITE sip:8005555555@outbound.vitelity.net SIP/2.0
Via: SIP/2.0/UDP 192.168.11.166:5060;branch=z9hG4bK40275183
Max-Forwards: 70
From: “John Doe”
Contact:
Call-ID: 59e9eff8339e32af271c23541298135d@192.168.11.166:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 13.0.0
Date: Sun, 21 Dec 2014 20:06:57 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer Content-Type: application/sdp Content-Length: 290
v=0
o=root 1422632184 1422632184 IN IP4 192.168.11.166
s=Asterisk PBX 13.0.0
c=IN IP4 192.168.11.166
t=0 0
m=audio 18226 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:150
a=sendrecv
–
I am running PJPROJECT 2.3 and Asterisk 13.0.0.
I answer the call, about 15 seconds later, vitality hangs up on my cell phone. However, Asterisk is never notified When the OK (for the answer) occurs, the ACK seems to never be accepted. The OK recvd with ACK sent occurs several times.
Here are the pjsip.conf settings…
[global]
type = global debug = yes
[transport1]
type = transport bind = 0.0.0.0
protocol = udp
[outbound.vitelity.net]
type = aor remove_existing = yes qualify_frequency = 60
contact = sip:64.2.142.93
[outbound.vitelity.net]
type = endpoint context = TestApp transport = transport1
aors = outbound.vitelity.net dtmf_mode = rfc4733
force_rport = yes rtp_symmetric = yes rewrite_contact = yes send_rpid = yes trust_id_inbound = yes disallow = all allow = ulaw direct_media = no
[outbound.vitelity.net]
type = identify endpoint = outbound.vitelity.net match = 64.2.142.93
When I Originate a call via AMI…
Action: Originate ActionID: S8
Channel: PJSIP/8005555555@outbound.vitelity.net
Exten: createcall Context: TestApp Priority: 1
Timeout: 60000
CallerID: John Doe <1234>
Variable: CALLERID(num-pres)=allowed_passed_screen Async: true The call goes through to my cell phone. I answer on my cell phone and Asterisk sees the call being answered. However, Vitelity disconnects the cell phone about 15 seconds later. When looking at the PJSIP trace, the ACK repsonse to the 200 OK (Answer) are missing the Contact header. From what I understand that is likely the reason Vitelity doesn’t seem to process the ACK.
*CLI> — Called 8005555555@outbound.vitelity.net;tag=340be959-af87-4b77-a7a7-8aaf83940b03;privacy=off;screen=no Max-Forwards: 70
<--- Transmitting SIP request (1018 bytes) to UDP:64.2.142.93:5060 --->
INVITE sip:8005555555@64.2.142.93 SIP/2.0
Via: SIP/2.0/UDP 192.168.11.166:5060;rport;branch=z9hG4bKPjc0fc94dc-bde3-441c-8a58-cd71e2d326f2
From: “John Doe”
To:
Contact:
Call-ID: e443f2a6-8f80-4493-b12b-22c48247c125
CSeq: 10207 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, REGISTER, MESSAGE
Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800
Min-SE: 90
Remote-Party-ID: “John Doe”
User-Agent: Asterisk PBX 13.0.0
Content-Type: application/sdp Content-Length: 241
v=0
o=- 2134048799 2134048799 IN IP4 192.168.11.166
s=Asterisk c=IN IP4 192.168.11.166
t=0 0
m=audio 16262 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
<--- Received SIP response (384 bytes) from UDP:64.2.142.93:5060 --->;tag=340be959-af87-4b77-a7a7-8aaf83940b03
SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 192.168.11.166:5060;rport=5060;branch=z9hG4bKPjc0fc94dc-bde3-441c-8a58-cd71e2d326f2
From: “John Doe”
To:
Call-ID: e443f2a6-8f80-4493-b12b-22c48247c125
CSeq: 10207 INVITE
Server: OpenSIPS (1.6.4-2-notls (x86_64/linux))
Content-Length: 0
<--- Received SIP response (851 bytes) from UDP:64.2.142.93:5060 --->;tag=340be959-af87-4b77-a7a7-8aaf83940b03;tag=as466c6135
SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 192.168.11.166:5060;received=192.168.11.166;rport=5060;branch=z9hG4bKPjc0fc94dc-bde3-441c-8a58-cd71e2d326f2
Record-Route:
From: “John Doe”
To:
Call-ID: e443f2a6-8f80-4493-b12b-22c48247c125
CSeq: 10207 INVITE
User-Agent: packetrino Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces Contact:
Content-Type: application/sdp Content-Length: 240
v=0
o=root 3457 3457 IN IP4 66.241.99.145
s=session c=IN IP4 66.241.99.145
t=0 0
m=audio 11872 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off – – – –
a=ptime:20
a=sendrecv
— PJSIP/outbound.vitelity.net-00000000 is making progress;tag=340be959-af87-4b77-a7a7-8aaf83940b03;tag=as466c6135
> 0x60fc840 — Probation passed – setting RTP source address to 66.241.99.145:11872
<--- Received SIP response (837 bytes) from UDP:64.2.142.93:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.11.166:5060;received=192.168.11.166;rport=5060;branch=z9hG4bKPjc0fc94dc-bde3-441c-8a58-cd71e2d326f2
Record-Route:
From: “John Doe”
To:
Call-ID: e443f2a6-8f80-4493-b12b-22c48247c125
CSeq: 10207 INVITE
User-Agent: packetrino Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces Contact:
Content-Type: application/sdp Content-Length: 240
v=0
o=root 3457 3458 IN IP4 66.241.99.145
s=session c=IN IP4 66.241.99.145
t=0 0
m=audio 11872 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off – – – –
a=ptime:20
a=sendrecv
<--- Transmitting SIP request (443 bytes) to UDP:64.2.142.93:5060 --->;tag=340be959-af87-4b77-a7a7-8aaf83940b03;tag=as466c6135
ACK sip:18005555555@64.2.142.93:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.11.166:5060;rport;branch=z9hG4bKPj5fa1c45c-fb91-4d87-aa6b-9ae451dcd211
From: “John Doe”
To:
Call-ID: e443f2a6-8f80-4493-b12b-22c48247c125
CSeq: 10207 ACK
Route:
Max-Forwards: 70
User-Agent: Asterisk PBX 13.0.0
Content-Length: 0
— PJSIP/outbound.vitelity.net-00000000 answered
— Executing [createcall@TestApp:1] Set(“PJSIP/outbound.vitelity.net-00000000”, “EXTIVR=”) in new stack
— Executing [createcall@TestApp:2] AGI(“PJSIP/outbound.vitelity.net-00000000”, “agi:async”) in new stack
Today, I tried the same behavior on Asterisk 13.1.0 and Asterisk 12.2.0.
Same problem is happening with both of them.
Could this be caused by PJPROJECT 2.3?
Anyone have any suggestions for what I can try?
My boss is giving me until tomorrow to get the PJSIP support working with Vitelity. Otherwise, he’s told me to go back to using chan_sip and wait a year or two for PJSIP to be in the field more.
Have a great day!
Dan
I have a Vitelity account I can try. Re-post your pjsip config and I’ll try it now.
SGkgR2VvcmdlLA0KDQpUaGFuayB5b3UgZm9yIGxvb2tpbmcgaW50byB0aGlzLg0KVGhpcyBpcyBi ZWhpbmQgYSBuYXTigKYNCg0KW2dsb2JhbF0NCnR5cGUgPSBnbG9iYWwNCmRlYnVnID0geWVzDQoN
Clt0cmFuc3BvcnQxXQ0KdHlwZSA9IHRyYW5zcG9ydA0KYmluZCA9IDAuMC4wLjANCnByb3RvY29s ID0gdWRwDQoNCltvdXRib3VuZC52aXRlbGl0eS5uZXRdDQp0eXBlID0gYW9yDQpyZW1vdmVfZXhp c3RpbmcgPSB5ZXMNCnF1YWxpZnlfZnJlcXVlbmN5ID0gNjANCmNvbnRhY3QgPSBzaXA6NjQuMi4x NDIuOTMNCg0KW291dGJvdW5kLnZpdGVsaXR5Lm5ldF0NCnR5cGUgPSBlbmRwb2ludA0KY29udGV4
dCA9IFRlc3RBcHANCnRyYW5zcG9ydCA9IHRyYW5zcG9ydDENCmFvcnMgPSBvdXRib3VuZC52aXRl bGl0eS5uZXQNCmR0bWZfbW9kZSA9IHJmYzQ3MzMNCmZvcmNlX3Jwb3J0ID0geWVzDQpydHBfc3lt bWV0cmljID0geWVzDQpyZXdyaXRlX2NvbnRhY3QgPSB5ZXMNCnNlbmRfcnBpZCA9IHllcw0KdHJ1
c3RfaWRfaW5ib3VuZCA9IHllcw0KZGlzYWxsb3cgPSBhbGwNCmFsbG93ID0gdWxhdw0KZGlyZWN0
X21lZGlhID0gbm8NCg0KW291dGJvdW5kLnZpdGVsaXR5Lm5ldF0NCnR5cGUgPSBpZGVudGlmeQ0K
ZW5kcG9pbnQgPSBvdXRib3VuZC52aXRlbGl0eS5uZXQNCm1hdGNoID0gNjQuMi4xNDIuOTMNCg0K
SGF2ZSBhIGdyZWF0IGRheSENCg0KRGFuDQoNCkZyb206IGFzdGVyaXNrLXVzZXJzLWJvdW5jZXNA
bGlzdHMuZGlnaXVtLmNvbSBbbWFpbHRvOmFzdGVyaXNrLXVzZXJzLWJvdW5jZXNAbGlzdHMuZGln aXVtLmNvbV0gT24gQmVoYWxmIE9mIEdlb3JnZSBKb3NlcGgNClNlbnQ6IE1vbmRheSwgRGVjZW1i ZXIgMTUsIDIwMTQgMzo0MCBQTQ0KVG86IEFzdGVyaXNrIFVzZXJzIE1haWxpbmcgTGlzdCAtIE5v bi1Db21tZXJjaWFsIERpc2N1c3Npb24NClN1YmplY3Q6IFJlOiBbYXN0ZXJpc2stdXNlcnNdIFBK
U0lQIGNvbmZpZ3VyYXRpb24gcXVlc3Rpb24NCg0KT24gTW9uLCBEZWMgMTUsIDIwMTQgYXQgMjow OCBQTSwgRGFuIENyb3BwIDxkYW5AYW10ZWxjby5jb208bWFpbHRvOmRhbkBhbXRlbGNvLmNvbT4+
IHdyb3RlOg0KVG9kYXksIEkgdHJpZWQgdGhlIHNhbWUgYmVoYXZpb3Igb24gQXN0ZXJpc2sgMTMu MS4wIGFuZCBBc3RlcmlzayAxMi4yLjAuDQoNClNhbWUgcHJvYmxlbSBpcyBoYXBwZW5pbmcgd2l0
aCBib3RoIG9mIHRoZW0uDQoNCkNvdWxkIHRoaXMgYmUgY2F1c2VkIGJ5IFBKUFJPSkVDVCAyLjM/
DQoNCkFueW9uZSBoYXZlIGFueSBzdWdnZXN0aW9ucyBmb3Igd2hhdCBJIGNhbiB0cnk/DQoNCk15
IGJvc3MgaXMgZ2l2aW5nIG1lIHVudGlsIHRvbW9ycm93IHRvIGdldCB0aGUgUEpTSVAgc3VwcG9y dCB3b3JraW5nIHdpdGggVml0ZWxpdHkuICBPdGhlcndpc2UsIGhl4oCZcyB0b2xkIG1lIHRvIGdv IGJhY2sgdG8gdXNpbmcgY2hhbl9zaXAgYW5kIHdhaXQgYSB5ZWFyIG9yIHR3byBmb3IgUEpTSVAg dG8gYmUgaW4gdGhlIGZpZWxkIG1vcmUuDQoNCkkgaGF2ZSBhIFZpdGVsaXR5IGFjY291bnQgSSBj YW4gdHJ5LiAgUmUtcG9zdCB5b3VyIHBqc2lwIGNvbmZpZyBhbmQgSSdsbCB0cnkgaXQgbm93Lg0K
DQoNCg0KSGF2ZSBhIGdyZWF0IGRheSENCg0KRGFuDQoNCi0tDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCi0tIEJh bmR3aWR0aCBhbmQgQ29sb2NhdGlvbiBQcm92aWRlZCBieSBodHRwOi8vd3d3LmFwaS1kaWdpdGFs LmNvbSAtLQ0KTmV3IHRvIEFzdGVyaXNrPyBKb2luIHVzIGZvciBhIGxpdmUgaW50cm9kdWN0b3J5
IHdlYmluYXIgZXZlcnkgVGh1cnM6DQogICAgICAgICAgICAgICBodHRwOi8vd3d3LmFzdGVyaXNr Lm9yZy9oZWxsbw0KDQphc3Rlcmlzay11c2VycyBtYWlsaW5nIGxpc3QNClRvIFVOU1VCU0NSSUJF
IG9yIHVwZGF0ZSBvcHRpb25zIHZpc2l0Og0KICAgaHR0cDovL2xpc3RzLmRpZ2l1bS5jb20vbWFp bG1hbi9saXN0aW5mby9hc3Rlcmlzay11c2Vycw0K
Just to be clear…both the pbx and local endpoints are behind the same NAT?
WWVzLCBldmVyeXRoaW5nIGlzIGJlaGluZCB0aGUgc2FtZSBOQVQuDQoNCkZvciB0aGUgYXBwbGlj YXRpb24gSeKAmW0gd29ya2luZyBvbiwgdGhlIG9ubHkgZW5kcG9pbnQgaXMgdGhlIGVuZHBvaW50
IHRvIFZpdGVsaXR5Lg0KV2UgdXNlIEFNSSB0byBPcmlnaW5hdGUgY2FsbHMgZnJvbSBBc3Rlcmlz ayBlbmRwb2ludCB0aHJvdWdoIFZpdGVsaXR5IHRvIHBob25lcy4NCkFmdGVyIHRoYXQsIHdlIGNv bnRyb2wgdGhlIGNhbGwgdGhyb3VnaCBBTUkgdG8gcGVyZm9ybSB0aGUgd29yayB3ZSBuZWVkLg0K
DQoNCg0KRnJvbTogYXN0ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5kaWdpdW0uY29tIFttYWls dG86YXN0ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5kaWdpdW0uY29tXSBPbiBCZWhhbGYgT2Yg R2VvcmdlIEpvc2VwaA0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAxNSwgMjAxNCA0OjQyIFBNDQpU
bzogQXN0ZXJpc2sgVXNlcnMgTWFpbGluZyBMaXN0IC0gTm9uLUNvbW1lcmNpYWwgRGlzY3Vzc2lv bg0KU3ViamVjdDogUmU6IFthc3Rlcmlzay11c2Vyc10gUEpTSVAgY29uZmlndXJhdGlvbiBxdWVz dGlvbg0KDQoNCg0KT24gTW9uLCBEZWMgMTUsIDIwMTQgYXQgMzozMyBQTSwgRGFuIENyb3BwIDxk YW5AYW10ZWxjby5jb208bWFpbHRvOmRhbkBhbXRlbGNvLmNvbT4+IHdyb3RlOg0KSGkgR2Vvcmdl LA0KDQpUaGFuayB5b3UgZm9yIGxvb2tpbmcgaW50byB0aGlzLg0KVGhpcyBpcyBiZWhpbmQgYSBu YXTigKYNCg0KDQpKdXN0IHRvIGJlIGNsZWFyLi4uYm90aCB0aGUgcGJ4IGFuZCBsb2NhbCBlbmRw b2ludHMgYXJlIGJlaGluZCB0aGUgc2FtZSBOQVQ/DQoNCg0KW2dsb2JhbF0NCnR5cGUgPSBnbG9i YWwNCmRlYnVnID0geWVzDQoNClt0cmFuc3BvcnQxXQ0KdHlwZSA9IHRyYW5zcG9ydA0KYmluZCA9
IDAuMC4wLjANCnByb3RvY29sID0gdWRwDQoNCltvdXRib3VuZC52aXRlbGl0eS5uZXQ8aHR0cDov L291dGJvdW5kLnZpdGVsaXR5Lm5ldD5dDQp0eXBlID0gYW9yDQpyZW1vdmVfZXhpc3RpbmcgPSB5
ZXMNCnF1YWxpZnlfZnJlcXVlbmN5ID0gNjANCmNvbnRhY3QgPSBzaXA6NjQuMi4xNDIuOTMNCg0K
W291dGJvdW5kLnZpdGVsaXR5Lm5ldDxodHRwOi8vb3V0Ym91bmQudml0ZWxpdHkubmV0Pl0NCnR5
cGUgPSBlbmRwb2ludA0KY29udGV4dCA9IFRlc3RBcHANCnRyYW5zcG9ydCA9IHRyYW5zcG9ydDEN
CmFvcnMgPSBvdXRib3VuZC52aXRlbGl0eS5uZXQ8aHR0cDovL291dGJvdW5kLnZpdGVsaXR5Lm5l dD4NCmR0bWZfbW9kZSA9IHJmYzQ3MzMNCmZvcmNlX3Jwb3J0ID0geWVzDQpydHBfc3ltbWV0cmlj ID0geWVzDQpyZXdyaXRlX2NvbnRhY3QgPSB5ZXMNCnNlbmRfcnBpZCA9IHllcw0KdHJ1c3RfaWRf aW5ib3VuZCA9IHllcw0KZGlzYWxsb3cgPSBhbGwNCmFsbG93ID0gdWxhdw0KZGlyZWN0X21lZGlh ID0gbm8NCg0KW291dGJvdW5kLnZpdGVsaXR5Lm5ldDxodHRwOi8vb3V0Ym91bmQudml0ZWxpdHku bmV0Pl0NCnR5cGUgPSBpZGVudGlmeQ0KZW5kcG9pbnQgPSBvdXRib3VuZC52aXRlbGl0eS5uZXQ8
aHR0cDovL291dGJvdW5kLnZpdGVsaXR5Lm5ldD4NCm1hdGNoID0gNjQuMi4xNDIuOTMNCg0KSGF2
ZSBhIGdyZWF0IGRheSENCg0KRGFuDQoNCkZyb206IGFzdGVyaXNrLXVzZXJzLWJvdW5jZXNAbGlz dHMuZGlnaXVtLmNvbTxtYWlsdG86YXN0ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5kaWdpdW0u Y29tPiBbbWFpbHRvOmFzdGVyaXNrLXVzZXJzLWJvdW5jZXNAbGlzdHMuZGlnaXVtLmNvbTxtYWls dG86YXN0ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5kaWdpdW0uY29tPl0gT24gQmVoYWxmIE9m IEdlb3JnZSBKb3NlcGgNClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMTUsIDIwMTQgMzo0MCBQTQ0K
VG86IEFzdGVyaXNrIFVzZXJzIE1haWxpbmcgTGlzdCAtIE5vbi1Db21tZXJjaWFsIERpc2N1c3Np b24NClN1YmplY3Q6IFJlOiBbYXN0ZXJpc2stdXNlcnNdIFBKU0lQIGNvbmZpZ3VyYXRpb24gcXVl c3Rpb24NCg0KT24gTW9uLCBEZWMgMTUsIDIwMTQgYXQgMjowOCBQTSwgRGFuIENyb3BwIDxkYW5A
YW10ZWxjby5jb208bWFpbHRvOmRhbkBhbXRlbGNvLmNvbT4+IHdyb3RlOg0KVG9kYXksIEkgdHJp ZWQgdGhlIHNhbWUgYmVoYXZpb3Igb24gQXN0ZXJpc2sgMTMuMS4wIGFuZCBBc3RlcmlzayAxMi4y LjAuDQoNClNhbWUgcHJvYmxlbSBpcyBoYXBwZW5pbmcgd2l0aCBib3RoIG9mIHRoZW0uDQoNCkNv dWxkIHRoaXMgYmUgY2F1c2VkIGJ5IFBKUFJPSkVDVCAyLjM/DQoNCkFueW9uZSBoYXZlIGFueSBz dWdnZXN0aW9ucyBmb3Igd2hhdCBJIGNhbiB0cnk/DQoNCk15IGJvc3MgaXMgZ2l2aW5nIG1lIHVu dGlsIHRvbW9ycm93IHRvIGdldCB0aGUgUEpTSVAgc3VwcG9ydCB3b3JraW5nIHdpdGggVml0ZWxp dHkuICBPdGhlcndpc2UsIGhl4oCZcyB0b2xkIG1lIHRvIGdvIGJhY2sgdG8gdXNpbmcgY2hhbl9z aXAgYW5kIHdhaXQgYSB5ZWFyIG9yIHR3byBmb3IgUEpTSVAgdG8gYmUgaW4gdGhlIGZpZWxkIG1v cmUuDQoNCkkgaGF2ZSBhIFZpdGVsaXR5IGFjY291bnQgSSBjYW4gdHJ5LiAgUmUtcG9zdCB5b3Vy IHBqc2lwIGNvbmZpZyBhbmQgSSdsbCB0cnkgaXQgbm93Lg0KDQoNCg0KSGF2ZSBhIGdyZWF0IGRh eSENCg0KRGFuDQoNCi0tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCi0tIEJhbmR3aWR0aCBhbmQgQ29sb2NhdGlv biBQcm92aWRlZCBieSBodHRwOi8vd3d3LmFwaS1kaWdpdGFsLmNvbSAtLQ0KTmV3IHRvIEFzdGVy aXNrPyBKb2luIHVzIGZvciBhIGxpdmUgaW50cm9kdWN0b3J5IHdlYmluYXIgZXZlcnkgVGh1cnM6
DQogICAgICAgICAgICAgICBodHRwOi8vd3d3LmFzdGVyaXNrLm9yZy9oZWxsbw0KDQphc3Rlcmlz ay11c2VycyBtYWlsaW5nIGxpc3QNClRvIFVOU1VCU0NSSUJFIG9yIHVwZGF0ZSBvcHRpb25zIHZp c2l0Og0KICAgaHR0cDovL2xpc3RzLmRpZ2l1bS5jb20vbWFpbG1hbi9saXN0aW5mby9hc3Rlcmlz ay11c2Vycw0KDQotLQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQotLSBCYW5kd2lkdGggYW5kIENvbG9jYXRpb24g UHJvdmlkZWQgYnkgaHR0cDovL3d3dy5hcGktZGlnaXRhbC5jb20gLS0NCk5ldyB0byBBc3Rlcmlz az8gSm9pbiB1cyBmb3IgYSBsaXZlIGludHJvZHVjdG9yeSB3ZWJpbmFyIGV2ZXJ5IFRodXJzOg0K
ICAgICAgICAgICAgICAgaHR0cDovL3d3dy5hc3Rlcmlzay5vcmcvaGVsbG8NCg0KYXN0ZXJpc2st dXNlcnMgbWFpbGluZyBsaXN0DQpUbyBVTlNVQlNDUklCRSBvciB1cGRhdGUgb3B0aW9ucyB2aXNp dDoNCiAgIGh0dHA6Ly9saXN0cy5kaWdpdW0uY29tL21haWxtYW4vbGlzdGluZm8vYXN0ZXJpc2st dXNlcnMNCg=
And it’s outbound calls that aren’t working right?
WWVzLCBvdXRib3VuZCBjYWxscyBhcmUgdGhlIG9ubHkgb25lcyBJ4oCZbSB0cnlpbmcuDQoNCg0K
RnJvbTogYXN0ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5kaWdpdW0uY29tIFttYWlsdG86YXN0
ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5kaWdpdW0uY29tXSBPbiBCZWhhbGYgT2YgR2Vvcmdl IEpvc2VwaA0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAxNSwgMjAxNCA0OjU5IFBNDQpUbzogQXN0
ZXJpc2sgVXNlcnMgTWFpbGluZyBMaXN0IC0gTm9uLUNvbW1lcmNpYWwgRGlzY3Vzc2lvbg0KU3Vi amVjdDogUmU6IFthc3Rlcmlzay11c2Vyc10gUEpTSVAgY29uZmlndXJhdGlvbiBxdWVzdGlvbg0K
DQoNCg0KT24gTW9uLCBEZWMgMTUsIDIwMTQgYXQgMzo1NCBQTSwgRGFuIENyb3BwIDxkYW5AYW10
ZWxjby5jb208bWFpbHRvOmRhbkBhbXRlbGNvLmNvbT4+IHdyb3RlOg0KWWVzLCBldmVyeXRoaW5n IGlzIGJlaGluZCB0aGUgc2FtZSBOQVQuDQoNCkZvciB0aGUgYXBwbGljYXRpb24gSeKAmW0gd29y a2luZyBvbiwgdGhlIG9ubHkgZW5kcG9pbnQgaXMgdGhlIGVuZHBvaW50IHRvIFZpdGVsaXR5Lg0K
V2UgdXNlIEFNSSB0byBPcmlnaW5hdGUgY2FsbHMgZnJvbSBBc3RlcmlzayBlbmRwb2ludCB0aHJv dWdoIFZpdGVsaXR5IHRvIHBob25lcy4NCkFmdGVyIHRoYXQsIHdlIGNvbnRyb2wgdGhlIGNhbGwg dGhyb3VnaCBBTUkgdG8gcGVyZm9ybSB0aGUgd29yayB3ZSBuZWVkLg0KDQoNCkFuZCBpdCdzIG91
dGJvdW5kIGNhbGxzIHRoYXQgYXJlbid0IHdvcmtpbmcgcmlnaHQ/DQoNCg0KDQpGcm9tOiBhc3Rl cmlzay11c2Vycy1ib3VuY2VzQGxpc3RzLmRpZ2l1bS5jb208bWFpbHRvOmFzdGVyaXNrLXVzZXJz LWJvdW5jZXNAbGlzdHMuZGlnaXVtLmNvbT4gW21haWx0bzphc3Rlcmlzay11c2Vycy1ib3VuY2Vz QGxpc3RzLmRpZ2l1bS5jb208bWFpbHRvOmFzdGVyaXNrLXVzZXJzLWJvdW5jZXNAbGlzdHMuZGln aXVtLmNvbT5dIE9uIEJlaGFsZiBPZiBHZW9yZ2UgSm9zZXBoDQpTZW50OiBNb25kYXksIERlY2Vt YmVyIDE1LCAyMDE0IDQ6NDIgUE0NClRvOiBBc3RlcmlzayBVc2VycyBNYWlsaW5nIExpc3QgLSBO
b24tQ29tbWVyY2lhbCBEaXNjdXNzaW9uDQpTdWJqZWN0OiBSZTogW2FzdGVyaXNrLXVzZXJzXSBQ
SlNJUCBjb25maWd1cmF0aW9uIHF1ZXN0aW9uDQoNCg0KDQpPbiBNb24sIERlYyAxNSwgMjAxNCBh dCAzOjMzIFBNLCBEYW4gQ3JvcHAgPGRhbkBhbXRlbGNvLmNvbTxtYWlsdG86ZGFuQGFtdGVsY28u Y29tPj4gd3JvdGU6DQpIaSBHZW9yZ2UsDQoNClRoYW5rIHlvdSBmb3IgbG9va2luZyBpbnRvIHRo aXMuDQpUaGlzIGlzIGJlaGluZCBhIG5hdOKApg0KDQoNCkp1c3QgdG8gYmUgY2xlYXIuLi5ib3Ro IHRoZSBwYnggYW5kIGxvY2FsIGVuZHBvaW50cyBhcmUgYmVoaW5kIHRoZSBzYW1lIE5BVD8NCg0K
DQpbZ2xvYmFsXQ0KdHlwZSA9IGdsb2JhbA0KZGVidWcgPSB5ZXMNCg0KW3RyYW5zcG9ydDFdDQp0
eXBlID0gdHJhbnNwb3J0DQpiaW5kID0gMC4wLjAuMA0KcHJvdG9jb2wgPSB1ZHANCg0KW291dGJv dW5kLnZpdGVsaXR5Lm5ldDxodHRwOi8vb3V0Ym91bmQudml0ZWxpdHkubmV0Pl0NCnR5cGUgPSBh b3INCnJlbW92ZV9leGlzdGluZyA9IHllcw0KcXVhbGlmeV9mcmVxdWVuY3kgPSA2MA0KY29udGFj dCA9IHNpcDo2NC4yLjE0Mi45Mw0KDQpbb3V0Ym91bmQudml0ZWxpdHkubmV0PGh0dHA6Ly9vdXRi b3VuZC52aXRlbGl0eS5uZXQ+XQ0KdHlwZSA9IGVuZHBvaW50DQpjb250ZXh0ID0gVGVzdEFwcA0K
dHJhbnNwb3J0ID0gdHJhbnNwb3J0MQ0KYW9ycyA9IG91dGJvdW5kLnZpdGVsaXR5Lm5ldDxodHRw Oi8vb3V0Ym91bmQudml0ZWxpdHkubmV0Pg0KZHRtZl9tb2RlID0gcmZjNDczMw0KZm9yY2VfcnBv cnQgPSB5ZXMNCnJ0cF9zeW1tZXRyaWMgPSB5ZXMNCnJld3JpdGVfY29udGFjdCA9IHllcw0Kc2Vu ZF9ycGlkID0geWVzDQp0cnVzdF9pZF9pbmJvdW5kID0geWVzDQpkaXNhbGxvdyA9IGFsbA0KYWxs b3cgPSB1bGF3DQpkaXJlY3RfbWVkaWEgPSBubw0KDQpbb3V0Ym91bmQudml0ZWxpdHkubmV0PGh0
dHA6Ly9vdXRib3VuZC52aXRlbGl0eS5uZXQ+XQ0KdHlwZSA9IGlkZW50aWZ5DQplbmRwb2ludCA9
IG91dGJvdW5kLnZpdGVsaXR5Lm5ldDxodHRwOi8vb3V0Ym91bmQudml0ZWxpdHkubmV0Pg0KbWF0
Y2ggPSA2NC4yLjE0Mi45Mw0KDQpIYXZlIGEgZ3JlYXQgZGF5IQ0KDQpEYW4NCg0KRnJvbTogYXN0
ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5kaWdpdW0uY29tPG1haWx0bzphc3Rlcmlzay11c2Vy cy1ib3VuY2VzQGxpc3RzLmRpZ2l1bS5jb20+IFttYWlsdG86YXN0ZXJpc2stdXNlcnMtYm91bmNl c0BsaXN0cy5kaWdpdW0uY29tPG1haWx0bzphc3Rlcmlzay11c2Vycy1ib3VuY2VzQGxpc3RzLmRp Z2l1bS5jb20+XSBPbiBCZWhhbGYgT2YgR2VvcmdlIEpvc2VwaA0KU2VudDogTW9uZGF5LCBEZWNl bWJlciAxNSwgMjAxNCAzOjQwIFBNDQpUbzogQXN0ZXJpc2sgVXNlcnMgTWFpbGluZyBMaXN0IC0g Tm9uLUNvbW1lcmNpYWwgRGlzY3Vzc2lvbg0KU3ViamVjdDogUmU6IFthc3Rlcmlzay11c2Vyc10g UEpTSVAgY29uZmlndXJhdGlvbiBxdWVzdGlvbg0KDQpPbiBNb24sIERlYyAxNSwgMjAxNCBhdCAy OjA4IFBNLCBEYW4gQ3JvcHAgPGRhbkBhbXRlbGNvLmNvbTxtYWlsdG86ZGFuQGFtdGVsY28uY29t Pj4gd3JvdGU6DQpUb2RheSwgSSB0cmllZCB0aGUgc2FtZSBiZWhhdmlvciBvbiBBc3RlcmlzayAx My4xLjAgYW5kIEFzdGVyaXNrIDEyLjIuMC4NCg0KU2FtZSBwcm9ibGVtIGlzIGhhcHBlbmluZyB3
aXRoIGJvdGggb2YgdGhlbS4NCg0KQ291bGQgdGhpcyBiZSBjYXVzZWQgYnkgUEpQUk9KRUNUIDIu Mz8NCg0KQW55b25lIGhhdmUgYW55IHN1Z2dlc3Rpb25zIGZvciB3aGF0IEkgY2FuIHRyeT8NCg0K
TXkgYm9zcyBpcyBnaXZpbmcgbWUgdW50aWwgdG9tb3Jyb3cgdG8gZ2V0IHRoZSBQSlNJUCBzdXBw b3J0IHdvcmtpbmcgd2l0aCBWaXRlbGl0eS4gIE90aGVyd2lzZSwgaGXigJlzIHRvbGQgbWUgdG8g Z28gYmFjayB0byB1c2luZyBjaGFuX3NpcCBhbmQgd2FpdCBhIHllYXIgb3IgdHdvIGZvciBQSlNJ
UCB0byBiZSBpbiB0aGUgZmllbGQgbW9yZS4NCg0KSSBoYXZlIGEgVml0ZWxpdHkgYWNjb3VudCBJ
IGNhbiB0cnkuICBSZS1wb3N0IHlvdXIgcGpzaXAgY29uZmlnIGFuZCBJJ2xsIHRyeSBpdCBub3cu DQoNCg0KDQpIYXZlIGEgZ3JlYXQgZGF5IQ0KDQpEYW4NCg0KLS0NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KLS0g QmFuZHdpZHRoIGFuZCBDb2xvY2F0aW9uIFByb3ZpZGVkIGJ5IGh0dHA6Ly93d3cuYXBpLWRpZ2l0
YWwuY29tIC0tDQpOZXcgdG8gQXN0ZXJpc2s/IEpvaW4gdXMgZm9yIGEgbGl2ZSBpbnRyb2R1Y3Rv cnkgd2ViaW5hciBldmVyeSBUaHVyczoNCiAgICAgICAgICAgICAgIGh0dHA6Ly93d3cuYXN0ZXJp c2sub3JnL2hlbGxvDQoNCmFzdGVyaXNrLXVzZXJzIG1haWxpbmcgbGlzdA0KVG8gVU5TVUJTQ1JJ
QkUgb3IgdXBkYXRlIG9wdGlvbnMgdmlzaXQ6DQogICBodHRwOi8vbGlzdHMuZGlnaXVtLmNvbS9t YWlsbWFuL2xpc3RpbmZvL2FzdGVyaXNrLXVzZXJzDQoNCi0tDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCi0tIEJh bmR3aWR0aCBhbmQgQ29sb2NhdGlvbiBQcm92aWRlZCBieSBodHRwOi8vd3d3LmFwaS1kaWdpdGFs LmNvbSAtLQ0KTmV3IHRvIEFzdGVyaXNrPyBKb2luIHVzIGZvciBhIGxpdmUgaW50cm9kdWN0b3J5
IHdlYmluYXIgZXZlcnkgVGh1cnM6DQogICAgICAgICAgICAgICBodHRwOi8vd3d3LmFzdGVyaXNr Lm9yZy9oZWxsbw0KDQphc3Rlcmlzay11c2VycyBtYWlsaW5nIGxpc3QNClRvIFVOU1VCU0NSSUJF
IG9yIHVwZGF0ZSBvcHRpb25zIHZpc2l0Og0KICAgaHR0cDovL2xpc3RzLmRpZ2l1bS5jb20vbWFp bG1hbi9saXN0aW5mby9hc3Rlcmlzay11c2Vycw0KDQotLQ0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQotLSBCYW5k d2lkdGggYW5kIENvbG9jYXRpb24gUHJvdmlkZWQgYnkgaHR0cDovL3d3dy5hcGktZGlnaXRhbC5j b20gLS0NCk5ldyB0byBBc3Rlcmlzaz8gSm9pbiB1cyBmb3IgYSBsaXZlIGludHJvZHVjdG9yeSB3
ZWJpbmFyIGV2ZXJ5IFRodXJzOg0KICAgICAgICAgICAgICAgaHR0cDovL3d3dy5hc3Rlcmlzay5v cmcvaGVsbG8NCg0KYXN0ZXJpc2stdXNlcnMgbWFpbGluZyBsaXN0DQpUbyBVTlNVQlNDUklCRSBv ciB1cGRhdGUgb3B0aW9ucyB2aXNpdDoNCiAgIGh0dHA6Ly9saXN0cy5kaWdpdW0uY29tL21haWxt YW4vbGlzdGluZm8vYXN0ZXJpc2stdXNlcnMNCg=
Ok Dan, try this… I was able to get this to work behind a NAT and with ip address authentication.
[global]
type = global debug = yes
[transport1]
type = transport bind = 0.0.0.0
protocol = udp
*local_net=http://10.10.10.10/24>>external_media_address=external_signaling_address= *
[outbound.vitelity.net]
type = aor remove_existing = yes qualify_frequency = 60
contact = sip:64.2.142.93
[outbound.vitelity.net]
type = endpoint context = TestApp transport = transport1
aors = outbound.vitelity.net dtmf_mode = rfc4733
force_rport = yes rtp_symmetric = yes rewrite_contact = yes send_rpid = yes trust_id_inbound = yes disallow = all allow = ulaw direct_media = no
*from_user= ; Not subaccount*
[outbound.vitelity.net]
type = identify endpoint = outbound.vitelity.net match = 64.2.142.93
Thanks George.
I will remote into and give this a try.
Have a great evening!
Dan
Ok Dan, try this… I was able to get this to work behind a NAT and with ip address authentication.
[global]
type = global debug = yes
[transport1]http://10.10.10.10/24>>
type = transport bind = 0.0.0.0
protocol = udp local_net=
external_media_address=
external_signaling_address=
[outbound.vitelity.net<http://outbound.vitelity.net>]
type = aor remove_existing = yes qualify_frequency = 60
contact = sip:64.2.142.93
[outbound.vitelity.net<http://outbound.vitelity.net>] ; Not subaccount
type = endpoint context = TestApp transport = transport1
aors = outbound.vitelity.net<http://outbound.vitelity.net>
dtmf_mode = rfc4733
force_rport = yes rtp_symmetric = yes rewrite_contact = yes send_rpid = yes trust_id_inbound = yes disallow = all allow = ulaw direct_media = no from_user=
[outbound.vitelity.net<http://outbound.vitelity.net>]
type = identify endpoint = outbound.vitelity.net<http://outbound.vitelity.net>
match = 64.2.142.93
SSBhbSBub3Qgc3VyZSBpZiBJIGVudGVyZWQgdGhlIGNvcnJlY3Qgc2V0dGluZ3MgZm9yIHRoZSB0
cmFuc3BvcnQgaW5mb3JtYXRpb24uDQpGb3IgdGhlIGxvY2FsX25ldCwgSSBlbnRlcmVkIG15IGxv Y2FsIGlwIGFkZHJlc3MsIGJ1dCBubyBtYXNrLiAgSSB3aWxsIGNoZWNrIHdpdGggdGhlIG5ldHdv cmsgYWRtaW4gc28gaGUgY2FuIHZlcmlmeSB0aGUgc2V0dGluZ3MgSSBlbnRlcmVkLg0KDQpPbmUg bWlub3IgZGV0YWlsLCB3ZSBhcmUgdXNpbmcgaXAgYXV0aGVudGljYXRpb24uICBXaGVuIFZpdGVs aXR5IGNoYW5nZWQgbXkgYWNjb3VudCBmcm9tIHVzZXIgYmFzZWQgYXV0aGVudGljYXRpb24gdG8g SVAgYmFzZWQgYXV0aGVudGljYXRpb24sIHRoZXkgc3RvcHBlZCBpbmNsdWRpbmcgYSB1c2VyIGZv ciB0aGUgYWNjb3VudC4NCg0KU2hvdWxkIHRoZXNlIHNldHRpbmdzIHdvcmsgd2l0aG91dCB0aGUg ZnJvbV91c2VyIChJUCBiYXNlZCBhdXRoZW50aWNhdGlvbikgb3IgZG8gSSBuZWVkIHRvIGdldCB0
aGUgYWNjb3VudCBuYW1lIGZyb20gVml0ZWxpdHk/DQoNCkhhdmUgYSBncmVhdCBkYXkhDQoNCkRh DQoNCkZyb206IGFzdGVyaXNrLXVzZXJzLWJvdW5jZXNAbGlzdHMuZGlnaXVtLmNvbSBbbWFpbHRv OmFzdGVyaXNrLXVzZXJzLWJvdW5jZXNAbGlzdHMuZGlnaXVtLmNvbV0gT24gQmVoYWxmIE9mIEdl b3JnZSBKb3NlcGgNClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMTUsIDIwMTQgNzoyNyBQTQ0KVG86
IEFzdGVyaXNrIFVzZXJzIE1haWxpbmcgTGlzdCAtIE5vbi1Db21tZXJjaWFsIERpc2N1c3Npb24N
ClN1YmplY3Q6IFJlOiBbYXN0ZXJpc2stdXNlcnNdIFBKU0lQIGNvbmZpZ3VyYXRpb24gcXVlc3Rp b24NCg0KT2sgRGFuLCB0cnkgdGhpcy4uLiAgSSB3YXMgYWJsZSB0byBnZXQgdGhpcyB0byB3b3Jr IGJlaGluZCBhIE5BVCBhbmQgd2l0aCBpcCBhZGRyZXNzIGF1dGhlbnRpY2F0aW9uLg0KDQpbZ2xv YmFsXQ0KdHlwZSA9IGdsb2JhbA0KZGVidWcgPSB5ZXMNClt0cmFuc3BvcnQxXQ0KdHlwZSA9IHRy YW5zcG9ydA0KYmluZCA9IDAuMC4wLjANCnByb3RvY29sID0gdWRwDQpsb2NhbF9uZXQ9PHlvdXJs b2NhbG5ldCBJLkUuIDEwLjEwLjEwLjEwLzI0PGh0dHA6Ly8xMC4xMC4xMC4xMC8yND4+DQpleHRl cm5hbF9tZWRpYV9hZGRyZXNzPTx5b3VyIHB1YmxpYyBpcCBhZGRyZXNzPg0KZXh0ZXJuYWxfc2ln bmFsaW5nX2FkZHJlc3M9PHlvdXIgcHVibGljIGFkZHJlc3M+DQoNCltvdXRib3VuZC52aXRlbGl0
eS5uZXQ8aHR0cDovL291dGJvdW5kLnZpdGVsaXR5Lm5ldD5dDQp0eXBlID0gYW9yDQpyZW1vdmVf ZXhpc3RpbmcgPSB5ZXMNCnF1YWxpZnlfZnJlcXVlbmN5ID0gNjANCmNvbnRhY3QgPSBzaXA6NjQu Mi4xNDIuOTMNCltvdXRib3VuZC52aXRlbGl0eS5uZXQ8aHR0cDovL291dGJvdW5kLnZpdGVsaXR5
Lm5ldD5dDQp0eXBlID0gZW5kcG9pbnQNCmNvbnRleHQgPSBUZXN0QXBwDQp0cmFuc3BvcnQgPSB0
cmFuc3BvcnQxDQphb3JzID0gb3V0Ym91bmQudml0ZWxpdHkubmV0PGh0dHA6Ly9vdXRib3VuZC52
aXRlbGl0eS5uZXQ+DQpkdG1mX21vZGUgPSByZmM0NzMzDQpmb3JjZV9ycG9ydCA9IHllcw0KcnRw X3N5bW1ldHJpYyA9IHllcw0KcmV3cml0ZV9jb250YWN0ID0geWVzDQpzZW5kX3JwaWQgPSB5ZXMN
CnRydXN0X2lkX2luYm91bmQgPSB5ZXMNCmRpc2FsbG93ID0gYWxsDQphbGxvdyA9IHVsYXcNCmRp cmVjdF9tZWRpYSA9IG5vDQpmcm9tX3VzZXI9PHlvdXIgbWFpbiB2aXRlbGl0eSBhY2NvdW50IG5h bWU+ICA7IE5vdCBzdWJhY2NvdW50DQpbb3V0Ym91bmQudml0ZWxpdHkubmV0PGh0dHA6Ly9vdXRi b3VuZC52aXRlbGl0eS5uZXQ+XQ0KdHlwZSA9IGlkZW50aWZ5DQplbmRwb2ludCA9IG91dGJvdW5k LnZpdGVsaXR5Lm5ldDxodHRwOi8vb3V0Ym91bmQudml0ZWxpdHkubmV0Pg0KbWF0Y2ggPSA2NC4y LjE0Mi45Mw0K
You need the network and mask. For example if the ip address and mask of the test machine is 192.168.0.1/255.255.255.0 then the correct entry would be 192.168.0.0/24.
You definitely need the master account login username. If you has this working with chan_sip, then try the ‘fromuser’ from sip.conf and user is from_user.
Thanks George.
I will correct my local_net in the morning.
Vitelity chan_sip settings I have working, do not have a fromuser. sip.conf settings…
[HVout]
type=friend dtmfmode=auto host=64.2.142.93
disallow=all allow=ulaw canreinvite=no trustrpid=yes sendrpid=yes nat=yes context=TestApp
I am not sure if I entered the correct settings for the transport information. For the local_net, I entered my local ip address, but no mask. I will check with the network admin so he can verify the settings I entered.
You need the network and mask. For example if the ip address and mask of the test machine is 192.168.0.1/255.255.255.0<http://192.168.0.1/255.255.255.0> then the correct entry would be 192.168.0.0/24<http://192.168.0.0/24>.
One minor detail, we are using ip authentication. When Vitelity changed my account from user based authentication to IP based authentication, they stopped including a user for the account.
Should these settings work without the from_user (IP based authentication) or do I need to get the account name from Vitelity?
You definitely need the master account login username. If you has this working with chan_sip, then try the ‘fromuser’ from sip.conf and user is from_user.
Have a great day!
Da
From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of George Joseph Sent: Monday, December 15, 2014 7:27 PM
To: Asterisk Users Mailing List – Non-Commercial Discussion Subject: Re: [asterisk-users] PJSIP configuration question
Ok Dan, try this… I was able to get this to work behind a NAT and with ip address authentication.
[global]http://10.10.10.10/24>>
type = global debug = yes
[transport1]
type = transport bind = 0.0.0.0
protocol = udp local_net=
external_media_address=
external_signaling_address=
[outbound.vitelity.net<http://outbound.vitelity.net>] ; Not subaccount
type = aor remove_existing = yes qualify_frequency = 60
contact = sip:64.2.142.93
[outbound.vitelity.net<http://outbound.vitelity.net>]
type = endpoint context = TestApp transport = transport1
aors = outbound.vitelity.net<http://outbound.vitelity.net>
dtmf_mode = rfc4733
force_rport = yes rtp_symmetric = yes rewrite_contact = yes send_rpid = yes trust_id_inbound = yes disallow = all allow = ulaw direct_media = no from_user=
[outbound.vitelity.net<http://outbound.vitelity.net>]
type = identify endpoint = outbound.vitelity.net<http://outbound.vitelity.net>
match = 64.2.142.93
with something other than a sub-account username.
VGhhbmtzIEdlb3JnZS4NCkkgd2lsbCBnaXZlIGl0IGEgdHJ5Lg0KDQpIYXZlIGEgZ3JlYXQgZGF5
IQ0KRGFuDQoNCg0KRnJvbTogYXN0ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5kaWdpdW0uY29t IFttYWlsdG86YXN0ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5kaWdpdW0uY29tXSBPbiBCZWhh bGYgT2YgR2VvcmdlIEpvc2VwaA0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAxNSwgMjAxNCAxMTox NCBQTQ0KVG86IEFzdGVyaXNrIFVzZXJzIE1haWxpbmcgTGlzdCAtIE5vbi1Db21tZXJjaWFsIERp c2N1c3Npb24NClN1YmplY3Q6IFJlOiBbYXN0ZXJpc2stdXNlcnNdIFBKU0lQIGNvbmZpZ3VyYXRp b24gcXVlc3Rpb24NCg0KSSB0aGluayB5b3UgY2FuIGFjdHVhbGx5IHNwZWNpZnkgYW55dGhpbmcs IGl0IGp1c3QgaGFzIHRvIGJlIHBvcHVsYXRlZCB3aXRoIHNvbWV0aGluZyBvdGhlciB0aGFuIGEg c3ViLWFjY291bnQgdXNlcm5hbWUuDQo
SSBjb3JyZWN0ZWQgbXkgbG9jYWxfbmV0IHNldHRpbmcgKGJhc2VkIG9uIGFkdmljZSBmcm9tIG5l dHdvcmsgYWRtaW4pLg0KDQpJIGhhdmUgdHJpZWQgc2V2ZXJhbCBkaWZmZXJlbnQgdmFsdWVzIGZv ciB0aGUgZnJvbV91c2VyIGFuZCBzdGlsbCBoYXZlIHRoZSBzYW1lIHByb2JsZW0uDQoNCkFzdGVy aXNrIHJlY2VpdmVzIHRoZSBPSyBmcm9tIFZpdGVsaXR5Lg0KQXN0ZXJpc2sgc2VuZHMgdGhlIEFD
SyAod2l0aG91dCBhIENvbnRhY3QgaGVhZGVyKS4NClZpdGVsaXR5IGRvZXNu4oCZdCBzZWVtIHRv IHByb2Nlc3MgaXQsIHNvIHRoZXkgc2VuZCBhbiBPSyBhZ2Fpbi4NCg0KVGhlIE9LIHJlY2VpdmUs IFRyYW5zbWl0IEFDSyBvY2N1cnMgNCB0aW1lcy4NCkEgc2hvcnQgd2hpbGUgbGF0ZXIsIFZpdGVs aXR5IGhhbmdzIHVwIG9uIG15IGNlbGwgcGhvbmUuDQoNCkFzdGVyaXNrIGlzIG5ldmVyIHRvbGQg dGhlIGNhbGwgIGlzIGdvbmUuDQoNCklmIEkgaGFuZ3VwIHRoZSBjYWxsIGZyb20gQXN0ZXJpc2sg c2lkZSwNCkFzdGVyaXNrIHNlbmRzIHRoZSBCWUUgbWVzc2FnZS4NClZpdGVsaXR5IHJlc3BvbmRz IHdpdGggYSDigJxTSVAvMi4wIDQ4MSBDYWxsIGxlZy90cmFuc2FjdGlvbiBkb2VzIG5vdCBleGlz dOKAnQ0KDQpBZ2FpbiwgdGhlIHRyYWNlIGluZGljYXRlcyB0aGUgQUNLIG1lc3NhZ2UgaXMgbWlz c2luZyB0aGUgQ29udGFjdCBoZWFkZXIuDQoNCkFkZGl0aW9uYWwgbm90ZTogdGhlIG5ldHdvcmsg YWRtaW4gaXMgYXNraW5nIHdoeSB0aGUgbG9jYWxfbmV0LCBleHRlcm5hbF9tZWRpYV9hZGRyZXNz LCBhbmQgZXh0ZXJuYWxfc2lnbmFsbGluZ19hZGRyZXNzIGFyZSBuZWVkZWQuICBIZSB3cm90ZSBt ZeKApuKAnFlvdSBzaG91bGQgTk9UIGhhdmUgdG8ga25vdyB5b3VyIHB1YmxpYyBJUC4gIFRoZSBm aXJld2FsbCBzaG91bGQgYmUgZG9pbmcgZml4dXAgY29tbWFuZHMgdG8gY2hhbmdlIHRoZSB2YWx1
ZXMgaW4gdGhlIHBhY2tldOKAnQ0KDQoNCkZyb206IGFzdGVyaXNrLXVzZXJzLWJvdW5jZXNAbGlz dHMuZGlnaXVtLmNvbSBbbWFpbHRvOmFzdGVyaXNrLXVzZXJzLWJvdW5jZXNAbGlzdHMuZGlnaXVt LmNvbV0gT24gQmVoYWxmIE9mIEdlb3JnZSBKb3NlcGgNClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIg MTUsIDIwMTQgMTE6MTQgUE0NClRvOiBBc3RlcmlzayBVc2VycyBNYWlsaW5nIExpc3QgLSBOb24t Q29tbWVyY2lhbCBEaXNjdXNzaW9uDQpTdWJqZWN0OiBSZTogW2FzdGVyaXNrLXVzZXJzXSBQSlNJ
UCBjb25maWd1cmF0aW9uIHF1ZXN0aW9uDQoNCk9uIE1vbiwgRGVjIDE1LCAyMDE0IGF0IDk6NDgg UE0sIERhbiBDcm9wcCA8ZGFuQGFtdGVsY28uY29tPG1haWx0bzpkYW5AYW10ZWxjby5jb20+PiB3
cm90ZToNClRoYW5rcyBHZW9yZ2UuDQoNCkkgd2lsbCBjb3JyZWN0IG15IGxvY2FsX25ldCBpbiB0
aGUgbW9ybmluZy4NCg0KVml0ZWxpdHkgY2hhbl9zaXAgc2V0dGluZ3MgSSBoYXZlIHdvcmtpbmcs IGRvIG5vdCBoYXZlIGEgZnJvbXVzZXIuDQpzaXAuY29uZiBzZXR0aW5ncy4uLg0KDQpJIHRoaW5r IHlvdSBjYW4gYWN0dWFsbHkgc3BlY2lmeSBhbnl0aGluZywgaXQganVzdCBoYXMgdG8gYmUgcG9w dWxhdGVkIHdpdGggc29tZXRoaW5nIG90aGVyIHRoYW4gYSBzdWItYWNjb3VudCB1c2VybmFtZS4N
Cg0KDQpbSFZvdXRdDQp0eXBlPWZyaWVuZA0KZHRtZm1vZGU9YXV0bw0KaG9zdD02NC4yLjE0Mi45
Mw0KZGlzYWxsb3c9YWxsDQphbGxvdz11bGF3DQpjYW5yZWludml0ZT1ubw0KdHJ1c3RycGlkPXll cw0Kc2VuZHJwaWQ9eWVzDQpuYXQ9eWVzDQpjb250ZXh0PVRlc3RBcHANCg0KDQpPbiBEZWMgMTUs IDIwMTQsIGF0IDk6MzIgUE0sIEdlb3JnZSBKb3NlcGggPGdlb3JnZS5qb3NlcGhAZmFpcnZpZXc1
LmNvbTxtYWlsdG86Z2VvcmdlLmpvc2VwaEBmYWlydmlldzUuY29tPj4gd3JvdGU6DQoNCg0KT24g TW9uLCBEZWMgMTUsIDIwMTQgYXQgNzozNCBQTSwgRGFuIENyb3BwIDxkYW5AYW10ZWxjby5jb208
bWFpbHRvOmRhbkBhbXRlbGNvLmNvbT4+IHdyb3RlOg0KSSBhbSBub3Qgc3VyZSBpZiBJIGVudGVy ZWQgdGhlIGNvcnJlY3Qgc2V0dGluZ3MgZm9yIHRoZSB0cmFuc3BvcnQgaW5mb3JtYXRpb24uDQpG
b3IgdGhlIGxvY2FsX25ldCwgSSBlbnRlcmVkIG15IGxvY2FsIGlwIGFkZHJlc3MsIGJ1dCBubyBt YXNrLiAgSSB3aWxsIGNoZWNrIHdpdGggdGhlIG5ldHdvcmsgYWRtaW4gc28gaGUgY2FuIHZlcmlm eSB0aGUgc2V0dGluZ3MgSSBlbnRlcmVkLg0KDQpZb3UgbmVlZCB0aGUgbmV0d29yayBhbmQgbWFz ay4gIEZvciBleGFtcGxlIGlmIHRoZSBpcCBhZGRyZXNzIGFuZCBtYXNrIG9mIHRoZSB0ZXN0IG1h Y2hpbmUgaXMgMTkyLjE2OC4wLjEvMjU1LjI1NS4yNTUuMDxodHRwOi8vMTkyLjE2OC4wLjEvMjU1
LjI1NS4yNTUuMD4gdGhlbiB0aGUgY29ycmVjdCBlbnRyeSB3b3VsZCBiZSAxOTIuMTY4LjAuMC8y NDxodHRwOi8vMTkyLjE2OC4wLjAvMjQ+Lg0KDQpPbmUgbWlub3IgZGV0YWlsLCB3ZSBhcmUgdXNp bmcgaXAgYXV0aGVudGljYXRpb24uICBXaGVuIFZpdGVsaXR5IGNoYW5nZWQgbXkgYWNjb3VudCBm cm9tIHVzZXIgYmFzZWQgYXV0aGVudGljYXRpb24gdG8gSVAgYmFzZWQgYXV0aGVudGljYXRpb24s IHRoZXkgc3RvcHBlZCBpbmNsdWRpbmcgYSB1c2VyIGZvciB0aGUgYWNjb3VudC4NCg0KU2hvdWxk IHRoZXNlIHNldHRpbmdzIHdvcmsgd2l0aG91dCB0aGUgZnJvbV91c2VyIChJUCBiYXNlZCBhdXRo ZW50aWNhdGlvbikgb3IgZG8gSSBuZWVkIHRvIGdldCB0aGUgYWNjb3VudCBuYW1lIGZyb20gVml0
ZWxpdHk/DQoNCllvdSBkZWZpbml0ZWx5IG5lZWQgdGhlIG1hc3RlciBhY2NvdW50IGxvZ2luIHVz ZXJuYW1lLiAgSWYgeW91IGhhcyB0aGlzIHdvcmtpbmcgd2l0aCBjaGFuX3NpcCwgdGhlbiB0cnkg dGhlICdmcm9tdXNlcicgZnJvbSBzaXAuY29uZiBhbmQgdXNlciBpcyBmcm9tX3VzZXIuDQoNCg0K
DQoNCkhhdmUgYSBncmVhdCBkYXkhDQoNCkRhDQoNCkZyb206IGFzdGVyaXNrLXVzZXJzLWJvdW5j ZXNAbGlzdHMuZGlnaXVtLmNvbTxtYWlsdG86YXN0ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5k aWdpdW0uY29tPiBbbWFpbHRvOmFzdGVyaXNrLXVzZXJzLWJvdW5jZXNAbGlzdHMuZGlnaXVtLmNv bTxtYWlsdG86YXN0ZXJpc2stdXNlcnMtYm91bmNlc0BsaXN0cy5kaWdpdW0uY29tPl0gT24gQmVo YWxmIE9mIEdlb3JnZSBKb3NlcGgNClNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMTUsIDIwMTQgNzoy NyBQTQ0KVG86IEFzdGVyaXNrIFVzZXJzIE1haWxpbmcgTGlzdCAtIE5vbi1Db21tZXJjaWFsIERp c2N1c3Npb24NClN1YmplY3Q6IFJlOiBbYXN0ZXJpc2stdXNlcnNdIFBKU0lQIGNvbmZpZ3VyYXRp b24gcXVlc3Rpb24NCg0KT2sgRGFuLCB0cnkgdGhpcy4uLiAgSSB3YXMgYWJsZSB0byBnZXQgdGhp cyB0byB3b3JrIGJlaGluZCBhIE5BVCBhbmQgd2l0aCBpcCBhZGRyZXNzIGF1dGhlbnRpY2F0aW9u Lg0KDQpbZ2xvYmFsXQ0KdHlwZSA9IGdsb2JhbA0KZGVidWcgPSB5ZXMNClt0cmFuc3BvcnQxXQ0K
dHlwZSA9IHRyYW5zcG9ydA0KYmluZCA9IDAuMC4wLjANCnByb3RvY29sID0gdWRwDQpsb2NhbF9u ZXQ9PHlvdXJsb2NhbG5ldCBJLkUuIDEwLjEwLjEwLjEwLzI0PGh0dHA6Ly8xMC4xMC4xMC4xMC8y ND4+DQpleHRlcm5hbF9tZWRpYV9hZGRyZXNzPTx5b3VyIHB1YmxpYyBpcCBhZGRyZXNzPg0KZXh0
ZXJuYWxfc2lnbmFsaW5nX2FkZHJlc3M9PHlvdXIgcHVibGljIGFkZHJlc3M+DQoNCltvdXRib3Vu ZC52aXRlbGl0eS5uZXQ8aHR0cDovL291dGJvdW5kLnZpdGVsaXR5Lm5ldD5dDQp0eXBlID0gYW9y DQpyZW1vdmVfZXhpc3RpbmcgPSB5ZXMNCnF1YWxpZnlfZnJlcXVlbmN5ID0gNjANCmNvbnRhY3Qg PSBzaXA6NjQuMi4xNDIuOTMNCltvdXRib3VuZC52aXRlbGl0eS5uZXQ8aHR0cDovL291dGJvdW5k LnZpdGVsaXR5Lm5ldD5dDQp0eXBlID0gZW5kcG9pbnQNCmNvbnRleHQgPSBUZXN0QXBwDQp0cmFu c3BvcnQgPSB0cmFuc3BvcnQxDQphb3JzID0gb3V0Ym91bmQudml0ZWxpdHkubmV0PGh0dHA6Ly9v dXRib3VuZC52aXRlbGl0eS5uZXQ+DQpkdG1mX21vZGUgPSByZmM0NzMzDQpmb3JjZV9ycG9ydCA9
IHllcw0KcnRwX3N5bW1ldHJpYyA9IHllcw0KcmV3cml0ZV9jb250YWN0ID0geWVzDQpzZW5kX3Jw aWQgPSB5ZXMNCnRydXN0X2lkX2luYm91bmQgPSB5ZXMNCmRpc2FsbG93ID0gYWxsDQphbGxvdyA9
IHVsYXcNCmRpcmVjdF9tZWRpYSA9IG5vDQpmcm9tX3VzZXI9PHlvdXIgbWFpbiB2aXRlbGl0eSBh Y2NvdW50IG5hbWU+ICA7IE5vdCBzdWJhY2NvdW50DQpbb3V0Ym91bmQudml0ZWxpdHkubmV0PGh0
dHA6Ly9vdXRib3VuZC52aXRlbGl0eS5uZXQ+XQ0KdHlwZSA9IGlkZW50aWZ5DQplbmRwb2ludCA9
IG91dGJvdW5kLnZpdGVsaXR5Lm5ldDxodHRwOi8vb3V0Ym91bmQudml0ZWxpdHkubmV0Pg0KbWF0
Y2ggPSA2NC4yLjE0Mi45Mw0KDQotLQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQotLSBCYW5kd2lkdGggYW5kIENv bG9jYXRpb24gUHJvdmlkZWQgYnkgaHR0cDovL3d3dy5hcGktZGlnaXRhbC5jb20gLS0NCk5ldyB0
byBBc3Rlcmlzaz8gSm9pbiB1cyBmb3IgYSBsaXZlIGludHJvZHVjdG9yeSB3ZWJpbmFyIGV2ZXJ5
IFRodXJzOg0KICAgICAgICAgICAgICAgaHR0cDovL3d3dy5hc3Rlcmlzay5vcmcvaGVsbG8NCg0K
YXN0ZXJpc2stdXNlcnMgbWFpbGluZyBsaXN0DQpUbyBVTlNVQlNDUklCRSBvciB1cGRhdGUgb3B0
aW9ucyB2aXNpdDoNCiAgIGh0dHA6Ly9saXN0cy5kaWdpdW0uY29tL21haWxtYW4vbGlzdGluZm8v YXN0ZXJpc2stdXNlcnMNCi0tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCi0tIEJhbmR3aWR0aCBhbmQgQ29sb2Nh dGlvbiBQcm92aWRlZCBieSBodHRwOi8vd3d3LmFwaS1kaWdpdGFsLmNvbSAtLQ0KTmV3IHRvIEFz dGVyaXNrPyBKb2luIHVzIGZvciBhIGxpdmUgaW50cm9kdWN0b3J5IHdlYmluYXIgZXZlcnkgVGh1
cnM6DQogICAgICAgICAgICAgIGh0dHA6Ly93d3cuYXN0ZXJpc2sub3JnL2hlbGxvDQoNCmFzdGVy aXNrLXVzZXJzIG1haWxpbmcgbGlzdA0KVG8gVU5TVUJTQ1JJQkUgb3IgdXBkYXRlIG9wdGlvbnMg dmlzaXQ6DQogIGh0dHA6Ly9saXN0cy5kaWdpdW0uY29tL21haWxtYW4vbGlzdGluZm8vYXN0ZXJp c2stdXNlcnMNCg0KLS0NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KLS0gQmFuZHdpZHRoIGFuZCBDb2xvY2F0aW9u IFByb3ZpZGVkIGJ5IGh0dHA6Ly93d3cuYXBpLWRpZ2l0YWwuY29tIC0tDQpOZXcgdG8gQXN0ZXJp c2s/IEpvaW4gdXMgZm9yIGEgbGl2ZSBpbnRyb2R1Y3Rvcnkgd2ViaW5hciBldmVyeSBUaHVyczoN
CiAgICAgICAgICAgICAgIGh0dHA6Ly93d3cuYXN0ZXJpc2sub3JnL2hlbGxvDQoNCmFzdGVyaXNr LXVzZXJzIG1haWxpbmcgbGlzdA0KVG8gVU5TVUJTQ1JJQkUgb3IgdXBkYXRlIG9wdGlvbnMgdmlz aXQ6DQogICBodHRwOi8vbGlzdHMuZGlnaXVtLmNvbS9tYWlsbWFuL2xpc3RpbmZvL2FzdGVyaXNr LXVzZXJzDQo
First…
“The firewall should be doing fixup commands to change the values in the packet”
*The firewall should NOT be changing values in the packet. If it is, all bets are off.*
Second.
Can you try making a call from a phone instead of from an AMI originate?
Dan Cropp wrote:
A Contact header is not required to be in the ACK.
I’d try to isolate this further as there’s two possible things:
1. The ACK never got to them
2. They didn’t process it
This can cause major problems. I’ve rarely (if ever) come across an ALG
(that’s what that is) that didn’t break something.
Cheers,
—
Joshua Colp Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW – Huntsville, AL 35806 – US
Check us out at: http://www.digium.com & http://www.asterisk.org
—
Thank you George and Joshua.
“This can cause major problems. I’ve rarely (if ever) come across an ALG (that’s what that is) that didn’t break something.”
I am contacting the network admin and seeing if he can modify the firewall.
I’m a lifelong programmer. Code and programming, I understand. When it comes to the network, I’m clueless.
Here’s an update…
My network admin would not turn off the ALG because it would cause several other problems to other phone systems we have.
He looked at the sip trace. What he found is the PJSIP trace showed a different IP address than the older chan_sip so he had me change the aor contact to outbound.vitelity.net
At this point, it seems to be working (and this is going through a Cisco ALG).
I will run more tests, but here is the pjsip.conf I have.
[global]
type = global debug = yes
[transport1]
type = transport bind = 0.0.0.0
protocol = udp
[outbound.vitelity.net]
type = aor remove_existing = yes qualify_frequency = 60
contact = sip:outbound.vitelity.net
[outbound.vitelity.net]
type = endpoint context = TestApp transport = transport1
aors = outbound.vitelity.net dtmf_mode = rfc4733
force_rport = yes rtp_symmetric = yes rewrite_contact = yes send_rpid = yes trust_id_inbound = yes disallow = all allow = ulaw direct_media = no
[outbound.vitelity.net]
type = identify endpoint = outbound.vitelity.net match = 64.2.142.93
Have a great day!
Dan
Glad you got it working!
I am trying to configure a connection to BluIP. I am able to make incoming calls work. However outgoing calls are not working.
For the Outbound Registration, I noticed the contact field is always the internal IP address of my pc instead of mycompany dot com
I can Originate (using AMI) to my Vitelity trunk (IP based authentication). However, when I Originate to my BluIP, it is being rejected.
When I compare this with another system that does the same behavior, the one difference I notice is that the other system does not pass the internal ip address for the From domain portion. Instead, it is passing companyname.com.
For the outbound Registration, I noticed the REGISTER Contact field is always my internal ip address. I programmed the contact for the registration portion of pjsip.conf to attempt to force the companyname instead of the internal ip address. However, this didn’t change the REGISTER packet. Is there a different setting that I need to enter to force the REGISTER to use my companyname dot com instead of the ip address?
contact = sip:didassignedbybluip at companyname.com
The REGISTER succeeds (which explains internal calls working). However, they are always using my internal ip address.
BluIP;tag=4fda8a53-8831-45bd-9b29-15eb276ceafb
Xmt
INVITE sip:18005551212 @bluipaddress SIP/2.0
Via: SIP/2.0/UDP myinternalipaddress:5060;rport;branch=z9hG4bKPj32298b5f-ed09-4de4-9649-da4c4b78fafb
From: “Name”
To:
Contact:
Call-ID: ebc6049a-d700-43a4-b230-b06cd6289eea
CSeq: 12733 INVITE
…
Rcv;tag=4fda8a53-8831-45bd-9b29-15eb276ceafb
SIP/2.0 100 Trying
Via: SIP/2.0/UDP myinternalipaddress:5060;received=myinternalipaddress;branch=z9hG4bKPj32298b5f-ed09-4de4-9649-da4c4b78fafb;rport=5060
From: “Name”
To:
Call-ID: ebc6049a-d700-43a4-b230-b06cd6289eea
CSeq: 12733 INVITE
….
Rcv;tag=4fda8a53-8831-45bd-9b29-15eb276ceafb;tag=1389319045-1450195105789
SIP/2.0 604 Does not exist anywhere
Via: SIP/2.0/UDP myinternalipaddress:5060;received=myinternalipaddress;branch=z9hG4bKPj32298b5f-ed09-4de4-9649-da4c4b78fafb;rport=5060
From: “Name”
To:
Call-ID: ebc6049a-d700-43a4-b230-b06cd6289eea
CSeq: 12733 INVITE
Content-Length: 0
Any suggestions of what I am doing wrong?
Have a great day!
Dan
Dan Cropp wrote:
This is fine. The Contact tells the server where to send incoming INVITEs in the case of a REGISTER. If it wasn’t your address then the server wouldn’t really know where to send incoming calls. If you need it to be a public IP address then NAT settings can be set on the transport.
The domain in the From header can be set using from_domain on the endpoint.
It would also be useful to provide the configuration, minus passwords, and an example of a working SIP INVITE from another machine…
Thank you Joshua.
I tried setting the from_domain for the endpoint, but it still sends the internal ip address for the INVITE’s From field
[acl1]
type = acl deny = 0.0.0.0/0.0.0.0
permit = variousaddress permit = bluipaddress
[transport1]
type = transport bind = 0.0.0.0
protocol = udp
[BLUIPIN]
type = aor remove_existing = yes contact = sip:bluipaddress
[auth7]
type = auth username = didassignedbybluip password = password
[didassignedbybluip]
type = endpoint context = TestApp transport = transport1
outbound_auth = auth7
aors = BLUIPIN
accountcode = 16
dtmf_mode = rfc4733
device_state_busy_at = 2
force_rport = no rtp_symmetric = no rewrite_contact = no identify_by = username outbound_proxy = chi-sbc3-iad.bluip.com trust_id_outbound = yes from_domain = amtelco.com disallow = all allow = ulaw
[identify72]
type = identify endpoint = didassignedbybluip match = bluipaddress
[registration2]
type = registration transport = transport1
client_uri = sip:didassignedbybluip at companyname dot com server_uri = sip:chi-sbc3-iad.bluip.com contact_user = sip:didassignedbybluip at companyname dot com outbound_auth = auth7
Here is a trace of another system where it works.
IINVITE sip:callphonenumber@bluipaddress:5060 SIP/2.0;tag=JEDtnWPm Contact:
Via: SIP/2.0/UDP ipaddress:5060;branch=z9hG4bKQFD28QYY8412c000
To:
From:
Alert-Info: Classic-1
Call-ID: kD5sJntD5-0001-@ipaddress CSeq: 1808 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY
100 Trying Via: SIP/2.0/UDP ipaddress:5060;branch=z9hG4bKQFD28QYY8412c000;tag=JEDtnWPm Call-ID: kD5sJntD5-0001-@ ipaddress CSeq: 1808 INVITE
To:
From:
401 Unauthorized Via: SIP/2.0/UDP ipaddress:5060;branch=z9hG4bKQFD28QYY8412c000;tag64309609-1450128136967 ;tag=JEDtnWPm Call-ID: kD5sJntD5-0001-@ ipaddress CSeq: 1808 INVITE
To:
From:
WWW-Authenticate: DIGEST qop=”auth”,nonce=”BroadWorksXii6gunlzTrqhij5BW”,realm=”BroadWorks”,algorithm=MD5
Content-Length: 0
ACK sip:callphonenumber@bluipaddress:5060 SIP/2.0;tag64309609-1450128136967;tag=JEDtnWPm Max-Forwards: 70
Via: SIP/2.0/UDP ipaddress:5060;branch=z9hG4bKQFD28QYY8412c000
To:
From:
Call-ID: kD5sJntD5-0001-@ ipaddress CSeq: 1808 ACK
INVITE sip:callphonenumber@bluipaddress:5060 SIP/2.0;tag=pcjBsnMZ
Via: SIP/2.0/UDP ipaddress:5060;branch=z9hG4bKYcoOR2md84130000
To:
From:
Contact:
Alert-Info: Classic-1
Call-ID: kD5sJntD5-0001-@ ipaddress CSeq: 1809 INVITE
Authorization: Digest username=” didassignedbybluip “,realm=”BroadWorks”,nonce=”BroadWorksXii6gunlzTrqhij5BW”,uri=”sip:callphonenumber@bluipaddress:5060″,response=”6d3f8dea20a6173a9cbde2ce912696b7″,algorithm=MD5
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,REFER,NOTIFY
Supported: replaces Content-Type: application/sdp Content-Length: 335
100 Trying Via: SIP/2.0/UDP ipaddress:5060;branch=z9hG4bKYcoOR2md84130000;tag=pcjBsnMZ
To:
From:
Call-ID: kD5sJntD5-0001-@ipaddress CSeq: 1809 INVITE
180 Ringing Via: SIP/2.0/UDP ipaddress:5060;branch=z9hG4bKYcoOR2md84130000;tag
To:
Dan Cropp wrote:
Try setting this to: outbound_proxy = chi-sbc3-iad.bluip.com\;lr
Thanks Joshua.
Commenting out the outbound_proxy line did fixed my problem. Both inbound and outbound calls are now working.
Have a great day!
Dan
—–Original Message—