[SR-Users] Re: Access avp vars in a cancel? How to pass information from an INVITE to a CANCEL?

Hi Alex *sigh* yes I guess you may ask. Somehow I think we do 'normal' VSP business, but it looks like we seem to have a complicated set-up. Our set-up basically looks like this: We have a core kamailio node taking care of dialog handling, CDR gathering for billing, routing and which has interconnections to other VSP, voicemail etc. but they are more or less firewalled from the internet. We have a registrar kamailio node taking care of connected customer, dynamic registrations, authentication facing the bad dangerous internet. No dialog module enable! This node does not know how to route stuff. It his relatively simple minded. If the call is from a customer, route it to the core who will then account for the call and know how to route. If the call is from the core, then look up the location and route to the customer if registered. Of course there is more like failure handling, call forwarding handling etc. but you get the basic idea. At the moment, we use a commercial SBC to handle RTP on the interconnection side to other VSP, but also to proxy RTP and registrations from customer CPE. Especially with registrations it's not always behaving according to SIP standard and causes a lot of issues. But also on the interconnection to other VSP side, it has some limitations, for example it can't stand crypto in an SDP and will reply with 450 (or whatever the sip code is to reject an SDP) when crypto is present. It also considers ipv6 addresses to be something that needs rejecting. We want to get rid of the SBC, especially on the side towards our customer, the sooner the better. Hey we could allow customers to encrypt their RTP traffic and talk a modern ip protocol! So, as the registrar are facing the bad and dangerous internet anyway I somehow prefer to keep our core kamailio a bit behind firewalls, my conclusion was to run rtpengine on the registrar any maybe also benefit from some advantages with firewalls and cpe who prefer to exchange RTP and Signaling to the same IP. Now picture customer A on the registrar calling customer B on the same registrar. The registrar authenticates the caller, rtpengine maybe talks ipv6 and crypto as suggested by the caller, throws in some ICE magic etc. all nice stuff to do with the customer. But as the registrar instance has no clue where the destination number is, it just routes the call to the core. As the destination could be behind our SBC, or maybe another VSP which only accepts IPv4, I have to make sure I remove crypto and use IPv4 in the SDP towards the core. Well, now the call is on the core, the routing table for the destination is looked up. Hey, it's also a customer of ours, let's route the call back to the registrar! The registrar look up the location table and determines what ip version and protocol that customer is registered with, if it's IPv6 then activate ICE. Offer Crypto! Well, for this to work, I need to run the call separately through rtpengine again, with a different callID. If I activate loop-protect on rtpengine, then the settings which are compatible towards our SBC and interconnection would be sent to the customer as the 2nd invocation of rtpengine would be ignored. I hope this makes sense. -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- 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 ______________________________________________________