Subject: RE: [Sipping] Some thoughts on fixing early media: request/indication for early media

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 19 Jul 2006 18:01:10 +0200

Hi,

>>>This is probably the right direction, but what do you really do  with
the
>>>media in the forking case?  Let's say you had two gateways, the  call
was
>>>forked to both of them, and early media came from both of them?
>>>
>>>Both send 200 OK.  This is probably acceptable, although I suspect
most UAs
>>>won't appreciate it.  Eventually, one is going to hang up, and the
other 
>>>is going to keep going (and send the "Billing Starts" message).  From
a sip
>>>standpoints, that's probably okay.
>>>
>>>But what do we do with the media?
>>>
>>>I'd clearly trade a "Billing Starts" message for deprecating early
media.
>>>Wouldn't even have to be a P-header.
>>>
>>>
>>That's where a two-phase model comes into play.
>>
>>Let's discard SIP syntax and talk about it at a higher level -- maybe 
>>that will help.
>>
>>Let's say I place a call, and it is delivered to 4 recipients, all of 
>>whom wish to send "early media".
>>
>>Each sends back a request to send early media, possibly with some 
>>additional information about the early media (like "custom ringing
tone", 
>>"PSTN early media", etc.).
>>
>>I can't listen to 4 media streams at once, so I pick one (possibly
using 
>>the additional information they sent), and I tell that early- media
source 
>>to go ahead.
>>
>>Assuming the early media doesn't lead me to establish a session, I
then 
>>tear down that leg and tell the next  early-media source to go  ahead.
>>
>>Repeat until I establish a session, then I tear down all remaining
legs 
>>(if any) without having heard their early media.
>>
>>
>>What would this look like in SIP?
>>
>>Here's a rough outline. I'm sure somebody can do better. The idea
here is 
>>to do a "media starts" using provisional reliable messages  and a
"billing 
>>starts" using 200 OK.
>>
>>I send an INVITE with a new early-media precondition tag. It is
forked 4 
>>ways. Each recipient responds with a reliable 18x including  an 
>>"early-media request" tag,  possibly including an SDP answer (for 
>>bidirectional or "early session" media), and possibly including an 
>>early-media usage description modifier of some sort.
>>
>>I pick one of the 4 responses and send a PRACK with an early-media - 
>>accepted tag. I defer sending PRACK to the other nodes.

>An issue here is that the other nodes will keep retransmitting their
18x 
>responses. So instead of deferring PRACK, better to send one with SDP 
>describing the equivalent of "early media on hold", for each other
node. The 
>UA could then use UPDATE to select the next one to play, etc

[CHH] 

I agree that we should not defer sending PRACK and "discard" 18x
responses, because:

1. It causes extra traffic in the network, when they are re-transmitted.
2. The 18x may contain other, non-media information, which the UAC wants
to acknowledge.
3. The PRACK may contain other, non-media informaion, which the UAC
wants to send.
4. It's bad protocol design.

Also, there seems to be two assumptions made with Dean's proposal:

1. The UAS is able to "hold" its early media, and the session setup,
until it's has been given permission to play it. It may work for a media
server type of node, but it may be difficult in scenarios where the UAS
doesn't have control when the media will start coming (e.g. in
interworking scenarios), and you have to communicate with the "non-SIP"
side before you can generate an SDP answer. Serial forking would solve
that, since it wouldn't get the INVITE until it is "permitted" to play
early media (if it wants to), but it would of course prevent things we
want to do with paralel forking.

2. The UAC is able to determine that early media on a specific leg
"doesn't lead me to establish a session", so it can tell the next
early-media source to play its media. This is another scenario where I
think a "190" provisional response could be useful, so that the UAS (or
proxy) can indicate to the UAC that a specific leg is now terminated,
and will not lead to an established session.

Another question is whether we always need to request early media. In
case of serial forking, wouldn't an indication be enough? The UAC would
only receive early media from one remote entity, so...

Also, isn't the request you are talking about already defined in
RFC3959? I am not sure we would need an SDP body for the request,
though, assuming the same SDP information will be used for both the
early and the "established" media.

[/CHH]

Regards,

Christer

_______________________________________________
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