Thats that solves that then. Is there a way I can do topology hiding to only of the legs to work around this issue?
Thanks, Royee On Thu, Sep 28, 2017 at 9:36 AM Liviu Chircu <[email protected]> wrote: > Quoted params in Contact header parameters are accepted, according to RFC > 3261 § 25.1: > > contact-params = c-p-q / c-p-expires > / contact-extension > contact-extension = generic-param > generic-param = token [ EQUAL gen-value ] > gen-value = token / host / quoted-string > quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE > > Liviu Chircu > OpenSIPS Developerhttp://www.opensips-solutions.com > > On 28.09.2017 08:58, Royee Tichauer via Users wrote: > > Understood, thanks Razvaan. > > Another issue I'm having here with SUBSCRIBE handling is with topology > hiding. When I use the topology hiding module an extra header parameter > named 'thinfo' is added to the contact field as explained in the docs. The > field parameter value contains parenthesis surrounding it. For example the > contact header I got was: > > Contact: <sip:52.70.236.51:51842;transport=tcp;thinfo=*"* > dm1KMyPQIyIU9fUQFpcQ0AVUdEXFwdbHNjClRbTF9TAGlwdkwWCBgeFFwoM3BMCBphbfKX18CEpfRENWAGhpfApUU0ddVANo > *"*> > > The SUBSCRIBE request is being routed to another server which uses Java's > Jane library. This library attempts to parse the headers of the SIP message > and throws an exception of this contact header. When I remove the > parenthesis it does work. My question is whether parenthesis are allowed in > contact field headers or not. It seems that either opensips should not add > these or that Jane has a bug in I tried to look in the RFC-3261 section > 20.10 <https://tools.ietf.org/html/rfc3261#section-20.10> but didn't get > a concrete answer. > > Here are the Java Jain implementation of trying to parse the header and > receiving an exception, I also have a sample > <https://drive.google.com/open?id=0B1qvsk1sLQdPb2MzZkNVQXFncGM> of this > project in case it helps: > > String sWithParenthesis = "Contact: > <sip:52.70.236.51:51842;transport=tcp;thinfo=\"dm1KMyPQIyIU9fUQFpcQ0AVUdEXFwdbHNjClRbTF9TAGlwdkwWCBgeFFwoM3BMCBphbfKX18CEpfRENWAGhpfApUU0ddVANo\">" > + "\n"; > > HeaderParser h = ParserFactory.createParser(sWithParenthesis); > > SIPHeader header = h.parse(); > System.out.println(header.getName()); > System.out.println(header.getHeaderValue()); > > > And this is the exception I am getting: > > Exception in thread "main" java.text.ParseException: [C@6477463f > Expecting >>>><<< got >>>"<<< > at gov.nist.core.LexerCore.match(LexerCore.java:284) > at gov.nist.javax.sip.parser.AddressParser.nameAddr(AddressParser.java:63) > at gov.nist.javax.sip.parser.AddressParser.address(AddressParser.java:112) > at > gov.nist.javax.sip.parser.AddressParametersParser.parse(AddressParametersParser.java:55) > at gov.nist.javax.sip.parser.ContactParser.parse(ContactParser.java:69) > at com.vonage.Main.main(Main.java:14) > … > > On Tue, Sep 26, 2017 at 7:31 PM Răzvan Crainea <[email protected]> > wrote: > >> Hi, Royee! >> >> There's no need for an actual dialog (from OpenSIPS pov) - you can simply >> route the NOTIFY messages as sequentials - route them according to the >> Record-Route headers. >> >> Best regards, >> >> Răzvan Crainea >> OpenSIPS Developerwww.opensips-solutions.com >> >> On 09/25/2017 07:06 PM, Royee Tichauer via Users wrote: >> >> Hi, >> >> I am using opensips 2.1 as a SIP proxy and I am trying to figure out how >> to best handle SUBSCRIBE messages which need to be routed through to >> another SIP component. As I read in the rfc3265 >> <https://tools.ietf.org/html/rfc3265#ref-1> an initial (out of call) >> SUBSCRIBE creates a dialog which NOTIFYs and following SUBSCRIBE messages >> are part of and are routed within the same dialog. >> >> From looking at the opensips code I see that when "create_dialog" is >> called then the request is only handled if it is an INVITE request. So I'm >> trying to understand what is the proper way of handling the SUBSCRIBEs that >> come from the devices and the NOTIFYs that come from the PBX after the >> SUBSCRIBE is accepted. >> >> If there are examples for handling such SUBSCRIBEs that would be great. >> >> Thanks, >> Royee >> >> >> >> >> _______________________________________________ >> Users mailing >> [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > _______________________________________________ > Users mailing > [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
