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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 17 Aug 2000 00:00:09 -0700

> 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).
> phone's new IP address. How ?

I am trying to get this assertion verified at the moment. I was told that
180 (with SDP) should be used for remote ringback (ie early media) and that
183 should _not_ be be used for remote ringback. This does not affect your
arguments. As Jonathan says, if we could make the early media thing go away,
great but until then I think we need to get the situation clarified.

It is my understanding that many people at the bakeoffs are using 183 for
remote ringback. I personally think it is a good thing to keep all the early
media handling under one response code despite some valid arguments that 183
does not necessarily infer that user being alerted (eg, you could be in a
queue).

Cheers,

Robert.

-- My opinions are my own. I tried selling them once but everybody
	seems to already have one. -- 

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

---

From: "Arnoud van Wijk (ETM)" <[email-masked]>
Date: Thu, 17 Aug 2000 11:35:59 +0200

Hmmmm
I agree that this is something that we need to look at. Or at least get a consensus on it.
I would, sofar I understand the problem, just select option 1 from Jonathon. Setup continues, and if it is not desired anymore, a CANCEL or BYE can be sent (right?). And a change DURING a call (after the media setup has been executed via SDP) will just work with a re-INVITE message.
We just have to accept that we deal with limitations. I cannot call this a real issue. The setup of a SIP call will not take THAT much time after all. Maybe what we can do is a 183 message that tells that user failed to connect, please retry the call.
Or something like that. 

That are my 2 cents

Arnoud van Wijk

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

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.

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

---

From: Jean-Hugues ROBERT <[email-masked]>
Date: Thu, 17 Aug 2000 12:36:05 +0200

Hi,

"SIP Caller cannot Hold/ChangeSDP during call setup with Early Media"

At 11:35 AM 8/17/00 +0200, Arnoud van Wijk (ETM) wrote:
>We just have to accept that we deal with limitations. I cannot call this a 
>real issue. The setup of a SIP call will not take THAT much time after 
>all. Maybe what we can do is a 183 message that tells that user failed to 
>connect, please retry the call.

How much time is tolerable ?

Apparently there are Telco, on PRI-ISDN links, that do not deliver Q.931 
Connect *at all*, to be confirmed.

On other PSTN numbers, Connect is delivered after one minute. The offending 
PSTN numbers are often 800 style numbers.

PSTN & AIN experts can probably explain this.

If we agree that this is an issue, I am begining to suspect that some "200 
OK Cause=Early Media" + callee initiated "re-INVITE, Cause=SessionProgress" 
could be a viable solution, because it would work with existing 
implementations (it also removes the issue of the reliability of 
provisional responses, if we extend its usage to all calls, not just ones 
with EarlyMedia). I am not a SIP expert so please be forgiving, I am 
willing to learn. Thanks.

Yours,

Jean-Hugues Robert.

---

From: "Ashutosh Dutta" <[email-masked]>
Date: Mon, 21 Aug 2000 15:23:37 -0400

Or better use dynamic home agent as often proposed and dynamic DNS ( as
described in HMMP and a recent host mobility paper in Mobicom 2000) may help if
the home agent is still in the home subnet, but still do not know how reverse
lookup for A record in different domain with different SOA would work for a
foreign IP address in that case.

Thanks
Ashutosh

Michael Thomas <[email-masked]> on 08/21/2000 02:38:39 PM

To:   Henning Schulzrinne <[email-masked]>
cc:   Michael Thomas <[email-masked]>, Ashutosh Dutta <[email-masked]>,
      "Arnoud van Wijk (ETM)" <[email-masked]>, "'SIP'"
      <[email-masked]> (bcc: Ashutosh Dutta/Telcordia)
Subject:  Re: [SIP] Media & Signaling inter-dependencies, issue with 183 ?

Henning Schulzrinne writes:
 > Michael Thomas wrote:
 > >    This assumes that the HA is always at "home".
 >
 > No, but it has to be somewhere where the network is willing to give me a
 > permanent IP address. I'm not aware of such a service, although it would
 > be quite useful.

For every problem there is an equal and opposite
opportunity. :-)

I personally think there is a good deal of
motivation for wireless things to not have their
HA on the same subnet as their real home
subnet. The main reason is that a dog-leg through
a comparatively slow access (cable, DSL, etc) that
almost certainly wants you to pay for QoS bits
doesn't sound like a very ideal situation to
me. It would be a lot cleaner to put the HA in the
middle of a diffserv cloud and be done with it.

 > >    Also: I'm not sure how you're naming your UA
 > >    behind the NAT/firewall without the help of
 > >    some sysadmin type person.
 >
 > Not really. I can imagine using a permanent address of the
 > hotmail/yahoo/etc. variety without any sysadmin help and without fees.
 > There is no shortage of user or domain names. I could run such a service
 > on my DSL line at home, with one IP address.

What bound the A record to your domain name?

            Mike