[Jingle] early media

Johansson Olle E oej at edvina.net
Wed Jul 23 02:44:51 CDT 2008


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


More information about the Jingle mailing list