We're revising draft-ietf-bliss-call-completion-02 in the Call-Completion committee of BLISS. It turns out that our design can be simplified and made more robust toward various difficulties in the Real World if the the recipient of a SUBSCRIBE request could take the >From header of the request into consideration when determining the entity/events that are to be sent in NOTIFYs.
But it does look like having a subscription affected by the From value has not done before, so we're extending the practice of SIP, if not the letter of the law. Use of the From value is not described in RFC 3265, but as one member pointed out, "It doesn't say you can't, either." What do people think of this? The use case: We want to be able to correlate an incoming SUBSCRIBE with a previous incoming INVITE from the same UA. The original idea was that the SUBSCRIBE should specify in some manner the Call-Id of the INVITE, but it turns out that in real SIP networks, SBCs often change the Call-Id, so the caller doesn't know the Call-Id that the callee sees. However, it's rather reliable that the From headers of the two requests will match, as SBCs are likely to change both of them in the same way. Dale _______________________________________________ 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
