Hello,
I tried the 302 redirect now in 2 different methods:
$ru = "sip:06912345...@yy.yyy.yyy.163:5062"; # rewite complete
contact address
rewritehostport("yy.yyy.yyy.163:5062"); # rewite host
and port
and then
sl_send_reply("302", "redirected");
In all cases OpenSIPS sends back a 302 message with the new contact
information yy.yyy.yyy.163.
The originating UA then takes the contact information into consideration
in the TO: header, however it still sends the message to the previous IP
yy.yyy.yyy.165 (OpenSIPS again) instead of 163 (Freeswitch).
I tried this with 2 SIP clients, they both behave the same.
What am I doing wrong?
Best regards
Peter
Log:
U 21x.xx.xx.189:3072 -> yy.yyy.yyy.165:5060
INVITE sip:06912345...@my.domain.de;user=phone SIP/2.0.
Via: SIP/2.0/UDP 21x.xx.xx.189:3072;branch=z9hG4bK-idw0po3hlbg0;rport.
From: "0691234568" <sip:0691234...@my.domain.de>;tag=cel72sxvyb.
To: <sip:06912345...@my.domain.de;user=phone>.
Call-ID: 3c2f57565d8d-8yv4cbrq6v5b.
CSeq: 1 INVITE.
Max-Forwards: 70.
Contact: <sip:0691234...@21x.xx.xx.189:3072;line=6iffymii>;reg-id=1.
P-Key-Flags: keys="3".
User-Agent: snom320/7.3.23.
Accept: application/sdp.
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO.
Allow-Events: talk, hold, refer, call-info.
Supported: timer, 100rel, replaces, from-change.
Session-Expires: 3600;refresher=uas.
Min-SE: 90.
Content-Type: application/sdp.
Content-Length: 438.
.
v=0.
o=root 129069374 129069374 IN IP4 21x.xx.xx.189.
s=call.
c=IN IP4 21x.xx.xx.189.
t=0 0.
m=audio 12656 RTP/AVP 8 0 9 3 18 4 101.
a=rtpmap:8 pcma/8000.
a=rtpmap:0 pcmu/8000.
a=rtpmap:9 g722/8000.
a=rtpmap:3 gsm/8000.
a=rtpmap:18 g729/8000.
a=rtpmap:4 g723/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=alt:1 1.0 : user 9kksj== 21x.xx.xx.189 12656.
a=alt:2 0.9 : user 9kksj== 192.168.178.50 12656.
a=sendrecv.
#
U yy.yyy.yyy.165:5060 -> 21x.xx.xx.189:3072
SIP/2.0 302 redirected.
Via: SIP/2.0/UDP 21x.xx.xx.189:3072;branch=z9hG4bK-idw0po3hlbg0;rport=3072.
From: "0691234568" <sip:0691234...@my.domain.de>;tag=cel72sxvyb.
To:
<sip:06912345...@my.domain.de;user=phone>;tag=6cdcba1e6882dd91c9dc4f84b97dd379.39cc.
Call-ID: 3c2f57565d8d-8yv4cbrq6v5b.
CSeq: 1 INVITE.
Contact: sip:06912345...@yy.yyy.yyy.163:5062.
Server: OpenSIPS (1.5.3-notls (x86_64/linux)).
Content-Length: 0.
.
#
U 21x.xx.xx.189:3072 -> yy.yyy.yyy.165:5060
ACK sip:06912345...@my.domain.de;user=phone SIP/2.0.
Via: SIP/2.0/UDP 21x.xx.xx.189:3072;branch=z9hG4bK-idw0po3hlbg0;rport.
From: "0691234568" <sip:0691234...@my.domain.de>;tag=cel72sxvyb.
To:
<sip:06912345...@my.domain.de;user=phone>;tag=6cdcba1e6882dd91c9dc4f84b97dd379.39cc.
Call-ID: 3c2f57565d8d-8yv4cbrq6v5b.
CSeq: 1 ACK.
Max-Forwards: 70.
Contact: <sip:0691234...@21x.xx.xx.189:3072;line=6iffymii>;reg-id=1.
Content-Length: 0.
.
#
U 21x.xx.xx.189:3072 -> yy.yyy.yyy.165:5060
INVITE sip:06912345...@yy.yyy.yyy.163:5062 SIP/2.0.
Via: SIP/2.0/UDP 21x.xx.xx.189:3072;branch=z9hG4bK-xeu8ee8qazdw;rport.
From: "0691234568" <sip:0691234...@my.domain.de>;tag=do1om35a01.
To: sip:06912345...@yy.yyy.yyy.163:5062.
Call-ID: 3c2f5756b590-r2mmsx66il1v.
CSeq: 1 INVITE.
Max-Forwards: 70.
Contact: <sip:0691234...@21x.xx.xx.189:3072;line=6iffymii>;reg-id=1.
P-Key-Flags: keys="3".
User-Agent: snom320/7.3.23.
Accept: application/sdp.
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO.
Allow-Events: talk, hold, refer, call-info.
Supported: timer, 100rel, replaces, from-change.
Session-Expires: 3600;refresher=uas.
Min-SE: 90.
Content-Type: application/sdp.
Content-Length: 438.
.
v=0.
o=root 129069374 129069375 IN IP4 21x.xx.xx.189.
s=call.
c=IN IP4 21x.xx.xx.189.
t=0 0.
m=audio 12656 RTP/AVP 8 0 9 3 18 4 101.
a=rtpmap:8 pcma/8000.
a=rtpmap:0 pcmu/8000.
a=rtpmap:9 g722/8000.
a=rtpmap:3 gsm/8000.
a=rtpmap:18 g729/8000.
a=rtpmap:4 g723/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
a=alt:1 1.0 : user 9kksj== 21x.xx.xx.189 12656.
a=alt:2 0.9 : user 9kksj== 192.168.178.50 12656.
a=sendrecv.
Bogdan-Andrei Iancu schrieb:
> Hi Peter,
>
> Interesting - the LB was not designed to work via 3xx redirect model,
> even so, with some changes, it is possible to do it.
>
> On the other side, can you trick FS to look for the IP (used for ACLs)
> somewhere else than the net level (src IP) ? maybe you can configure LB
> to put the original SRC IP into a SIP header into the request.
>
> Regards,
> Bogdan
>
> Peter P GMX wrote:
>
>> Hello,
>>
>> I am using OpenSIPS as a load balancer in front of Freeswitch by using
>> the load balancer module.
>> Scenario: All phones are registered at Freeswitch. Some gateways provide
>> calls via registered accounts and some external gateways are accepted
>> by their IPs (access control list, ACL).
>>
>> When using OpenSIPS in front of Freeswitch I am losing the ACL feature
>> for some external gateways, as from Freeswitch's perpective all calls
>> are now coming from OpenSIPS.
>>
>> Does anybody know how to solve this ACL problem? Is there a way load
>> balance by redirecting invites (302 Moved temporarily) to Freeswitch?
>> Then the gateway will contact Freeswitch directly and ACLs will still apply.
>> So is there any load balancing feature in OpenSIPS which uses redirects
>> or do I have to implement it by myself? E.g. by a perl script which
>> changes the redirect IP on every request (e.g. round robin).
>>
>> Best regards
>> Peter
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
>
> _______________________________________________
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
