Re: [Sipping] Re: draft-sinnreich-sipdev-req-06.txt

[Paul Kyzivat <[e-mail]>]

Christian Stredicke wrote:
> About the dial plan discussion: Friends, please lets not forget this is
> just a requirement. In this document we cannot nail down the details.
> Lets just mention that the phone (*if* it support a dial plan) is able
> to generate all kinds of URI. Practically, that will be done by
> generating text with some ERE-matching scheme (see for an example
> http://snom.com/whitepapers/FAQ-04-03-27-cs.pdf). But we don't have to
> solve this problem here in this document.

Yes, one can get carried away, and I don't want to do that.
OTOH, when trying to turn requirements into standards it is not unusual 
to have someone say "why do you specify XYZ when there is no requirement 
justifying that?"

Maybe some examples of the kinds of transformations that should be 
possible would be better. E.g. dialed digits "5551234", based on 
different configs should be able to end up as:

   tel:[phone]
   sip:[e-mail];user=phone
   sips:[e-mail];user=phone
   sip:[e-mail]
   sips:[e-mail]
   tel:[phone];phone-context=nyc1.example.net
   sip:5551234;phone-context=nyc1.example.net
            @example.net;user=phone
   sips:5551234;phone-context=nyc1.example.net
            @example.net;user=phone
   sip:5551234;phone-context=nyc1.example.net
            @example.net;user=dialstring
   sips:5551234;phone-context=nyc1.example.net
            @example.net;user=dialstring
   tel:[phone];phone-context=+1212
   sip:5551234;phone-context=+1212
            @example.net;user=phone
   sips:5551234;phone-context=+1212
            @example.net;user=phone
   sip:5551234;phone-context=+1212
            @example.net;user=dialstring
   sips:5551234;phone-context=+1212
            @example.net;user=dialstring

In the simplest devices there may be only one transformation for all 
dial strings, while for smarter devices the transformation may be a 
function of the digits dialed, but the same range of possibilities 
should be there in all cases.

Paul

> CS
> 
> 
>>-----Original Message-----
>>From: Paul Kyzivat [mailto:[e-mail]] 
>>Sent: Wednesday, May 18, 2005 4:32 PM
>>To: Francois Audet
>>Cc: Christian Stredicke; 'Johnston, Alan'; [e-mail]
>>Subject: Re: [Sipping] Re: draft-sinnreich-sipdev-req-06.txt
>>
>>Trimmed a lot out. Comments inline.
>>
>>	Paul
>>
>>Francois Audet wrote:
>>
>>
>>>We need something that says something like.
>>>
>>>Prefix X ---> phone-context=blablaba
>>>
>>>Prefix Y  ----> phone-context=someotherstring
>>>
>>>Typically you will need 3 prefixes in Enterprises:
>>>
>>>An "internal" call prefix (i.e., mapping to some phone-context 
>>>denoting an enterprise numbering plan). E.g., a "6" prefix.
>>>
>>>An "external" call prefix (i.e., mapping to E.164). E.g., a 
>>
>>"9". Means 
>>
>>>the local country code (and maybe area code) of the device 
>>
>>needs to be 
>>
>>>added.
>>>
>>>And probably another one for international. E.g., a "9011".
>>>
>>>Also, in Enterprises, you would normally need another phone for 4-5 
>>>digit dialling.
>>>
>>>Dial string lengh smaller than Z digits -----> 
>>>phone-context=yetanotherstring
>>>
>>>This stuff is quite important to deploy SIP in 
>>
>>multinational organizations.
>>
>>>It is somewhat easier for a Public network access scenario.
>>
>>I was suggesting something simpler and more generic that 
>>could be configured to produce results such as you are 
>>suggesting if that is desired.
>>
>>Deciding what particular mappings are appropriate for 
>>converting dial strings into URIs is a much bigger deal. I 
>>suspect it may be too hard to attempt to achieve agreement at 
>>the IETF.
>>
>>Regarding your suggestion for several contexts above, 
>>consider the following from 3966:
>>
>>    The 'telephone-subscriber' part of the URI indicates the 
>>number.  The
>>    phone number can be represented in either global (E.164) or local
>>    notation.  All phone numbers MUST use the global form unless they
>>    cannot be represented as such.  Numbers from private 
>>numbering plans,
>>    emergency ("911", "112"), and some directory-assistance numbers
>>    (e.g., "411") and other "service codes" (numbers of the 
>>form N11 in
>>    the United States) cannot be represented in global 
>>(E.164) form and
>>    need to be represented as a local number with a context.  Local
>>    numbers MUST be tagged with a 'phone-context' (section 5.1.5).
>>
>>Especially note: "All phone numbers MUST use the global form 
>>unless they cannot be represented as such." This seems to 
>>rule out using different phone contexts simply based on how a 
>>number is dialed.
>>
>>
>>> > >>The outgoing proxy will presumably have requirements 
>>
>>for how URIs  
>>
>>>>>>containing phone numbers are formed. There need to be enough  > 
>>>>>
>>>>>requirements so that the phone can be configured to work 
>>>>
>>with the  > 
>>
>>>>proxy.
>>>
>>> > >
>>> > > But I am afraid the discussion did not result in a  > 
>>
>>consensus 
>>
>>>that goes  > > that far. Some people think that it is the 
>>
>>proxy's job 
>>
>>>to clean the  > > URI up. Therefore we cannot mandate such 
>>
>>a behavior 
>>
>>>in this  > document.
>>> >
>>> > Well, maybe I can't fight mother nature. But even if you 
>>
>>expect the  
>>
>>>>proxy to fix it, you need to give the proxy enough data 
>>>
>>to work with.
>>
>>> >
>>> > And there are things a proxy isn't supposed to fix. The  
>>>poster 
>>>child for  > this is a blind transfer where the transfer target is 
>>>dialed by the  > device initiating the transfer. This could 
>>
>>result in 
>>
>>>something like:
>>> >
>>> >       REFER sip:[e-mail]
>>> >       To: sip:[e-mail]
>>> >       From: sip:[e-mail]
>>> >       Refer-To: sip:[e-mail]
>>> >       Route: sip:atlanta.com;lr
>>> >       ...
>>> >
>>> > If atlanta.com is a *proxy* it isn't supposed to mess 
>>
>>with  > the 
>>
>>>Refer-To  > header. If it doesn't, then this will result in:
>>> >
>>> >       INVITE sip:[e-mail]
>>> >       To: sip:[e-mail]
>>> >       From: sip:[e-mail]
>>> >       Route: sip:biloxi.com;lr
>>> >       ...
>>> >
>>> > At that point the fact that this call was dialed by alice has  > 
>>>been lost  > from the message. Biloxy.com can't fix it, and 
>>>atlanta.com can fix it  > only if all users of atlanta.com have the 
>>>same digit map.
>>> >
>>> > OTOH, if the original request had been:
>>> >
>>> >       REFER sip:[e-mail]
>>> >       To: sip:[e-mail]
>>> >       From: sip:[e-mail]
>>> >       Refer-To: sip:4321;phone=context=plan12.atlanta.com
>>> >               @atlanta.com;user=dialstring
>>> >       Route: sip:atlanta.com;lr
>>> >       ...
>>> >
>>> > Then the request would get back to atlanta.com in a form 
>>
>>that  > it 
>>
>>>would  > know how to fix it.
>>> >
>>> > Otherwise, if you force atlanta.com to "fix" the Refer-To, you 
>>>either  > require it to be a non-conforming proxy, or else 
>>
>>require it 
>>
>>>to be a  > B2BUA/SBC. I don't think we want that.
>>>
>>>The To and From field containing a "dial string" is also an 
>>
>>issue. How 
>>
>>>is a gateway in England supposed to deal with some dialstring with 
>>>bogus north american prefixes (like 9011) that it can't possibly 
>>>understand.
>>
>>Yes. From is an issue for callerid and callback. Luckily a 
>>phone typically is provisioned with its From address rather 
>>than receiving it as a dial string. "To" is somewhat less of 
>>a problem because there just isn't a lot of use of it.
>>
>>
>>>This is why it is important to get the phone-context well populated.
>>>
>>>
>>> > >>>       Req-18: SIP telephony devices MUST support the URIs for
>>> > >>>               Telephone numbers as per RFC 3966 [9].
>>> > >>
>>> > >>What is meant by "support"? Which headers should TEL 
>>
>>be accepted 
>>
>>>in,  > > and  > >>which should it be capable of generating 
>>
>>TEL in. In 
>>
>>>case of  > > generation,  > >>how is use of TEL vs SIP specified?
>>> > >
>>> > > We are just referring to RFC3966. That can't be a mistake.
>>> >
>>> > Referring to 3966 isn't a mistake. But 3966 says nothing 
>>
>> > about 
>>
>>>where it  > is used. *Maybe* this is sufficient to make it clear a 
>>>device  > must not  > fail if it receives a message with 
>>
>>one of these 
>>
>>>any place  > 3261 says it  > may be. But it is not a 
>>
>>requirement that 
>>
>>>the device be able  > to generate  > TEL URIs in the messages it 
>>>sends. Is ability to receive all you are  > after? If so, than I 
>>>withdraw my objection.
>>>
>>>I don't think mandating tel URI is the right thing to do. We should 
>>>mandate the tel-URI inside SIP as per RFC 3261/19.1.6 instead.
>>
>>While there are places where the sip form of the tel uri is 
>>needed, the tel form also has advantages. This is especially 
>>so in To, From, P-Asserted-Identity, and perhaps Refer-To.
>>
>>One advantage is that if it is used to initiate a call, the 
>>initiator is then much less constrained in how the call is 
>>initiated. For instance,
>>consider:
>>
>>1)	REFER sip:[e-mail]
>>	To: sip:[e-mail]
>>	From: sip:[e-mail]
>>	Refer-To: tel:+1=212-555-1234
>>vs.
>>2)	REFER sip:[e-mail]
>>	To: sip:[e-mail]
>>	From: sip:[e-mail]
>>	Refer-To: sip:+1=[e-mail];user=phone
>>
>>In (1), bob is free to send the call to a local gateway known 
>>to biloxi.com, or to look the number up in ENUM and route 
>>based on the results. In (2), bob is required to send the 
>>call via sip to atlanta.com.
>>
>>It may be that alice *wants* to constrain how bob makes the 
>>call. If so the sip form is desirable. But if not, then the 
>>tel form may be preferred.
>>
>>Another advantage is giving the recipient more freedom in how 
>>to display the number. Consider
>>
>>3)	INVITE sip:[e-mail]
>>	To: sip:[e-mail]
>>	From: tel:+1=212-555-1234
>>vs
>>4)	INVITE sip:[e-mail]
>>	To: sip:[e-mail]
>>	From: sip:+1=[e-mail];user=phone
>>
>>Assume bob's phone is using the From header as the source of 
>>caller id information to display about the incoming call.
>>
>>In (3) bob's phone can recognize this as a phone number and 
>>simply display it as such, just as it would for a call from the PSTN.
>>
>>But in (4), bob's phone sees a sip uri that it is not 
>>supposed to interpret. It SHOULD NOT simply strip out and 
>>display the digits. It SHOULD, if it displays anything at 
>>all, probably just display the entire URI. This is not nearly 
>>as user friendly.
>>
>>But this discussion is probably off topic and should be 
>>continued elsewhere, if at all. The point is that telephony 
>>devices should be able to deal with tel URIs.
>>
>>
>>> > >>>       Req-26: SIP telephony devices MUST generate local
>>> > ringing and
>>> > >>>               SHOULD ignore any early RTP media when a "180
>>> > > Ringing"
>>> > >>>               response is received. Any received media
>>> > that is not
>>> > >>>               early media (i.e., not received within the
>>> > context of
>>> > > an
>>> > >>>               early session, as specified in [71] should be
>>> > > rendered
>>> > >>>               as soon as it arrives in order to avoid speech
>>> > > clipping.
>>> > >>>               SIP telephony devices MUST play the 
>>
>>RTP stream for
>>
>>> > > the
>>> > >>>               established dialog and ignore any 
>>
>>other RTP media
>>
>>> > >>>               streams when a "183 Session Progress" 
>>
>>response is
>>
>>> > >>>               received.
>>>
>>>I really strongly AGREE with this requirement. Otherwise 
>>
>>you get into 
>>
>>>forking hell with early media.
>>>
>>> > >>>       Req-27: SIP telephony devices SHOULD obey the last 18x
>>> > > message
>>> > >>>               received when multiple 18x responses are
>>> > received. If
>>> > >>>               the last response is "180 Ringing", 
>>
>>the client MUST
>>
>>> > >>>               generate local ringing. If the last
>>> > response is "183
>>> > >>>               Session Progress", the client MUST play the RTP
>>> > > stream.
>>> > >
>>> > >>This is contrary to recommendations in RFC 3960.  I 
>>
>>think  > this 
>>
>>>should  > >>say that a SIP telephony device, when acting as 
>>
>>a UAC,  > 
>>
>>>SHOULD support  > >>the gateway model of RFC 3960, and that when 
>>>acting as a  > UAS it SHOULD  > >>NOT send early media.
>>> > >
>>> > > You are probably right that is it would be smart to 
>>
>>refer  > to 
>>
>>>the work  > > on early media.
>>>
>>>I agree on that as well.
>>
>>Francois - you can't agree with both! (They are inconsistent.)
>>
>>
>>
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP