Subject: Re: [Simple]How does MSRP support NAT traversal?

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 08 Jun 2006 16:41:54 -0400

>>document should be applied to the presentity URI sip:[email-masked]
> 
> as
> 
>>well. Consequently, a SUBSCRIBE request for sip:[email-masked] would
>>return a presence document whose entity attribute is
> 
> sip:[email-masked].
> 
> I guess there is typo - it should say:
> ...applied to the presentity URI pres:[email-masked] as well...
> Am I right?

Yes, sorry.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 08 Jun 2006 16:41:54 -0400

I agree it could work. I recall even proposing this eons ago. With TURN 
and ICE tcp usage maturing it probably is much more viable these days 
than when msrp-relays started.

That said, there are going to be some differences. First and foremost is 
that with TURN, if you have two domains each of which deploy TURN 
servers, and you end up in a trapezoid configuration, you'll end up with 
a separate tcp connection set up between the two TURN servers for each 
MSRP session. I believe with MSRP the number of connections between 
servers would just be two.

Also, as Cullen is alluding to, TLS will work differently. With the 
latest TURN each client can have a TLS connection between itself and its 
own TURN server. However, inter-server TLS won't happen. Rather, you'd 
end up with TLS from one client to the other. Whether p2p TLS is a 
feature or a bug may depend on what you're trying to do, but with TURN 
relays it'll be p2p.

There are probably other differences too, but thats what comes to mind.

Thanks,
Jonathan R.

Cullen Jennings wrote:

> 
> I can imagine that it might be possible to set up a MSRP session over  
> TURN or over STUNT. I've not checked the details of this being  possible 
> but seems like it might work. Keep in mind TLS won't work  very well 
> with TURN.
> 
> On May 24, 2006, at 11:29 AM, <[email-masked]>  
> <[email-masked]> wrote:
> 
>> Hi,
>>
>>> -----Original Message-----
>>> From: ext Marc Petit-Huguenin [mailto:[email-masked]]
>>> Sent: 24 May, 2006 21:02
>>> To: Rohan Mahy
>>> Cc: Cullen Jennings; Paul Kyzivat; simple
>>> Subject: Re: [Simple]How does MSRP support NAT traversal?
>>>
>>> Rohan Mahy wrote:
>>>
>>>> Hi Marc,
>>>>
>>>> It was specifically a non-goal of MSRP to use a TURN server for MSRP
>>>> traffic.
>>>
>>>
>>> I understand, but what technically prevent doing NAT traversal
>>> for MSRP with a TCP TURN server?
>>>
>>
>> Good question, I have been wondering the same. If TURN relays start  
>> to be available (I hope they do, although I haven't heard about  such 
>> a thing), it would make sense to run MSRP through TURN instead  of 
>> introducing separate MSRP specific relays. There may be other  reasons 
>> to use MSRP relays, but the pure NAT traversal should be  based on 
>> something more generic.
>>
>> Regards,
>>     Markus
>>
>> ----------------------------
>> Markus Isomäki
>> [email-masked]
>> ----------------------------
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 08 Jun 2006 16:41:54 -0400

this is not presence at all, but rather is other type of state that is 
useful for composing presence. Consequently, I'd suggest defining a new 
event package to appropriately represent this information.

This concept - of using data from other event packages (or non-SIP 
sources as the case may be) to derive presence states - is one of the 
things that needs to be described in presence-processing-model IMHO.

Thanks,
Jonathan R.

Paul Kyzivat wrote:

> I may be missing how this is supposed to be used.
> 
> - Does the car know who (which presentities) are present within, so that 
> it can report presence status about them?
> 
> - or does some independent element associated with a known presentity 
> query the attributes of the car and then report that as presence status 
> of the associated presentity? (E.g. when I use the car I dock my cell 
> phone. It then picks up and reports the car status as part of my presence.)
> 
> - or is there a unique presentity associated with the car, regardless of 
> who is within? (This would seem to be the case with OnStar.)
> 
>     Paul
> 
> Henning Schulzrinne wrote:
> 
>> [Chiming in since Vishal's project is in my lab.]
>>
>> On May 31, 2006, at 7:01 PM, Rohan Mahy wrote:
>>
>>> Hi Vishal,
>>>
>>> I'm assuming that the vehicle is a tuple for a human presentity--that
>>> the car doesn't have its own resource/presentity name.
>>>
>>
>> Indeed; it's used as an adjunct to a person (in our case repair 
>> technicians in a truck).
>>
>> The basic question is whether this should be treated as:
>>
>> - person-associated information (under <person>)
>> - a <device> (although it is not necessarily a communication device)
>>
>> Maybe a combination would be best, depending on the nature of the 
>> information.
>>
>>> I don't think ignition is really orthogonal to movement status.  I
>>> think you want a rich presence indicator of movement within the tuple
>>> representing the vehicle.  The lock status might be relevant here as
>>> well.  What you are probably trying to determine is 1) a state of
>>> occupancy, and 2) a state of distraction. Keep in mind that many
>>> hybrids don't require use of an ignition switch.  I think these work
>>> for automobiles and trucks, but not for other types of vehicles:
>>>
>>> - parked locked (vehicle off)
>>> - parked unlocked (vehicle off)
>>> - standing (vehicle ready - idling/enabled)
>>> - stopped (vehicle not moving, but in a driving "gear")
>>> - under-way (vehicle in motion)
>>>
>>> You probably don't want fuel status.  Projected range is probably more
>>> interesting.  1 liter of fuel in a Prius vs. 1 liter in a Hummer makes
>>> a big difference in range.
>>
>>
>> It's just a lot harder to estimate this. I think at least for 
>> published information, having raw information seems more useful, maybe 
>> along with information about the vehicle type. (I'm actually not quite 
>> sure what this information might be used for, but maybe it is useful 
>> for OnStar-style systems if a guy with a gas canister needs to be 
>> dispatched.)
>>
>>>
>>> The car stereo is often an interesting contributor to presence.  Some
>>> cars even allow you to turn on the stereo with the ignition off. As a
>>> student I used to sit in my car while studying, because the stereo was
>>> better there.  Be aware that many car stereos are easily heard (and
>>> listened to) outside the vehicle.
>>
>>
>> There are IM/presence systems that display what song you're currently 
>> listening to.
>>
>>>
>>> Finally, if one or more of the seat belts are on this is probably a
>>> pretty reliable indicator of the presence of a human.  Unfortunately,
>>> not having seat belts on is not a reliable indicator that there are
>>> *not* humans in the car.
>>
>>
>> Most modern cars have weight sensors at least in their front seats, to 
>> tune the behavior of air bags. While absence of passengers in the 
>> front seat does not indicate an empty car, it might indicate a 
>> situation where the occupants are looking for privacy.
>>
>> It would be interestingvement status, and so on. I would assert that 
this is not presence at all, but rather is other type of state that is 
useful for composing presence. Consequently, I'd suggest defining a new 
event package to appropriately represent this information.

This concept - of using data from other event packages (or non-SIP 
sources as the case may be) to derive presence states - is one of the 
things that needs to be described in presence-processing-model IMHO.

Thanks,
Jonathan R.

Paul Kyzivat wrote:

> I may be missing how this is supposed to be used.
> 
> - Does the car know who (which presentities) are present within, so that 
> it can report presence status about them?
> 
> - or does some independent element associated with a known presentity 
> query the attributes of the car and then report that as presence status 
> of the associated presentity? (E.g. when I use the car I dock my cell 
> phone. It then picks up and reports the car status as part of my presence.)
> 
> - or is there a unique presentity associated with the car, regardless of 
> who is within? (This would seem to be the case with OnStar.)
> 
>     Paul
> 
> Henning Schulzrinne wrote:
> 
>> [Chiming in since Vishal's project is in my lab.]
>>
>> On May 31, 2006, at 7:01 PM, Rohan Mahy wrote:
>>
>>> Hi Vishal,
>>>
>>> I'm assuming that the vehicle is a tuple for a human presentity--that
>>> the car doesn't have its own resource/presentity name.
>>>
>>
>> Indeed; it's used as an adjunct to a person (in our case repair 
>> technicians in a truck).
>>
>> The basic question is whether this should be treated as:
>>
>> - person-associated information (under <person>)
>> - a <device> (although it is not necessarily a communication device)
>>
>> Maybe a combination would be best, depending on the nature of the 
>> information.
>>
>>> I don't think ignition is really orthogonal to movement status.  I
>>> think you want a rich presence indicator of movement within the tuple
>>> representing the vehicle.  The lock status might be relevant here as
>>> well.  What you are probably trying to determine is 1) a state of
>>> occupancy, and 2) a state of distraction. Keep in mind that many
>>> hybrids don't require use of an ignition switch.  I think these work
>>> for automobiles and trucks, but not for other types of vehicles:
>>>
>>> - parked locked (vehicle off)
>>> - parked unlocked (vehicle off)
>>> - standing (vehicle ready - idling/enabled)
>>> - stopped (vehicle not moving, but in a driving "gear")
>>> - under-way (vehicle in motion)
>>>
>>> You probably don't want fuel status.  Projected range is probably more
>>> interesting.  1 liter of fuel in a Prius vs. 1 liter in a Hummer makes
>>> a big difference in range.
>>
>>
>> It's just a lot harder to estimate this. I think at least for 
>> published information, having raw information seems more useful, maybe 
>> along with information about the vehicle type. (I'm actually not quite 
>> sure what this information might be used for, but maybe it is useful 
>> for OnStar-style systems if a guy with a gas canister needs to be 
>> dispatched.)
>>
>>>
>>> The car stereo is often an interesting contributor to presence.  Some
>>> cars even allow you to turn on the stereo with the ignition off. As a
>>> student I used to sit in my car while studying, because the stereo was
>>> better there.  Be aware that many car stereos are easily heard (and
>>> listened to) outside the vehicle.
>>
>>
>> There are IM/presence systems that display what song you're currently 
>> listening to.
>>
>>>
>>> Finally, if one or more of the seat belts are on this is probably a
>>> pretty reliable indicator of the presence of a human.  Unfortunately,
>>> not having seat belts on is not a reliable indicator that there are
>>> *not* humans in the car.
>>
>>
>> Most modern cars have weight sensors at least in their front seats, to 
>> tune the behavior of air bags. While absence of passengers in the 
>> front seat does not indicate an empty car, it might indicate a 
>> situation where the occupants are looking for privacy.
>>
>> It would be [email-masked]?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Thanks,
Jonathan R.