Paul,
I have a question on the signalling below. The playout from B is
indeterminate so doesn't there need to be some mechanism for B to inform
the Proxy that the playout/digit collection(whatever) has completed so that
the Proxy can terminate this session and INVITE the actual target.
I thought that this could be done using MSCML or other - not only for
notification that the playout had completed but possibly also to inform B
what actually to play and return of digit collection etc. But, shouldn't
INFO messages for carrying such events only be on a completed session ? and
this dialog doesn't get completed.
Regards - Wayne.
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
**********************************************************************
Any personal or sensitive information contained in this email and
attachments must be handled in accordance with the Victorian Information
Privacy Act 2000, the Health Records Act 2001 or the Privacy Act 1988
(Commonwealth), as applicable.
This email, including all attachments, is confidential. If you are not the
intended recipient, you must not disclose, distribute, copy or use the
information contained in this email or attachments. Any confidentiality or
privilege is not waived or lost because this email has been sent to you in
error. If you have received it in error, please let us know by reply
email, delete it from your system and destroy any copies.
**********************************************************************
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
