17 Oct
2016
17 Oct
'16
1:22 p.m.
Hello everybody,
I am having issues with one SIP vendor.
I have a Kamailio in bridge mode (private IP / Public IP) and some Asterisk
and Media Gateways.
Calls get established and I have two way audio but when the remote party
hangs up the call, the BYE arrives to the Kamailio and does not move
forward.
I think the problem is SIP vendor rewrite the BYE header and change the
asterisk IP with the public IP of the kamailio.
The IP that appears in the header of the BYE have to be the same that
appears in the contact (UAC that send the call, in my case the Asterisk).
Vendor should not change that IP. ¿Am I correct?
Thank you
-----------------------------------------------------------------------------------------------------
INVITE
----------------------------------------------------------------------------------------------------
2016/10/17 18:50:49.110967 PUBLIC-KAMAILIO-IP:5060 -> VENDOR-IP:6060
INVITE sip:DESTINATION-NUMBER@VENDOR-IP:6060 SIP/2.0
Record-Route:
<sip:PUBLIC-KAMAILIO-IP;r2=on;lr=on;ftag=as5e87b96c;vsf=AAAAAAAAAAAAAAAAAABQUk9fRVYAU0UuODY-;vst=AAAAAAQEAw8MDgsAAHYAcVddXkZWRVVDVl1MMDIudm9pY2U
G9jYWw-;did=09b.9572;nat=yes>
Record-Route:
<sip:PRIVATE-KAMAILIO-IP;r2=on;lr=on;ftag=as5e87b96c;vsf=AAAAAAAAAAAAAAAAAABQUk9fRVYAU0UuODY-;vst=AAAAAAQEAw8MDgsAAHYAcVddXkZWRVVDVl1MMDIudm9pY2U
G9jYWw-;did=09b.9572;nat=yes>
Via: SIP/2.0/UDP
PUBLIC-KAMAILIO-IP;branch=z9hG4bK06a.07540d0e2f32a811ecf9c0a5235dc77a.1
Via: SIP/2.0/UDP
PRIVATE-ASTERISK-IP:5060;received=PRIVATE-ASTERISK-IP;branch=z9hG4bK6bb5a7b3;rport=5060
Max-Forwards: 69
From: "SOURCE-NUMBER" <sip:SOURCE-NUMBER@MY-COMPANY>;tag=as5e87b96c
To: <sip:DESTINATION-NUMBER@VENDOR-IP>
Contact: <sip:SOURCE-NUMBER@PRIVATE-ASTERISK-IP:5060>
Call-ID: 025cc3717ba59faa000cf4db6f8be588@PRIVATE-ASTERISK-IP:5060
CSeq: 102 INVITE
User-Agent: UAC
Date: Mon, 17 Oct 2016 16:53:35 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 269
v=0
o=root 292850421 292850421 IN IP4 PUBLIC-KAMAILIO-IP
s=Asterisk PBX
c=IN IP4 PUBLIC-KAMAILIO-IP
t=0 0
m=audio 23456 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=nortpproxy:yes
-----------------------------------------------------------------------------------------------------
BYE
-----------------------------------------------------------------------------------------------------
2016/10/17 18:50:58.241666 VENDOR-IP:6060 -> PUBLIC-KAMAILIO-IP:5060
BYE sip:SOURCE-NUMBER@PUBLIC-KAMAILIO-IP:5060 SIP/2.0
Via: SIP/2.0/UDP VENDOR-IP:6060;branch=z9hG4bKeff4.48943e76.0
Via: SIP/2.0/UDP
VENDOR-IP:5060;branch=z9hG4bK1d4e605e4ll19f74fBYE421ce8658050206
Max-Forwards: 34
Route:
<sip:PUBLIC-KAMAILIO-IP;lr;r2=on;ftag=as5e87b96c;vsf=AAAAAAAAAAAAAAAAAABQUk9fRVYAU0UuODY-;vst=AAAAAAQEAw8MDgsAAHYAcVddXkZWRVVDVl1>
Route:
<sip:PRIVATE-KAMAILIO-IP;lr;r2=on;ftag=as5e87b96c;vsf=AAAAAAAAAAAAAAAAAABQUk9fRVYAU0UuODY-;vst=AAAAAAQEAw8MDgsAAHYAcVddXkZWRVVDVl1>
To: "SOURCE-NUMBER"<sip:SOURCE-NUMBER@YO>;tag=as5e87b96c
From: <sip:DESTINATION-NUMBER@PUBLIC-KAMAILIO-IP>;tag=421ce86-co1547-INS001
Call-ID: 025cc3717ba59faa000cf4db6f8be588@PRIVATE-ASTERISK-IP:5060
CSeq: 154701 BYE
User-Agent: VENDOR
Content-Length: 0
-----------------------------------------------------------------------------------------------------
17 Oct
17 Oct
2:36 p.m.
Nelson,
You are very correct. The request URI of the BYE (and all other
in-dialog requests, such as reinvites) should equal the Contact URI of
the party to which it is being sent, and this should not change even if
the in-dialog request is being sent through Kamailio because of
Record-Route.
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
18 Oct
18 Oct
3:18 a.m.
It sounds like the vendor is handling NAT traversal on their side. They will be assuming
that Asterisk is behind NAT, because of the presence of private IP addresses –
particularly in the contact, and will be rewriting various parts.
They may be able to disable this for you – otherwise you’ll need to rewrite the headers
yourself.
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Nelson
Migliaro
Sent: 17 October 2016 18:23
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.sip-router.org>
Subject: [SR-Users] BYE issue
Hello everybody,
I am having issues with one SIP vendor.
I have a Kamailio in bridge mode (private IP / Public IP) and some Asterisk and Media
Gateways.
Calls get established and I have two way audio but when the remote party hangs up the
call, the BYE arrives to the Kamailio and does not move forward.
I think the problem is SIP vendor rewrite the BYE header and change the asterisk IP with
the public IP of the kamailio.
The IP that appears in the header of the BYE have to be the same that appears in the
contact (UAC that send the call, in my case the Asterisk). Vendor should not change that
IP. ¿Am I correct?
Thank you
-----------------------------------------------------------------------------------------------------
INVITE
----------------------------------------------------------------------------------------------------
2016/10/17 18:50:49.110967 PUBLIC-KAMAILIO-IP:5060 -> VENDOR-IP:6060
INVITE sip:DESTINATION-NUMBER@VENDOR-IP:6060 SIP/2.0
Record-Route:
<sip:PUBLIC-KAMAILIO-IP;r2=on;lr=on;ftag=as5e87b96c;vsf=AAAAAAAAAAAAAAAAAABQUk9fRVYAU0UuODY-;vst=AAAAAAQEAw8MDgsAAHYAcVddXkZWRVVDVl1MMDIudm9pY2U
G9jYWw-;did=09b.9572;nat=yes>
Record-Route:
<sip:PRIVATE-KAMAILIO-IP;r2=on;lr=on;ftag=as5e87b96c;vsf=AAAAAAAAAAAAAAAAAABQUk9fRVYAU0UuODY-;vst=AAAAAAQEAw8MDgsAAHYAcVddXkZWRVVDVl1MMDIudm9pY2U
G9jYWw-;did=09b.9572;nat=yes>
Via: SIP/2.0/UDP PUBLIC-KAMAILIO-IP;branch=z9hG4bK06a.07540d0e2f32a811ecf9c0a5235dc77a.1
Via: SIP/2.0/UDP
PRIVATE-ASTERISK-IP:5060;received=PRIVATE-ASTERISK-IP;branch=z9hG4bK6bb5a7b3;rport=5060
Max-Forwards: 69
From: "SOURCE-NUMBER" <sip:SOURCE-NUMBER@MY-COMPANY>;tag=as5e87b96c
To: <sip:DESTINATION-NUMBER@VENDOR-IP>
Contact: <sip:SOURCE-NUMBER@PRIVATE-ASTERISK-IP:5060>
Call-ID: 025cc3717ba59faa000cf4db6f8be588@PRIVATE-ASTERISK-IP:5060
CSeq: 102 INVITE
User-Agent: UAC
Date: Mon, 17 Oct 2016 16:53:35 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH,
MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 269
v=0
o=root 292850421 292850421 IN IP4 PUBLIC-KAMAILIO-IP
s=Asterisk PBX
c=IN IP4 PUBLIC-KAMAILIO-IP
t=0 0
m=audio 23456 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=nortpproxy:yes
-----------------------------------------------------------------------------------------------------
BYE
-----------------------------------------------------------------------------------------------------
2016/10/17 18:50:58.241666 VENDOR-IP:6060 -> PUBLIC-KAMAILIO-IP:5060
BYE sip:SOURCE-NUMBER@PUBLIC-KAMAILIO-IP:5060 SIP/2.0
Via: SIP/2.0/UDP VENDOR-IP:6060;branch=z9hG4bKeff4.48943e76.0
Via: SIP/2.0/UDP VENDOR-IP:5060;branch=z9hG4bK1d4e605e4ll19f74fBYE421ce8658050206
Max-Forwards: 34
Route:
<sip:PUBLIC-KAMAILIO-IP;lr;r2=on;ftag=as5e87b96c;vsf=AAAAAAAAAAAAAAAAAABQUk9fRVYAU0UuODY-;vst=AAAAAAQEAw8MDgsAAHYAcVddXkZWRVVDVl1>
Route:
<sip:PRIVATE-KAMAILIO-IP;lr;r2=on;ftag=as5e87b96c;vsf=AAAAAAAAAAAAAAAAAABQUk9fRVYAU0UuODY-;vst=AAAAAAQEAw8MDgsAAHYAcVddXkZWRVVDVl1>
To: "SOURCE-NUMBER"<sip:SOURCE-NUMBER@YO>;tag=as5e87b96c
From: <sip:DESTINATION-NUMBER@PUBLIC-KAMAILIO-IP>;tag=421ce86-co1547-INS001
Call-ID: 025cc3717ba59faa000cf4db6f8be588@PRIVATE-ASTERISK-IP:5060
CSeq: 154701 BYE
User-Agent: VENDOR
Content-Length: 0
-----------------------------------------------------------------------------------------------------
3:39 a.m.
Handling NAT, perhaps, but not correctly. The RURI doesn't change. But not does it
have to determine where the request is actually sent on the network and transport layers.
-- Alex
--
Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
3:48 a.m.
Is it not just the case that the vendor does not support loose routing?
-----Original Message-----
From: sr-users [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Alex Balashov
Sent: 18 October 2016 08:40
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.sip-router.org>
Subject: Re: [SR-Users] BYE issue
Handling NAT, perhaps, but not correctly. The RURI doesn't change. But not does it
have to determine where the request is actually sent on the network and transport layers.
-- Alex
--
Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
10:27 a.m.
Thank you very much for your support,
When you say: "They may be able to disable this for you – otherwise you’ll
need to rewrite the headers yourself."
How can I rewrite the header if I dont have destination IP?, there are four
Asterisk servers and all of them send calls to the bridged Kamailio and I
dont have Asterisk private IP in the BYE request.
Regards and again thank you,
Nelson.-
2016-10-18 9:18 GMT+02:00 Phil Lavin <phil.lavin(a)cloudcall.com>om>:
It sounds like the vendor is handling NAT traversal on
their side. They
will be assuming that Asterisk is behind NAT, because of the presence of
private IP addresses – particularly in the contact, and will be rewriting
various parts.
They may be able to disable this for you – otherwise you’ll need to
rewrite the headers yourself.
*From:* sr-users [mailto:sr-users-bounces@lists.sip-router.org] *On
Behalf Of *Nelson Migliaro
*Sent:* 17 October 2016 18:23
*To:* Kamailio (SER) - Users Mailing List <sr-users(a)lists.sip-router.org>
*Subject:* [SR-Users] BYE issue
Hello everybody,
I am having issues with one SIP vendor.
I have a Kamailio in bridge mode (private IP / Public IP) and some
Asterisk and Media Gateways.
Calls get established and I have two way audio but when the remote party
hangs up the call, the BYE arrives to the Kamailio and does not move
forward.
I think the problem is SIP vendor rewrite the BYE header and change the
asterisk IP with the public IP of the kamailio.
The IP that appears in the header of the BYE have to be the same that
appears in the contact (UAC that send the call, in my case the Asterisk).
Vendor should not change that IP. ¿Am I correct?
Thank you
------------------------------------------------------------
-----------------------------------------
INVITE
------------------------------------------------------------
----------------------------------------
2016/10/17 18:50:49.110967 PUBLIC-KAMAILIO-IP:5060 -> VENDOR-IP:6060
INVITE sip:DESTINATION-NUMBER@VENDOR-IP:6060 SIP/2.0
Record-Route: <sip:PUBLIC-KAMAILIO-IP;r2=on;lr=on;ftag=as5e87b96c;vsf=
AAAAAAAAAAAAAAAAAABQUk9fRVYAU0UuODY-;vst=AAAAAAQEAw8MDgsAAHYAcVddXkZWRV
VDVl1MMDIudm9pY2U
G9jYWw-;did=09b.9572;nat=yes>
Record-Route: <sip:PRIVATE-KAMAILIO-IP;r2=on;lr=on;ftag=as5e87b96c;vsf=
AAAAAAAAAAAAAAAAAABQUk9fRVYAU0UuODY-;vst=AAAAAAQEAw8MDgsAAHYAcVddXkZWRV
VDVl1MMDIudm9pY2U
G9jYWw-;did=09b.9572;nat=yes>
Via: SIP/2.0/UDP PUBLIC-KAMAILIO-IP;branch=z9hG4bK06a.
07540d0e2f32a811ecf9c0a5235dc77a.1
Via: SIP/2.0/UDP PRIVATE-ASTERISK-IP:5060;received=PRIVATE-ASTERISK-IP;
branch=z9hG4bK6bb5a7b3;rport=5060
Max-Forwards: 69
From: "SOURCE-NUMBER" <sip:SOURCE-NUMBER@MY-COMPANY>;tag=as5e87b96c
To: <sip:DESTINATION-NUMBER@VENDOR-IP>
Contact: <sip:SOURCE-NUMBER@PRIVATE-ASTERISK-IP:5060>
Call-ID: 025cc3717ba59faa000cf4db6f8be588@PRIVATE-ASTERISK-IP:5060
CSeq: 102 INVITE
User-Agent: UAC
Date: Mon, 17 Oct 2016 16:53:35 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 269
v=0
o=root 292850421 292850421 IN IP4 PUBLIC-KAMAILIO-IP
s=Asterisk PBX
c=IN IP4 PUBLIC-KAMAILIO-IP
t=0 0
m=audio 23456 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=nortpproxy:yes
------------------------------------------------------------
-----------------------------------------
BYE
------------------------------------------------------------
-----------------------------------------
2016/10/17 18:50:58.241666 VENDOR-IP:6060 -> PUBLIC-KAMAILIO-IP:5060
BYE sip:SOURCE-NUMBER@PUBLIC-KAMAILIO-IP:5060 SIP/2.0
Via: SIP/2.0/UDP VENDOR-IP:6060;branch=z9hG4bKeff4.48943e76.0
Via: SIP/2.0/UDP VENDOR-IP:5060;branch=z9hG4bK1d4e605e4ll19f74fBYE421
ce8658050206
Max-Forwards: 34
Route: <sip:PUBLIC-KAMAILIO-IP;lr;r2=on;ftag=as5e87b96c;vsf=
AAAAAAAAAAAAAAAAAABQUk9fRVYAU0UuODY-;vst=AAAAAAQEAw8MDgsAAHYAcVddXkZWRV
VDVl1>
Route: <sip:PRIVATE-KAMAILIO-IP;lr;r2=on;ftag=as5e87b96c;vsf=
AAAAAAAAAAAAAAAAAABQUk9fRVYAU0UuODY-;vst=AAAAAAQEAw8MDgsAAHYAcVddXkZWRV
VDVl1>
To: "SOURCE-NUMBER"<sip:SOURCE-NUMBER@YO>;tag=as5e87b96c
From: <sip:DESTINATION-NUMBER@PUBLIC-KAMAILIO-IP>;tag=
421ce86-co1547-INS001
Call-ID: 025cc3717ba59faa000cf4db6f8be588@PRIVATE-ASTERISK-IP:5060
CSeq: 154701 BYE
User-Agent: VENDOR
Content-Length: 0
------------------------------------------------------------
-----------------------------------------
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3043
days inactive
3044
days old
5 comments
3 participants
participants (3)
-
Alex Balashov -
Nelson Migliaro -
Phil Lavin