One problem with removing UPDATE from Allow list due to UAS response is that you will likely not be able to use UPDATE for Session Refresh between UAC and B2BUA (if the UAC is the refresher). And, UPDATE is preferred over re-INVITE for session refresh.
It is not a bad thing to just have B2BUA remember that the UPDATE attempt took place, respond to UPDATE with some dummy/hold SDP, and perform re-INVITE exchange with both UAC and UAS after answer. It's not a perfect solution, and may cause some voice clipping but should succeed. Neb On 8/20/2008 1:34 PM, Jagan Mohan wrote: > Hi Paul, > > I think your suggestion of including the value in Allow header only if > it's received from other side, is the best solution considering the > following constraints: > 1) Since the call is in early dialog, translating the UPDATE to Re-INVITE on > the other leg would result in failure of the UPDATE request. > 2) My B2BUA does not support transcoding. > > Thanks, > Jagan > > On 8/20/08, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > >> >> >>Jagan Mohan wrote: >> >> >>>Hi All, >>> >>> I would like to know whether a B2BUA can insert the SIP Methods it >>>support in the Allow header, when a SIP call is made between two UAs >>>through >>>the B2BUA. >>> >> >>There are *no* rules for B2BUAs, other than that each *side* must behave >>correctly as a UA. There are no rules for how the two sides are correlated. >> >>So the B2BUA can put anything it likes into the Allow header, as long as it >>truly does allow it. >> >>BUT, if the B2BUA can only allow it when the other side allows it (which >>depends on the relationship that the B2BUA establishes between the two >>sides), then it ought only include the value in Allow if it receives it from >>the other side. >> >> If yes, then I have query on the following call flow: >> >>> UAC ---- B2BUA ---- UAS. >>> >>> Say, UAC and B2BUA support UPDATE method. And UAS does not support >>>UPDATE method. >>> >>> If an UPDATE request for codec change is received from UAC within an >>>early dialog, then what should be the Error response from B2BUA? Here, >>>B2BUA >>>is aware that UAS does not support UPDATE method from the reliable >>>provisional response. So, it should not forward the UPDATE request to the >>>UAS. >>> >> >>The B2BUA need not match messages 1:1 on the two sides. If it is >>sufficiently clever, it may be able to create some valid signaling on the >>other side to make things work. E.g. it might send a reINVITE toward the >>UAS. >> >>Or, if the B2BUA is also processes/relays the media, it may just handle the >>UPDATE locally, and start transcoding to the format(s) negotiated with the >>UAS. >> >>It sounds like you want your B2BUA to act like a proxy. If so, then why not >>just let it *be* a proxy? >> >> Thanks, >> Paul >> >>Thanks, >> >>>Jagan >>>_______________________________________________ >>>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
