From: Hadriel Kaplan <[EMAIL PROTECTED]>
Note the "adversary" so to speak is just that a downstream node
can get a Call-ID and must not be able to tell from the Call-ID
it got, what the Session-ID should be, so they can't tell the
Call-ID was changed by a b2bua. Of course an upstream node
would be able to tell - for example the UAC would if it received
a subscribe for the dialog-event that had a session-id it
created, with a call-id+tags it didn't. But then one of the
main points of this exercise is to make those cases work. I
can't guarantee that all operators would want it to work in such
cases, but for those that don't want it to, nothing will help us
make it work.
There's something I don't understand here. You mention "received a
SUBSCRIBE for the dialog-event that had a session-id it created, etc."
What does that mean? I assume you mean that the UAS of the original
call (or something in its near network vicinity) wanted to subscribe to
the dialog events of the UAC, filtering for the one dialog it knows of.
That would be:
SUBSCRIBE [contact taken from INVITE seen at UAS] SIP/2.0
Call-Id: [something new]
Session-Id: [something new]
Event: dialog;session-id=[session-id of INVITE]
That would go back through the B2BUA (or one of its brethren) because
the Contact as seen at the UAS was munged as necessary by the B2BUA to
ensure that that would happen. The B2BUA would change the Call-ID, but
it would leave the Session-Id and the Event session-id parameter
unchanged.
But there would be nothing to compare the Event session-id parameter
*to*. And the Session-Id would have no apparent relationship to the
Call-Id or tags of the SUBSCRIBE as seen at the original UAC (the UAS of
the SUBSCRIBE).
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
