[Jingle] early media

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

[Johansson Olle E]

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

[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