Subject: Re: I-D Action: SIP Call Flows and Service Examples

From: Alan Johnston <[email-masked]>
Date: Tue, 02 Nov 1999 14:57:59 -0600

See my notes below.

Rick Workman wrote:
> 
> Alan Johnston wrote:
> 
> > We were reluctant to include the tel URL in this draft since it was still in I-D
> > status, and using sip URLs worked, if not as elegantly.  By the time we make the
> > next revision, it should be an RFC and we will probably change the sip URLs to
> > tels.  We attempted to use sip URLs as #@proxy rather than #@gateway, but we ran
> > into problems populating From headers on incoming calls from the PSTN.  The tel
> > URL will probably solve these issues.
> >
> 
> Just to clarify my position,  I think it makes sense to use SIP URL's in the From headers in
> INVITEs originating from gateways (or any SIP UA for that matter). In the context of that SIP
> session, the From host is the gateway so there's no problem in using #@gateway there, and
> allows the inclusion of tag fields and calling name if necessary. However, the only
> information the gateway has about the destination endpoint is just the dialled digits, so
> "manufacturing" a To host in the gateway is problematical. It's less of a problem for the
> RequestURIs since proxies can change those in course of routing the request, but I see no
> reason why the tel: URL shouldn't optionally be used there as well. This does require that
> proxies support this but this seems fairly fundamental to PSTN interworking (but not really
> an issue if you're not worried about the PSTN).
> 
> > I hope that once the tel URL reaches RFC status, the telephone number handling
> > in sip URLs is again matched to the tel URL.
> >
> 
> I'm not sure why the use of the tel: URL in it's I-D form isn't the same as using the
> proposed 183 response, which arguably is in a less mature state. I guess this depends
> somewhat on  the intent of publishing your call flow draft. As a discussion paper, I think
> it's a valuable and appreciated contibution to the SIP community. If it's intended that it
> evolve to RFC status as a standard for SIP network operation then I think we have to be more
> careful. For example, are the assumptions stated in the first section intended to be
> requirements. If so, what should happen if the assumptions are violated even though the SIP
> protocol usage is valid.

We included the 183 Session Progress response because there was no alternative -
without this response or a suitable header indicating early media, certain IP
Telephony calls will simply fail.  The use of SIP URLs for telephone numbers
does work (if not very elegantly as you and others have pointed out) and is
consistent with the RFC.

As to the document's future status, that is up to the group.  I see it always
remaining as an Informational document, never becoming a standard.  The document
began its life as a "current state" of SIP IP Telephony.  Future versions will
be more forward looking.

Finally, as for the assumptions made, we can discuss them - they are not
intended to be requirements.  Perhaps a section discussing alternative
assumptions and the changes this would entail in the call flows would be useful.

Again, thanks for all your input.

Alan Johnston
MCI WorldCom
+1-314-342-7360
[email-masked]