if you enable auto from_restore_mode, you do not need to perform any restore from script. Just replace the from in the initial INVITE and this is it - all replies and sequential request would be auto fixed (restore/replace).
regards, bogdan
Barry Flanagan wrote:
Bogdan-Andrei Iancu wrote:
Hi Barry,
have you set auto from restoring? See: http://openser.org/docs/modules/1.1.x/uac.html#AEN75
Yes, but I am not sure where it is supposed to go.
I have the following in just before relaying to Asterisk:
rewritehostport("XXX.XXX.XXX.XXX:5060"); uac_replace_from("$fn","sip:$au_$ar@$fd"); append_hf("P-hint: GATEWAY\r\n"); t_relay("udp:XXX.XXX.XXX.XXX:5060");and I put in uac_restore_from(); just after the record_route()
with all the other modparams I have:
modparam("uac","from_restore_mode","auto")
Thanks for the help.
-Barry
regards, bogdan
Barry Flanagan wrote:
So, the only way around it that I can see is to somehow have OpenSER change the username to username_domain so that each will be unique.
It looks like uac_from_replace should handle this. I have tried it, and I can see that Asterisk does in fact get user_domain@domain in the first invite, but thereafter for some reason OpenSER changes it to just _@domain for subsequent requests.
Regards,
-Barry
Bogdan-Andrei Iancu wrote:
if you enable auto from_restore_mode, you do not need to perform any restore from script. Just replace the from in the initial INVITE and this is it - all replies and sequential request would be auto fixed (restore/replace).
Aha! Thank you very much - that seems to have done the trick!
Regards,
-Barry Flanagan
regards, bogdan
Barry Flanagan wrote:
Bogdan-Andrei Iancu wrote:
Hi Barry,
have you set auto from restoring? See: http://openser.org/docs/modules/1.1.x/uac.html#AEN75
Yes, but I am not sure where it is supposed to go.
I have the following in just before relaying to Asterisk:
rewritehostport("XXX.XXX.XXX.XXX:5060"); uac_replace_from("$fn","sip:$au_$ar@$fd"); append_hf("P-hint: GATEWAY\r\n"); t_relay("udp:XXX.XXX.XXX.XXX:5060");and I put in uac_restore_from(); just after the record_route()
with all the other modparams I have:
modparam("uac","from_restore_mode","auto")
Thanks for the help.
-Barry
regards, bogdan
Barry Flanagan wrote:
So, the only way around it that I can see is to somehow have OpenSER change the username to username_domain so that each will be unique.
It looks like uac_from_replace should handle this. I have tried it, and I can see that Asterisk does in fact get user_domain@domain in the first invite, but thereafter for some reason OpenSER changes it to just _@domain for subsequent requests.
Regards,
-Barry
Barry Flanagan wrote:
Bogdan-Andrei Iancu wrote:
if you enable auto from_restore_mode, you do not need to perform any restore from script. Just replace the from in the initial INVITE and this is it - all replies and sequential request would be auto fixed (restore/replace).
Aha! Thank you very much - that seems to have done the trick!
Hmm, OK, it did work until I started using nathelper and mediaproxy. With mediaprixy I get no audio, and Asterisk is retransmitting
It appears that mediaproxy is looking for the "unmunged" username. Below is the mediaproxy log for this call. It is expecting from:sipps2@sip.domain.com, whereas asterisk is sending sipps2_domain.com@sip.domain.com
Feb 3 11:25:05 www1 mediaproxy[7461]: command request 1647296070-45779966@XXX.XXX.96.225 XXX.XXX.96.225:12047:audio,XXX.XXX.96.225:12049:video XXX.XXX.96.225 sip.domain.com local sip.domain.com local Nero=20SIPPS=20IP=20Phone=20Version=202.1.3.25 info=from:sipps2@sip.domain.com,to:0863854334@sip.domain.com,fromtag:622fb836,totag: Feb 3 11:25:05 www1 mediaproxy[7461]: session 1647296070-45779966@XXX.XXX.96.225: started. listening on XXX.XXX.1.16:35194,35196
Here Asterisk is retransmitting: Retransmitting #1 (NAT) to XXX.XXX.1.16:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP XXX.XXX.1.16;branch=z9hG4bK9e52.4f879791.0;received=XXX.XXX.1.16 Via: SIP/2.0/UDP XXX.XXX.96.225:12046;branch=z9hG4bKnp1643392953-45a6e6feXXX.XXX.96.225;rport=12020 Record-Route: sip:XXX.XXX.1.16:5060;nat=yes;ftag=61f4a3ce;lr=on From: ""Barry Flanagan"" sip:sipps2_domain.com@sip.domain.com;tag=61f4a3ce To: sip:0863854334@sip.domain.com;tag=as53b2855b Call-ID: 1643422664-49d79852@XXX.XXX.96.225 CSeq: 2 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: sip:0863854334@XXX.XXX.1.68 Content-Type: application/sdp Content-Length: 201
Any idea?
Thanks.
-Barry Flanagan
Regards,
-Barry Flanagan
regards, bogdan
Barry Flanagan wrote:
Bogdan-Andrei Iancu wrote:
Hi Barry,
have you set auto from restoring? See: http://openser.org/docs/modules/1.1.x/uac.html#AEN75
Yes, but I am not sure where it is supposed to go.
I have the following in just before relaying to Asterisk:
rewritehostport("XXX.XXX.XXX.XXX:5060"); uac_replace_from("$fn","sip:$au_$ar@$fd"); append_hf("P-hint: GATEWAY\r\n"); t_relay("udp:XXX.XXX.XXX.XXX:5060");and I put in uac_restore_from(); just after the record_route()
with all the other modparams I have:
modparam("uac","from_restore_mode","auto")
Thanks for the help.
-Barry
regards, bogdan
Barry Flanagan wrote:
So, the only way around it that I can see is to somehow have OpenSER change the username to username_domain so that each will be unique.
It looks like uac_from_replace should handle this. I have tried it, and I can see that Asterisk does in fact get user_domain@domain in the first invite, but thereafter for some reason OpenSER changes it to just _@domain for subsequent requests.
Regards,
-Barry
Hi Barry,
indeed, messing with the FROM URI may brake things that rely on it... not sure about mediaproxy, but nathelper uses only the from-tag, which is not replaced....I would say it should work..have you tried?
regards, bogdan
Barry Flanagan wrote:
Barry Flanagan wrote:
Bogdan-Andrei Iancu wrote:
if you enable auto from_restore_mode, you do not need to perform any restore from script. Just replace the from in the initial INVITE and this is it - all replies and sequential request would be auto fixed (restore/replace).
Aha! Thank you very much - that seems to have done the trick!
Hmm, OK, it did work until I started using nathelper and mediaproxy. With mediaprixy I get no audio, and Asterisk is retransmitting
It appears that mediaproxy is looking for the "unmunged" username. Below is the mediaproxy log for this call. It is expecting from:sipps2@sip.domain.com, whereas asterisk is sending sipps2_domain.com@sip.domain.com
Feb 3 11:25:05 www1 mediaproxy[7461]: command request 1647296070-45779966@XXX.XXX.96.225 XXX.XXX.96.225:12047:audio,XXX.XXX.96.225:12049:video XXX.XXX.96.225 sip.domain.com local sip.domain.com local Nero=20SIPPS=20IP=20Phone=20Version=202.1.3.25 info=from:sipps2@sip.domain.com,to:0863854334@sip.domain.com,fromtag:622fb836,totag:
Feb 3 11:25:05 www1 mediaproxy[7461]: session 1647296070-45779966@XXX.XXX.96.225: started. listening on XXX.XXX.1.16:35194,35196
Here Asterisk is retransmitting: Retransmitting #1 (NAT) to XXX.XXX.1.16:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP XXX.XXX.1.16;branch=z9hG4bK9e52.4f879791.0;received=XXX.XXX.1.16 Via: SIP/2.0/UDP XXX.XXX.96.225:12046;branch=z9hG4bKnp1643392953-45a6e6feXXX.XXX.96.225;rport=12020
Record-Route: sip:XXX.XXX.1.16:5060;nat=yes;ftag=61f4a3ce;lr=on From: ""Barry Flanagan"" sip:sipps2_domain.com@sip.domain.com;tag=61f4a3ce To: sip:0863854334@sip.domain.com;tag=as53b2855b Call-ID: 1643422664-49d79852@XXX.XXX.96.225 CSeq: 2 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: sip:0863854334@XXX.XXX.1.68 Content-Type: application/sdp Content-Length: 201
Any idea?
Thanks.
-Barry Flanagan
Regards,
-Barry Flanagan
regards, bogdan
Barry Flanagan wrote:
Bogdan-Andrei Iancu wrote:
Hi Barry,
have you set auto from restoring? See: http://openser.org/docs/modules/1.1.x/uac.html#AEN75
Yes, but I am not sure where it is supposed to go.
I have the following in just before relaying to Asterisk:
rewritehostport("XXX.XXX.XXX.XXX:5060"); uac_replace_from("$fn","sip:$au_$ar@$fd"); append_hf("P-hint: GATEWAY\r\n"); t_relay("udp:XXX.XXX.XXX.XXX:5060");and I put in uac_restore_from(); just after the record_route()
with all the other modparams I have:
modparam("uac","from_restore_mode","auto")
Thanks for the help.
-Barry
regards, bogdan
Barry Flanagan wrote:
So, the only way around it that I can see is to somehow have OpenSER change the username to username_domain so that each will be unique.
It looks like uac_from_replace should handle this. I have tried it, and I can see that Asterisk does in fact get user_domain@domain in the first invite, but thereafter for some reason OpenSER changes it to just _@domain for subsequent requests.
Regards,
-Barry
Bogdan-Andrei Iancu wrote:
Hi Barry,
indeed, messing with the FROM URI may brake things that rely on it... not sure about mediaproxy, but nathelper uses only the from-tag, which is not replaced....I would say it should work..have you tried?
Yes, nathelper on its own appears to be ok.
Is nathelper on its own generally sufficient for a public SIP server where most clients are behind NAT?
Thanks.
-Barry
regards, bogdan
Barry Flanagan wrote:
Barry Flanagan wrote:
Bogdan-Andrei Iancu wrote:
if you enable auto from_restore_mode, you do not need to perform any restore from script. Just replace the from in the initial INVITE and this is it - all replies and sequential request would be auto fixed (restore/replace).
Aha! Thank you very much - that seems to have done the trick!
Hmm, OK, it did work until I started using nathelper and mediaproxy. With mediaprixy I get no audio, and Asterisk is retransmitting
It appears that mediaproxy is looking for the "unmunged" username. Below is the mediaproxy log for this call. It is expecting from:sipps2@sip.domain.com, whereas asterisk is sending sipps2_domain.com@sip.domain.com
Feb 3 11:25:05 www1 mediaproxy[7461]: command request 1647296070-45779966@XXX.XXX.96.225 XXX.XXX.96.225:12047:audio,XXX.XXX.96.225:12049:video XXX.XXX.96.225 sip.domain.com local sip.domain.com local Nero=20SIPPS=20IP=20Phone=20Version=202.1.3.25 info=from:sipps2@sip.domain.com,to:0863854334@sip.domain.com,fromtag:622fb836,totag:
Feb 3 11:25:05 www1 mediaproxy[7461]: session 1647296070-45779966@XXX.XXX.96.225: started. listening on XXX.XXX.1.16:35194,35196
Here Asterisk is retransmitting: Retransmitting #1 (NAT) to XXX.XXX.1.16:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP XXX.XXX.1.16;branch=z9hG4bK9e52.4f879791.0;received=XXX.XXX.1.16 Via: SIP/2.0/UDP XXX.XXX.96.225:12046;branch=z9hG4bKnp1643392953-45a6e6feXXX.XXX.96.225;rport=12020
Record-Route: sip:XXX.XXX.1.16:5060;nat=yes;ftag=61f4a3ce;lr=on From: ""Barry Flanagan"" sip:sipps2_domain.com@sip.domain.com;tag=61f4a3ce To: sip:0863854334@sip.domain.com;tag=as53b2855b Call-ID: 1643422664-49d79852@XXX.XXX.96.225 CSeq: 2 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: sip:0863854334@XXX.XXX.1.68 Content-Type: application/sdp Content-Length: 201
Any idea?
Thanks.
-Barry Flanagan
Regards,
-Barry Flanagan
regards, bogdan
Barry Flanagan wrote:
Bogdan-Andrei Iancu wrote:
Hi Barry,
have you set auto from restoring? See: http://openser.org/docs/modules/1.1.x/uac.html#AEN75
Yes, but I am not sure where it is supposed to go.
I have the following in just before relaying to Asterisk:
rewritehostport("XXX.XXX.XXX.XXX:5060"); uac_replace_from("$fn","sip:$au_$ar@$fd"); append_hf("P-hint: GATEWAY\r\n"); t_relay("udp:XXX.XXX.XXX.XXX:5060");and I put in uac_restore_from(); just after the record_route()
with all the other modparams I have:
modparam("uac","from_restore_mode","auto")
Thanks for the help.
-Barry
regards, bogdan
Barry Flanagan wrote:
> > So, the only way around it that I can see is to somehow have > OpenSER change the username to username_domain so that each will > be unique. > > It looks like uac_from_replace should handle this. I have tried > it, and I can see that Asterisk does in fact get > user_domain@domain in the first invite, but thereafter for some > reason OpenSER changes it to just _@domain for subsequent requests. > > > Regards, > > -Barry >
Barry Flanagan wrote:
Bogdan-Andrei Iancu wrote:
Hi Barry,
indeed, messing with the FROM URI may brake things that rely on it... not sure about mediaproxy, but nathelper uses only the from-tag, which is not replaced....I would say it should work..have you tried?
Yes, nathelper on its own appears to be ok.
Is nathelper on its own generally sufficient for a public SIP server where most clients are behind NAT?
yes, nathelper + rtpproxy can do the job.
regards, bogdan
-
Barry Flanagan -
Bogdan-Andrei Iancu