Currently, OpenSIPS is using the actual IP address in the record-route URI, but I believe my SIP client needs the domain name in the record-route instead.
For example, it should be: Record-Route: <sip:sipdomain.com;lr;nat=yes;did=29.3daff1f4> NOT: Record-Route: <sip:162.242.153.259;lr;nat=yes;did=29.3daff1f4> How can I make this change in the OpenSIPS config? This should solve the problem because in a working setup (different SIP server), the logs state *"Resolving host address 'sipdomain.com <http://sipdomain.com>'"* and the record route URI includes the domain name, but in the OpenSIPS setup the logs state *"Resolving host address '162.242.153.259'* and the record route URI contains the IP address. On 24 August 2015 at 18:37, Nabeel <nabeelshik...@gmail.com> wrote: > Hi, > > I see the cause now on the UAC side; I know it seems simple to just add > some DNS records to the server IP, but I'm still pondering on the best way > to solve this and where exactly to add the SRV records because: > > 1) I already have the SRV records set up on the actual hostname / domain, > hosted by a DNS service third party, which is easier for me to maintain. > However the UAC seems to be ignoring this. > > 2) I have used the same UAC with another server and did not have to set up > SRV on the actual server machine IP. > > I'm not sure if this has anything to do with the OpenSIPS config but I'll > let you know if I solve it. > On 24 Aug 2015 17:56, "Bogdan-Andrei Iancu" <bog...@opensips.org> wrote: > >> Hi , >> >> So, is the problem solved (by your findings in the UAS side) ? >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >> >> On 24.08.2015 18:25, Nabeel wrote: >> >> I just discovered that the SIP client logs show an error message only on >> the recipient side, not on the caller's side. I missed this previously >> because the caller's side log does not show any error: >> >> java.lang.Exception: No DNS SRV or A results found for: 162.242.153.259 >>> (IP address of OpenSIPS server). >> >> >> I have the SRV records set on the actual hostname/domain, but it seems to >> be looking for SRV at the actual IP address itself. >> >> On 21 August 2015 at 17:57, Nabeel <nabeelshik...@gmail.com> wrote: >> >>> The log doesn't show any errors when the Timeout occurs, it only shows >>> this: >>> >>> opensips[1842]: ACC: call missed: >>>> timestamp=1440174643;method=INVITE;from_tag=z9hG4bK04147190;to_tag=;call_id= >>>> 424618310389@10.137.181.237;code=408;reason=Request Timeout >>>> >>> >>> >>> This seems to occur sporadically; some calls connect without problem but >>> others don't; so perhaps it is a genuine timeout... maybe it simply longer >>> to connect on some calls? >>> >>> >>> On 21 August 2015 at 17:46, Nabeel <nabeelshik...@gmail.com> wrote: >>> >>>> Sorry to bring this up again, but I still get the 408 Request Timeout >>>> on some calls. >>>> >>>> Isn't there just a way to increase the request timeout limit? >>>> >>>> Here is the trace: >>>> >>>> http://pastebin.com/jvCPGYDu >>>> >>>> There is even an ACK in the trace after the request timeout message, >>>> but the call doesn't connect. >>>> >>>> On 7 August 2015 at 18:10, Bogdan-Andrei Iancu <bog...@opensips.org> >>>> wrote: >>>> >>>>> Indeed, >>>>> >>>>> Bogdan-Andrei Iancu >>>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>>>> >>>>> On 07.08.2015 20:08, Nabeel wrote: >>>>> >>>>> You mean like this, right? >>>>> >>>>> if (is_method("REGISTER")) >>>>> >>>>> { >>>>> if ( 0 ) setflag(TCP_PERSISTENT); >>>>> >>>>> setbflag(SIP_PING_FLAG); >>>>> >>>>> if (!save("location")) >>>>> sl_reply_error(); >>>>> >>>>> exit; >>>>> } >>>>> >>>>> >>>>> >>>>> On 7 August 2015 at 17:52, Bogdan-Andrei Iancu <bog...@opensips.org> >>>>> wrote: >>>>> >>>>>> Hi Nabeel, >>>>>> >>>>>> Bogdan-Andrei Iancu >>>>>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com >>>>>> >>>>>> On 07.08.2015 19:39, Nabeel wrote: >>>>>> >>>>>> [........] >>>>>> Bogdan, >>>>>> >>>>>> Regarding UDP, I realised that the UDP port could not be in LISTEN >>>>>> state and this was probably preventing my server from fully opening that >>>>>> port. Running nmap on that port showed result "open|filtered", unlike >>>>>> with >>>>>> TCP which showed fully open. I am not running any firewalls on my >>>>>> server, >>>>>> so this seems to be the default behaviour of my network. >>>>>> >>>>>> A bidirectional traffic through the NAT will keep the NAT pinhole >>>>>> open, while a unidirectional one may not. This is the advantage of the >>>>>> SIP >>>>>> pinging versus simple UDP pinging. >>>>>> >>>>>> >>>>>> I would like to clarify one thing. You mentioned adding >>>>>> setbflag(SIP_PING_FLAG) before doing save(), but in my config file I >>>>>> don't >>>>>> see save() anywhere, there is only this line: "if (!save("location"))". >>>>>> Where exactly do I add this line? >>>>>> >>>>>> exactly. >>>>>> >>>>>> Regards, >>>>>> Bogdan >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> >> _______________________________________________ >> Users mailing >> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >>
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users