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