Hadriel Kaplan wrote:
-----Original Message-----
From: Jiri Kuthan [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2008 8:20 AM
well, this is really guessing which can be quite brittle but isn't dialog
id safer? For lot of other things to function, it must be translated
consistently from A to X on one side and X to A in the reverse direction,
mustn't it? So that using some method with same callid/tags as the tested
INVITE should get to the same place?
Oh I don't think I'm guessing.
I was referring to myself, when I mean guessing :)
I'm pretty sure there's a large population of B2BUA's that will change
the call-id and tags when requests go through them. SBC's for example,
but not just SBC's - lots of App/feature Servers too.
They will "fix" them for requests within that dialog, or some vendors can fix
them for requests outside the dialog but only if the request flows through them or
through another box in the same network. In your case you can't send the return-check
in-dialog ('cause that would be pointless presumably). And you wouldn't even want to
send it with a pre-loaded route-set of the received call attempt's path, because that
would also be pointless.
Messages with some dialog-id but not in-dialog could get translated
consistently but supposedly they will break just because of such an
unusual message constructions anyhow.
And even if they get to the same set of b2bua's, you have to hope they each will "fix"
the call-id_tags embedded in the body content of your check message to match the ones from the
original INVITE, which is more than just normal "fixing" of the call-id+tags in the
normal SIP headers.
So if you use the call-id+tags its chances of success are slim if there are
b2bua's. Of course it could be that your mechanism is popular enough that the
b2bua's decide to add support for fixing it - like the Replaces header in REFER
transfer cases was sufficiently popular to make b2bua's auto-fix the dialog
info in them eventually. Or it could end up like S/MIME. Or you could choose
to ignore b2bua's altogether. Or you could pick something else to use for
verification.
P-Charging-Vector? :)
-jiri
-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
