Tolga Asveren wrote:
[TOLGA]Is this ambiguity a bug or is this the way it should be? I didn't interprete it as a bug till now, and so was interpreting a NOTIFY/SUBSCRIBE with no "id" as sent for the subscription established with the first REFER. Is there a problem with the semantics defined in RFC? It seems working.Given the ambiguity in the current spec, implementations of both the REFERer and the NOTIFYer need to recognize an Event header with no id as equivalent to an Event header with the id equal to the CSeq of that first REFER with a given dialog identifier - even for refresh SUBSCRIBES.
Well, one person's bug is another person's feature...
The problem with this is that it requires extra special casing in the implementation of refer events vs other events. For all other events the subscription without an id is different from any subscription with an id. With this bug you have to handle the naming of refer events differently.
Paul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
