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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 14 August 2013 19:17 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF7A11E80FF for <stox@ietfa.amsl.com>; Wed, 14 Aug 2013 12:17:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.128
X-Spam-Level:
X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[AWL=-0.305, 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs5LB85DKgdS for <stox@ietfa.amsl.com>; Wed, 14 Aug 2013 12:17:34 -0700 (PDT)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 3102B11E818F for <stox@ietf.org>; Wed, 14 Aug 2013 12:17:34 -0700 (PDT)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta04.westchester.pa.mail.comcast.net with comcast id CcKQ1m0011HzFnQ54jHZ82; Wed, 14 Aug 2013 19:17:33 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id CjHY1m00K3ZTu2S3ajHYFy; Wed, 14 Aug 2013 19:17:33 +0000
Message-ID: <520BD7CB.6020909@alum.mit.edu>
Date: Wed, 14 Aug 2013 21:17:31 +0200
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
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
To: Adrian Georgescu <ag@ag-projects.com>
References: <7594FB04B1934943A5C02806D1A2204B1C418E51@ESESSMB209.ericsson.se> <8C703C0F-181C-4E36-8A59-727B45C0A1B5@ag-projects.com> <7594FB04B1934943A5C02806D1A2204B1C418FAC@ESESSMB209.ericsson.se> <B7CBEFB1-2A23-4337-90DD-D8157123A1AD@ag-projects.com> <7594FB04B1934943A5C02806D1A2204B1C41C17E@ESESSMB209.ericsson.se> <6E2B9398-C9C5-47F1-AC5D-2C7E23AB6E69@ag-projects.com> <7594FB04B1934943A5C02806D1A2204B1C41C208@ESESSMB209.ericsson.se> <51FEA128.2060806@ag-projects.com> <52011FEA.5040104@alum.mit.edu> <6A3963CE-AD8C-4C93-9E39-9268BA82AF4B@ag-projects.com> <520534A9.9050100@alum.mit.edu> <8A0B7E66-0F4F-41CF-8CC0-E5BD77EFE0F5@edvina.net> <52064F57.80309@alum.mit.edu> <AF343715-E436-44E4-A2DE-062AA0526DB0@edvina.net> <7594FB04B1934943A5C02806D1A2204B1C43CA2E@ESESSMB209.ericsson.se> <4B4DCCFA-EF19-4F93-A740-6A9F5003DB4D@ag-projects.com>
In-Reply-To: <4B4DCCFA-EF19-4F93-A740-6A9F5003DB4D@ag-projects.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1376507853; bh=m8291R3eut8Zh+2Ib4QLoFz9IL3zAT832QPBDm8+EXk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Yz3aA1uzV9gLA1/4DLWuNxpmMURjTBY/Y0PbtHpmj5w/NLuZDu3Jqd0Z0Q2jroxm/ 0ASeb2Q3A52jhO6HSgGfaE07VVIcwvd3Y5BS6bUaoq+Zdgw9SpGD6xgvVDSJV0wgmX +tw1kY+UtFOLQo6JhMtPip9w3foU36ihGrkP3vhcgS+CCkLrqFiutKZZyYOsTyuZvL kiOO4zks9M5b8Fa8c2Ki1U84jk1qo5JwdC3KyE4to4o4NfogjHrk+aijYZt0zEhrZ3 lt7QT64X8TKX1nfviY30RnUEpZEUrSG6wuTPDFiNSDsXVzQTYFCEkdyvYylDBggZE+ kjNgobquVhsaw==
Cc: "stox@ietf.org" <stox@ietf.org>, "Olle E. Johansson" <oej@edvina.net>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [Stox] Media Sessions (draft-ietf-stox-media-01) and forking
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Aug 2013 19:17:39 -0000

On 8/11/13 12:33 AM, Adrian Georgescu wrote:
> I am wondering how a SIP session with multiple media types like RTP and MSRP can be translated into an equivalent XMPP signalling without bridging media as well.

I suppose the MSRP would indeed have to be terminated by the GW and 
translated into XMPP format. But it could still avoid handling the RTP.

	Thanks,
	Paul

> Adrian
>
>
> On Aug 11, 2013, at 12:22 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>
>> Hi,
>>
>>>>>>>> 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.
>>> Right, but I haven't seen anyone really interested in "signaling only" gw's. Emil said multiple times during our IETF meeting that it will be a b2bua anyway.
>>
>> A B2BUA does not necessarily control media. Please take a look at http://tools.ietf.org/html/draft-ietf-straw-b2bua-taxonomy-02, which discusses signaling B2BUAs :)
>>
>>> Early media is just media - it's the billing that's the difference. There's no way to handle multiple early media streams "properly" even if you're a sip b2bua without Jingle at all...
>>
>> That is correct. The difference is that we are now standardizing the behavior of the GW, so we do need to say something.
>>
>>> So if you have a jingle endpoint placing a call to a SIP URI and the gateway gets early media from the SIP side, the gateway can answer the jingle call and relay the
>>> early media. Whether it wants to mix or stay with the first stream in the case of multiple early media stream is propably up to the implementation - or it's time to
>>> specify this behaviour.  Personally I would like to ban sending ring tones with 183 - if they used 180 for ring tones and 183 for other messages a gateway could suspend
>>> the ring tones instead of mixing or just ignoring the second media stream.
>>
>> If you are going to forward all early media from the SIP side (keep in mind that there may be multiple simultaneous early media streams coming from different SIP UASs), you also need to map and forward the SDP information received on each SIP early dialog to the Jingle side.
>>
>> Regards,
>>
>> Christer
>>
>> _______________________________________________
>> stox mailing list
>> stox@ietf.org
>> https://www.ietf.org/mailman/listinfo/stox
>>
>
>