In some cases, different INVITEs cause different applications to start at the UAS. The way to differentiate between those INVITEs is sometimes by using the sdp as a clue. For those devices, receiving INVITE with no sdp might cause problems. The UAS needs to guess what application to start.
/Hisham
-----Original Message-----
From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of
ext Cullen Jennings
Sent: 27.February.2004 08:50
To: Ben Campbell; Robert Sparks; Rohan Mahy; Adam Roach
Cc: simple@ietf.org
Subject: [Simple] MSRP & Comedia
This is a half baked idea that I am just tossing out as food
for thought
Consider a systems where something like the UA that sends the
answer sends
the VISIT.
Consider the cases where A want to set up a MSRP session with B.
A is behind a NAT and does not want to use a relay. A sends
an INVITE with
no offer. B sends an offer, gets back an answer and A sends the VISIT.
A -> inv -> B
A <- offer <- B
A -> answer -> B
A -> visit -> B
B is behind a NAT. A sends an offer and B sends an answer and
A sends VISIT.
A -> offer -> B
A <- answer <- B
A <- visit <- B
A and B are behind NATS. A sends INVITE no offer, B knows
relay is needed
and gets one and sends offer.
The underlying principal is basically if you don't know what
port you are
going to receive media at (which is the case with a NAT) you
should not be
making any offers and if you make an offer the assumption is
that the other
side and send media (a VISIT) to that and have it work.
The fundamental thing I am trying to avoid is two vendors
both saying they
have MSRP compliant systems yet still having them fail to be
able to talk to
each other because they both expect the other one to host.
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple