[OpenSIPS-Users] Record-routing & failover (drouting)

[Max Mühlbronner]

Hi,

ok, thanks.

I will look into this, but we got record_route() in the request route 
(initial request) still i can reproduce the error (i can see the invite 
going out without record-route, on gw failover) and if i add another 
record_route it is fine. Maybe i can get some more details.


Best Regards


On 03/19/2013 04:24 PM, Bogdan-Andrei Iancu wrote:
> Hi Max,
>
> If you do the RR on request route, the header will be present in all 
> branches of that INVITE. If you do it later in branch route or failure 
> route, it will be visible only for that branch.
>
> Regards,
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
> On 03/15/2013 09:11 AM, Max Mühlbronner wrote:
>> Hi,
>>
>> thanks very much for your reply. That's also what i thought, first it 
>> was just a siptrace where opensips sends to the second gw but the 
>> invite got no Record-route header.
>>
>> But later on, I was able to reproduce the problem and when adding 
>> another record_route() the second invite is indeed fixed (contains a 
>> record-route header)? Maybe there is some other reason for this 
>> behavior i am not seeing yet?
>>
>>
>> Best Regards
>>
>> Max M.
>>
>> On 03/14/2013 05:35 PM, Muhammad Shahzad wrote:
>>> No, I think the serial forked invite contains same RR and in general 
>>> all changes you did to original invite just before creating the 
>>> transaction (by calling t_newtrans or t_relay or any t_* function 
>>> that creates transaction).
>>>
>>> Thank you.
>>>
>>>
>>> On Thu, Mar 14, 2013 at 5:15 PM, Max Mühlbronner <mm at 42com.com 
>>> <mailto:mm at 42com.com>> wrote:
>>>
>>>     Hi,
>>>
>>>     I am not sure about record-routing in combination with failover
>>>     of drouting. Maybe someone knows for sure :)
>>>
>>>     If i got a configuration where i am record_routing on inital
>>>     invite, but later there is a failover (use_next_gw() returns
>>>     true) and the call is sent to the next gateway. But the serial
>>>     forked call (second INVITE) is missing the Record-route header?
>>>
>>>
>>>     Does this mean i just have to explicitly call record routing
>>>     again on failover? But to me it seems like this can't be right,
>>>     or is this correct/expected behaviour?
>>>
>>>     ||
>>>
>>>     if (use_next_gw()) {
>>>     ...
>>>     record_route();
>>>
>>>     }
>>>
>>>
>>>
>>>     Best Regards
>>>
>>>     -- 
>>>     Max Mühlbronner
>>>
>>>     42com Telecommunication GmbH
>>>     Straße der Pariser Kommune 12-16
>>>     10243 Berlin
>>>
>>>     E-Mail:mm at 42com.com  <mailto:mm at 42com.com>
>>>     Web:www.42com.com  <http://www.42com.com>
>>>
>>>     Firmenangaben/Company information:
>>>     Handelsregister/Commercial register: Amtsgericht Berlin HRB 99071 B
>>>     Umsatzsteuer-ID/VAT-ID: DE223812306
>>>     Geschäftsführer/CEO: Thomas Reinig, Alexander Reinig
>>>
>>>     Diese E-Mail enthält Informationen von 42com Telecommunication GmbH. Diese sind möglicherweise vertraulich und ausschließlich für den Adressaten bestimmt. Sollten Sie diese elektronische Nachricht irrtümlicherweise erhalten haben, so informieren Sie uns bitte unverzüglich telefonisch oder per E-Mail.
>>>
>>>     This message is intended only for the use of the individual or entity to which it is addressed. If you have received this message by mistake, please notify us immediately.
>>>
>>>
>>>     _______________________________________________
>>>     Users mailing list
>>>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>>
>>> -- 
>>> Mit freundlichen Grüßen
>>> Muhammad Shahzad
>>> -----------------------------------
>>> CISCO Rich Media Communication Specialist (CRMCS)
>>> CISCO Certified Network Associate (CCNA)
>>> Cell: +49 176 99 83 10 85
>>> MSN: shari_786pk at hotmail.com <mailto:shari_786pk at hotmail.com>
>>> Email: shaheryarkh at googlemail.com <mailto:shaheryarkh at googlemail.com>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> 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/20130319/b1840e75/attachment.htm>