[SR-Users] Redirect Server Including Path/Recieved Information
Daniel-Constantin Mierla
miconda at gmail.com
Fri Jan 9 15:51:20 CET 2015
Hello,
I saw others commenting regarding some patch -- not sure if merged or not.
But, if there is no other specific requirement to get the 30x to media
server (like extra processing on received contact), an option could be
to just forward on the 'redirect' server without doing the
record_route(). It means the 'redirect' server is involved only for
first INVITE of the call, everything else is media server to proxy load
balancer.
Cheers,
Daniel
On 09/01/15 15:43, Asgaroth wrote:
> Hi,
>
> The media server, redirect server and proxy/loadbalancer are all on
> the same local LAN, signaling is direct in local LAN, between media
> server and redirect server, and again from media server to proxy
> loadbalancer.
>
> Thanks
>
>
> On 09/01/2015 14:22, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> where is the media server located and the signaling flow for it?
>>
>> Cheers,
>> Daniel
>>
>> On 09/01/15 14:41, Asgaroth wrote:
>>> Hi,
>>>
>>> I am hoping to have the redirect server not be in the signalling path,
>>> so when a media server asterisk/freeswitch sends an invite over to the
>>> redirect server, I need to respond with the 302 and include the
>>> contact information, outbound path (via proxy loadbalancer) and the
>>> recieved information to let the proxy/loadbalancer know where to
>>> forward to.
>>>
>>> So when a client registers it comes in like this:
>>>
>>> UAC --> Firewall --> Proxy --> Registrar
>>>
>>> At this point the registrar stores the recieved host:port of firewall,
>>> and path via the proxy.
>>>
>>> When I send a redirect, I want the media server to travers the path
>>> via the route the uac registered with:
>>>
>>> uas invite --> redirect server
>>> uas <-- 302
>>> uas invite --> proxy (path) --> firewall (recieved) --> uac
>>>
>>> I am not sure how to provide the path information in the 302 response.
>>> I tried to add it as a madd parameter in the contact header but it
>>> then uses the port defined in the host part of the uri as the proxy
>>> port. I cant seem to find a reference as to how to do this.
>>>
>>> for example, uac is registered with following info (info manipulated
>>> to protect the poor :) ) and pulled from location table:
>>>
>>> Contact:
>>> sip:username at 192.168.1.150:55023;rinstance=9dc7a3f0e662b2cd;transport=UDP
>>>
>>> Recieved: sip:213.146.165.189:20185
>>> Path: <sip:77.87.89.91;lr;received="sip:213.146.165.189:20185">
>>>
>>> I tried to perform a redirect with the following information in the
>>> contact
>>>
>>> Contact:
>>> <sip:username at 192.168.1.150:55023;rinstance=9dc7a3f0e662b2cd;transport=UDP;received=sip:213.146.165.189:20185,maddr=77.87.89.91>
>>>
>>>
>>> The problem here is that the media server attempts to send the new
>>> invite to port 55023 at the host specified by the maddr (77.87.89.91)
>>> parameter.
>>>
>>> I did some more reading this morning and I can see that the rfc says
>>> that the new invite should be relayed in this manner.
>>>
>>> How would I specify the equivilent of $du in a 302 response message?
>>>
>>> I hope that explains it a little better.
>>>
>>> Thanks
>>>
>>>
>>> On 09/01/2015 13:14, Daniel-Constantin Mierla wrote:
>>>> Hello,
>>>>
>>>> I am not sure if path and received from location will be of any
>>>> information for the redirect. At least received is the proto,
>>>> source and
>>>> port of incoming REGISTER. Then, the Path is to be used by location
>>>> server when forwarding requests.
>>>>
>>>> Can you give more details of how path and received from location
>>>> should
>>>> be used by the one receiving the 30x redirect?
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>> On 08/01/15 22:09, Asgaroth wrote:
>>>>> Hi All,
>>>>>
>>>>> I am attempting to setup a standalone redirect server which will
>>>>> lookup contact info and redirect to appropriate outbound proxy.
>>>>>
>>>>> The problem I am having is that the registrar is storing the path and
>>>>> recieved information, however, when I perform a lookup and reply with
>>>>> 302, the recieved and path information is not included.
>>>>>
>>>>> Are there module parameters in the registrar module that will include
>>>>> these contact parameters (recieved) or create the appropriate headers
>>>>> (path/route) in the 302 response, or, is this something I need to do
>>>>> manually.
>>>>>
>>>>> Currently I have the following lookup code:
>>>>>
>>>>> route {
>>>>>
>>>>> t_check_trans();
>>>>>
>>>>> if ( method == "INVITE" ) {
>>>>> xlog("route[MAIN] : $rm : ruri=$ru");
>>>>> xlog("route[MAIN] : $rm : lookup=sip:$rU at registered.domain");
>>>>> if ( lookup("location", "sip:$rU at registered.domain") ) {
>>>>> send_reply("302", "Moved Temporarily");
>>>>> exit;
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> I had a look at the path_mode parameter but this looks like it only
>>>>> takes affect for REGISTER methods.
>>>>>
>>>>> The INVITE that comes in supports the PATH header but I dont see this
>>>>> being passed back. In fact, I'm not entirely sure if the path header
>>>>> is a supported header in the 302 response message. I had a quick
>>>>> google and I cant seem to easily find what headers are suported in
>>>>> the
>>>>> 302 message, and where I need to put the path/recieved information. I
>>>>> presume I can add the recieved info as a parameter to the contact
>>>>> header, but how would i specify the outbound proxy to use, would that
>>>>> be in a route or a path header in the 302 response?
>>>>>
>>>>> I can see that the $du pseudo variable is set with the appropriate
>>>>> outbound path and received information, now I just need to include
>>>>> this information in the 302 response.
>>>>>
>>>>> Any suggestions/comments to assist in how I get this info into the
>>>>> 302
>>>>> message would be greatly appreciated.
>>>>>
>>>>> Thanks in advance.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>>>> list
>>>>> sr-users at lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
More information about the sr-users
mailing list