[OpenSIPS-Users] Double via in MI generated NOTIFY
Bogdan-Andrei Iancu
bogdan at opensips.org
Thu Jun 4 17:43:40 CEST 2015
Stas,
As per ticket, I tried both 2.1 and 1.11 and there is no double VIA when
the message is originally leaving the server (via MI). My 2 cents
(considering the 2 VIAs are actually different) - i thing your request
spirals on your opensips.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 04.06.2015 16:17, Stas Kobzar wrote:
> Hello Bogdan,
>
> In fact the branch parameters are different:
> Via: SIP/2.0/UDP 10.130.8.20:5060;branch=z9hG4bK0872.598957f2.0.
> Via: SIP/2.0/UDP 10.130.8.20:5060;branch=z9hG4bK0872.498957f2.0.
>
> They look alike and different only with one number.
>
> I did not try it with 2.1 but had the same issue on 1.8 and 1.11.
>
> Regards,
> Stas
>
>
>
> On Thu, Jun 4, 2015 at 6:50 AM, Bogdan-Andrei Iancu
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
> Ben,
>
> If is spirals undetected (as I think you suggest), the branch in
> via should be different.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
> On 04.06.2015 02:00, Newlin, Ben wrote:
>> It sounds like you may be sending the NOTIFY to yourself when you
>> use the domain name instead of the IP. Have you verified the
>> address that the domain resolves to? Is it the same as the
>> OpenSIPS instance?
>>
>> Ben Newlin
>>
>> From: Stas Kobzar
>> Reply-To: OpenSIPS users mailling list
>> Date: Wednesday, June 3, 2015 at 6:00 PM
>> To: Bogdan-Andrei Iancu
>> Cc: OpenSIPS users mailling list
>> Subject: Re: [OpenSIPS-Users] Double via in MI generated NOTIFY
>>
>> Hi Bogdan,
>>
>> No, I do not use local_route at all.
>>
>> My code for these kind of notifies is in the beginning of the
>> initial part or main route after t_check_trans and looks like this:
>>
>> ----------------------------------------------------------------------------------------
>> t_check_trans();
>>
>> # RFC3265: NOTIFY can not be outside SIP dialog.
>> # So we should drop the packet
>> if(is_method("NOTIFY")) {
>> # There is an exception: if this is a check-sync packet
>> # for phone configuration reload request
>> if($hdr(Event) =~ "check-sync"){
>> lookup("locations", "m");
>> xlog("L_INFO", "$ci|$rm| Send reboot request notify packet to
>> destination $ru");
>> t_relay();
>> exit();
>> }
>> send_reply("481","Dialog does not exists");
>> exit;
>> }
>> ----------------------------------------------------------------------------------------
>>
>> I have tried different scenarios:
>> - Put this code before t_check_trans
>> - do not use lookup function
>> - replaced t_relay with forward
>>
>> Nothing helped.
>>
>> However, when I run fifo command using IP address in sip URI,
>> like this:
>> opensipsctl fifo t_uac_dlg NOTIFY sip:7037 at 10.130.8.225
>> <mailto:sip%3A7037 at 10.130.8.225> . . '"From:
>> <sip:7037 at voip.etsmtl.ca
>> <mailto:sip%3A7037 at voip.etsmtl.ca>>;tag=8755a8d01aa27e903a6f4ccaf393f04\r\nTo:
>> <sip:7037 at voip.etsmtl.ca
>> <mailto:sip%3A7037 at voip.etsmtl.ca>>\r\nEvent: check-sync\r\n"'
>>
>> then, the packet seems to send directly from local_route.
>> Because, in this case, I do not even see it in the logs.
>>
>> Thank you!
>> Stas
>>
>>
>>
>>
>>
>> On Wed, Jun 3, 2015 at 11:05 AM, Bogdan-Andrei Iancu
>> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>
>> Hi Stas,
>>
>> Do you do any local_route stuff ? If yes, do you modify the
>> RURI/DURI or other parts of the requests?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 01.06.2015 17:42, Stas Kobzar wrote:
>>> Hello,
>>>
>>> I am sending NOTIFY packet with event "check-sync" to reload
>>> phone configuration.
>>>
>>> I am doing it with opensips FIFO mi.
>>>
>>> My command looks like this:
>>> opensipsctl fifo t_uac_dlg NOTIFY sip:7037 at 10.130.8.225
>>> <mailto:sip%3A7037 at 10.130.8.225> . . '"From:
>>> <sip:7037 at voip.etsmtl.ca
>>> <mailto:sip%3A7037 at voip.etsmtl.ca>>;tag=8755a8d01aa27e903a6f4ccaf393f04\r\nTo:
>>> <sip:7037 at voip.etsmtl.ca
>>> <mailto:sip%3A7037 at voip.etsmtl.ca>>\r\nEvent: check-sync\r\n"'
>>>
>>> When I use IP address in RURI (sip:7037 at 10.130.8.225
>>> <mailto:sip%3A7037 at 10.130.8.225>) it works as expected.
>>>
>>> However, when I use domain name in RURI (like this:
>>> sip:7037 at campus.voip.etsmtl.ca
>>> <mailto:sip%3A7037 at campus.voip.etsmtl.ca>) and my command
>>> looks like this:
>>> opensipsctl fifo t_uac_dlg NOTIFY
>>> sip:7037 at campus.voip.etsmtl.ca
>>> <mailto:sip%3A7037 at campus.voip.etsmtl.ca> . . '"From:
>>> <sip:7037 at voip.etsmtl.ca
>>> <mailto:sip%3A7037 at voip.etsmtl.ca>>;tag=8755a8d01aa27e903a6f4ccaf393f04\r\nTo:
>>> <sip:7037 at voip.etsmtl.ca
>>> <mailto:sip%3A7037 at voip.etsmtl.ca>>\r\nEvent: check-sync\r\n"'
>>>
>>> I have two Via headers in my resulting NOTIFY packet with
>>> different branche tags:
>>>
>>> NOTIFY sip:7037 at 10.130.8.225
>>> <mailto:sip%3A7037 at 10.130.8.225> SIP/2.0.
>>> Via: SIP/2.0/UDP 10.130.8.20:5060;branch=z9hG4bK0872.598957f2.0.
>>> Via: SIP/2.0/UDP 10.130.8.20:5060;branch=z9hG4bK0872.498957f2.0.
>>> To: sip:7037 at campus.voip.etsmtl.ca
>>> <mailto:sip%3A7037 at campus.voip.etsmtl.ca>.
>>> From: <sip:7037 at campus.voip.etsmtl.ca
>>> <mailto:sip%3A7037 at campus.voip.etsmtl.ca>>;tag=734c62bd59eb9f33d3e6313898450dd1.
>>> CSeq: 10 NOTIFY.
>>> Call-ID: 693206c572f70ff6-19332 at 10.130.8.20
>>> <mailto:693206c572f70ff6-19332 at 10.130.8.20>.
>>> Max-Forwards: 69.
>>> Content-Length: 0.
>>> Server: ETS voip router01.
>>> Event: check-sync
>>> .
>>>
>>>
>>> In first case, I do not even see the packet in main route
>>> but I see it in local_route.
>>>
>>> In my second case I see it in main route but the packet is
>>> sent with double Via header.
>>>
>>> I am sure it is not my routing script, because I have just
>>> put a forward to some IP whenever NOTIFY is received and I
>>> still have this problem.
>>>
>>> Is it a known issue?
>>>
>>> Everything still works fine, but having a double Via in logs
>>> a bit confusing.
>>>
>>> Thank you,
>>> --
>>>
>>> Stas Kobzar
>>>
>>> Developeur VoIP / VoIP Developer
>>>
>>> ___________________
>>>
>>>
>>> Modulis.ca Inc.
>>>
>>> # Bureau / Office: 514-284-2020 x 246
>>> <tel:514-284-2020%20x%20246>
>>>
>>> Email: s <http://firstname.lastname>tas.kobzar at modulis.ca
>>>
>>> https://www.modulis.com <https://www.modulis.com/>
>>>
>>>
>>> <https://www.modulis.com/es-url-001>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>> --
>>
>> Stas Kobzar
>>
>> Developeur VoIP / VoIP Developer
>>
>> ___________________
>>
>>
>> Modulis.ca Inc.
>>
>> # Bureau / Office: 514-284-2020 x 246 <tel:514-284-2020%20x%20246>
>>
>> Email: s <http://firstname.lastname>tas.kobzar at modulis.ca
>>
>> https://www.modulis.com <https://www.modulis.com/>
>>
>>
>> <https://www.modulis.com/es-url-001>
>>
>>
>> _______________________________________________
>> 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
>
>
>
>
> --
>
> Stas Kobzar
>
> Developeur VoIP / VoIP Developer
>
> ___________________
>
>
> Modulis.ca Inc.
>
> # Bureau / Office: 514-284-2020 x 246
>
> Email: s <http://firstname.lastname>tas.kobzar at modulis.ca
>
> https://www.modulis.com <https://www.modulis.com/>
>
>
> <https://www.modulis.com/es-url-001>
>
>
> _______________________________________________
> 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/20150604/b866e6c7/attachment-0001.htm>
More information about the Users
mailing list