I'm not buying the "this poor dumb UA can't handle it" argument.
A UA capable of handling IMS signaling is not dumb. So I agree that the
"right" way to do this is to forward the INVITE for the new call to A,
alongside the existing call. The UA then is responsible for alerting the
user. Because the phone is "off hook", it then alerts by (locally)
playing a tone in the audio stream to the user rather than by generating
the usual ring tone.
An alternate, and IMO much inferior, way to deal with this is:
Treat the AS serving A as the actual UA for all calls. Use a sip session
between the AS and UA-A as just a slave connection by which the AS
relays call data to A. If you do that, then the AS probably terminates
and reoriginates media. It can then switch media between calls, generate
tones, etc.
This approach can be made to work, but is entirely at odds with the
architectural principles of SIP.
Thanks,
Paul
Vikram Chhibber wrote:
> If A had an intelligent SIP UA with call-waiting feature, we all would have
> been very relaxed. Unfortunately, that is text-book SIP and in real-world we
> have dumb IADs interfacing with POTS with minimal SIP intelligence and no
> soft-clients running on PC.
> The correct way IMO would be to re-negotiate media between A's UA
> media-server by the application server. This it can do by sending re-INVITE
> without offer to media-server and the received 200 OK offer should be send
> to A party in re-INVITE. It is more complex work that we think but will work
> with any sip UA.
>
> On Wed, Sep 17, 2008 at 2:02 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
>
>> 2008/9/17, Somesh S. Shanbhag <[EMAIL PROTECTED]>:
>>> Actually INFO is usually sent out as part of MID_DIALOG.
>>> But when the new call comes to A, the IMSServer can send 180 as follows.
>>>
>>> SIP/2.0 180 --Waiting for Call--
>>>
>>> and if A disconnects, it can automatically connect.
>> I think karthik asked for a way to notify A about a new call to him
>> (so I suggested just to send a new INVITE as usual).
>>
>> --
>> Iñaki Baz Castillo
>> <[EMAIL PROTECTED]>
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
