Martin, I don't see forking as a problem. A monitor generates a URI that uniquely identifies itself and the call and places it in the Call-Info header field of the response to the original INVITE request. For example, it can ask a registrar for a temporary GRUU if it doesn't have its own host name. If this URI is used in the SUBSCRIBE request or in the final INVITE request, it will cause it to be routed to the same monitor and allow that monitor to identify the call.
Of course, a different solution will be needed for PSTN interworking - I have not thought that one through. John > -----Original Message----- > From: Huelsemann, Martin [mailto:[EMAIL PROTECTED] > Sent: 06 March 2008 09:08 > To: Elwell, John; [email protected] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Alexeitsev, D > Subject: AW: [BLISS] Call-completion design question: > End-to-end parameters > > Surely this would be conveyed unchanged from the callee CC > monitor to the caller CC agent. > > But how to use this for the subscription/recall? As Dale > indicated the request URI is very like to be changed in a > forking scenario. > > BR, Martin > > > > > -----Ursprüngliche Nachricht----- > > Von: Elwell, John [mailto:[EMAIL PROTECTED] > > Gesendet: Donnerstag, 6. März 2008 09:02 > > An: Hülsemann, Martin; [email protected] > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Alexeitsev, Denis > > Betreff: RE: [BLISS] Call-completion design question: > > End-to-end parameters > > > > 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
