I also find it very strange you have it working with proxy, ALG disabled and your local IP in the headers. That shouldn’t work so I still suspect there is a ALG in there somewhere that’s messing things up.
I understand that the provider is using it in the wrong way, but it will be great to be added in asterisk and/or pjsip for 0.00001% of the users This will not be against the RFC however probably not so much use it, but in the same time can help some. If someone knows how to make a little patch I will apply to my asterisk. Sorry but I had an average knoledge of asterisk more than 10 years ago (I believe it was <=1.6) know I only transfer the configuration
Isn’t this up to the pjproject at http://www.pjsip.org ?
Although pjproject is bundled with asterisk, the source is downloaded from there during compilation with some patches (unless I totally misunderstood the process).
(Without any knowledge of C and pjproject my guess is that you could need to adjust it in sip_dialog.c > create_uas_dialog.)
Haha, just tried something similar but my change was this:
I don’t think it would matter which ‘user’ you pass and it can even be something nonsense (like ‘dummy’) because it doesn’t get used anyway. Sending a real user would even be a security issue. (I’m not sure what your endpoint->contact_user containt at the moment)
BTW. Seeing the Contact header from the INVITE from the calling server, it also doesn’t have the a ‘user’ included, so why would it demand it from the other side. Really buggy server.
And also… …/1/asterisk-16.30.1/res/res_pjsip.c ???
I thought you where on 20.4.0 ?
In one of my test, it was to go back to 16 (in the previous server I was using 16 with chan_sip), but it is the same mod and I didn’t try to pass a wrong contact_user, if they test it I believe/hope they need it
Thank all to have pushed me to look in the code
Mmm, that’s weird. I’m not sure to what (user)info they would check it against. 180/183 RINGING would have the same dummy contact. Unless it’s their login-username which is used there in endpoint->contact_user.
But I’m glad it works now.
It’s up to the developers to see if they make an option for this.
(although I’m not sure if you would need to file it in the issue section for this to happen)