Hope to add the stream_id attribute in the on_publish callback interface.

[stormbirds]

Based on the current development version, during the process of implementing the SIP signaling server myself, I need to obtain stream information after the invitation to pull the stream. However, the current on_publish callback only provides app and stream, without stream_id. In this case, I need to first obtain the stream list through the http_api's api/v1/streams interface, and then filter out the specific stream information based on app and stream. I think it would be more appropriate to return the stream_id in the on_publish callback and save it on the business side. This way, the corresponding stream information can be directly obtained based on the stream_id.

TRANS_BY_GPT3

[winlinvip]

Welcome to submit a patch.'
Make sure to maintain the markdown structure.

TRANS_BY_GPT3

[jinleileiking]

cid pubtime也有用' translates to 'cid pubtime is also useful' in English.

TRANS_BY_GPT3

[winlinvip]

Please provide a detailed explanation of the specific application scenarios, instead of just giving a conclusion. Do not add any unnecessary information unless it is necessary.

TRANS_BY_GPT3

[jinleileiking]

@jinleileiking Please provide a detailed explanation of the application scenario, instead of just giving a conclusion. Do not include any unnecessary information unless it is necessary.

When there is a flash break, for example, when stream1 stops and stream2 starts, there is a rather troublesome case in distributed systems. That is, when sending callbacks or triggering transcoding tasks, these two events may be out of order. My experience is to use CID and pubtime for disorder handling. In the case of network jitter, these four messages (stream1 start, stop, stream2 start, stop) can sometimes be disordered, in extreme cases.

TRANS_BY_GPT3

[winlinvip]

Thank you, described very clearly. 👍

TRANS_BY_GPT3

[drchzy]

Curve-saving law: Use the client_id in the callback information to query the clients interface => can obtain the stream_id.

TRANS_BY_GPT3

[28269890]

Not bad, not bad, I support it. My application scenario also needs this functionality.

Actual application situation: In the list, you can see the information of the stream currently being pushed, and you can also verify the running status of the stream.

To implement this application scenario, it is necessary to directly obtain the information of the stream. However, currently, the data submitted from the hook cannot be directly obtained from the API.

---

The ultimate goal is to be able to directly obtain the relevant information of the stream through the API, such as modifying the API, for example, api/v1/vhost/app/stream.

TRANS_BY_GPT3

[winlinvip]

There is a way to bypass it, the callback will provide the client_id, for example:

        #       {
        #           "action": "on_publish",
        #           "client_id":"1y83d208",
        #           "ip": "192.168.1.10", "vhost": "video.test.com", "app": "live",
        #           "stream": "livestream", "param":"?token=xxx&salt=yyy", "server_id": "vid-werty"
        #       }

Then, by querying this client, you can obtain the stream_id:

http://localhost:1985/api/v1/clients/1y83d208

{
  "code": 0,
  "server": "srs-ie193id",
  "client": {
    "id": "1y83d208",
    "vhost": "vid-pg0862j",
    "stream": "vid-538tx0p",
    "ip": "127.0.0.1"
  }
}

Then, using vid-538tx0p, you can retrieve the information of the stream.

TRANS_BY_GPT3