Re: [Sipping] Question on RFC 3725 (3PCC)

[Paul Kyzivat <pkyzivat at cisco.com>]

John,

I believe this has been discussed a bit, informally. But not in any 
definitive way.

IMO "A's phone rings" is just a familiar way of saying "A's UA alerts" - 
it implies nothing about media, or exactly how the alerting is done.

In this case, A can offer whatever is wishes. It can enhance the 
possibility of a successful session by offering all the media it 
supports, but it is under no obligation to do so. For instance, and 
audio/video device might only offer audio.

If the device supports audio and IM, but the audio is currently in use, 
it is indeed a challenge for the UA to decide how best to manage the 
situation. That is perhaps an area where vendors get to innovate for awhile.

If PRACK and UPDATE are supported then there are more options to get 
things sorted out before answering.

	Paul

Elwell, John wrote:
> In RFC 3725, for flow 1 (figure 1) it states: "The controller first 
> sends an INVITE A (1).  This INVITE has no session description.  A's 
> phone rings, and A answers."
>
> If there is no SDP offer in the INVITE request, UA A must include all 
> media it supports in the SDP offer sent in the 200 OK, and in the ACK it 
> will determine which of those media UA B wishes to support. One 
> possibility is that only IM is accepted. On the other hand, the 
> statement "A's phone rings" seems to suggest that it can be assumed that 
> audio will be among the media accepted by UA B. It seems that UA A 
> cannot make any decision on which resources to make available until it 
> receives the ACK. So, for example, if it already has an audio session, 
> it might need to place that on hold to make audio resources available, 
> but it would seem to be premature to do that until the ACK is received. 
> Hence it would also seem premature to "ring".
>
> Similar considerations would appear to apply to the other flows in RFC 
> 3725 (except for the deprecated flow 2).
>
> Has this issue been raised in the past, and if so what was the outcome?
>
> John
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP