[SR-Users] Re: How to use @via[idx] ?

Hi Alex I attempt to find a way, without using the dialog module, to determine in which loop I am. The same old issue I am still desperately trying to solve: Two customer behind the SAME Registrar. CPE A => Kam Registrar => Kam Core => Kam Registrar => CPE B I want to be able to find out, if I work on messages/replies in a transaction to CPE A or in a transaction to CPE B. It looks like this is required to make rtpengine (on the Registrar) work by adding some counter to the callid or fromtag or whatever so rtpengine does not confuse the two different invocations. If anyone has any idea how to solve this in a simpler way I would really love to know how. Not routing the call via Core is not an option (core does billing, routing and dialog handling and has interconnections to other telcos, besides the registrar is intentionally 'dumb' and does not know how to route calls). What could work (I am not sure if it would) looking at for example the first invite is if there would be a way to only keep the 2nd one. eg: INVITE CPE A => Registrar => Core rtpengine processing 'offer' from A to CORE INVITE CORE => Registrar => CPE B rtpengine processing 'offer' from CORE to B if this 2nc offer could 'overwrite' the first one received this may work. It does not work(*1) the way the built-in rtpengine loop detection works by just ignoring subsequent offers after the first one was received. (*1) Maybe I have to explain what fails... A CPE might be connected via IPv6. Interconnections with other telcos still run via legacy IPv4 same with most of the registered CPE. So when CPE A calls with ipv6 I add address-family=IP4 to ensure that the core is getting an IPv4 SDP. But when CPE B has an IPv6 contact registered I need to set address-family=IP6 to ensure it is getting an IPv6 SDP. If the 2nd invocation of rtpengine is dropped (actual rtpengine loop detection behavior), IPv6 CPE B is getting an IPv4 SDP. If the 2nd invocation of rtpengine would replace the 1st invocation, then maybe, thinks could work out just fine. Offering ICE is helping - only there are CPE which do not support ICE and therefore 488 a SDP with an unsupported protocol in the c= line even if ICE would offer a supported one. Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________