Re: [Stox] Media Sessions (draft-ietf-stox-media-01) and forking

Paul Kyzivat <> Sat, 10 August 2013 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DA5221F9E6B for <>; Sat, 10 Aug 2013 07:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.14
X-Spam-Status: No, score=0.14 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_MLH_Stock1=0.87]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ui0ktrQWqwOw for <>; Sat, 10 Aug 2013 07:42:48 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:43:76:96:62:16]) by (Postfix) with ESMTP id 78AE411E818E for <>; Sat, 10 Aug 2013 07:34:00 -0700 (PDT)
Received: from ([]) by with comcast id B1iD1m0041vXlb8512a0kN; Sat, 10 Aug 2013 14:34:00 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id B2Zz1m00q3ZTu2S3d2ZzmG; Sat, 10 Aug 2013 14:34:00 +0000
Message-ID: <>
Date: Sat, 10 Aug 2013 16:33:59 +0200
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1376145240; bh=JqqZfehVj3I0rc1IUm6tfy9juyI2X9qDgVKVifrim+U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LOk/kcYMobps74hRFti3ILtlQKa8PTCg2o7VxliAsE+QRsvGCxzJEavQ3FijFzYF5 m53/fsNswK746njlXgbNdkKGO1Me/3s+2pQMNYZNAetKuEThotO+C08k6OouOrhxqF 2EOt15/3yokwFbIkhRe9INtp1TrbyRYOdTP9Po5jFwsCkfv3/N+As8HL1TK2IX1UV3 m9k0wWPmqvSDMrzFQGXnndWTY2lbMiRmOwmFM3DLBG5vLt1N6wgv4Y3oudo+wNtqZc af9DqaSsgb5UoyB3J45M8MnKDxPs8BnueKOaTyWGF6o0sLb9KMmQBElg+Tz4lKMmi8 KuC1R/aajQ+zQ==
Subject: Re: [Stox] Media Sessions (draft-ietf-stox-media-01) and forking
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 10 Aug 2013 14:42:54 -0000

On 8/10/13 2:41 PM, Olle E. Johansson wrote:
> 9 aug 2013 kl. 20:27 skrev Paul Kyzivat <
> <>>:
>>>> The typical issue is that forking results in multiple early dialogs.
>>>> More than one may result in early media. To give good results the GW
>>>> needs to pass on some or all of that early media to the XMPP side.
>>>> If more than one has early media, then its difficult to know what to
>>>> do. You might pass *one* of them on to the XMPP side.
>>> I don't think we can pass the early media, since there is no way to
>>> do it today. I'd go for leaving it unspecified. There seems to be
>>> some action going on for rebooting Jingle, so when Jingle has a story
>>> for early media a new document could be written specifying it. Would
>>> this work for you? I know it doesn't cover all those
>>> mutli-edarly-dialog cases, but I'm not sure we can do nay better at
>>> this point.
> Just answer the call on the jingle side when you have early media. If
> you haven't got billing on that side, it doesn't matter. If you have
> billing, then don't answer. Easy to document.

That doesn't help very often. The case of concern is when the call 
originates from Jingle and an offer is included. This then gets 
gatewayed to SIP, and then forked. At that point each of the forks could 
start sending media back to the media address in the offer.

The Jingle end doesn't have the option to answer the call.

If the GW terminates and relays media, then it is possible for the GW to 
answer the Jingle call, prior to receiving an answer from any fork. Then 
the GW can decide what media to relay.

But that only works if the GW is a media relay. It isn't an option for a 
signaling only GW.