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
