Re-Subscribe .

[skotow]

I think is a bug . The first initial subscription works properly. When I sent expires 60s instate to re-subscribe to the same dialog is just sending expires 0 (which make server to delete record)

And then send a new Subscribe as it is a different Subscribe.

Any solution for this ?

Or how is lib handle re-subscribe ?

[slavikbialik]

I didn't experience something like this. Can you share the logs of SIP.js with all the SIP messages involved from the initial SUBSCRIBE?

[skotow]

Hi, please let me know where I can sent you logs .

[dovi5988]

@skotow Try creating a HAR file of the traffic that goes over the web socket. See https://developer.chrome.com/blog/new-in-devtools-76/#websocket

[dovi5988]

@slavikbialik I am working with Nazar on this issue. I believe the problem is this.

1. A SUBSCRIBE is sent all goes well. In the initial transactions the WebSocket server adds a RR to the packet.
2. From what I understand as per the RFC if you get as RR in a response (e.g. in the 200 OK) on the next transaction (e.g. when the phone re-subscribes) the client (SIPjs) should add those RR's to the re-subscibe. Because it does not when the server sends it's NOTIFY it tries to send id directly to the clients browser bypassing the WebRTC server. (The call flow is Web Browser -> WebRTC (RTC2SIp Proxy( -> OpenSipS -> Asterisk. I assume that because the web browser did not get the NOTIFY it sent a SUBSCRIBE for 0 seconds to remove the subscription and then created a new one.

As of now we modified our WebRTC to Sip Proxy so that it auto adds the RR to all re-subscribes which cause the NOTIFY's to be sent correctly however I would rather put in fixes that have the potential to hurt other UA's that are following the rules.

[skotow]

@slavikbialik any update on @dovi5988 post ?