Bogdan,
I don't think the uac_redirect module in this case is helpful. The Contact
data that comes back from an LRN DIP's 302 isn't a real SIP URI, but rather
just some routing data that happens to be using a 302's Contact field as a
transport mechanism.
Kent,
Sorry for the late reply... I
Hi Jeff,
Well, according to RFC3261, a Contact hdr must carry a valid SIP URI -
now, in dip lookups, the answer is added as params to the SIP URI or to
the CT SIP hdr...depending...
If you uac_redirect does not server your purpose (like answer in in CT
hdr params), you can access the hdr
Hi Kpirlo,
When sending the call to the dip provider, use a failure route in order
to catch the 3xx reply you get back. In the failure route, use the
uac_redirect module with the get_redirects() function
(http://www.opensips.org/html/docs/modules/1.7.x/uac_redirect.html#id250367)
in order to
Kent,
I also subscribe to a simliar service. I capture the fields I need in the
302's Contact header inside the onreply_route, then use that data to
perform the least cost routing.
- Jeff
___
Users mailing list
Users@lists.opensips.org
Kent,
I also subscribe to a simliar service. I capture the fields I need in the
302's Contact header inside the onreply_route, then use that data to
perform the least cost routing.
- Jeff
___
Users mailing list
Users@lists.opensips.org
We are currently using the Dynamic routing module for our least cost
routing.
Now we are looking at implementing an LRN dipping service, where we will
send the call to a dip provider first and receive a 302 redirect back which
will have the LRN returned in the contact header as rn= if the number
