[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip
Subject:    RE: [SIP] SUS/RES encapsulation
From:       Jon.Peterson () Level3 ! com
Date:       2001-06-11 20:57:23
[Download RAW message or body]

I think this case is interesting in so far as the originating PSTN gateway
(which has received the SUS and which will subsequently send a re-INVITE or
INFO) is making a decision about how the terminating SIP endpoint should
react to the suspension of the PSTN leg of the call. In some networks it
might not matter if the terminating SIP endpoint continues to transmit media
to the PSTN gateway while the call is suspended. If however the terminating
SIP endpoint is using a dialup link for connectivity or has some similar
bandwidth constraint, the endpoint might want to stop transmitting media.

So, should a SIP endpoint (which could be a native SIP phone with no
understanding of ISUP) have to understand a SUS in INFO in order to know
that it should stop transmitting media, if its local policies suggest that
it should do just that? Should the PSTN gateway decide this for SIP
endpoints (perhaps it makes a difference if they are in the same
administrative domain or not)? On the converse side, is there any harm in
the PSTN gateway sending a re-INVITE on receipt of SUS? I don't see why it
would be undesirable to cease the flow of media for the duration of the
suspension of the call, especially considering that suspensions most often
lead to the termination of the call.

I am certainly wary of defining two mechanisms for this (i.e. allowing both
INFO and re-INVITE for SUS), since I'm not sure why a gateway vendor would
implement one rather than the other. Perhaps if there needs to be a
mechanism by which the gateway can handle a SUS without forcing a change in
the media characteristics of a call, it could send a re-INVITE without SDP,
or something. Personally I'd rather see one defined way of handling this
case.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
Sent: Monday, June 11, 2001 6:53 AM
To: Jonathan Rosenberg
Cc: sip; Peterson, Jon; adam.roach@ericsson.com
Subject: Re: [SIP] SUS/RES encapsulation


Hello,

Jonathan Rosenberg wrote:
> I may be mistaken, but I thought
> that SUS really was an end-to-end hold of media, and therefore, should be
> mapped to the equivalent function in SIP - a re-INVITE with 0.0.0.0 SDP.

SUS is used when an ISDN subscriber unplugs his phone from the socket
and plugs it in another socket in the middle of the call. When the call
is SUSpended, the local exchange of the user unplugging the phone cuts
the media, but the rest of the switches do not do anything.

SUS is also sent by the an analog callee when he hangs up, but for our
purposes it does not matter which one of the scenarios we are dealing
with.


I agree with you that SDP 0.0.0.0 is the proper way to go, and that's
why it was included in the draft in the first place. However, I have
been receiving comments about this proposing a differeent mapping.
That's why I wanted to get the opinion of the mailing list. My personal
opinion was written in the draft already.

The proposal that I have received is that, since in the PSTN all the
switches but the local exchange do not do anything, the SUS message can
be mapped to an INFO message, since it does not affect the state of the
session.

Opinions?

Best regards,

Gonzalo
-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              Gonzalo.Camarillo@ericsson.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
sip-implementors-request@cs.columbia.edu with "subscribe" in the body.

[prev in list] [next in list] [prev in thread] [next in thread]