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
Sip-implementors cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors
|
