I wasn't trying to suggest that 180 and/or 182 is the best way to hand
the call waiting indication. I was only reacting to the suggestion that
there might be something wrong with returning multiple 180 responses.
Paul
Huelsemann, Martin wrote:
> 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
