[Jingle] early media

[Diana Cionoiu]

Hi,

Let me make this a bit more clear, especially on the SIP side.
When you do early media that's actually a completely different media 
stream than the actual voice. When it all started in the PSTN was the 
same because PSTN is a circuit switching network, and once you allocate 
a circuit you can use it as much as you want, before of after answering 
the call.
However SIP has a single transport, which is RTP. Because of that the 
negotiation of the 2 media streams is kind of easy, since you don't have 
to negotiate the transport all over again.
The proposal for early media for jingle is to have a content-add coming 
from the early media machines when they want to provide a different 
media stream. That means, they have to send a new content-add since that 
holds both the transports and the codecs.
If you look at SIP you will find out that SIP sends a complete new 
transport and codecs for the early media, and that may happened in any 
18x answers (180 and 183 are the most common).

Regards,
Diana

Johansson Olle E wrote:
>
> 23 jul 2008 kl. 03.08 skrev Robert McQueen:
>
>> We discussed how Jingle<->{SIP,PSTN,etc} gateways should represent early
>> media (a ringing tone played to the initiator while waiting for a
>> response) to the Jingle client which initiates a call.
>>
>> The problem with the existing spec is twofold:
>> 1. Jingle RTP doesn't support renegotiating codecs, it only supports an
>>    initial offer, and accepting that offer with the intersection, after
>>    which no renegotiation is possible.
>> 2. It's unclear how ICE interacts with early media[1] - do you want a
>>    separate ICE negotiation between the initiator and the gateway, or
>>    can the gateway use the same ICE offer and then trigger a
>>    renegotiation when the real client picks up? There's no way (besides
>>    transport-replace) to cause a renegotiation.
>>
>> However, unlike SIP, Jingle allows the dynamic addition/removal of other
>> streams within a session, without changing the state of the other
>> streams or the session itself. The proposal is therefore that early
>> media is that the gateway should add a new senders="responder" (ie,
>> unidirectional from the gateway to the initiator) audio stream to the
>> call just for the purposes of the early media. The Jingle client can
>> then decide whether to negotiate and play this, or ignore it, etc.
>>
>> More generally, this also avoids the need to make decisions about any
>> complex re-negotiation stuff in Jingle, as we can just say SIP
>> renegotiations can be turned into new contents within the ongoing
>> session by the gateway.
>>
>> To allow this, the following modifications should be made:
>> * Amend XEP-0166 to say:
>>    * the session-accept action should only accept contents which
>>       were offered in the session-init
>>    * the content-accept action should only be used to accept contents
>>       which were added later with content-add
>>    * hence we can allow content-add when the session is in the pending
>>       state
>> * Add an element to XEP-0167 to hint that RTP content is being added
>>   for the purpose of early media, so that the Jingle client should
>>   accept it in advance of the session itself being accepted.
>>
>> Regards,
>> Rob
>>
>> [1]: In many cases it's un-necessary to use ICE as the gateway itself
>> will know it's not behind NAT, and can send an RTP stream for early
>> media directly to the call initiator.
>
> The early media part of SIP call setup can be very complex and
> frustrating.
>
> I haven't followed your discussion, but do remember that
> in the case of PSTN calls, we do not know at call setup whether we
> will receive early media or not. In SIP, this is an additional 
> provisional
> response, like "180 Ringing", which indicates that RTP will arrive
> at the offered ports in one of the offered codecs. This can arrive a
> long time after the initial invite. It's not only used for indication 
> tones,
> but also for messages like "This phone number is not valid" or
> "I am sorry, but the subscriber has moved to Alpha Centauri and
> can't be reached by terrestial PSTN service."
>
> One weird additional feature that we discovered while working with 
> Asterisk
> is that some phone services require the ability to send DTMF from the 
> caller
> during early media phase.
> The example used here was FedEx who had a DTMF menu before they
> actually answered the call.
>
> In a complex situation, you send a SIP invite to a request URI and
> get 180 ringing from one device, 183 Session progress with early
> media from another device and then 200 OK from a third device.
> It's also a bit unclear how to handle 183 Session Progress
> received from multiple devices...
>
> /O