VARUN BHATIA <varuninbha...@gmail.com> writes: > As a B2BUA what is the expectation when it is sitting behind a forking > proxy (IMS Application Server) and it is sending back multiple early > dialogs back. > > 1. It should ideally send it back transparently to ingress i.e. > creating multiple early dialogs at ingress leg too. (UAC should be > capable of supporting early dialogs) > 2. Doing inter-working with ingress and rather than sending multiple > early dialog toward ingress it should send new offer in UPDATE. > (Though in this case UAC should support UPDATE method in early > dialog).
As Paul said, the B2BUA must present itself as a proper UAS on the ingress side and as a proper UAC on the egress side. Other than that, it can do anything that accomplishes your goal. But as Paul also said, it is complicated to bundle multiple early dialogs on the egress side into one early dialog on the ingress side. > In the above scenario if Pre-condition is been expected then will > there be any change or it should be same. > As per my understanding forking proxy should handle, in this scenario, > once the pre-condition has been exchanged & resource reservation has > been done. AS should not send multiple early dialog towards B2BUA. A forking proxy is simpler, because the proxy doesn't actually handle any of the precondition processing, it just passes the messages through. A UAC that is handling preconditions on multiple early dialogs has to allocate resources for each of them, in coordination with each early dialog's precondition negotiation. It would be complicated for a B2BUA to merge precondition processing in multiple early dialogs into precondition processing in a single early dialog, because the B2BUA would have to merge the demands of all of the UASs into a single demand for reservations on the ingress side. Depending on the range of demands that can be expressed in preconditions, it might be difficult to create such "union" preconditions. > Though i am trying to find reference in RFC or 3GPP standard but not > yet able to find any. The difficulty is that the problem is implicit -- Can you figure out how to implement a B2BUA that has the features you want? The standards only prescribe the requirements that the B2BUA must conform to, not how to design one that does what you want. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
