Subject: [Sipping] a question about 3pcc

From: wenkai <[email-masked]>
Date: Fri, 10 Jan 2003 09:14:10 +0800

Hi,
The following is the "Mid-Call Announcement" call flow from "draft-ietf-sipping-3pcc-02.txt". 
After hanging up with the media server, the controller reconnects the Pre-Paid user to the called party. I think the media stream(stream 3) established between Pre-Paid user and the Called Party maybe is not the same as the original media stream(stream 1).
In practice, maybe we want to have the same media codec as original one when we restore a call.
Could you please give the call flow to reach this requirment?

Best Regards
Kevin

     Pre-Paid User        Controller         Called Party        Media Server
          |                   |                   |                   |
          |..........stream 1.....................|                   |
          |                   |(1) INV SDP c=0    |                   |
          |                   |------------------>|                   |
          |                   |(2) 200 answer1    |                   |
          |                   |<------------------|                   |
          |                   |(3) ACK            |                   |
          |                   |------------------>|                   |
          |(4) INV no SDP     |                   |                   |
          |<------------------|                   |                   |
          |(5) 200 offer2     |                   |                   |
          |------------------>|                   |                   |
          |                   |(6) INV offer2     |                   |
          |                   |-------------------------------------->|
          |                   |(7) 200 answer2    |                   |
          |                   |<--------------------------------------|
          |(8) ACK answer2    |                   |                   |
          |<------------------|                   |                   |
          |                   |(9) ACK            |                   |
          |                   |-------------------------------------->|
          |(10) RTP           |                   |                   |
          |..........stream 2.........................................|
          |                   |(11) BYE           |                   |
          |                   |-------------------------------------->|
          |                   |(12) 200 OK        |                   |
          |                   |<--------------------------------------|
          |                   |(13) INV no SDP    |                   |
          |                   |------------------>|                   |
          |                   |(14) 200 offer3    |                   |
          |                   |<------------------|                   |
          |(15) INV offer3'   |                   |                   |
          |<------------------|                   |                   |
          |(16) 200 answer3'  |                   |                   |
          |------------------>|                   |                   |
          |                   |(17) ACK answer3'  |                   |
          |                   |------------------>|                   |
          |(18) ACK           |                   |                   |
          |<------------------|                   |                   |
          |(19) RTP           |                   |                   |
          |..........stream 3.....................|                   |

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Jan 2003 23:16:52 -0500

wenkai wrote:
> After hanging up with the media server, the controller reconnects the 
> Pre-Paid user to the called party. I think the media stream(stream 3) 
> established between Pre-Paid user and the Called Party maybe is not the 
> same as the original media stream(stream 1).

The media is re-established to the caller with an offer/answer exchange.
Everything is done with sequences of offer/answer exchanges. Codec
negotiation is fundamental to this exchange. So, if the called party
decides, when its reconnected to the caller, to all of a sudden expand
its proposed list of codecs (which it may do in offer3), the caller can
pick the one it wants - which can be the one it was using before - in
the answer (answer3).

So, in summary, negotiation is already part of the flow below, and it
would allow the caller to make sure the same codec is used throughout.

-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