Hi
I have this endpoint
[mycity]
type=endpoint
contact_user=717177171
context=myproviderTrunk
disallow=all
allow=ulaw
outbound_auth=mycity
aors=mycity
However in the ring 180 my contact is
Contact: sip:192.168.2.52:5060
and also in the OK, therefore, the servertrunk is not recognized and never answer with an ACK
Why I am not able to insert contact_user? it is for an incoming call
Sorry for the trivial question
Asterisk 20.4.0
This is the SIP communication
INVITE sip:MYUSERID@TRUNKIP:5060 SIP/2.0.
Record-Route: <sip:MYUSERID@TRUNKIP;lr=on>.
Via: SIP/2.0/UDP TRUNKIP;branch=z9hG4bK2d13.723ffdc7.0.
Via: SIP/2.0/UDP PROXYIPs:5060;branch=z9hG4bK-524287-1---a8e35cf2080e17e254ab1881926352dc;rport=5060.
Via: SIP/2.0/UDP PROXYIPs:5060;branch=z9hG4bK-524287-1---d8dcd1bf84efdbc47065c5ab19b242cd;rport=5060.
Via: SIP/2.0/UDP PROXYIPs:5070;rport=5070;branch=z9hG4bK-qdmfpuvk7r7jnekw.
Max-Forwards: 68.
Route: <sip:MYUSERID@TRUNKIP;lr;received='sip:174.94.113.77:1024'>.
Record-Route: <sip:PROXYIPs;ipnt=8j0-_t23dm3>.
Record-Route: <sip:PROXYIPs;ipnt=8j0dkv23do3>.
Contact: sip:PROXYIPs:5070.
To: <sip:MYUSERID@PROXYIPs>.
From: <sip:CALLERNUMBER@PROXYIPs;tag=zkg5ayzen3lpd5ml.o.
Call-ID: 57162CF5@PROXYIPs~1o.
CSeq: 915 INVITE.
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE.
Content-Disposition: session.
Content-Type: application/sdp.
User-Agent: PortaSIP.
Content-Length: 138.
.
v=0.
o=PortaSIP 3492189661757030230 1 IN IP4 PROXYIPs.
s=-.
t=0 0.
m=audio 61374 RTP/AVP 18 0.
c=IN IP4 PROXYIPs.
a=ptime:20.
#
U 07:04:38.212715 192.168.2.52:5060 -> TRUNKIP:5060 #5
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP TRUNKIP;rport=5060;received=TRUNKIP;branch=z9hG4bK2d13.723ffdc7.0.
Via: SIP/2.0/UDP PROXYIPs:5060;rport=5060;branch=z9hG4bK-524287-1---a8e35cf2080e17e254ab1881926352dc.
Via: SIP/2.0/UDP PROXYIPs:5060;rport=5060;branch=z9hG4bK-524287-1---d8dcd1bf84efdbc47065c5ab19b242cd.
Via: SIP/2.0/UDP PROXYIPs:5070;rport=5070;branch=z9hG4bK-qdmfpuvk7r7jnekw.
Record-Route: <sip:MYUSERID@TRUNKIP;lr>.
Record-Route: <sip:PROXYIPs;ipnt=8j0-_t23dm3>.
Record-Route: <sip:PROXYIPs;ipnt=8j0dkv23do3>.
Call-ID: 57162CF5@PROXYIPs~1o.
From: <sip:CALLERNUMBER@PROXYIPs;tag=zkg5ayzen3lpd5ml.o.
To: <sip:MYUSERID@PROXYIPs>.
CSeq: 915 INVITE.
Server: Asterisk PBX 20.4.0.
Content-Length: 0.
.
#
U 07:04:38.278549 192.168.2.52:5060 -> TRUNKIP:5060 #6
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP TRUNKIP;rport=5060;received=TRUNKIP;branch=z9hG4bK2d13.723ffdc7.0.
Via: SIP/2.0/UDP PROXYIPs:5060;rport=5060;branch=z9hG4bK-524287-1---a8e35cf2080e17e254ab1881926352dc.
Via: SIP/2.0/UDP PROXYIPs:5060;rport=5060;branch=z9hG4bK-524287-1---d8dcd1bf84efdbc47065c5ab19b242cd.
Via: SIP/2.0/UDP PROXYIPs:5070;rport=5070;branch=z9hG4bK-qdmfpuvk7r7jnekw.
Record-Route: <sip:MYUSERID@TRUNKIP;lr>.
Record-Route: <sip:PROXYIPs;ipnt=8j0-_t23dm3>.
Record-Route: <sip:PROXYIPs;ipnt=8j0dkv23do3>.
Call-ID: 57162CF5@PROXYIPs~1o.
From: <sip:CALLERNUMBER@PROXYIPs;tag=zkg5ayzen3lpd5ml.o.
To: <sip:MYUSERID@PROXYIPs;tag=2f10b0de-73f7-4a28-b932-8e9658f58634.
CSeq: 915 INVITE.
Server: Asterisk PBX 20.4.0.
Contact: <sip:192.168.2.52:5060>.
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER.
Content-Length: 0.
.
#
U 07:04:45.747752 192.168.2.52:5060 -> TRUNKIP:5060 #7
SIP/2.0 200 OK.
Via: SIP/2.0/UDP TRUNKIP;rport=5060;received=TRUNKIP;branch=z9hG4bK2d13.723ffdc7.0.
Via: SIP/2.0/UDP PROXYIPs:5060;rport=5060;branch=z9hG4bK-524287-1---a8e35cf2080e17e254ab1881926352dc.
Via: SIP/2.0/UDP PROXYIPs:5060;rport=5060;branch=z9hG4bK-524287-1---d8dcd1bf84efdbc47065c5ab19b242cd.
Via: SIP/2.0/UDP PROXYIPs:5070;rport=5070;branch=z9hG4bK-qdmfpuvk7r7jnekw.
Record-Route: <sip:MYUSERID@TRUNKIP;lr>.
Record-Route: <sip:PROXYIPs;ipnt=8j0-_t23dm3>.
Record-Route: <sip:PROXYIPs;ipnt=8j0dkv23do3>.
Call-ID: 57162CF5@PROXYIPs~1o.
From: <sip:CALLERNUMBER@PROXYIPs;tag=zkg5ayzen3lpd5ml.o.
To: <sip:MYUSERID@PROXYIPs;tag=2f10b0de-73f7-4a28-b932-8e9658f58634.
CSeq: 915 INVITE.
Server: Asterisk PBX 20.4.0.
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER.
Contact: <sip:192.168.2.52:5060>.
Supported: 100rel, timer, replaces, norefersub.
Content-Type: application/sdp.
Content-Length: 172.
.
v=0.
o=- 3042033494 3 IN IP4 192.168.2.52.
s=Asterisk.
c=IN IP4 192.168.2.52.
t=0 0.
m=audio 10928 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
a=ptime:20.
a=maxptime:150.
a=sendrecv.
#
U 07:04:46.248121 192.168.2.52:5060 -> TRUNKIP:5060 #8
SIP/2.0 200 OK.
Via: SIP/2.0/UDP TRUNKIP;rport=5060;received=TRUNKIP;branch=z9hG4bK2d13.723ffdc7.0.
Via: SIP/2.0/UDP PROXYIPs:5060;rport=5060;branch=z9hG4bK-524287-1---a8e35cf2080e17e254ab1881926352dc.
Via: SIP/2.0/UDP PROXYIPs:5060;rport=5060;branch=z9hG4bK-524287-1---d8dcd1bf84efdbc47065c5ab19b242cd.
Via: SIP/2.0/UDP PROXYIPs:5070;rport=5070;branch=z9hG4bK-qdmfpuvk7r7jnekw.
Record-Route: <sip:MYUSERID@TRUNKIP;lr>.
Record-Route: <sip:PROXYIPs;ipnt=8j0-_t23dm3>.
Record-Route: <sip:PROXYIPs;ipnt=8j0dkv23do3>.
Call-ID: 57162CF5@PROXYIPs~1o.
From: <sip:CALLERNUMBER@PROXYIPs;tag=zkg5ayzen3lpd5ml.o.
To: <sip:MYUSERID@PROXYIPs;tag=2f10b0de-73f7-4a28-b932-8e9658f58634.
CSeq: 915 INVITE.
Server: Asterisk PBX 20.4.0.
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER.
Contact: <sip:192.168.2.52:5060>.
Supported: 100rel, timer, replaces, norefersub.
Content-Type: application/sdp.
Content-Length: 172.
.
v=0.
o=- 3042033494 3 IN IP4 192.168.2.52.
s=Asterisk.
c=IN IP4 192.168.2.52.
t=0 0.
m=audio 10928 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
a=ptime:20.
a=maxptime:150.
a=sendrecv.
#
U 07:04:47.247555 192.168.2.52:5060 -> TRUNKIP:5060 #9
SIP/2.0 200 OK.
Via: SIP/2.0/UDP TRUNKIP;rport=5060;received=TRUNKIP;branch=z9hG4bK2d13.723ffdc7.0.
Via: SIP/2.0/UDP PROXYIPs:5060;rport=5060;branch=z9hG4bK-524287-1---a8e35cf2080e17e254ab1881926352dc.
Via: SIP/2.0/UDP PROXYIPs:5060;rport=5060;branch=z9hG4bK-524287-1---d8dcd1bf84efdbc47065c5ab19b242cd.
Via: SIP/2.0/UDP PROXYIPs:5070;rport=5070;branch=z9hG4bK-qdmfpuvk7r7jnekw.
Record-Route: <sip:MYUSERID@TRUNKIP;lr>.
Record-Route: <sip:PROXYIPs;ipnt=8j0-_t23dm3>.
Record-Route: <sip:PROXYIPs;ipnt=8j0dkv23do3>.
Call-ID: 57162CF5@PROXYIPs~1o.
From: <sip:CALLERNUMBER@PROXYIPs;tag=zkg5ayzen3lpd5ml.o.
To: <sip:MYUSERID@PROXYIPs;tag=2f10b0de-73f7-4a28-b932-8e9658f58634.
CSeq: 915 INVITE.
Server: Asterisk PBX 20.4.0.
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER.
Contact: <sip:192.168.2.52:5060>.
Supported: 100rel, timer, replaces, norefersub.
Content-Type: application/sdp.
Content-Length: 172.
.
v=0.
o=- 3042033494 3 IN IP4 192.168.2.52.
s=Asterisk.
c=IN IP4 192.168.2.52.
t=0 0.
m=audio 10928 RTP/AVP 0.
a=rtpmap:0 PCMU/8000.
a=ptime:20.
a=maxptime:150.
a=sendrecv.
This is my pjsip conf
[MYTRUNK1]
type=registration
outbound_auth=MYTRUNK1_auth
contact_user=MYUSERID
server_uri=sip:MYUSERID@DOMAINURL
client_uri=sip:MYUSERID@DOMAINURL
transport=transport-udp
endpoint=MYTRUNK1_endpoint
line=yes
[MYTRUNK1_auth]
type=auth
auth_type=userpass
password=THISISTHETRUNKPASS
username=MYUSERID
[MYTRUNK1_aor]
type=aor
contact=sip:MYUSERID@DOMAINURL:5060
[MYTRUNK1_endpoint]
type=endpoint
context=THISISTHECONTEXT
disallow=all
contact_user=MYUSERID
allow=ulaw
outbound_auth=MYTRUNK1_auth
contact_user=MYUSERID
aors=MYTRUNK1_aor
[MYTRUNK1]
type=identify
endpoint=MYTRUNK1_endpoint
match=DOMAINURL
match=162.213.111.25:5060
match=PROXYIPs/24
The contact_user setting only applies to INVITEs sent. I’ve never seen it be required in the case of a 180 Ringing or 200 OK. What makes you think that is the case?
Since in my old asterisk using chan_sip it is the same answer but in the 200 OK (on answer) the contact has the user and the other server send an ACK for the 200 ok
Moreover, if I’m watching this RFC 3261 - SIP: Session Initiation Protocol the OK as the user in the contact
I’d suggest providing a capture from chan_sip as well then.
As for the RFC, user isn’t required even if it is present in any examples.
This is from a different machine using chan_sip, this machine is using double NAT without problem
#
U 07:34:33.266995 TRUNKIP:5060 -> 192.168.1.52:5060 #93
INVITE sip:MYUSERID@TRUNKIP:5060 SIP/2.0.
Record-Route: <sip:MYUSERID@TRUNKIP;lr=on>.
Via: SIP/2.0/UDP TRUNKIP;branch=z9hG4bKe88a.dc20d8a3.0.
Via: SIP/2.0/UDP PROXYIPs:5060;branch=z9hG4bK-524287-1---ade955e8294c177856bebbbdb1f2423c;rport=5060.
Via: SIP/2.0/UDP PROXYIPs:5060;branch=z9hG4bK-524287-1---03b752a4b4d0f8edb860a420a3d803b8;rport=5060.
Via: SIP/2.0/UDP PROXYIPs:5070;rport=5070;branch=z9hG4bK-x5376q7lgrpeyiij.
Max-Forwards: 68.
Route: <sip:MYUSERID@TRUNKIP;lr;received='sip:174.94.113.77:5060'>.
Record-Route: <sip:PROXYIPs;lr;ep;ipnt=8j0-_t23dm3>.
Record-Route: <sip:PROXYIPs;lr;ep;ipnt=8j0dkv23do3>.
Contact: sip:PROXYIPs:5070.
To: <sip:MYUSERID@PROXYIPs>.
From: <sip:CALLERNUMBER@PROXYIPs>;tag=6zxgn555vllggtzg.o.
Call-ID: F5FCE8A0@PROXYIPs~1o.
CSeq: 936 INVITE.
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE.
Content-Disposition: session.
Content-Type: application/sdp.
User-Agent: PortaSIP.
Content-Length: 138.
.
v=0.
o=PortaSIP 2204021514136562356 1 IN IP4 PROXYIPs.
s=-.
t=0 0.
m=audio 52940 RTP/AVP 18 0.
c=IN IP4 PROXYIPs.
a=ptime:20.
#
U 07:34:33.268261 192.168.1.52:5060 -> TRUNKIP:5060 #94
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP TRUNKIP;branch=z9hG4bKe88a.dc20d8a3.0;received=TRUNKIP.
Via: SIP/2.0/UDP PROXYIPs:5060;branch=z9hG4bK-524287-1---ade955e8294c177856bebbbdb1f2423c;rport=5060.
Via: SIP/2.0/UDP PROXYIPs:5060;branch=z9hG4bK-524287-1---03b752a4b4d0f8edb860a420a3d803b8;rport=5060.
Via: SIP/2.0/UDP PROXYIPs:5070;rport=5070;branch=z9hG4bK-x5376q7lgrpeyiij.
Record-Route: <sip:MYUSERID@TRUNKIP;lr=on>.
Record-Route: <sip:PROXYIPs;lr;ep;ipnt=8j0-_t23dm3>.
Record-Route: <sip:PROXYIPs;lr;ep;ipnt=8j0dkv23do3>.
From: <sip:CALLERNUMBER@PROXYIPs>;tag=6zxgn555vllggtzg.o.
To: <sip:MYUSERID@PROXYIPs>.
Call-ID: F5FCE8A0@PROXYIPs~1o.
CSeq: 936 INVITE.
Server: Asterisk PBX 16.2.1~dfsg-2ubuntu1.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Contact: <sip:MYUSERID@192.168.1.52:5060>.
Content-Length: 0.
.
#
U 07:34:33.335354 192.168.1.52:5060 -> TRUNKIP:5060 #102
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP TRUNKIP;branch=z9hG4bKe88a.dc20d8a3.0;received=TRUNKIP.
Via: SIP/2.0/UDP PROXYIPs:5060;branch=z9hG4bK-524287-1---ade955e8294c177856bebbbdb1f2423c;rport=5060.
Via: SIP/2.0/UDP PROXYIPs:5060;branch=z9hG4bK-524287-1---03b752a4b4d0f8edb860a420a3d803b8;rport=5060.
Via: SIP/2.0/UDP PROXYIPs:5070;rport=5070;branch=z9hG4bK-x5376q7lgrpeyiij.
Record-Route: <sip:MYUSERID@TRUNKIP;lr=on>.
Record-Route: <sip:PROXYIPs;lr;ep;ipnt=8j0-_t23dm3>.
Record-Route: <sip:PROXYIPs;lr;ep;ipnt=8j0dkv23do3>.
From: <sip:CALLERNUMBER@PROXYIPs>;tag=6zxgn555vllggtzg.o.
To: <sip:MYUSERID@PROXYIPs>;tag=as0e29054b.
Call-ID: F5FCE8A0@PROXYIPs~1o.
CSeq: 936 INVITE.
Server: Asterisk PBX 16.2.1~dfsg-2ubuntu1.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Contact: <sip:MYUSERID@192.168.1.52:5060>.
Content-Length: 0.
.
#
U 07:34:47.237717 192.168.1.52:5060 -> TRUNKIP:5060 #116
SIP/2.0 200 OK.
Via: SIP/2.0/UDP TRUNKIP;branch=z9hG4bKe88a.dc20d8a3.0;received=TRUNKIP.
Via: SIP/2.0/UDP PROXYIPs:5060;branch=z9hG4bK-524287-1---ade955e8294c177856bebbbdb1f2423c;rport=5060.
Via: SIP/2.0/UDP PROXYIPs:5060;branch=z9hG4bK-524287-1---03b752a4b4d0f8edb860a420a3d803b8;rport=5060.
Via: SIP/2.0/UDP PROXYIPs:5070;rport=5070;branch=z9hG4bK-x5376q7lgrpeyiij.
Record-Route: <sip:MYUSERID@TRUNKIP;lr=on>.
Record-Route: <sip:PROXYIPs;lr;ep;ipnt=8j0-_t23dm3>.
Record-Route: <sip:PROXYIPs;lr;ep;ipnt=8j0dkv23do3>.
From: <sip:CALLERNUMBER@PROXYIPs>;tag=6zxgn555vllggtzg.o.
To: <sip:MYUSERID@PROXYIPs>;tag=as0e29054b.
Call-ID: F5FCE8A0@PROXYIPs~1o.
CSeq: 936 INVITE.
Server: Asterisk PBX 16.2.1~dfsg-2ubuntu1.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE.
Supported: replaces, timer.
Contact: <sip:MYUSERID@192.168.1.52:5060>.
Remote-Party-ID: "Casa" <sip:1011@PROXYIPs>;party=called;privacy=off;screen=no.
Content-Type: application/sdp.
Content-Length: 244.
.
v=0.
o=root 2106023445 2106023445 IN IP4 192.168.1.52.
s=Asterisk PBX 16.2.1~dfsg-2ubuntu1.
c=IN IP4 192.168.1.52.
t=0 0.
m=audio 11914 RTP/AVP 0 18.
a=rtpmap:0 PCMU/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=maxptime:150.
a=sendrecv.
#
U 07:34:47.271227 TRUNKIP:5060 -> 192.168.1.52:5060 #121
ACK sip:MYUSERID@TRUNKIP:5060 SIP/2.0.
Record-Route: <sip:MYUSERID@TRUNKIP;lr=on>.
Via: SIP/2.0/UDP TRUNKIP;branch=z9hG4bKcydzigwkX.
Via: SIP/2.0/UDP PROXYIPs:5060;branch=z9hG4bK-524287-1---f4520bdee8a5d9aac313082be729d494;rport=5060.
Via: SIP/2.0/UDP PROXYIPs:5060;branch=z9hG4bK-524287-1---d7d86abf01ce158362aaeba2de7a9634;rport=5060.
Via: SIP/2.0/UDP PROXYIPs:5070;rport=5070;branch=z9hG4bK-xewt7ztjpn4qypus.
Max-Forwards: 68.
Route: <sip:MYUSERID@TRUNKIP;lr>.
Contact: sip:PROXYIPs:5070.
To: <sip:MYUSERID@PROXYIPs>;tag=as0e29054b.
From: <sip:CALLERNUMBER@PROXYIPs>;tag=6zxgn555vllggtzg.o.
Call-ID: F5FCE8A0@PROXYIPs~1o.
CSeq: 936 ACK.
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS.
User-Agent: PortaSIP.
Content-Length: 0.
.
I personally think it’s more likely the double NAT situation is different between the two, resulting in one working and one not. It IS possible it is the user portion of the Contact URI, but I lean towards it not being so due to the fact that the Contact URI is supposed to just be a URI to reach back to Asterisk and Asterisk doesn’t care about the user portion. As it stands without code modifications there’s no support for having contact_user apply in such a scenario.
I will do both test on the same machine, however, why all the other signal are working the BYE is working?
The double NAT is on the machine without problem using chan_sip
I agree with the others that USERID in the 180 RING isn’t needed. The other end won’t need to answer the 180. And even the missing USERID in the 200 OK on answer isn’t a problem. The other end can just send an ACK to your server.
But I spot a potential other problem.
You have this in your 200 OK on answer.
c=IN IP4 192.168.2.52.
Do you have an internal server address defined for your asterisk server?
If you have communication with the outside this should be your external IP adres.
You could enable ALG in your router which would translate that… but that’s asking for a whole lot of other problems.
Is ALG enabled on your router? And if not, why is your external IP not set in that package.
I suspect the ACK gets lost there somehow.
And maybe you have ALG enabled on your double NAT (which is why it worked there) but not with this new server.
Thank you, I enable the ALG now I have the public IP instead of 192.168.2.52, but I have the same problem
when the server reply to the 180 with the 200 OK I never receive the ACK and my asterisk is sending it every 2 seconds, till the timeout
Is the contact header, in the 200 OK, correct? If it is, the fault is outside Asterisk.
I am missing the contact user, on asterisk 16 with chan_sip I have it
I should have asked is the address in the contact header correct. As has been pointed out in another current thread, the user part is irrelevant to anything other than Asterisk. If anything its looking at the user part as anything other than something to return, unchanged, as part of the complete contact URI, it is broken. Such brokeness is common enough when handling requests, that Asterisk has a workaround; in that context, it is, incorrectly, being used as some form of account identifier, but there is not even a need for such an identifier on a response.
I did the following test, compiled the asterisk 16 on the same machine
once runned with chain_sip and one with chain_pjsip
with chan_sip is working with chain_pjsip same problem
Here the differences
A20 Supported: 100rel, timer, replaces, norefersub.
A16 Supported: replaces, timer.
A20 Contact: sip:192.168.2.52:5060.
A16 Contact: sip:MYUSER@192.168.2.52:5060.
A16 Remote-Party-ID: “MYCID” sip:1011@208.X.X.X;party=called;privacy=off;screen=no.
I didn’t check the registration
Enable remote party ID.
However, I think you need to replace whatever isn’t capable of handing a valid contact URI.
You should probably ask the provider what they are seeing, first, as it may be a rogue router.
A ammunition, you may want to note:
https://www.rfc-editor.org/rfc/rfc3261.html#section-12.1.2
https://www.rfc-editor.org/rfc/rfc3261.html#section-8.1.1.8
Which says the contact values is a SIP or SIPS URI.
and
https://www.rfc-editor.org/rfc/rfc3261.html#section-19.1.1
which says:
I create my own SIP proxy in python and rewrote the contact, when this was sip:192.168.2.52:5060 I changed in sip:MYUSER@192.168.2.52:5060, therefore, my 200 OK was going out with the full contact, doing so I was able to received the ACK and the call was working as expected.
Now we agree that this is not normal, to force something that it is optional and is not a good implementation from the provider (FreePhoneLine), however, they don’t offer any support and probably is not a mistake.
Is there a way in chan_pjsip to send the contact_user during the 200 OKm since it is optional should be possible?
I believe that Joshua has already said there is no way of sending a bogus one for responses. It’s bogus because Asterisk will make no use of it, and there is no safe use to which the UAC can put it.
How do you see that?
ALG is at router level and it will mange/change the SIP message to translate 192.168.2.52 to your public IP. But YOU don’t see any of that. From your point of view you are still sending the local IP.
But maybe ALG expects @192.168.2.52 in the contact header and doesn’t translate it correctly.
That’s why it’s best to just disable ALG and put the external IP in your pjsip.conf
external_media_address = x.x.x.x
external_signaling_address = x.x.x.x
(make sure ALG is really disabled)
You still have your local IP and I don’t trust the ALG of the router to always correctly substitute the local IP for your external one. It might work in this situation (with your proxy) but it might not always do it correctly.
See https://www.voicehost.co.uk/help/sip-alg-and-why-it-should-be-disabled-most-routers
So my suggestion is to try it with ALG disabled and the external_ setting in the config.
(For me this works behind a NAT)
That’s why I was vague about what is buggy. I’ve not seen anyone say a good word about SIP ALG, and that isn’t limited to Asterisk users.
Hi
The ALG was activated only for a test, I deactivate it after the test, I also changed the transport for the NAT, but didn’t help either.
What solved the problem, but it was a proof of concept, was my proxy which changed the contact, when it was not including the contact_user, therefore, asterisk → pyproxy → provider
I also found a post in the freebox forum having the same issue