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

From: Jean-Hugues ROBERT <[email-masked]>
Date: Wed, 16 Aug 2000 12:18:49 +0200

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."

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Aug 2000 02:12:57 -0400

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.

-- 
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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 17 Aug 2000 07:31:23 -0700

> and see if those issues could be resolved some other way?

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"

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

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 17 Aug 2000 17:09:21 +0200

These are the kind of anomalies that are to be expected when nested
calls are introduced. I believe when we had this discussion last time it
all got down to billing eventually. I guess most people would agree that
(ideally at least) the signaling protocol shouldn't depend on billing.
Option 3 seems much preferable to me - avoid doing early media and set
up legs properly. Option 2 is just an abomination.

Anders

---

From: "Simon Barber" <[email-masked]>
Date: Thu, 17 Aug 2000 10:34:57 -0700

The reason for the problem here is that functionality in SIP isn't as
clearly layered as it could be. Early media mixes up call setup and bearer
setup layers. Sticking to option 3 separates call setup into one layer and
media setup into another. This simplifies the protocol - we should do this
if at all possible.

Simon Barber

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Anders Kristensen
Sent: Thursday, August 17, 2000 8:09 AM
To: Jonathan Rosenberg
Cc: Jean-Hugues ROBERT; [email-masked]
Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183
?

Anders

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 17 Aug 2000 14:28:28 -0400

----- Original Message -----
From: Anders Kristensen <[email-masked]>
To: Jonathan Rosenberg <[email-masked]>
Cc: Jean-Hugues ROBERT <[email-masked]>; <[email-masked]>
Sent: Thursday, August 17, 2000 11:09 AM
Subject: Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ?

> up legs properly. Option 2 is just an abomination.

I agree that option 2 adds too much complexity to SIP.

However I think that early media is very useful for ip-telephony;
thus I would hate to see option 3 get adopted.  I just feel that
early media needs to be more explicitly defined;
please see "Remote ringback" thread.

I think that if the caller needs to change SDP,
the caller needs to wait until after the call is
answered before sending a message with the new SDP.

Unless considered a violation by the Transfer draft,
the following is an overkill strange possibility.
The caller can REFER the called party back to caller and
provide the new SDP in the 200rsp, and CANCEL the
original INVITE before the called party answers.  When
the original called party answers, the SDP is passed in
the ACK.

---

From: Manoj Bhatia <[email-masked]>
Date: Fri, 18 Aug 2000 11:21:00 -0400

I would strongly debate against changing the existing semantics of
18x messages. We have discussed 18x too much and had arrived on this
semantics of 183 . The 183 draft is clear on what needs to be done with
the response and what does an SDP mean in 183.

The original concept of 180 (with or without SDP) and 183 (with SDP always)
works fine for all the scenarios today.

For a UAS willing to feed any ringback /early media or announcements, the
choice of
183 with SDP is there.
These messages were thought about carefully and they mapped to ALERTING and
PROGRESS events from PSTN world. Any change in semantics like using a generic
200 OK (As suggested in option 3) for all events then using SIP headers to
decide
what to do might be an overkill.
Think about the SIP drafts which are already under review based on this logic.

I still have concerns about :
1) Why a need to distinguish a remote ringback case from a remote media ?
2) If  the caller wishes to change the media before the call is established,
the option 2 of sending re-INVITE is the most logical way to do.
Agreed, that it is a pain; but so is everything down the lane when
QoS/PRACK/COMET/
3pcc/ INVITE with DELAYED media et a.

Comments ?

thanks
-manoj

--
Manoj Bhatia                           |        |         |
[email-masked]                       |       :|:       :|:
7025 Kit Creek Road, RTP, NC - 27709   |     :|||||:   :|||||:
Ph: 919-392-3873  IP: 919-991-5714     |  C i s c o S y s t e m s

---

From: "Steve Donovan" <[email-masked]>
Date: Fri, 18 Aug 2000 10:33:27 -0500

The motivation for introducing the early media concept, and the various
solutions were explored in the original 183 draft, which appears to have
expired, as it is no longer on the IETF site.  However, it can be found at:

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-183-00.txt

It is an interworking issue that has billing implications, not a billing
issue.  I will not go into it here, as it has been documented already.

I am certainly willing to explore other methods for solving this
interworking issue.  However, I would suspect that there are a number of
implementations out there that have implemented early media with 183.
Please also remember that there were a number of proposals discussed on the
list for other creative uses of the early media concept.

I have also seen it proposed in this and other threads that the ability to
attach SDP to a provisional response should be removed from the bis draft.
Doing so would break the QoS and security solutions documented in:

http://www.softarmor.com/sipwg/drafts/draft-manyfolks-sip-resource-01.txt

I suspect that the same issue raised about early media also applies to the
use of SDP in a 18x message for the purpose of setting up QoS and security
relationships.

It may not be the cleanest solution, but I vote for number 1 and making it a
client problem to handle changing of the IP address during session setup.

Steve

> [mailto:[email-masked]]On Behalf Of Jonathan Rosenberg
> Sent: Thursday, August 17, 2000 1:13 AM
> To: Jean-Hugues ROBERT
> Cc: [email-masked]

---

From: Alan Johnston <[email-masked]>
Date: Fri, 18 Aug 2000 14:11:11 -0500

I agree - 183 seems to work, and many PSTN Gateway vendors area  long
way down this road.

Since the 183 I-D has expired, I wonder what replaces the Session header
that was proposed in that draft.  I think it is critical for a UAC to be
able to distinguish between SDP which is optional, and may safely ignore
(such as a customized ringtone or other feature) and early media which
can contain information about the final status of the call (ring no
answer, busytone, recorded announcement "The number you have dialed has
changed.  The new number is ...") that might be received from the PSTN.

Is it the consensus that SDP in a 180 response falls into the first
category - the UAC has the option of playing or not playing to the user,
and SDP in a 183 falls into the second category of "ignore at your
peril"?

As for Jonathan's options, I vote for 1.

Alan Johnston

Manoj Bhatia wrote:

> For a UAS willing to feed any ringback /early media or announcements,
> the choice of
> 183 with SDP is there.
> 200 OK (As suggested in option 3) for all events then using SIP
> headers to decide
>> > > > 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
>> > > > A prime example of this distinction is SDP usage in SIP. SIP
>> is
>> basically
>> > > > Signaling is mainly about setting up and tearing down
>> communications.
>> Media
>> > > > started to flow only after INVITE's 200 OK final response was
>> received
>> or
>> > > > Afterward, changes impacting Media (changes in SDPs) occured
>> at any
>> time
>> > > > using re-INVITE. Callee could ask Caller "Please now handle
>> Media
>> according
>> > > > However, since 183 Provisionnal response was introduced, as
>> well as
>> other
>> > > > new occasions to change SDPs during call setup, Media can
>> start to
>> flow
>> > > > 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*
>> > > > 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
>> > > > So my question is: "In the presence of Early Media, how can a
>> Caller
>> ask a
>> > > > One potential solution could be to allow re-INVITE while the
>> "main"
>> INVITE
>> > > > "nested-transaction", but I guess that (PR w/SDP + PRACK) is
>> already a
>> form
>> > > > 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
>> > > > 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):
>> > > >         - The expensive UA has a fixed IP address and a full
>> featured
>> SIP stack
>> > > > 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
>> > > > Now the issue: What if the phone moves while receiving Early
>> Media
>> (say
>> > > > Other, simplier, issues: How do I put a call on hold when I am
>>
>> listening to
>> > > > behalf of the boss, transfer the ringing call to the boss when
>>
>> ringback
>> > > > 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
>> --------------------------------------------------------------------------
>>
>> -
>> > > > "Fix Bugs First"
>> > > > Sophia General Manager.
>> > > > mailto:[email-masked]      - We serve providers -
>> "Think
>> globally.
>> > > > http://www.netergynet.com     - Hosted PBX solutions -
>> Act
>> locally."
>> > > >

---

From: Manoj Bhatia <[email-masked]>
Date: Fri, 18 Aug 2000 15:21:05 -0400

I agree to Steve's point that QoS aware SIP UAs would have to take the option
(1)
because of so much interworking already based on the current logic.
For QoS unaware UAs, the option (2 or 3) which are messy are do-able.

I feel that 'media-aware SIP UAs ' are already burdened
with handling  complexities in implementing the following :
3pcc, early media, Reliable Prov responses, Manyfolks draft
which are all media related features. Any tweaks in basic call flows at this
point
either suggests that we moved too much ahead too fast or that we are
now stretching it too far.

It is quite natural that softswitch/proxy server/'media unaware UA"
implementors
are not seeing the above load .

thanks
-manoj

> > 200 OK, how
> > SDP ? Or "How
> > ringback tone ?"
> > communications. Media
> > received or
> > Media according
> > well as other
> > the setup phase:
> > according to this
> > Caller *cannot*
> > Callee to change
> > Callee doing it
> > Caller ask a
> > "main" INVITE
> > already a form
> > potentially only
> > beeing setted up.
> > not a thread
> > featured SIP stack
> > interact with
> > probably some
> > yet to define
> > "Think globally.
> > Act locally."