I was just thinking of an alternative soln. for this issue. How about sending a 500 Error response with Retry-After header, so that UAC could try re-sending the UPDATE request after a time decided by Retry-After header value?
Then we could probably expect the call to connect, in the meantime, after which the UAC would send an UPDATE / Re-INVITE to modify the codec. Then, we would be able to avoid voice clipping issue, mentioned below. But, we would not be able to accept an UPDATE request to modify the codec in early-media state, in this case. Any thoughts on this? Thanks, Jagan On Thu, Aug 21, 2008 at 10:20 PM, Nebojsa Miljanovic <[EMAIL PROTECTED] > wrote: > 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
