> -----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.


> 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.

That's not the case for this Session-ID draft.

-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

Reply via email to