> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Huelsemann, Martin > Sent: 18 April 2008 11:16 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [BLISS] Technical problem -- correlating dialogs > > > > > -----Ursprüngliche Nachricht----- > > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Im Auftrag von Paul Kyzivat > > Gesendet: Freitag, 11. April 2008 17:39 > > An: [EMAIL PROTECTED] > > Cc: [email protected] > > Betreff: Re: [BLISS] Technical problem -- correlating dialogs > > > > And I suppose this could be combined with some other sort of > > authorization. There could be one mechanism with a cookie for > > those who > > can support it, and this weaker mechanism could require > some special > > credential or a whitelist, that was by policy restricted to > gateways. > > > > Paul > > > Hi, > > I also think for the internet draft it could be sufficient to > concentrate to describe the cookie mechanism for a pure > internet environment and strongly recommend to use this, but > mention the option for a weaker (but possibly also cookie) > mechanism. Possibly also in combination with a whitelist for > the subscription. But any way this could be described in > specs for networks that can guarantee to prevent > invastigation of privacy, which I think will be possible for > example in the 3GPP IMS. > > > > The other question is, how is the cookie conveyed from > monitor to agent? Did we come to a conclusion for this? Is it > possible to use the Call-Info header for this purpose? In the > design team there was a discussion to use the Call-Info > header in the following way: > > > > For example, consider this header inserted in a response > by a monitor: > > Call-Info: > <sip:atlanta.example.com?Call-Info=%3cx:y%3e;purpose%3dcall-co > mpletion%3bcookie%3d123456> > ;purpose=call-completion > ;m=NR > > The contained monitor's contact URI is thus: > > > sip:atlanta.example.com?Call-Info=%3cx:y%3e;purpose%3dcall-com > pletion%3bcookie%3d123456 > > When that URI is used to generate a SUBSCRIBE, the > resulting request > looks like this: > > SUBSCRIBE sip:atlanta.example.com SIP/2.0 > Call-Info: <x:y>;purpose=call-completion;cookie=123456 > Call-Info: <...>;purpose=call-completion;m=NR [JRE] I don't understand how you get two Call-Info header fields.
John _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
