>> >> |------ C >> | >> A ------ B >> | >> |------ D >>
> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 03, 2008 3:49 PM > > You mentioned something like "dialog-set". I'm not certain yet if "set" > is the proper term here. But assume for the moment that it is. > > Then what you really have is a "dialog-set-id" right? Not a session-id. I think very few people on this planet know what a SIP "dialog" is. :) But the word "Session" is a more common word for operators (even though its definition in SIP is far more ambiguous, IMO). For example, I think in your first 3PCC example (up top) most people really do expect that the same Session-ID be used for A-to-C. Whether it should be the same for B-D is what (IMO) is fine but not necessary, but that's just my opinion; and I bet plenty of operators would consider that the same "Session" too and be surprised if it wasn't. > (I suspect that an SBC creates > dialog-sets, and other B2BUAs do not.) I don't think so. For example, I would argue that half the SIP functional roles defined in 3GPP create dialog-sets in actual deployment. Or for example, what a find-me app server does, which hunts for a user at multiple targets; or even what a typical IP-PBX does; or what the market-leading "feature servers" seem to do. Basically, my assertion is that if you receive a SIP request from A as a UAS, and route or fork it to one or more targets (B/C/D) as a UAC, you have created a single dialog-set. Let's assume it establishes with B. IF you receive an in-dialog or dialog-referential request from A or B, and act upon that request as the UA without forwarding it back to A or B and the action creates another dialog, (e.g., you create a new INVITE), then I'd argue you're probably creating a new dialog-set; because that's what should have been created had it actually gone back to A or B and they'd created a new dialog. But really I'd defer to other people's opinions on that. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
