Subject: Re: [Sipping] Associating SIP sessions with PSTN calls

From: [email-masked]
Date: Mon, 23 Sep 2002 15:09:06 -0400

Isn't  the issue here concerned with 'callee' preferences. In the defining
example in the draft, a user wishes to receive voice calls on his PSTN
device and wishes that the call would travel over the PSTN. It should break
out of any IP network as soon as possible and possibly never travel over
it. At least that is my reading of the draft, although I may be completely
out to lunch here.. It highlights the issue of honouring callee preferences
during call set up. It is the traversal of the PSTN network rather than the
use of the PSTN device which strikes me as something that ii not part of
the current SIP structure

Tom Gray

Jonathan Rosenberg <[email-masked]>@ietf.org on 09/22/2002
10:41:08 PM

Sent by:  [email-masked]

To:   "David R. Oran" <[email-masked]>
cc:   "Michael O'Doherty" <[email-masked]>, "'Alan Johnston'"
      <[email-masked]>, "[email-masked]'"
      <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject:  Re: [Sipping] Associating SIP sessions with PSTN calls

inline.

David R. Oran wrote:
> --On Thursday, September 19, 2002 11:20 AM +0100 Michael O'Doherty
> <[email-masked]> wrote:
>
>>
>> Alan,
>>
>> Couple of comments on this approach:
>>
>> - firstly, I think this would mean that the proxy would have to look at
>> the body to decide what type of call it was handling.
>
> Why, pray tell? What is missing from the SIP headers that is needed?

If the caller expresses a preference expicitly, then yes, the headers
say what is required. For example, if a caller explicitly says "route
this call to a UA that supports video":

Accept-Contact: *;media="video"

The problem that Michael is talking about is where the caller does not
explicitly state this preference; its a normal SIP invite, whose body is
SDP and happens to have a video stream in it. The only way for the proxy
to know this at the moment is to look at the body. In fact, my current
working copy of caller prefs has added support for an implicit
preference for media types by looking at the body. That is, it would
construct the above caller prefs header, and use it as if it were in the
message, if the SDP indicates video. This implicit preference is at MAY
strength because SMIME may make it impossible to do.

It would always be possible to do with my media policy mechanism, by the
way:
http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-00.txt

>
>> I did'nt think
>> proxy's were allowed to do this (although I admit I could'nt see
anything
>> in a quick span of the proxy behaviour scetion of the RFC).
>>
> Some proxies look at bodies. They'd better not depend on it though,
> because once end-to-end SMIME shows up all they'll see is ciphertext.

Yup. Breaks midcom too. Thats why I wrote the above draft.

>
>> - assuming we get around the above point somehow, this solution means
>> that the callee is effectively choosing the point where the call breaks
>> out form the SIP network to the PSTN.
>>
> Not necessarily. All the callee's proxy is deciding is whether the call
> goes to  a contact (or contacts) on the IP network, or to a contact (or
> contacts) on the PSTN. Where the call actually exits to the PSTN is a
> routing issue dealt with by gateway routing protocols like TRIP.

True; but I think Michael's point is that the policy which guides these
routing policies exists within the callee's domain.

If you want the callers domain to make such policy decisions, then you
can redirect rather than proxy.

Generally speaking, It is well within the bounds of a proxy to route a
call to one place or another based on any information it likes. That
includes looking at the bodies, and other such things. A CPL script
could be used to guide this logic, or a servlet, or whatever. The caller
prefs spec will allow a proxy to know the callers preference, and to
know information about registered contacts to help guide its routing
decision.

This, of course, leads to one of the big differences between a SIP-based
approach and an enum-based approach. If the routing decision is made by
a proxy in the callee's domain, the callee (who ultimately cares to
which device the call is routed), can make this decision based on the
time of day, the identity of the caller, or the temperature in Zimbabwe.
Since enum is a directory service, that kind of logic can't be there.
This is what Dave is alluding to when he was referring to enum as a
directory service, not a routing service.

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Sep 2002 18:47:06 -0400

[email-masked] wrote:
> out to lunch here..

I don't know which draft you are referring to.

While a user with a PSTN phone will wish to receive calls from the PSTN, I don't see why he should necessarily be the one to decide when the call breaks out of the IP network. Of course billing is a dirty word, but I would expect that whoever is paying for the call would feel entitled to express the preference over how the call was routed over paths that incur costs.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Sep 2002 02:48:04 -0400

[email-masked] wrote:
> Isn't  the issue here concerned with 'callee' preferences. 

Yes, I believe it is largely an issue of callee preferences.

In the defining
> the current SIP structure

I don't really see anything in the draft that is "not part of the SIP 
structure". We've always supported flexible call routing, which is what 
this is.

-Jonathan R.