Dima Polsky wrote:
> Although transactions are independent the info that passes in those
> transactions is related to both UA ( SDP for example, INFO, or query for
> OPTIONS), let's look at mid-dialog UPDATE for a more extreme example -
> it carries a new sdp offer which is of little relevance to the B2BUA but
> should be forwarded from side to side.
While what you say may be true for some B2BUAs, it is not something that
can be asserted generally for all B2BUAs. Apparently you have in mind a
sort of B2BUA where this is the case.
> If the UAS responds to the UPDATE
> request before the UAC received an answer from the other user it may
> create an inconsistent state (if user declines the offer), so should he
> wait?
3261 doesn't provide any requirements for B2BUAs other than that the
each side shall follow the rules for a UA. If you want some predictable
behavior over and above that, then it is up to you, or somebody, to
specify it.
It sounds like you are talking about the fabled "transparent" B2BUA. But
AFAIK there are no formal specifications for such a thing. (I guess
perhaps you could consider some of the IMS specifications to be such,
but they are very specialized.)
Paul
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> [EMAIL PROTECTED]
> Sent: Wednesday, November 22, 2006 3:17 PM
> To: [email protected]
> Subject: Re: [Sip-implementors] B2BUA, atomic requests and UPDATE
> question
>
> From: "Dima Polsky" <[EMAIL PROTECTED]>
>
> Now a B2BUA is described in the RFC as a concatenation of a UAC and
> a UAS. If a call is established through the B2BUA, and an OPTIONS
> request is received by one side of the B2BUA, can it answer the
> request with a final response or should it wait for a response of
> the other side to the forwarded request ? If it waits, can it
> process additional overlapping requests? For example another
> OPTIONS or INFO?
>
> It can do any of these, as the SIP transactions on one side of the
> B2BUA are independent (from the SIP standard point of view) from the
> SIP transactions on the other side.
>
> Dale
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
