[SR-Users] Specifying Upstream and Downstream Servers for a simple SIP proxy
AliReza Khoshgoftar Monfared
khoshgoftar at gmail.com
Mon Jun 23 21:39:57 CEST 2014
Hi,
I have another update.
The problem that I had is fixed now and it is fixed in an unexpected way!
The fix seems to be in changing the SIPp default client scenario. In
specific, once I change the UAC.xml in SIPp trunk to generate the "BYE"
message's "To" field like this:
To: sut <sip:[call_number]@[remote_ip]:[remote_port]>
>
instead of:
To: sut <sip:[call_number]@[remote_ip]:[remote_port]>[peer_tag_param]
The problem is solved and Kamailio proxy forwards BYEs to the server.
I am not sure why this is happening and if it more of a SIPp issue or a
Kamailio issue. Neither I am sure of the meaning of the "[peer_tag_param]"
in SIPp default client, but I thought it might be helpful to document the
issue here in case that somebody else was searching the same issue.
On Thu, Jun 19, 2014 at 8:42 PM, AliReza Khoshgoftar Monfared <
khoshgoftar at gmail.com> wrote:
> Shedding some more light on the situation, here are some further facts I
> could figure out:
>
> 1) I did the same test without the proxy in between (UAC <--> UAS) purely
> in SIPp, everything was fine, no dead call error
>
> 2) With the Kamailio proxy in between, I can see that there is a problem
> in call termination. The client is not receiving any "200 OK" for the
> "BYE"s it is sending.
>
> Is there anything wrong in my routing logic that is preventing these ACKs?
>
>
> On Thu, Jun 19, 2014 at 4:09 PM, AliReza Khoshgoftar Monfared <
> khoshgoftar at gmail.com> wrote:
>
>> Thanks very much Daniel,
>>
>> This is solving a part of my issue for now.
>> Here is the routing section of my configuration file (it may be good to
>> share it once complete as a minimally working proxy):
>>
>>
>> route{
>>> if (!mf_process_maxfwd_header("10")) {
>>> sl_reply("483","Too Many Hops");
>>> break;
>>> }
>>> if (msg:len >= 4096 ) {
>>> sl_reply("513", "Message too big");
>>>
>> }
>>>
>> if (!method=="REGISTER") record_route();
>>>
>> if (!loose_route()) {
>>> $du = "sip:10.236.214.86:5060";
>>> #setdsturi("sip:10.236.214.86:5060"); #second way to do
>>> it
>>> if (!t_relay()) {
>>> sl_reply_error();
>>> }
>>>
>> }
>>> }
>>>
>>
>>>
>>
>> I am trying to set up a kamailio proxy on an EC2 VM using this
>> configurations and have been running a UAC and a UAS using SIPp on two
>> other machines (UAC <--> Kamailio Proxy <--> UAS):
>>
>> UAC
>>
>>> sipp -sn uac -nr -r 1 -rp 1000 -d 0 -l 1 -p 5060 -trace_msg -i
>>> SELF_IP(UAC) -rsa PROXY_IP:5060 UAS_IP:5060
>>>
>>
>> UAS:
>>
>>> sipp -sn uas -d 0 -p 5060 -i SELF_IP(UAS) -rsa PRXY_IP:5060 -trace_msg
>>
>>
>> It looks that messages go through, and are received by the server, but
>> what I get back at the UAC (client) is a "dead call" error:
>>
>> Last Error: Dead call 1-1734 at 10.140.34.188 (aborted at index 8),
>>> receive...
>>>
>>
>> Is there a specific meaning to this "dead call" error? Is there anything
>> that my proxy is missing in its routing or does it have to do with the
>> UAC/UAS configs?
>>
>>
>> Thanks
>> Alireza
>>
>>
>> On Tue, Jun 17, 2014 at 5:11 AM, Daniel-Constantin Mierla <
>> miconda at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> listen is to specify local ip address or network interface on which
>>> kamailio should listen for sip traffic.
>>>
>>> To send to an ip address there are couple of variants, in config file:
>>>
>>> $ru = "sip:" + $rU + "@__NEXT_PROXY_IP__";
>>> t_relay();
>>> exit;
>>>
>>> Or, if you don't want to change the r-uri, then use:
>>>
>>> $du = "sip:__NEXT_PROXY_IP__";
>>> t_relay();
>>> exit;
>>>
>>> Of course, you have to replace the __NEXT_PROXY_IP__ with the
>>> appropriate value.
>>>
>>> More dynamic option would be using dispatcher module.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 15/06/14 15:28, AliReza Khoshgoftar Monfared wrote:
>>>
>>> Dear Kamailio users,
>>>
>>> I am trying to set up a simple scenario as follows:
>>>
>>> UAC --> Proxy_1 --> Proxy_2 --> Proxy_3 --> UAC
>>>
>>> I am new to Kamailio and had the following basic questions that came
>>> to my mind after reading the documentation an the default kamilio.cfg
>>> config script:
>>>
>>> 1) Is there any good example of the above scenario in which the UAC
>>> and UAS (caller and callee) are modeled using SIPp and proxies are simple
>>> kamailio instances run on different machines that simply forward the SIP
>>> packets?
>>>
>>> 2) In specific, I want the proxies to simply forward the messages to
>>> their downstream (I do not care about registration or other operations and
>>> look for a minimally working simple SIP scenario). Is there any example of
>>> such configuration?
>>>
>>> 3) Let's imagine Proxy_2 in the above example, in the default config,
>>> it looks like that with modifying line 164, "listen=udp:10.0.0.10:5060"
>>> I can specify the address of its upstream, Proxy_1, but how and where shall
>>> I set the specifications of the downstream, Proxy_3?
>>>
>>> I suspect it is somewhere in the Routing Logic block (line 449) but
>>> not sure how it is exactly done. I see a "route(SIPOUT)" call for example
>>> but I am not sure how and where the value of SIPOUT is modified. Is it a
>>> representation of the downstream servers in the config file?
>>>
>>>
>>> Thanks,
>>> Alireza
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>> --
>>> Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140623/110627a5/attachment.html>
More information about the sr-users
mailing list