Gagandeep Singh <higagand...@gmail.com> writes:
> Considering below scenario. (Please view in fixed-width font)
>
> UAC              B2BUA1             B2BUA2             UAS
> |------INVITE----->|                  |                  |
> |                  |------INVITE----->|                  |
> |                  |                  |------INVITE----->|
> |                  |                  |                  |
> |                  |                  |<-------180-------|
> |                  |<-------180-------|                  |
> |<-------180-------|                  |                  |
> |                  |                  |                  |
> |<---183(100rel)---|                  |                  |
> |                  |                  |                  |
> |------PRACK------>|                  |                  |
> |                  |(-----PRACK?---->)|                  |
> |                  |                  |                  |
>
> (1) Route set due to 180: <B2BUA1>, <B2BUA2>
> (2) Route set due to 183: <B2BUA1>
>
> PRACK should be routed as per (2), which will not be possible if route set
> (1) is used.

As all the responders have indicated, within a dialog, the UAS MUST
provide the same Record-Routes for all the provisional responses, which is
indeed the set of Record-Routes that was attached to the INVITE when it
received it.

When B2BUAs are operating, there are two methods of operation:

(1) operate the incoming and outgoing dialogs as specified in RFC 3261,
that is, be a UAC connected to a UAS, or

(2) act as a "quasi-proxy", which does not fully terminate either the
incoming or outgoing dialog, but also modifies the messages within the
dialog in ways that are not permitted by RFC 3261.

In the latter case, the B2BUA has to ensure that the message flow
appears to the upstream and downstream devices to be operating according
to RFC 3261.  (That is not easy to do.)

In the example you diagram, if B2BUA1 is operating in mode (1), then the
PRACK terminates at B2BUA1; B2BUA1 sends a 200 response for it.  But
also, the 180 and the 183 going to UAC do not contain Record-Route
headers for B2BUA2 or UAS; B2BUA1 is the UAS for the dialog with UAC.
B2BUA1 MUST NOT send a PRACK to B2BUA2 because B2BUA1 has not received a
100rel provisional response from B2BUA2.

If B2BUA1 is operating in mode (2), it still MUST NOT send a PRACK to
B2BUA2.  Since it decided to send the 183 itself, it knows that it MUST
provide the response to the PRACK it receives for the 183 -- despite
that it MUST have provided the 183 with the same Record-Route headers
that were on the 180 going to UAC.

Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to