Martin, If we are considering using Call-Info in an INVITE response to convey a contact URI to be used as the Request-URI in a SUBSCRIBE request, that URI could not only identify the monitor but also the particular call. Problem solved?
John > -----Original Message----- > From: Huelsemann, Martin [mailto:[EMAIL PROTECTED] > Sent: 05 March 2008 14:40 > To: [email protected] > Cc: [EMAIL PROTECTED]; Elwell, John; > [EMAIL PROTECTED]; Alexeitsev, D > Subject: AW: [BLISS] Call-completion design question: > End-to-end parameters > > Dear colleagues, > > I'm just trying to summarize your discussion for myself: > > - the CC subscription and the CC call have to be correlated > to the original call somehow, psoposed is to use a 'id' > parameter for this purpose > > - the callid from the original call could be used as value > for the 'id' parameter (for the PSTN interworking also a > fallback procedure to generate the 'id' parameter from caller > and callee id is proposed, as gateways are not able to store callids) > > - the problem with the usage of the callid is, that proxies > can change the callid, and because of this a correlation of > original callid and the callid delivered in the 'id' > parameter might not be possible > > - it is unclear to which header the 'id' parameter should be > added: From-header might be changed by forking proxies; Call > Info header demands a URI which is not always available > > > > So if this summary is correct, there seem to be 2 questions: > > > Is there a end-to-end unchanged identification of the > original call which can be used to fill the 'id' parameter? > > To which end-to-end unchanged header of the CC subscription > or the CC call can the 'id' parameter be added? > > > > BR, Martin > > > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
