Hi, the problem is that in case of an interworking to the PSTN the mapping is not symmetrical. This is especially a problem if you think of a scenario where a Internet call to the PSTN is forwarded in the PSTN to back the Internet. When forwarding the PSTN generates an ACM indicating Call Forwarding, which will be mapped into a 181. The 180 generated by the destination in the internet will be mapped into an ACM, which will be mappep by the forwarding instance in the PSTN into a CPG indication allerting (because the ACM was already sent). The CPG will be mapped into a 180 back to the Internet. The 182 generated by the destination in the internet will be mapped into a CPG indicating Call Waitng, which at this point of the call would also be mapped into a 180, in this case followed by the 182. So there would be two 180 Ringing responses on the origination Internet side, which could cause problems.
BR, Martin > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 18. April 2008 12:56 > An: Hülsemann, Martin; [email protected] > Betreff: RE: [BLISS] Call Waiting Indication > > Hello, > > What would be the problem in sending both 182 and 180? > > BR, > Jari > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of ext Huelsemann, Martin > Sent: 18 April, 2008 13:49 > To: [email protected] > Subject: [BLISS] Call Waiting Indication > > > Dear colleagues, > > we've discussed about Call Waiting some time ago, but I think > we didn't > really came to a conclusion at that time. So I'm still looking for a > solution how to inform a calling user that the called user is already > involved in a call. > > The background was and is, > as the behaviour of the called user in the case of call waiting is > different from the situation the phone rings and the user just answers > the call (the time until the call is answered will be longer > in average, > because the user realises that a call is waiting, then he brings the > call he is involved in on hold or ends it, probably saying > some words to > the other user, and only then he answers the waiting call), > in the PSTN > there is an indication in the backward 'Ringing' message, saying "call > is a waiting call", defined in the Generic Notification Indicator > element in ITU-T recommendation Q.763. > > In some networks this leeds to a call waiting announcement to the > calling user. > > Anyway the calling user is informed that the time until the call is > answered might be a littlebit longer, and he will wait a littlebit > longer until he hangs up. > On the other hand the called user knows the the calling user has > information about the call waiting situation, and that gives him some > more time to answer the waiting call. > > > > When we discussed this issue, I think the proposed solutions were the > following > > - usage of a 182 Queued response > > Con: it not sure the the 182 will cause a ringing tone at > the calling > user > > > - usage of an Alert-Info header > > Con: Alert-Info shoulf be used to provide Ringing tones, possible > conflict between providing a ringing tone and rendering the > information > to the user > > > - Usage of presence information <activities> <on-the-phone/> > </activities> > > Con: Presence is a subscription based service and it may not be > possible to interwork this information to other Networks, esp. PSTN > > > - I proposed (as usual) to use a P-header for this purpose, as a > possibility to interwork the Generic Notifiaction Indicator element in > general > > Con: another new P-header; possible interactions with the event > notification framework; > > > > So in my opinion the best solution would be an indication in the 180 > Ringing response. Something like the Alert-Info header without the > mentioned difficulties. > > > In other discussions it was proposed to use the Call-Info header for a > similar purpose. This could perhaps be done by using a special URI and > defining a new CW specific purpose value. > > Another solution could be to re-use the presence XML schema as defined > in RFC 4480 with <activities> set to <on-the-phone/> and > include it in a > MIME body in the 180. > > > > Regards, Martin > > > > > > > > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
