Re: [MMUSIC] Notes from Orlando human language draft discussion

Randall Gellens <> Sat, 16 March 2013 21:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6528821F867B for <>; Sat, 16 Mar 2013 14:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7XMxdiEY+xqe for <>; Sat, 16 Mar 2013 14:55:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1C05A21F867A for <>; Sat, 16 Mar 2013 14:55:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1363470916; x=1395006916; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=+qDZf2m0Zc/bS0uythbbBuHeBWs+Vjfg3houmE9tdx8=; b=K/INVjN4YDujxz8TX2QJpf/fH4lrix6uLca9UMs48QgDF/M9gqv3uCbj /lmzE0TfR1L+5mxEzKjcaaLjyUhS82l0MVaTMsBCw1PsQHBasUPMCx0XY 6yFqhLySsGxaw+gRkFLlIYh7PxY4GIToyaPh0xyCic9DZydnHr2Zz776Q M=;
X-IronPort-AV: E=Sophos;i="4.84,857,1355126400"; d="scan'208";a="30336300"
Received: from ([]) by with ESMTP; 16 Mar 2013 14:55:16 -0700
X-IronPort-AV: E=Sophos;i="4.84,857,1355126400"; d="scan'208";a="506283920"
Received: from ([]) by with ESMTP/TLS/RC4-SHA; 16 Mar 2013 14:55:16 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 16 Mar 2013 14:55:15 -0700
Message-ID: <>
In-Reply-To: <>
References: <> <>
X-Mailer: Eudora for Mac OS X
Date: Sat, 16 Mar 2013 14:54:46 -0700
To: Hadriel Kaplan <>
From: Randall Gellens <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: []
Cc: Randall Gellens <>, "<>" <>, "<>" <>
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Mar 2013 21:55:18 -0000

At 7:54 PM +0000 3/16/13, Hadriel Kaplan wrote:

>  On Mar 15, 2013, at 2:49 PM, Randall Gellens <> wrote:
>>  SDP or SIP:
>>  - Use SDP for actual negotiation, but use SIP header to provide a hint
>>  - Emergency services use case can use SDP for policy 
>> routing/handling decisions
>>  - Other use cases may or may not have ability/desire to use SDP 
>> for this and can use the SIP header hint
>  Another reason not to only put it in SDP is the delayed-offer scenario.
>>  Directionality of SDP attributes:
>>  - Define two new SDP media-level attributes: 'send-lang' and 
>> 'recv-lang'.  In an offer, send-lang is a list in preference order 
>> of the languages the offerer wishes to send and recv-lang is a 
>> list in preference order of the languages the offerer wishes to 
>> receive.  In most cases these are expected to have the same value, 
>> because otherwise it is harder to match desired resources.  In an 
>> answer, send-lang is the accepted language the answerer will send 
>> (which in most cases should be one of the languages in the offer's 
>> recv-lang) and recv-lang is the accepted language the answerer 
>> expects to receive (which in most cases should be one of the 
>> languages in the offer's send-lang).
>  What's the use-case when the two directions are not identical? 
> I.e., when does it make sense to receive Latin but send Swahili for 
> the same media?
>  I ask because this separation complicates things quite a bit in 
> code/testing/error-handling, obviously.

I'll let Harald speak to this as he was pretty insistent that it was 
a misuse of SDP (if I understood him) to use the same attribute for 
sending and receiving.

>   > Advisory vs Required:
>>  - Does call fail if no common language?
>  I haven't thought about this draft's scenarios much, but think we 
> need to think about this very carefully.  Otherwise the outcome 
> would be SBCs would strip it from the INVITE, just to avoid failing 
> the call.  I don't think anyone would actually want such calls to 
> truly fail for the end user - not just for Emergency calls, but for 
> any calls - people can always hang up if they don't like what they 
> hear/see.  ISTM that there's a high likelihood of this language 
> value actually being *wrong* in either the sender or receiver or 
> both, so I think failing the call because of a mismatch would be 
> really bad.
>  At first glance, I can see one and only one reason failing it would 
> make sense: for a serial-forking proxy/B2BUA/UA to be able to 
> recurse to alternate targets if the first one didn't support the 
> language(s).  But it has a very negative drawback: if there are no 
> more targets it can recurse to, or if there were no such forking to 
> begin with, the call fails.  Then we're back to square one above, 
> and the thing gets removed from all calls by middleboxes, just to 
> avoid such cases.

The result of the discussion is to add a token for the caller to 
indicate a preference for the language being mandatory or advisory, 
but the callee is not required to honor this preference.  I can 
imagine scenarios where failing the call might be preferred, such as 
a caller who will call an alternate party if the required language 
isn't supported.

>  -hadriel
>  p.s. was this presented in MMUSIC this past week?  For some reason 
> this topic was neither on the MMUSIC agenda pages 
> (, nor 
> in the meeting materials 
> (, nor is 
> the draft on the MMUSIC tools page 
> (  I only mention this because I 
> was looking for the slides and draft today and didn't find them.

No, this is my fault.

Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
An economist is an expert who will know tomorrow why the things he
predicted yesterday didn't happen today.       --Laurence J. Peter