[OpenSIPS-Users] Handling SUBSCRIBE & NOTIFIES

Thu Sep 28 04:18:29 EDT 2017

I want topology hiding for SUBSCRIBEs. The 200 OK that is returned by our
servers for the initial SUBSCRIBE reveals the full topology of our system.
We are not using the opensips presence module.

Thanks,
Royee

On Thu, Sep 28, 2017 at 11:08 AM Răzvan Crainea <razvan at opensips.org> wrote:

> Hi, Royee!
>
> Do you need topology hiding for Presence? If not, simply avoid calling
> topology_hiding() for anything else but INVITEs.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Developerwww.opensips-solutions.com
>
> On 09/28/2017 10:57 AM, Royee Tichauer via Users wrote:
>
> 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 <liviu at opensips.org> 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 at 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 <razvan at opensips.org>
>> 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 listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170928/e00f1d1b/attachment.html>