Re: [SR-Users] ACK sent to wrong socket IP in mhomed scenario

2013-12-12 Thread Ronald Voermans
Daniel,

Thank you for your answer. Configured the following (with mhomed=yes):

if ($(route_uri{uri.host}) == VIP_PROXY) {
force_send_socket(VIP_PROXY);
} else if ($(route_uri{uri.host}) == VIP_PROXY_PUB) {
force_send_socket(VIP_PROXY_PUB);
} else if ($(route_uri{uri.host}) == THIS_PROXY) {
force_send_socket(THIS_PROXY);
} else if ($(route_uri{uri.host}) == THIS_PROXY_PUB) {
force_send_socket(THIS_PROXY_PUB);
}
  t_relay();
...

This solves the issue when using the VIP_PROXY(_PUB). However, the ACK always 
has two route headers when using the THIS_PROXY as ip address. In this case, 
the top route header is VIP_PROXY; the second one is THIS_PROXY. Hence, the 
solution above doesn't work, because the force_send_socket uses the top route 
header (which is VIP_PROXY).

Why is this different behavior when compared to mhomed=no?

Thanks,

Ronald
Dear list,

I'm having an issue with our Kamailio setup.

I've installed two Kamailio servers with Corosync/Pacemaker. Kamailio1 has ip 
10.254.254.5, Kamailio2 has ip 10.254.254.23. The VIP is 10.254.254.1. All is 
working well; clients can sent request to the VIP, and all traffic is sent via 
10.254.254.1, and not the real ipI've configured the listen addressess:

mhomed = no
listen = udp:10.254.254.1:5060
listen = udp:10.254.254.23:5060

I'm now trying to configure the server as a multihomed one. Both Kamailio have 
two NIC's. Kamailio1 also has ip X1, Kamailio2 has ip X2. The VIP is Y. 
Configuration is done as:

mhomed = yes
listen = udp:10.254.254.1:5060
listen = udp:10.254.254.23:5060
listen = udp:Y:5060
listen = udp:X1:5060

When a UA sends an INVITE to for example 10.254.254.1, all responses (back) to 
UA are being sent with source address 10.254.254.1 (VIP), except for the ACK 
(and BYE). The ACK is sent via the real ip 10.254.254.23. I can resolve this by 
issuing a force_send_socket before t_relay in the config; but since it's 
multihomed, I have to build a lot of checks to find out the outgoing socket. 
Besides that, I want it to be possible to use both the real IP and the VIP as 
IP-address for the UA (for testing purposes). This won't work with 
force_send_socket.

Does anyone from the list know how I can solve this?

Thanks,

Regards,

Ronald

___
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


Re: [SR-Users] uac_replace_from / New URI shorter than old URI

2013-02-26 Thread Ronald Voermans

Hi Daniel,

Thanks for your update. No, I'm only changing the from header. The to-header 
URI is not touched. The R-URI is however (there's a prefix added). When the ACK 
is being sent, syslog adds a message 'New URI shorter then old URI'.

Regards,

Ronald

Op 26 feb. 2013, om 11:02 heeft Daniel-Constantin Mierla 
mico...@gmail.commailto:mico...@gmail.com het volgende geschreven:

Hello,

the problem here seems to be the update of To header. Are you changing the To 
URI as well? I don't see the parameter for it in the Route header.

From URI handling seems to be ok.

Cheers,
Daniel

On 2/21/13 11:12 PM, Ronald Voermans wrote:

Responding to myself: attached is an ngrep (made by homer/sipcature server). 
Some strange things are happening. When I do a ngrep on the Kamailio, I see the 
ACK gets mangled:

SIP UA - Kamalio
ACK sip:08000403@10.254.254.20:5060 SIP/2.0.
Via: SIP/2.0/UDP 
192.168.1.10:56953;branch=z9hG4bK-d8754z-170b73a13fd7a39d-1---d8754z-.
Max-Forwards: 70.
Route: 
sip:10.254.254.1;lr;ftag=868b7d56;nat=yes;vsf=czFwOkQpYzVueyNnLEMbCDY6fyo/ejIqLXoQM2IvdwpSA14CTmo8PmQ-sip:10.254.254.1;lr;ftag=868b7d56;nat=yes;vsf=czFwOkQpYzVueyNnLEMbCDY6fyo/ejIqLXoQM2IvdwpSA14CTmo8PmQ-.
Contact: 
sip:r.voermans@192.168.1.10:56953;transport=UDPsip:r.voermans@192.168.1.10:56953;transport=UDP.
To: 
sip:08000403@10.254.254.1;transport=UDPsip:08000403@10.254.254.1;transport=UDP;tag=a94c095b773be1dd6e8d668a785a9c84dac9696f.
From: 
testcalleridsip:r.voermans@10.254.254.1;transport=UDPsip:r.voermans@10.254.254.1;transport=UDP;tag=868b7d56.
Call-ID: YWYwY2M0MTcwM2VmMTUxMTdkMTUwNDFhM2E2NjI3MTg..
CSeq: 2 ACK.
Proxy-Authorization: Digest 
username=r.voermans,realm=10.254.254.1,nonce=USabJ1EmmfuYD+XnJVMqKQkK6/VmiXJ8,uri=sip:08000403@10.254.254.1;transport=UDPsip:08000403@10.254.254.1;transport=UDP,response=25e0d8980c67d1785948a44de4e51b44,algorithm=MD5.
User-Agent: Zoiper Communicator 2.04.10164 rev.10204.
Content-Length: 0.
.


Kamailio - SIP UA
U 2013/02/21 23:04:52.911391 10.254.254.1:5060 - 10.254.254.20:5060
ACK sip:08000403@10.254.254.20:5060 SIP/2.0.
Record-Route: 
sip:10.254.254.1;lr;ftag=868b7d56;nat=yessip:10.254.254.1;lr;ftag=868b7d56;nat=yes.
Via: SIP/2.0/UDP 10.254.254.1;branch=z9hG4bKcydzigwkX.
Via: SIP/2.0/UDP 
192.168.1.10:56953;rport=56953;branch=z9hG4bK-d8754z-170b73a13fd7a39d-1---d8754z-.
Max-Forwards: 69.
Contact: 
sip:r.voermans@192.168.1.10:56953;transport=UDPsip:r.voermans@192.168.1.10:56953;transport=UDP.
To: 
sip:#x)1,+2']..qmu.vinu5l{3(yuvO!y.DPsip:#x)1,+2']..qmu.vinu5l{3(yuvO!y.DP;tag=a94c095b773be1dd6e8d668a785a9c84dac9696f.
From: 
testcalleridsip:anonymous@anonymous.invalidsip:anonymous@anonymous.invalid;tag=868b7d56.
Call-ID: YWYwY2M0MTcwM2VmMTUxMTdkMTUwNDFhM2E2NjI3MTg..
CSeq: 2 ACK.
User-Agent: Zoiper Communicator 2.04.10164 rev.10204.
Content-Length: 0.
.

restore_mode modparam is set to 'auto', and I checked that the vsf in 
Route-headers are correct. Any clues?

Regards,
Ronald



Op 21 feb. 2013, om 16:49 heeft Ronald Voermans 
r.voerm...@global-datacenter.nlmailto:r.voerm...@global-datacenter.nlmailto:r.voerm...@global-datacenter.nlmailto:r.voerm...@global-datacenter.nl
 het volgende geschreven:


Hi,


this last weekend we went live from the old 3.0 version to the latest stable 
release of Kamailio (3,3,0). All went well, except for one issue. We make use 
of uac_replace_from in our config, in case a client needs CLIR: 
uac_replace_from(Anonymous,sip:anonymous@anonymous.invalidsip:anonymous@anonymous.invalid);

Since the upgrade we receive the following error:

uac [replace.c:521]: new URI shorter than old URI

Which causes the call to be disconnected after about 20/30 seconds. This, 
because the ACK is received by Kamailio, but cannot be 'linked' to the 
transaction i guess.

What is exactly causing this issue and, more importantly, is there any way to 
resolve this?

Thanks in advance,

Regards,
Ronald Voermans

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users





___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



--
Daniel-Constantin Mierla - http://www.asipto.comhttp://www.asipto.com/
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
 - http://conference.kamailio.comhttp://conference.kamailio.com/ -

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] uac_replace_from / New URI shorter than old URI

2013-02-21 Thread Ronald Voermans

Hi,


this last weekend we went live from the old 3.0 version to the latest stable 
release of Kamailio (3,3,0). All went well, except for one issue. We make use 
of uac_replace_from in our config, in case a client needs CLIR: 
uac_replace_from(Anonymous,sip:anonymous@anonymous.invalid);

Since the upgrade we receive the following error:

uac [replace.c:521]: new URI shorter than old URI

Which causes the call to be disconnected after about 20/30 seconds. This, 
because the ACK is received by Kamailio, but cannot be 'linked' to the 
transaction i guess.

What is exactly causing this issue and, more importantly, is there any way to 
resolve this?

Thanks in advance,

Regards,
Ronald Voermans

___
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


Re: [SR-Users] uac_replace_from / New URI shorter than old URI

2013-02-21 Thread Ronald Voermans

Responding to myself: attached is an ngrep (made by homer/sipcature server). 
Some strange things are happening. When I do a ngrep on the Kamailio, I see the 
ACK gets mangled:

SIP UA - Kamalio
ACK sip:08000403@10.254.254.20:5060 SIP/2.0.
Via: SIP/2.0/UDP 
192.168.1.10:56953;branch=z9hG4bK-d8754z-170b73a13fd7a39d-1---d8754z-.
Max-Forwards: 70.
Route: 
sip:10.254.254.1;lr;ftag=868b7d56;nat=yes;vsf=czFwOkQpYzVueyNnLEMbCDY6fyo/ejIqLXoQM2IvdwpSA14CTmo8PmQ-.
Contact: sip:r.voermans@192.168.1.10:56953;transport=UDP.
To: 
sip:08000403@10.254.254.1;transport=UDP;tag=a94c095b773be1dd6e8d668a785a9c84dac9696f.
From: testcalleridsip:r.voermans@10.254.254.1;transport=UDP;tag=868b7d56.
Call-ID: YWYwY2M0MTcwM2VmMTUxMTdkMTUwNDFhM2E2NjI3MTg..
CSeq: 2 ACK.
Proxy-Authorization: Digest 
username=r.voermans,realm=10.254.254.1,nonce=USabJ1EmmfuYD+XnJVMqKQkK6/VmiXJ8,uri=sip:08000403@10.254.254.1;transport=UDP,response=25e0d8980c67d1785948a44de4e51b44,algorithm=MD5.
User-Agent: Zoiper Communicator 2.04.10164 rev.10204.
Content-Length: 0.
.


Kamailio - SIP UA
U 2013/02/21 23:04:52.911391 10.254.254.1:5060 - 10.254.254.20:5060
ACK sip:08000403@10.254.254.20:5060 SIP/2.0.
Record-Route: sip:10.254.254.1;lr;ftag=868b7d56;nat=yes.
Via: SIP/2.0/UDP 10.254.254.1;branch=z9hG4bKcydzigwkX.
Via: SIP/2.0/UDP 
192.168.1.10:56953;rport=56953;branch=z9hG4bK-d8754z-170b73a13fd7a39d-1---d8754z-.
Max-Forwards: 69.
Contact: sip:r.voermans@192.168.1.10:56953;transport=UDP.
To: 
sip:#x)1,+2']..qmu.vinu5l{3(yuvO!y.DP;tag=a94c095b773be1dd6e8d668a785a9c84dac9696f.
From: testcalleridsip:anonymous@anonymous.invalid;tag=868b7d56.
Call-ID: YWYwY2M0MTcwM2VmMTUxMTdkMTUwNDFhM2E2NjI3MTg..
CSeq: 2 ACK.
User-Agent: Zoiper Communicator 2.04.10164 rev.10204.
Content-Length: 0.
.

restore_mode modparam is set to 'auto', and I checked that the vsf in 
Route-headers are correct. Any clues?

Regards,
Ronald



Op 21 feb. 2013, om 16:49 heeft Ronald Voermans 
r.voerm...@global-datacenter.nlmailto:r.voerm...@global-datacenter.nl het 
volgende geschreven:


Hi,


this last weekend we went live from the old 3.0 version to the latest stable 
release of Kamailio (3,3,0). All went well, except for one issue. We make use 
of uac_replace_from in our config, in case a client needs CLIR: 
uac_replace_from(Anonymous,sip:anonymous@anonymous.invalid);

Since the upgrade we receive the following error:

uac [replace.c:521]: new URI shorter than old URI

Which causes the call to be disconnected after about 20/30 seconds. This, 
because the ACK is received by Kamailio, but cannot be 'linked' to the 
transaction i guess.

What is exactly causing this issue and, more importantly, is there any way to 
resolve this?

Thanks in advance,

Regards,
Ronald Voermans

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.orgmailto:sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

U 2013/02/21 21:55:33.436906 192.168.1.10:56953 - 10.254.254.1:5060

INVITE sip:08000403@10.254.254.1;transport=UDP SIP/2.0

Via: SIP/2.0/UDP 
192.168.1.10:56953;branch=z9hG4bK-d8754z-6de76e7e5b4b8a20-1---d8754z-

Max-Forwards: 69

Contact: sip:r.voermans@192.168.1.10:56953;transport=UDP

To: sip:08000403@10.254.254.1;transport=UDP

From: testcalleridsip:r.voermans@10.254.254.1;transport=UDP;tag=1c9f8e1e

Call-ID: M2ZhNDllNzNkZmNhNzBjOTg5NGZmODdjNGMwZGZkZjQ.

CSeq: 1 INVITE

Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, 
SUBSCRIBE

Content-Type: application/sdp

Supported: replaces, norefersub, extended-refer, X-cisco-serviceuri

User-Agent: Zoiper Communicator 2.04.10164 rev.10204

Allow-Events: presence, kpml

Content-Length: 230



v=0

o=ZoiperCommunicator_user 0 0 IN IP4 192.168.1.10

s=ZoiperCommunicator_session

c=IN IP4 192.168.1.10

t=0 0

m=audio 8000 RTP/AVP 8 101

a=rtpmap:8 PCMA/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=sendrecv



U 2013/02/21 21:55:33.436999 10.254.254.1:5060 - 192.168.1.10:56953

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 
192.168.1.10:56953;branch=z9hG4bK-d8754z-6de76e7e5b4b8a20-1---d8754z-;rport=56953

To: sip:08000403@10.254.254.1;transport=UDP

From: testcalleridsip:r.voermans@10.254.254.1;transport=UDP;tag=1c9f8e1e

Call-ID: M2ZhNDllNzNkZmNhNzBjOTg5NGZmODdjNGMwZGZkZjQ.

CSeq: 1 INVITE

Server: kamailio (3.3.3 (x86_64/linux))

Content-Length: 0





U 2013/02/21 21:55:33.437050 10.254.254.1:5060 - 192.168.1.10:56953

SIP/2.0 407 Proxy Authentication Required

Via: SIP/2.0/UDP 
192.168.1.10:56953;branch=z9hG4bK-d8754z-6de76e7e5b4b8a20-1---d8754z-;rport=56953

To: 
sip:08000403@10.254.254.1;transport=UDP;tag=f3d9132ccd7454f67ea80bf2bf6bdae6.af7b

From: testcalleridsip:r.voermans@10.254.254.1;transport=UDP;tag=1c9f8e1e

Call-ID: M2ZhNDllNzNkZmNhNzBjOTg5NGZmODdjNGMwZGZkZjQ.

CSeq: 1 INVITE

Proxy-Authenticate: Digest realm=10.254.254.1, 
nonce=USaK8FEmicQNRyuQ84ZPSzcxW6fNxA78

Server: kamailio (3.3.3 (x86_64