Wainwright, John wrote:
According to RFC 3261 section 13.2.1 a UAC must treat the first session
description it receives as the answer and must ignore session descriptions
in subsequent responses to the initial INVITE. Relating this to your answer
below seems to indicate that the initial 183 response completes the first
offer/answer description and when the 'real' call is answered it will result
in a second offer/answer scenario but it will be on a different dialog - due
to the To tag ? - which makes this legal ?
yes
Without the different dialog
info would this scenario be invalid ?
Yes
Consider the following pure proxy forking scenario:
A P B C
| INVITE(sdp1) | | |
|------------------>| INVITE(sdp1) | |
| |------------------>| |
| | 183(sdp2)to-tag=1 | |
| 183(sdp2)to-tag=1 |<------------------| |
|<------------------| | |
| PRACK | | |
|------------------>| PRACK | |
| |------------------>| |
| | 200 PRACK | |
| 200 PRACK |<------------------| |
|<------------------| | |
|<=====================================>| |
| | CANCEL | |
| |------------------>| |
| | 200 CANCEL | |
| |<------------------| |
| | 487 INVITE | |
| |<------------------| |
| | INVITE(sdp1) |
| |------------------------->|
| | 180 to-tag=2 |
| |<-------------------------|
| 180 to-tag=2 | |
|<------------------| |
| | 200 (sdp3) to-tag=2 |
| |<-------------------------|
| 200 (sdp3)to-tag=2| |
|<------------------| |
| ACK | |
|------------------>| |
| | ACK |
| |<-------------------------|
|<============================================>|
A only sent an offer once, but that same offer was then sent to two
different targets, and each sent an answer. A understands this because
the to-tags in the responses containing the answers are different,
indicating different dialogs. At the point where A receives the 200
response to the invite, with to-tag=2, it knows that is unrelated to the
earlier dialog, and that it completes A's call attempt, so that is the
one that A should be using. A doesn't have to cancel the other dialog,
because the proxy does it.
You can replace P with your B2BUA, and B with your media server, and
have the result appear to A just as this call flow.
BUT, I suspect there are many UAs out there that won't do the right ting
with this call flow.
Paul
John
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Monday, May 23, 2005 8:55 AM
To: Wainwright, John
Cc: Dale Worley; [email protected]
Subject: Re: [Sip-implementors] UPDATE or INVITE Replaces.
Wainwright, John wrote:
Paul,
So the UAC establishes the initial dialog with the media server via
the softswitch using the 183 response and then when the softswitch
terminates the 'real' call it will get a new SDP via either a 183 or
200 which it can use for the dialog to the end user ? This avoids the
use of the UPDATE method. Have a read this right ?
Right. THe key to making this legal according to offer/answer is that
the answer for the 'real' call is on a different dialog than the one
with the media server.
It is just as if the call was sequentially forked, first to the media
server, and then to the real device. (And this isn't far from the truth.)
Paul
Thanks
John
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Kyzivat
Sent: Friday, May 20, 2005 5:31 PM
To: Dale Worley
Cc: [email protected]
Subject: Re: [Sip-implementors] UPDATE or INVITE Replaces.
Dale,
Sounds like a pretty natural approach when the box in the middle is a
proxy, which most of us tend to think of as the *right* way. I suspect
that the way this is described, the softswitch wants to be a B2BUA.
ALso, as John said in a later reply, the softswitch interface to the
Media Server might not be sip.
Nevertheless, there is an aspect to what you suggest that can still
work
in this case, that makes things (arguably) simpler:
- the 183 establishes an early dialog with an offer1/answer1
- eventually, the call gets sent somewhere else. The responses
from there establish a *different* dialog. It is the responsibility
of the caller to realize what is going on and abandon the early
dialog when the the new one sends a 2xx response.
So all that the softswitch has to do is ensure that it uses a new
to-tag
for communications relating to the ultimate call after the media server
is done. It can do that by acting as a proxy, or it can simply establish
a 2nd dialog back to the caller from its B2BUA.
Paul
Dale Worley wrote:
From: Wainwright, John
In particular I am thinking about UA-->softswitch-->Media Server
sequence which plays an announcement/collect a new DN from the UA
forwards this
info
to the softswitch ( in an application specific way ) who then sends
out an INVITE to the collected DN and UPDATES the initial UA with this
dialog information in order to connect the call. The initial UA would
be in an early media type state in effect waiting for the UPDATE from
the
softswitch.
That sequence seems excessively heavy-weight. What seems easier to me
is this sequence:
1. INVITE from UA to Softswitch.
2. INVITE from Softswitch to Media Server.
3. Media Server sends 183 back to UA to set up early dialog.
4. User sends information, Media Server collects and processes it to
determine required action.
5. Media Server sends 302 response to Softswitch, with:
Contact:
<where-ever-call-should-be-forwarded-to>;var=data;var=data;var=data
Where the "var=data" items are various bits of information provided to
the Softswitch by the Media Server.
6. Softswitch processes the "var=data" items, and forwards the INVITE
to the correct destination.
7. UA is ultimately connected to the destination, which establishes
media with the UA.
There doesn't seem to be any need to send an UPDATE, as long as the
Media Server is willing to retry the 183 a few times to allow for its
unreliability.
Dale
_______________________________________________
Sip-implementors mailing list [email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list [email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
