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

From: "Elwell, John" <[email-masked]>
Date: Mon, 07 Feb 2005 08:47:35 +0000

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Feb 2005 08:18:08 -0500

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).
> 
> ------------------------------------------------------------------------
>