Question/proposal: REFER method and/or making arbitrary in-dialog requests

[adamchol]

Hi, please let me know what would be a good PR idea from here.

I'm trying to make a custom in-dialog transaction, which in my case is a REFER request. I'm not sure if it's even possible to make such transaction right now. I have to manually construct the request using exposed info about the dialog (just like in bye function) and then pass it to Transaction::new_client, which is fine I guess but not everything is available. To be precise, the CSeq number is not available to me and it's needed for any in-dialog request.

I think it would be a good idea to make a function like Dialog::in_dialog_request that would either take some custom properties of the request like a method and then construct it with dialog's call id, to tags, cseq, etc. or even start a new in-dialog client transaction.

This is actually all available in DialogInner but that's not exactly exposed, right?

For my specific case, we could also make a refer function on dialog just like we have bye or info. That would also require to implement subscriptions/event notifications if we want full REFER support. The implicit subscription can be disabled with a header, which I would do in my case, but what I'm saying is that if we want to have a whole separate refer function, perhaps we would also want full support.

Let me know what do you think I should do here!

[yeoleobun]

We don't support the REFER method yet, so a PR would be very welcome! Here are a few clarifications on the current architecture:

1. Handling In-Dialog Requests

For requests sent within an established dialog, you can use the DialogInner methods:

• When you call make_request on DialogInner with cseq: None, it automatically triggers increment_local_seq. This handles the local sequence increment and populates the Call-ID, From, and To headers (including tags) for you.
• Instead of manually constructing a Transaction, use do_request in DialogInner. This helper manages the transaction and waits for the response.
• Take a look at ClientDialog::bye to see a example of this flow.

2. Handling Event Notifications

To handle incoming NOTIFY requests, you can follow the pattern used by handle_bye. Here is the general architecture:

1. When creating a Client or Server Invite, you can pass a state_sender.
2. When polling incoming_transactions from the endpoint, the user code (not the library itself) should call handle on the matching dialog. You can see an example of this in examples/client/main.rs under the process_incoming_request function.
3. Like handle_bye, it call the transition of DialogInner and send DialogState through the sender mentioned in Step 1.
4. So you can get the state from the state_receiver paired with the state_sender

Note: While DialogState::Notify already exists, but handle_notify is not yet implemented.

---

Please let me know if this is enough or not for your scenario.

[shenjinti]

Thanks.

I have refactored the code to support custom in-dialog requests, including REFER.
For REFER,also added a dedicated refer function on the dialog, similar to bye and info.

[adamchol]

Sorry for not responding. I ended up making some small changes in our fork and didn't make a PR becuase we actually need very little functionalities from REFER. Before I got myself some time to work on full PR here you just did it already including subscriptions - great stuff guys! I like how quickly this library is moving. Thanks!

Out of curiosity - do you guys use LLMs/vibe-code a lot?

Also, are you at all are interested in maintaining a library similar to rsip or a fork of it? There are some small potential improvements to be made there and also corrections! For example, for REFER method we must wait for a 202 Accepted response instead of a standard 200 OK. Unfortunately, in rsip Accepted status code is marked as 201 instead of 202 lol. We have a fork now for this where we also derive Hash trait on Uri type which is useful in many cases.

Let me know please!

[shenjinti]

Hi,
Yes, we use vibe-coding extensively and it's a core part of our development workflow.

The rsip crate has not been updated in four years; I'm sorry I previously chose not to continue relying on it.
We plan to remove the rsip dependency in Q1 2026 by:

• Vendoring the rsip code into out codebase, including fixes from outstanding PRs and issues.
• Renaming the rsip namespace to rsipstack

This is a short roadmap for rsip -- is that right ?
Thanks.

[adamchol]

Yeah that's cool. That'd be great, thanks