[OpenSIPS-Users] Handling SUBSCRIBE & NOTIFIES
Răzvan Crainea
razvan at opensips.org
Fri Sep 29 05:14:56 EDT 2017
If you want to do topology hiding for Presence, then there is no other
way to do it, rather than storing the actual topology info in the
contact header :(.
Best regards,
Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com
On 09/28/2017 11:18 AM, Royee Tichauer via Users wrote:
> 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
> <mailto: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 Developer
> www.opensips-solutions.com <http://www.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
>> <mailto: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 Developer
>> http://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 <mailto: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 Developer
>>> www.opensips-solutions.com
>>> <http://www.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 list
>>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://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/20170929/f68572a1/attachment-0001.html>
More information about the Users
mailing list