16 Feb
2018
16 Feb
'18
5:51 p.m.
First, RFCs related to SIP presence are quite confusing sometimes and often
not fully implemented by presence servers and endpoints.
Secondly, dialog presence event for first call has already completed its
life-cycle i.e. It has been terminated by second publish from Asterisk. You
can not change dialog state AFTER it has been terminated. Thus, third
publish is rejected by kamailio. Asterisk is suppose to send third publish
without sip-if-match header since it is new call and thus a new dialog,
completely unrelated to previous call and dialog.
Hope this helps.
On Fri 16. Feb 2018 at 13:40, Cyrille Demaret <cyrille(a)omail.be> wrote:
Hi,
I’m using Kamailio with presence enabled and Asterisk PJSIP and
outbound-publish. My problem is happening when I place 2 consecutive calls
from Asterisk :
When I make a first call Asterisk sent the following:
PUBLISH sip:201@192.168.100.37 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.37:5080
;rport;branch=z9hG4bKPj4f9c19eb-26d8-4bb1-8f00-e69723a61082
From: sip:201@mydomain.com;tag=a560e088-9e8a-49f2-a9b1-4a0ec31340bf
To: sip:201@mydomain.com
Call-ID: 5adcf0a0-f138-44d6-8c56-eaf7c3b3b183
CSeq: 10697 PUBLISH
Event: dialog
Expires: 180
Max-Forwards: 70
User-Agent: Asterisk PBX 14.6.0
Content-Type: application/dialog-info+xml
Content-Length: 247
<?xml version="1.0" encoding="UTF-8"?> early……
Kamailio replies :
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.100.37:5080
;rport=5080;branch=z9hG4bKPj4f9c19eb-26d8-4bb1-8f00-e69723a61082;received=192.168.100.37
From: sip:201@mydomain.com;tag=a560e088-9e8a-49f2-a9b1-4a0ec31340bf
To: sip:201@mydomain.com;tag=b596189c6de9c38f624fd84638f43be6-ff39
Call-ID: 5adcf0a0-f138-44d6-8c56-eaf7c3b3b183
CSeq: 10697 PUBLISH
Expires: 180
SIP-ETag: a.1518775074.19863.16.0
Server: kamailio (5.0.5 (x86_64/linux))
Content-Length: 0
When the call is done, Asterisk sent another PUBLISH telling that the call
if terminated :
PUBLISH sip:201@192.168.100.37 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.37:5080
;rport;branch=z9hG4bKPja93efb01-a518-445e-9e9b-f6f97ab8c752
From: sip:201@mydomain.com;tag=165fb3b2-ec0e-4786-889f-eb194ad456ce
To: sip:201@mydomain.com
Call-ID: 5adcf0a0-f138-44d6-8c56-eaf7c3b3b183
CSeq: 10698 PUBLISH
Event: dialog
SIP-If-Match: a.1518775074.19863.16.0
Expires: 180
Max-Forwards: 70
User-Agent: Asterisk PBX 14.6.0
Content-Type: application/dialog-info+xml
Content-Length: 230
<?xml version="1.0" encoding="UTF-8"?> terminated….
And Kamailio replies :
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.100.37:5080
;rport=5080;branch=z9hG4bKPja93efb01-a518-445e-9e9b-f6f97ab8c752;received=192.168.100.37
From: sip:201@mydomain.com;tag=165fb3b2-ec0e-4786-889f-eb194ad456ce
To: sip:201@mydomain.com;tag=b596189c6de9c38f624fd84638f43be6-48b4
Call-ID: 5adcf0a0-f138-44d6-8c56-eaf7c3b3b183
CSeq: 10698 PUBLISH
Expires: 180
SIP-ETag: a.1518775074.19873.18.1
Server: kamailio (5.0.5 (x86_64/linux))
Content-Length: 0
Here, the SIP ETag is a.1518775074.19873.18.1.
The problem is if I make a new call before the expiration of the previous
SUBSCRIBE, Asterisk reuse this SIP ETag according to the RFC :
PUBLISH sip:201@192.168.100.37 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.37:5080
;rport;branch=z9hG4bKPj9d13bb82-31d9-48db-9672-bd4b6b4f22f0
From: sip:201@mydomain.com;tag=33e6b028-0444-4b3a-8bc2-4a987a291528
To: sip:201@mydomain.com
Call-ID: 5adcf0a0-f138-44d6-8c56-eaf7c3b3b183
CSeq: 10699 PUBLISH
Event: dialog
SIP-If-Match: a.1518775074.19873.18.1
Expires: 180
Max-Forwards: 70
User-Agent: Asterisk PBX 14.6.0
Content-Type: application/dialog-info+xml
Content-Length: 247
<?xml version="1.0" encoding="UTF-8"?> early…
Kamailio refuse it with this error : “Trying to update an already
terminated state. Skipping update.” because the call is considered as
terminated.
The RFC is stating :
When updating previously published event state, PUBLISH requests MUST
contain a single SIP-If-Match header field identifying the specific
event state that the request is refreshing, modifying or removing.
This header field MUST contain a single entity-tag that was returned
by the ESC in the SIP-ETag header field of the response to a previous
publication.
Why Kamailio is acting like that?
Best regards,
Cyrille
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users