Subject: [Sip] issue with putting early media on hold

From: Rohan Mahy <[email-masked]>
Date: Wed, 05 Sep 2001 20:13:12 -0700

Hi Folks,

Traditionally proxies that implement pre-call features (e.g. some type of 
complex forking logic) assume that they do not have to Record-Route.
Under the early-media draft, putting early media on hold using the reINVITE 
mechanism proposed can interfere with pre-call features on proxies that 
don't record route.

Below is a call flow where this problem occurs:

UA1	Proxy	UA2

INVITE ->		# original INVITE
	INVITE ->	#   first branch of this INVITE
	<- 18x		# 18x with offer for early media
<- 18x
PRACK -------->	# answer accepting early media
<--- 200 (PRACK)
<==============	# early media flows

so far, so good--we now have early media flowing from UA2 to UA1
...

Now UA1 wants to put this media on hold using a reINVITE

INVITE ------->	# UA1 wants to put early media on hold
	<- 490		# UA2 terminates the previous INVITE transaction
<---------- 18x
  	
At this point the proxy believes that the first branch has been 
terminated.  The proxy now has no control over the INVITE which replaced 
the earlier transaction.  The proxy can never cancel this first branch.

Fortunately this is easy to solve.  I propose using a separate method to 
convey that the caller wants to modify early media.  I will use the OFFER 
method (listed as option 4 in the early media draft) as an example.

OFFER ----------->	# this SDP offers to put early media on hold
<------------ 200	# this SDP answers the offer

The 18x/PRACK for early media offered by the callee, and accepted/rejected 
by the the caller still works fine.

thanks,
-rohan

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 5 Sep 2001 20:58:51 -0700

Rohan,

I agree with you that the early media re-INVITE call flows should be changed
(too complicated for starters).

I suggested a while back that the "OFFER" request/response does not carry
SDP itself. I believe this avoid a number of nasty synchronization problems
with INVITE responses. Instead the "OFFER" method simply prompts the UAS to
regenerate its last 183 response (ie, the offer message is asking the UAS to
generate OFFER rather than carrying the UAC's offer). This allows the UAC to
put media on hold or whatever it wants. This requires no extra SDP/media
processing logic on either side - the same mechanism is reused which is a
big bonus in my books. 

Cheers,

Robert.

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Wednesday, September 05, 2001 8:13 PM
> To: [email-masked]
> Subject: [Sip] issue with putting early media on hold
> 
> 
> Hi Folks,
>