24 Jun
2020
24 Jun
'20
7:31 p.m.
Just to clarify what we are seeing, here is a packet from the INVITE from the S-CSCF
(6060) to the P-CSCF(4060). I have eliminated the S-CSCF as this packet looks correct.
The P-CSCF is not handling the request URI correctly, and simply sends it back to the
I-CSCF where I-CSCF cannot find the user in the HSS based on the ruri updated by the
S-CSCF with the local IP address of the UE (192.168.20.1). The P-CSCF should send this
INVITE to the UE (703222888(a)192.168.20.1)
No. Arrival Time Source Destination Source Port Destination
Port SIP to tag SIP from tag Method Record-Route Userinfo Request-URI Media Port
Protocol Length Request-URI Host Port Owner Username Media Type Media Format Origin-Host
Type slice_type SIP from address User Part SIP from address Host Part SIP to address
User Part SIP to address Host Part Contact URI User Part Contact URI Host Part Request-URI
User Part Request-URI Host Part Request-URI Host Port Info
1553 Jun 17, 2020 09:31:21.722451703 Eastern Daylight Time 192.168.20.128
192.168.20.128 6060 4060
d490a30c-42a8-4fc0-9fe9-b7a21537386d INVITE mt
sip:7032228888@192.168.20.1:63871;transport=udp 10626,13370 SIP/SDP 2263 63871
- audio,video ITU-T G.711
PCMU,DynamicRTP-Type-101,0,101,101,DynamicRTP-Type-99,99,99
7033331111 asterisk.irisims.org 7032228888
ims522.irisims.org asterisk 192.168.20.131 7032228888
192.168.20.1 63871 Request: INVITE
sip:7032228888@192.168.20.1:63871;transport=udp |
Frame 1553: 2263 bytes on wire (18104 bits), 2263 bytes captured (18104 bits) on interface
any, id 0
Linux cooked capture
Internet Protocol Version 4, Src: 192.168.20.128, Dst: 192.168.20.128
User Datagram Protocol, Src Port: 6060, Dst Port: 4060
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:7032228888@192.168.20.1:63871;transport=udp SIP/2.0
Method: INVITE
Request-URI: sip:7032228888@192.168.20.1:63871;transport=udp
Request-URI User Part: 7032228888
Request-URI Host Part: 192.168.20.1
Request-URI Host Port: 63871
[Resent Packet: False]
Message Header
Record-Route:
<sip:mt@192.168.20.128:6060;lr=on;ftag=d490a30c-42a8-4fc0-9fe9-b7a21537386d;did=7d2.e0f1>
Route: <sip:term@pcscf522.irisims.org;lr>
Via: SIP/2.0/UDP
192.168.20.128:6060;branch=z9hG4bK285b.2a57abaad57cfd55bc18a23d4e9cefc8.0
Via: SIP/2.0/UDP
192.168.20.128;branch=z9hG4bK285b.793ba7dcf9fcd18ddef225b83896340e.1
Via: SIP/2.0/UDP
192.168.20.131:5060;received=192.168.20.131;rport=5060;branch=z9hG4bKPjef451437-0a4f-4732-ac54-318740956335
From:
<sip:7033331111@asterisk.irisims.org>;tag=d490a30c-42a8-4fc0-9fe9-b7a21537386d
To: <sip:7032228888@ims522.irisims.org>
Contact: <sip:asterisk@192.168.20.131:5060>
Call-ID: 39c15c42-b0b7-48b5-b4bf-ac7a99fbe660
[Generated Call-ID: 39c15c42-b0b7-48b5-b4bf-ac7a99fbe660]
CSeq: 19314 INVITE
Route: <sip:ims522.irisims.org:5060;lr>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL,
UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 68
User-Agent: Asterisk PBX 16.6.0
Content-Type: application/sdp
Content-Length: 1121
Message Body
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Martin W Woscek
Sent: Wednesday, June 24, 2020 11:21 AM
To: miconda(a)gmail.com; Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] [EXT] Re: Kamailio I-CSCF not sending SIP:200 OK messages to
Asterisk (to tag)
Hi,
The issue is the P should be sending to the UE not back to the I like the failed flow:
Asterisk16-[phone] --->ICSCF--->S-CSCF--->P-CSCF--->I-CSCF ---> [604 HSS
user unknown] to Asterisk16[phone]
The successful call should look like:
Asterisk16-[phone] --->ICSCF--->S-CSCF--->P-CSCF--->Kamailio-[UE]
Does anyone have a example P-cscf scripts including the mt.cfg or other script file that
make this work?
The reverse calls work just fine.
Thanks,
_Martin
From: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>
Sent: Wednesday, June 24, 2020 4:53 AM
To: Kamailio (SER) - Users Mailing List
<sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>>; Martin W
Woscek <mwoscek@mitre.org<mailto:mwoscek@mitre.org>>
Subject: [EXT] Re: [SR-Users] Kamailio I-CSCF not sending SIP:200 OK messages to Asterisk
(to tag)
Hello,
Kamailio is not generating the 200ok for INVITE (calls), it just sends out what it
received from end point, after consuming own Via header (of course, other headers can be
changed based on config rules, but Kamailio is not in charge of setting To-tag).
Cheers,
Daniel
On 19.06.20 21:19, Martin W Woscek wrote:
Hello all,
SIP/UE (boghe or imsdroid) client registered to Kamailio makes call to an Asterisk
registered SIP phone is successful:
[UE]-Kamailio--->INVITE--->Asterisk16-[phone]
[UE]-Kamailio--->200 OK with to_tag--->Asterisk16-[phone]
But in reverse direction for a call, Kamailio does not return the SIP OK so no to_tag is
sent so call fails to ring and complete:
[phone]-Asterisk16 --->INVITE--->Kamailio
Where the UE device never receives the INVITE, Asterisk never gets and 200 OK message with
the to_tag from the I-CSCF, the call flow itself gets lost in Kamailio, where the P-CSCF
sends final INVITE to I-CSCF and and ultimately a 604 HSS user unknown message is sent
back to Asterisk from the I-CSCF.
Basically Im using the default "sample" configs for both the P and the I-CSCF.
Our sauce is in the S-CSCF for out going calls that originate by a registered UE.
Any insight or sample Kamailio configuration that Im lacking?
Has anyone done this and could share the asterisk and Kamailio script snippets that make
it possible.
Thanks,
_Martin
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com>
www.twitter.com/miconda<http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla