comments at end
Mark R. Lindsey wrote:
> Imagine a call from a SIP user to the PSTN via a B2BUA.
>
> The call may first be sent from the B2BUA to the PSTN gateway, and a
> 183 w/SDP sent back to the UAC, where the SDP has connection info for
> the PSTN gateway. If the call doesn't succeed after a few rings, then
> the B2BUA may CANCEL the call to the PSTN gateway and INVITE a media
> server; if it accepts with a 200 OK, then the B2BUA would return the
> media server's SDP to the UAC.
>
>
> UAC B2BUA PSTN GW MS
> | | | |
> |--INVITE--->| | |
> |<--100------| | |
> | |---INVITE------>| |
> | |<--100----------| |
> | |<-183 w/SDP-----| |
> A|<-183 w/SDP-| | |
> | |--CANCEL------->| |
> | |-------------------INVITE-------->|
> | |<------------------200 w/SDP------|
> B|<-200 w/SDP-| | |
> | | | |
>
>
> So the SDP of "A" != the SDP of "B".
>
> However RFC 3264 on the Offer/Answer model says:
> At any time, either agent MAY generate a new offer that updates the
> session. However, it MUST NOT generate a new offer if it has
> received an offer which it has not yet answered or rejected.
> Furthermore, it MUST NOT generate a new offer if it has generated a
> prior offer for which it has not yet received an answer or a
> rejection.
>
> This doesn't seem to preclude "modifying the answer"; is anyone aware
> of a rule against this?
There is no such thing as "modifying an answer". An answer is an answer.
Period. If you want to make a change after having sent your answer, then
send another offer.
Technically there is only one answer to each offer. There are some cases
where the same SDP is carried redundantly in multiple messages, but only
one is the answer. Please study draft-ietf-sipping-sip-offeranswer-00
which has been created to answer such questions.
The case you describe above has been discussed ad nausium. Consider a
variation where the B2BUA is replaced with a forking proxy. Everything
else is fine. But the key difference is that the sessions with the two
UASs are distinct early dialogs. (Distinguished by unique to-tags in the
responses.) The o/a rules apply separately to each dialog - the UAC then
decides how it wants to use the two answers - e.g. which it wants to
play out.
When you put the B2BUA in, if it wants to act in a similar way, then it
should form two distinct early dialogs with the UAC, corresponding to
the early dialogs it has with the UASs. Or, it can do more complex
signaling to make the changes within a single dialog, but that is hard.
Paul
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
