> -----Original Message----- > From: Alex Balashov [mailto:[EMAIL PROTECTED] > Sent: Friday, November 28, 2008 8:48 PM > > You're right. Is SDP in non-183 1xx messages particularly common?
In 180 Ringing it's not very common, but not rare either. I don't think I've ever seen it another provisional. Then again, it's rare to see any other provisional but 180 or 183. > There's no rule that says the first 1xx reply with an offer wins in the > same way that the first 200 OK wins? Nope, not AFAIK. > > The B2BUA is basically broken if it sends them all back with the same > to-tag but unique SDP, IMO. > > But isn't it just following the rule in 13.3.1.1 that all provisional > responses *sent by a UAS* must have the same dialog-identifying > attributes? The rules for a UAS in 3261 were created under the assumption that a UAS is the end of the line. The rules for a B2BUA were mostly undefined, and to this day different B2BUA's do widely different things in different cases, because they perform different functions/roles, and there was no guidance given. A B2BUA can certainly only send provisional responses with the same to-tag, but it can't do it with differing SDP because it has to further comply with section 13.2.1 as a UAS. So no, if it's sending multiple provisionals back with the same to-tag but different SDPs it's not complying with 3261. And I don't just mean in the sense of following 3261 for posterity - things will actually fail to work properly if it does it. It would be nice if UAC's handled it more gracefully, but not all do. The funny thing is that a B2BUA can safely send the responses back with unique to-tags as separate dialogs, because that's just the equivalent to what would happen if a proxy in-between forked the request and its forks reached the same UAS. Technically it's a merged request, but since the rules for the UAC don't care about that case, in that it's legal as far as the UAC cares, it works. (and anyway one could make it appear as multiple UAS's which just happen to be on the same host, but this is not necessary IMO and adds complications) So a B2BUA has two choices: (1) send back only the first SDP, and then "fix" all subsequent SDP answers in the 2xx and after for the session/origin info, and re-invite/update upstream after the initial offer/answer in case the final real UAS sent different SDP, or (2) send back all/any SDP with unique to-tags each(preferably the real to-tags of the real early dialogs) and handle them as the multiple early dialogs they really are. (there is actually a 3rd choice, which is to just send back the first SDP, and then for the 200 ok change the to-tag, but that's tricky in some cases) If the B2BUA can do (2) that is preferable, IMHO, so it can leave the to-tags alone and make other uses of the tags work better (like Replaces or dialog-events). But not all B2BUA's can realistically do that due to their architecture or function. -hadriel p.s. and if you ask most folks they would probably say SIP should never have supported forks or early-dialogs because they cause massive confusion and tech-support headaches, but that horse left the barn years ago and it's a relatively popular feature of SIP. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
