Subject: RE: [SIP] Media & Signaling inter-dependencies, issue with 183 ?

From: "Arnoud van Wijk (ETM)" <[email-masked]>
Date: Fri, 18 Aug 2000 12:54:03 +0200

Jonathan..
thou art the master! :-)

I am seriously looking at SIP and charging. I think that your proposed idea for method #3 looks quite doable.
This will only work if this header is mandatory..else the SIP proxy has no idea WHEN to start the charging timer.
Maybe a good idea to have this header X-Media (maybe call it Charging-Flag?)
This would then look like:

Charging-Flag = "Charging-Flag" ":" flag
flag = "off"|"standby"|"on"
Session timer timeout or a BYE/CANCEL will indicate end of session and thus end of charging.

An advantage is that it is possible at a later time to give the option NOT to charge for a session (flag = "off").
This will enable flatrate or free calling for certain sessions..like text only sessions for deaf callers (after all..text is not really that resource hungry compared to video and speech).

My 2 Euro cents.
  
Arnoud

_______________________________________________________________
ERICSSON TELECOMMUNICATIE BV
Arnoud van Wijk
ABACUS Lab
Research & Development
Fax: +31-161 247569
_______________________________________________________________

-----Original Message-----
From: Marc Petit-Huguenin [mailto:[email-masked]]
Sent: Thursday, August 17, 2000 4:31 PM
To: Jonathan Rosenberg
Cc: [email-masked]
Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183
?

Jonathan Rosenberg wrote:
> 
> This is a really good issue. Thanks for bringing it up.
> 
> Seems like there are really just three possibilities:
> 
> 1. punt this problem; you can't change the parameters before the call is
> setup
> 2. allow reinvites before the 200 OK to change the parameters
> 3. don't allow early media - send a 200 OK for this instead
> 
> None of these are ideal. (2) worries me, as it introduces additional
> complexity which I fear will have interactions with other things. (3) is
> somewhat appealing, allowing us to return to the simpler model SIP
> orginally had. However, people claimed this had nasty interactions with
> billing systems and PSTN interworking. I wonder if we can't revisit this
> and see if those issues could be resolved some other way?
> 
> -Jonathan R.

In my understanding of SIP, this issue is not really related to 183
messages. The end of section 4.2.1 states that "A UAC MUST be prepared
to receive media data according to the session description as soon as it
sends an INVITE...". I cannot find a symmetrical sentence for UAS in the
draft, something like "A UAS MAY send media data according to the
session description as soon it receives an INVITE...". If this is true,
then the caller can receive data media without receiving a SDP (which
will may be used for sending media data). 

(1) works, we have just to discard data media received if the UAC is in
hold state (and the UAC can use another RTP port pair to establish
another call). But what if the INVITE is forked - In this case we can
receive multiple data media on the same port.

I agree that (2) complicates things.

For (3), perhaps we can change the 4.2.1 section to state that media
data can be send (and receive) only when a 200 OK is receive (send),
forbidding SDP on provisional responses and adding a header to signal
the "billed" part of the call, so we can imagine the following call
flow:

 UAC                       UAS                       PSTN
  |     INVITE F1           |                         |
  |------------------------>|           SETUP         |
  |                         |------------------------>|
  |     100 Trying F2       |                         |
  |<------------------------|     CALL PROCEEDING     |
  |                         |<------------------------|
  |                         |    ALERT OR PROGRESS    |
  |                         |<------------------------|
  |     200 OK F3           |                         |
  |<------------------------|                         |
  |     ACK F4              |                         |
  |------------------------>|                         |
  |                         |        CONNECT          |
  |                         |<------------------------|
  |     INVITE F5           |                         |
  |<------------------------|      CONNECT ACK        |
  |                         |------------------------>|
  |     200 OK F6           |                         |
  |------------------------>|                         |
  |     ACK F7              |                         |
  |<------------------------|                         |
 
  Message details 

   F1 INVITE 

   INVITE sip:[email-masked] SIP/2.0
   Content-Type: application/sdp
   To: sip:[email-masked]
   From: Anonymous <sip:[email-masked]>
   Via: SIP/2.0/UDP 207.82.37.67
   Content-Length: 116
   Call-ID: [email-masked]
   CSeq: 965506497 INVITE
   Supported: com.netergynet.media

   v=0
   o=- 967711854878 967711854878 IN IP4 207.82.37.67
   s=-
   c=IN IP4 207.82.37.226
   t=0 0
   m=audio 8000 RTP/AVP 0

   F2 100 Trying 

   SIP/2.0 100 Trying
   Via: SIP/2.0/UDP 207.82.37.67
   From: Anonymous <sip:[email-masked]>
   To: sip:[email-masked]
   Call-ID: [email-masked]
   CSeq: 965506497 INVITE
   Content-Length: 0
   Supported: com.netergynet.media

   F3 200 OK 

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 207.82.37.67
   From: Anonymous <sip:[email-masked]>
   To: sip:[email-masked];tag=601718-1330
   Call-ID: [email-masked]
   Contact: <sip:[email-masked]:5060;user=phone>
   CSeq: 965506497 INVITE
   Content-Type: application/sdp
   Content-Length: 134
   Supported: com.netergynet.media
   X-Media: Alerting

   v=0
   o=- 3295 7550 IN IP4 207.82.37.28
   s=-
   c=IN IP4 207.82.37.28
   t=0 0
   m=audio 20698 RTP/AVP 0

   F4 ACK 

   ACK sip:[email-masked] SIP/2.0
   To: sip:[email-masked];tag=601718-1330
   From: Anonymous <sip:[email-masked]>
   Via: SIP/2.0/UDP 207.82.37.67
   Content-Length: 0
   Call-ID: [email-masked]
   CSeq: 965506497 ACK
   Supported: com.netergynet.media

   F5 INVITE 

   INVITE sip:[email-masked] SIP/2.0
   Content-Type: application/sdp
   To: Anonymous <sip:[email-masked]>
   From: sip:[email-masked]
   Via: SIP/2.0/UDP 207.82.37.28
   Content-Length: 116
   Call-ID: [email-masked]
   CSeq: 965506498 INVITE
   Supported: com.netergynet.media
   X-Media: Connect

   v=0
   o=- 967711854878 967711854878 IN IP4 207.82.37.67
   s=-
   c=IN IP4 207.82.37.226
   t=0 0
   m=audio 8000 RTP/AVP 0

   F6 200 OK 

   SIP/2.0 200 OK
   To: Anonymous <sip:[email-masked]>
   From: sip:[email-masked]
   Via: SIP/2.0/UDP 207.82.37.28
   Call-ID: [email-masked]
   CSeq: 965506498 INVITE
   Content-Type: application/sdp
   Content-Length: 134
   Supported: com.netergynet.media

   v=0
   o=- 3295 7550 IN IP4 207.82.37.28
   s=-
   c=IN IP4 207.82.37.28
   t=0 0
   m=audio 20698 RTP/AVP 0

   F7 ACK 

   ACK sip:[email-masked] SIP/2.0
   To: Anonymous <sip:[email-masked]>
   From: sip:[email-masked]
   Via: SIP/2.0/UDP 207.82.37.28
   Content-Length: 0
   Call-ID: [email-masked]
   CSeq: 965506498 ACK
   Supported: com.netergynet.media

With the header X-Media (to be renamed) :
X-Media = "X-Media" ":" media-type
media-type = "Alert" | "Progress" | "Connect"
 
> 
> Jean-Hugues ROBERT wrote:
> >
> > Hi,
> >
> > Short form: In the presence of Early Media, prior to receiving 200 OK, how
> > can a Caller tell a Callee to send media according to a *new* SDP ? Or "How
> > can I put a call on hold when I hear a remotely generated ringback tone ?"
> >
> > Much longer form:
> >
> > It is generaly agreed that making Media and Signaling distinct is a good
> > thing. Amoung other benefit it enables decomposed architectures and more
> > generaly support the locality of concern principle.
> >
> > A prime example of this distinction is SDP usage in SIP. SIP is basically
> > concerned by Signaling whereas SDP is about Media.
> >
> > Signaling is mainly about setting up and tearing down communications. Media
> > is mainly about payload formats and destinations.
> >
> > It is my understanding that, prior to 183 Session Progress, Media data
> > started to flow only after INVITE's 200 OK final response was received or
> > acknowledged (depending on side).
> >
> > Afterward, changes impacting Media (changes in SDPs) occured at any time
> > using re-INVITE. Callee could ask Caller "Please now handle Media according
> > to this new SDP". Caller could do the same. This was fine.
> >
> > However, since 183 Provisionnal response was introduced, as well as other
> > new occasions to change SDPs during call setup, Media can start to flow
> > well before 200 OK, or even in the total absence of 200 OK.
> >
> > This may introduce an issue regarding control of Media, during the setup phase:
> >         Callee can still ask Caller "Please now handle Media according to this
> > *new* SDP", simply sending a new 183. However I fear that Caller *cannot*
> > ask Callee to change Media any more.
> >
> > To be fully accurate, it seems that Caller could still ask Callee to change
> > Media, if SDP is allowed in PRACK, but only in response to Callee doing it
> > first. Is SDP legal in PRACK's ack message ?
> >
> > So my question is: "In the presence of Early Media, how can a Caller ask a
> > Callee to handle Media according to a new SDP when Caller's INVITE
> > transaction is still not completed ?".
> >
> > One potential solution could be to allow re-INVITE while the "main" INVITE
> > is still not completed. It is illegal today. This would introduce
> > "nested-transaction", but I guess that (PR w/SDP + PRACK) is already a form
> > of nested transaction, isn't it ?
> >
> > Another solution, probably simplier, would be to enable 183 "both ways":
> > The Caller would have the rigth to send it to the Callee, potentially only
> > in the presence of Early Media. But that seems weird, because it is a
> > reponse without a question.
> >
> > If you are guessing "why the hell does this matter ?", please think of
> > potential restrictions if Media cannot change while call is beeing setted up.
> >
> > One example related to mobility (probably not 100% relevant, not a thread
> > to SIP for Mobility):
> > Lets say I have a decomposed cheap wireless IP phone:
> >         - The expensive UA has a fixed IP address and a full featured SIP stack
> > with a fancy Java user application, it handles multiple phones.
> >         - The cheap phones have no fixed IP addresses, a very ligth
> > Codec+RTP+UDP+IP stack and some minimal stimulus protocol to interact with
> > the UA.
> > Whenever the phone's IP address changes, the UA will change the Media of
> > the involved SIP calls, if any.
> >
> > Now the issue: What if the phone moves while receiving Early Media (say
> > remote ringback tone) ? UA need to tell the Callee about the Calling
> > phone's new IP address. How ?
> >
> > Other, simplier, issues: How do I put a call on hold when I am listening to
> > some network generated annoucement ? How can an assistant, dialing on
> > behalf of the boss, transfer the ringing call to the boss when ringback
> > tone is generated remotely ?
> >
> > Any previous art in solving this issue (if it is actually an issue) ?
> > Is there a similar issue in H.323 (Early H.245 related I guess) or was it
> > solved ?
> >
> > BTW: A *radical* solution would be to avoid 1xx responses that initiate
> > Early Media and have a 200 OK as soon as media is there (with probably some
> > hints that the call/session is not "fully" established). Some yet to define
> > "INFO Session Progress" could later on indicate how the call is
> > progressing. This has the merit of beeing compatible with existing
> > implementations.
> >
> > Jean-Hugues Robert
> > ---------------------------------------------------------------------------
> > "Fix Bugs First"
> > Sophia General Manager.
> > mailto:[email-masked]      - We serve providers -     "Think globally.
> > http://www.netergynet.com     - Hosted PBX solutions -        Act locally."
> >
> 
> --
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 

-- 
Marc Petit-Huguenin
Home: mailto:[email-masked]
Work: mailto:[email-masked]
"So much to do and so little time" The Joker - Batman (The Movie)

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 19 Aug 2000 01:57:58 -0400

> thou art the master! :-)

Well, thanks, but I didn't propose this header, Marc did.

In any case, seems like the consensus here is to punt this, and stick
with what we have re 183 and SDP in provisionals.

-Jonathan R.

---

From: Jean-Hugues ROBERT <[email-masked]>
Date: Sat, 19 Aug 2000 13:35:35 +0200

Hi,

Well... Installed base syndrom bites again...

With consensual 183, an ad-hoc solution is to switch the Early Media, this 
is better than switching all the media for the call and worse than 
switching no media at all.

I.E: To change the destination of the early media of an ougoing call before 
the call is connected, the caller has to instruct the receiver of the media 
to retransmit it to the new destination. When the call is connected, caller 
will send a re-INVITE to have the media directed to the rigth destination 
directly by the callee.

What should be the name for such a switching function ? "RTP Proxy", "RTP 
Switcher", "ISWF, Integrated Switching Fabric" ?

Nota: This is an ad-hoc solution for an hypotetical cheap decomposed 
wireless IP phone.

Nota: This does not solve the "hold" case. I.E. there is no way to stop the 
early media from flowing.

Conclusion: 183 results in "During call setup, Callee is stronger than 
Caller because only Callee can change SDP for Early Media, workaround is to 
switch the Early Media". Is there a place (some draft) to store this 
solution for a PSTN interoperability related issue ?

Yours,

Jean-Hugues Robert

---

From: Michael Thomas <[email-masked]>
Date: Sat, 19 Aug 2000 09:02:03 -0700 (PDT)

> Nota: This is an ad-hoc solution for an hypotetical cheap decomposed 

   If you want decomposed, use MGCP/MEGACO.

   I've been hearing some rumblings in wireless
   about hacking on SIP to make way for a "dumbed
   down" phone. As, in trying to offload some of
   the call processing and who knows what else off
   the "dumb" phone. Maybe somebody else has a
   clear definition of what that might be, but I'm
   extremely suspicious that:

   1) A "dumbed down" phone will not in fact be any
      dumber given the things it must do which
      have nothing to do with SIP, per se.

   2) That Moore's Law hasn't already made
      need for gobs of extra complexity moot. Ram
      and flash are about $2/MB retail. 

   There are some clear disadvantages of trying to
   use some UA-like proxy though: namely garden
   walls, end to end transparency, and far worse,
   privacy/security. In order to justify this sort
   of architecture, the cost savings would need to
   be at least an order of magnitude down on a
   cost item that actually impacts the COG's
   significantly. This ain't one of them, IMO.

		       Mike

---

From: Michael Thomas <[email-masked]>
Date: Sat, 19 Aug 2000 10:14:20 -0700 (PDT)

Jean-Hugues ROBERT writes:
 > At 09:02 AM 8/19/00 -0700, Michael Thomas wrote:
 > When wireless IP phone IP address is changed, early 
 > media need to be delivered to the new IP address, not the old one. That is 
 > were a RTP Switcher is needed.

   This is if you make the assumption that you can't
   use IP mobility instead which solves the general
   problem. I've seen some pretty promising work on
   that front which looks like it converges very, very
   fast. Application layer routing should be the last
   option, not the first in my opinion.

 > Good points. Fact is, there is no such thing as a cheap IP phone, wireless 
 > or not... yet.
 
 > What is "COG" ?

   Sorry, cost of goods.

	       Mike

---

From: Jean-Hugues ROBERT <[email-masked]>
Date: Sat, 19 Aug 2000 18:29:32 +0200

Hi,

"Switching early media solves the cheap decomposed wireless IP phone case"

>   If you want decomposed, use MGCP/MEGACO.

Sure. In the cheap wireless IP phone case, MGCP could be used to have the 
"full featured java based SIP UA with a fancy user application" tell the 
dump writeless phone were to send media. However this does not solve the 
early media issue. When wireless IP phone IP address is changed, early 
media need to be delivered to the new IP address, not the old one. That is 
were a RTP Switcher is needed.

What is "COG" ?

Yours,

Jean-Hugues Robert

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 19 Aug 2000 15:23:08 -0700

OK, let me try again,

I understand that all the design and implementations made for the 18x
cannot simply be thrown. But I think that the idea of having the
alerting after the establishement of the session is interesting, and
even can be extended. 
My previous mail described the X-Media header just as an information
header, just to know when starting the billing. We can replace it by
another header:

Call-State = "X-Call-State" ":" call-state
call-state = "Idle" | "Offered" | "Queued" | "Alerting" | "Talking" |
"Held" | "Failed" | "Disconnected"

In this scenario, this header is mandatory (with a Require header) and
all the provisonnal responses except the 100 are forbidden. Now each SIP
Agent is a state machine and each request or response contains the state
of the machine that send the message.

We can imagine a SIP gateway in the "grey" zone between Internet and the
PSTN who can work like this:

Internet             Gateway               PSTN
   |  INVITE Idle       |                   |
   |------------------->|      INVITE       |
   |  100 Idle          |------------------>|
   |<-------------------|      100          |
   |  200 Offered       |<------------------|
   |<-------------------|                   |
   |  ACK Talking       |                   |
   |------------------->|                   |
   |                    |                   |
   |                    |      18x          |
   |  INVITE Alerting   |<------------------|
   |<-------------------|                   |
   |  OK Talking        |                   |
   |------------------->|      PRACK        |
   |  ACK Alerting      |------------------>|
   |<-------------------|      200 PRACK    |
   |                    |<------------------|
   |                    |                   |
   |                    |                   |
   |                    |      200          |
   |  INVITE Talking    |<------------------|
   |<-------------------|                   |
   |  OK Talking        |                   |
   |------------------->|      ACK          |
   |  ACK Talking       |------------------>|
   |<-------------------|                   |
   |                    |                   |

Now we can put an alerting session on hold. The RTP packets from the
PSTN side are discarded by the RTP translator in the Gateway, just like
in (1)

Internet             Gateway               PSTN
   |  INVITE Idle       |                   |
   |------------------->|      INVITE       |
   |  100 Idle          |------------------>|
   |<-------------------|      100          |
   |  200 Offered       |<------------------|
   |<-------------------|                   |
   |  ACK Talking       |                   |
   |------------------->|                   |
   |                    |                   |
   |                    |      18x          |
   |  INVITE Alerting   |<------------------|
   |<-------------------|                   |
   |  OK Talking        |                   |
   |------------------->|      PRACK        |
   |  ACK Alerting      |------------------>|
   |<-------------------|      200 PRACK    |
   |                    |<------------------|
   |                    |                   |
   |                    |                   |
   |  INVITE Held       |                   |
   |------------------->|                   |
   |  OK Talking        |                   |
   |<------------------>|                   |
   |  ACK Talking       |                   |
   |------------------->|                   |
   |                    |                   |

The discussion in the SIP mailing-list is now about the media in the
pre-connect stages (alerting, progress...), but in the future the media
stream can also be of some interest when the connection failed (i.e.
instead of a 486 Busy or a 603 Decline, I want to play a prerecorded
message - for a specific person for example). This is not relevant for
PSTN sessions but the message can be generated by the gateway:

Internet             Gateway               PSTN
   |  INVITE Idle       |                   |
   |------------------->|      INVITE       |
   |  100 Idle          |------------------>|
   |<-------------------|      100          |
   |  200 Offered       |<------------------|
   |<-------------------|                   |
   |  ACK Talking       |                   |
   |------------------->|                   |
   |                    |                   |
   |                    |      603          |
   |  INVITE Failed     |<------------------|
   |<-------------------|                   |
   |  OK Talking        |                   |
   |------------------->|      ACK          |
   |  ACK Failed        |------------------>|
   |<-------------------|                   |
   |                    |                   |
   |  BYE Disconnected  |                   |
   |------------------->|                   |
   |  OK Disconnected   |                   |
   |<-------------------|                   |
   |                    |                   |

With this design, we have three layers
- The first layer for searching the destination and establishing a link
(Activated between the first INVITE and the BYE). The Session-Expires
mechanism can be part of this layer.
- The second layer for the call control (state machines)
- The third layer for the media (SDP exchange)

In fact, "this proposition versus the early media" sounds like "JTAPI
versus JAIN".

Bye,