Subject: WG: [Sipping] SIP-ISUP interworking draft

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 17 Jul 2002 11:48:04 +0200

Hello Rohan

So what should a GW do if it gets the 183 with SDP just because the other side wants the allocation of resources at the GW and no indication on the ISUP side? It can not distinguish this case from the "real" session progress information that should be mapped to the ACM/CPG.

My confusion is that because of such wide definition "not otherwise classified" everybody is using the 183 if they just wand to send SDP in e2e provisional response.

So it might be better to define an additional e2e provisional response, that would allow the transportation of SDP without impacting the call/session state. As such the bearer control and the whole resource reservation has nothing to do with the session itself.

In my understanding the orthogonality does not mean that the SIP is just the transport for SDP.  It is still the call/session control protocol. So the requests and responses are driving the session state and can not be abused just for the transportation.

Greetings,
Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: Rohan Mahy [mailto:[email-masked]]
Gesendet am: Dienstag, 16. Juli 2002 17:05
An: Alexeitsev, D
Betreff: Re: [Sipping] SIP-ISUP interworking draft

Hi,

The meaning of 183 is pretty well specified in 3261:

The 183 (Session Progress) response is used to convey information about 
the progress of the call that is not otherwise classified. The 
Reason-Phrase, header fields, or message body MAY be used to convey more 
details about the call progress.

The fact that 183 (like other 18x responses and 2xx responses to an 
INVITE) can contain an SDP offer or answer is completely orthogonal to 
the semantics of the response code.

thanks,
-rohan

_______________________________________________
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

---

From: Michael Hammer <[email-masked]>
Date: Wed, 17 Jul 2002 15:53:32 -0400

Denis,

What I hear you saying is that the mapping of the 183 to ACM/CPG will cause 
problems for your state machine on the ISUP side.  What exactly is the 
issue?  That there is no event indicator to distinguish between 'alerting' 
and 'progress', which may come from a ISUP-SIP GW in embedded ISUP, but not 
from a pure SIP end-point?  And that the state of the bearer setup is not 
relevant to your problem?

Mike

At 11:48 AM 7/17/2002 +0200, Alexeitsev, D wrote:
>Hello Rohan
>
>So what should a GW do if it gets the 183 with SDP just because the other 
>side wants the allocation of resources at the GW and no indication on the 
>ISUP side? It can not distinguish this case from the "real" session 
>progress information that should be mapped to the ACM/CPG.
>
>My confusion is that because of such wide definition "not otherwise 
>classified" everybody is using the 183 if they just wand to send SDP in 
>e2e provisional response.
>
>So it might be better to define an additional e2e provisional response, 
>that would allow the transportation of SDP without impacting the 
>call/session state. As such the bearer control and the whole resource 
>reservation has nothing to do with the session itself.
>
>In my understanding the orthogonality does not mean that the SIP is just 
>the transport for SDP.  It is still the call/session control protocol. So 
>the requests and responses are driving the session state and can not be 
>abused just for the transportation.
>
>Greetings,
>Denis Alexeitsev
>

---

From: "Alexeitsev, D" <[email-masked]>
Date: Thu, 18 Jul 2002 11:25:12 +0200

Hello Michael

The issue of mapping 183 to ACM/CPG for the manyfolks case is resolved by the Chris Hoggs message.

The bigger point I'm trying to make is the general abusation of 183 message of SIP as call/session control protocol for the bearer control procedures. In SIP the 183 as a provisional response has no impact at the SIP call/session state (that is why in my understanding it was taken), but for the ISUP call state it is crucial. So I would like to see the separation of call and bearer control procedures is SIP in the backward direction as it was already started with the introduction of UPDATE method in forward direction.

Greetings,
Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: Michael Hammer [mailto:[email-masked]]
Gesendet am: Mittwoch, 17. Juli 2002 21:54
An: Alexeitsev, D
Cc: [email-masked]
Betreff: Re: WG: [Sipping] SIP-ISUP interworking draft

Denis,

Mike