Why should two 180 responses ever be a problem? (Assuming they carry 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
