[AVTCORE] Re: BUNDLE question - relationship to PR-Answer?

[Roman Shpount <[e-mail]>]

Paul,

I think I can provide some context here. WebRTC acts similarly to a
physical SIP UA when placing a call. When multiple parallel dialogs are
created for a single outbound call, it is hard to represent this to the
user. At the same time, if you get several dialogs that occur one after the
other, it should be possible for a normal SIP UA to handle this gracefully,
discard the dialog created by the previous provisional answer, and re-run
the offer/answer for the new dialog, and present the user with what appears
to be a single call.

So, in case Harald is asking about, the case

Offer: BUNDLE(a, b)
PR-Answer: BUNDLE(a, b)
Answer: No bundle

should be handled the same as

Offer: BUNDLE(a, b)
Answer: No bundle

The use case is that the call connects to a user's phone and establishes an
early media session with bundle to play ringback. The call to the end user
device times out, and the call is connected to an answering service that
does not support bundle to record the message.

Best regards,
_____________
Roman Shpount


On Tue, Apr 21, 2026 at 10:48 PM Paul Kyzivat <pkyzivat=
[e-mail]> wrote:

> Hi Jonathan!
>
> On 4/21/26 5:02 PM, Jonathan Lennox wrote:
> >
> >>> The question is whether, if we get
> >>> Offer: BUNDLE(a, b)
> >>> PR-Answer: BUNDLE(a, b)
> >>> Answer: No bundle
> >>
> >> I'm not familiar with the term "PR-Answer". I presume this comes from
> >> webrtc rather than sip. I'm thinking the sip-analog to this would be a
> >> reliable provisional response containing an answer. An exchange like
> >> that is probably an invalid use of offer/answer in sip. Specifically,
> >> once an answer is returned in a reliable provisional response to an
> >> offer in an INVITE it must remain unchanged in subsequent responses to
> >> that INVITE. (See section 2.2 of RFC 6337.)
> >>
> >> It would be helpful to see more detail - the message bodies from the
> >> exchange.
> >
> > See https://datatracker.ietf.org/doc/html/rfc8829#section-4.1.10
> > <https://datatracker.ietf.org/doc/html/rfc8829#section-4.1.10> for a
> > definition of a WebRTC provisional answer.
> >
> > In particular, it’s notable that one of the use cases described there is
> > the “serial forking” case, i.e. cases where in SIP various provisional
> > answers would have arrived on different dialogs.
> >
> > As such, I think for WebRTC there can't be any constraints imposed on
> > what’s in the pr-answer vs. what’s in the final answer (or in a
> > subsequent pr-answer), because they might be coming from entirely
> > separate peers, and that’s an intended use case.
>
> That is also a possibility in sip. In the case of forking, each fork
> establishes a separate provisional dialog, and all the offer/answer
> rules are applied separately in each. My prior comment assumed a single
> dialog.
>
> More details would help sort it out. But it sounds like Harold is
> talking about a hypothetical case for which there is no more dialog.
>
>         Thanks,
>         Paul
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> To unsubscribe send an email to [e-mail]
>