But it seems that some preconditions should be fulfilled in context with the 'adding a 182' solution, which could cause problems to very simple UAs or gateways. So if there is another solution which avoids this difficulties I think we should choose this other solution.
BR, Martin > -----Ursprüngliche Nachricht----- > Von: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 21. April 2008 18:11 > An: Hülsemann, Martin > Cc: [email protected]; [EMAIL PROTECTED] > Betreff: Re: [BLISS] Call Waiting Indication > > > > Paul Kyzivat wrote: > > Why should two 180 responses ever be a problem? (Assuming > they carry the > > same answer.) > > The above is a little sloppy. TO restate: > > Why should two 180 responses ever be a problem so long as > they conform > to correct offer/answer and dialog usage? > > (If reliable provisional responses are *not* being used, then > those in > the same dialog that contain answers must contain the same answer.) > > > That is entirely legal, and may in fact be the most > appropriate way to > > keep the transaction from timing out if the alerting goes > on for a long > > time. > > > > I certainly hope no UAS is going to choke on this. > > > > Paul > > > > Huelsemann, Martin wrote: > >> 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 > >> > > _______________________________________________ > > BLISS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
