[SR-Users] PUBLISH and ETag

[M S]

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 at 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 at 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 at mydomain.com;tag=a560e088-9e8a-49f2-a9b1-4a0ec31340bf
>
> To: sip:201 at 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 at mydomain.com;tag=a560e088-9e8a-49f2-a9b1-4a0ec31340bf
>
> To: sip:201 at 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 at 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 at mydomain.com;tag=165fb3b2-ec0e-4786-889f-eb194ad456ce
>
> To: sip:201 at 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 at mydomain.com;tag=165fb3b2-ec0e-4786-889f-eb194ad456ce
>
> To: sip:201 at 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 at 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 at mydomain.com;tag=33e6b028-0444-4b3a-8bc2-4a987a291528
>
> To: sip:201 at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180216/20f7d811/attachment.html>