PJSIP outbound-publish and ETag

Asterisk Asterisk SIP
1

Hi,

I’m trying to use outbound-publish with kamailio. I have some hints configured in Asterisk and Asterisk is sending PUBLISH to Kamailio without any problem. My problem is that Asterisk is reusing a SIP-ETag that’s considered a terminated in Kamailio if I make a second call.

Example when I make a first call :

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

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 which is supposed to be terminated :

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 : “Trying to update an already terminated state. Skipping update.” because the call is considered as terminated.

Is it a normal behaviour on the Asterisk side? Isn’t it supposed to send a PUBLISH without SIP-If-Match since it’s a new call ?

Best regards,

Cyrille

2

I don’t know why Kamailio is refusing it but the RFC states:

   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.

Which is exactly what is happening here. The 200 OK returned that SIP-ETag, we are modifying it, we provide it in SIP-If-Match.

If it’s referring to the dialog-info+xml itself it’s possible, but the same thing we provide to phones is what is provided in the PUBLISH.

3

You’re right, the PUBLISH is not related to the call.

I’ll ask the question on the Kamailio ML.

Thank you.

4

I have checked the RFC 4235 which I think is related to this because my PUBLISH is Event: dialog and you can see there (https://www.rfc-editor.org/rfc/pdfrfc/rfc4235.txt.pdf) on page 9 that the “Terminated” state cannot go back to another state.

Isn’t it correct?

5

Within the context of conveying the state of a dialog yes. Other implementations may have just handled it fine which is why it hasn’t come up before (I think chan_sip conveys dialog-info+xml via NOTIFY the same way as pjsip does). You can file an issue on the issue tracker[1] with the details and reference.

[1] https://issues.asterisk.org/jira