-----Original Message----- From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] Sent: 19 November 2008 15:49 To: Ian Elz; Dan Wing Cc: SIP List Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt
> -----Original Message----- > From: Ian Elz [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 19, 2008 6:40 AM > > The bigger issue is what is to stop a B2BUA either removing the > session-id or generating one of its own. Nothing can stop a B2BUA from doing what its customer wants it to do. Nothing can stop a UA or Proxy or Gateway from doing what they want to do either. None of us are compliance angels, and the customers own the products, not the IETF. All we can do is define a specification, and say what something that supports a mechanism must do to comply with the spec. We can't force compliance on any product of any type, and there is no compliance police. However, if we can show the value of complying to the spec, and don't try to make the device do what its customers don't want it to do, then it has a much better chance of being complied with. And of course a B2BUA may simply just not implement/support this draft, just like a UA doesn't need to implement sip-outbound or gruu or ICE or a myriad of other IETF drafts/RFCs. [Ian Elz ] Agreed. B2BUAs are a world apart. They do have to support the basic UAC/UAS functionality in RFC 3261, or at least they should. The problem is that there is nothing which defines how they should behave to any extent, e.g. passing on received headers etc, mapping Contacts if Call-id or tags are mapped. > RFC 3261 defines a B2BUA as a concatenation of a UAS and a UAC. What > happens between the UAS and UAC parts is undefined and there is no > specification as to what actions the B2BUA should take when passing a > request from the UAS to the UAC. There was a draft presented to the > sipping wg to try an define actions of B2BUAs but this was rejected by a > hum as dangerous. I guess that the consensus was that the B2BUA should > remain totally undefined so that it could perform any action that was > required. [Declaration of interest: I was a contributor to this now > expired draft.] You mean the transparent-b2bua draft? I don't remember what the consensus was in terms of whether it was specific to that draft or to anything about b2bua's. I think there was concern about the type of things that draft tried to address, because it was suggesting behavior of B2BUA's that would potentially change currently deployed behavior, and its scope was rather large and people were worried about all the different types of things B2BUA's do and need to do that would need to be taken into account. [Ian Elz ] That's the one. I was not at the IETF when the draft was rejected so I don't know what happened in the room at the time. I don't think that the draft was trying to specify any specific behavior, it was not Standards Track, but was recommending what types of things a B2BUA should do to behave well in the network and the behavior to solve specific problems, e.g. the dialog reference header mapping issue. The scope of the transparent b2bua draft was large but the longer such work is delayed the larger it becomes. That's not the case for this Session-ID draft. [Ian Elz ] Hopefully not. Specifying the header should not be a large task. The hard part will be how it is used in specific network scenarios and how it interworks with the existing mechanism based upon dialog ids. If the draft gets pushed down that route then it could be a long haul. Has there been a sipping draft identifying a specific problem to be solved and identifying requirements for this header? -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
