Re: draft-kuthan-sip-derive
Jiri Kuthan <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
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