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

From: "Francois Audet" <[email-masked]>
Date: Wed, 18 May 2005 19:01:05 -0400

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 

[Lots of stuff about numbering plan trimmed]

> 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.

I don't think it is that difficult, but I do agree with you that it is 
perhaps not something we need to do at 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.

Yes. The phone-context is mostly useful for Enterprise numbering
plans (i.e., internal phone numbers). They don't have a global
representation if you don't put a phone-context.

I agree that for public numbers, you should use the global representation.

> > 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.

Yes, the From is mostly a configuration issue (which most people do
wrong today).

The To and Request-URI are also important for other reasons, mostly
related to services that rely on the destination numer.

> > 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.

[cutting a bunch of stuff on the benefits of Tel URI vs Tel URI
embedded in sip URI]

I'm not going to debate your points since I agree with them anyways.
I was just saying that we can't MANDATE the Tel URI. The sip URI
format however is already part of plain SIP. 

I do agree that the tel URI is quite useful when you don't care how
your PSTN call is routed.

> >  > >>>       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.)

I agree with the Application Server model with regards to Req-27. The "obey
the last 18X" idea doesn't work with parallel forking which we can't ignore
since it is one of the most useful and distinguishing feature of SIP.

Now that I am re-reading Re-26, I am getting confused about what it is
trying to
say. I was agreeing about the part where 180 means play locally generate
media and ignore other messages, and ignore the rest.

How to deal with multiple conflicting responses (from the point of view
of the originator of the call) is the key. Personally, I don't think that 
picking the last one, or picking the first one, or picking randomly is 
acceptable. I believe that it should have a deterministic behavior, like 
play some locally generated indication instead of inband when you receive 
multiple streams or multiple conflicting responses (like ringing, or even 
a ringing with a different pattern).

I really don't want to get into this same discussion that we had many times
on
this list, but I don't think I can sell a phone or gateway with random
behavior.

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