Depending from case to case, the record-routing can be avoided,
especially if you know the environment and only one server is used
between two endpoints. At that moment you can store existing contact
in htable and replace it with one having the server ip. You can
eventually use uuid to generate the contact to be unique, but not a
must.
The logic would be:
- call comes in, store $sht(x=>$ci::a1:contact) = contact uri
- store $sht(x=>$ci::a1:ftag) = From tag
- replace contact header with one using server ip and send out
- store new contact uri as $sht(x=>$ci::a2:contact)
- replies comes in, store $sht(x=>$ci::b1:contact) = contact uri
- replace contact header with another new one using server ip and
send out
- store new contact uri as $sht(x=>$ci::b2:contact)
- when a request within dialog comes in, based on From tag and
$sht(x=>$ci::a1:ftag), you detect the direction and based on that
you set the appropriate r-uri using either
$sht(x=>$ci::a1:contact) or $sht(x=>$ci::b1:contact) and
replace the contact with a2/b2 variants
Alternative to htable is to use database or other storage (e.g.,
nosql like redis, mongo, ...).
As a matter of fact, upcoming 4.4 includes the topos module which
should do what you want here, but due to lack of time caused by some
unexpected events, at this moment works properly only for MESSAGE
requests. By the time of release I should have the time to fix the
dialog routing as well.
Cheers,
Daniel
On 20/03/16 02:41, Matthew Harrold
wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com